지금 당장 환경에서 모든 API 엔드포인트를 식별하려고 시도해도 불가능할 가능성이 매우 높습니다. 불행히도 악의적인 행위자에 대해서는 똑같은 말을 할 수 없을 수도 있습니다. 엔드포인트가 존재하면 이를 사용하여 중요한 비즈니스 기능을 방해하는 수단이나 경로로 사용될 수 있습니다.
또한 API를 공개적으로 공개하면 다양한 고객, 파트너, 앱으로부터 질의를 받을 수 있습니다. 이러한 노출로 인해 조직이 손상될 위험도 커지므로 API를 이해하고 모니터링하는 것이 중요합니다. 조직을 API의 취약점과 잠재적 위협으로부터 보호하기 위해 고려해야 할 여러 가지 위험 관리 방안이 있습니다. 이러한 취약점과 위협은 침해와 가동 중지로 이어질 수 있습니다.
모든 보안 담당자에게 API 검색은 API 보안을 위한 첫 번째이자 중요한 단계입니다. 말할 필요도 없겠지만, "보이지 않는 것은 보호할 수 없다"는 말보다 더 진실된 것은 없습니다. 완전한 API 인벤토리를 갖추면 API 보안 태세를 개발하거나 개선하기 위한 시작점이 되어 전체 API 위협 영역을 이해하고 정량화하는 데 도움이 됩니다. 이는 다음의 기준선으로 사용됩니다:
전형적인 투쟁이죠. 한편, 대담하게 행동하고 경계를 넓히며 경쟁자가 할 수 없는 일을 하려는 욕구는 모든 성공적인 사업의 초석입니다. 하지만 반면에 보안을 유지하는 것이 항상 최신 혁신과 잘 어울리는 것은 아닙니다.
균형을 맞추는 핵심은 세 가지입니다.
업계에 따라 규정 준수 기준이 다르며, 일부 업계는 다른 업계보다 더 엄격한 보안을 요구합니다. 그럼에도 불구하고, 귀하의 API 보안 태세가 수많은 위협 벡터에 맞서기에 충분히 강력해지는 것이 필수적입니다.
API 보안 테스트는 일회성 작업이 아닙니다. 배포 전, 배포 중, 배포 후의 테스트가 중요합니다. 개발의 모든 단계에 테스트를 구축하면 침해가 발생하기 전에 약점과 취약성을 파악할 수 있는 기회가 훨씬 더 많아집니다. 보안 관련 테스트 도구가 훌륭하기는 하지만, 보안 사용 사례 모델링도 잊지 마세요.
보안은 앱 자체의 동일한 연속적 수명 주기에서 실행되어야 하며, 이는 CI/CD 파이프라인, 서비스 프로비저닝 및 이벤트 모니터링 생태계 내에서 긴밀하게 통합되어야 함을 의미합니다.
외부 클라이언트부터 내부 백엔드 인프라까지 아키텍처의 모든 부분은 자체 보호 조치가 필요합니다.
게다가 여전히 검증된 보안 관행이 적용됩니다. 즉, 기본 거부 아키텍처, 강력한 암호화, 최소 권한 액세스 등이 적용됩니다.
API 계층의 보호에 대해 생각할 때 먼저 API를 내부 및 외부의 두 가지 범주로 분류하는 것이 좋습니다. 내부 API는 API 제공자가 앱 팀과 보안 조치를 조정할 수 있으므로 보안을 강화하기가 더 간단합니다. 외부 API의 경우 위험 계산 방식이 다릅니다. 다음 세 가지 작업을 수행하는 API 수준 보호 기능을 구현할 수 있습니다(그리고 구현해야 합니다).
프로덕션 수준에서 API 확산으로 인한 엄청난 양의 트래픽을 처리하기 위해서는 비정상적인 동작과 악의적인 사용자를 감지하기 위해 AI를 사용해야 합니다.
우리를 완벽하게 영양 공급해 줄 단 하나의 음식이 없는 것처럼, API를 완벽하게 보호해 줄 단일 보안 관리 수단은 없습니다. 대신, 전체적인 앱 및 API 보안 아키텍처의 일부로 다양한 도구의 포괄적인 생태계를 활용하는 전략을 개발해야 합니다. 여기에는 API 동작을 제어하고, 바람직하지 않거나 악의적인 활동을 제한하고, 민감한 데이터가 노출되는 것을 차단하는 기능을 제공하는 감지 및 인라인 시행이 포함됩니다.
여기에는 다음을 포함한 역량과 도구의 조합이 포함될 수 있습니다.
API 게이트웨이는 견고한 인벤토리 및 관리 기능을 제공하지만, 정교한 공격자를 막을 수 없는 속도 제한과 같은 기본적인 보안만 제공합니다. 또한 API의 확산으로 인해 도구의 확산, 특히 API 게이트웨이의 확산이 발생하고 있습니다.
앱 보안 테스트는 항상 중요하지만 개발 중에 강력한 애플리케이션 보안을 위한 쉬프트-레프트 방법론은 쉴드-라이트 관행, 즉 프로덕션에서 API 엔드포인트를 보호하는 방식으로 강화되어야 합니다.
웹 애플리케이션 방화벽은 시그니처를 사용하여 애플리케이션 취약성 악용을 완화하는 중요한 임시방편을 제공합니다. API는 지원하는 애플리케이션과 동일한 유형의 주입 공격, 즉 의도치 않은 명령을 실행하거나 데이터에 액세스하려는 공격을 받을 수 있습니다. 그러나 WAF는 일반적으로 알려지지 않은(섀도 또는 좀비) API와 API의 동작 이상, 비즈니스 로직의 잠재적 악용을 포함한 문제를 지속적으로 감지하는 데 필요한 동적 검색 기능이 부족합니다.
민감한 데이터 탐지 및 데이터 손실 방지 기능은 개인 식별 정보(PII) 및 금융 정보를 비롯한 민감한 중요 데이터를 탐지하고 마스킹하여 API와 API가 액세스하고 전송하는 데이터를 보호하는 데 도움이 됩니다. 이를 통해 조직에서는 데이터 보호 규칙을 만들어 데이터 전송을 제한하거나 가리고 API 엔드포인트가 데이터를 전혀 노출하지 못하도록 차단할 수 있습니다. 즉, API를 통한 데이터 유출을 방지하는 데 도움이 됩니다.
API에 대한 봇 관리에서는 다중 인증(MFA)이나 CAPTCHA와 같은 일반적으로 사용되는 보안 제어 기능에 의존할 수 없습니다. API 트래픽은 일반적으로 머신 대 머신이며 API 기반 시스템의 사용자 인터페이스를 제외하고는 직접적인 인간 상호 작용이 없기 때문입니다.
기존 DDoS 완화책은 네트워크 및 볼륨별 공격에 초점을 맞추는 반면, API는 중요한 비즈니스 로직을 악용하는 타겟팅된 7계층 공격을 받을 수 있습니다. 최종 결과는 동일합니다. 성능이 저하되고 잠재적으로 가동 중지 시간이 발생합니다.
동적 API 검색, 스키마 적용(긍정적 보안), 액세스 제어, 그리고 머신 러닝을 기반으로 한 자동화된 이상 탐지 및 보호가 API를 방어하는 데 중요한 생태계 역량으로 부상했습니다. API 프로토콜에 능통하고 적절한 API 동작과 API 보호 규칙 생성을 시행할 수 있는 도구 하나 이상을 갖는 것이 중요합니다. 조직에서는 API와 API 동작을 구체적으로 제어하는 사용자 지정 규칙을 만들 수 있어야 합니다. 여기에는 허용 및 거부 목록 제어, 속도 제한, 지리적 IP 필터링, API 요청에 따라 민감한 데이터를 마스킹하고 특정 API 엔드포인트나 그룹에 대한 일치 및 요청 제약 조건을 처리하는 사용자 정의 규칙 생성이 포함됩니다.
API의 확산으로 인해 하이브리드 및 멀티 클라우드 환경에서 구조적 확산이 견딜 수 없을 정도로 심화되고 있습니다. 다시 말해, API 확산은 API 게이트웨이 확산으로 이어졌습니다. 많은 보안 도구가 데이터 센터, 프라이빗/퍼블릭 클라우드, 엣지 등 여러 아키텍처에서 일관된 보안을 제공할 수 없기 때문입니다. 디지털 생태계 전반의 API 트래픽에 대한 가시성과 제어는 다음의 심각한 취약성을 완화하고 엔드포인트가 여러 클라우드 공급자에 분산되어 있을 때 발생할 수 있는 잘못된 구성을 방지하는 데 필수적입니다.
API는 데이터 센터, 클라우드, 에지 등 모든 곳에 존재하며 웹 앱, 모바일 앱 및 관련 타사 통합을 통해 상호 연결됩니다. API는 어디에 있든 보호되어야 하며 보안은 결코 저하되지 않아야 합니다. 대신, API 뒤에 있는 중요한 비즈니스 로직을 지속적으로 방어하고 API에 연결된 디지털 패브릭을 일관되게 보호하는 솔루션이 전략에 포함되어 있는지 확인하세요. 이렇게 하면 운영을 간소화하고 자신 있게 혁신할 수 있습니다.