이 문서에서는 Apigee API 관리 및 다음 Google Cloud 제품을 사용하여 애플리케이션 및 API를 보호하는 데 도움을 줄 수 있는 권장사항에 대해 설명합니다.
이 문서는 애플리케이션을 관리하고 안전하고, 확장 가능하고, 성능이 뛰어난 API를 제공하길 바라는 API 설계자, 보안 설계자, 엔지니어링 책임자를 대상으로 합니다.
이 문서에서는 일련의 아키텍처 예시를 사용하여 Apigee API 관리 사용에 대한 권장사항을 설명합니다. 이 문서에서는 애플리케이션 및 API를 보호하는 데 사용할 수 있는 포괄적인 보안 솔루션인 웹 앱 및 API 보호(WAAP) 사용을 위한 권장사항도 설명합니다.
이 문서에서는 대상 독자가 네트워킹, API, Google Cloud에 익숙하다고 가정합니다.
Apigee API 관리
Apigee는 API 개발 및 관리를 위한 플랫폼입니다. Apigee는 서비스에 프록시 레이어를 추가함으로써 백엔드 서비스 API를 보호하는 데 도움이 되는 추상화 또는 퍼사드를 제공합니다.
사용자는 OAuth 2.0 및 허용 목록에 추가된 IP 주소 범위를 사용하여 애플리케이션과 상호작용할 수 있습니다. 다음 이미지에 표시된 것처럼 사용자가 애플리케이션과 상호작용할 수 있고, 데이터 및 서비스가 양방향 흐름에 노출됩니다.
보안 포인트는 다음과 같습니다.
- 사용자:
- OAuth 2.0
- IP 주소 액세스 제어
- 애플리케이션
- API 키
- OAuth 2.0
- TLS
- 개발자 및 파트너
- SSO
- RBAC
- API
- OAuth 2.0
- OpenID Connect
- 할당량
- 급증 저지
- 위협 보호
- API팀
- IAM RBAC
- 통합 논리
- 데이터 마스킹
- 감사 로그
- 백엔드
- 비공개 네트워킹
- 상호 TLS
- IP 주소 액세스 제어
앞의 이미지에 표시된 것처럼 전송 계층 보안(TLS)을 사용하는 API 키 또는 OAuth 2.0과 같이 애플리케이션에서 여러 다른 보안 메커니즘을 사용할 수 있습니다. 또한 비율 제한, 위협 보호 정책, 상호 TLS 구성을 API 레이어의 백엔드에 추가할 수 있습니다.
Apigee 플랫폼 내에서 API팀의 액세스 권한을 관리할 수 있도록 Apigee에서는 역할 기반 액세스 제어(RBAC)와 제휴 로그인을 제공합니다.
Apigee 기본 정책을 사용하여 API를 보호하는 것이 좋습니다. 정책은 다음과 같습니다.
- 트래픽 관리. 캐싱을 구성하고, 할당량을 제어하고, 급증 영향을 완화하고, API 트래픽을 제어하도록 도와줍니다.
- 메시지 수준 보호. 악의적인 공격자들로부터 백엔드를 보호하기 위해 요청 페이로드를 검사하고 검증할 수 있게 해줍니다.
- 보안. API에 대한 액세스를 제어합니다.
이러한 하나 이상의 정책을 프록시 레이어에 추가할 수 있습니다. 다음 표에서는 정책 유형별로 분류된 각 정책의 보안 사용 사례를 보여줍니다.
| 정책 유형 | 정책 이름 | 보안 사용 사례 |
|---|---|---|
| 트래픽 관리 | SpikeArrest 정책 | 백엔드로 전송되는 요청 수에 대해 비율 제한을 적용합니다. |
| 트래픽 관리 | 할당량 정책 | 조직에서 각 소비자의 할당량(API 호출 수)을 적용하도록 지원합니다. |
| 트래픽 관리 | ResponseCache 정책 | 백엔드에 대해 요청 수를 줄이는 캐시 응답입니다. |
| 메시지 수준 보호 | OASValidation 정책 | OpenAPI 3.0 사양(JSON 또는 YAML)에 대해 들어오는 요청 또는 응답 메시지를 검사합니다. |
| 메시지 수준 보호 | SOAPMessageValidation 정책 | 선택한 스키마에 대해 XML 메시지를 검증합니다. WSDL에 대해 SOAP 메시지를 검증하고 JSON 및 XML 메시지가 올바르게 형성되었는지 확인합니다. |
| 메시지 수준 보호 | JSONThreatProtection 정책 | 배열 및 문자열과 같이 JSON 구조에 대해 제한을 지정할 수 있게 해서 콘텐츠 수준 공격 위험을 완화할 수 있게 해줍니다. |
| 메시지 수준 보호 | XMLThreatProtection 정책 | 메시지가 파싱되기 전에 메시지 콘텐츠를 평가하고 손상되거나 잘못된 메시지를 감지하여 XML 취약점을 해결하고 공격 위험을 완화할 수 있습니다. |
| 메시지 수준 보호 | RegularExpressionProtection 정책 | 미리 정의된 정규 표현식에 대해 콘텐츠를 평가하고 표현식이 true이면 이를 거부합니다. |
| 보안 | BasicAuthentication 정책 | 사용자 인증 정보를 Base64로 인코딩 및 디코딩합니다. |
| 보안 | VerifyAPIKey 정책 | 런타임 시 API 키 확인 및 검증을 수행합니다. API 제품과 연결된 승인된 API 키가 있는 애플리케이션만 API에 액세스하도록 허용합니다. |
| 보안 | OAuthV2 정책 | OAuth 2.0 부여 유형 작업을 수행하여 액세스 토큰을 생성하고 검증합니다. |
| 보안 | JWS 및 JWT 정책 | JSON 웹 토큰(JWT) 및 JSON 웹 서명(JWS)을 생성, 확인, 디코딩합니다. |
| 보안 | HMAC 정책 | 인증 및 애플리케이션 수준의 무결성 검사를 위해 해시 기반 메시지 인증 코드(HMAC)를 계산하고 확인합니다. |
| 보안 | SAMLAssertion 정책 |
|
| 보안 | CORS 정책 | 웹 애플리케이션이 소비하는 API에 교차 출처 리소스 공유(CORS) 헤더를 설정할 수 있습니다, |
IP 주소 기반 및 지역 기반 액세스 제어를 위해 Google Cloud Armor를 사용하는 것이 좋습니다. 하지만 불가능한 경우에는 AccessControl 정책을 사용할 수 있습니다. Apigee에서 백엔드로의 연결을 보호하기 위해 Apigee는 또한 TLS 핸드셰이크용으로 키 저장소 및 트러스트 저장소를 구성할 수 있게 해주는 키 저장소 관리를 제공합니다.
Apigee를 사용하여 API 작업을 번들로 묶고 이를 애플리케이션 개발자가 사용하도록 제공할 수 있게 해주는 API 제품을 만들 수 있습니다. API 제품은 하나 이상의 작업과 함께 번들로 제공합니다. 작업은 API 프록시와 해당 프록시에서 액세스할 수 있는 리소스 경로를 지정합니다. HTTP 메서드 및 할당량에 따라 액세스를 제한할 수도 있습니다.
API 제품을 사용하여 API에 대한 액세스를 제어합니다. 개발자 애플리케이션에서 하나 이상의 API 제품을 정의하면 API 키로 프록시에 대한 액세스를 제한할 수 있습니다. 예를 들어 고객이 사용하는 모바일 애플리케이션은 /v1/payments 엔드포인트(여기에서는 https://$DOMAIN/v1/payments)에서 POST 작업만 수행할 수 있습니다. 또 다른 예시로, 콜센터 직원이 사용하는 콜센터 애플리케이션은 https://$DOMAIN/v1/payments/1234와 같이 /payments 엔드포인트에서 PUT 또는 DELETE와 같은 작업을 수행하여 결제를 되돌리거나 역전시킬 수 있습니다.
초기 아키텍처
이 섹션에서는 데이터 센터 및 클라우드 제공업체에서 배포된 서비스가 포함된 예시 마이크로서비스 아키텍처에 대해 설명합니다. 다음 아키텍처 권장사항에서는 초기 아키텍처를 반복하고 향상시키는 방법을 보여줍니다.
초기 아키텍처는 다음과 같습니다.
- 결제 및 계정 서비스는 데이터 센터에 호스팅되고 송금 서비스는 Google Cloud에서 호스팅됩니다.
- 외부 애플리케이션 부하 분산기는 서비스에 대한 인그레스를 제어하고 구성합니다.
- 외부 애플리케이션 부하 분산기는 요청을 적절한 백엔드 또는 제3자 서비스로 전달하고 TLS 핸드셰이크를 처리합니다.
초기 상태에서 예시 아키텍처에는 다음 제약조건이 포함됩니다.
- 확장될 가능성이 낮습니다.
- 악의적인 공격으로부터 시스템을 보호할 가능성이 낮습니다.
- 서비스가 조직 내 여러 팀에서 개발되고 유지보수되기 때문에 보안 및 로깅에 관해 일관성 있는 권장사항이 반영되지 않습니다.
아키텍처 권장사항
Apigee는 모든 API에 걸쳐 표준 보안 정책 집합을 구현하여 가치를 더할 수 있고 소비자에게 더 쉽게 서비스를 노출할 수 있습니다. 이 섹션에서는 API 보호를 위한 Apigee 사용 권장사항을 설명합니다.
Apigee를 프록시 레이어로 사용
다음 다이어그램은 프록시(퍼사드) 레이어로 Apigee가 추가된 초기 아키텍처를 보여줍니다.
Apigee가 Google Cloud 프로젝트에서 프로비저닝되고, 런타임은 VPC 네트워크 피어링을 사용하여 테넌트 프로젝트에서 프로비저닝 및 피어링됩니다. 시스템 보호를 위해 인터넷을 통해 데이터를 전송하는 대신 Apigee를 프록시 레이어로 사용하고 Cloud Interconnect를 사용해서 데이터 센터에 대해 직접(비공개) 연결을 설정할 수 있습니다.
요청 흐름은 다음과 같습니다.
- 클라이언트가 애플리케이션의 사용자 인증 정보(예: 키, 토큰, 인증서)를 사용하여 외부 애플리케이션 부하 분산기에 요청을 전송합니다.
- 부하 분산기가 요청을 Apigee로 라우팅합니다.
- Apigee가 요청을 처리하고, Apigee API 관리에 설명된 대로 보안 정책을 실행하고, 요청을 허용하거나 거부합니다. 또한 Apigee는 클라이언트나 요청 또는 클라이언트 및 요청 모두를 기준으로 여러 백엔드로 요청을 라우팅하는 데 사용될 수 있습니다.
- Apigee는 내부 IP 주소를 통해 요청을 GKE 백엔드로 직접 전달합니다. Apigee와 송금 서비스는 피어링된 네트워크 내에 있으므로 RFC 1918 주소(내부 IP 주소)를 통해 통신할 수 있습니다.
- Apigee는 Cloud Interconnect를 통해 비공개 데이터 센터 백엔드로 요청을 보냅니다.
- Apigee는 Apigee NAT IP 주소 프로비저닝을 통해 타사 서비스에 요청을 전송합니다.
Apigee를 사용하여 Google Cloud Armor를 WAF 레이어로 사용
보안 경계를 늘리기 위해 Google Cloud Armor를 아키텍처에 추가할 수 있습니다. Google Cloud Armor는 Google Cloud의 전 세계 부하 분산 인프라에 포함됩니다. 웹 애플리케이션 방화벽(WAF) 기능을 제공하고 분산 서비스 거부(DDoS) 공격을 방지하는 데 도움을 줍니다. 또한 OWASP 상위 10개에 나열된 위험 요소들로부터 애플리케이션에 대한 위협을 완화할 수 있습니다.
외부 애플리케이션 부하 분산기에 연결되는 클라이언트의 모든 호출을 평가하도록 Google Cloud Armor에서 규칙 및 정책을 구성할 수 있습니다. 또한 Google Cloud Armor 정책의 구성을 자동화할 수 있습니다. Google Cloud Armor에서 규칙을 구성하는 방법은 Google Cloud Armor 방법 가이드를 참조하세요.
다음 다이어그램은 Apigee 및 Google Cloud Armor가 모두 사용되는 예시 아키텍처를 보여줍니다.
이 아키텍처의 이벤트 흐름은 이 문서의 앞 부분에 나오는 Apigee를 프록시 레이어로 사용에 설명된 것과 비슷합니다. 요청 흐름은 다음과 같습니다.
- 클라이언트가 애플리케이션의 사용자 인증 정보(예: 키, 토큰, 인증서)를 사용하여 외부 애플리케이션 부하 분산기에 요청을 전송합니다.
- 외부 애플리케이션 부하 분산기에 사용 설정되었기 때문에 Google Cloud Armor가 요청을 필터링합니다. 모든 구성된 규칙 및 정책을 적용 및 평가합니다. 규칙을 위반하면 Google Cloud Armor가 요청을 거부하고 오류 메시지 및 상태 코드를 표시합니다.
- Google Cloud Armor 규칙 위반 사항이 없으면 외부 애플리케이션 부하 분산기가 요청을 Apigee로 라우팅합니다.
- Apigee는 요청을 처리하고, 보안 정책을 실행하고, 요청을 허용하거나 거부합니다. 또한 클라이언트나 요청 또는 클라이언트 및 요청 모두를 기준으로 여러 백엔드로 요청을 라우팅하는 데 사용될 수 있습니다.
- Apigee는 내부 IP 주소를 통해 요청을 GKE 백엔드로 직접 전달합니다. Apigee와 송금 서비스는 피어링된 네트워크 내에 있으므로 RFC 1918 주소(내부 IP 주소)를 통해 통신할 수 있습니다.
- Apigee는 Cloud Interconnect를 통해 비공개 데이터 센터 백엔드로 요청을 보냅니다.
- Apigee는 Apigee NAT IP 주소 프로비저닝을 통해 타사 서비스에 요청을 전송합니다.
WAAP 사용
또한 보안 프로필을 더 향상시키기 위해서는 DDoS 공격 및 봇으로부터 시스템을 보호할 수 있도록 Google Cloud Armor, reCAPTCHA, Apigee를 하나로 연결하는 WAAP를 사용할 수 있습니다. 또한 WAF 및 API 보호도 제공합니다.
웹사이트 및 모바일 애플리케이션에서 API 호출이 수행되는 기업 사용 사례에는 WAAP가 권장됩니다. reCAPTCHA 라이브러리를 로드해서 reCAPTCHA 토큰을 생성하고 요청이 수행될 때 이를 함께 전송하도록 애플리케이션을 전송할 수 있습니다.
다음 다이어그램은 워크플로를 보여줍니다.
이전 다이어그램의 요청 흐름은 다음과 같습니다.
- (1) 고객 및 API 소비자의 모든 HTTP(S) 요청이 외부 애플리케이션 부하 분산기로 전송됩니다.
- (2) WAAP 솔루션에서 첫 번째 연락 지점은 Google Cloud Armor입니다.
- (2a) Google Cloud Armor 정책에서 이러한 규칙을 트리거하지 않으면 수신 트래픽이 적법한 요청인지 평가하기 위해 요청이 reCAPTCHA API로 전송됩니다.
- (3a) 적법한 요청의 경우 요청이 백엔드로 전달됩니다.
- (2b) 요청이 적법하지 않으면 Google Cloud Armor는 요청을 거부하고 사용자에게 403 응답 코드를 보낼 수 있습니다.
- (3b) 어떤 API 요청이든, Google Cloud Armor OWASP 규칙 및 DDoS 보호가 평가된 후 API 요청의 유효성을 확인하기 위해 요청이 Apigee로 전달됩니다.
- (4) Apigee가 요청에 사용된 API 키 또는 액세스 토큰이 유효한지 여부를 결정합니다. Apigee에서 요청이 적법한 것으로 결정되면 Apigee가 403 응답 코드를 전송할 수 있습니다.
- (5) 요청이 적법하면 Apigee가 요청을 백엔드로 전달합니다.
다음 다이어그램은 API 요청에 대해 Google Cloud Armor, reCAPTCHA, Apigee를 사용하는 WAAP 아키텍처를 보여줍니다.
이전 다이어그램의 요청 흐름은 다음과 같습니다.
- 클라이언트가 애플리케이션의 사용자 인증 정보(예: 키, 토큰, 인증서)를 사용하여 외부 애플리케이션 부하 분산기에 요청을 전송합니다.
- 외부 애플리케이션 부하 분산기에 Google Cloud Armor가 사용 설정되었기 때문에 Google Cloud Armor가 요청을 선택합니다. 모든 구성된 규칙 및 정책을 적용 및 평가합니다. 규칙을 위반하면 Google Cloud Armor가 오류 메시지 및 상태 코드와 함께 요청을 거부합니다.
- 로그인 페이지 양식 제출과 같은 웹사이트 호출을 위해 Google Cloud Armor는 reCAPTCHA와 통합되어 있습니다. reCAPTCHA는 수신 트래픽을 평가하고 적법한 트래픽에 위험 점수를 추가합니다. 적법하지 않은 트래픽의 경우 Google Cloud Armor에서 요청을 거부할 수 있습니다.
- Google Cloud Armor 규칙 위반 사항이 없으면 외부 애플리케이션 부하 분산기가 API 요청을 Apigee로 라우팅합니다.
- Apigee는 요청을 처리하고, 보안 정책을 실행하고, 요청을 허용하거나 거부합니다. 또한 Apigee는 클라이언트나 요청 또는 클라이언트 및 요청 모두를 기준으로 여러 백엔드로 요청을 라우팅하는 데 사용될 수 있습니다.
- Apigee는 내부 IP 주소를 통해 요청을 GKE 백엔드로 직접 전달합니다. Apigee와 송금 서비스는 둘 다 피어링된 네트워크 내에 있으므로 RFC 1918 주소(내부 IP 주소)를 통해 통신할 수 있습니다.
- Apigee는 Cloud Interconnect를 통해 비공개 데이터 센터 백엔드로 요청을 보냅니다.
- Apigee는 Apigee NAT IP 주소 프로비저닝을 통해 타사 서비스에 요청을 전송합니다.
캐싱에 Cloud CDN 사용
Cloud CDN은 Google 글로벌 네트워크를 사용하여 사용자에게 더 가까운 위치에서 콘텐츠를 제공하므로 웹사이트 및 애플리케이션의 응답 시간이 빨라집니다. 또한 Cloud CDN은 캐시에서 응답을 반환함으로써 백엔드를 보호하는 데 도움이 되는 캐싱 기능을 제공합니다. Google 네트워크 에지에 있는 Google 프런트엔드(GFE)에서 자주 액세스하는 데이터를 캐시하여 사용자와 최대한 가깝게 데이터를 유지하고 빠르게 액세스할 수 있도록 합니다.
또한 Cloud CDN은 휴일 또는 개학 기간 중에 발생할 수 있는 급증과 같은 계절적인 트래픽 급증을 조직이 효율적으로 처리할 수 있게 해줍니다. 이러한 캐싱 접근 방법은 생태계에서 안정성 및 사용자 경험을 향상시켜줍니다. 또한 웹 서버 로드, 컴퓨팅, 네트워크 사용량을 최소화하는 데 도움이 됩니다. 이 아키텍처를 구현하기 위해서는 Apigee에 대해 트래픽을 처리하는 부하 분산기에서 Cloud CDN을 사용 설정해야 합니다.
Cloud CDN은 이 문서에 설명된 여러 옵션과 함께 사용될 수 있습니다. 다음 다이어그램은 Cloud CDN이 추가된 WAAP의 초기 예시 아키텍처를 보여줍니다.
이전 다이어그램에 표시된 요청 흐름은 다음과 같습니다.
- 클라이언트가 reCAPTCHA 라이브러리를 사용하여 토큰을 가져오고 애플리케이션의 키, 토큰, 인증서와 같은 사용자 인증 정보와 함께 요청을 외부 애플리케이션 부하 분산기로 보냅니다.
- Cloud CDN은 캐시 키로 캐시를 확인하고 캐시 적중이 true이면 응답을 반환합니다.
- 캐시 적중이 false이면 외부 애플리케이션 부하 분산기에 Google Cloud Armor가 사용 설정되었기 때문에 Google Cloud Armor가 요청을 필터링합니다. Google Cloud Armor는 모든 구성된 규칙 및 정책을 적용 및 평가합니다. 규칙을 위반하면 오류 메시지 및 상태 코드와 함께 요청을 거부합니다.
- Google Cloud Armor는 적법한 수신 트래픽을 위험 점수로 평가하는 reCAPTCHA와 통합됩니다. 적법하지 않은 트래픽의 경우 Google Cloud Armor에서 요청을 거부할 수 있습니다.
- Google Cloud Armor 규칙 위반 사항이 없으면 외부 애플리케이션 부하 분산기가 요청을 Apigee로 라우팅합니다.
- Apigee가 요청을 처리하고, Apigee API 관리에 설명된 대로 보안 정책을 실행하고, 요청을 허용하거나 거부합니다. 또한 클라이언트나 요청 또는 클라이언트 및 요청 모두를 기준으로 여러 백엔드로 요청을 라우팅하는 데 사용될 수 있습니다.
- Apigee는 내부 IP 주소를 통해 요청을 GKE 백엔드로 직접 전달합니다. Apigee와 송금 서비스는 피어링된 네트워크 내에 있으므로 RFC 1918 주소(내부 IP 주소)를 통해 통신할 수 있습니다.
- Apigee는 Cloud Interconnect를 통해 비공개 데이터 센터 백엔드로 요청을 보냅니다.
- Apigee는 Apigee NAT IP 주소 프로비저닝을 통해 타사 서비스에 요청을 전송합니다.
- 응답이 클라이언트로 다시 전달되면 Cloud CDN은 이후 호출에 대해 캐시에서 응답을 반환할 수 있도록 응답을 캐시합니다.
다음 단계
- Apigee 프로비저닝 옵션 자세히 알아보기
- Apigee 및 Google Cloud Armor를 사용한 멀티 레이어 API 보안 읽어보기
- Apigee X 및 Cloud CDN을 사용한 고성능 전역 API 제공 방법 알아보기
- Apigee 커뮤니티에서 읽고 질문하기
- GitHub에서 Apigee 저장소 살펴보기
- 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 Cloud 아키텍처 센터를 확인하세요.