API가 해커의 꿈의 타겟인 이유는?
글로벌 디지털 경제에서는 애플리케이션 기반 서비스를 고객, 소비자, 파트너, 직원에게 연결하기 위한 애플리케이션 프로그래밍 인터페이스(API)가 필요합니다. 기존, 현대화된, 새로운 애플리케이션은 애플리케이션 개발을 가속화하고 출시 시간을 단축하기 위해 API 기반 아키텍처로 발전하고 있습니다. 마찰을 줄이기 위해 애플리케이션 기능을 고객에게 더 가깝게 옮기는 것이 분산형 아키텍처와 API 우선 운동의 시작입니다.
안타깝게도 애플리케이션 개발에서 API를 통해 얻은 효율성은 IT 기업에 초래되는 위험 때문에 그 빛이 바래고 있습니다. 해커들은 API가 가볍게 보호되거나 보호되지 않을 경우 API를 손상시키기 쉽다는 것을 알게 되었습니다. API에 보안 관행이 필요하다는 데는 이의를 제기할 사람이 없습니다. 그러나 API를 보호하는 가장 좋은 방법에 대한 업계의 합의는 없습니다. API에 일반적인 것보다 더 많은 보호가 필요한 몇 가지 주요 이유는 다음과 같습니다.
API 취약점은 대부분 해결되지 않음
API 가시성 및 보안이 부족하여 심각한 보안 침해가 점점 더 많이 발생하고 있으며 앞으로도 계속될 것입니다.1 조직의 디지털화 경쟁으로 인해 제대로 보호되지 않은 API가 더 많이 프로덕션에 투입될 것입니다. 많은 조직에서는 더 나은 설계와 코딩을 통해 API 취약점을 해결하려고 시도하지만, 일반적인 애플리케이션과 동일한 보안 결함을 깨닫게 됩니다. 그 이유는 보안이 일반적인 애플리케이션 개발자의 핵심 역량이 아니고, 보안팀에서 환경 내의 모든 타사 상호 연결을 인식하지 못할 수 있기 때문입니다.
API 확산은 충격적으로 만연하다
API 확산의 핵심은 거버넌스와 모범 사례를 포함한 전체적인 전략이 부족하다는 것입니다. 애자일 애플리케이션 개발로 인해 API 버전 제어의 이점 없이 동일한 API의 여러 버전이 생겨났습니다. 마이크로서비스로 전환하면 수십 개의 API로 구성된 애플리케이션이 생성됩니다.
관리되지 않는 API는 불량, 섀도, 좀비 API를 생성합니다. API는 2030년까지 20억 개에 도달할 것으로 예상되며, 이는 문제를 더욱 악화시킬 것입니다.2
API 게이트웨이는 복잡한 생태계에서 API를 보호하기에 불충분합니다.
오늘날에는 분산 클라우드 환경에서 운영하는 것이 일반적입니다. 그러나 전용 API 게이트웨이를 보안을 제어하는 단일 진입점으로 사용하면 단일 장애 지점 및 성능 저하를 포함한 한계가 있습니다. 오늘날 API 게이트웨이는 API 인프라의 중요한 구성 요소이므로 API의 확산으로 인해 API 게이트웨이 배포도 늘어나고, 이는 API 게이트웨이의 확산으로 이어진다는 것이 분명해졌습니다.
웹 애플리케이션 방화벽(WAF)은 API를 부분적으로만 보호합니다.
최신 WAF는 GraphQL 및 gRPC를 비롯한 API 프로토콜에 대한 강력한 보호 및 보안을 제공하고 중요한 소프트웨어 취약점에 대한 대책을 제공하지만, 하이브리드 및 멀티 클라우드 아키텍처에서 고급 위협을 감지하는 데 필요한 API 관찰 기능을 제공하지 못하는 경우가 많습니다. 많은 WAF에는 동적 API 검색, 자동 감지 및 위협 완화, 테스트, OpenAPI 문서 사양 자동화 및 시행 기능이 부족합니다.
이제 해커가 API를 좋아하는 이유를 알았으니, 이를 어떻게 보호할 수 있을까요?
API 보호 프로젝트에 대한 지원을 얻기 위해 규정 및 표준 활용
규제 기관은 API로 인해 발생하는 위험을 인식하고, 기업이 타사를 포함한 IT 기업 전반에서 위험을 완화하도록 권장했습니다. 미국 재무부와 소비자 금융 보호국(CFPB)은 API를 보호해야 하는 규정을 준수하는 기관에 강력한 지침을 발표했습니다. 표준 관점에서 PCI DSS v4 요구 사항 6.3.2는 API 보안을 요구하고, 2007년 이후 NIST 800-95 보안 웹 서비스 가이드 권장 사항, 800-24 마이크로서비스 기반 애플리케이션 시스템을 위한 보안 전략은 안전한 API 관리를 지정합니다.
아키텍처에 집중
API 보안 아키텍처는 멀티 클라우드, 지역 엣지, 서비스 계층을 포함한 분산 IT 기업과의 통합을 고려해야 합니다. 솔루션은 모든 하드웨어, 가상화된 환경, Docker, Kubernetes 등에 배포할 수 있어야 합니다. 솔루션은 보안 정책이 해당 생태계 전반의 API를 따를 수 있도록 허용해야 합니다. 다음은 API 보안을 위한 참조 아키텍처의 예입니다.
마지막 생각
해커들은 API가 취약한 인증 및 권한 부여 제어를 포함하여 웹 애플리케이션과 동일한 보안 문제를 겪고 있다는 사실을 오래 전부터 알고 있었습니다. 그들은 API 취약점을 악용하고, 비즈니스 로직을 남용하고, 제로데이 익스플로잇을 만들어 거의 저항 없이 IT 기업에 접근하는 데 능숙해졌습니다.
개인 데이터는 해당 개인의 재산이며, 애플리케이션이나 서비스 제공자의 재산이 아닙니다. 디지털 경제는 오픈 데이터 공유를 촉진합니다. API는 개인, 공공, 파트너 및 타사의 데이터와 서비스를 활성화합니다. API에는 데이터 개인 정보 보호 규정을 준수하기 위해 개인 정보 보호 기술이 적용되어야 합니다.
API 보안 솔루션을 배포하려면 인프라 통합과 커넥터가 필요하며, 일부는 IT 환경에 적절하게 배포하기 위해 맞춤화되어야 합니다. 배포의 복잡성을 이해하려면 아키텍처 계획이 필요합니다. 기존 IT 엔터프라이즈 아키텍처 내에서 바로 작동하는 솔루션을 선택하면 배포 시간이 단축됩니다.
API 공격에 대한 방어에 대해 자세히 알아보려면 F5에서 의뢰한 최근 보고서인 API 보안 솔루션 평가 가이드를 확인하세요. 이 보고서에서는 API 보호 솔루션을 선택할 때 고려해야 할 가장 중요한 사항에 대해 설명합니다.
Tari Schreider, C|CISO, CRISC – Datos Insights 전략 고문