OWASP 상위 10개 API 위협

Apigee Edge 문서입니다.
Apigee X 문서로 이동 정보

이 문서에서는 Apigee 내에서 OWASP에서 식별한 보안 취약점을 해결하는 데 사용할 수 있는 다양한 접근 방식을 설명합니다. Apigee에 관해 문서화된 추가 접근 방식은 Google Cloud의 OWASP 2021년 상위 10개 완화 옵션을 참고하세요.

소개

OWASP는 조직이 신뢰할 수 있는 애플리케이션과 API를 개발, 구매, 유지관리할 수 있도록 지원하는 공개 커뮤니티입니다. OWASP는 OWASP API 보안 프로젝트를 통해 웹 애플리케이션 및 REST API에 대한 가장 중요한 보안 위험을 게시하고 이러한 위험을 해결하기 위한 권장사항을 제공합니다.

이 문서에서는 OWASP의 2019년 상위 10개 API 보안 위협에서 확인한 일반적인 API 기반 공격을 방어하는 접근 방식을 설명합니다. 최신 목록에서 강조 표시된 주요 위협의 공통적인 주제는 클라이언트 앱 내에서 API 요청에 의해 반환된 데이터의 필터링에 의존하는 등 인증 및 승인 제어를 부적절하게 배치하는 데서 비롯됩니다. 이는 액세스 제어 시행을 위해 소비 클라이언트 앱에 의존하는 안티패턴을 사용하는 것입니다.

API 생태계가 빠르게 성장함에 따라 공격자가 데이터를 유출하는 API 악용 및 오용은 안타깝게도 오늘날 가장 일반적인 공격 벡터 중 하나가 되고 있습니다. 보안은 Apigee의 주요 과제이며 보안 보고 및 이상 감지 기능을 포함하는 고급 API 작업과 같은 여러 새로운 기능이 이를 뒷받침합니다. 하지만 API에 대한 공격이 성공할 가능성을 줄이려면 Apigee의 보안 기능을 올바르게 설계하고 구현하는 것이 중요합니다.

앱이 실행되는 플랫폼을 제어할 수 없으므로 소비자 애플리케이션은 신뢰할 수 없거나 '공개'로 간주되어야 합니다. 모든 공개 앱은 손상될 수 있으므로 액세스 제어 (API1, API5), 응답 데이터 필터링 (API6) 또는 API 키나 액세스 토큰과 같은 클라이언트 비밀 (API2)을 안전하게 저장하는 데 사용할 수 없습니다. 2019년 OWASP 상위 10개 항목을 검토한 결과 다음과 같은 권장사항이 도출되었습니다.

  • API를 사용할 클라이언트 앱의 종류 (SPA, 모바일 또는 브라우저 기반)를 결정하고 적절한 인증, 승인, 보안 패턴을 설계합니다.
  • 항상 '공개 클라이언트' OAuth 또는 OpenID Connect 흐름을 사용합니다 (PKCE 사용을 적극 권장함).
  • 앱의 비즈니스 로직을 고려하고 먼저 OpenAPI 사양을 정의한 후 Apigee 내 백엔드에서 모든 응답 데이터를 필터링하도록 API 프록시를 설계합니다. 이를 실행하기 위해 다운스트림 앱 코드 로직에 의존하지 마세요.
  • 사용자별 PII가 포함된 모든 데이터 요청을 필터링하여 요청하는 사용자에게 속한 백엔드의 데이터만 허용합니다.

API1:2019 손상된 객체 수준 승인

위협 설명

객체 액세스 요청의 승인 검증이 충분하지 않으면 공격자가 액세스 토큰을 재사용하여 승인되지 않은 작업을 실행할 수 있습니다. 이 위협은 승인 유효성 검사가 잘못 구성되어 발생합니다. Apigee는 이 취약점으로부터 보호하는 데 도움이 되는 VerifyApiKey, OAuth, JSON 웹 토큰 (JWT) 정책을 제공하지만 이러한 정책을 올바르게 구성하여 위협을 방지하는 것이 중요합니다.

이러한 위협을 방지하려면 애플리케이션 개발팀과 보안팀이 긴밀하게 협력하는 것이 중요합니다. 승인은 본질적으로 복잡한 주제이며 효과적인 세분화된 승인을 위해서는 애플리케이션의 비즈니스 로직을 깊이 이해해야 합니다.

Apigee 구현 관점에서 고려해야 할 두 가지 주요 측면은 다음과 같습니다.

  • 액세스 토큰 무결성
  • 액세스 제어 적용

액세스 토큰 무결성

적절한 사용자 인증 정보 유효성 검사 또는 서명 메커니즘과 함께 올바른 OAuth 또는 OpenID Connect 흐름을 사용하여 요청 클라이언트가 제공한 토큰이 조작되지 않았는지 확인하는 것이 중요합니다. Apigee는 일반적으로 사용되는 모든 OAuth 흐름을 지원합니다.

Apigee 액세스 토큰 확인 정책에는 다음이 포함됩니다.

액세스 제어 적용

액세스 토큰의 유효성이 확인되면 수신되는 각 API 요청을 승인 토큰의 액세스 사용 권한과 비교하여 평가하는 액세스 제어 시행 정책을 구현하는 것이 중요합니다.

Apigee는 승인 정책을 확인하고 시행하기 위한 두 가지 기본 메커니즘을 제공합니다.

  • 내부: 조건부 흐름을 사용하여 승인 토큰에서 흐름 변수로 추출된 클레임을 기반으로 액세스 요청을 평가합니다.
  • 위임됨: 서드 파티 액세스 관리 솔루션에 대한 서비스 호출을 사용합니다.

액세스 제어 모델이 비교적 간단한 경우 내부 접근 방식 (위 그림 참고)을 사용하는 것이 좋습니다. 예를 들어 액세스 토큰에서 추출된 클레임을 사용하여 API 객체 요청을 직접 평가하고 승인할 수 있습니다.

OAuth 또는 JWT 정책에 사용할 수 있는 흐름 변수를 사용하여 조건부 흐름 문을 사용하여 액세스 요청을 평가합니다.

액세스 토큰에서 추출된 클레임을 백엔드 객체에 대한 API 요청을 승인하는 데 직접 사용할 수 없는 경우 또는 액세스 토큰을 가져오기 위해 인증 서버를 별도로 호출해야 하는 더 복잡한 OAuth 흐름 유형의 경우 위임된 접근 방식 (위 그림 참고)을 사용하는 것이 좋습니다.

서비스 호출 정책을 사용하면 서드 파티 서비스에 승인 정책 결정을 요청하거나 요청 에이전트에 관한 추가 소유권 주장 정보를 획득한 후 조건부 흐름을 사용하여 액세스 제어 결정을 내릴 수 있습니다.

