API 보안이 얼마나 중요한지 이해하셨다면…

F5

(최근 업계의 주요 화두로 떠오른 API 보안에 대해 빠르게 파악하려면 이 최근 블로그 게시물을 참조하세요. 아래 지침은 그 내용을 바탕으로 어떤 조치를 취할 수 있는지 간략히 설명합니다.)

보안 게이트웨이로 API 게이트웨이를 보완하세요

API의 폭발적인 성장으로 API 게이트웨이와 API 보안 모두에서 새로운 시장이 형성되고 있습니다. 향후에는 이 두 시장이 통합될 수도 있지만, 현재는 API 게이트웨이 앞단에 강력한 웹 애플리케이션 방화벽(WAF)을 배치하여 위협을 완화할 수 있습니다. WAF는 IP 인텔리전스, 공격 시그니처, 악성 봇 탐지, OWASP Top 10 규칙 세트와 같은 기본 제공 기능을 사용하여 알려진 악성 트래픽이 API 게이트웨이에 도달하기 전에 차단할 수 있습니다. F5 Advanced WAF와 같은 고도화된 WAF는 전용 기능을 갖추고 있으며, 도메인별로 하나의 전역 규칙 세트만 적용하는 데 그치지 않고 단일 도메인 내의 여러 API를 보호하도록 보안 정책을 맞춤 설정할 수 있습니다.

현재와 새롭게 대두되는 요구 사항에 대응할 때 기억해야 할 세 가지 사항은 다음과 같습니다:

1. API 게이트웨이는 전략적 통제 지점으로 자리 잡았습니다. 기술 전환으로 인해 비인간 트래픽이 더욱 증가하면서 API는 비즈니스의 핵심이 되고 있습니다. API 게이트웨이는 네트워크 경계에 위치하며 모든 API 트래픽이 유입되는 지점입니다. 효과적인 API 보안을 위해서는 더욱 풍부한 컨텍스트, 분석, 호출자 ID 및 상관관계 분석 기능이 필요합니다.
   
   
2. API 게이트웨이와 API 보안 제품 간의 격차는 상당합니다. 기존 애플리케이션 보안 공급업체의 제품에는 버전 관리, 오케스트레이션, 사용량 측정과 같은 기본적인 API 게이트웨이 기능이 부족합니다. 대부분의 API 게이트웨이 솔루션에는 대다수 WAF 솔루션에서 제공하는 표준 보안 제어 기능이 없습니다. 충분한 기능과 보안을 확보하려면 두 가지 모두가 필요합니다.
   
   
3. 이러한 격차는 보안 게이트웨이를 통해 해소할 수 있습니다. API 보호 기능을 갖춘 Advanced WAF를 추가하면 대부분의 API 게이트웨이가 지닌 보안상의 취약점을 보완할 수 있습니다. F5 Advanced WAF는 API와 마이크로서비스까지 보호할 수 있도록 보안 기능을 확장했습니다. API 게이트웨이의 확장 기능을 대체할 수는 없지만, 일반적인 보안 제어를 개선하고 적용할 수 있습니다. 또한 F5 Advanced WAF는 선언형 API를 지원하므로 애자일 환경에서 API 보안 정책을 오케스트레이션하고 자동화할 수 있습니다.
   

보안 게이트웨이는 보안 허점을 보완할 수 있지만, 방심해서는 안 됩니다

기술이 성숙해짐에 따라 API 게이트웨이는 더 다양한 API 보안 문제를 해결하는 데 도움이 되겠지만, 아직은 그 단계에 이르지 못했습니다. 단기적으로 API를 적절히 보호하려면 체계적인 계획과 모범 사례를 적용하는 것이 큰 도움이 됩니다. API를 효과적으로 보호하려면 다음 사항을 잊지 마세요:

1. 항상 보안 게이트웨이를 사용하세요. 클라이언트가 인증 없이 API에 직접 액세스하도록 허용하지 마세요. 알려진 악성 트래픽을 차단할 수 있는 보안 게이트웨이나 프록시를 통해 모든 트래픽이 전달되도록 하세요. 기존 WAF가 있다면 활용하세요. 더 포괄적인 솔루션을 검토하는 동안에는 기본적인 WAF도 임시방편으로 사용할 수 있습니다.
   
   
2. 단순하게 유지하세요. DevOps와 SecOps가 API 개발을 위한 일련의 표준(예: OpenAPI/Swagger)에 합의하도록 하세요. 표준을 사용하면 API를 문서화하고 테스트하는 데 도움이 됩니다. OpenAPI 3.0에는 안전한 설계를 구현하는 데 재사용할 수 있는 전용 보안 구성 요소가 있습니다. 또한 OpenAPI 표준을 사용하면 Crunch42와 같은 감사 및 적합성 도구를 활용하여 설계 및 보안 테스트를 자동화할 수 있습니다.
   
   
3. 보안 요구 사항 정의. API 요구 사항의 범위에는 일반적으로 API에 필요한 기능, 즉 API가 수행해야 하는 작업에 대한 정의만 포함됩니다. API 요구 사항에는 보안 요구 사항(API가 수행해서는 안 되는 작업)도 포함되어야 합니다. 보안을 설계 사양에 포함하면 API 기능 테스트에서도 보안을 검증하게 됩니다.
   
   
4. API 서비스에 대한 위협 모델 수립 – API 클라이언트 및 서버. 제안된 시스템에 대한 위협 모델링을 수행하면 주요 자산/구성 요소와 위협 범주를 식별하는 데 도움이 됩니다. 그런 다음 식별된 위협을 완화하기 위한 보안 설계 요구 사항을 추가할 수 있습니다. 통제 조치가 API 및 앱에 대해 원하는 위험 모델에 부합하는지 확인하세요.
   
   
5. 인증 및 권한 부여를 오프로드합니다. 최신 인증 및 권한 부여를 위해 API 게이트웨이를 활용합니다. 모든 API에는 배포 과정의 일부로 인증이 포함되어야 합니다. 이를 앱 자체에 구현할 필요는 없습니다(인증되지 않은 트래픽을 API로 직접 전달하면 API가 공격에 취약해질 수 있으므로 권장되는 방식도 아닙니다). 활용할 수 있는 인증 방식은 여러 가지이며, 위험 기반 접근 방식을 통해 적합한 방식을 선택할 수 있습니다. 일반적으로 OAuth 2.0은 REST API에 가장 적합한 옵션으로 간주됩니다. F5 BIG-IP APM은 이러한 제어 기능을 구현하는 데 적합한 솔루션입니다.
   
   
6. 모든 것을 암호화하십시오. 암호화를 사용하지 않을 이유는 없습니다. 전체 인터넷 트래픽에서 SSL/TLS 사용률은 100%에 가까워지고 있습니다. 모든 공개 API 트래픽은 암호화해야 합니다. 가능하다면 보안을 강화하기 위해 임시 키를 사용하십시오(하트블리드를 기억하시나요?). API 게이트웨이가 성능이나 비용 문제로 암호화 작업 부하를 처리할 수 없다면 다음과 같은 전용 시스템으로 작업 부하를 오프로드하는 방안을 고려하십시오. F5 SSL Orchestrator.
   
   
7. 보안과 관련된 개발자의 ‘창의성’을 자제시키십시오. 보안을 제대로 구현하기란 어렵습니다. 보안 커뮤니티가 수십 년 동안 이 문제를 다뤄 왔지만, 여전히 결함이 계속 발견되고 있습니다. 개발자들이 아무리 뛰어나더라도 새로운 암호화 모델과 같은 맞춤형 보안 통제를 고안하는 일에는 각별히 주의해야 합니다. 이러한 종류의 보안 ‘창의성’을 방지하려면 DevOps 팀에 표준화되고 충분히 검증된 기본 보안 통제를 제공해야 합니다. 특별히 맞춤화된 보안 통제가 필요하다면 SecOps 팀과 상의해야 합니다.

API를 활용하면 새로운 비즈니스 모델과 수익원을 창출할 수 있어 혁신적인 변화를 이끌 잠재력이 있습니다. 그러나 적절한 안전장치 없이 API를 구현하면 비즈니스 운영에 차질을 빚고 위험에 노출될 수도 있습니다. API 보안은 아직 다소 초기 단계의 기술 분야로 여겨질 수 있지만, 관련 솔루션이 성숙해지는 동안 위에서 설명한 방식을 적용하면 현재의 API 보안 공백을 해소하는 데 도움이 될 수 있습니다.

작성자 소개

F5

F5의 다른 블로그 게시물