이제 API 보안이 얼마나 중요한지 이해하셨으니…
(API 보안이 현재 업계에서 화두로 떠오르고 있는 상황을 빠르게 알아보려면 최근 블로그 게시물을 참조하세요. 아래 지침은 이 문제를 다루고 이에 대해 무엇을 할 수 있는지 설명합니다.)
보안 게이트웨이로 API 게이트웨이 보완
API의 폭발적인 성장은 API 게이트웨이와 API 보안 분야에서 새로운 시장을 창출하고 있습니다. 미래에는 이러한 기능이 통합될 수 있지만, 현재는 API 게이트웨이에 강력한 웹 애플리케이션 방화벽(WAF)을 구축하여 위협을 완화할 수 있습니다. WAF는 IP 인텔리전스, 공격 시그니처, 악성 봇 탐지, OWASP Top 10 규칙 세트와 같은 기본 제공 기능을 사용하여 알려진 악성 트래픽이 API 게이트웨이에 도달하기 전에 차단할 수 있습니다. F5 Advanced WAF 와 같은 보다 성숙한 WAF는 전담 기능을 갖추고 있으며, 글로벌 도메인별 규칙 세트뿐만 아니라 단일 도메인 내의 여러 API를 보호하기 위해 보안 정책을 사용자 정의할 수 있습니다.
현재와 새로운 요구 사항을 충족하기 위해 기억해야 할 세 가지 사항은 다음과 같습니다.
- API 게이트웨이는 전략적 제어 지점이 되었습니다. 기술 변화로 인해 인간이 아닌 트래픽이 더욱 늘어나면서 API가 비즈니스의 초점이 되고 있습니다. API 게이트웨이는 가장자리에 위치하며 모든 API 트래픽의 진입점입니다. API 보안을 효과적으로 구현하려면 보다 풍부한 컨텍스트, 분석, 발신자 ID 및 상관 관계 기능이 필요합니다.
- API 게이트웨이와 API 보안 서비스 간의 격차는 상당합니다. 기존 앱 보안 공급업체는 버전 관리, 오케스트레이션, 측정과 같은 최소한의 API 게이트웨이 기능이 부족합니다. 대부분의 API 게이트웨이 솔루션에는 대부분 WAF 솔루션에서 제공하는 표준 보안 제어 기능이 없습니다. 적절한 기능과 보안을 위해서는 둘 다 필요합니다.
- 이런 문제는 보안 게이트웨이를 통해 해결할 수 있습니다. API 보호 기능이 있는 고급 WAF를 추가하면 대부분 API 게이트웨이의 보안 결함을 극복하는 데 도움이 될 수 있습니다. F5 Advanced WAF는 API와 마이크로서비스를 포함하도록 보안 기능을 확장했습니다. 이는 API 게이트웨이의 확장된 기능을 대체할 수는 없지만, 일반적인 보안 제어를 개선하고 강화할 수 있습니다. F5 Advanced WAF는 선언적 API도 지원하므로 민첩한 환경에서 API 보안 정책을 조정하고 자동화할 수 있습니다.
보안 게이트웨이는 보안 허점을 보완할 수 있지만 게으르지 마십시오.
기술이 발전함에 따라 API 게이트웨이가 추가적인 API 보안 문제를 해결하는 데 도움이 되겠지만 아직은 그 수준에 이르지 못했습니다. 단기적으로 API를 적절하게 보호하는 데는 계획과 모범 사례가 큰 도움이 됩니다. API를 효과적으로 보호하려면 다음 사항을 잊지 마세요.
- 항상 보안 게이트웨이를 사용하세요. 클라이언트가 API에 인증되지 않은 직접 액세스를 할 수 없도록 하세요. 알려진 불량 트래픽을 삭제할 수 있는 보안 게이트웨이나 프록시를 통해 모든 트래픽을 강제로 실행하세요. 기존 WAF가 있다면 활용하세요. 더욱 포괄적인 솔루션을 고려하는 동안 기본 WAF도 긴급하게 작동할 수 있습니다.
- 간단하게 유지하세요. 가지다 DevOps와 SecOps는 API를 개발하기 위한 일련의 표준(예: OpenAPI/Swagger)에 동의합니다. 표준은 API를 문서화하고 테스트하는 데 도움이 됩니다. OpenAPI 3.0에는 보안 설계 구현에 도움이 되는 전용 보안 구성 요소가 있으며, 이를 재사용할 수 있습니다. OpenAPI 표준을 사용하면 Crunch42와 같은 감사 및 적합성 도구를 사용하여 설계 및 보안 테스트를 자동화할 수도 있습니다.
- 보안 요구 사항을 정의합니다 . API 요구 사항의 범위에는 일반적으로 API에 대해 원하는 기능만 포함됩니다. 즉, API가 수행해야 하는 기능을 정의하는 것입니다. API 요구 사항에는 보안 요구 사항(API가 할 수 없어야 하는 것)도 포함되어야 합니다. 보안이 설계 사양의 일부이므로 보안은 API 기능 테스트의 일부가 됩니다.
- API 서비스(API 클라이언트 및 서버)에 대한 위협 모델을 만듭니다 . 제안된 시스템에 대한 위협 모델링을 수행하면 주요 자산/구성 요소와 위협 범주를 식별하는 데 도움이 됩니다. 그런 다음 식별된 위협을 완화하기 위해 보안 설계 요구 사항을 추가할 수 있습니다. API 및 앱에 대한 원하는 위험 모델에 맞게 제어가 구성되어 있는지 확인하세요.
- 인증 및 권한 부여를 오프로드합니다. 최신 인증 및 권한 부여를 위해 API 게이트웨이를 활용하세요. 모든 API는 배포의 일부로 인증을 받아야 합니다. 앱 자체에 이 기능을 빌드할 필요는 없습니다(권장하지 않는 방법인데, 인증되지 않은 트래픽을 API로 직접 전달하면 공격에 취약해질 수 있기 때문입니다). 활용할 수 있는 인증 형태는 여러 가지가 있으며, 위험 기반 접근 방식이 선택에 도움이 될 수 있습니다. Oauth 2.0은 일반적으로 REST API에 가장 적합한 옵션으로 간주됩니다. F5 BIG-IP APM은 이러한 제어를 구현하는 데 적합한 솔루션입니다.
- 모든 것을 암호화하세요. 암호화를 사용하지 않는 데에는 변명의 여지가 없습니다. SSL/TLS는 모든 인터넷 트래픽에서 100%에 가까워지고 있습니다. 모든 공개 API 트래픽은 암호화되어야 합니다. 가능하다면 보안을 강화하기 위해 임시 키를 사용하세요(Heartbleed를 기억하시나요?). 성능이나 가격으로 인해 API 게이트웨이가 암호화 작업 부하를 처리할 수 없는 경우 F5 SSL Orchestrator 와 같은 전용 시스템에 작업 부하를 오프로드하는 것을 고려하세요.
- 보안과 관련된 개발자의 "창의성"을 억제합니다 . 보안을 제대로 하는 것은 어려운 일입니다. 보안 커뮤니티에서는 수십 년 동안 이 일을 해왔지만, 여전히 취약점을 발견하고 있습니다. 개발자가 아무리 뛰어나더라도 새로운 암호화 모델 등의 맞춤형 보안 제어 기능을 개발할 때는 각별히 주의하세요. 이런 종류의 보안 "창의성"을 피하려면 DevOps에 표준화되고 철저히 검토된 기본 보안 제어를 제공해야 합니다. 특별히 맞춤화된 보안 제어가 필요한 경우 SecOps 팀에 문의해야 합니다.
API를 활용하면 새로운 비즈니스 모델과 수익 흐름을 창출하여 혁신을 가져올 수 있는 잠재력이 있습니다. 하지만 적절한 보호 장치 없이 API를 구현할 경우 기업을 혼란에 빠뜨리고 위험에 빠뜨릴 수도 있습니다. API 보안은 아직 다소 초기 단계의 기술 분야로 간주될 수 있지만, 위에서 설명한 관행은 주변 솔루션이 발전함에 따라 현재의 API 보안 격차를 해소하는 데 도움이 될 수 있습니다.