API2:2019 손상된 사용자 인증

위협 설명

잘못 구현된 사용자 인증 정책을 사용하면 공격자가 인증 구현의 구현 결함을 악용해 적법한 사용자의 명의를 도용할 수 있습니다. 인증 접근 방식을 구현할 때 유의해야 할 몇 가지 인증 원칙은 다음과 같습니다.

  • 항상 사용자 에이전트 (앱)와 요청하는 사용자를 모두 인증합니다.
  • 위임된 인증 및 승인 패턴을 사용하고 API 요청 내에서 비밀번호를 직접 전달하지 않음
  • 항상 액세스 사용자 인증 정보의 서명을 확인하고 사용되는 모든 액세스 사용자 인증 정보에 정의된 만료 시간이 있는지 확인합니다.
  • 할당량을 설정하고 Apigee Sense를 사용하여 봇 기반 무차별 대입 공격을 감지하고 대응하여 무차별 대입 공격을 방지합니다.

외부에서 안으로 패러다임에서 API 설계는 백엔드 시스템의 기존 데이터 구조가 아닌 데이터에 대한 소비자의 사용 사례를 중심으로 구축되며, 보안은 외부 소비자를 위한 API를 설계할 때 중요한 요소입니다. 기존 백엔드 시스템은 공개 네트워크에 노출하기에 충분히 강력한 인증 구현으로 빌드되지 않았습니다. 이때 Apigee는 ID 및 액세스 관리 솔루션과 함께 이러한 위협으로부터 보호하기 위한 강력한 솔루션을 제공할 수 있습니다.

여기서 고려해야 할 주요 요소는 두 가지가 있으며, 두 가지 모두 후속 섹션에서 다룹니다.

  • 보안 설계: 인증 패턴을 구현하기 위해 Apigee 기능을 최대한 활용합니다.
  • 거버넌스: 설계된 인증 패턴이 게시된 모든 API 제품에서 일관되게 올바르게 사용되도록 합니다.
  • 운영 보안: 의심스럽거나 비정상적인 동작과 인증된 API 프록시를 우회하거나 무차별 대입하려는 시도를 감지할 수 있어야 합니다.

보안 설계

보안 설계의 목표는 인증 흐름을 올바르게 구현하고 서드 파티 ID 도구와 통합하는 것입니다. 보안 설계는 중요한 단계이며, API 엔드포인트를 사용할 앱의 유형에 따라 사용할 적절한 위임 인증 흐름 유형을 이해하는 것으로 시작됩니다. 다음 단계는 ID 팀과 함께 ID 솔루션으로 구현할 통합 패턴을 정의하는 것입니다.

OpenID Connect 및 OAuth RFC는 위임된 인증 및 승인 흐름과 이러한 흐름에 참여하는 행위자를 광범위하게 제공합니다. 이는 복잡한 주제이며, 인증 중단이 주요 OWASP API 위협 중 하나라는 것은 놀라운 일이 아닙니다. ID 표준의 올바른 구현에 관한 포괄적인 입문서를 제공하는 것은 이 문서의 범위에 해당하지 않지만 Apigee에는 이 ebook 및 웹캐스트, 구현 예와 같이 OAuth 흐름을 더 잘 이해할 수 있는 추가 리소스가 많이 있습니다.

인증 정책

ID 및 인증 문제를 해결하는 데 도움이 되는 Apigee 정책은 다음과 같습니다.

  • OAuth 2.0 프레임워크를 사용할 때 액세스 토큰, 갱신 토큰 또는 응답 흐름 토큰을 확인하거나 생성합니다. 참고: 기술적으로 OAuth는 위임된 승인 프레임워크이지만 위임된 인증 패턴이나 제휴 인증 패턴에서 광범위하게 사용됩니다.
  • OpenID Connect 1.0 JSON 웹 토큰 및 JSON 웹 서명을 확인, 디코딩, 생성
  • SAML 어설션 생성 및 유효성 검사
  • API 키 확인
  • 키 해시 기반 메시지 인증 코드 (HMAC) 인증

트래픽 관리

다음 Apigee 트래픽 관리 기능은 무차별 대입 공격으로부터 보호하는 데 도움이 됩니다.

  • API 프록시에 전반적인 롤링 평균 비율 제한을 설정하기 위한 Spike Arrest 정책
  • 할당량 정책: 앱 키, 개발자 또는 API 제품 할당량으로 정의된 할당량에 따라 API 프록시에 세분화된 요금 한도를 설정합니다.
  • 정의된 만료 시간을 기반으로 저장된 액세스 토큰을 캐시하는 캐싱 정책과 캐시된 사용자 인증 정보를 invalidate하는 기능 (예: 유효한 액세스 토큰이 도용된 경우)

거버넌스

보안은 '설정하고 잊어버리는' 프로젝트가 아니라 지속적인 프로세스이며, 보안 침해의 가장 큰 원인 중 하나는 구성 오류입니다. 인증 흐름, ID 통합 패턴, 인증 관련 트래픽 관리 정책을 정의한 후에는 이를 올바르고 일관되게 구현하는 것이 매우 중요합니다.

Apigee는 구현 무결성을 보장하고 구성 오류를 방지하기 위한 다양한 기능과 도구를 제공합니다.

역할 기반 액세스 제어 (RBAC)

대기업이든 소규모 스타트업이든 구성 오류를 방지하려면 적절한 사용자와 팀만 API 프록시 구성에 액세스하고 이를 수정할 수 있도록 하는 것이 가장 중요합니다. API 프로그램은 조직 전반의 여러 팀에서 지원합니다. 각 팀에 API 여정의 일환으로 업무를 수행하는 데 필요한 권한만 부여하는 것이 매우 중요합니다.

Apigee는 사전 정의된 역할에 사용자를 할당하거나 API팀에 적합한 맞춤 역할을 만들 수 있는 기능을 제공하여 역할 기반 액세스를 관리하는 기능을 제공합니다. API 프로그램을 안전하게 확장하려면 역할 할당을 올바르게 정의하고 관리하는 것이 중요합니다. 제휴를 사용하여 기존 기업 디렉터리와 통합하고 Apigee 내에서 두 번째 관리자 사용자 인증 정보를 관리할 필요성을 줄일 수도 있습니다.

공유 흐름

공유 흐름을 사용하면 정책과 리소스를 API 프록시 전반에서 구현할 수 있는 재사용 가능한 객체로 정의할 수 있습니다. 예를 들어 API를 사용하는 앱의 유형에 따라 보안팀과 공동으로 여러 인증 설계 패턴을 설계했을 수 있습니다. API 개발자가 이를 재사용하기 위해 ID 전문가일 필요는 없습니다. 흐름 호출 정책을 사용하여 기존 API 프록시 구성에 추가할 올바른 공유 흐름만 알면 됩니다.

