API Management를 사용하여 OWASP API 보안 상위 10개 위협을 완화하는 권장 사항

  • 아티클

적용 대상: 모든 API Management 계층

OWASP(Open Web Application Security Project) Foundation은 커뮤니티 주도의 오픈 소스 소프트웨어 프로젝트, 전 세계 수백 개의 챕터, 수만 명의 회원, 현지 및 글로벌 컨퍼런스를 개최하여 소프트웨어 보안을 개선하기 위해 노력하고 있습니다.

OWASP API 보안 프로젝트는 API의 고유한 취약성 및 보안 위험을 이해하고 완화하기 위한 전략 및 솔루션에 중점을 둡니다. 이 문서에서는 Azure API Management를 사용하여 OWASP로 식별되는 상위 10개 API 위협을 완화하는 권장 사항에 대해 설명합니다.

참고 항목

이 문서의 권장 사항을 따르는 것 외에도 API 보안 인사이트, 권장 사항 및 위협 탐지를 위해 클라우드용 Microsoft Defender 기능인 API용 Defender를 사용하도록 설정할 수 있습니다. API Management에서 API용 Defender 사용에 대해 자세히 알아보기

손상된 개체 수준 권한 부여

적절한 수준의 권한 부여로 보호되지 않는 API 개체는 약한 개체 액세스 식별자를 통해 데이터 유출 및 무단 데이터 조작에 취약할 수 있습니다. 예를 들어 공격자는 반복될 수 있는 정수 개체 식별자를 악용할 수 있습니다.

이 위협에 대한 자세한 정보: API1:2019 손상된 개체 수준 권한 부여

권장 사항

  • 개체 수준 권한 부여를 구현하는 가장 좋은 위치는 백 엔드 API 자체 내에 있습니다. 백 엔드에서 도메인 및 API에 적용되는 논리를 사용하여 요청(또는 개체) 수준에서 올바른 권한 부여 결정을 내릴 수 있습니다. 요청자의 권한 및 권한 부여에 따라 지정된 요청이 응답에서 서로 다른 수준의 세부 정보를 생성할 수 있는 시나리오를 고려합니다.

  • 현재 취약한 API를 백 엔드에서 변경할 수 없는 경우 API Management를 대체로 사용할 수 있습니다. 예시:

    • 백 엔드에서 구현되지 않은 경우 사용자 지정 정책을 사용하여 개체 수준 권한 부여를 구현합니다.

    • 내부 식별자가 노출되지 않도록 요청에서 백 엔드로, 백 엔드에서 클라이언트로 식별자를 매핑하는 사용자 지정 정책을 구현합니다.

      이러한 경우 사용자 지정 정책은 조회(예: 사전)가 있는 정책 식이거나 요청 보내기 정책을 통해 다른 서비스와 통합될 수 있습니다.

  • GraphQL 시나리오의 경우 authorize 요소를 사용하여 GraphQL 요청 유효성 검사 정책을 통해 개체 수준 권한 부여를 적용합니다.

손상된 사용자 인증

인증 메커니즘은 종종 잘못 구현되거나 누락되어 공격자가 구현 결함을 악용하여 데이터에 액세스할 수 있습니다.

이 위협에 대한 자세한 정보: API2:2019 손상된 사용자 인증

권장 사항

사용자 인증 및 권한 부여에 API Management를 사용합니다.

  • 인증 - API Management는 다음 인증 방법을 지원합니다.

    • 기본 인증 정책 - 사용자 이름 및 암호 자격 증명.

    • 구독 키 - 구독 키는 기본 인증과 유사한 수준의 보안을 제공하며 단독으로는 충분하지 않을 수 있습니다. 구독 키가 손상된 경우 공격자는 시스템에 무제한으로 액세스할 수 있습니다.

    • 클라이언트 인증서 정책 - 클라이언트 인증서를 사용하는 것이 기본 자격 증명 또는 구독 키보다 더 안전하지만, 이는 OAuth 2.0과 같은 토큰 기반 권한 부여 프로토콜에서 제공하는 유연성을 허용하지 않습니다.

  • 권한 부여 - API Management는 OAuth ID 공급자의 메타데이터 엔드포인트에서 가져온 정보를 기반으로 들어오는 OAuth 2.0 JWT 액세스 토큰의 유효성을 검사하는 JWT 유효성 검사 정책을 지원합니다. 정책을 구성하여 관련 토큰 클레임, 대상 그룹, 만료 시간을 확인합니다. OAuth 2.0 권한 부여 및 Microsoft Entra ID를 사용하여 API를 보호하는 방법에 대해 자세히 알아봅니다.

