API Security Pattern

소개

API는 외부 및 내부에 중요한 비즈니스 정보를 공유하는 인터페이스입니다. 이런 정보에 대한 접근을 보호하는 것은 엔터프라이즈 소프트웨어 설계에서 매우 중요합니다.

API Security Pattern

소비자 및 비즈니스는 디지털 환경에 익숙해지고 있습니다. 도메인에 관계 없이 오늘날 모든 기업은 디지털 전환을 시도하는 것이 필수적입니다. API는 디지털 환경에서 경쟁할 수 있는 기능을 제공합니다.

스리랑카의 일부 시골 마을에서 만든 제품을 ebay 또는 alibaba와 같은 온라인 전자 상거래를 통해 뉴욕에 거주하는 개인에게 판매 할 수 있습니다. 소매점이나 도매점에 가지 않고도 휴대폰이나 태블릿을 사용하여 물건을 주문할 수 있습니다. 과거에는 이런 전자 상거래 사이트 없이도 사업을 잘해왔지만, 이제는 세상이 변했습니다.

이제 기업은 다양한 채널을 통해 내부 및 외부 소비자에게 비즈니스 서비스를 제공해야 합니다. 소비자는 여러 매체를 사용하여 비즈니스 정보에 접근합니다. 잘 정의되고, 문서화되고 탐색 가능한 API 세트를 보유하면 서로 다른 사용자가 다른 매체에서도 비즈니스 정보를 사용할 수 있습니다.

다양한 매체

API 보호

사용자가 비즈니스 정보에 접근하도록 허용하면 비즈니스 생태계 측면에서 다른 업체와 경쟁하는데 도움이 됩니다. 그러나 보안 및 제어없이 중요한 비즈니스 정보를 노출 할 수는 없습니다. API를 제어하지 않으면 비즈니스를 위험가 처해질 수 있습니다.

API 보안은 10년동안 진화해왔습니다. API 보안에는 크게 두 가지 주요 요소가 존재합니다.

인증은 모든 시스템에 대한 접근을 제어하기 위한 기본 요구 사항입니다. 이 방법은 IT역사적으로 가장 오랫동안 존재했습니다. 과거에는 사용자 아이디와 패스워드를 보관하고 이를 사용하여 접근하려는 시스템을 인증했었습니다. 그러나 매일 엑세스하는 다양한 비즈니스 시스템 및 웹 애플리케이션이 성장함에 따라 모든 사용자 아이디와 패스워드를 유지하는 것이 매우 어려운 작업이 되었습니다. 대부분의 사람들은 은행 계좌, 소셜 로그인, 컴퓨터 로그인 및 비즈니스 애플리케이션에 동일한 자격 증명을 사용합니다. 따라서 악의적 목적을 지닌 해커가 해당 정보에 엑세스하는 경우, 하나의 시스템에서 이 정보를 제공하는 것은 매우 위험 할 수 있습니다.

이런 상황들로 인해 사용자가 신뢰할 수 있는 하나의 시스템에 단일 사용자 아이디 및 패스워드를 저장하면서 다른 애플리케이션에서 사용할 수 있도록 자격 증명을 손상시키지 않고 기존 ID를 재사용 할 수 있는 매커니즘을 원하게 되었습니다. 비즈니스 또는 엔터프라이즈 시나리오에서 자격 증명이 LDAP 또는 AD에 안전하게 저장되는 방식을 가질 수 있습니다.

API 보안 매커니즘

OAuth2

OAuth2는 엑세스를 위임하는 매커니즘을 통해 API 보안의 실질적인 표준이 되었습니다.OAuth2를 사용하면 자격 증명을 제공하지 않고도 애플리케이션이 사용자를 대신하여 특정 리소스에 접근할 수 있는 권한을 부여할 수 있습니다. 이 모델을 사용하면 보안 ID 공급자에 대해서 인증을 하게 됩니다. 애플리케이션(웹,모바일)은 사용자를 대신하여 엑세스 토큰을 받고 해당 토큰을 이용하여 허용된 정보에 접근할 수 있습니다.

OIDC

간혹 애플리케이션은 사용자 정보를 식별하기를 원합니다. 그러나 OAuth2에는 이를 수행하는 표준 매커니즘이 없습니다. 이런 제한으로 인해 사용자가 특정 리소스에 접근할 수 있는 권한을 부여하면(사용자 동의하에) 애플리케이션이 기본 사용자 정보를 요청할 수 있는 OIDC(Open ID Connect)를 고안했습니다.

Basic Authentication

위에서 언급한 최신 보안 매커니즘외에도 API 보안을 위해 사용자 아이디 및 패스워드를 기반으로 인증(기본 인증)하는 방식을 계속 사용하는 기업도 존재합니다.

기존 보안 매커니즘과 토큰 교환

엔터프라이즈 솔루션 아키텍트는 기존 애플리케이션 및 사용자 경험을 수정하지 않고 API 관리와 같은 새로운 개념을 도입해야 합니다. 애플리케이션을 제어할 수 없는 경우 OAuth2와 같은 새로운 보안 매커니즘을 도입할 수가 없게됩니다. 이런 경우에는 SAML2, Kerberos, NTLM과 같은 기존 보안 매커니즘과 상호 운용할 수 있도록 API 관리 계층을 구축하고 애플리케이션 기반의 토큰 교환 매커니즘을 구축 해야 합니다. 엔터프라이즈 수준에서 토큰 프록시를 사용하거나 토큰 교환을 위해 클라이언트측 애플리케이션의 일부 코드만 수정하기에 사용자는 보안 구현의 차이를 느끼지 못할 수 있습니다.

API Gateway와 Identity Provider

API Gateway는 클라이언트의 모든 요청을 수신하는 런타임 구성 요소입니다. 비즈니스 정보를 제공하는 하단의 엔드 포인트를 호출하기 전에 사용자 요청을 검증하는 것이 게이트웨이의 의무입니다. API Gateway는 사용자 자격 증명과 IDP라는 접근 제어 수준을 확인합니다. 즉, 아래와 같은 모든 보안 관련 작업을 처리합니다.

간혹 기존 백엔드 애플리케이션에 대한 인증 및 권한을 관리하는데 동일한 IDP가 사용되는 경우도 있습니다. 사용자가 애플리케이션을 통해 API에 접근하려는 경우 IDP로 리다리엑션되고 여기서 사용자 자격 증명이 제공됩니다. 기업에 이미 IDP가 있는 경우에는 이를 사용하여 토큰 유효성 검사 및 토큰 생성 기능을 제공하는 것이 좋습니다.

백엔드 엔드 포인트에 연결

때로는 API Gateway의 인증 및 권한 부여가 충분하지 않기에 백엔드 서비스는 데이터 접근의 유효성을 검사하기 위해 사용자에 대한 일부 정보를 원합니다. 이런 경우에는 API Gateway는 클라이언트에서 오는 기본 인증 정보 또는 Access Token에서 생성된 JWT를 전달해야 합니다.