그림: 공유 흐름은 복합 패턴을 유지할 수 있는 정책 및 조건부 로직의 재사용 가능한 번들입니다.

보안 보고

조직의 적절한 인원만 인증 패턴을 수정할 수 있도록 하고 공유 인증 흐름을 정의한 후에는 API팀에서 개발한 API 프록시가 이러한 인증 패턴을 일관되게 사용하고 있는지 확인해야 합니다.

Apigee의 새로운 고급 API 작업 기능에는 고급 보안 보고가 포함되어 있습니다. 이를 통해 운영팀과 보안팀이 모든 API 프록시에 관한 보고서를 쉽게 확인할 수 있으며 공유 흐름 사용과 같은 보안 정책 준수에 중점을 둡니다. 보고, 로깅, 알림은 API 보안의 핵심 요소이며 API10: 로깅 불충분에서 자세히 설명합니다. 하지만 인증 손상 위험 방지의 관점에서는 공유 흐름으로 구현된 정의된 인증 표준을 준수하는 데 매우 유용합니다.

운영 보안

기준 트래픽 관리가 적용된 올바른 인증 패턴을 사용하여 API가 프로덕션에 배포되면 SecOps팀은 의심스러운 활동을 모니터링하고 이에 대응할 수 있어야 합니다. 이러한 활동은 종종 인증 사용자 인증 정보 도용 시도로 시작됩니다.

Apigee Sense

Apigee Sense는 악의적인 클라이언트의 공격을 비롯한 원치 않는 요청 트래픽으로부터 API를 보호합니다. Apigee Sense는 API 요청 트래픽을 분석하여 원치 않는 요청을 나타낼 수 있는 패턴을 식별합니다. 이 분석을 사용하면 원치 않는 요청을 하는 클라이언트를 식별한 후 이러한 요청을 허용, 차단 또는 신고하는 조치를 취할 수 있습니다. 향후 Sense의 기능에는 의심스러운 트래픽에서 ReCAPTCHA 인증을 자동으로 사용 설정하는 기능이 포함될 예정입니다.

Apigee Sense를 사용하면 다음과 같은 요청 패턴으로부터 API를 보호할 수 있습니다.

  • 인간의 행동과 조화를 이루는 자동화된 행동
  • 동일한 IP에서 지속적으로 시도함
  • 비정상적인 오류율
  • 의심스러운 클라이언트 요청
  • 데이터 크롤링
  • 키 수집 및 인증 무차별 대입 공격
  • 활동 급증
  • 지역적 패턴

고급 API 작업

Sense는 봇과 유사한 위협을 감지하고 대응하기 위해 특별히 설계되었지만, 고급 API 운영에는 이상 감지와 고급 알림 정의가 모두 포함되어 있습니다.

이상 감지는 이전 API 데이터에 인공지능 (AI) 및 머신러닝 (ML) 모델을 적용하여 작동합니다. 이상 감지는 생산성 향상과 API 문제의 평균 해결 시간 (MTTR) 단축에 관한 전혀 예상하지 못한 시나리오에 대해 실시간으로 경고를 보낼 수 있습니다.

고급 API 작업은 기존 API Monitoring 알림 메커니즘을 기반으로 다음과 같은 고급 알림 유형을 추가합니다.

  • 총 트래픽 알림 일정 기간에 트래픽이 지정된 비율만큼 변동하면 경고가 발생합니다. 예를 들어 트래픽이 1시간 동안 5% 이상 증가하거나, 일주일 동안 10% 이상 줄어들 때 경고를 받을 수 있습니다.
  • 이상치 알림 사용자가 직접 미리 결정하지 않아도 Edge는 트래픽 및 성능 문제를 자동으로 감지합니다. 그런 후 이러한 이상에 대해 경고를 발생시킬 수 있습니다.
  • TLS 만료 알림 TLS 인증서가 곧 만료될 때 알림을 표시합니다.

API3:2019 과도한 데이터 노출

위협 설명

게시된 API는 클라이언트 앱에서 필요한 필터링을 실행하도록 하여 필요 이상으로 많은 데이터를 노출할 수 있습니다. 공격자가 기본 API를 직접 쿼리하면 민감한 정보에 액세스할 수 있습니다.

Apigee의 API 설계 '외부에서 안으로' 설계 원칙 중 하나는 데이터 절약입니다. UX 디자이너 및 개발자와 협력하여 앱 UI 내에 필요한 API를 통해서만 데이터를 노출합니다. 백엔드 시스템은 공개 사용 패턴을 위해 빌드되지 않았으므로 Apigee를 사용한 API 우선 설계의 첫 번째 작업 중 하나는 고객과 개발자에게 우수한 API 제품을 제공하는 데 필요한 최소한의 데이터로 노출되는 데이터를 줄이는 것입니다.

Apigee의 또 다른 설계 원칙은 재사용성입니다. 보안 문제는 차치하고 앱을 사용하여 API에서 제공하는 데이터를 필터링하면 앱을 개발하는 모든 플랫폼에 필터링 로직을 포팅해야 합니다.

보안 관점에서 이 위협은 승인 시행을 앱에 위임하는 데서 비롯되며, 앱이 개발자가 제어할 수 없는 플랫폼이나 OS에 있는 경우가 많습니다. API1 및 API2에서 무단 데이터 액세스를 방지하기 위해 인증 및 승인을 올바르게 구현하는 것이 얼마나 중요한지 이미 살펴봤습니다.

다음 섹션에서는 다음 작업을 수행하는 방법을 살펴봅니다.

  • 백엔드 서비스에 대한 요청 및 응답을 재작성하여 데이터 노출 최소화
  • 상세 오류 메시지가 백엔드 서비스에 관한 민감한 환경 정보를 공격자에게 노출하지 못하도록 오류 처리를 구현합니다.

응답 및 요청 재작성

백엔드 시스템은 일반적으로 공개 앱이나 신뢰할 수 없는 공개 네트워크에서 사용하도록 설계되지 않습니다. Apigee Edge는 과도한 데이터 노출로부터 백엔드를 보호하여 퍼블릭 API 제품을 배포할 수 있도록 설계되었습니다.

이를 위해 Apigee는 다음 세 가지 주요 정책을 사용합니다.

  • Assign Message
  • 코드 콜아웃
  • 오류 처리

메시지 할당 정책

