다음을 통해 공유

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

  • 아티클

적용 대상: 모든 API Management 계층

참고 항목

이 문서는 2023년 최신 OWASP API 보안 상위 10개 목록을 반영하도록 업데이트되었습니다.

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

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

API Management는 API 보안을 위한 포괄적인 제어를 제공하지만 다른 Microsoft 서비스 OWASP API 위협을 감지하거나 보호하는 보완적인 기능을 제공합니다.

손상된 개체 수준 권한 부여

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

이 위협에 대한 자세한 정보: API1:2023 깨진 개체 수준 권한 부여

권장 사항

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

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

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

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

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

  • GraphQL 시나리오의 경우 요소를 사용하여 validate-graphql-request 정책을 통해 개체 수준 권한 부여를 적용합니다authorize.

끊어진 인증

사이트 또는 API에 대한 인증 메커니즘은 익명 사용자에게 열려 있기 때문에 특히 취약합니다. 잊어버린 암호 또는 암호 재설정 흐름을 포함하여 인증에 필요한 자산 및 엔드포인트는 악용을 방지하기 위해 보호되어야 합니다.

이 위협에 대한 자세한 정보: API2:2023 끊어진 인증

권장 사항

깨진 개체 속성 수준 권한 부여

좋은 API 인터페이스 디자인은 믿을 수 없을 정도로 어렵습니다. 특히 시간이 지남에 따라 진화해 온 레거시 API에서 요청 및 응답 인터페이스에는 소비하는 애플리케이션에 필요한 것보다 더 많은 데이터 필드가 포함되어 데이터 삽입 공격을 가능하게 하는 경우가 많습니다. 공격자는 문서화되지 않은 인터페이스를 검색할 수도 있습니다. 이러한 취약성은 공격자에게 중요한 데이터를 생성할 수 있습니다.

이 위협에 대한 자세한 정보: API3:2023 Broken Object Property Level Authorization

권장 사항

  • 이 취약성을 완화하는 가장 좋은 방법은 백 엔드 API에 정의된 외부 인터페이스가 데이터 지속성과 독립적으로 신중하고 이상적으로 설계되도록 하는 것입니다. API의 소비자가 요구하는 필드만 포함해야 합니다. API는 자주 검토해야 하며 레거시 필드는 더 이상 사용되지 않으며 제거되어야 합니다.
  • API Management에서 수정 버전을 사용하여 호환성이 손상되지 않는 변경(예: 인터페이스에 필드 추가) 및 호환성이 손상되는 변경 내용을 구현하는 버전을 정상적으로 제어합니다. 또한 일반적으로 소비자 지향 API와 다른 수명 주기가 있는 백 엔드 인터페이스의 버전을 지정해야 합니다.
  • 내부 데이터 구현에서 외부 API 인터페이스를 분리합니다. 백 엔드 서비스의 데이터 계약에 직접 API 계약을 바인딩하지 마세요.
  • 백 엔드 인터페이스 디자인을 변경할 수 없으며 과도한 데이터가 우려되는 경우 API Management 변환 정책을 사용하여 응답 페이로드를 다시 작성하고 데이터를 마스킹하거나 필터링합니다. API Management의 콘텐츠 유효성 검사를 XML 또는 JSON 스키마와 함께 사용하여 문서화되지 않은 속성 또는 부적절한 값으로 응답을 차단할 수 있습니다. 예를 들어 응답 본문에서 불필요한 JSON 속성을 제거합니다. 문서화되지 않은 속성이 있는 요청을 차단하면 공격이 완화되는 반면, 문서화되지 않은 속성이 있는 응답을 차단하면 잠재적인 공격 벡터를 리버스 엔지니어링하기가 더 어려워집니다. 유효성 검사 콘텐츠 정책은 지정된 크기를 초과하는 차단 응답도 지원합니다.
  • validate-status-code 정책을 사용하여 API 스키마에 정의되지 않은 오류가 있는 응답을 차단합니다.
  • 유효성 검사 헤더 정책을 사용하여 스키마에 정의되지 않았거나 스키마의 정의를 준수하지 않는 헤더로 응답을 차단합니다. set-header 정책을 사용하여 원치 않는 헤더를 제거합니다.
  • GraphQL 시나리오의 경우 validate-graphql 요청 정책을 사용하여 GraphQL 요청의 유효성을 검사하고, 특정 쿼리 경로에 대한 액세스 권한을 부여하고, 응답 크기를 제한합니다.