추가 권장 사항:

  • API Management의 정책을 사용하여 보안을 강화합니다. 예를 들어 호출 속도 제한을 사용하면 무차별 암호 대입 공격(brute force attack)을 사용하여 자격 증명을 손상시키는 악의적인 행위자의 속도를 늦춥니다.

  • API는 TLS/SSL(전송 보안)을 사용하여 자격 증명 또는 토큰을 보호해야 합니다. 자격 증명 및 토큰은 쿼리 매개 변수가 아닌 요청 헤더로 전송되어야 합니다.

  • API Management 개발자 포털에서 Microsoft Entra ID 또는 Azure Active Directory B2C를 ID 공급자로 구성하여 계정 보안을 강화합니다. 개발자 포털은 CAPTCHA를 사용하여 무차별 암호 대입 공격을 완화합니다.

과도한 데이터 노출

좋은 API 인터페이스 디자인은 믿을 수 없을 정도로 어렵습니다. 특히 시간이 지남에 따라 발전해 온 레거시 API에서 요청 및 응답 인터페이스에는 소비하는 애플리케이션에 필요한 것보다 더 많은 데이터 필드가 포함되어 있는 경우가 많습니다.

잘못된 행위자는 API에 직접 액세스를 시도하거나(아마도 유효한 요청을 재생하여) 서버와 API 간의 트래픽을 검색할 수 있습니다. API 작업 및 사용 가능한 데이터를 분석하면 프런트 엔드 애플리케이션에 노출되거나 사용되지 않는 중요한 데이터를 공격자에게 제공할 수 있습니다.

이 위협에 대한 자세한 정보: API3:2019 과도한 데이터 노출

권장 사항

  • 이 취약성을 완화하는 가장 좋은 방법은 백 엔드 API에 정의된 외부 인터페이스가 데이터 지속성과 독립적으로 신중하고 이상적으로 설계되도록 하는 것입니다. API의 소비자가 요구하는 필드만 포함해야 합니다. API는 자주 검토해야 하며 레거시 필드는 더 이상 사용되지 않으며 제거되어야 합니다.

    API Management에서 다음을 사용합니다.

    • 인터페이스에 필드 추가와 같이 호환성이 손상되지 않는 변경을 정상적으로 제어하기 위한 수정 버전입니다. 백 엔드에서 버전 관리 구현과 함께 수정 버전을 사용할 수 있습니다.

    • 인터페이스에서 필드 제거와 같은 호환성이 손상되는 변경을 위한 버전입니다.

  • 백 엔드 인터페이스 디자인을 변경할 수 없으며 과도한 데이터가 우려되는 경우 API Management 변환 정책을 사용하여 응답 페이로드를 다시 작성하고 데이터를 마스킹하거나 필터링합니다. 예를 들어 응답 본문에서 불필요한 JSON 속성을 제거합니다.

  • API Management의 응답 콘텐츠 유효성 검사를 XML 또는 JSON 스키마와 함께 사용하여 문서화되지 않은 속성 또는 부적절한 값으로 응답을 차단할 수 있습니다. 이 정책은 지정된 크기를 초과하는 차단 응답도 지원합니다.

  • 상태 코드 유효성 검사 정책을 사용하여 API 스키마에 정의되지 않은 오류가 있는 응답을 차단합니다.

  • 헤더 유효성 검사 정책을 사용하여 스키마에 정의되지 않았거나 스키마의 정의를 준수하지 않는 헤더가 있는 응답을 차단합니다. 집합 헤더 정책을 사용하여 원치 않는 헤더를 제거합니다.

  • GraphQL 시나리오의 경우 GraphQL 요청 유효성 검사 정책을 사용하여 GraphQL 요청의 유효성을 검사하고, 특정 쿼리 경로에 대한 액세스 권한을 부여하고, 응답 크기를 제한합니다.

리소스 부족 및 속도 제한