Assign Message 정책은 API 프록시 흐름 중에 새 요청 및 응답 메시지를 변경하거나 만듭니다. 정책을 사용하면 이러한 메시지에 대해 다음 작업을 수행할 수 있습니다.

  • 메시지에 새 양식 매개변수, 헤더, 쿼리 매개변수 추가
  • 기존 속성을 한 메시지에서 다른 메시지로 복사하기
  • 메시지에서 헤더, 쿼리 매개변수, 양식 매개변수, 메시지 페이로드를 삭제합니다.
  • 메시지에서 기존 속성 값 설정

Assign Message를 사용하면 일반적으로 요청 또는 응답의 속성을 추가, 변경, 삭제할 수 있습니다. 그러나 커스텀 요청 메시지 만들기에 설명된 대로 Assign Message을 사용하여 커스텀 요청 또는 응답 메시지를 만들고 대체 대상으로 전달할 수도 있습니다.

커스텀 코드를 사용한 복잡한 재작성

메시지 할당 정책의 기능을 벗어나는 복잡성을 가지는 복잡한 데이터 처리 및 재작성 규칙의 경우 JavaScript, Java, Python과 같은 절차적 언어를 사용할 수 있습니다. API 프록시에 커스텀 코드를 추가한 다음 프록시 흐름에 추가된 정책에서 이를 호출할 수 있습니다. 절차적 코드 지원은 흐름 변수, 오류, 요청 및 응답 본문의 복잡한 처리를 보다 쉽게 구현할 수 있도록 설계되었습니다.

절차적 코드를 사용하면 다음을 수행할 수 있습니다.

  • 요청 및 응답 값과 같은 복잡한 본문 값을 만들거나 조작합니다.
  • 대상 엔드포인트 URL을 마스킹하기 위해 URL을 재작성합니다.

Apigee Edge에는 지원되는 언어별로 JavaScript 정책, Java 콜아웃 정책, Python 스크립트 정책의 별도 정책이 포함되어 있습니다.

오류 처리

Apigee를 사용하면 RaiseFault 유형의 정책을 사용하여 맞춤 예외 처리를 실행할 수 있습니다. 메시지 할당 정책의 변형인 오류 제기 정책을 사용하면 오류 조건에 따라 커스텀 오류 응답을 생성할 수 있습니다.

공유 흐름

공유 흐름은 오류 메시지의 표준화를 적용하는 데 사용할 수 있습니다. 예를 들어 백엔드에서 특정 HTTP 오류 코드를 감지하는 동일한 구성된 정책을 사용하여 오류 응답을 재작성하여 일반 오류 메시지를 반환할 수 있습니다.

API4:2019 리소스 부족 및 비율 제한

위협 설명

비율 제한 정책을 구현하지 않으면 공격자가 서비스 거부 공격으로 백엔드를 과도하게 사용하게 될 수 있습니다.

이 위협은 다음 Apigee 기능을 사용하여 쉽게 해결할 수 있습니다.

  • 인바운드 API 요청에 트래픽 제한을 적용하는 예방 조치로 할당량 및 급증 저지 정책
  • 봇 기반 공격을 동적으로 감지하고 대응하는 Apigee Sense
  • 진행 중인 DDoS 공격에 대한 알림을 받을 수 있는 탐지 통제 기능으로 고급 API 모니터링 및 알림

할당량 및 급증 저지 정책을 사용한 비율 제한

Apigee는 비율 제한에 관한 두 가지 정책을 제공합니다.

  • 급증 저지는 백엔드로 들어오는 전체 요청 수를 제한하는 속도에 관한 API 프록시 수준에서 정의된 일반적인 정책을 제공합니다.
  • 할당량은 API 프록시 또는 API 제품 수준에서 할당량 정책을 적용하기 위한 세분화된 정책 도구를 제공합니다.

급증 저지

Spike Arrest 정책은 트래픽 급증으로부터 보호합니다. 이 정책은 API 프록시에서 처리하고 백엔드로 전송되는 요청 수를 제한하여 성능 지연 및 다운타임으로부터 보호합니다. 정책 내에서 정의할 수 있는 롤링 평균 값을 사용합니다.

할당량

할당량 정책을 사용하면 1분, 1시간, 1일, 1주, 1개월 등의 기간 동안 API 프록시에서 허용하는 요청 메시지 수를 구성할 수 있습니다. API 프록시에 액세스하는 모든 앱에서 할당량을 동일하게 설정하거나 다음을 기준으로 할당량을 설정할 수 있습니다.

  • API 프록시가 포함된 제품
  • API를 요청하는 앱
  • 앱 개발자
  • 기타 여러 기준

이 정책은 급증 저지보다 세분화되어 있으며 일반적으로 급증 저지와 동시에 사용해야 합니다.

Apigee Sense를 사용한 봇 감지

Apigee Sense를 사용하면 악의적이거나 의심스러운 동작을 보이는 클라이언트 또는 위치를 기반으로 특정 클라이언트, IP 범위 또는 자율 시스템 조직의 요청을 명시적으로 허용, 차단 또는 신고하는 작업을 수행할 수 있습니다. Apigee Edge는 API 프록시에서 요청을 처리하기 전에 요청에 이러한 작업을 적용합니다. 예를 들어 '무차별 대입' 동작을 보이는 IP 범위 또는 특정 클라이언트를 감지한 후 차단하거나 신고할 수 있습니다.

고급 API 운영 모니터링을 통한 위협 감지

트래픽 알림을 사용하여 환경, 프록시 또는 지역의 트래픽이 일정 기간에 지정된 비율만큼 변경되면 알림을 표시합니다. 이 기능은 DDoS 공격과 같이 트래픽이 예상 처리량에서 크게 벗어날 때 동적으로 알림을 보낼 수 있습니다. 이러한 알림은 서드 파티 로깅 및 모니터링 솔루션으로 쉽게 전송할 수 있습니다.

API5:2019 손상된 함수 수준 승인

위협 설명

이 위협은 API1의 변형이며 승인 취약점입니다. 이 위협을 통해 공격자는 액세스 권한이 없는 함수에 요청을 전송하여 작업을 실행할 수 있습니다. 예를 들어 API 엔드포인트가 HTTP 요청 동사를 검증하지 않는 경우 공격자는 GET을 PUT 또는 DELETE로 대체하여 읽기 권한만 있는 데이터를 수정하거나 삭제할 수 있습니다. 또는 API 리소스 URI 경로에 충분히 제한적인 액세스 제어를 구현하지 않으면 API 엔드포인트로 인해 공격자가 요청의 경로를 변경하여 다른 사용자의 데이터를 볼 수 있습니다.

이러한 유형의 위협은 Apigee를 미디에이션 및 추상화 레이어로 사용하는 가치를 강조합니다. 공개 액세스를 위해 설계되지 않은 많은 백엔드 시스템은 기본적으로 위험도가 높은 관리 기능을 포함하여 여러 비즈니스 로직 함수를 실행하기 위한 단일 엔드포인트를 제공할 수 있기 때문입니다.

