# API Eventing Is The Next Big Opportunity For API Providers
## API에게 이벤트 달기



지난 10 년 여 동안 최신 웹 API는 Flickr와 같은 솔루션에서 새로운 비즈니스 모델을 생성하는 강력한 플랫폼으로 성장했습니다. 이 성장 기간 동안 대부분의 API는 HTTP를 통한 요청-응답으로 제한되었습니다. 이제 SaaS 솔루션을 연결하는 Webhook의 인기, 내부 메시징을 구동하는 Kafka와 같은 기술의 도입, IoT 장치 통합의 필요성과 함께 이벤팅으로 다시 돌아가고 있습니다.
API 이벤트는 API 소비자가 API와 상호 작용하는 방식을 완전히 바꿔놓아서 요청-응답이 할 수 없는 새로운 가능성을 만듭니다. API 이벤트 지원을 API에 추가하는 것을 여러 분이 고려하도록 영감을 줄 기회와 함께 API 이벤트 발생에 기여하는 추동 요인 (driving factors)을 살펴 보겠습니다.

##  **왜 여러분의 API가 이벤트를 지원해야 할까요?**


### 이유 1: API 이벤트는 혁신을 주도합니다. 

GitHub 플랫폼에 WebHooks가 도입됨에 따라 소프트웨어 개발이 크게 바뀌었습니다. 팀은 더 이상 빌드 프로세스를 버튼을 클릭하여 명시적으로 시작할 필요가 없습니다. 매일 또는 매시간 빌드를 생성한다는 아이디어는 과거의 일이 되었습니다. 대신 팀은 새 코드가 GitHub에 푸시 될 때마다 빌드 프로세스를 시작할 수 있습니다. Post-commit hooks는 항상 svn 및 git의 일부 였지만, GitHub는 이러한 이벤트 스트림을 전체 웹에 걸쳐 확장했습니다. 클라우드 공급 업체의 API와 결합 된 WebHooks는 팀이 자신이 선택한 어떤 환경에서든지 코드를 구축하고 배포 할 수있게 해주며, 모두 WebHooks에 의해 구동됩니다.  


### **이유 2: API 이벤트는 협업을 가능하게 합니다.**

HipChat 및 Slack과 같은 메시징 플랫폼은 팀원들이 협업하는 방식을 변화 시켰습니다. 이러한 팀 메시징 플랫폼은 bots와  command-line 자동화를 통합 할 기회를 열었습니다. 그 결과 기존의 IRC 및 그룹 채팅을 뛰어 넘는 새로운 커뮤니케이션 방법이 탄생했습니다. 이를 위해, 이러한 플랫폼은 요청-응답 API와 실시간 이벤트 스트리밍의 조합을 제공하여 외부 앱, 봇 및 API를 플랫폼에 원활하게 통합 될 수 있도록 합니다.  


### **이유 3: API 이벤트는 코드 없는 통합을 주도합니다.** 