속도 제한이 없으면 백 엔드 서비스에 대한 데이터 반출 또는 성공적인 DDoS 공격으로 인해 모든 소비자에게 중단이 발생할 수 있습니다.

이 위협에 대한 자세한 정보: API4:2019 리소스 부족 및 속도 제한

권장 사항

  • 속도 제한(단기) 및 할당량 제한(장기) 정책을 사용하여 소비자당 허용되는 API 호출 수 또는 대역폭을 제어합니다.

  • OpenAPI 정의에서 엄격한 요청 개체 정의 및 해당 속성을 정의합니다. 예를 들어 문자열의 페이징 정수, maxLength, 정규식에 대한 최댓값을 정의합니다. 콘텐츠의 유효성을 검사하고 API Management의 매개 변수 정책의 유효성을 검사하여 해당 스키마를 적용합니다.

  • 콘텐츠 유효성 검사 정책을 사용하여 요청의 최대 크기를 적용합니다.

  • 기본 제공 캐싱을 사용하여 성능을 최적화하여 특정 작업에 대한 CPU, 메모리, 네트워킹 리소스의 소비를 줄입니다.

  • API 호출에 인증을 적용합니다(손상된 사용자 인증 참조). 악의적인 사용자에 대한 액세스 권한을 취소합니다. 예를 들어 구독 키를 비활성화하거나, 호출자 IP 제한 정책을 사용하여 IP 주소를 차단하거나, JWT 토큰의 특정 사용자 클레임에 대한 요청을 거부합니다.

  • CORS 정책을 적용하여 API를 통해 제공되는 리소스를 로드할 수 있는 웹 사이트를 제어합니다. 지나치게 허용되는 구성을 방지하려면 CORS 정책에서 와일드카드 값(*)을 사용하지 마세요.

  • 백 엔드 서비스가 응답하는 데 걸리는 시간을 최소화합니다. 백 엔드 서비스가 응답하는 데 걸리는 시간이 길어질수록 API Management의 연결이 더 오래 사용되므로 지정된 기간에 제공될 수 있는 요청 수가 줄어듭니다.

  • API Management는 DDoS 공격으로부터 백 엔드 서비스를 보호할 수 있지만 이러한 공격 자체에 취약할 수 있습니다. DDoS 공격으로부터 더 잘 보호하기 위해 API Management 앞에 봇 보호 서비스를 배포합니다(예: Azure Application Gateway, Azure Front Door 또는 Azure DDoS Protection). Azure Application Gateway 또는 Azure Front Door에서 WAF를 사용하는 경우 Microsoft_BotManagerRuleSet_1.0을 사용하는 것이 좋습니다.

손상된 함수 수준 권한 부여

계층, 그룹, 역할이 서로 다른 복잡한 액세스 제어 정책 및 관리 기능과 일반 기능 간의 명확하지 않은 분리로 인해 권한 부여 결함이 발생합니다. 공격자는 이러한 문제를 악용하여 다른 사용자의 리소스 또는 관리 기능에 액세스할 수 있습니다.

이 위협에 대한 자세한 정보: API5:2019 손상된 함수 수준 권한 부여

권장 사항

  • 기본적으로 구독 키를 사용하여 API Management의 모든 API 엔드포인트를 보호합니다.

  • JWT 유효성 검사 정책을 정의하고 필수 토큰 클레임을 적용합니다. 특정 작업에 더 엄격한 클레임 적용이 필요한 경우 해당 작업에 대한 추가 validate-jwt 정책만 정의합니다.

  • Azure 가상 네트워크 또는 Private Link를 사용하여 인터넷에서 API 엔드포인트를 숨깁니다. API Management의 가상 네트워크 옵션에 대해 자세히 알아봅니다.

  • 와일드카드 API 작업(즉, *을 경로로 사용하는 “포괄적” API)을 정의하지 마세요. API Management가 명시적으로 정의된 엔드포인트에 대한 요청만 제공하고 정의되지 않은 엔드포인트에 대한 요청은 거부하는지 확인합니다.

  • 구독이 필요하지 않은 개방형 제품이 있는 API는 게시하지 마세요.

대량 할당