이러한 위협의 가능성을 줄이기 위한 개념적 요소는 일반적으로 다음과 같이 분류됩니다.

  • 보호되는 항목은 무엇인가요? API 제품 전략을 고려하고 RESTful 권장사항을 사용하여 Apigee API 프록시, 제품, 앱 기능에서 노출되는 경로와 리소스를 설계할 때 기능의 논리적 세분화를 구현합니다.
  • API 리소스에 액세스하는 사용자는 누구인가요? API1 및 API2에 설명된 대로 Apigee의 인증 및 승인 기능 중 일부를 사용하여 대략적인 사용자 역할을 정의하고 '최소 권한' 기본 액세스 사용 권한을 구현합니다.
  • 액세스 정책은 어떻게 시행되나요? 조건부 흐름 및 오류를 사용하여 모든 API 요청의 URL 경로와 동사를 유효성 검사합니다.

그림: 이 다이어그램은 액세스 토큰 내에 제공된 범위를 사용 권한으로 사용하여 Apigee에서 기능 수준 승인을 적용하는 방법을 보여줍니다.

API 프록시, 제품, 앱을 사용한 논리적 세분화

Apigee는 API 리소스의 논리적 세분화를 지원하는 매우 유연한 툴킷을 제공하므로 API 프록시를 원하는 수만큼 API 제품으로 번들로 묶을 수 있습니다. 이러한 API 제품은 앱 개발자가 사용하며, 앱 개발자는 API 제품을 사용하는 앱을 등록할 수 있습니다. 액세스 정책은 이러한 수준 중 어느 수준에서든 정의할 수 있습니다.

하지만 효과적인 기능 승인 및 세분화를 구현하려면 API 제품 전략을 정의하는 것이 중요합니다. 이 필수적이고 지속적인 프로세스의 일부는 고객 및 개발자의 관점에서 API 리소스를 살펴본 다음 경로 리소스 및 HTTP 동사 수준까지 허용되는 요청 유형을 정확하게 정의하여 API 제품의 '누가'와 '무엇'을 정의하는 것입니다.

그림: API 제품에 번들로 포함된 API 리소스는 하나 이상의 API에서 가져올 수 있으므로 리소스를 혼합하고 일치시켜서 소비 등급 및 승인 경계를 만들 수 있습니다.

OAuth 범위 및 JWT 클레임을 사용한 함수 수준 액세스 제어

API1:2019 손상된 객체 승인에 대해 위에서 고려한 승인 접근 방식은 객체 수준에서 세분화된 액세스 제어를 처리하지만 함수 수준에서 대략적인 액세스 제어를 처리하는 것도 마찬가지로 중요합니다. 요청하는 사용자가 이 URL 경로를 요청할 권한이 있나요? 이러한 유형의 정책은 사용자 캐릭터 (고객, 직원, 관리자, 내부 또는 서드 파티 개발자)별로 정의되는 경우가 많습니다.

구성 오류의 위험을 줄이려면 보안팀과 협력하여 요청 사용자에 관한 어설션이 OAuth 범위 또는 JWT 클레임을 사용하여 액세스 토큰 내에 포함되도록 하는 것이 좋습니다.

조건부 흐름을 사용하여 요청 유효성 검사

기본적으로 REST API 호출은 다음으로 구성됩니다.

  • 엔드포인트
  • 리소스
  • 동사
  • 쿼리 매개변수와 같은 추가 요청 속성(갯수 제한 없음)

이 위협에 설명된 공격 유형은 일반적으로 API 요청의 필터링이 불충분하여 발생하므로 공격자가 승인되지 않은 작업을 실행하거나 보호된 리소스에 액세스할 수 있습니다. Apigee는 액세스 토큰 또는 클레임을 기반으로 요청을 필터링할 수 있는 조건부 로직 외에도 요청 자체를 기반으로 필터링 로직을 구현할 수 있도록 허용합니다.

API 제품의 비즈니스 로직, 즉 API에서 허용하는 기능을 명확하게 이해하고 정의한 후에는 다음 Apigee 제품 기능을 통해 이 범위에 해당하지 않는 요청을 제한해야 합니다.

  • 프록시 흐름 구성의 모든 단계에서 리소스 경로 또는 동사를 제한하는 조건부 로직 및 Raise Fault 정책
  • 잘못된 형식의 JSON 또는 XML 요청 페이로드를 사용하는 콘텐츠 기반 공격으로부터 보호하기 위한 JSON 및 XML 위협 보호 정책

API6:2019 일괄 할당

위협 설명

API를 통해 클라이언트 앱에 필터링되지 않은 데이터가 제공되면 공격자가 요청을 통해 객체 속성을 추측하거나 엔드포인트 이름 지정 규칙을 사용하여 백엔드에 저장된 데이터 객체의 속성을 무단으로 수정하거나 액세스할 위치에 대한 단서를 얻을 수 있습니다.

이 위협은 필터링되지 않은 데이터 (일반적으로 JSON 또는 XML)가 클라이언트로 전송되어 공격자가 백엔드 시스템의 기본 구현 세부정보와 기밀 데이터 요소의 속성 이름을 추측할 수 있게 될 때 발생합니다. 이러한 유형의 공격의 결과로 공격자가 부적절한 데이터를 읽거나 조작할 수 있게 되거나 최악의 경우 원격 코드 실행 취약점이 발생할 수 있습니다.

일반적으로 이러한 유형의 위협을 허용하는 데는 두 가지 측면이 있습니다.

  • API 설계 관점 앱이 공격자에 의해 악용되어 신뢰할 수 있는 것으로 간주될 수 있으므로 애플리케이션 로직을 사용하여 클라이언트 측 데이터 필터링을 수행하지 마세요. 항상 API 서비스를 사용 설정하는 데 필요한 최소한의 데이터만 노출하도록 API 데이터 스키마를 설계합니다.
  • API 구현 관점 데이터 필터링 및 스키마 유효성 검사를 구현하여 기밀 데이터가 클라이언트 애플리케이션에 실수로 노출되는 것을 방지합니다.

Apigee 제품 관점에서 Google은 API의 강력한 데이터 필터링 구현을 보장하기 위한 몇 가지 유용한 기능을 제공합니다.

OpenAPI 사양 필터링 정책

OASValidation (OpenAPI 사양 유효성 검사) 정책을 사용하면 OpenAPI 3.0 사양 (JSON 또는 YAML)에 대한 수신 요청 또는 응답 메시지의 유효성을 검사할 수 있습니다. 이 정책을 사용하면 다음 작업을 할 수 있습니다.

  1. OpenAPI 사양 (OAS)을 만들어 API 설계
  2. Apigee를 사용하여 백엔드에서 API 제품을 안전하게 노출하기 위한 필요한 미디에이션, 보안, 캐싱 로직을 구현합니다.
  3. basepath, verb, request message policy, parameters를 비롯하여 OAS 사양에 정의된 데이터 스키마에 대해 수신 요청을 검사합니다.

SOAP 메시지 유효성 검사 정책

SOAP 메시지 유효성 검사 정책을 사용하면 XSD 스키마에 대해 XML 메시지를 검증하거나 WSDL 정의에 대해 SOAP 메시지를 검증하여 XML 기반 요청의 유효성을 검사할 수 있습니다. 또한 메시지 유효성 검사 정책을 사용하여 JSON 또는 XML 메시지 페이로드가 올바른 형식인지 확인할 수 있습니다. 여기에는 XML 또는 JSON 메시지에서 다음을 확인하는 것이 포함됩니다.

  • 단일 루트 요소가 있습니다.
  • 콘텐츠에 유효하지 않은 문자가 없습니다.
  • 객체와 태그가 올바르게 중첩됩니다.
  • 시작 및 종료 태그가 일치합니다.

API7:2019 보안 구성 오류

위협 설명

보안 구성 오류는 일반적으로 안전하지 않은 기본 구성, 불완전하거나 임시 구성, 개방형 클라우드 스토리지, 잘못 구성된 HTTP 헤더, 불필요한 HTTP 메서드, 관대한 교차 출처 리소스 공유 (CORS), 민감한 정보가 포함된 상세 오류 메시지로 인해 발생합니다. 공격자는 패치되지 않은 결함, 일반적인 엔드포인트 또는 보호되지 않은 파일 및 디렉터리를 찾아 공격하려는 시스템에 대한 무단 액세스 권한을 얻거나 정보를 얻으려고 시도합니다. 보안 구성을 잘못하면 민감한 사용자 데이터가 노출될 뿐만 아니라 전체 서버가 손상될 수 있는 시스템 세부정보도 노출될 수 있습니다. 또한 보안 구성 오류의 취약점의 다른 사용 사례에는 다음이 포함될 수 있습니다.

  • TLS 구성 오류
  • 스택 트레이스가 포함된 오류 메시지
  • 패치되지 않은 시스템
  • 노출된 저장소 또는 서버 관리 패널

조직은 보안 구성 오류와 관련된 문제를 해결하고 완화하기 위해 다음과 같은 다양한 조치를 취할 수 있습니다.

  1. 강화 및 패치 프로세스 수립 및 표준화
  2. API 생태계 관련 거버넌스 개발
  3. 관리 액세스 제한 및 감사 및 알림 사용 설정

공유 흐름 및 흐름 후크

Apigee는 API 개발자가 정책 및 리소스를 재사용 가능한 그룹으로 결합할 수 있는 공유 흐름 개념을 지원합니다. 공유 흐름을 사용하면 재사용 가능한 기능을 하나의 위치에 캡처함으로써, 일관성을 보장하고, 개발 시간을 단축시키고, 코드를 보다 쉽게 관리할 수 있습니다. 개별 API 프록시 내부에 공유 흐름을 포함하거나 한 단계 더 나아가 흐름 후크에 공유 흐름을 배치하여 공유 흐름과 동일한 환경에 배포된 모든 API 프록시에 대해 공유 흐름 로직을 자동으로 실행할 수 있습니다.

API 보안 보고

조직이 거버넌스 프레임워크를 개발하기 위해 노력하는 가운데 Apigee는 API 보안 보고와 관련된 기능을 제공하여 운영팀이 다음과 같은 작업을 할 수 있도록 API의 보안 속성을 확인할 수 있도록 지원합니다.

  • 보안 정책 및 구성 요구사항 준수 보장
  • 내부 및 외부 악용으로부터 민감한 정보 보호
  • 보안 사고를 선제적으로 식별, 진단, 해결

Apigee 보안 보고는 운영팀이 정책 및 구성 요구사항을 준수하고, 내부 및 외부 악용으로부터 API를 보호하고, 보안 문제를 신속하게 파악하고 해결할 수 있도록 심층적인 통계를 제공합니다.

보안 보고를 통해 보안 관리자는 API 프록시가 보안을 위해 구성된 방식과 프록시 보안에 영향을 줄 수 있는 런타임 조건을 빠르게 파악할 수 있습니다. 이 정보를 사용하여 각 프록시에 적절한 수준의 보안을 적용하도록 구성을 조정할 수 있습니다.

API 모니터링

Apigee는 보안 보고 기능을 보완하는 포괄적인 API 모니터링 플랫폼을 제공합니다. API 모니터링을 사용하면 조직에서 API 트래픽 및 성능 문제를 사전에 감지할 수 있습니다. Apigee API Monitoring은 Apigee Edge for Public Cloud와 함께 작동하여 API 성능에 대한 실시간 상황별 정보를 제공하고, 문제를 빠르게 진단하고, 비즈니스 연속성을 위한 구제 조치를 용이하게 합니다.

그림: Apigee API 모니터링은 문제를 모니터링, 조사, 처리하는 다양한 도구를 제공합니다. Google Cloud Platform의 동급 최고의 인텔리전스 기능을 활용합니다.

Apigee Sense

Apigee Sense는 악의적인 클라이언트의 공격을 비롯한 원치 않는 요청 트래픽으로부터 API를 보호하는 데 도움이 됩니다. Apigee Sense는 API 요청 트래픽을 분석하여 원치 않는 요청을 나타낼 수 있는 패턴을 식별합니다.

조직은 이 분석을 사용하여 원치 않는 요청을 하는 클라이언트를 식별한 후 이러한 요청을 허용, 차단 또는 신고하는 조치를 취할 수 있습니다. Apigee Sense를 사용하면 다음과 같은 요청 패턴으로부터 API를 보호할 수 있습니다.

  • 인간의 행동과 조화를 이루는 자동화된 행동
  • 동일한 IP에서 지속적으로 시도함
  • 비정상적인 오류율
  • 의심스러운 클라이언트 요청
  • 데이터 크롤링
  • 키 수집
  • 활동 급증
  • 지역적 패턴

API8:2019 삽입

위협 설명

SQL, NoSQL, XML 파서, ORM, LDAP, OS 명령어, JavaScript와 같은 데이터를 API 요청에 신뢰할 수 없는 방식으로 삽입하면 의도하지 않은 명령어 실행 또는 승인되지 않은 데이터 액세스가 발생할 수 있습니다. 공격자는 직접 입력, 매개변수, 통합 서비스 등 사용 가능한 모든 삽입 벡터를 통해 API에 악성 데이터를 제공하고 인터프리터로 전송되기를 기대합니다. 공격자는 취약점 스캐너와 퍼저를 사용하여 소스 코드를 검토할 때 이러한 결함을 쉽게 발견할 수 있습니다. 삽입에 성공하면 기밀 유지 및 데이터 손실에 영향을 미치는 정보가 공개되거나 경우에 따라 DoS가 발생할 수도 있습니다.

삽입 오류/공격을 완화하기 위한 권장사항에는 스키마, 유형, 문자열 패턴과 같은 입력 데이터를 엄격하게 정의하고, 입력 유효성 검사를 실행하고, 제한 검사를 실행하고, 런타임에 이를 적용하는 것이 포함됩니다. Apigee 플랫폼을 사용하면 필터를 사용하여 수신 데이터를 검증하여 각 입력 매개변수의 유효한 값만 허용할 수 있습니다.

수신되는 API 요청의 서버 역할을 하는 Apigee Edge는 페이로드 구조가 허용되는 범위(한도 검사라고도 함) 내에 있는지 확인합니다. 입력 검증 루틴이 입력을 변환하여 위험한 문자 시퀀스를 삭제하고 안전한 값으로 바꾸도록 API 프록시를 구성할 수 있습니다.

정규 표현식 보호 정책

RegularExpressionProtection 정책은 메시지 (예: URI 경로, 쿼리 매개변수, 헤더, 양식 매개변수, 변수, XML 페이로드 또는 JSON 페이로드)에서 정보를 추출하고 사전 정의된 정규 표현식에 따라 해당 콘텐츠를 평가합니다. 지정된 정규 표현식이 true로 평가되면 메시지가 위협으로 간주되어 거부됩니다. 정규 표현식(줄여서 정규식)은 문자열의 패턴을 지정하는 문자열 집합입니다. 정규식을 사용하면 콘텐츠의 패턴을 프로그래매틱 방식으로 평가할 수 있습니다. 예를 들어 이메일 주소가 올바르게 구조화되어 있는지 평가하는 등의 용도로 정규 표현식을 사용할 수 있습니다.

RegularExpressionProtection의 가장 일반적인 용도는 JSON 및 XML 페이로드의 악성 콘텐츠를 평가하는 것입니다.

정규 표현식으로 모든 콘텐츠 기반 공격을 제거할 수 없으며, 심층 방어를 위해 여러 메커니즘을 결합해야 합니다. 이 섹션에서는 콘텐츠 액세스를 차단하는 데 권장되는 몇 가지 패턴을 설명합니다.

Apigee 플랫폼에서 입력을 검증하는 데 사용할 수 있는 다른 접근 방식에는 다음이 있습니다.

콘텐츠 유형 검사

콘텐츠 유형은 HTTP를 통해 전송되고 두 부분으로 구성된 구조에 따라 분류되는 파일의 콘텐츠를 의미합니다. Apigee에서는 아래에 설명된 대로 조건부 로직을 사용하여 요청 및 응답의 콘텐츠 유형을 검사하는 것이 좋습니다.

API 보안 보고

조직이 거버넌스 프레임워크를 개발하기 위해 노력하는 가운데 Apigee는 API 보안 보고와 관련된 기능을 제공합니다. 이 기능은 운영팀이 다음과 같은 작업을 할 수 있도록 API의 보안 속성에 대한 가시성을 제공하여 API를 보호하는 데 필요한 지원을 제공합니다.

  • 보안 정책 및 구성 요구사항 준수 여부 확인
  • 내부 및 외부 악용으로부터 민감한 정보 보호
  • 보안 사고를 사전에 식별, 진단, 해결합니다.

API9:2019 부적절한 확장 소재 관리

위협 설명

환경 관리 및 환경 분리가 충분하지 않으면 공격자가 보안이 취약한 API 엔드포인트에 액세스할 수 있습니다. 거버넌스 보호 수단이 부족하면 지원 중단된 리소스가 불필요하게 노출되기도 합니다.

이 위협은 Apigee의 성숙한 기능을 활용하여 전체 API 수명 주기를 관리함으로써 해결할 수 있습니다. 이를 통해 팀 간의 공동작업을 지원하는 포괄적인 거버넌스 모델을 만들고 동시에 보안 이해관계자와 API 개발자 간에 책임 분리를 적용할 수 있습니다. 경계 및 컨트롤은 다음을 사용하여 구성하고 유지할 수 있습니다.

조직, 환경, 버전: 런타임 컨텍스트를 통해 격리 및 보안 프로모션 프로세스를 보장하는 가상 및 실제 가드레일입니다.

역할 기반 액세스 제어: API팀의 필요한 사용자만 구성 변경사항과 승격 프로세스를 관리할 수 있는 권한을 갖습니다.

API 문서의 잠재고객 관리: API가 개발자 포털에 게시되면 타겟 잠재고객을 관리하여 문서의 공개 상태를 제한할 수 있습니다.

흐름 후크: API 개발자가 수정할 수 없는 권한이 있는 가드레일로 관리할 수 있는 글로벌 정책 및 패턴을 시행할 수 있습니다.

보안 보고: 보안 이해관계자는 게시된 API와 이를 지원하는 구성을 처음부터 끝까지 확인할 수 있습니다. 게시된 각 API 엔드포인트의 위험 프로필을 기반으로 전 세계 보안 정책 준수 여부를 감사하고 평가할 수 있습니다.

조직 및 환경

Apigee의 구성 아티팩트, 사용자, 기능은 특정 조직 또는 환경으로 범위를 지정할 수 있습니다. 즉, 플랫폼에는 API와 이를 지원하는 구성 주위에 배치할 수 있는 사전 빌드된 가드레일이 있습니다.

조직: 조직은 Apigee의 최상위 테넌트입니다. 이를 통해 트래픽, 구성, 사용자를 완전히 분리할 수 있습니다. 거버넌스 권장사항에 따라 프로덕션 조직과 비프로덕션 조직을 별도로 두는 것이 좋습니다. 이렇게 하면 프로덕션 데이터, 사용자, 트래픽이 하위 환경과 혼합되는 것을 효과적으로 방지할 수 있습니다.

환경: Apigee의 API는 여러 배포 상태를 통해 승격될 수 있습니다. 각 상태는 실행 컨텍스트에 연결됩니다. 프로모션 프로세스 중에 환경 컨텍스트가 전달되지 않으므로 권한이 없는 사용자에게 민감한 구성이 노출되지 않습니다.

버전: 버전을 사용하면 API와 개별 기능을 환경을 통해 원활하게 프로모션할 수 있습니다.

역할 기반 액세스 제어

API9를 완화하려면 보안 이해관계자와 API 개발자 간에 역할이 명확하게 정의되고 분리되어야 합니다. 이 문서에서 이전에 설명한 것처럼 Apigee에는 맞춤 역할에 권한을 할당할 수 있는 유연한 역할 기반 액세스 제어 기능이 있습니다. 이러한 특정 위협의 경우 조직, 환경 또는 더 세분화된 구성 권한별로 제한된 권한을 갖도록 역할 범위를 지정할 수 있습니다. 권장되는 방법은 환경을 통해 API의 배포 상태를 변경하고 개발자가 전역 보안 라이브러리 (흐름 후크)에 액세스하거나 수정할 수 없도록 하는 권한을 제한하는 것입니다. 이러한 제한된 역할은 기존 및 현재 게시된 엔드포인트 모두에 광범위하게 적용되는 전 세계 보안 정책을 요청하지 않고 변경하는 것을 방지합니다.

API 문서의 잠재고객 관리

개발자 포털은 API 전략을 성공적으로 수행하는 데 중요한 구성요소입니다. 개발자 포털을 사용하면 호스트/엔드포인트, 리소스, 작업, 페이로드 스키마 등 API와 관련된 모든 문서의 포괄적인 인벤토리를 유지할 수 있습니다. Apigee에서는 API 제품 구성을 사용하여 API를 그룹화할 수 있습니다. API 제품은 동일한 비즈니스 및 보안 컨텍스트 (예: 서비스 요금제, 비즈니스 도메인, 카테고리, 회사 계층 구조 등)에 속하는 리소스 및 작업 번들로 정의됩니다.

Apigee의 통합 개발자 포털을 사용하면 타겟 잠재고객을 관리하여 API 제품을 게시하고 게시된 콘텐츠의 공개 상태를 제한할 수 있습니다. 이 기능은 비즈니스 및 보안 요구사항에 부합하는 콘텐츠 세분화 전략을 준수합니다.

흐름 후크

API의 프로모션 및 출시 프로세스에는 항상 보안 규정 준수 및 인증 프로세스가 포함되어야 합니다. 효과적으로 운영하려면 적절한 도구를 사용하는 API팀이 책임 분리를 보장하고 민첩한 출시 주기를 유지하면서 가드레일을 만들 수 있어야 합니다.

Apigee를 사용하면 흐름 후크를 통해 전역 정책을 시행하여 보안 거버넌스 업무를 개선할 수 있습니다. 이러한 전역 정책은 API 개발자가 수정할 수 없는 권한이 있는 가드레일로 관리할 수 있으므로 책임 분리를 보장하고 기본 보안을 적용하여 민첩성을 높이며 더 나아가 특정 실행 환경에 배포된 모든 API에 보안 규정을 준수하도록 할 수 있습니다.

그림: Apigee에서 흐름 후크 및 공유 흐름을 통해 권한 가드레일을 구성할 수 있습니다. 보안 이해관계자는 보안 관련 글로벌 정책을 유지 관리할 책임이 있습니다. 이러한 기능은 책임 분리를 보장하고 민첩한 개발 수명 주기를 촉진합니다.

보안 보고

보안 감사는 조직의 데이터와 비즈니스 목표를 보호하기 위한 보안 정책을 평가하고 테스트하기 위한 것입니다. API는 포괄적이고 동시에 감사 가능한 보안 거버넌스 모델로 보호되어야 하는 표준화된 공개 또는 비공개 인터페이스입니다.

Apigee에서는 정의된 정책을 준수하고 보안팀이 다음에 관한 포괄적인 통계를 기반으로 조치를 취할 수 있도록 지원하는 전문 보안 보고서에 액세스할 수 있습니다.

런타임 트래픽: 대상 서버, 가상 호스트, TLS 구성, 환경별 트래픽 변경사항 등에 관한 API 트래픽 통계를 한곳에서 확인할 수 있습니다.

구성: API 프록시 구성의 감사 기능으로, API 프록시 수준에서 시행되는 모든 정책과 조직 또는 프록시 수준에서 연결된 공유 흐름의 시행 스펙트럼을 종단 간으로 확인할 수 있습니다.

사용자 활동: 플랫폼 사용자가 수행하는 민감한 작업을 추적합니다. 의심스러운 활동을 드릴다운하여 분석합니다.

API10:2019 로깅 및 모니터링 부족

위협 설명

로깅, 모니터링, 알림이 충분하지 않으면 진행 중인 공격을 감지하지 못할 수 있으므로 비즈니스에 영향을 미치는 중요한 이벤트에 대한 통계를 얻기 위한 전략이 필요합니다.

API의 이벤트 및 로깅 관리 전략은 다음 권장사항을 고려해야 합니다.

  • 로그 관리 정책: 로그 상세 수준, 로그 수준, 로그 무결성, 중앙 집중식 저장소 등을 표준화하고 제어하기 위한 규칙을 문서화하고 시행합니다.
  • 이벤트 관리 정책: 모든 이벤트가 소스까지 추적 가능해야 합니다. 또한 이벤트를 중요도 및 비즈니스 영향에 따라 분류할 수 있어야 합니다.
  • 보고서 및 감사: 보안 및 운영 이해관계자는 실시간으로 로그 및 이벤트에 액세스하고 이에 대응할 수 있어야 합니다. 또한 이해관계자가 이전 데이터를 기반으로 감지 패턴을 조정하기 위해 강화 주기를 실행할 수 있습니다.

Apigee는 포괄적인 이벤트 및 로깅 관리 전략을 만드는 데 필요한 도구를 제공합니다. 이러한 도구는 다음과 같습니다.

메시지 로깅 정책: API 트래픽의 트래픽 데이터 또는 메타데이터를 기반으로 로그 스트림을 만듭니다. 조건부 로직과 메시지 템플릿을 활용하여 스트림 상세 수준을 유연하게 결정할 수 있습니다.

Google의 Cloud Operation Suite: Google의 확장성이 뛰어난 모니터링 및 로깅 도구에 즉시 통합할 수 있습니다.

서비스 콜아웃 정책: 이벤트를 전송하는 데 HTTP 엔드포인트가 필요한 로그 스트림에 대한 지원을 추가합니다.

분석: 기본 제공 또는 맞춤 보고서를 통해 이전 트래픽 메타데이터에 액세스하고 분석합니다. 동향에 따라 알림을 만들고 관리하며 트래픽 이상치를 파악하세요.

API 모니터링: 앞에서 설명한 대로 이 도구는 중요한 이벤트를 기반으로 트리거할 수 있는 알림 기능을 제공합니다. 트래픽 로그를 추가로 분석하고 조치를 취할 수 있습니다.