REST API - Endpoint 보안 설계 Tips

Jun Hwang

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

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

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

REST API는 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의 선호도에 따라 어떤 조직의 선택 방안이 결정될 것입니다.

Public API의 허가 (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 엔드포인트들은 해커들의 접근 지점들이며 네트워크와 데이터에 대한 비인가된 접근을 획득하기 위한 엔진으로 사용되어 왔다. 엔드포인트 보안은 비즈니스와 그에 관련된 고객들에게 안전한 보호구를 제공해 줍니다.