API가 클라이언트가 지정된 작업에 필요한 것보다 더 많은 필드를 제공하는 경우 공격자는 과도한 속성을 삽입하여 데이터에 대한 무단 작업을 수행할 수 있습니다. 공격자는 요청 및 응답 또는 기타 API의 형식을 검사하거나 추측하여 문서화되지 않은 속성을 검색할 수 있습니다. 이 취약성은 강력한 형식의 프로그래밍 언어를 사용하지 않는 경우에 특히 적용됩니다.

이 위협에 대한 자세한 정보: API6:2019 대량 할당

권장 사항

  • 외부 API 인터페이스는 내부 데이터 구현에서 분리되어야 합니다. 백 엔드 서비스의 데이터 계약에 직접 API 계약을 바인딩하지 마세요. API 디자인을 자주 검토하고 API Management의 버전 관리를 사용하여 레거시 속성을 더 이상 사용하지 않고 제거합니다.

  • API 스키마에서 XML 및 JSON 계약을 정확하게 정의하고, 콘텐츠 유효성 검사 및 매개 변수 유효성 검사 정책을 사용하여 문서화되지 않은 속성이 있는 요청 및 응답을 차단합니다. 문서화되지 않은 속성이 있는 요청을 차단하면 공격이 완화되는 반면, 문서화되지 않은 속성이 있는 응답을 차단하면 잠재적인 공격 벡터를 리버스 엔지니어링하기가 더 어려워집니다.

  • 백 엔드 인터페이스를 변경할 수 없는 경우 변환 정책을 사용하여 요청 및 응답 페이로드를 다시 작성하고 백 엔드 계약에서 API 계약을 분리합니다. 예를 들어 데이터를 마스킹 또는 필터링하거나 불필요한 JSON 속성을 제거합니다.

잘못된 보안 구성

공격자는 다음과 같은 잘못된 보안 구성 취약성을 악용하려고 시도할 수 있습니다.

  • 보안 강화 누락
  • 불필요한 사용 기능
  • 불필요하게 인터넷에 열려 있는 네트워크 연결
  • 약한 프로토콜 또는 암호화 사용
  • 시스템에 대한 무단 액세스를 허용할 수 있는 기타 설정 또는 엔드포인트

이 위협에 대한 자세한 정보: API7:2019 잘못된 보안 구성