SaaS (Software-as-a-Service) 제품은 점점 더 통합을위한 API를 제공하고 있습니다. [Zapier](https://zapier.com/)(link) 나 [IFTTT](https://ifttt.com/)와 같은 iPaaS (Integration Platform as a Service) 도구는 복-붙 없이 많은 공통 작업을 자동화하기 위해 서로 연결 할 수 있게 지원합니다. 많은 iPaaS 제품은 사용자를 대신하여 코드마저도 호스팅 해주기 때문에 서버와 인프라를 관리 할 필요가 없습니다.  

이러한 종류의 통합은 항상 코드 작성을 요구하지는 않지만, API에서 제공하는 트리거 유형에 따라 제한됩니다. API가 요청 / 응답 지원만 제공하는 경우에는, 클라이언트는 중요한 데이터에 변경 사항이 있는지 확인하기 위해 폴링을 해야합니다. API 이벤트를 통해, 이러한 도구들은, 데이터가 변경 될 때 트리거 (해당 이벤트)를 수신하고 요구되는 자동화 흐름을 실행할 수 있습니다.  


### **이유 4: API 이벤트는 유연한 아키텍처를 생성합니다.**

점점 더 많은 팀이 전체 솔루션의 일부를 이해하는 데 필요한 인지 부하를 줄여 복잡한 솔루션 주변에 경계를 설정하는 방법으로서 마이크로 서비스 아키텍처를 탐색하고 있습니다. 이 모든 것은 신속하게 기능을 제공 할 수 있는 소규모의 독립적인 팀을 만들어서 제공 속도를 높이는 것을 목표로 수행됩니다. 느슨하게 결합된 마이크로 서비스 아키텍처의 결과로 서비스는 비즈니스 워크플로우를 구동하는 데이터 변경 및 주요 비즈니스 이벤트를 다른 마이크로 서비스에 알리는 이벤트를 내 보냅니다.  

또한 서버리스 세계 안에서 function-as-a-service (FaaS)가 부상하고 있습니다. 전체 애플리케이션을 배포하는 대신 더 작은 기능이 배포 된 다음 메시지 기반 이벤트 또는 요청 / 응답 스타일 호출을 제공하는 API 게이트웨이를 통해 트리거 됩니다.  

Kafka, RabbitMQ 또는 Amazon SNS / SQS와 같은 메시징 브로커는 종종 마이크로 서비스 이벤트를 유도하고 함수 기반 서비스 (function based service)를 트리거하는 데 사용됩니다. 이는 내부 메시징에 대한 유효한 솔루션이지만 외부화를 위해 설계되지 않았습니다. 이벤트를 외부화하는 경우 소비자가 WebHook, event streaming,  또는 어쩌면 일부 상황에서는 덜 효율적인 long-polling의 조합을 사용하여 이벤트를 소비하는 방법을 고려해야 합니다.  


### **이유 5: 이벤트는 사물인터넷과 엣지 컴퓨팅을 위한 접착제 입니다.**

집이나 사무실 주변에 스마트 기기가 있을 것입니다. 이러한 장치는 웹 또는 모바일 장치의 중요한 데이터 및 이벤트를 시각화하기 위해 종종 클라우드 서비스와 통신합니다. 공급 업체가 제공하는 클라우드 기반 API를 통해 IoT 서비스와 통합하면 타사 자동화 솔루션이 이러한 장치의 유용성을 확장 할 수 있으므로 이벤트 스트리밍의 이점을 얻을 수 있습니다.  

일부 장치 통합 시나리오의 경우 클라우드 리소스에 대한 네트워크 연결이 보장되지 않거나 생성 된 데이터의 양이 클라우드로 전송되기 전에 평가 및 집계가 필요할 수 있습니다. 이를 '에지 컴퓨팅'이라고 하며, 특히 고대역폭을 항상 사용할 수 있지는 않은 제조 및 에너지 산업에서 수년 동안 일반적이었습니다.  

이제 엣지 컴퓨팅이 차세대 IoT 장치의 일부로 등장 할 것이라는 신호가 있습니다. 에지 장치가 서로 통합되고 로컬 네트워크의 스마트 컨트롤러 장치와 통합하려면 이벤트 스트리밍이 필요합니다. IoT 용 API를 구축하는 경우 이벤트 스트리밍은 에지 커뮤니케이션 및 컴퓨테이션에 필수적 입니다. 
 

## **여러분의  API 가 이벤트 구독(Event Subscriptions)을 제공해야 할까요?**

API 이벤트는 일상적인 문제를 해결하기 위해 API를 사용할 때 API에 필요한 대화의 종류를 확장합니다. 우리는 팀이 API 이벤트를 추가하여 API 대화를 강화할 수 있는 방법을 고려하도록 권장합니다. 이벤트 지원이 없으면 API는 단순히 사용자가 요청 하기만을 기다리게 됩니다. 이벤트 지원이 추가됨으로써, 비로소 API는 다른 API 및 애플리케이션과 양방향 대화를 할 수 있습니다. 이를 통해 더 나은 사용자 경험을 제공하고 API 채택을 크게 확대하게 되어 소비자의 이탈을 줄입니다.  

 API에 이벤트 달기   

# Tyk 3.2 - 차세대 엔터프라이즈 FLAPIM (Full Life cycle API Management)

##**복잡한 엔터프라이즈 APIM 보안, 간편하게 처리하기**

어떤 API first 제품 비즈니스에서든지 보안은 제일 중요한 고려사항 중 하나이거나, 제일 중요한 바로 그것 입니다. 이것은 Tyk와 같은 현대의 API  기술 스택이 API 관리 플랫폼들의 심장부에 자리하고 있다는 것이 주된 이유이며, 그것이 플랫폼의 필수적인 부품이 되기 때문입니다. 플랫폼들은 강력한 보안 역량을, 내부의 API를 만드는 쪽과 외부의 API 사용자 양쪽 모두에게, 간편하고 비용효과적인 형식으로 제공합니다.

당연히, 엔터프라이즈 수준의 보안은 언제나 Tyk의 핵심 역량이었습니다만, 우리는 지금 3.2 버전 릴리스에 탑재된 더 높은 수준의 보안 역량에 대해 말하고 있는 것입니다.  완전히 판을 뒤바꿔 놓을 새로운 기능들을 여러분들이 잘 알고, 그것들이 어떻게 여러분들의 사업에  이익을 가져다 줄 지 한시 빨리 알려 드리고 싶습니다. 이것과 함께 우리는 차세대 [GraphQL 엔진](https://tyk.io/docs/graphql/)을 탑재하여 여러분들의 [Universal Data Graph (UDG)](https://tyk.io/docs/universal-data-graph/udg-concepts/)에 보안과 사용성에 터보 파워를 더하였습니다!

Tyk 3.2는 [DCR (Dynamic Client Registration)](https://tyk.io/docs/tyk-stack/tyk-developer-portal/dynamic-client-registration/)과 [OPA (Open Policy Agent)](https://www.openpolicyagent.org/) 기능들을 구현하여 Tyk의 대시보드와 개발자 포털의 호환성을 초특급으로 향상시켰기 때문에, 어떤 종류의 인증 (authorisation) 이든지 상관없이, 스트럭처나 프로세스를 구성하는 등의 모든 업무가 믿기지 않을 만큼 간단하게 형상관리을 관리하고 상태를 유지할 수 있도록 하나의 통합된 방법으로 제공됩니다. 

전체 기술을 알고 싶다면, [릴리스 노트](https://tyk.io/docs/release-notes/version-3.2/)로 바로 다이빙 하시면 되지만, 우리의 흥미진진한 새로운 기능들을 여유롭게 둘러볼 시간이 된다면 우리가 여러분의 디스커버리로 데리고 갈 수 있게 맡겨 주세요~^^

##**Dynamic Client Registration으로 자신의 IDP (Identity Provider)를 사용하기**

IDP들은 현대 APIM 스택에서 빠져서는 안될 부분이며 점점 더 많은 엔터프라이즈들이 그들의 전 자산에 걸쳐  IDP를 필수적으로 채택하고 있습니다. 이것은 3자 개발자들과 파트너들을 위한 온보딩 절차를 간소화 할 뿐 아니라, 조직의 전체적인 애플리케이션 포트폴리오에 걸쳐 하나의 통합된 보안체계를 만들 수 있게 하였습니다. 

여러분의 조직이 Keycloak를 사용하든, Gluu 또는 Okta를 외부 IDP로 사용하든 상관없이; Tyk 3.2가 제공하는 [Dynamic Client Registration](https://tyk.io/docs/tyk-stack/tyk-developer-portal/dynamic-client-registration/) 기능을 가지고, 여러분은 단지 몇 단계의 절차 만으로 그것들을 Tyk의 개발자 포털에 통합시킬 수 있습니다. 아랫단의 인증 매커니즘에 시달리거나 고민할 필요가 전혀 없습니다.

DCR은 IETF가 인증 서버를 가지고 클라이언트의 동적 등록을 하기 위한 표준을 정하기 위해 공표한 프로토콜의 일종 입니다. Tyk 개발자 포털을 통하여 앱을 생성할 때, Tyk 3.2는 해당 클라이언트를 여러분의 인증 서버에 동적으로 등록할 것입니다. 그렇게함으로써 인증 서버가 해당 서버에 대하여 클라이언트 ID와 클라이언트 시크릿을 발급하는 것입니다.


##**Open Policy Agent로 직접 커스터마이징**

API 거버넌스는 현대 엔터프라이즈의 전생명주기 API 관리 (FLAPIM, Full Life cycle APIM) 스택에 빠져서는 안되는 부분입니다. 거버넌스의 핵심 기능은 접근제어 입니다. 이것을 통하여, 스택 내에서 '맞는 행위'는 더 쉽게, '잘못 행위' 는 더 어렵게 이행되도록 보장해 주는 것입니다. 전형적인 엔터프라이즈들은 DevOps에서 API 엔지니어링과 API 관리자들, 그리고 시스템 통합자들에 이르기 까지 복수의 팀들을 가지고 있고, 이 모든 참여자들이 하나의 스택 내에서 서로 다른 관심사를 처리합니다. 다른 API들에 대한 보안 강화와 접근 제한을, 사용자들의 역할에 기반하여, 우리는 [Open Policy Agent (OPA)](https://tyk.io/docs/tyk-dashboard/open-policy-agent/)를 가지고 Tyk의 대시보드를 형상관리 하는 기능을 도입하고 있습니다. 

OPA를 가지고 사용자 정의 퍼미션을 안전하게, 효과적으로 생성할 수 있습니다. OPA의   policy 엔진은 대시보드의 정면에 위치하며, 여러분이 하이레벨 언어 ([Rego](https://blog.openpolicyagent.org/opas-full-stack-policy-language-caeaadb1e077))로 정책을 코드와 간단한 API들로 명시할 수 있게 함으로써 여러분의 소프트웨어에 대한 정책 의사결정의 짐을 덜어 줍니다.


##**GraphQL과 UDG의 기능 향상**

[Universal Data Graph (UDG)](https://tyk.io/docs/universal-data-graph/)의 GraphQL 기능서을 업데이트 하기 위해 우리는 부단한 노력을 해 오고 있습니다.  UDG는 어떤 업스트림 서비스라도, 그것이 보안된 것이든 오픈된 것이든 상관없이, 단순한 GUI를 통해 함께 꿰맬 수 있게 합니다. 이것은 여러분들의 모든 REST 자산을 하나의 데이터 그래프로 여러분이 전환 시킬 수 있다는 것을 의미합니다. 이 강력한 새 해법은 심지어 단순한 GUI 조작으로 완성됩니다. 

이제 여러분은 깊은 단계로 중첩된 GraphQL과 REST API들을 어떤 가능한 방법으로든 함께 꿰맬 수 있습니다.  웹소켓과 서브스크립션을 가능하게 해 주는 쿼리들은 Tyk의 다음 릴리스에서 제공될 것입니다.

업스트림 헤더를 동적으로 설정하는 것도 가능한데, 클라이언트 요청으로부터 UDG업스트림에 주입하면 됩니다. 이 기능은 다른 것들 사이에서 보호된 업스트림에 접근하는데 사용할 수 있습니다.

끝으로, 우리는 사용하기 쉬운 URL 빌더도 추가하였습니다. 이것은 여러분이 UDG 내에서 REST API들을 꿰맬 때, 오브젝트 필드들을 REST API URL들로 주입하는 것을 한결 쉽게 만들어 줍니다. 각 필드 레벨에 대한 쿼리의 깊이를 제한하는 것도 할 수 있습니다.

여러분이 UDG로 GraphQL 업스트림 서비스를 사용하고 있다면, 이제는 UDG를 통하여 업스트림 에러 오브젝트들을 전달하는 것이 가능하게 됨으로써 그것들을 클라이언트에 노출시킬 수 있습니다.


##**당장 개이득!!**

Tyk 3.2 버전의 강력한 파워를 장착할 준비가 되셨나요?
여기, 우리의 웹사이트로 가셔서 [프리 트라이얼 버전을 다운로드](https://tyk.io/get-started/) 받으세요.


**[## 관련 웨비나 등록 (6/17)](https://www.brighttalk.com/webcast/18833/490122?utm_source=Tyk&utm_medium=brighttalk&utm_campaign=490122)**



Tyk 3.2가 공개 되었습니다!

large_Banner_benchmark.png

medium_Banner_benchmark.png

small_Banner_benchmark.png

thumbnail_Banner_benchmark.png

Banner_benchmark.png

# Why Tyk?

## Tyk API Gateway의 AWS 성능 테스트 (benchmark)

최근에 우리는 새로운 사용자로부터 초당 일천 만 개의 API 요청을 처리할 수 있는 게이트웨이를 찾는 중이라고 들었습니다. 그것도 저가로 말이죠. 그 분들은 모든 것을 AWS를 이용하여 cloud-first 온라인 쇼핑몰을 운영 중이라고 하였습니다.  “이 분들은 Tyk의 성능이 AWS 상에서 어느 정도이기를 기대할까?” 하는 궁극적인 질문을 하게  되는 대목입니다.

이 질문에 대한 정답은, 사실대로 말하자면, 아무도 듣고 싶지 않은, ‘경우에 따라 다르다’ 입니다. 그것은 여러분의 설정에 달려 있고, 환경에 따라 다르며, 어떤 타입의 CPU/Memory/Storage 자원을 제공하는 지에 따라, 어떤 기능을 사용하고 싶은 지에 따라, payload가 어느 정도인 지에 따라, 사용하는 애플리케이션의 속성에 따라, … 이 리스트는 한없이 길어집니다. Tyk는 처음부터 클라우드 네이티브 아키텍처로서 설계되었기 때문에, 수직확장 (scale-up)과 수평확장 (scale-out)에 아무런 제약이 없습니다.

하지만, 고객들이 기대하는 성능 수준에 대해 계속되는 질문은, 우리가 지난 번에 성능 벤치마킹 결과를 게시한지 거의 1년이 되었다는 사실을 알아차리게 하였습니다. 그 당시에 동료, Ahmet Soormally는 부가기능 없는 2코어 서버와 4GB의 램으로 구성된 환경에서 Tyk의 성능이  극도로 낮은 수준의 지체 (latency)와 함께 6400 RPS를 이른다는 것을 보여준 바 있습니다.

그 벤치마킹의 의도는 Tyk를 경쟁제품과 비교하려는 것이 아니었습니다. 그것은 절대로, 테스트 환경을 블랙박스 안에 감추거나, 이상한 환경적 설정을 적용하여 성능에 대한 거짓 주장을 하려던 것이 아니었습니다. 그것은 “그래, 그렇지만…” 하고 나서는 Tyk를 싫어하는 어떤 사람들의 주장에 기름을 부을 목적도 아니었습니다. 

그 당시에는, 오히려, 우리가 벤치마킹으로 무엇을 하고 있는지에 대하여 몇 가지 사항에 주의를 기울인 다음, Tyk가 아주 유연한 게이트웨이라는 사실을 알리기 위한 목적이었습니다. 타이크가 어떤 성능 필요와 어떤 규모의 예산에도 맞춤 재단 될 수 있다는 것을 알리자는 의도였죠.
여러분의 유스케이스에 따라, 타이크를 사용하여 요구사항에 맞게 API를 매니지먼트 할 방법은 아주 많습니다.

작년의 Ahmet의 벤치마킹 개요는 크기 조정, 구성, 종속성, 그리고 설치 및 몇 가지의 기법에 대하여 다루었습니다. 따라서, 단순히 “예, 우리 제품은 빠르고, 저가입니다” 라고 말하기 보다는 실제로 그가 어떻게 자신의 테스트를 수행하였고 그 당시 자신의 사고 과정을 보여주고 싶었던 것입니다.

1년의 빠르게 지났고 우리는 비슷한 방법의 테스트를 원했습니다. 타이크로부터 기대할 수 있는 성능 유형에 대한 같은 질문에 답하고 싶었지만, 이번에는 AWS를 기본 인프라로 사용하는 데 중점을 두었습니다.우리의 접근방식에 투명성을 제공함으로써 오픈 소스의 정신에 충실하기 위하여 AWS에서 성능 테스트를 안내하는 [단계별 가이드](https://tyk.io/a-manual-for-simple-performance-testing-with-tyk-on-aws/)를 제공합니다.

아래의 요약표를 보시고 자세한 사항은 위의 링크를 참조하세요.

맨 앞단에서의 벤치마크 결과 - 5분 동안 초당 75,000 요청 처리 (75,000 RPS)
![Picture1.png](https://storage.googleapis.com/argo-cms-strapi-upload/Picture1_007d9e5594/Picture1_007d9e5594.png)


투명 프록시로서의 벤치마크 결과 - 5분 동안 초당 75,000 요청 처리 (75,000 RPS)
![Picture2.png](https://storage.googleapis.com/argo-cms-strapi-upload/Picture2_24809a2221/Picture2_24809a2221.png)


Full-load APIM (트래픽 조정, API 인가/인증, 대시보드 분석정보 포함)
5분 동안 초당 75,000 요청 처리 (75,000 RPS)
![Picture3.png](https://storage.googleapis.com/argo-cms-strapi-upload/Picture3_d9e73a07c8/Picture3_d9e73a07c8.png)


게이트웨이 없이 투명 프록시로서 여러 가지 기능들을 활성화하고 테스트 한 뒤 Tyk 게이트웨이를 추가할 때, 초당 69,000 개 이상의 요청을 리버스 프록시하는 동안 0.77ms만 늘어나는 것으로 나타났습니다. 다음은 모든 API 요청에 대해 달성된 기록입니다.
인증 토큰에 대한 유효성 검증 수행
인증 토큰 별 요청에 대한 리소스 접근권한 검증 수행
속도 제한 추가 수행 (해당 키가 초당 100,000 요청 이상 쿼리 하지 못하게 설정)
추가 분석 및 향후 추적을 위하여 모든  요청/응답 트립에 대하여 분석정보 수집 

앞으로 더, 우리는 타이크의 성능에 대한 벤치마킹 테스트를 진행할 것입니다. 그 테스트들에서 우리는 타이크를 어디까지 확장할 수 있는지를 보기 위해 더 높은 초당 요청수 (RPS)를 추구할 것입니다.우리는 주요 병목점이 타이크 노드 (게이트웨이 nodes)와 Redis 클러스터의 CPU 사용량이라고 믿고 있습니다. 우리가 그 문제를 해결하기 위해 하드웨어를 추가할 수 있는 한,  타이크는 플랫폼이 요구하는 가능한 만큼의 충분한 처리를 해 낼 수 있습니다.

앞에서 언급한 것처럼, 예산은 천차만별이고 large EC2 인스턴스는 누구에게나 허용된 자원이 아닐 것입니다. 그래서 우리는 항상 하드웨어를  추가하는 것이 해결책 일 수 없다는 것을 잘 압니다. 하지만, Ahmet이 작년에 보여주었고, 우리가 여기에서 확인한 것처럼, Tyk는 스스로, 다양한 예산 범위 내에서 유연하면서 고성능의 게이트웨이라는 것을 증명하고 있습니다. 한 예로, 다른 인스턴스 사이즈로 테스트 한 결과, 우리는 smaller EC2 인스턴스가 오히려 ‘비용의 측면 (RPS / latency per dollar)’에서 더 높은 RPS와 latency를 보여준다는 것을 알았습니다. 이처럼 가성비를 올리면서 효율을 증대시킬 수 있습니다.  

향후에는 Tyk Pro 버전으로 다른 설정으로 어떤 결과를 보이는지 블로그에 포스팅 할 예정입니다. 우리는 K8s와 같은 다른 배포환경도 테스트 요소로 추가할 것입니다. 컨테이너와 마이크로서비스가 점점 확산되면서, 우리는 타이크가 K8s에서 어떻게 구동되는지, 세계 곳곳으로 연결된 엔터프라이즈의 인프라가 어떻게 확장되고 관리될 수 있는지 보여 드리고 싶습니다. 또한, 타이크가 어떻게 벤더에 종속적으로 되는 것을 방지하는지 보여 드리고, 이종 클라우드에서 여러 개의 클러스터를 수용하는 기능을 각각의 플랫폼에서 타이크 게이트웨이 서비스를 통하여 보여 드릴 것입니다. 

여러분이 이런 벤치마킹에 관심이 있다면, [저희에게 메모](http://argopacific.io)를 남겨 주십시오.

![Picture2.png](https://storage.googleapis.com/argo-cms-strapi-upload/Picture2_24809a2221/Picture2_24809a2221.png)
![Picture3.png](https://storage.googleapis.com/argo-cms-strapi-upload/Picture3_d9e73a07c8/Picture3_d9e73a07c8.png)
![Picture1.png](https://storage.googleapis.com/argo-cms-strapi-upload/Picture1_007d9e5594/Picture1_007d9e5594.png)


왜 Tyk (타이크) 인가

APIs를 설계할 때 개발자들은 누가, 어떤 API를, 언제, 어떤 목적으로 사용하고 있는지를 보여 주게 될 컴포넌트들의 보안 설계에 대하여 반드시 좋은 의사결정을 하여야만 합니다. 이 글에서 APIs의 안전을 위해 까다로운 역할을 담당하는 컴포넌트들의 내부에 대한 인사이트를 얻기 바랍니다.

보안은 퍼블릭 클라우드에 배포되는 모든 애플리케이션에 대한 비즈니스 요구사항이기 때문에, API 아키텍트들은 클라이언트 애플리케이션에서 다른 사람들이 퍼블릭 APIs를 사용하게 하려면 반드시 보안이 최고 우선순위가 되게 해야 합니다. 현재, 대부분의 퍼블릭 APIs는 JSON 또는 XML로 된 REST 기반의 것들입니다. REST, JSON, XML은 유연성과 개방적 태생으로 말미암아 서비스 엔드포인트와 데이터를 위협으로부터 보호하기 위한 핵심적인 보안 설계 고려사항이 되었습니다.

APIs를 설계할 때 개발자들은 authentication, authorization, monitoring/tracking과 같은 어떤 사용자가 어떤 APIs를 언제, 왜 사용하는지 등을 보여 주는 컴포넌트들의 보안 설계에 대한 좋은 의사결정이 필수적입니다. 

REST APIs는 HTTP/HTTPS 프로토콜을 통하여 접근되고 데이터 포맷팅에는 JSON과 XML이 사용됩니다. REST는 GET (read or list), POST (create), PUT (update)와 DELETE (delete)의 기본적인 actions를 수행합니다. 

설계에 있어서 API 엔드포인트를 안전하게 하는 첫 번째 단계는 노출된 어떤 actions를 보안할 필요가 있는지를 결정하는 일입니다. 보안 설계는 아키텍트들이 authentication, authorization과 session state를 보호할 방법을 고려할 것을 요구합니다. 어떤 API 설계에 보안을 추가하면 IT 또는 DevOps에 맞추어 개발 자원을 소유하고 그 API를 제어하는 것이 가능해집니다. 또, 그것은 IT와 DevOps 자원을 조직이 공개한 개별 퍼블릭 API를 추적하는 것 보다 좀 더 상위 레벨의 보안 우려사항들에 집중할 수 있게 해 줍니다. 


**인증과 API 키 (Authentication and API Keys)**



개발자나 아키텍트가 REST API를 설계할 때 그것이 오직 인증되고 (authenticated) 허용된 (authorized) 사용자들만 action을 수행할 수 있게 하는 것이 아주 중요합니다.

HMAC (Hash-based message authentication code)는 서버와 클라이언트에 각각 public 키와 private 키를 제공하므로, 이를 해결하는 방법이 될 수 있습니다. public 키는 알려진 것이고, private 키는 오직 해당 서버와 클라이언트에만 알려진 것입니다. 클라이언트는, 서버에 대한 매 요청 마다 그 요청 데이터를 정렬 (combing)하고 해싱하여 private 키와 함께 서버로 보내는 요청의 일부로서 unique HMAC 또는 hash를 생성합니다. 해당 서버는 보내진 요청을 접수하고 그 자신만의 unique HMAC를 재생성 합니다. 서버는 또 이 두 개의 HMACs를 비교하고, 두 개가 동일하면 클라이언트는 신뢰되어 그 요청이 실행됩니다. 이 과정은 secret handshake로 자주 불려집니다.

다른 선택 방안 하나는 해당 API 내에서 open authorization (OAuth)를 JSON Web token (JWT)와 함께 사용하는 것입니다. 전형적으로, OAuth는 네 가지의 역할들을 구체적으로 명시합니다: resource owner, client, resource server, authorization server 가 그것들입니다. 어떤 API를 사용하는 각 클라이언트는 인증 (authentication)을 위한 JWT 안에 내장된 unique API 키를 받습니다. 

위의 두 가지 방법 다 API 인증에 대한 보안을 제공하지만, 둘 다 설치가 복잡합니다. 개발자와 아키텍트 또는 DevOps의 선호도에 따라 어떤 조직의 선택 방안이 결정될 것입니다. 


**퍼블릭 APIs의 허가 (Authorization of public APIs)**


허가는 예닐곱 개의 모델을 통하여 가능하지만 HTTP를 보호하는 방법들과 whitelisting이 선호되며, 보안지능시스템 (security intelligence system)을 가지고 모니터링을 하는데도 사용될 수 있습니다. 

REST API를 가지고 HTTP를 보호하는 것은 REST action (GET, POST, PUT, and DELETE)에 대한 사용자의 권한을 설정합니다는 것을 의미합니다. 모든 사용자가 각 API에 대한 모든 action에 대한 접근이 필요한 것은 아니다. 허가를 기반으로 하여 사용자의 권한 수준을 설정하는 것은 예를 들면, 오직 DELETE가 허가된 사용자들만 실제로 데이터 레코드를 지울 수 있습니다는 것을 의미합니다. 최소한 대부분의 사용자들은 레코드나 정보의 목록에 대한 접근을 할 수 있어야 할 것입니다. 해당 API 클라이언트 약관이나 조직의 사용 약관에 근거하여 몇몇 사용자들은 데이터 레코드의 생성과 갱신에 대하여 허용 될 수도 있을 것입니다.

허가 (authorization)을 통한 HTTP 메소드 접근 권한 부여는 사용자에게만 적용 될 수 있는 것이 아니다; 이 방법은 자원 수집 (resource collections)에도 적용될 수 있습니다 권한이나 한 사용자의 역할을 기반으로 허가를 설정하는 것은 비교적 일상적인 것이지만 API의 엔드포인트 보안에 포함되는 효과적인 레이어 입니다.

메소드들을 Whitelisting 하는 것이 다른 대안입니다. 화이트리스팅은 URL을 기반으로 허가 (authorization)를 허용합니다. 메소드들은 GET, POST, PUT 그리고 DELETE로 똑 같지만, 그 메소드들의 사용은 URL이 화이트리스트 (각 URL 별로 할당된 허락된 actions의 세트를 가지고 있음)에 있는지에 따라서 제한됩니다. 만약 그 URL이 그 리스트에 없다면 403-Forbidden과 같은 에러 코드로 응답됩니다. 이 방법을 쓸 때는 서버와 시스템 정보가 표준 에러 메시지로부터 제거 된 것을 확실히 할 것을 권고합니다. 그래야 내부 시스템 정보가 표출되는 것을 막을 수 있습니다.

메소드 화이트리스팅을 사용하면 접근 로그를 통하여 모니터링 할 수 있고 데이터가 로그 내에서 또는 보안지능시스템에 의하여 추적될 수 있습니다는 유리한 장점이 있습니다. 


**세션 상태의 보호 (Protecting session states)**

대부분의 웹 서비스들과 APIs는 state blob가 해당 트랜잭션 내에서 보내지도록 하여 stateless로 설계됩니다. 더 안전한 설계를 위해서, 해당 API가 server-side cache를 사용하는 경우라면 API 키를 클라이언트의 state에서 유지하는 것을 고려해 보라. 이 방법은 웹 애플리케이션에서 흔히 사용되는 것이고, 이것은 anti-replay를 방지하는 추가적인 보안을 제공합니다. Anti-replay는 공격자가 허가된 사용자가 되려고 blob을 copy-paste하는 곳입니다. 효과적 이려면 API 키, 날짜, 시간, 그리고 들어오는 IP 주소에 대하여 작동하는 시간이 제한된 암호 키를 포함하도록 하세요. 

효과적인 보안의 핵심은 활동적인 모니터링과 결합된 계층화 (layering)를 하는 것입니다. 계층화는 하나가 기능을 제대로 수행하지 못할 경우에 하나 또는 그 이상의 백업 시스템을 제공합니다. 데이터와 접근은 다음 레이어에 의해서 여전히 보호됩니다. API에 대한 활동 모니터링은 조직이 그 API에 대한 제어를 확보하고 그것이 원래의 계약과 사용 약관을 일관되게 준수하는 것을 보증하며, 조직의 또는 API 사용자 시스템의 접근 포인트로 들어 오지 못하게 해 줍니다. 

API 아키텍트는 반드시 API 엔드포인트가 퍼블릭 API의 시작점부터 그 조직과 사용자들에게 최대가치를 제공하도록 설계하여야 하고, 개발팀 내에서 보안에 대한 소유권을 이양하여야 합니다. 비록 어떤 API가 비밀 데이터나 보호된 정보의 공통 양식에 연결 또는 전달하는 것이 아니라 하더라도, API 엔드포인트들은 해커들의 접근 지점들이며 네트워크와 데이터에 대한 비인가된 접근을 획득하기 위한 엔진으로 사용되어 왔다. 엔드포인트 보안은 비즈니스와 그에 관련된 고객들에게 안전한 보호구를 제공해 줍니다. 


Leading Tyk Partner in South Korea

Tyk Pricing

Tyk Launch

Tyk Flex

Tyk Multi-Team

Tyk Global Multi-Team

Latest Posts

API에 이벤트 달기

Tyk 3.2가 공개 되었습니다!

왜 Tyk (타이크) 인가

REST APIs 엔드포인트 보안 설계 팁