이 페이지는 Cloud Translation API를 통해 번역되었습니다.

OWASP 상위 10개 API 위협

현재 Apigee Edge 문서가 표시되고 있습니다.
Apigee X 문서로 이동 정보

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

소개

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

이 문서에서는 OWASP의 2019년 10대 API 보안 위협에서 식별한 일반적인 API 기반 공격으로부터 보호하는 방법을 설명합니다. 최신 목록에서 강조된 주요 위협의 공통 주제는 인증 및 승인 제어의 부적절한 배치(예: 클라이언트 앱 내에서 API 요청이 반환한 데이터 필터링에 의존함)가 소비 클라이언트 앱에 의존하여 액세스 제어 적용을 수행하는 안티패턴을 사용하기 때문에 발생합니다.

API 생태계가 빠른 속도로 성장하고 있는 가운데, 공격자에 의한 데이터 무단 반출을 초래하는 API 악용 및 오용은 오늘날 가장 일반적인 공격 벡터 중 하나가 되고 있습니다. 보안 보고 및 이상 감지 기능이 포함된 고급 API 작업과 같은 여러 가지 새로운 기능이 도입되면서 보안은 Apigee의 핵심 우선순위로 여겨지고 있습니다. 하지만 API에 대한 공격이 성공할 가능성을 줄이려면 Apigee의 보안 기능을 올바르게 설계하고 구현하는 것이 중요합니다.

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

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

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

위협 설명

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

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

Apigee 구현 관점에서 고려해야 할 두 가지 주요 측면이 있습니다.

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

액세스 토큰 무결성

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

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

OAuth 2.0 프레임워크를 사용할 때의 액세스 토큰, 갱신 토큰 또는 응답 흐름 토큰(공격자가 액세스 토큰을 캡처하지 못하도록 PKCE를 사용한 클라이언트 챌린지 사용 포함)
OpenID Connect 1.0 JSON 웹 토큰 및 JSON 웹 서명
SAML 어설션 확인
API 키 확인
키 해시 메시지 인증 코드 (HMAC) 인증

액세스 제어 적용

액세스 토큰의 유효성이 확인된 후에는 액세스 제어 시행 정책을 구현하여 각 수신 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에는 OAuth 흐름을 더 잘 이해할 수 있는 eBook, 웹캐스트, 구현 예 등 다양한 추가 리소스가 있습니다.

인증 정책

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

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

트래픽 관리

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

Spike Arrest 정책 - API 프록시의 전체 이동 평균 비율 한도를 설정합니다.
할당량 정책: 앱 키, 개발자 또는 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는 봇과 유사한 위협을 감지하고 이에 대응하도록 특별히 설계되었지만, Advanced API Ops에는 이상 감지 및 고급 알림 정의가 모두 포함되어 있습니다.

이상 감지는 이전 API 데이터에 인공지능 (AI) 및 머신러닝 (ML) 모델을 적용하는 방식으로 작동합니다. 그러면 이상 감지를 통해 생산성을 향상하고 API 문제의 평균 해결 시간 (MTTR)을 단축하기 위해 생각조차 하지 못한 시나리오에 대해 실시간으로 알림을 받을 수 있습니다.

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

총 교통정보 알림. 일정 기간 동안 트래픽이 지정된 비율만큼 변경되면 알림을 보냅니다. 예를 들어 트래픽이 1시간 동안 5% 이상 증가하거나 1주일 동안 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는 세 가지 주요 정책을 사용합니다.

메시지 할당
코드 콜아웃
결함 처리

메시지 할당 정책

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

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

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

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

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

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

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

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

오류 처리

Apigee를 사용하면 Raise Fault 유형의 정책을 사용해 커스텀 예외 처리를 수행할 수 있습니다. 메시지 할당 정책의 변형인 오류 발생 정책을 사용하면 오류 조건에 대한 응답으로 커스텀 오류 응답을 생성할 수 있습니다.

공유 흐름

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

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

위협 설명

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

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

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

할당량 및 급증 체포 정책을 통한 비율 제한

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

Spike arrest는 백엔드에 대한 전체 인바운드 요청 수를 제한하는 비율을 위한 일반 정책(API 프록시 수준에서 정의됨)을 제공합니다.
할당량은 API 프록시 또는 API 제품 수준에서 할당량 정책을 시행하기 위한 세분화된 정책 도구를 제공합니다.

급증 저지

급증 체포 정책은 교통체증을 방지합니다. 이 정책은 API 프록시에서 처리되고 백엔드로 전송되는 요청 수를 제한하여 정책 내에서 정의 가능한 이동 평균 값을 사용해 성능 지연과 다운타임을 방지합니다.

할당량

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

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

이 정책은 스파이크 체포보다 더 세부적이며 일반적으로 이 정책과 함께 사용해야 합니다.

Apigee Sense를 사용한 봇 감지

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

고급 API 운영 모니터링으로 위협 감지

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

API5:2019 함수 수준 승인이 손상됨

위협 설명

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

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

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

무엇이 보호되고 있나요? Apigee API 프록시, 제품, 앱 기능에서 노출되는 경로와 리소스를 설계하는 RESTful 권장사항에 따라 API 제품 전략을 생각해 보고 기능의 논리적 세분화를 구현하세요.
API 리소스에 누가 액세스하나요? API1 및 API2에 설명된 대로 Apigee의 인증 및 승인 기능을 사용하여 상위 수준의 캐릭터를 정의하고 '최소 권한' 기본 액세스 사용 권한을 구현합니다.
액세스 정책이 어떻게 시행되고 있나요? 조건부 흐름과 오류를 사용하여 모든 API 요청의 URL 경로와 동사를 검증합니다.

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

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