무제한 리소스 사용

API는 메모리 또는 CPU와 같은 리소스를 실행해야 하며 운영 비용(예: 요청당 종량제 서비스)을 나타내는 다운스트림 통합을 포함할 수 있습니다. 제한을 적용하면 과도한 리소스 사용으로부터 API를 보호할 수 있습니다.

이 위협에 대한 자세한 정보: API4:2023 무제한 리소스 사용

권장 사항

  • 속도 제한 기준 또는 속도 제한 정책을 사용하여 짧은 시간 기간에 제한을 적용합니다. 암호 재설정, 로그인 또는 등록 작업 또는 중요한 리소스를 사용하는 엔드포인트와 같은 중요한 엔드포인트에 더 엄격한 속도 제한 정책을 적용합니다.
  • 키별 할당량 또는 할당량 제한 정책을 사용하여 더 긴 시간 프레임에 허용되는 API 호출 또는 대역폭 수를 제어합니다.
  • 기본 제공 캐싱을 사용하여 성능을 최적화하여 특정 작업에 대한 CPU, 메모리, 네트워킹 리소스의 소비를 줄입니다.
  • 유효성 검사 정책을 적용합니다.
  • 생성 AI API의 경우:
  • 백 엔드 서비스가 응답하는 데 걸리는 시간을 최소화합니다. 백 엔드 서비스가 응답하는 데 시간이 오래 걸릴수록 API Management에서 연결이 더 오래 사용되므로 지정된 시간 프레임에 제공될 수 있는 요청 수가 줄어듭니다.
  • CORS 정책을 적용하여 API를 통해 제공되는 리소스를 로드할 수 있는 웹 사이트를 제어합니다. 지나치게 허용되는 구성을 방지하려면 CORS 정책에서 와일드카드 값(*)을 사용하지 마세요.
  • Azure에는 플랫폼 수준 보호와 DDoS(분산 서비스 거부) 공격에 대한 향상된 보호가 모두 있지만 API에 대한 애플리케이션(계층 7) 보호는 API Management 앞에 봇 보호 서비스(예: Azure 애플리케이션 Gateway, Azure Front Door 또는 Azure DDoS Protection)를 배포하여 개선할 수 있습니다. Azure 애플리케이션 Gateway 또는 Azure Front Door에서 WAF(웹 애플리케이션 방화벽) 정책을 사용하는 경우 Microsoft_BotManagerRuleSet_1.0을 사용하는 것이 좋습니다.

손상된 함수 수준 권한 부여

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

이 위협에 대한 자세한 정보: API5:2023 깨진 함수 수준 권한 부여

권장 사항

  • 기본적으로 구독 키 또는 모든 API 수준 권한 부여 정책을 사용하여 API Management의 모든 API 엔드포인트를 보호합니다. 해당하는 경우 특정 API 또는 API 작업에 대한 다른 권한 부여 정책을 정의합니다.
  • 정책을 사용하여 OAuth 토큰의 유효성을 검사합니다.
    • validate-azure-ad-token 정책을 사용하여 Microsoft Entra 토큰의 유효성을 검사합니다. 필요한 모든 클레임을 지정하고 해당하는 경우 권한 있는 애플리케이션을 지정합니다.
    • Microsoft Entra에서 발급하지 않은 토큰의 유효성을 검사하려면 validate-jwt 정책을 정의하고 필요한 토큰 클레임을 적용합니다. 가능하면 만료 시간이 필요합니다.
    • 가능하면 암호화된 토큰을 사용하거나 액세스를 위해 특정 애플리케이션을 나열합니다.
    • 권한 부족으로 인해 거부된 요청을 모니터링하고 검토합니다.
  • Azure 가상 네트워크 또는 Private Link를 사용하여 인터넷에서 API 엔드포인트를 숨깁니다. API Management의 가상 네트워크 옵션에 대해 자세히 알아봅니다.
  • 와일드카드 API 작업(즉, * 을 경로로 사용하는 “포괄적” API)을 정의하지 마세요. API Management가 명시적으로 정의된 엔드포인트에 대한 요청만 제공하고 정의되지 않은 엔드포인트에 대한 요청은 거부하는지 확인합니다.
  • 구독이 필요하지 않은 개방형 제품이 있는 API는 게시하지 마세요.
  • 클라이언트 IP가 알려진 경우 IP 필터 정책을 사용하여 권한 있는 IP 주소의 트래픽만 허용합니다.
  • validate-client-certificate 정책을 사용하여 클라이언트가 API Management 인스턴스에 제공한 인증서가 지정된 유효성 검사 규칙 및 클레임과 일치하도록 적용합니다.