권장 사항

  • 게이트웨이 TLS를 올바르게 구성합니다. 취약한 프로토콜(예: TLS 1.0, 1.1) 또는 암호화를 사용하지 마세요.

  • 암호화된 트래픽(예: HTTPS 또는 WSS 프로토콜)만 허용하도록 API를 구성합니다.

  • API Management를 프라이빗 엔드포인트 뒤에 배포하거나 내부 모드로 배포된 가상 네트워크에 연결하는 것이 좋습니다. 내부 네트워크에서는 프라이빗 네트워크(방화벽 또는 네트워크 보안 그룹을 통해) 및 인터넷(역방향 프록시를 통해)에서 액세스를 제어할 수 있습니다.

  • Azure API Management 정책 사용:

    • 항상 <base> 태그를 통해 부모 정책을 상속합니다.

    • OAuth 2.0을 사용하는 경우 백 엔드에 도달하기 전에 JWT 토큰의 존재와 유효성을 확인하도록 JWT 유효성 검사 정책을 구성하고 테스트합니다. 토큰 만료 시간, 토큰 서명, 발급자를 자동으로 확인합니다. 정책 설정을 통해 클레임, 대상 그룹, 토큰 만료, 토큰 서명을 적용합니다.

    • CORS 정책을 구성하고 구성 옵션에 와일드카드 *을 사용하지 마세요. 대신 허용된 값을 명시적으로 나열합니다.

    • 프로덕션 환경에서 유효성 검사 정책을 prevent로 설정하여 JSON 및 XML 스키마, 헤더, 쿼리 매개 변수, 상태 코드의 유효성을 검사하고 요청 또는 응답의 최대 크기를 적용합니다.

    • API Management가 네트워크 경계 외부에 있는 경우 클라이언트 IP 유효성 검사는 여전히 호출자 IP 제한 정책을 사용하여 가능합니다. 차단 목록이 아닌 허용 목록을 사용하는지 확인합니다.

    • 호출자와 API Management 간에 클라이언트 인증서가 사용되는 경우 클라이언트 인증서 유효성 검사 정책을 사용합니다. validate-revocation, validate-trust, validate-not-before, validate-not-after 속성이 모두 true로 설정되어 있는지 확인합니다.

      • 클라이언트 인증서(상호 TLS)는 API Management 백 엔드 간에도 적용할 수 있습니다. 백 엔드는 다음을 수행해야 합니다.

        • 권한 부여 자격 증명 구성

        • 해당하는 경우 인증서 체인의 유효성 검사

        • 해당하는 경우 인증서 이름의 유효성 검사

  • GraphQL 시나리오의 경우 GraphQL 요청 유효성 검사 정책을 사용합니다. authorization 요소와 max-size 및 max-depth 특성이 설정되어 있는지 확인합니다.

  • 정책 파일 또는 소스 제어에 비밀을 저장하지 마세요. 항상 API Management 명명된 값을 사용하거나 사용자 지정 정책 표현식을 사용하여 런타임에 비밀을 가져옵니다.

    • 명명된 값은 Key Vault와 통합하거나 API Management 내에서 “비밀”로 표시하여 암호화해야 합니다. 명명된 일반 텍스트 값에 비밀을 저장하지 마세요.

  • 구독이 필요한 제품을 통해 API를 게시합니다. 구독이 필요하지 않은 개방형 제품을 사용하지 마세요.

  • Key Vault 통합을 사용하여 모든 인증서를 관리합니다. 이렇게 하면 인증서 관리가 중앙 집중화되며 인증서 갱신 또는 해지와 같은 작업 관리 작업을 쉽게 수행할 수 있습니다.

  • 자체 호스팅 게이트웨이를 사용하는 경우 이미지를 정기적으로 최신 버전으로 업데이트하는 프로세스가 있는지 확인합니다.

  • 백 엔드 서비스를 백 엔드 엔터티로 나타냅니다. 해당하는 경우 권한 부여 자격 증명, 인증서 체인 유효성 검사, 인증서 이름 유효성 검사를 구성합니다.

  • 개발자 포털을 사용하는 경우:

    • 개발자 포털을 자체 호스팅하도록 선택하는 경우 자체 호스팅 포털을 최신 버전으로 주기적으로 업데이트하는 프로세스가 있는지 확인합니다. 기본 관리 버전에 대한 업데이트는 자동으로 수행됩니다.

    • 사용자 등록 및 로그인에 Microsoft Entra ID 또는 Azure Active Directory B2C를 사용합니다. 보안이 덜한 기본 사용자 이름 및 암호 인증을 사용하지 않도록 설정합니다.

    • 제품에 사용자 그룹을 할당하여 포털에서 API의 표시 유형을 제어합니다.

  • Azure Policy를 사용하여 리소스 액세스를 제어하는 API Management 리소스 수준 구성 및 RBAC(역할 기반 액세스 제어) 권한을 적용합니다. 모든 사용자에게 필요한 최소 권한을 부여합니다.

  • 개발 환경 외부에서 DevOps 프로세스 및 코드로서의 인프라 접근 방식을 사용하여 API Management 콘텐츠 및 구성 변경의 일관성을 보장하고 사용자 오류를 최소화합니다.

  • 사용되지 않는 기능은 사용하지 마세요.

삽입

사용자 데이터를 수락하는 모든 엔드포인트는 삽입 악용에 잠재적으로 취약합니다. 예에는 다음이 포함되지만 이에 국한되지는 않습니다.

  • 명령 삽입은 잘못된 행위자가 API를 호스팅하는 운영 체제에서 명령을 실행하도록 API 요청을 변경하려고 시도하는 경우입니다.

  • SQL 삽입은 잘못된 행위자가 API 요청을 변경하여 API가 의존하는 데이터베이스에 대해 명령 및 쿼리를 실행하려고 시도하는 경우입니다.

이 위협에 대한 자세한 정보: API8:2019 삽입