Apigee는 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 제품 기능을 통해 여기에 포함되지 않는 모든 요청을 제한하는 것입니다.

조건부 로직 및 오류 발생 정책을 통해 프록시 흐름 구성의 모든 단계에서 리소스 경로나 동사를 제한합니다.
JSON 및 XML 위협 방지 정책으로 잘못된 형식의 JSON 또는 XML 요청 페이로드를 사용하여 콘텐츠 기반 공격으로부터 보호합니다.

API6:2019 대량 할당

위협 설명

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

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

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

API 디자인 관점. 클라이언트 측 데이터 필터링을 위해 애플리케이션 로직에 의존하지 마세요. 앱은 공격자에 의해 악용되거나 신뢰할 수 있는 앱으로 간주될 수 있습니다. API 서비스를 사용 설정하는 데 필요한 최소한의 데이터만 노출하도록 API 데이터 스키마를 설계하세요.
API 구현 관점: 기밀 데이터가 실수로 클라이언트 애플리케이션에 노출되지 않도록 데이터 필터링 및 스키마 검증을 구현하세요.

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

OpenAPI 사양 필터링 정책

OASValidation (OpenAPI 사양 유효성 검사) 정책을 사용하면 OpenAPI 3.0 사양 (JSON 또는 YAML)을 기준으로 수신 요청 또는 응답 메시지를 검증할 수 있습니다. 이 정책을 통해 다음을 할 수 있습니다.

OpenAPI 사양 (OAS)을 만들어 API 설계
Apigee를 통해 백엔드에서 API 제품을 안전하게 노출하는 데 필요한 미디에이션, 보안, 캐싱 로직을 구현합니다.
basepath, verb, 요청 메시지 정책, 매개변수 등 OAS 사양에 정의된 데이터 스키마를 기준으로 수신 요청의 유효성을 검사합니다.

SOAP 메시지 유효성 검사 정책

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

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

API7:2019 보안 구성 오류

위협 설명

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

잘못 구성된 TLS
스택 트레이스 관련 오류 메시지
패치가 적용되지 않은 시스템
노출된 스토리지 또는 서버 관리 패널

다음과 같이 잘못된 보안 구성과 관련된 문제를 해결하고 완화하기 위해 조직이 취할 수 있는 다양한 조치가 있습니다.

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

공유 흐름 및 흐름 후크

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

API 보안 보고

조직에서 거버넌스 프레임워크를 개발하려는 동안 Apigee에서 제공하는 API 보안 보고 관련 기능을 사용하면 운영팀이 API의 보안 속성이 필요한 이유를 파악할 수 있습니다.

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

Apigee 보안 보고는 운영팀에 심층적인 통계를 제공하여 정책 및 구성 요구사항 준수를 보장하고, 내부 및 외부 악용으로부터 API를 보호하며, 보안 이슈를 신속하게 식별하고 해결합니다.

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

API 모니터링

Apigee는 보안 보고 기능을 보완하는 포괄적인 API 모니터링 플랫폼을 제공합니다. 조직은 API 모니터링을 통해 API 트래픽 및 성능 문제를 사전에 감지할 수 있습니다. Apigee API Monitoring은 퍼블릭 클라우드용 Apigee Edge와 함께 작동하여 API 성능에 대한 실시간 상황별 통계를 제공하고 문제를 신속하게 진단하고 비즈니스 연속성을 위한 시정 조치를 지원합니다.

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

Apigee Sense

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

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

인간 행동과 혼합된 자동화된 행동
동일한 IP에서 지속적인 시도
비정상적인 오류율
의심스러운 클라이언트 요청
데이터 크롤링
열쇠 수확
활동 버스트
지리적 패턴

API8:2019 삽입

위협 설명

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

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

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

정규 표현식 보호 정책

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

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

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

Apigee 플랫폼에서 사용 가능한 입력을 검증하는 방법에는 여러 가지가 있습니다.

JSONThreatProtection 정책은 JSON 페이로드에 위협이 있는지 확인합니다.
XMLThreatProtection 정책은 XML 페이로드에 위협이 있는지 확인합니다.
자바스크립트를 사용하여 매개변수 유효성 검사를 수행할 수 있습니다.
자바스크립트를 사용하여 헤더 유효성 검사를 수행할 수 있습니다.

콘텐츠 유형 확인

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

요청 - 프록시 흐름에서 조건부 로직을 사용하여 Content-Type을 확인합니다. AssignMessage 또는 RaiseFault 정책을 사용하면 맞춤 오류 메시지를 반환할 수 있습니다.
응답 - 프록시 흐름에서 조건부 로직을 사용하여 Content-Type을 확인합니다. AssignMessage 정책을 사용하여 Content-Type 헤더를 설정하거나AssignMessage 또는 RaiseFault 정책을 사용하여 맞춤 오류 메시지를 반환합니다.

API 보안 보고

조직이 거버넌스 프레임워크를 개발하기 위해 노력하는 동안 Apigee는 API 보안 보고와 관련된 기능을 제공합니다. 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의 클라우드 운영 제품군: Google의 확장성이 뛰어난 모니터링 및 로깅 도구에 즉시 통합할 수 있습니다.

서비스 콜아웃 정책: HTTP 엔드포인트에서 이벤트를 전송해야 하는 로그 스트림에 대한 지원이 추가되었습니다.

애널리틱스: 즉시 사용 가능한 보고서 또는 맞춤 보고서를 통해 이전 트래픽 메타데이터에 액세스하고 이를 분석합니다. 추세에 따라 알림을 생성 및 관리하고 비정상적인 트래픽을 파악하세요.

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