중요한 비즈니스 흐름에 대한 무제한 액세스

API는 사용 중인 애플리케이션에 다양한 기능을 노출할 수 있습니다. API 작성자는 API가 제공하는 비즈니스 흐름과 관련 민감도를 이해하는 것이 중요합니다. 중요한 흐름을 노출하는 API가 적절한 보호를 구현하지 않는 경우 비즈니스에 더 큰 위험이 있습니다.

이 위협에 대한 자세한 정보: API6:2023 중요한 비즈니스 흐름에 대한 무제한 액세스

권장 사항

서버 쪽 요청 위조

API가 적절한 유효성 검사 없이 API 호출자가 전달한 URL 값을 기반으로 다운스트림 리소스를 가져올 때 서버 쪽 요청 위조 취약성이 발생할 수 있습니다.

이 위협에 대한 자세한 정보: API7:2023 서버 쪽 요청 위조

권장 사항

  • 가능하면 클라이언트 페이로드에 제공된 URL을 백 엔드 URL , 송신 요청 정책 또는 다시 쓰기 URL 정책에 대한 매개 변수로 사용하지 마세요.
  • API Management 또는 백 엔드 서비스가 비즈니스 논리에 대한 요청 페이로드에 제공된 URL을 사용하는 경우 API Management에서 정책 선택 및 정책 식과 같은 정책을 사용하여 호스트 이름, 포트, 미디어 형식 또는 기타 특성의 제한된 목록을 정의하고 적용합니다.
  • timeout 전달 요청 및 송신 요청 정책에서 특성을 정의합니다.
  • 유효성 검사 정책을 사용하여 요청 및 응답 데이터의 유효성을 검사하고 삭제합니다. 필요한 경우 집합 본문 정책을 사용하여 응답을 처리하고 원시 데이터를 반환하지 않도록 합니다.
  • 프라이빗 네트워킹을 사용하여 연결을 제한합니다. 예를 들어 API가 공용일 필요가 없는 경우 인터넷 연결을 제한하여 공격 표면을 줄입니다.

잘못된 보안 구성

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

  • 보안 강화 누락
  • 불필요하게 사용하도록 설정된 기능
  • 불필요하게 인터넷에 열려 있는 네트워크 연결
  • 약한 프로토콜 또는 암호화 사용

이 위협에 대한 자세한 정보: API8:2023 보안 구성 오류

권장 사항

  • 게이트웨이 TLS를 올바르게 구성합니다. 취약한 프로토콜(예: TLS 1.0, 1.1) 또는 암호화를 사용하지 마세요.
  • 암호화된 트래픽(예: HTTPS 또는 WSS 프로토콜)만 허용하도록 API를 구성합니다. Azure Policy를 사용하여 이 설정을 감사하고 적용할 수 있습니다.
  • API Management를 프라이빗 엔드포인트 뒤에 배포하거나 내부 모드로 배포된 가상 네트워크에 연결하는 것이 좋습니다. 내부 네트워크에서는 프라이빗 네트워크(방화벽 또는 네트워크 보안 그룹을 통해) 및 인터넷(역방향 프록시를 통해)에서 액세스를 제어할 수 있습니다.
  • Azure API Management 정책을 사용합니다.
    • 항상 <base> 태그를 통해 부모 정책을 상속합니다.
    • OAuth 2.0을 사용하는 경우 백 엔드에 도달하기 전에 토큰의 존재와 유효성을 검사하도록 validate-jwt 정책을 구성하고 테스트합니다. 토큰 만료 시간, 토큰 서명, 발급자를 자동으로 확인합니다. 정책 설정을 통해 클레임, 대상 그룹, 토큰 만료, 토큰 서명을 적용합니다. Microsoft Entra 를 사용하는 경우 validate-azure-ad-token 정책은 보안 토큰 의 유효성을 검사하는 보다 포괄적이고 쉬운 방법을 제공합니다.
    • CORS 정책을 구성하고 구성 옵션에 와일드카드 *을 사용하지 마세요. 대신 허용된 값을 명시적으로 나열합니다.
    • 프로덕션 환경에서 유효성 검사 정책을 설정하여 JSON 및 XML 스키마, 헤더, 쿼리 매개 변수 및 상태 코드의 유효성을 검사하고 요청 또는 응답에 대한 최대 크기를 적용합니다.
    • API Management가 네트워크 경계 외부에 있는 경우 클라이언트 IP 유효성 검사는 여전히 호출자 IP 제한 정책을 사용하여 가능합니다. 차단 목록이 아닌 허용 목록을 사용하는지 확인합니다.
    • 호출자와 API Management 간에 클라이언트 인증서를 사용하는 경우 validate-client-certificate 정책을 사용합니다. validate-revocation, validate-trust, validate-not-before, validate-not-after 속성이 모두 true로 설정되어 있는지 확인합니다.
  • 클라이언트 인증서(상호 TLS)는 API Management 백 엔드 간에도 적용할 수 있습니다. 백 엔드는 다음을 수행해야 합니다.
    • 권한 부여 자격 증명 구성
    • 해당하는 경우 인증서 체인의 유효성 검사
    • 해당하는 경우 인증서 이름의 유효성 검사
    • GraphQL 시나리오의 경우 validate-graphQL 요청 정책을 사용합니다. authorization 요소와 max-size 및 max-depth 특성이 설정되어 있는지 확인합니다.
  • 정책 파일 또는 소스 제어에 비밀을 저장하지 마세요. 항상 API Management 명명된 값을 사용하거나 사용자 지정 정책 표현식을 사용하여 런타임에 비밀을 가져옵니다. 명명된 값은 Azure Key Vault 와 통합되거나 API Management 내에서 "비밀"로 표시하여 암호화해야 합니다. 명명된 일반 텍스트 값에 비밀을 저장하지 마세요.
  • 구독이 필요한 제품을 통해 API를 게시합니다. 구독이 필요하지 않은 개방형 제품을 사용하지 마세요.
  • 모든 제품에 구독 키가 필요하도록 구성된 경우에도 API에 구독 키가 필요한지 확인합니다. 자세한 정보
  • 모든 제품에 대한 구독 승인이 필요하고 모든 구독 요청을 신중하게 검토합니다.
  • Key Vault 통합을 사용하여 모든 인증서를 관리합니다. 이렇게 하면 인증서 관리를 중앙 집중화하고 인증서 갱신 또는 해지와 같은 작업 관리 작업을 쉽게 수행할 수 있습니다. 관리 ID를 사용하여 키 자격 증명 모음에 인증합니다.
  • 자체 호스팅 게이트웨이를 사용하는 경우 이미지를 정기적으로 최신 버전으로 업데이트하는 프로세스가 있는지 확인합니다.
  • 백 엔드 서비스를 백 엔드 엔터티로 나타냅니다. 해당하는 경우 권한 부여 자격 증명, 인증서 체인 유효성 검사, 인증서 이름 유효성 검사를 구성합니다.
  • 가능한 경우 자격 증명 관리자 또는 관리 ID를 사용하여 백 엔드 서비스에 대해 인증합니다.
  • 개발자 포털을 사용하는 경우:
    • 개발자 포털을 자체 호스팅하도록 선택하는 경우 자체 호스팅 포털을 최신 버전으로 주기적으로 업데이트하는 프로세스가 있는지 확인합니다. 기본 관리 버전에 대한 업데이트는 자동으로 수행됩니다.
    • 사용자 등록 및 로그인에 Microsoft Entra ID 또는 Azure Active Directory B2C를 사용합니다. 보안이 덜한 기본 사용자 이름 및 암호 인증을 사용하지 않도록 설정합니다.
    • 제품에 사용자 그룹을 할당하여 포털에서 API의 표시 유형을 제어합니다.
  • Azure Policy를 사용하여 리소스 액세스를 제어하는 API Management 리소스 수준 구성 및 RBAC(역할 기반 액세스 제어) 권한을 적용합니다. 모든 사용자에게 필요한 최소 권한을 부여합니다.
  • 개발 환경 외부에서 DevOps 프로세스 및 코드로서의 인프라 접근 방식을 사용하여 API Management 콘텐츠 및 구성 변경의 일관성을 보장하고 사용자 오류를 최소화합니다.
  • 사용되지 않는 기능은 사용하지 마세요.