권장 사항

  • 최신 WAF(Web Application Firewall) 정책은 많은 일반적인 삽입 취약성을 다룹니다. API Management에는 기본 제공 WAF 구성 요소가 없지만 API Management 인스턴스의 WAF 업스트림(앞)을 배포하는 것이 좋습니다. 예를 들어 Azure Application Gateway 또는 Azure Front Door를 사용합니다.

    Important

    잘못된 행위자가 WAF를 호스트하는 게이트웨이를 우회하지 못하고 API Management 게이트웨이 또는 백 엔드 API 자체에 직접 연결할 수 없는지 확인합니다. 가능한 완화 방법으로는 네트워크 ACL, API Management 정책을 사용하여 클라이언트 IP에 의한 인바운드 트래픽 제한, 필요하지 않은 퍼블릭 액세스 제거, 클라이언트 인증서 인증(상호 TLS 또는 mTLS라고도 함) 등이 있습니다.

  • 해당하는 경우 스키마 및 매개 변수 유효성 검사 정책을 사용하여 백 엔드 API 서비스에 도달하기 전에 요청을 추가로 제한하고 유효성을 검사합니다.

    API 정의와 함께 제공되는 스키마에는 취약한 필드에 정규식 패턴 제약 조건이 적용되어야 합니다. 일반적인 삽입 시도를 완화하기 위해 필드를 충분히 제한하도록 각 정규식을 테스트해야 합니다.

부적절한 자산 관리

부적절한 자산 관리와 관련된 취약성은 다음과 같습니다.

  • 적절한 API 설명서 또는 소유권 정보 부족

  • 보안 수정이 누락될 수 있는 이전 API 버전의 과도한 수

이 위협에 대한 자세한 정보: API9:2019 부적절한 자산 관리

권장 사항

  • 잘 정의된 OpenAPI 사양을 REST API 가져오기의 원본으로 사용합니다. 이 사양을 사용하면 자체 문서화 메타데이터를 포함하여 API 정의를 캡슐화할 수 있습니다.

    • 정확한 경로, 데이터 스키마, 헤더, 쿼리 매개 변수, 상태 코드와 함께 API 인터페이스를 사용합니다. 와일드카드 작업을 피하세요. 각 API 및 작업에 대한 설명을 제공하고 연락처 및 라이선스 정보를 포함합니다.

    • 비즈니스 목표에 직접 기여하지 않는 엔드포인트를 피하세요. 이는 공격 노출 영역을 불필요하게 증가시키고 API를 발전하기 어렵게 만듭니다.

  • API Management 수정 버전 및 버전을 사용하여 API 엔드포인트를 제어합니다. 강력한 백 엔드 버전 관리 전략을 사용하고 지원되는 API 버전의 최대 수(예: 2 또는 3 이전 버전)에 커밋합니다. 더 오래되고 종종 덜 안전한 API 버전을 신속하게 사용 중단하고 궁극적으로 제거하도록 계획합니다.

  • 환경별 API Management 인스턴스(예: 개발, 테스트, 프로덕션)를 사용합니다. 각 API Management 인스턴스가 동일한 환경에서 해당 종속성에 연결되는지 확인합니다. 예를 들어 테스트 환경에서 테스트 API Management 리소스는 테스트 Azure Key Vault 리소스 및 백 엔드 서비스의 테스트 버전에 연결해야 합니다. DevOps 자동화 및 코드로서의 인프라 사례를 사용하여 환경 간의 일관성과 정확도를 유지하고 사용자 오류를 줄일 수 있습니다.

  • 태그를 사용하여 API 및 제품을 구성하고 게시를 위해 그룹화합니다.

  • 기본 제공 개발자 포털을 통해 사용할 API를 게시합니다. API 설명서가 최신 상태인지 확인합니다.

  • 문서화되지 않았거나 관리되지 않는 API를 검색하고 더 나은 제어를 위해 API Management를 통해 노출합니다.

로깅 및 모니터링 부족

불충분한 로깅 및 모니터링은 인시던트 대응과의 통합이 누락되거나 비효율적이며, 공격자가 시스템을 추가로 공격하고, 지속성을 유지하며, 더 많은 시스템으로 피벗하여 데이터를 변조하고 추출하거나 삭제할 수 있습니다. 대부분의 위반 연구에 따르면 위반을 감지하는 데 걸리는 시간이 200일 이상이며 일반적으로 내부 프로세스나 모니터링이 아닌 외부 당사자가 감지합니다.

이 위협에 대한 자세한 정보: API10:2019 로깅 및 모니터링 부족

권장 사항

다음 단계

자세히 알아보기: