제로 트러스트 환경의 API 보안
보안 경계에 대한 기존의 개념이 그 어느 때보다 급격히 변화하고 있습니다. 이에 대응해 많은 기업이 ZTA(제로 트러스트 아키텍처) 원칙을 도입하고 사용자 신뢰를 평가하며 주요 사용자 인터페이스를 통한 중요한 네트워크, 시스템 및 데이터 접속을 관리하는 데 주력하고 있습니다.
그러나 다수의 ZTA 이니셔티브는 신뢰를 지속적으로 평가하는 방법을 설계하면서 중요한 애플리케이션 기능 및 데이터에 대한 API(애플리케이션 프로그래밍 인터페이스) 기반의 접속이 더욱 빈번하게 발생하고 있다는 점을 간과합니다.
이 블로그 게시물에서는 API와 ZTA 간의 몇 가지 교차점을 중점적으로 살펴봅니다. 또한 API를 포함하도록 ZTA를 확장하기 위해 취할 수 있는 몇 가지 초기 단계도 간략하게 설명합니다.
제로 트러스트란 무엇일까요?
2010년 Forrester Research는 주요 기업 보안 고객에게 ZTA의 원칙을 소개했습니다. 그 이후로 Forrester는 물론 NIST 특별 간행물 800-207의 NIST(National Institute of Standards and Technology)를 비롯한 수많은 업계 관계자들이 ZTA 설계를 크게 개선했습니다.
간단히 말해, 제로 트러스트는 기본적으로 신뢰할 수 있는 사용자나 디바이스는 없다고 가정합니다. 대신 사용자나 디바이스가 중요한 리소스에 접속을 시도할 때마다 이를 평가하고, 이후에도 지속적으로 평가해야 합니다.
ZTA는 수년 동안 기업이 현실 세계에서 추구하는 주제라기보다는 토론 주제에 더 가까웠습니다. 그러나 코로나19 팬데믹으로 인해 전 세계의 근로자들이 재택근무를 하게 되면서 많은 기업이 ZTA 원칙을 도입하기 위해 실질적인 계획을 추진하게 되었습니다.
API와 제로 트러스트의 교차점은 무엇일까요?
NIST SP 200-807은 ZTA의 일곱 가지 기본 원칙을 설명합니다. 이러한 원칙은 애플리케이션 기능 및 데이터에 대한 API 기반 접속 외에도 매우 많은 것을 포함하며, 기업의 API 전략과 매우 분명하게 교차하는 부분도 있습니다.
제로 트러스트의 7가지 기본 원칙
다음 표는 NIST SP 200-807에 정의된 ZTA의 7가지 기본 원칙과 기업의 API 보안 사례를 이러한 원칙에 맞추기 위한 권장 사항을 보여줍니다.
제로 트러스트 아키텍처의 7가지 기본 원칙 |
API 보안의 영향 |
|---|---|
1. “모든 데이터 소스와 컴퓨팅 서비스는 리소스로 간주됩니다.” |
ZTA 범위에 속한 수많은 애플리케이션과 데이터 소스는 직접적인 사용자 인터페이스 외에도 API를 통해 접속할 수 있습니다. 따라서 ZTA 평가 및 정책 적용 모델에는 API 인터페이스를 포함해야 합니다. |
2. "모든 통신은 네트워크 위치에 관계없이 보호됩니다." |
API가 프라이빗 데이터 센터 또는 클라우드 환경 내에서 내부용으로만 사용되더라도ㅡ 데이터 기밀성과 무결성을 보장하기 위해 외부에서 사용하는 것처럼 암호화, 인증, 권한을 구축해야 합니다. |
3. "개별 기업 리소스에 대한 접속 권한이 세션별로 부여됩니다." |
API 리소스에 대한 접속 권한을 부여하려면 먼저 신뢰도를 평가해야 합니다. 접속 권한은 가능한 최소한의 권한으로 부여되어야 합니다. 행동 애널리틱스를 활용해 API 사용량을 모니터링하고 지속적으로 신뢰도를 평가합니다. |
4. "리소스에 대한 접속은 클라이언트 ID, 애플리케이션 또는 서비스 및 요청 자산의 관측 가능한 상태를 포함한 동적 정책에 의해 결정되며, 다른 행동 및 환경 특성을 포함할 수 있습니다." |
API에 ZTA를 적용하려면 관련 주체를 식별하고, 비즈니스 맥락을 추론하고, 행동 애널리틱스를 활용해 정상적인 사용 패턴과의 차이를 식별할 수 있어야 합니다. 주목할 만한 행동 특성은 신속한 API 호출을 통한 서비스 거부입니다. 이 때문에 API 전송률 제한의 부족은 OWASP(Open Web Application Security Project) API 보안 상위 10대 목록에서 민감한 비즈니스 플로우에 대한 무제한 접속으로 분류됩니다. NIST에 따르면 "이러한 룰과 특성은 비즈니스 프로세스의 요구사항과 허용 가능한 리스크 수준을 기반으로 합니다." |
5. "기업은 모든 소유 및 관련 자산의 무결성과 보안 체계를 모니터링하고 측정합니다." |
이 요구사항은 미국 CISA(Cybersecurity and Infrastructure Security Agency)에서 정의한 CDM(Continuous Diagnostics and Mitigation) 개념을 기반으로 합니다. CDM에는 자산 관리, 취약점 관리, 구성 및 설정 관리와 같은 요소가 포함됩니다. 물리적 자산과 마찬가지로, API를 지속적으로 검색, 분류 및 추적해야 합니다. 마찬가지로 기존 네트워크 및 애플리케이션 보안 취약점 이상으로 지속적인 취약점 평가를 확장하여 가능한 API 기반의 취약점을 포함해야 합니다. |
6. “모든 리소스 인증 및 권한은 동적이며 접속이 허용되기 전에 엄격하게 적용됩니다.” |
이 개념은 API로 확장될 수 있으며 또한 확장되어야 합니다. ZTA를 도입하는 기업은 API 사용에 대한 지속적인 모니터링을 수행하고 자동화된 기술(예: 인증정보 차단, 제한, 해지)을 활용해 인증되고 승인된 API 트래픽 내에서 탐지되는 비정상적이거나 악의적인 행동에 대응해야 합니다. |
7. "기업은 자산, 네트워크 인프라 및 통신의 현재 상태에 대한 정보를 가능한 많이 수집하고 이를 활용해 보안 체계를 개선합니다." |
API 보안 수단이 ZTA의 효과적인 구성요소가 되려면 장기간 데이터를 캡처할 수 있어야 합니다. 이상적으로는 미묘한 API 악용을 탐지할 수 있을 만큼 충분한 기간 동안 캡처하는 것이 좋습니다. 이러한 수준의 세부 정보는 실시간 리스크 평가와 ZTA 설계의 지속적인 개선을 위한 행동 애널리틱스를 수행하는 데 필요합니다. 여기에는 가능한 정책 개선 사항을 식별하는 데 사용할 수 있도록 위협 연구원에게 API 및 위협 데이터에 대한 온디맨드 접속을 제공하는 것이 포함됩니다. 또한 팀에서 사용하는 개발 및 운영 툴과 워크플로우를 활용해 유사한 통합 지점을 만들어야 합니다. |
API를 포함하도록 ZTA를 확장하기 위한 7가지 초기 단계 실행
ZTA를 도입하려는 대부분의 기업에서 가장 큰 도전 과제 중 하나는 바로 시작 지점입니다. API 보안의 경우, 다음과 같은 기능을 구축하면 보안 체계에 즉각적인 영향을 미칠 수 있을 뿐만 아니라 API 보안을 향후 ZTA 계획에 통합하는 데 필요한 토대를 마련할 수 있습니다.
지속적인 API 검색을 구축하고 모든 API 및 API 접속 가능 자산의 정확한 인벤토리 유지
허가되지 않은 API가 발견되면 이러한 API를 관리하거나 제거하기 위한 체계적인 워크플로우 마련
API가 퍼블릭인지 프라이빗인지와 관계없이 믿을 만한 API 인증 및 권한 구축
OWASP API 보안 상위 10대 목록을 시작으로, API 취약점을 지속적인 통제 분야로 선제적으로 식별
대규모 API 트래픽 데이터 세트를 분석하여 정상적인 행동에 대한 기준을 결정하고 비정상을 탐지하는 기능 개발
API 통합을 통해 구축되는 ZTA 정책 엔진에 위협 및 신뢰 인사이트 제공
API 취약점, 위협 및 악용 사례가 나타날 때 자동화된 대응 개시
첫 번째 단계
API 보안을 ZTA에 통합하세요. Akamai API Security로 가능한 작업을 확인하세요.