부적절한 인벤토리 관리

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

  • 적절한 API 설명서 또는 소유권 정보 부족
  • 보안 수정이 누락될 수 있는 이전 API 버전의 과도한 수

이 위협에 대한 자세한 정보: API9:2023 부적절한 인벤토리 관리

권장 사항

  • 잘 정의된 OpenAPI 사양을 REST API 가져오기의 원본으로 사용합니다. 이 사양을 사용하면 자체 문서화 메타데이터를 포함하여 API 정의를 캡슐화할 수 있습니다.
  • 정확한 경로, 데이터 스키마, 헤더, 쿼리 매개 변수, 상태 코드와 함께 API 인터페이스를 사용합니다. 와일드카드 작업을 피하세요. 각 API 및 작업에 대한 설명을 제공하고 연락처 및 라이선스 정보를 포함합니다.
  • 비즈니스 목표에 직접 기여하지 않는 엔드포인트를 방지합니다. 이는 공격 노출 영역을 불필요하게 증가시키고 API를 발전하기 어렵게 만듭니다.
  • API Management에서 수정 버전 및 버전을 사용하여 API 변경 내용을 관리합니다. 강력한 백 엔드 버전 관리 전략을 사용하고 지원되는 API 버전의 최대 수(예: 2 또는 3 이전 버전)에 커밋합니다. 더 오래되고 종종 덜 안전한 API 버전을 신속하게 사용 중단하고 궁극적으로 제거하도록 계획합니다. 사용 가능한 모든 API 버전에서 보안 컨트롤이 구현되었는지 확인합니다.
  • 환경(예: 개발, 테스트 및 프로덕션)을 다른 API Management 서비스와 분리합니다. 각 API Management 서비스가 동일한 환경에서 해당 종속성에 연결하는지 확인합니다. 예를 들어 테스트 환경에서 테스트 API Management 리소스는 테스트 Azure Key Vault 리소스 및 백 엔드 서비스의 테스트 버전에 연결해야 합니다. DevOps 자동화 및 코드로서의 인프라 사례를 사용하여 환경 간의 일관성과 정확도를 유지하고 사용자 오류를 줄일 수 있습니다.
  • 작업 영역을 사용하여 API 및 관련 리소스에 대한 관리 권한을 격리합니다.
  • 태그를 사용하여 API 및 제품을 구성하고 게시를 위해 그룹화합니다.
  • 개발자 포털을 통해 사용할 API를 게시합니다. API 설명서가 최신 상태인지 확인합니다.
  • 문서화되지 않았거나 관리되지 않는 API를 검색하고 더 나은 제어를 위해 API Management를 통해 노출합니다.
  • Azure API Management에서 API를 관리하지 않더라도 Azure API 센터를 사용하여 API, 버전 및 배포의 포괄적인 중앙 집중식 인벤토리를 유지 관리합니다.

안전하지 않은 API 사용

다운스트림 통합을 통해 얻은 리소스는 호출자 또는 최종 사용자의 API 입력보다 더 신뢰할 수 있는 경향이 있습니다. 적절한 삭제 및 보안 표준이 적용되지 않으면 통합이 신뢰할 수 있는 서비스를 통해 제공되더라도 API가 취약할 수 있습니다.

이 위협에 대한 자세한 정보: API10:2023 안전하지 않은 API 사용

권장 사항

  • API Management를 사용하여 백 엔드 API가 통합되는 다운스트림 종속성에 대한 외관 역할을 하는 것이 좋습니다.
  • 다운스트림 종속성이 API Management와 함께 제공되거나 다운스트림 종속성이 API Management의 송신 요청 정책과 함께 사용되는 경우 이 설명서의 다른 섹션의 권장 사항을 사용하여 다음을 포함하여 안전하고 제어된 소비를 보장합니다.
    • 보안 전송을 사용하도록 설정하고 TLS/SSL 구성을 적용합니다.
    • 가능하면 자격 증명 관리자 또는 관리 ID로 인증
    • rate-limit-by-key 및 quota-limit-by-key 정책을 사용하여 사용 제어
    • 유효성 검사-콘텐츠 및 유효성 검사 헤더 정책을 사용하여 API 사양과 호환되지 않는 응답을 기록하거나 차단합니다.
    • 예를 들어 불필요한 또는 중요한 정보를 제거하기 위해 집합 본문 정책을 사용하여 응답 변환
    • 시간 제한 구성 및 동시성 제한

관련 콘텐츠

자세히 알아보기: