이 문서에서는 OWASP 상위 10개 항목에 설명된 일반적인 애플리케이션 수준 공격을 방어하는 데 도움이 되는 Google Cloud 제품 및 완화 전략을 식별할 수 있도록 도와줍니다. OWASP 상위 10개 항목은 모든 애플리케이션 소유자가 주의해야 하는 상위 10개 보안 위험에 대해 Open Web Application Security(OWASP) 재단에서 작성된 목록입니다. 어떠한 보안 제품도 이러한 위험 요소들에 대해 완전한 보호를 보장할 수 없지만, 해당 아키텍처에 적합할 때 이러한 제품 및 서비스를 적용하면 강력한 멀티 레이어 보안 솔루션을 만드는 데 도움을 줄 수 있습니다.
Google 인프라는 안전한 방식으로 서비스를 빌드, 배포, 운영하는 데 도움이 되도록 설계되었습니다. 물리적 및 운영적 보안, 저장 데이터 암호화 및 전송 중 데이터 암호화, 보안 인프라의 다른 여러 중요 속성은 Google에서 관리됩니다. 애플리케이션을 Google Cloud로 배포하면 이러한 이점을 이용할 수 있지만 특정 공격으로부터 애플리케이션을 보호하기 위해 추가 조치가 필요할 수 있습니다.
이 문서에 나열된 완화 전략은 애플리케이션 보안 위험 및 Google Cloud 제품에 따라 정렬되어 있습니다. 많은 제품들이 웹 보안 위험에 대한 심층 방어 전략을 만드는 데 일익을 담당합니다. 이 문서에서는 OWASP 상위 10개 위험을 완화하는 데 도움이 되는 여러 제품들에 대한 정보를 제공하지만, Google Cloud Armor 및 Apigee를 사용하여 이러한 다양한 위험을 완화하는 방법에 대한 추가 세부정보를 제공합니다. 웹 애플리케이션 방화벽(WAF) 역할을 수행하는 Google Cloud Armor와 API 게이트웨이 역할을 수행하는 Apigee는 여러 종류의 공격을 차단하는 데 특히 도움이 될 수 있습니다. 이러한 제품은 인터넷에서 트래픽 경로에 있으며, Google Cloud의 애플리케이션에 연결되기 전에 외부 트래픽을 차단할 수 있습니다.
제품 개요
다음 표에 나열된 Google Cloud 제품은 상위 10개 보안 위험으로부터 보호하는 데 도움을 줄 수 있습니다.
제품 | 요약 | A01 | A02 | A03 | A04 | A05 | A06 | A07 | A08 | A09 | A10 |
---|---|---|---|---|---|---|---|---|---|---|---|
액세스 투명성 | 관리자 액세스 로그 및 승인 제어를 통해 클라우드 제공업체의 액세스를 자세히 파악하고 관리합니다. | ✓ | ✓ | ||||||||
Artifact Registry | 중앙에서 아티팩트 저장 및 종속 항목 빌드 | ✓ | |||||||||
Apigee | 애플리케이션 프로그래밍 인터페이스 설계, 보안, 확장 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ||
Binary Authorization | 신뢰할 수 있는 컨테이너 이미지만 Google Kubernetes Engine에 배포 | ✓ | ✓ | ||||||||
Google Security Operations | Google 인프라, 감지 기법, 신호를 사용하여 대규모 실시간 자동 위협 감지 | ✓ | |||||||||
Cloud 애셋 인벤토리 | 프로젝트 및 서비스 간에 모든 Google Cloud 및 Google Distributed Cloud Virtual 또는 멀티 클라우드 애셋을 확인, 모니터링, 분석합니다. | ✓ | ✓ | ✓ | ✓ | ||||||
Cloud Build | Google Cloud에서 빌드, 테스트, 배포 | ✓ | |||||||||
Sensitive Data Protection | 가장 민감한 정보 검색, 분류, 보호 | ✓ | ✓ | ✓ | |||||||
Cloud Load Balancing | SSL 프록시 또는 HTTPS 부하 분산기가 협상하는 암호화 제어 | ✓ | ✓ | ✓ | ✓ | ||||||
Cloud Logging | 규모에 따른 실시간 로그 관리 및 분석 | ✓ | |||||||||
Cloud Monitoring | Google Cloud 서비스, 다양한 애플리케이션 및 타사 서비스의 측정항목, 이벤트, 메타데이터를 수집하고 분석합니다. | ✓ | |||||||||
Cloud Source Repositories | 팀의 단일 위치에서 코드 저장, 관리, 추적 | ✓ | |||||||||
Container Threat Detection | 지속적인 컨테이너 이미지 상태 모니터링, 모든 변경사항 평가, 원격 액세스 시도 모니터링으로 런타임 공격을 거의 실시간으로 감지 | ✓ | ✓ | ||||||||
Event Threat Detection | 거의 실시간으로 조직의 Cloud Logging 스트림 모니터링 및 위협 감지 | ✓ | ✓ | ✓ | |||||||
Forseti Inventory | 아키텍처의 스냅샷 수집 및 저장 | ✓ | |||||||||
Forseti Scanner | 커스텀 정의된 정책에 따라 인벤토리 데이터 스캔 및 예기치 않은 편차에 대한 알림 표시 | ✓ | |||||||||
Google Cloud Armor | Google 네트워크 에지에 배포된 웹 애플리케이션 방화벽(WAF)으로 일반적인 공격 벡터 방어 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
Google Cloud 보안 게시판 | Google Cloud 제품 관련 최신 보안 게시판 | ✓ | |||||||||
IAP(Identity-Aware Proxy) | ID와 컨텍스트를 사용하여 애플리케이션 및 VM에 대한 액세스 보호 | ✓ | ✓ | ✓ | |||||||
Identity Platform | 애플리케이션에 ID 및 액세스 관리 기능 추가, 사용자 계정 보호, ID 관리 확장 | ✓ | ✓ | ||||||||
Cloud Key Management Service | Google Cloud에서 암호화 키 관리 | ✓ | ✓ | ||||||||
reCAPTCHA Enterprise | 허위 행위, 스팸, 악용으로부터 웹사이트를 보호하도록 지원 | ✓ | |||||||||
Secret Manager | API 키, 비밀번호, 인증서 등 민감한 정보 저장 | ✓ | ✓ | ||||||||
Security Command Center | 보안 분석 및 위협 인텔리전스를 위해 중앙화된 가시성으로 애플리케이션의 취약점 표면화 | ✓ | |||||||||
Security Health Analytics(SHA) | Security Command Center에서 제공되는 취약점 발견 항목 생성 | ✓ | ✓ | ✓ | ✓ | ||||||
Titan 보안 키 | 키 무결성 확인을 위해 하드웨어 칩(Google에서 설계한 펌웨어 포함)이 내장된 피싱 방지 2FA 기기로 고액 사용자 보호 | ✓ | |||||||||
Virtual Private Cloud 방화벽 | 가상 머신(VM) 인스턴스 간의 연결 허용 또는 거부 | ✓ | |||||||||
VPC 서비스 제어 | 멀티 테넌트 Google Cloud 서비스의 리소스 격리로 데이터 무단 반출 위험 완화 | ✓ | ✓ | ||||||||
VirusTotal | 의심스러운 파일 및 URL 분석으로 멀웨어 유형 감지, 보안 커뮤니티와 자동 공유 | ✓ | ✓ | ||||||||
Web Security Scanner | Security Command Center에서 제공되는 취약점 발견 항목 유형 생성 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
A01: 손상된 액세스 제어
손상된 액세스 제어는 클라이언트 측에서 부분적으로만 적용되는 또는 약하게 구현되는 액세스 제어를 의미합니다. 이러한 제어 문제를 완화하기 위해서는 승인된 사용자만 리소스에 액세스하도록 애플리케이션 측면에서 재작성이 필요한 경우가 많습니다.
Apigee
사용 사례:
- 액세스 제어 적용
- 데이터 조작 제한
Apigee는 공격자가 승인되지 않은 항목을 변경하거나 시스템에 액세스하지 못하도록 액세스 제어를 구현하기 위한 계층화된 접근방법을 지원합니다.
사용자가 필요한 기능 및 구성만 액세스하도록 역할 기반 액세스 제어(RBAC)를 구성합니다. 민감한 키-값 쌍을 저장하도록 암호화된 키-값 맵을 만듭니다. 키-값 쌍은 Edge UI 및 관리 API 호출에서 마스킹된 상태로 표시됩니다. 회사의 ID 공급업체로 싱글 사인온(SSO)을 구성합니다.
사용자 역할에 따라 특정 API 제품을 표시하도록 개발자 포털을 구성합니다. 사용자 역할을 기준으로 콘텐츠를 표시하거나 숨기도록 포털을 구성합니다.
Cloud 애셋 인벤토리
사용 사례:
- 승인되지 않은 IT('비공식 IT'라고도 함) 모니터링
- 오래된 컴퓨팅 인스턴스
데이터 노출에서 가장 일반적인 벡터 중 하나는 고립되었거나 승인되지 않은 IT 인프라입니다. 예기치 않게 실행되는 리소스에 대해 알림을 제공하도록 실시간 알림을 설정합니다. 이러한 리소스는 부적절하게 보호되거나 오래된 소프트웨어를 사용할 수 있습니다.
Cloud Load Balancing
사용 사례:
- 세밀한 SSL 및 TLS 암호화 제어
Cloud Load Balancing에서 사용할 수 있는 사전 정의된 그룹이나 커스텀 암호화 목록을 할당하여 약한 SSL 또는 TLS 암호화 사용을 방지합니다.
Forseti Scanner
사용 사례:
- 액세스 제어 구성 모니터링
액세스 제어가 의도한 대로 설정되도록 Google Cloud 리소스를 체계적으로 모니터링합니다. 보안 자세를 코드화하기 위해 규칙 기반 정책을 만듭니다. 구성이 예기치 않게 변경되면 알려진 상태로 자동 복구할 수 있도록 Forseti Scanner가 알림을 제공합니다.
Google Cloud Armor
사용 사례:
- 교차 도메인 요청 필터링
- 로컬 또는 원격 파일 포함 공격 필터링
- HTTP 매개변수 오염 공격 필터링
많은 손상된 액세스 제어 사례는 웹 애플리케이션 방화벽을 사용하여 완화될 수 없습니다. 이것은 애플리케이션에서 모든 요청에 대해 액세스 토큰이 필요하지 않거나 이를 올바르게 검사하지 않고, 데이터가 클라이언트 측에서 조작될 수 있기 때문입니다. Juice Shop에는 손상된 액세스 제어와 관련된 여러 문제가 있습니다. 예를 들어 다른 사용자 이름에 의견을 게시하면 일부 요청이 서버 측에서 인증되지 않습니다. 도전과제 솔루션에서 볼 수 있듯이, 이 취약점 공격은 완전히 클라이언트 측에서 이뤄지며, 따라서 Google Cloud Armor를 사용하여 완화될 수 없습니다.
애플리케이션에 즉시 패치를 적용할 수 없는 경우에는 서버 측에서 일부 도전과제를 부분적으로 완화할 수 있습니다.
예를 들어 CSRF Juice Shop 도전과제의 설명처럼 웹 서버가 교차 출처 리소스 공유(CORS)를 잘못 구현하므로 크로스 사이트 요청 위조(CSRF) 공격이 발생할 수 있으면 커스텀 규칙을 사용해 예상하지 못한 출처의 모든 요청을 차단하여 이 문제를 완화할 수 있습니다. 다음 규칙은 example.com 및 google.com 이외의 원본이 포함된 모든 일치하는 요청을 검색합니다.
has(request.headers['origin']) &&
!((request.headers['origin'] == 'https://example.com')||
(request.headers['origin'] == 'https://google.com') )
이러한 규칙과 일치하는 트래픽이 거부되면 CSRF 도전과제에 대한 솔루션이 중지됩니다.
장바구니 조작 도전과제에서는 HPP(HTTP parameter pollution)를 사용하므로 도전과제 솔루션을 따르면 매장을 공격하는 방식을 확인할 수 있습니다.
HPP는 프로토콜 공격 규칙 집합의 일부로 탐지됩니다. 이러한 종류의 공격을 차단하려면 evaluatePreconfiguredExpr('protocolattack-stable')
규칙을 사용합니다.
IAP(Identity-Aware Proxy) 및 컨텍스트 인식 액세스
사용 사례:
- 중앙 집중식 액세스 제어
- 클라우드 및 온프레미스에서 작업
- HTTP 및 TCP 연결 보호
- 컨텍스트 인식 액세스
IAP를 사용하면 ID 및 컨텍스트를 사용하여 애플리케이션 주위에 보안 인증 및 승인 벽을 만들 수 있습니다. Cloud ID 및 IAM으로 빌드된 중앙에서 관리되는 인증 및 승인 시스템으로 퍼블릭 대면 애플리케이션에 대한 손상된 승인 또는 액세스 제어를 방지합니다.
기존 VPN을 사용하지 않고도 사용자 ID 및 요청 컨텍스트를 기반으로 세부적인 액세스 제어를 웹 애플리케이션, VM, Google Cloud API, Google Workspace 애플리케이션에 적용합니다. 클라우드 및 온프레미스 애플리케이션 및 인프라 리소스 모두에 대해 단일 플랫폼을 사용합니다.
Security Health Analytics
사용 사례:
- MFA 또는 2FA 적용
- API 키 보호
- SSL 정책 모니터링
다단계 인증 규정 준수, SSL 정책, API 키의 상태를 모니터링하여 손상된 액세스 제어를 방지합니다.
Web Security Scanner
사용 사례:
- 공개되어 노출된 저장소
- 안전하지 않은 요청 헤더 유효성 검사
Web Security Scanner는 웹 애플리케이션에서 공개적으로 표시되는 코드 저장소 및 잘못 구성된 요청 헤더 유효성 검사와 같은 취약점을 검사합니다.
A02: 암호화 실패
암호화 실패는 암호화 부족이나 취약한 전송 중인 데이터 암호화 또는 실수로 인한 민감한 정보 노출로 인해 발생할 수 있습니다. 이러한 취약점을 노리는 공격자는 일반적으로 애플리케이션에 집중하므로, 완화를 위해 심층 방어 접근 방법이 필요합니다.
Apigee
사용 사례:
- 민감한 정보 보호
단방향 및 양방향 TLS를 사용하여 프로토콜 수준에서 민감한 정보를 보호할 수 있습니다.
메시지 할당 정책 및 자바스크립트 정책과 같은 정책을 사용하여 클라이언트에 반환되기 전 민감한 정보를 삭제합니다.
표준 OAuth 기법을 사용하고 각 요청의 인증 수준을 향상시키기 위해 HMAC, 해시, 상태, nonce, PKCE, 기타 기법을 추가할 수 있습니다.
Edge Trace 도구에서 민감한 정보를 마스킹합니다.
키 값 맵에서 저장 중인 민감한 정보를 암호화합니다.
Cloud 애셋 인벤토리
사용 사례:
- 검색 서비스
- 액세스 분석기
데이터 노출에서 가장 일반적인 벡터 중 하나는 고립되었거나 승인되지 않은 IT 인프라입니다. 클라우드 애셋 시계열 데이터를 분석하여 아무도 유지 관리하지 않는 서버 및 공유 규칙이 너무 포괄적인 버킷을 식별할 수 있습니다.
실시간 알림 설정을 통해 보안이 올바르지 않거나 승인되지 않았을 수 있는 리소스가 예기치 않게 프로비저닝될 때 이에 대한 알림을 제공할 수 있습니다.
Cloud Data Loss Prevention API(Sensitive Data Protection의 일부)
사용 사례:
- 민감한 정보 검색 및 분류
- 자동 데이터 마스킹
Cloud Data Loss Prevention API(DLP API)를 통해 의도치 않은 정보 누출을 방지하기 위해 버킷 또는 데이터베이스에 저장된 잠재적으로 민감한 정보를 스캔할 수 있습니다. 허용되지 않은 데이터가 식별된 경우 이를 자동으로 플래그 지정하거나 수정할 수 있습니다.
Cloud Key Management Service
사용 사례:
- 보안 암호화 키 관리
(Cloud KMS)는 암호화 키 유출 가능성을 방지합니다. 이 클라우드 호스팅 키 관리 서비스를 사용하여 온프레미스에서와 동일한 방식으로 클라우드 서비스의 대칭 및 비대칭 암호화 키를 관리합니다. AES256, RSA 2048, RSA 3072, RSA 4096, EC P256, EC P384 암호화 키를 생성, 사용, 순환, 폐기할 수 있습니다.
Cloud Load Balancing
사용 사례:
- 세밀한 SSL 및 TLS 암호화 제어
SSL 정책은 부하 분산기에서 허용되는 SSL 및 TLS 기능과 암호화를 통한 제어 기능을 제공하여 민감한 정보 노출을 방지하는 데 도움을 줄 수 있습니다. 필요에 따라 승인되지 않은 또는 안전하지 않은 암호화를 차단합니다.
Google Cloud Armor
사용 사례:
- 알려진 공격 URL 필터링
- 민감한 엔드포인트 액세스 제한
일반적으로 민감한 정보 노출은 소스에서 중지될 수 있지만, 모든 공격이 애플리케이션과 관련되기 때문에 웹 애플리케이션 방화벽은 포괄적인 데이터 노출 방지를 위해 제한된 방법으로만 사용될 수 있습니다. 하지만 애플리케이션에 즉시 패치를 적용할 수 없으면 Google Cloud Armor 커스텀 규칙을 사용하여 취약한 엔드포인트 또는 요청 패턴에 대해 액세스를 제한할 수 있습니다.
예를 들어 일부 민감한 정보 노출에 대한 Juice Shop 도전과제는 안전하지 않은 디렉터리 순회 및 널 바이트 삽입 공격으로 인해 악용될 수 있습니다. 다음 커스텀 표현식으로 URL의 문자열을 검사하여 이러한 삽입 공격을 완화할 수 있습니다.
request.path.contains("%00") || request.path.contains("%2500")
Prometheus에 사용되는 /metrics
하위 디렉터리에 액세스하여 노출된 측정항목 도전과제를 해결할 수 있습니다.
민감한 엔드포인트가 노출되고 액세스를 즉시 삭제할 수 없으면 특정 IP 주소 범위를 제외하고 이에 대한 액세스를 제한할 수 있습니다. 다음 커스텀 표현식과 비슷한 규칙을 사용합니다.
request.path.contains("/metrics") && !(inIpRange(origin.ip, '1.2.3.4/32')
1.2.3.4/32
를 측정항목 인터페이스에 액세스해야 하는 IP 주소 범위로 바꿉니다.
사고로 노출된 로그 파일은 Juice Shop 도전과제 중 하나를 해결하기 위해 사용됩니다. 로그 노출을 방지하려면 request.path.endsWith(".log")
와 같이 로그 파일에 대한 액세스를 완전히 금지하는 규칙을 설정합니다.
IAP(Identity-Aware Proxy) 및 컨텍스트 인식 액세스
사용 사례:
- 민감한 서비스에 대한 원격 액세스 보안
- 중앙 집중식 액세스 제어
- 컨텍스트 인식 액세스
ID 및 컨텍스트를 사용하여 애플리케이션의 보안 인증 및 승인을 만듭니다. 인터넷 어디에서든 승인된 개인에게만 컨텍스트 인식 액세스를 허용할 수 있도록 내부 버그 신고, 회사 기술 자료, IAP 기반 이메일과 같은 도구를 배포합니다.
컨텍스트 인식 액세스를 사용하면 기존 VPN 없이 사용자의 ID 및 요청 컨텍스트를 기반으로 웹 애플리케이션, 가상 머신(VM), Google Cloud API, Google Workspace 애플리케이션에 대해 세부적인 액세스 제어를 적용할 수 있습니다. 제로 트러스트 보안 모델 및 Google의 BeyondCorp 구현을 기준으로 컨텍스트 인식 액세스를 사용하면 사용자에 대한 액세스 권한을 제공하고, 세부적인 제어를 적용하고, 클라우드 및 온프레미스 애플리케이션과 인프라 리소스 모두에 단일 플랫폼을 사용할 수 있습니다.
Secret Manager
사용 사례:
- Crypto 키
- API 키
- 기타 시스템 사용자 인증 정보
Secret Manager는 API 키, 서비스 계정 비밀번호, 암호화 애셋과 같은 가장 중요한 데이터를 위한 보안 스토리지 서비스입니다. 이러한 보안 비밀을 중앙 위치에 저장함으로써 IAM을 포함하여 Google Cloud의 인증 및 승인 시스템을 활용해서 액세스를 위해 제공된 요청이 유효한지 여부를 확인할 수 있습니다.
Secret Manager는 신용 카드 토큰화 또는 개별 사용자 비밀번호 스토리지와 같은 대규모 작업용으로 설계되지 않았습니다. 이러한 애플리케이션은 CIAM을 위한 Identity Platform, 조직 구성원을 위한 Cloud ID, 전용 토큰화 소프트웨어를 사용해야 합니다.
Security Health Analytics
사용 사례:
- MFA/2FA 적용
- API 키 보호
- API 키 순환 적용
- 컴퓨팅 이미지 개인정보 보호
- SSH 키 규칙 적용
- 보안 부팅 모니터링
- API 액세스 보안
- SSL 정책 모니터링
- 사용 중지된 로깅
- 공개 버킷 ACL 알림
다단계 인증 규정 준수 및 API 키 상태를 모니터링하여 민감한 정보 노출을 방지합니다. 컨테이너 이미지 스토리지, Cloud Storage, SSL 정책, SSH 키 정책, 로깅, API 액세스 등에서 안전하지 않은 구성에 대한 알림을 표시합니다.
VirusTotal
사용 사례:
- 피싱 방지
VirusTotal을 사용하면 URL을 사용자 또는 직원들에게 제공하기 전 사용자 입력, 이메일, 채팅, 로그, 기타 위치 등 어디에서든 URL에서 악의적인 콘텐츠를 스캔할 수 있습니다.
VPC 서비스 제어
사용 사례:
- 관리형 서비스의 방화벽
서비스를 호출할 수 있는 사람과 서비스가 응답할 수 있는 사람을 제어하기 위해 방화벽에서 중요하게 관리되는 서비스를 래핑합니다. Cloud Functions와 같은 서비스에서 아웃바운드 경계 규칙으로 승인되지 않은 이그레스 및 데이터 무단 반출을 차단합니다. 관리되는 데이터 저장소 및 데이터베이스에 대한 승인되지 않은 사용자 및 위치의 요청을 방지합니다. 강력하거나 잠재적으로 비용이 높은 API 주변에 보안 경계를 만듭니다.
Web Application Scanner
사용 사례:
- 웹 애플리케이션 보안 위험 스캐너
- 소스 저장소 가용성 스캐너
웹 애플리케이션이 민감한 정보를 노출하지 못하도록 방지하려면 비밀번호가 일반 텍스트로 전송되지 않도록 합니다. 노출된 git 및 Apache Subversion 소스 코드 저장소를 확인하여 잠재적으로 파괴적인 원시 소스 코드 누출을 방지합니다. 이러한 스캔은 특정 OWASP 상위 10개 제어 항목을 포함하도록 설계되었습니다.
Web Security Scanner
사용 사례:
- 네트워크를 통해 전송되는 암호화되지 않은 비밀번호
Web Security Scanner는 웹 애플리케이션을 스캔하고 오류와 취약점의 발견 항목을 보고합니다. 애플리케이션이 비밀번호를 일반 텍스트로 전송하면 Web Security Scanner가 CLEAR_TEXT_PASSWORD
발견 항목을 생성합니다.
A03: 삽입
SQL, NoSQL, OS, LDAP 삽입과 같은 삽입 결함은 명령어 또는 쿼리의 일부로 신뢰할 수 없는 데이터가 인터프리터에 전송될 때 발생합니다. 공격자의 적대적인 데이터로 인해 적절한 승인 없이 인터프리터가 의도하지 않은 명령어를 실행하거나 데이터에 액세스하게 될 수 있습니다. 사용자 데이터를 인터프리터로 전송하기 전에 애플리케이션에서 이를 삭제하거나 필터링하는 것이 좋습니다.
다음 섹션에서는 이 위험을 완화하는 데 도움이 되는 Google Cloud 제품들에 대해 설명합니다.
Apigee
사용 사례:
- SQL 삽입 차단
- NoSQL 삽입 차단
- LDAP 삽입 차단
- 자바스크립트 삽입 차단
Apigee는 정책 또는 규칙의 추가 처리를 허용하기 전 클라이언트에서 제공된 값이 구성된 예상 항목과 일치하는지 확인하기 위해 여러 입력 검증 정책을 제공합니다. 수신되는 API 요청의 게이트웨이로 작동하는 Apigee는 한도 검사를 실행하여 페이로드 구조가 허용되는 범위 내에 있는지 확인합니다. 위험한 문자 시퀀스를 삭제하고 이를 안전한 값으로 바꾸기 위해 입력 검증 루틴이 입력을 변환할 수 있도록 API 프록시를 구성할 수 있습니다.
Apigee 플랫폼으로 입력을 검증하는 데에는 몇 가지 접근 방법이 있습니다.
- JSONThreatProtection은 JSON 페이로드에서 위협을 검사합니다.
- XMLThreatProtection은 XML 페이로드에서 위협을 검사합니다.
- 자바스크립트는 매개변수 및 헤더를 검증합니다.
- RegularExpressionProtection 정책은 SQL 코드 삽입을 처리합니다.
OASValidation
정책은 OpenAPI 사양(JSON 또는 YAML)에 따라 수신 요청 또는 응답 메시지를 검증합니다.SOAPMessageValidation
정책은 XSD 스키마에 따라 모든 XML 메시지를 검증하며, WSDL 정의에 따라 SOAP 메시지를 검증할 수 있습니다.
Container Threat Detection
사용 사례:
- 악성 스크립트 감지
- 역방향 셸 감지
- 멀웨어 설치 감지
Container Threat Detection의 Malicious Script Executed
감지기는 시스템에서 실행된 모든 셸 스크립트를 분석하고 악성 셸 스크립트를 보고합니다. 이렇게 하면 셸 명령어 삽입 공격을 감지할 수 있는 차량이 제공됩니다. 셸 명령어 삽입에 성공하면 공격자는 역방향 셸을 생성하여 Reverse Shell
감지기를 트리거할 수 있습니다.
또는 Added Binary Executed
및 Added Library Loaded
감지기를 트리거하는 멀웨어를 설치할 수 있습니다.
Google Cloud Armor
사용 사례:
- SQL 삽입 필터링
- PHP 삽입 필터링
Google Cloud Armor는 일반적인 삽입 공격이 애플리케이션에 도달하기 전에 이를 차단할 수 있습니다. SQL 삽입(SQLi)의 경우 Google Cloud Armor에는 OWASP Modsecurity Core Rule Set을 기반으로 하는 사전 정의된 규칙 집합이 있습니다. evaluatePreconfiguredExpr('sqli-stable')
규칙을 자체적으로 또는 다른 커스텀 규칙과 함께 사용하여 핵심 규칙 집합에 정의된 일반 SQLi 공격을 차단하는 보안 정책을 빌드할 수 있습니다. 예를 들어 URL 경로 필터를 사용하여 SQLi 차단을 특정 애플리케이션으로 제한할 수 있습니다.
PHP 삽입의 경우 또 다른 사전 구성된 규칙 집합이 있습니다. evaluatePreconfiguredExpr('php-stable')
규칙을 사용하여 일반적인 PHP 삽입 공격을 차단할 수 있습니다.
애플리케이션에 따라 사전 구성된 표현식을 활성화하면 해당 규칙 집합의 규칙 중 너무 민감한 일부 규칙으로 인해 일부 거짓양성이 나타날 수 있습니다. 자세한 내용은 거짓양성 문제 해결 및 규칙 집합을 다른 민감도 수준으로 조정하는 방법을 참조하세요.
SQL 또는 PHP 대상 공격 이외의 다른 삽입 공격의 경우 해당 프로토콜에서 특정 키워드 또는 이스케이프 패턴이 요청 경로 또는 쿼리에 사용되었을 때 요청을 차단하도록 커스텀 규칙을 만들 수 있습니다. 이러한 패턴이 유효한 요청에 표시되지 않는지 확인하세요. 또한 이러한 규칙이 전달된 데이터를 해석할 수 있는 특정 엔드포인트 또는 경로에만 사용되도록 제한할 수 있습니다.
또한 일부 삽입 공격은 원격 코드 실행 및 원격 파일 삽입에 대해 사전 구성된 규칙을 사용하여 완화될 수 있습니다.
Web Security Scanner
사용 사례:
- 교차 사이트 스크립팅 모니터링
- SQL 삽입 모니터링
Web Security Scanner는 웹 애플리케이션에서 취약점을 검사하고 교차 사이트 스크립팅 및 SQL 삽입 공격을 모니터링하는 감지기를 제공합니다.
A04: 안전하지 않은 설계
안전하지 않은 설계는 조직에서 개발 수명 주기 동안 위협을 평가하고 처리하는 방법을 구현하지 않는 경우에 발생합니다. 위협 모델링은 설계 및 미세 조정 단계 초기에 수행되어 개발 및 테스트 단계 내내 계속되는 경우 조직에서 가정 및 실패 결함을 분석하는 데 도움이 됩니다. 실수로부터 학습하는 비난 없는 문화는 보안 설계의 핵심입니다.
Apigee
사용 사례:
- 입력 유효성 검사
- 액세스 제어
- 오류 처리
- 콘텐츠 보호 정책
- 비밀번호 관리
Apigee를 사용하면 OASValidation 정책을 사용하여 애플리케이션에 대한 수신 요청과 응답의 유효성을 검사할 수 있습니다. 또한 액세스가 보호되도록 싱글 사인온(SSO), 역할 기반 액세스 제어(RBAC)를 구성하고 API에 대한 액세스를 제한하고(예: Auth0 사용) 환경에 대한 액세스 권한이 있는 IP 주소를 제한할 수 있습니다. 오류 처리 규칙을 사용하면 API 프록시가 오류에 반응하는 방식을 맞춤설정할 수 있습니다.
Apigee 전역 사용자의 안전하지 않은 비밀번호가 보호되도록 Apigee에서는 비밀번호 만료, 차단, 재설정 기능을 제공합니다. 또한 2단계 인증(2FA)을 사용 설정할 수 있습니다.
Cloud Data Loss Prevention API(Sensitive Data Protection의 일부)
사용 사례:
- 기밀 데이터 식별 및 수정
Cloud Data Loss Prevention API를 사용하면 기밀 데이터를 식별하고 토큰화할 수 있습니다. DLP API는 데이터가 토큰화되고 저장된 후 데이터를 볼 수 있는 사용자를 제한하도록 액세스 제어를 설정할 수 있으므로 기밀 데이터 노출을 제한하는 데 도움이 됩니다. 자세한 내용은 Cloud Storage에 업로드된 데이터 분류 자동화 및 Sensitive Data Protection를 사용하여 대규모 데이터 세트에서 PII 익명화 및 재식별을 참조하세요.
Secret Manager
사용 사례:
- 사용자 인증 정보 스토리지 보호
Secret Manager를 사용하면 애플리케이션과 파이프라인에서 IAM으로 부여된 권한을 기반으로 명명된 보안 비밀의 값에 액세스할 수 있습니다. 또한 자동화된 프로세스가 보안 비밀 값에 액세스할 수 있도록 프로그래매틱 방식으로 보안 비밀에 대한 액세스 권한을 제공합니다. 사용 설정하면 모든 Secret Manager와의 상호작용에서 감사 추적을 제공합니다. 이러한 감사 추적을 사용하여 포렌식 및 규정 준수 요구사항을 지원합니다.
Web Security Scanner
사용 사례:
- 애플리케이션의 보안 취약점을 파악합니다.
Web Security Scanner는 웹 애플리케이션의 취약점을 검사합니다. 링크를 따라가며 최대한 많은 사용자 입력과 이벤트 핸들러를 실행하려고 합니다. CACHEABLE_PASSWORD_INPUT
감지기는 웹 애플리케이션에 입력한 비밀번호가 보안 비밀번호 스토리지 대신 일반 브라우저 캐시에 캐시될 수 있으면 발견 항목을 생성합니다.
A05: 잘못된 보안 구성
잘못된 보안 구성은 일반적으로 애플리케이션 강화로 방지될 수 있는 패치가 적용되지 않은 애플리케이션 결함, 개방된 기본 계정, 보호되지 않은 파일 및 디렉터리를 의미합니다. 잘못된 보안 구성은 기본 구성 신뢰, 안전하지 않을 수 있는 일부 구성 수행, 오류 메시지에 민감한 세부정보 포함 허용, 적절한 보안 제어 없이 클라우드에 데이터 저장, 잘못된 HTTP 헤더 구성과 같은 여러 방식으로 발생할 수 있습니다.
Apigee
사용 사례:
- 보안 구성 관리
- 보안 구성 모니터링
공유 흐름을 통해 API 개발자는 정책 및 리소스를 재사용 가능한 그룹으로 결합할 수 있습니다. 공유 흐름을 사용하면 재사용 가능한 기능을 하나의 위치에 캡처함으로써, 일관성을 보장하고, 개발 시간을 단축시키고, 코드를 보다 쉽게 관리할 수 있습니다. FlowCallout 정책을 사용하여 개별 API 프록시 내부에 공유 흐름을 포함하거나 동일한 환경에 배포된 모든 API 프록시에 대해 공유 흐름 논리를 자동으로 실행하도록 흐름 후크에 공유 흐름을 배치할 수 있습니다.
Cloud 애셋 인벤토리
사용 사례:
- 실시간 알림 서비스
실시간 알림은 부적절하게 보호되거나 승인되지 않을 수 있는 리소스에 대한 예기치 않은 프로비저닝에 대해 알림을 제공할 수 있습니다.
Cloud Load Balancing
사용 사례:
- 세밀한 SSL 및 TLS 암호화 제어
부하 분산기에서 사용할 수 있는 사전 정의된 암호화 그룹이나 커스텀 목록을 할당하여 취약하다고 알려진 SSL 또는 TLS 암호화 사용을 방지합니다.
Google Cloud Armor
사용 사례:
- 안전하지 않은 엔드포인트 필터링
- 로컬 또는 원격 파일 포함 공격 필터링
- 프로토콜 공격 필터링
잘못된 보안 구성은 애플리케이션 수준에서 발생할 수 있기 때문에 OWASP 재단은 애플리케이션을 강화하고 직접 패치를 적용하고, 모든 불필요한 기능을 삭제할 것을 권장합니다.
Google Cloud Armor와 같은 웹 애플리케이션 방화벽(WAF)이 잘못된 기본 구성의 해결에 도움을 줄 수는 없지만 애플리케이션의 일부에 대한 액세스를 완전히 또는 특정 IP 주소 또는 국가를 제외한 모든 사람들에 대해 차단할 수 있습니다. 액세스를 제한하면 이러한 잘못된 구성이 악용될 위험을 줄일 수 있습니다.
예를 들어 애플리케이션이 /admin
과 같은 일반적인 URL을 사용하여 관리 인터페이스를 노출하는 경우, 인증되어 있더라도 이 인터페이스에 대한 액세스를 제한할 수 있습니다. 다음과 같이 거부 규칙을 사용하여 이를 수행할 수 있습니다.
request.path.contains("/admin") && !(inIpRange(origin.ip, '1.2.3.4/32')
1.2.3.4/32
를 관리 인터페이스에 액세스해야 하는 IP 주소 범위로 바꿉니다.
일부 잘못된 구성은 사전 정의된 로컬 파일 포함(LFI) 또는 원격 파일 포함(RFI) 규칙 집합을 사용하여 부분적으로 완화될 수 있습니다. 예를 들어 LFI 규칙 집합이 적용된 경우 Juice Shop 교차 사이트 이미징 도전과제 악용이 성공하지 못합니다. evaluatePreconfiguredExpr('lfi-stable') ||
evaluatePreconfiguredExpr('rfi-stable')
규칙을 사용해서 LFI 및 RFI 규칙 집합을 사용하여 요청을 차단하고 필요에 따라 규칙을 조정합니다. 도전과제 솔루션이 더 이상 성공하지 않는지 확인할 수 있습니다.
또한 일부 HTTP 공격은 사전 정의된 규칙 집합을 사용하여 완화될 수 있습니다.
- HTTP 동사 조작을 방지하려면 메서드 적용 규칙 집합(미리보기)을 사용합니다.
evaluatePreconfiguredExpr('methodenforcement-stable')
규칙을 사용하여GET
,HEAD
,POST
,OPTIONS
메서드 이외의 HTTP 요청 메서드를 금지합니다. - HTTP 요청 스머글링, HTTP 응답 분할, HTTP 헤더 삽입과 같은 HTTP 파싱 및 프록시에 대한 일반적인 공격을 차단하려면
evaluatePreconfiguredExpr('protocolattack-stable')
규칙을 사용하여 프로토콜 공격 규칙 집합을 사용합니다.
Security Health Analytics
사용 사례:
- 보안 제어 모니터링 및 알림
단일 인터페이스를 통해 수십 개의 신호를 모니터링하여 애플리케이션이 보안 권장사항을 유지 관리하는지 확인합니다.
Web Security Scanner
사용 사례:
- OWASP 상위 10개 항목에 맞게 조정된 Web Application Scanner
- HTTP 서버 구성 오류
- 혼합된 HTTP/HTTPS 콘텐츠
- XML 외부 항목(XXE)
Web Security Scanner는 콘텐츠 유형 불일치, 잘못된 보안 헤더, 혼합 콘텐츠 제공과 같은 일반적인 보안 오류를 모니터링합니다. 또한 Web Security Scanner는 XXE 취약점과 같은 취약점을 모니터링합니다. 이러한 스캔은 OWASP 상위 10개 제어 항목을 포함하도록 설계되었습니다. 다음 감지기는 보안 구성 오류를 검사합니다.
INVALID_CONTENT_TYPE
INVALID_HEADER
MISMATCHING_SECURITY_HEADER_VALUES
MISSPELLED_SECURITY_HEADER_NAME
MIXED_CONTENT
XXE_REFLECTED_FILE_LEAKAGE
이러한 감지기 및 기타 감지기에 대한 자세한 내용은 Web Security Scanner 개요를 참조하세요.
A06: 취약하고 오래된 구성요소
알려진 취약점이 있는 구성요소는 일반적인 공격 벡터의 한 가지 카테고리이며, 이러한 취약점은 모든 애플리케이션 구성요소를 모니터링하고 빠르게 업그레이드함으로써 가장 효과적으로 완화됩니다.
Binary Authorization
사용 사례:
- GKE 클러스터를 신뢰할 수 있는 컨테이너로 제한
Binary Authorization은 신뢰할 수 있는 컨테이너 이미지만 Google Kubernetes Engine(GKE)에 배포되도록 보장하는 배포 시 보안 제어 기능입니다. Binary Authorization을 사용하면 개발 프로세스 중에 신뢰할 수 있는 기관으로부터 이미지에 서명을 받도록 요구하고 이후 배포 시 서명 검증을 실시할 수 있습니다. 검증을 적용하여 빌드 및 출시 프로세스에 확인된 이미지만 사용되도록 보장할 수 있습니다.
Cloud Load Balancing
사용 사례:
- 세밀한 SSL 및 TLS 암호화 제어
Cloud Load Balancing에서 사용할 수 있는 사전 정의된 그룹이나 커스텀 암호화 목록을 할당하여 취약하다고 알려진 SSL 또는 TLS 암호화 사용을 방지합니다.
Container Threat Detection
사용 사례:
- 악성 스크립트 감지
- 역방향 셸 감지
- 멀웨어 설치 감지
공격자가 취약한 구성요소를 악용하여 악성 스크립트를 실행하면 Container Threat Detection의 Malicious Script Executed
감지기가 발견 항목을 생성합니다.
공격자가 역방향 셸을 생성하면 Reverse Shell
감지기가 발견 항목을 생성합니다.
공격자가 멀웨어를 설치하면 Added Binary Executed
및 Added Library Loaded
감지기가 발견 항목을 생성합니다.
Event Threat Detection
사용 사례:
- 암호화폐 채굴 감지
- 멀웨어 감지
- 데이터 무단 반출
- 발신 DoS
Event Threat Detection은 Cloud Logging 스트림을 모니터링하고 세부적인 수준으로 감지 논리 및 위협 인텔리전스를 적용합니다. Event Threat Detection에서 위협을 감지하면 Security Command Center 및 Cloud Logging 프로젝트에 발견 항목을 기록합니다. 다음 감지 규칙은 취약점이 알려진 구성요소를 사용할 때의 효과를 감지하는 데 유용합니다.
- 암호화폐 채굴. 알려진 채굴 주소에 대한 DNS 요청 또는 연결을 기반으로 암호화폐 채굴을 감지합니다.
- 멀웨어. 알려진 잘못된 주소에 대한 멀웨어 기반의 DNS 요청 또는 연결을 감지합니다.
- 외부 테이블에 대한 유출. 복사 또는 전송 작업을 포함하여 조직 외부에 저장된 리소스를 감지합니다.
- 발신 DoS. 서비스 거부 공격을 시도하는 악용된 취약점을 감지합니다.
Google Cloud Armor
사용 사례:
- 사용되지 않는 애플리케이션 엔드포인트에 대한 액세스를 차단합니다.
- 일반적인 공격 벡터 차단
Google Cloud Armor와 같은 웹 애플리케이션 방화벽(WAF)은 공격이 라이브러리와 관련된 경우가 많고 사전 구성된 규칙 집합으로 차단되거나 서버 측에서 패치 적용될 수 없기 때문에 이 카테고리의 공격을 차단하기 위한 단일 완화 전략으로 사용되지 않아야 합니다. 이러한 종류의 취약점을 완화하기 위해서는 애플리케이션의 모든 구성요소를 정기적으로 모니터링하고 업그레이드하는 것이 유일한 옵션입니다.
하지만 Google Cloud Armor는 원격 코드 실행, 로컬 파일 삽입, 원격 파일 삽입에 대해 사전 구성된 규칙을 통해 취약한 애플리케이션에 대한 일반적인 일부 공격을 완화하는 데 도움이 될 수 있습니다.
애플리케이션에서 취약한 구성요소가 인식되었지만, 애플리케이션에 즉시 패치를 적용할 수 없으면 이러한 구성요소가 악용될 위험을 일시적으로 낮추기 위해 애플리케이션에서 해당 부분에 대한 액세스를 차단할 수 있습니다. 이러한 취약한 구성요소에 액세스하는 URL 경로 또는 쿼리와 일치하는 커스텀 규칙을 빌드하고 액세스를 거부합니다. 특정 사용자 또는 위치에서 이러한 구성요소에 액세스해야 하는 경우에는 특정 신뢰할 수 있는 소스 IP 주소가 해당 구성요소에 액세스하도록 허용할 수 있습니다. URL 경로를 사용한 규칙은 다음과 비슷합니다.
`request.path.contains("/component") && !(inIpRange(origin.ip, '1.2.3.4/32')
다음을 바꿉니다.
/component
: 알려진 취약점이 있는 구성요소의 경로입니다.1.2.3.4/32
: 인터페이스에 대해 액세스를 유지해야 하는 IP 주소 범위입니다.
최종 사용자가 절대로 액세스할 필요가 없는 특정 디렉터리 또는 파일 유형과 같이, 애플리케이션에 포함된 부분이 있으면 커스텀 규칙으로 이러한 리소스에 대한 액세스를 제한하거나 차단하여, 해당 구성요소가 이후에 취약해지더라도 위험을 사전에 완화할 수 있습니다.
Google Cloud 보안 게시판
사용 사례:
- 보안 게시판 모니터링
- Google Cloud 제품의 CVE
Google Cloud 보안 게시판은 Google Cloud에 영향을 주는 공인된 보안 게시판입니다. 게시물에는 백그라운드 정보, CVE 링크, 이후 작업을 위한 권장사항이 포함됩니다.
Web Security Scanner
사용 사례:
- 오래된 라이브러리
- 취약점 및 발견 항목 대시보드
웹 애플리케이션에 포함된 오래된 라이브러리를 모니터링합니다. Security Command Center 대시보드에서 이러한 발견 항목을 모니터링합니다.
A07: 식별 및 인증 실패
애플리케이션 인증과 세션 관리는 잘못 구현되는 경우가 많으므로 식별 및 인증 실패는 일반적인 위험입니다. 공격자는 손상된 암호, 키, 세션 토큰과 같은 구현 결점을 악용하여 일시적으로 또는 영구적으로 다른 사용자의 ID를 가장할 수 있습니다.
액세스 투명성
사용 사례:
- 서비스 제공업체 모니터링
- 액세스 근거
일반적으로 외부 제공업체의 직접 지원이 필요하면 임시 사용자 인증 정보를 부여하고 공유해야 했습니다. 이러한 방식은 사용자 인증 정보가 고립되거나 누출될 위험이 있습니다. Access Approval은 계정 지원을 위해 작업하는 Google 직원의 액세스 요청을 승인하거나 거부할 수 있게 해주는 통합 서비스입니다. 각 액세스 요청에는 액세스 근거가 포함되므로, 지원 티켓 참조를 포함하여 각 액세스에 대한 이유를 확인할 수 있습니다.
Apigee
사용 사례:
- 키 검증
- 토큰 검증
- OAuth 정책
Apigee에서는 이 위험으로부터 보호하는 데 도움이 되는 VerifyApiKey, OAuth, JSON 웹 토큰(JWT) 정책을 제공합니다.
API 키 검증은 API에 구성할 수 있는 가장 간단한 형태의 앱 기반 보안입니다. 클라이언트 애플리케이션은 API 키에 해당 요청을 제공합니다. Apigee Edge는 API 프록시에 연결된 정책을 통해 요청되는 리소스에 대해 API 키가 승인 상태인지 확인합니다.
OAuth 2.0 승인 프레임워크는 리소스 소유자와 HTTP 서비스 사이의 승인 상호작용을 조정하여 리소스를 대신해서 또는 타사 애플리케이션이 액세스 권한을 얻을 수 있도록 허용하여 그 자체로 타사 애플리케이션이 HTTP 서비스에 대해 제한된 액세스 권한을 얻을 수 있게 해줍니다.
일반적으로 JSON 웹 토큰(JWT)은 연결된 애플리케이션 간의 클레임 또는 어설션을 공유하기 위해 사용됩니다. Apigee는 세 가지 정책을 사용하여 JWT 지원을 제공합니다.
Event Threat Detection
사용 사례:
- 무작위 공격 감지
- IAM 악용 감지
Event Threat Detection은 Cloud Logging 스트림을 모니터링하고 세부적인 수준으로 감지 논리 및 고유 위협 인텔리전스를 적용합니다. Event Threat Detection이 위협을 감지하면, 선택한 항목 보호를 위해 Security Command Center 및 Cloud Logging에 발견 항목을 기록합니다. 다음 이벤트 유형은 손상된 인증을 식별하는 데 유용합니다.
- 무작위 공격 SSH. 호스트에서 SSH에 대해 성공한 무작위 공격을 감지합니다.
- 비정상적인 권한 부여. Google Cloud 조직 외부의 Identity and Access Management(IAM) 사용자에게 부여된 권한을 감지합니다.
Google Cloud Armor
사용 사례:
- 인증 엔드포인트 액세스 제한
- 승인되지 않은 토큰 사용 제한
손상된 인증 위험으로 분류된 취약점에 대한 공격은 애플리케이션 수준 또는 다른 제어 방식으로 완화하는 것이 가장 좋습니다. 하지만 Google Cloud Armor는 공격 표면을 제한하거나 알려진 공격 벡터를 차단하는 데 도움을 줄 수 있습니다.
예를 들어 애플리케이션에 제한된 사용자 기반이 포함되어 있고 이러한 사용자가 알려진 IP 주소 또는 국가 집합에서 시작되는 경우, 해당 IP 주소 블록 또는 국가에서 시작되는 사용자로 애플리케이션 액세스 권한을 제한하는 보안 정책을 만들 수 있습니다. 이 정책은 이러한 영역 외부의 엔드포인트에서 시작되는 자동화된 스캔에 대한 위험을 완화하는 데 도움을 줄 수 있습니다.
다른 보안 메커니즘으로 암호, 키, 세션 토큰이 손상된 것으로 감지된 경우, 커스텀 규칙을 사용하여 쿼리 문자열에 해당 매개변수가 포함된 요청에 대해 액세스를 제한할 수 있습니다.
securityPolicy.patchRule
메서드를 사용하여 이전에 정의한 규칙을 업데이트할 수 있습니다. HTTP 부하 분산 로그에 대한 이상 감지 메커니즘을 사용하여 잠재적으로 도용되었을 수 있는 토큰을 식별할 수 있습니다.
또한 해당 로그에서 일반적인 암호를 스캔하여 잠재적인 공격자들을 감지할 수도 있습니다.
세션 고정을 위해 설정된 사전 구성된 ModSecurity 규칙 집합을 사용하여 일반적인 세션 고정 공격을 차단할 수 있습니다.
사전 정의된 evaluatePreconfiguredExpr('sessionfixation-stable')
규칙을 보안 정책에 추가하여 규칙 집합을 사용할 수 있습니다.
애플리케이션에 쿼리 문자열의 암호 변경사항이 포함된 경우, request.query
속성과 일치하는 커스텀 규칙을 사용하여 일반적인 암호 사용을 차단할 수도 있습니다. 하지만 이러한 검사는 가능한 경우 애플리케이션 측면에서 구현하는 것이 더 효율적입니다.
IAP(Identity-Aware Proxy)
사용 사례:
- 중앙 집중식 액세스 제어
- 클라우드 및 온프레미스에서 작업
- HTTP 및 TCP 연결 보호
- 컨텍스트 인식 액세스
IAP가 HTTP(S) 부하 분산과 통합되기 때문에 ID 및 컨텍스트를 사용하여 애플리케이션에서 인증 및 승인 벽을 만들 수 있습니다. Identity Platform에서 외부 사용자를 프로비저닝하여 퍼블릭 대면 애플리케이션에 대한 손상된 인증을 방지합니다(자세한 내용은 다음 섹션 참조).
또한 IAP(Identity-Aware Proxy)를 제공하고 Identity and Access Management 또는 Cloud ID로 프로비저닝된 사용자를 인증하여 관리 인터페이스에 대한 손상된 인증을 방지할 수 있습니다. 도구에 액세스하려고 시도하면 인증된 사용자가 요청된 리소스에 액세스할 수 있도록 승인 검사 후 인증 시도가 로깅됩니다.
Identity Platform
사용 사례:
- 서비스로서의 인증
- 다단계 인증
- 엔터프라이즈 SLA
- 광범위한 프로토콜 지원
- Google 계정 보호 인텔리전스
Identity Platform은 Google Cloud 고객을 위한 ID 및 액세스 관리(CIAM) 플랫폼입니다. Identity Platform은 SDK 및 API를 사용하여 멀티 프로토콜을 지원하는 서비스로 보안 인증을 제공할 수 있습니다. 다단계 인증, 타사 인증 서비스와의 통합, 감사 가능한 활동 추적 기능을 제공합니다.
reCAPTCHA Enterprise
사용 사례:
- 자동 로그인 시도
- 콘텐츠 스크래핑
- 사용자 인증 정보 반복 입력
- 허위 트랜잭션
- 계정 탈취
- 허위 계정
- 자금세탁
reCAPTCHA Enterprise는 액세스 시도의 위험 수준을 확인하여 봇과 기타 자동화 및 대량 트래픽 형식에 대해 매우 효과적인 필터링 기능을 제공합니다. 자동 피드백으로 사이트 특정 모델을 조정할 수 있습니다. reCAPTCHA는 사이트에 맞게 이후 점수를 조정합니다.
Security Health Analytics
사용 사례:
- MFA/2FA 적용
- API 키 보호
- API 키 순환 적용
Security Command Center는 다단계 인증 규정 준수 및 API 키의 상태를 모니터링하여 손상된 인증을 방지하는 데 도움을 줍니다. 의심스러운 요청을 식별하고 이를 차단하거나 특별하게 처리하도록 플래그를 지정할 수 있습니다.
Titan 보안 키
사용 사례:
- 피싱 방지 2FA
- 모바일 및 PC 인증
Titan 보안 키는 사용자 이름 및 암호를 제공하더라도 공격자가 사용자 계정에 액세스할 수 없도록 공개 키 암호화를 사용하여 사용자 ID 및 로그인 페이지의 URL을 확인합니다.
Web Security Scanner
사용 사례:
- 세션 식별자 유출
Web Security Scanner는 웹 애플리케이션에 다른 당사자가 사용자를 가장하거나 고유하게 식별할 수 있도록 하는 세션 ID 유출과 같은 취약점이 있는지 검사합니다.
A08: 소프트웨어 및 데이터 무결성 실패
소프트웨어 및 데이터 무결성 실패는 소프트웨어 업데이트, 기밀 데이터 처리 또는 CI/CD 파이프라인의 모든 프로세스 중에 무결성 검사가 발생하지 않으면 발생할 수 있습니다.
Artifact Registry
사용 사례:
- 신뢰할 수 있는 단일 위치에 아티팩트 중앙화
- 버전 관리, 취약점 스캔, 승인 워크플로 사용
Artifact Registry는 조직에서 컨테이너 이미지와 언어 패키지(예: Maven 및 npm)를 관리할 수 있게 해주는 단일 장소입니다. 기존 개발 도구와 통합될 수 있으며 Artifact Analysis를 사용하여 컨테이너에 대한 취약점 스캔을 제공합니다.
Binary Authorization
사용 사례:
- 신뢰할 수 있는 컨테이너만 배포되도록 보장
Binary Authorization에서는 컨테이너 무결성을 확인하므로 신뢰할 수 있는 컨테이너 이미지만 배포됩니다. 증명 유무 여부에 따라 배포를 허용하거나 거부하는 정책을 만들 수 있습니다. Binary Authorization은 클러스터 수준에서 정책을 적용하므로 환경마다 다른 정책을 구성할 수 있습니다. 이러한 구분에서는 환경이 프로덕션에 가까워질수록 점진적 증명 요구사항을 허용합니다.
Cloud 애셋 인벤토리
사용 사례:
검색 서비스
액세스 분석기
데이터 노출에서 가장 일반적인 벡터 중 하나는 고립되었거나 승인되지 않은 IT 인프라입니다. 클라우드 애셋 시계열 데이터를 분석하여 아무도 유지보수하지 않는 서버와 공유 규칙이 너무 포괄적인 버킷을 식별할 수 있습니다.
실시간 알림을 설정하면 보안이 잘못 되었거나 승인되지 않았을 수 있는 리소스의 예기치 않은 프로비저닝을 알립니다.
Cloud Build
사용 사례:
코드 변경사항 검토
테스트 실행
빌드 배포 표준화
Cloud Build를 사용하면 빌드 구성을 만들어 정적 분석, 통합 테스트 실행 등 빌드 배포에 대한 안내를 제공할 수 있습니다.
Google Cloud Armor
사용 사례:
- 원격 코드 실행 차단
소프트웨어 및 데이터 무결성에 대한 대부분의 공격은 애플리케이션에 따라 다르므로 이러한 공격을 완화할 수 있는 몇 가지 방법만 있습니다(예: Google Cloud Armor와 같은 웹 애플리케이션 방화벽(WAF) 사용). OWASP는 신뢰할 수 없는 소스로부터 직렬화된 객체를 허용하지 않을 것을 권장합니다. 가능하다면 다음과 비슷한 거부 규칙을 사용하여 해당 객체를 수락하는 엔드포인트를 신뢰할 수 있는 IP 주소 집합으로만 제한할 수 있습니다.
request.path.contains("/endpoint") && !(inIpRange(origin.ip, '1.2.3.4/32')
다음을 바꿉니다.
/endpoint
: 직렬화된 객체를 수락하는 엔드포인트의 경로입니다.1.2.3.4/32
: 인터페이스에 대해 액세스를 유지해야 하는 IP 주소 범위입니다.
원격 코드 실행(RCE)을 사용하는 소프트웨어 및 데이터 무결성에 대한 일반적인 공격을 완화하려면 RCE 공격에 대한 사전 정의된 규칙 집합을 사용합니다. evaluatePreconfiguredExpr('rce-stable')
규칙을 사용하여 UNIX 및 Windows 셸에서 일반적인 RCE 공격을 차단할 수 있습니다.
안전하지 않은 역직렬화에 대한 Juice Shop 도전과제에 설명된 RCE 공격은 서버의 Node.js에서 함수 및 정규 표현식을 실행합니다. 이러한 종류의 공격은 사전 정의된 RCE 규칙 집합 및 해당 OWASP Modsecurity 규칙으로 차단되지 않으며, 서버 측의 패치 사용 또는 커스텀 규칙으로 완화되어야 합니다.
VirusTotal
사용 사례:
- 신뢰할 수 없는 데이터 스캔
VirusTotal API를 사용하면 파일을 업로드하고 멀웨어를 검사할 수 있습니다. 특정 카테고리의 악의적인 입력을 삭제하기 위해 처리되기 전 이미지, 문서, 바이너리, 기타 신뢰할 수 없는 데이터를 스캔할 수 있습니다.
Web Security Scanner
사용 사례:
- 안전하지 않은 역직렬화
Web Security Scanner는 웹 애플리케이션의 취약점을 검사합니다. 예를 들어 애플리케이션이 원격 명령어 삽입 공격에 취약한 Apache Struts 버전을 사용할 경우 Web Security Scanner는 STRUTS_INSECURE_DESERIALIZATION
발견 항목을 생성합니다.
A09: 보안 로깅 및 모니터링 실패
시스템에서 이슈를 적절하게 로깅, 모니터링, 관리하지 않을 경우, 공격자가 데이터 및 소프트웨어에 대해 더 심층적이고 더 장기적인 방법으로 공격을 수행할 수 있습니다.
액세스 투명성
사용 사례:
- 서비스 제공업체 액세스 모니터링 및 감사
- 액세스 근거
- 리소스 및 메서드 식별
클라우드 제공업체 액세스를 감사할 수 없으면 온프레미스에서 클라우드로 마이그레이션하는 데 지장이 생길 수 있습니다. 액세스 투명성은 클라우드 제공업체 액세스의 검증을 가능하게 하여 온프레미스 조건에서 하는 것과 가까운 감사 제어를 할 수 있습니다. 관련 지원 티켓에 대한 참조를 포함하여 각 액세스의 이유를 기록할 수 있습니다. 여기에는 리소스와 리소스가 액세스되는 메서드 식별 이름, 어느 관리자가 어느 메서드를 실행했는지에 대한 정보가 포함됩니다. 액세스 승인 기능을 사용하면 서비스 지원 업무를 담당하는 Google 직원의 액세스 요청을 승인하거나 무시할 수 있습니다.
Apigee
사용 사례:
- SIEM으로 Apigee 로그 내보내기
- Apigee 모니터링 UI 사용
- 모니터링 권장사항 따르기
Apigee에는 로깅, 모니터링, 오류 처리, 감사 로깅을 수행하기 위한 몇 가지 방법이 있습니다.
- 로깅
- 로그 메시지는 MessageLogging 정책을 사용하여 Splunk 또는 기타 syslog 엔드포인트로 전송될 수 있습니다.
- API 분석 데이터는 Analytics API를 통해 가져오고 다른 시스템으로 가져오거나 내보낼 수 있습니다.
- 프라이빗 클라우드용 Edge에서 MessageLogging 정책을 사용하여 로컬 로그 파일에 기록할 수 있습니다. 실행되는 각 구성요소의 로그 파일도 사용할 수 있습니다.
- 자바스크립트 정책을 사용하여 로그 메시지를 REST 로깅 엔드포인트에 동기 또는 비동기로 전송할 수 있습니다.
- 모니터링
- 오류 처리
- Apigee는 API 프록시에 대해 강력하고 다양한 결함 처리 메커니즘을 제공합니다. 자바 프로그램이 예외를 캐치하는 것과 비슷하게, API 프록시는 결함을 캐치하고 적절한 응답을 클라이언트에 반환할 방법을 결정할 수 있습니다.
- Apigee 커스텀 오류 처리를 사용하면 오류가 발생할 때마다 메시지 로깅과 같은 기능을 추가할 수 있습니다.
- 감사 로그
- Apigee 플랫폼은 API 프록시, 제품, 조직 기록에 대한 변경사항을 추적하는 감사 로그를 유지 관리합니다.
- 이 로그는 UI 또는 Management API를 통해 제공됩니다.
Google Security Operations
사용 사례:
- 위협 감지
- 조기 경고
강력한 탐지 규칙을 통합 데이터 집합에 적용할 수 있도록 보안 팀에서 Google Security Operations에 보안 원격 분석을 전송할 수 있습니다.
Sensitive Data Protection
사용 사례:
- 민감한 정보 자동 마스킹
로그 스트림에서 규정 준수에 필요한 민감한 정보를 식별하고 로그에 기록되기 전 이를 적절하게 마스킹 또는 변환합니다. 예를 들어 신용카드 번호 또는 개인 식별 정보와 같이 마스킹해야 하는 민감한 정보가 오류 메시지 또는 코어 덤프에 포함될 수 있습니다.
Cloud Key Management Service
사용 사례:
- 암호화 키 요청 이벤트 로깅
- 액세스 근거
키 액세스 근거는 기술된 근거 및 해당 요청의 승인 또는 거부 기록을 로깅하여 암호화 키의 모든 요청에 대한 시간별 가시성을 제공합니다.
Cloud Logging
사용 사례:
- 로그 집계
- 로그 스토리지
- 로그 검색
- 로그 분석
Cloud Logging을 사용하면 Google Cloud 및 Amazon Web Services의 로깅 데이터와 이벤트를 저장, 검색, 분석, 모니터링하고 알림을 받을 수 있습니다. 여기에는 150개 이상의 일반적인 애플리케이션 구성요소, 온프레미스 시스템, 하이브리드 클라우드 시스템으로부터 로깅 데이터를 수집하기 위해 사용할 수 있는 BindPlane 서비스에 대한 액세스가 포함됩니다.
Cloud Monitoring
사용 사례:
- 로그 모니터링
- 이벤트 알림
Cloud Monitoring은 클라우드 기반 애플리케이션의 성능, 업타임, 전반적인 상태에 관한 정보를 제공합니다. 여러 채널을 통해 모니터링 대시보드, 이벤트 모니터, 알림을 제공합니다.
Cloud Source Repositories
사용 사례:
- 코드 변경 기여
- 감사 로깅 액세스
Cloud Source Repositories에서 생성된 Cloud 감사 로그를 사용하여 시간 및 위치를 포함하여 저장소에서 수행된 작업에 대한 유용한 정보를 파악할 수 있습니다.
Error Reporting
사용 사례:
- Cloud Logging에서 내부 애플리케이션 오류 캡처
- 비정상적으로 종료된 컴퓨팅 인스턴스 외부의 비정상 종료 보고서 수집
내부 애플리케이션 오류는 보안 문제, 손상된 기능, 보안 우회 시도를 나타낼 수 있습니다. Error Reporting은 실행 중인 클라우드 서비스의 비정상 종료를 집계, 분석, 종합하며 중앙 오류 관리 인터페이스에 정렬 및 필터링 기능과 함께 결과를 표시해 줍니다. 전용 뷰에 시간 차트, 발생 횟수, 문제가 발생한 사용자 수, 최초 및 최근 발견 날짜, 정리된 예외 스택 트레이스 등 오류 세부정보가 표시됩니다. 새로운 오류에 대한 이메일 및 모바일 알림 수신도 가능합니다.
Event Threat Detection
사용 사례:
- 무작위 공격
- 암호화폐 채굴
- IAM 악용
- 멀웨어
- 피싱
Event Threat Detection은 Cloud Logging 스트림을 모니터링하고 세부적인 수준으로 감지 논리 및 고유 위협 인텔리전스를 적용합니다. Event Threat Detection은 로그에서 눈에 띄는 항목을 식별하고 검토할 수 있도록 이를 승격합니다. Event Threat Detection은 위협을 감지하면 Security Command Center 및 Cloud Logging 프로젝트에 이 발견 항목을 기록합니다.
Forseti Inventory
사용 사례:
- 인벤토리 변경 모니터링 및 알림
Forseti Inventory는 Google Cloud 리소스의 인벤토리 스냅샷을 데이터베이스에 저장하므로 리소스에 대한 이전 레코드가 제공됩니다. 이 정보를 통해 Google Cloud에 있는 모든 리소스를 파악하고 리소스 보존, 비용 감소, 보안 노출 최소화를 위해 조치를 취할 수 있습니다. 원하는 만큼 자주 실행되도록 인벤토리를 구성하고 리소스 스냅샷을 업데이트할 때 이메일 알림을 보낼 수 있습니다.
Google Cloud Armor
사용 사례:
- 보안 정책 로깅
- 모니터링 대시보드
- 트래픽 이상 알림
Google Cloud Armor 요청 로그는 외부 애플리케이션 부하 분산기를 위한 Cloud Logging의 일부입니다. 트래픽과 일치하는 보안 정책 규칙 등과 같이 로깅 정보에 액세스하기 위해서는 보안 정책이 연결된 모든 백엔드 서비스에서 로깅을 사용 설정합니다. 미리보기 모드의 규칙을 사용하여 효과를 적용하지 않고 규칙을 테스트하고 결과를 로깅할 수 있습니다.
Google Cloud Armor는 또한 보안 정책에 따라 통과했거나 거부된 트래픽 양에 대한 개요를 얻을 수 있게 해주는 보안 정책에 대한 모니터링 대시보드를 제공합니다. Google Cloud Armor는 Security Command Center에서 허용된 트래픽에서의 갑작스러운 증가 또는 거부된 트래픽의 증가와 같은 트래픽 이상에 대한 발견 항목을 게시합니다.
Google Cloud Armor는 리소스의 구성 또는 메타데이터를 수정하는 작업을 기록하는 관리자 활동 감사 로그를 자동으로 작성합니다. 또한 리소스의 구성 또는 메타데이터를 읽는 API 호출뿐만 아니라 사용자가 제공한 리소스 데이터를 생성, 수정 또는 읽는 사용자 주도 API 호출을 포함하는 데이터 액세스 감사 로그를 작성하도록 이 서비스를 구성할 수 있습니다.
Identity Platform
사용 사례:
- 관리 활동 감사 로그
- 데이터 액세스 감사 로그
- 시스템 이벤트 감사 로그
- 정책 거부 감사 로그
- 인증 활동 로그
Identity Platform은 기본적으로 인증 활동을 로깅하는 Google Cloud의 사용자 대상 ID 및 액세스 관리 플랫폼입니다.
관리 활동, 데이터 액세스, 시스템 이벤트, 거부된 인증 시도를 포함하여 몇 가지 강력한 감사 로그를 사용 설정합니다.
Security Command Center
사용 사례:
- 알림 모니터링
- 위협 관리
- 취약점 스캔 보고
- 규정 준수 모니터링
- 애셋 모니터링
- 보안 스캔 발견 항목
개요 패널에서 보안 수준별로 조직 내 총 발견 항목 수를 확인합니다. 위협 대시보드를 사용하여 조직의 Google Cloud 리소스에서 잠재적으로 위험한 이벤트를 검토합니다. 취약점 탭에서 Security Health Analytics 발견 항목 및 권장사항을 확인합니다.
규정 준수 대시보드에서 PCI-DSS, CIS Google Cloud Computing Foundations Benchmark 등의 제어 기능으로 규정 준수를 지속적으로 모니터링할 수 있습니다. 애셋 보기에서는 조직 내에서 애셋이라고 부르는 모든 Google Cloud 리소스에 대한 세부 표시를 제공합니다. 애셋 탭에서는 전체 조직의 애셋을 보거나, 특정 프로젝트 내, 애셋 유형 또는 변경 유형별로 애셋을 필터링할 수 있습니다. 마지막으로 발견 항목 탭에는 잠재적인 보안 위험을 볼 수 잇도록 모든 조직 애셋에 대한 자세한 발견 항목 인벤토리가 표시됩니다.
A10: 서버 측 요청 위조(SSRF)
SSRF 공격은 공격자가 강제로 취약한 서버에서 타사 서버나 내부 리소스에 원치 않는 악성 요청을 트리거하도록 하면 발생합니다. SSRF 결함은 웹 애플리케이션이 사용자가 제공한 URL을 검증하지 않고 원격 리소스를 가져오면 발생할 수 있습니다.
Apigee
사용 사례:
- LFI 또는 RFI를 사용하여 SSRF 공격 차단
Apigee에는 XPath 또는 JSONPath를 사용하여 데이터를 추출하는 XML 및 JSON 파서가 기본 제공됩니다. 여기에는 악의적인 XML 페이로드로부터 보호하기 위한 XMLThreatProtection 정책과 악의적인 JSON 페이로드로부터 보호하는 데 도움이 되는 JSONThreatProtection 정책이 있습니다.
Apigee ExtractVariables 정책을 사용하면 요청 또는 응답으로부터 콘텐츠를 추출하고 이 콘텐츠를 변수에 할당할 수 있습니다. 헤더, URI 경로, JSON 및 XML 페이로드, 양식 매개변수, 쿼리 매개변수를 포함하여 메시지의 모든 부분을 추출할 수 있습니다. 이 정책은 메시지 콘텐츠에 텍스트 패턴을 적용하고 일치하는 항목을 찾으면 지정된 메시지 콘텐츠로 변수를 설정하는 방식으로 작동합니다.
Google Cloud Armor
사용 사례:
- LFI 또는 RFI를 사용하여 SSRF 공격 필터링
SSRF 공격은 복잡하고 다양한 형식으로 사용될 수 있으므로 웹 애플리케이션 방화벽에 의한 완화 가능성이 제한됩니다. XML 또는 JSON 파서에 패치를 적용하고 외부 항목을 금지하고 공개 웹 서버의 XML 또는 JSON 데이터 전송을 최솟값으로 제한하면 공격을 효과적으로 완화할 수 있습니다. 하지만 애플리케이션 및 공격 유형에 따라 Google Cloud Armor는 데이터 무단 반출 및 기타 영향을 계속 방어할 수 있습니다.
OWASP ModeSecurity Core Rule Set의 어떠한 규칙도 SSRF 공격을 특별히 방어하지는 않지만 로컬 파일 포함(LFI) 및 원격 파일 포함(RFI) 규칙으로 이러한 공격 중 일부를 방어할 수 있습니다. 공격자가 서버의 로컬 파일을 검색하지 못하도록 하려면 Google Cloud Armor 보안 정책의 evaluatePreconfiguredExpr('lfi-stable')
규칙을 사용합니다.
SSRF Juice Shop 도전과제에서는 사전 구성된 원격 파일 포함(RFI) 또는 로컬 파일 포함(LFI) 규칙 집합을 사용하여 URL 또는 경로 순회 포함을 차단하므로 이러한 공격 중 일부를 완화할 수 있습니다. 예를 들어 다음 규칙은 두 규칙 집합을 모두 사용 설정합니다.
evaluatePreconfiguredExpr('lfi-stable') ||
evaluatePreconfiguredExpr('rfi-stable')
이러한 규칙을 구현하면 SSRF 도전과제에 대한 솔루션도 작동하지 않습니다.
VPC 서비스 제어
사용 사례:
- 서버를 분할하는 네트워크 경계
SSRF 공격의 영향을 줄이려면 VPC 서비스 제어를 사용하여 조직의 다른 리소스에서 서버를 분할하는 경계를 만들면 됩니다. 이러한 경계는 데이터 무단 반출을 방지합니다. 시행 모드에서 실행되는 경우 제한된 서비스에 대한 API 요청은 경계의 필수 인그레스 및 이그레스 규칙 조건이 충족되지 않으면 경계를 넘어가지 않습니다.
Virtual Private Cloud(VPC) 방화벽
사용 사례:
- 필수 인트라넷 트래픽을 제외한 모든 트래픽을 차단하려면 '기본적으로 거부' 방화벽 정책이나 네트워크 액세스 제어 규칙을 시행합니다.
VPC 방화벽은 프로젝트와 VPC 네트워크의 인바운드 및 아웃바운드 트래픽에 적용됩니다. 허용하려는 트래픽을 제외한 모든 트래픽을 차단하는 방화벽 규칙을 만들 수 있습니다. 자세한 내용은 VPC 방화벽 규칙 개요를 참조하세요.
Web Security Scanner
사용 사례:
- 웹 애플리케이션 모니터링
Web Security Scanner는 웹 애플리케이션의 취약점을 검사합니다. 예를 들어 애플리케이션이 서버 측 요청 위조에 취약한 경우 Web Security Scanner가 SERVER_SIDE_REQUEST_FORGERY
발견 항목을 생성합니다.
다음 단계
- Google Cloud에서 웹 애플리케이션 및 API 보호
- OWASP 상위 10개 항목
- Google Cloud 보안 게시판
- Google Cloud Security Best Practices Center
- 규정 준수 제품
- Google Cloud용 CIS 벤치마크
- Security Command Center
- Apigee
- Google Cloud Armor
- 모든 Google Cloud 보안 제품
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항을 살펴봅니다. Cloud 아키텍처 센터 살펴보기