Google Cloud에서 OWASP Top 10:2025 완화

이 문서에서는 OWASP Top 10:2025에 설명된 애플리케이션 수준 공격을 방어하는 데 도움이 되는 Google Cloud 서비스와 완화 전략을 식별합니다. Open Web Application Security (OWASP) 재단에서 만든 OWASP 상위 10개:2025는 소프트웨어 개발 주기 (SDLC)의 상위 10개 보안 위험 목록입니다. 어떠한 서비스도 이러한 위험 요소들에 대해 완전한 보호를 보장할 수 없지만, 해당 아키텍처에 적합할 때 이러한 서비스를 적용하면 강력한 멀티 레이어 보안 솔루션을 만드는 데 도움을 줄 수 있습니다.

Google 인프라는 강력한 보안 제어를 통해 서비스를 빌드, 배포, 운영하는 데 도움이 되도록 설계되었습니다. 물리적 및 운영적 보안, 저장 데이터 암호화 및 전송 중 데이터 암호화, 기타 여러 기본 인프라 보호 조치는 Google에서 관리합니다. 애플리케이션을 Google Cloud에 배포하면 이러한 혜택을 이용할 수 있지만 특정 공격으로부터 애플리케이션을 보호하기 위해 추가 조치가 필요할 수 있습니다.

참고: Google Cloud 는 강력한 경계 및 런타임 방어를 제공하지만 보안은 공동 책임입니다. OWASP 위험을 효과적으로 완화하려면 소프트웨어 개발 수명 주기 (SDLC) 초기에 보안을 통합해야 합니다. 기본적으로 보안이 적용되는 코딩 프레임워크, 정기적인 개발자 교육, 사전 대응형 위협 모델링과 함께 다음 서비스를 사용하세요.

규정 준수 매트릭스

다음 표에 나열된 Google Cloud 서비스는 OWASP Top 10:2025에서 식별된 상위 10개 보안 위험으로부터 보호하는 데 도움이 될 수 있습니다.

OWASP Top 10:2025 카테고리	기본 Google Cloud 및 Wiz 컨트롤
A01: 손상된 액세스 제어	Access Context Manager, Agent Gateway, 에이전트 ID, Apigee, Google Cloud Armor, Firebase 앱 체크, Firebase 보안 규칙, Cloud Next Generation Firewall (Cloud NGFW), ID 인식 프록시 (IAP), ID 및 액세스 관리 (IAM), 조직 정책 서비스, VPC 서비스 제어, Wiz Cloud
A02: 잘못된 보안 구성	Access Context Manager, Cloud 애셋 인벤토리, Google Security Operations, 조직 정책, Security Command Center Premium, VPC 서비스 제어, Wiz Cloud
A03: 소프트웨어 공급망 실패	Artifact Registry, Assured Open Source Software (Assured OSS), Binary Authorization, Cloud Build, Cloud Deploy, Cloud Workstations, CodeMender, Wiz Code
A04: 암호화 실패	Apigee, Certificate Authority Service, 인증서 관리자, Cloud Key Management Service, Cloud Load Balancing, Cloud Workstations, 컨피덴셜 컴퓨팅, 조직 정책, Secret Manager, Sensitive Data Protection, Wiz Cloud
A05: 삽입	Apigee, Cloud Armor, CodeMender, Firebase 보안 규칙, Cloud Next Generation Firewall (Cloud NGFW), Model Armor, Security Command Center Premium, VirusTotal, Wiz Code
A06: 안전하지 않은 설계	Apigee, CodeMender, Mandiant, Wiz Cloud
A07: 인증 실패	Access Context Manager, 에이전트 ID, Apigee, Cloud Armor, Cloud Identity, Firebase 앱 체크, Firebase 인증, Google Cloud Fraud Defense, IAM (Privileged Access Manager, 워크로드 아이덴티티 제휴, 직원 ID 페더레이션), IAP, Identity Platform, Security Command Center Premium, Secret Manager, Titan 보안 키, Wiz Code
A08: 소프트웨어 또는 데이터 무결성 실패	Artifact Analysis, Assured OSS, Binary Authorization, Cloud Armor, Cloud Build, Cloud Deploy, Firebase 앱 체크, Security Command Center Premium, VirusTotal, Wiz Defend
A09: 보안 로깅 및 알림 실패	액세스 승인 및 액세스 투명성, Apigee, Google SecOps, Cloud Logging, Cloud Monitoring, Sensitive Data Protection, Wiz Defend
A10: 예외 조건의 잘못된 처리	Cloud Armor, Cloud Load Balancing, Error Reporting, Model Armor

Google Cloud 서비스

다음 섹션에서는 핵심Google Cloud 서비스에 관한 OWASP Top 10 권장사항을 설명합니다.

액세스 승인 및 액세스 투명성

액세스 투명성 및 액세스 승인을 사용하면 클라우드 제공업체 액세스를 확인할 수 있습니다. 액세스 투명성을 사용하면 Google 직원이 액세스하는 이유를 기록할 수 있습니다. 액세스 승인 기능을 사용하면 서비스 지원 업무를 담당하는 Google 직원의 액세스 요청을 승인하거나 무시할 수 있습니다.

A09: 보안 로깅 및 알림 실패에 적용됩니다.

다음 권장사항을 검토하세요.

• 액세스 승인 프로세스를 자동화합니다. 이렇게 하려면 액세스 승인이 수신 액세스 승인 요청 메타데이터를 Pub/Sub 주제로 전송하도록 구성하세요. 처리할 JSON 페이로드를 인증된 Cloud Run 서비스, Cloud Run 함수, 엔터프라이즈 API 게이트웨이와 같은 맞춤 웹훅 엔드포인트로 푸시하는 Pub/Sub 구독을 만듭니다.
• 액세스 투명성 로그를 중요한 보안 원격 분석으로 취급합니다. Monitoring에서 로그 기반 측정항목과 알림 정책을 만들어 Google 직원이 활성 상태의 해당 지원 티켓 없이 민감한 리소스에 액세스하는 경우 보안 운영 센터 (SecOps)에 알립니다.
• Google SecOps 또는 중앙 집중식 엔터프라이즈 SIEM으로 액세스 투명성 로그를 직접 내보냅니다.
• 규정 준수 정책을 만들어 로그 스트림을 정기적으로 감사하고 auto_approved 긴급 액세스 이벤트가 문서화된 심각도 높은 인시던트와 상관관계가 있는지 확인합니다.
• 암호화 제어를 위해 키 액세스 근거를 사용하여 시스템이 프로그래매틱 방식으로 키 복호화 승인을 요청하도록 강제합니다.

Access Context Manager

Access Context Manager는Google Cloud의 컨텍스트 인식 액세스 엔진입니다. Access Context Manager를 사용하면 IAP, VPC 서비스 제어, IAM에 대한 속성 기반 액세스 수준 (예: 클라이언트 IP 주소 범위, 기기 보안 상황, 지리적 위치)을 정의할 수 있습니다.

적용 대상:

• A01: 손상된 액세스 제어
• A02: 잘못된 보안 구성
• A07: 인증 실패

A01: 손상된 액세스 제어에 관한 다음 권장사항을 검토하세요.

• 조직의 액세스 정책에 재사용 가능한 계층화된 보안 수준을 빌드합니다. 표준 속성을 테스트하기 위해 기본 액세스 수준을 만듭니다. 복잡한 다중 요인 조건의 경우 맞춤 액세스 수준을 배포하여 고급 기기 상태와 서드 파티 엔드포인트 신호를 평가합니다.
• 엔드포인트 확인 또는 Chrome Enterprise Core를 사용하여 전체 디스크 암호화, 활성 화면 잠금, 승인된 운영체제 버전과 같은 기기 수준 제약 조건을 적용합니다.
• VPC 서비스 제어로 가치가 높은 데이터 저장소를 보호하려면 VPC 서비스 제어 인그레스 규칙에 액세스 수준을 추가하세요. 서비스 계정 키가 유출되더라도 공격자는 키만 사용하여 승인되지 않은 공개 IP 주소나 신뢰할 수 없는 머신에서 BigQuery 또는 Cloud Storage를 쿼리할 수 없습니다.
• 웹 애플리케이션 및 VM 관리 터널로 제로 트러스트 보호를 확장하려면 IAP 보안 리소스에 직접 액세스 수준을 연결하세요.

A02: 보안 구성 오류에 관한 다음 권장사항을 검토하세요.

• 특정 폴더에 바인딩된 범위가 지정된 액세스 정책을 구현하여 개별 프로젝트 팀에 로컬 정책 관리를 위임하고 조직의 나머지 부분에서 변경사항을 격리합니다.
• 고아 인그레스 규칙이 무음 백도어가 되지 않도록 정기적으로 폐기된 IP 범위, 만료된 파트너 서브넷, 오래된 기기 속성을 검토하고 삭제하세요.

A07: 인증 실패에 관한 다음 권장사항을 검토하세요.

• 사용자 액세스 바인딩을 사용하여 엄격한 최대 세션 기간을 설정합니다. SECURITY_KEY (FIDO2 또는 WebAuthn)를 요구하도록 재인증 정책을 구성합니다. 고위험 환경에 더 엄격한 제약 조건을 적용하려면 민감한 애플리케이션의 기본 세션 기간을 재정의하도록 scopedAccessSettings를 구성하세요.

Agent Gateway 및 Agent Identity

에이전트 게이트웨이 및 에이전트 ID는 AI 에이전트 및 에이전트형 워크플로를 위한 전용 네트워크 정책 적용, ID 수명 주기 관리, 암호화 인증을 제공합니다.

적용 대상:

• A01: 손상된 액세스 제어
• A07: 인증 실패

A01: 손상된 액세스 제어에 관한 다음 권장사항을 검토하세요.

• 멀티 에이전트 시스템, 외부 MCP 도구 또는 자율 파이프라인이 있는 환경에서는 에이전트 게이트웨이를 전용 네트워크 및 정책 시행 지점으로 사용하여 에이전트 액세스 제어 실패를 완화하세요.
• 에이전트 ID에 대해 세부 승인 정책을 구성하여 도구 액세스 및 데이터 검색을 에이전트의 특정 워크플로에 필요한 리소스로만 제한합니다.

A07: 인증 실패에 관한 다음 권장사항을 검토하세요.

• 정적 API 키나 비밀번호를 삽입하지 않고 자율 에이전트와 도구 통합을 인증하려면 각 에이전트에 에이전트 ID를 생성하고 할당하세요.
• X.509 인증서를 에이전트의 사용자 인증 정보로 발급하도록 에이전트 ID를 구성합니다. 이러한 인증서는 액세스 토큰이 가로채진 경우 다른 환경에서 해당 토큰을 사용할 수 없도록 하여 토큰 도용을 방지하는 데 도움이 됩니다.

Apigee

Apigee는 API 프록시를 사용하여 암호화 표준을 적용하고, 서명된 페이로드를 검증하고, 전송 중 및 저장 중인 애플리케이션 데이터를 암호화하는 중앙 집중식 게이트웨이 수준 메커니즘을 제공합니다. API 트래픽의 리버스 프록시 게이트웨이 역할을 하는 Apigee는 경계 및 구조 검사를 실행하여 페이로드를 검증합니다. Apigee는 강력한 ID 경계를 설정하기 위해 기본 제공 API 인증, OAuth, JSON 웹 토큰 (JWT) 확인 정책을 제공합니다. Apigee에는 로깅, 모니터링, 오류 처리, 감사 로깅을 수행하기 위한 몇 가지 방법이 있습니다.

적용 대상:

• A01: 손상된 액세스 제어
• A04: 암호화 실패
• A05: 삽입
• A06: 안전하지 않은 설계
• A07: 인증 실패
• A09: 보안 로깅 및 알림 실패

A01: 손상된 액세스 제어에 관한 다음 권장사항을 검토하세요.

• API 프록시를 사용하여 다음을 완료합니다.

  • 공격자가 API 요청 경로에서 ID 변수를 조작하여 다른 사용자의 기록에 액세스하려고 하는 요청을 가로챕니다.

  • 표준 클라이언트가 제한된 관리 메서드 또는 높은 권한 작업을 실행하지 못하도록 차단

• API 관리 플레인의 경우 암호화된 키-값 맵, Secret Manager 또는 Kubernetes 보안 비밀(하이브리드 배포만 해당)을 사용하여 액세스 제어, 인증, 보안 비밀 스토리지를 적용합니다.

• OAuth 정책 및 JWT 토큰을 사용하여 서명을 확인합니다. 민감한 엔드포인트와 작업을 높은 권한의 세부적인 OAuth 범위 (예: delete:account 또는 write:billing)에 매핑합니다. OAuthV2 정책을 사용하여 API 진입점에서 이러한 범위를 검증하고 올바른 권한이 없는 클라이언트에는 HTTP 403 Forbidden 상태 코드를 반환합니다.

• 지능화된 API 보안을 사용 설정하여 이상 동작 패턴에 대한 트래픽을 분석하고 보안 작업을 시작합니다.

A04: 암호화 실패에 관한 다음 권장사항을 검토하세요.

• 애플리케이션에서 민감한 정보를 암호화하고 트래픽이 백엔드 애플리케이션에 도달하기 전에 엄격한 암호화 유효성 검사를 적용합니다. Cloud KMS를 사용하여 고객 관리 암호화 키(CMEK)로 Apigee 환경을 구성합니다.
• 단방향 및 양방향 TLS를 사용하여 프로토콜 수준에서 민감한 정보를 암호화합니다. 서버 간 또는 위험도가 높은 비즈니스 통합의 경우 Apigee 인그레스 게이트웨이에서 상호 TLS(mTLS)를 구성합니다.
• VerifyJWT 및 VerifyJWS 정책을 사용하여 요청이 처리되기 전에 수신 토큰에 유효한 암호화 서명이 있어야 합니다. 표준 OAuth 기법을 사용하고 HMAC, 페이로드 해싱, 상태 또는 nonce 검증, PKCE (Proof Key for Code Exchange)를 구현하여 각 요청을 암호화 방식으로 강화하는 것이 좋습니다.
• Apigee 디버그 도구를 사용할 때 데이터가 암호화되고 숨겨지도록 민감한 정보를 마스킹합니다.

A05: 주입에 관한 다음 권장사항을 검토하세요.

• Apigee 위협 보호 정책을 배포하여 입력 매개변수를 정리하고 게이트웨이 레이어에서 SQL, NoSQL, 명령 삽입 시도를 차단합니다.
  • JSONThreatProtection
  • XMLThreatProtection
  • RegularExpressionProtection
  • SOAPMessageValidation

A06: 안전하지 않은 설계에 관한 다음 권장사항을 검토하세요.

• OpenAPI 사양에 대해 수신 요청 또는 응답 메시지에 대한 OASValidation 정책으로 수신 요청을 검증합니다.
• SpikeArrest 정책과 Quota 정책을 구현하여 트래픽 급증과 백엔드 과부하를 완화합니다.
• 오류 처리 규칙을 사용하여 백엔드 오류 (예: 데이터베이스 비정상 종료)를 가로채고 일반 HTTP 응답으로 다시 작성합니다.

A07: 인증 실패에 관한 다음 권장사항을 검토하세요.

• Apigee가 클라이언트 애플리케이션의 API 키가 있고 유효하며 요청된 API 리소스에 액세스할 권한이 있는지 확인할 수 있도록 개발자용 API에 API 키 유효성 검사를 구현합니다.
• 세션 토큰 도용 및 재생 공격을 방지하려면 소유 증명(DPoP)을 구현하세요. DPoP는 토큰 재전송을 완화하기 위해 토큰을 발신자의 공개 키에 바인딩합니다.
• SpikeArrest 비율 제한과 reCAPTCHA Enterprise 통합을 결합하여 자동 무차별 대입 공격으로부터 토큰 생성 및 로그인 엔드포인트를 보호하세요.

A09: 보안 로깅 및 알림 실패에 관한 다음 권장사항을 검토하세요.

• 구조화된 API 트랜잭션 메타데이터를 로깅 또는 서드 파티 SIEM에 비동기식으로 스트리밍합니다. 응답이 클라이언트에 전달된 후에 실행되는 PostClientFlow에 MessageLogging 정책을 연결합니다.
• 플랫폼 감사 로그를 중앙 집중화하여 API 프록시, 사용자 인증 정보, 배포 환경의 수정사항을 추적합니다. 승인되지 않은 프록시 수정사항이 눈에 띄지 않게 되는 것을 방지하려면 Apigee를 Cloud 감사 로그와 통합하세요. 자세한 내용은 Apigee 감사 로깅 및 Apigee API 관리 감사 로깅을 참고하세요.
• 모니터링에서 지능화된 API 보안 알림을 구성하여 자동화된 스크래핑 캠페인, 사용자 인증 정보 악용, 보안 점수 회귀를 SecOps팀에 알립니다.
• escapeJSON() 함수로 래핑하여 로그 메시지 템플릿에서 사용자가 제공한 변수를 정리합니다.
• 로그 메타데이터를 외부 SIEM으로 스트리밍하는 경우 TLS를 통한 Syslog (TCP 포트 6514)를 사용하여 전송 중인 데이터를 암호화하도록 MessageLogging 정책을 구성합니다.

Artifact Registry 및 Artifact Analysis

Artifact Registry는 조직이 컨테이너 이미지와 언어 패키지를 한곳에서 관리할 수 있게 해줍니다. Artifact Analysis는 Artifact Registry에 저장된 아티팩트에 대한 통합 취약점 스캔, 소프트웨어 재료명세서 (SBOM) 생성, 메타데이터 스토리지를 제공합니다.

적용 대상:

• A03: 소프트웨어 공급망 실패
• A08: 소프트웨어 또는 데이터 무결성 실패

A03: 소프트웨어 공급망 실패에 관한 다음 권장사항을 검토하세요.

• 미리 정의된 보관 기간이 지난 후 버전이 지정되지 않았거나 태그가 지정되지 않았거나 비활성 출시 후보 이미지를 삭제하도록 정리 정책을 구성하여 공격 표면을 줄이고 취약한 기존 이미지의 배포를 방지합니다.
• 공개 레지스트리보다 내부 아티팩트 저장소를 우선시하는 업스트림 저장소 우선순위로 가상 저장소를 구성하여 종속 항목 혼동 공격으로부터 보호하세요.
• 변경할 수 없는 이미지 태그를 적용하거나 암호화 다이제스트(sha256:...)로 엄격하게 배포하여 태그 변이 공격을 방지합니다.

A08: 소프트웨어 또는 데이터 무결성 실패에 관한 다음 권장사항을 검토하세요.

• Artifact Analysis에서 자동 취약점 스캔 및 SBOM 생성을 사용 설정하여 배포 전에 심각한 CVE를 감지합니다.
• Artifact Analysis 메타데이터를 Binary Authorization 증명과 통합하여 보안 기준을 충족하지 않는 이미지의 배포를 차단합니다.

Assured OSS

Assured OSS를 사용하면 Google에서 검증하고 사용하는 OSS 패키지를 자체 개발자 워크플로에 통합할 수 있습니다.

적용 대상:

• A03: 소프트웨어 공급망 실패
• A08: 소프트웨어 또는 데이터 무결성 실패

A03: 소프트웨어 공급망 실패에 관한 다음 권장사항을 검토하세요.

• Assured OSS를 업스트림으로 가리키도록 원격 저장소를 구성합니다.
• 빌드의 오픈소스 라이브러리에 유효한 Google 서명과 검증 가능한 SLSA 빌드 출처 기록이 포함되어 있는지 확인합니다. 애플리케이션 바이너리를 컴파일하기 전에 이러한 증명을 확인하도록 Cloud Build에서 품질 게이트를 구성합니다.
• Cloud Workstations 기본 이미지에서 패키지 관리자 (예: pip.conf, settings.xml, build.gradle)가 내부 Assured OSS 저장소만 가리키도록 구성합니다.
• Assured OSS에서 생성된 메타데이터를 사용하여 오픈소스 패키지에서 새로 공개된 CVE가 특정 배포 컨텍스트에서 악용될 수 있는지 확인합니다.

A08: 소프트웨어 또는 데이터 무결성 실패에 관한 다음 권장사항을 검토하세요.

• Artifact Registry에서 가상 업스트림 저장소를 구성하여 Google에서 확인한 암호화 서명을 적용함으로써 빌드 파이프라인 전반에서 패키지 무결성을 강화합니다.
• Assured OSS 프리미엄 등급 (Security Command Center Premium의 일부)을 사용하여 저장소 프로비저닝을 자동화하고, 선별된 JavaScript (npm) 패키지에 액세스하고, 패키지 메타데이터 및 취약점 알림에 액세스합니다.

Binary Authorization

Binary Authorization에서는 컨테이너 무결성을 확인하므로 신뢰할 수 있는 컨테이너 이미지만 배포됩니다. 증명 유무에 따라 배포를 허용하거나 거부하는 정책을 만들 수 있습니다. Binary Authorization은 클러스터 수준에서 정책을 적용하므로 환경마다 다른 정책을 구성할 수 있습니다.

적용 대상:

• A03: 소프트웨어 공급망 실패
• A08: 소프트웨어 또는 데이터 무결성 실패

A03: 소프트웨어 공급망 실패에 관한 다음 권장사항을 검토하세요.

• 고유하고 변경 불가능한 SHA-256 암호화 다이제스트 (예: @sha256)로 컨테이너 이미지를 참조하고 적용하도록 배포 파이프라인을 구성합니다.
• GKE 클러스터에 Binary Authorization 지속적 검증을 배포하여 활성 포드를 플랫폼 정책에 따라 모니터링하고 실행 중인 컨테이너가 더 이상 규정을 준수하지 않는 경우 로깅에서 알림을 생성합니다.

A08: 소프트웨어 또는 데이터 무결성 실패에 관한 다음 권장사항을 검토하세요.

• Cloud Build 또는 GitHub Actions 파이프라인에서 자동 증명 생성을 강제 적용합니다. 이미지가 프로덕션에 가까워질수록 순차적 검증 게이트를 통과하도록 점진적 증명 요구사항을 만듭니다.
• 심각도가 높은 프로덕션 인시던트의 경우 브레이크글래스 긴급 배포를 사용 설정합니다. 어드미션 우회가 발생할 때 SecOps팀에 알리도록 브레이크글래스 감사 로그 이벤트에 대한 Monitoring 알림 정책을 구성합니다.

CA 서비스 및 인증서 관리자

Certificate Authority Service(CA 서비스)는 비공개 인증 기관(CA)의 배포 및 관리를 간소화합니다. 인증서 관리자는 Cloud Load Balancing 및 Cloud CDN의 TLS 인증서를 중앙에서 프로비저닝, 갱신, 관리할 수 있도록 지원합니다.

A04: 암호화 실패에 적용됩니다.

다음 권장사항을 검토하세요.

• CA Service를 사용하여 비공개 인증서의 발급 및 수명 주기 관리를 자동화합니다. Cloud HSM으로 지원되는 루트 및 중간 CA를 배포하여 비공개 키를 보호하고 인증서 템플릿을 사용하여 암호화 정책 (예: 최소 키 길이 및 허용된 확장 키 사용)을 적용합니다.
• Cloud 감사 로그를 사용 설정하여 위험도가 높은 관리 이벤트 (예: CA 취소, 정책 업데이트, 인증서 요청의 급격한 증가)를 모니터링합니다. Google SecOps로 알림을 라우팅하여 잠재적인 내부자 위협 또는 손상된 CI/CD 파이프라인을 감지합니다.
• DNS 승인과 페어링된 Google 관리형 인증서를 사용하도록 인증서 관리자를 구성합니다. 인증서 관리자는 도메인 소유권을 검증하고, X.509 인증서를 발급하고, 만료 30일 전에 갱신을 처리합니다.
• 대상 HTTPS 프록시에 인증서 맵을 연결하여 프록시를 다시 시작하거나 부하 분산기를 재구성하지 않고도 동적 인증서 선택 및 인증서 순환을 사용 설정합니다.
• 내부 마이크로서비스 또는 하이브리드 부하 분산의 경우 인증서 맵을 구성하여 비공개 CA 서비스 CA 풀에서 직접 비공개 인증서를 발급합니다.
• 수신되는 서버 이름 표시 (SNI) 요청을 특정 인증서와 일치하도록 인증서 맵을 구성합니다.

Cloud 애셋 인벤토리

Cloud 애셋 인벤토리를 사용하면 Google Cloud 에서 고아 또는 승인되지 않은 IT 인프라를 모니터링할 수 있습니다.

A02: 잘못된 보안 구성에 적용됩니다.

다음 권장사항을 검토하세요.

• 알림을 설정하여 예기치 않게 실행되는 리소스에 대해 알림을 제공합니다. 이러한 리소스는 부적절하게 보호되거나 오래된 소프트웨어를 사용할 수 있습니다.
• IAM 정책 분석기를 사용하여 allUsers 권한이 있는 공개 스토리지 버킷, 과도한 권한이 있는 서비스 계정 역할, 고아 ID와 같은 잘못 구성된 액세스 제어를 검색합니다.
• 애셋 스냅샷을 BigQuery로 내보내기를 통해 시간 경과에 따른 인프라 구성을 감사하고 다중 프로젝트 환경 전반에서 기준 규정 준수 기록을 유지합니다.

Cloud Armor

Cloud Armor는 DDoS 공격을 방어하고 SQLi 또는 XSS 삽입 페이로드를 차단하기 위해 Google Cloud 네트워크's 에지에 배포하는 적응형 웹 애플리케이션 방화벽 (WAF)입니다. Cloud Armor에는 OWASP 상위 10개 취약점을 방어하고, 인증 엔드포인트의 공격 표면을 제한하고, 도용된 사용자 인증 정보를 차단하는 사전 구성된 WAF 규칙이 포함되어 있습니다.

적용 대상:

• A01: 손상된 액세스 제어
• A05: 삽입
• A07: 인증 실패
• A08: 소프트웨어 또는 데이터 무결성 실패
• A10: 예외 조건의 잘못된 처리

A01: 손상된 액세스 제어에 관한 다음 권장사항을 검토하세요.

• evaluatePreconfiguredWaf('lfi-stable')와 같은 사전 구성된 WAF 규칙을 적용하여 로컬 파일 포함 및 경로 순회 공격을 차단합니다.
• origin.region_code 속성을 사용하여 발신 국가 코드를 기반으로 수신 트래픽과 일치하는 보안 정책 규칙을 구성하여 지리적 액세스 제어 (지오펜싱이라고도 함)를 적용합니다.
• 위협 인텔리전스 피드를 사용하여 알려진 악성 IP 주소를 차단합니다.
• 일치 규칙을 작성하여 민감한 URL (예: /admin, /login 또는 /config)에 대한 외부 액세스를 제한합니다.
• 부하 분산기에서 Cloud Armor 경로 정규화를 사용 설정하여 Cloud Armor가 보안 정책을 평가하기 전에 수신 URL을 디코딩하고 표준화하도록 강제합니다.

A05: 주입에 관한 다음 권장사항을 검토하세요.

• 네트워크 에지에서 SQL 삽입 (sqli-v422-stable), 교차 사이트 스크립팅(xss-v422-stable), PHP 명령 삽입 (php-v422-stable), Java 삽입 (java-v422-stable)을 감지하고 차단합니다.
• 트래픽을 적극적으로 거부하도록 규칙을 구성하기 전에 사전 구성된 WAF 규칙을 다양한 민감도 수준으로 조정하여 오탐을 해결하세요.
• 사전 구성된 원격 코드 실행 (RCE) 규칙(rce-v422-stable)과 원격 파일 포함 (RFI) 규칙(rfi-v422-stable)을 사용 설정하여 추가적인 복잡한 명령어 삽입 기법을 포착합니다.
• SQL 또는 PHP를 타겟팅하는 공격 이외의 삽입 공격의 경우 맞춤 규칙을 만듭니다. 커스텀 규칙을 사용하면 프로토콜의 특정 키워드 또는 이스케이프 패턴이 요청 경로 또는 쿼리에 사용되었을 때 요청을 차단할 수 있습니다.

A07: 인증 실패에 관한 다음 권장사항을 검토하세요.

• 인증 및 관리 엔드포인트에 대한 액세스를 승인된 IP 주소 또는 국가로 제한합니다.
• evaluatePreconfiguredWaf를 사용 설정하여 세션 상태 취약점과 세션 하이재킹을 악용하도록 설계된 요청을 가로채고 차단합니다.
• securityPolicies.patchRule API를 사용하여 네트워크 에지에서 쿼리 문자열 또는 헤더에 손상된 매개변수가 포함된 수신 요청을 차단합니다.

A08: 소프트웨어 또는 데이터 무결성 실패에 관한 다음 권장사항을 검토하세요.

• 신뢰할 수 없는 소스에서 고위험 직렬화 객체를 수락하는 엔드포인트를 다음과 비슷한 거부 규칙을 사용하여 신뢰할 수 있는 IP 주소 집합으로만 제한합니다.

  request.path.contains('/endpoint') && !inIpRange(origin.ip, '192.0.2.1/32')
  

• 맞춤 규칙을 배포하여 언어별 실행 패턴과 안전하지 않은 역직렬화 서명에 대한 요청 본문 키워드를 검사합니다.

A10: 예외 조건의 잘못된 처리에 관한 다음 권장사항을 검토하세요.

• 보안 정책에서 Google Cloud Armor Adaptive Protection을 사용 설정하여 일반적인 트래픽 패턴을 기준선으로 설정하고, L7 비정상에 대한 알림을 구성하고, 공격 서명으로 타겟팅된 WAF 규칙을 생성합니다.
• 중요한 엔드포인트 (예: /login, /checkout 또는 검색 API)에서 Cloud Armor 비율 제한 규칙을 구성합니다. 비율 제한 규칙은 클라이언트 IP 또는 HTTP 헤더를 기준으로 요청을 제한하고 (예: 클라이언트를 분당 100개 요청으로 제한) HTTP 429 Too Many Requests 상태 코드를 반환합니다.
• Cloud Armor 보안 정책에서 가장 낮은 우선순위의 기본 규칙을 설정하여 Deny (상태 코드: 403 또는 404)로 설정합니다.

Cloud Build 및 Cloud Deploy

Cloud Build 및 Cloud Deploy는Google Cloud에서 통합되고 안전한 지속적 통합 및 지속적 배포 (CI/CD) 파이프라인을 제공합니다. Cloud Build는 검증 가능한 SLSA provenance 및 암호화 증명으로 아티팩트를 빌드하고, Cloud Deploy는 GKE 및 Cloud Run 전반에서 점진적 출시, 타겟 승인, 자동 검증을 관리합니다.

적용 대상:

• A03: 소프트웨어 공급망 실패
• A08: 소프트웨어 또는 데이터 무결성 실패

A03: 소프트웨어 공급망 실패에 관한 다음 권장사항을 검토하세요.

• cloudbuild.yaml 파일에서 requestedVerifyOption: VERIFIED를 설정하여 확인 가능한 출처를 요구합니다.
• 민감한 엔터프라이즈 빌드를 위해 비공개 VPC 네트워크와 피어링된 Cloud Build 비공개 풀을 배포합니다.
• 전용 사용자 관리형 서비스 계정에서 실행되도록 빌드 트리거를 구성합니다. 이러한 서비스 계정에는 최소한의 필수 IAM 허용 권한 (예: Artifact Registry 작성자 (roles/artifactregistry.writer) 및 로그 작성자(roles/logging.logWriter))만 부여합니다.
• 스테이징 또는 프로덕션 환경을 타겟팅하는 Cloud Build 트리거에 수동 승인이 필요합니다.
• 빌드 파이프라인에서 출시만 만들 수 있도록 CI 빌드 도구 (예: Cloud Build, GitHub Actions 또는 GitLab)를 Cloud Deploy 출시자(roles/clouddeploy.releaser) 역할로 제한합니다.
• 수동 승인을 요구하려면 스테이징 및 프로덕션 타겟에서 requireApproval: true를 사용하여 배포 파이프라인 매니페스트 (delivery-pipeline.yaml)를 구성하세요.
• 타겟별 서비스 계정 (예: 권한이 스테이징 네임스페이스로 제한된 서비스 계정 하나와 프로덕션용 별도의 감사된 서비스 계정)으로 실행 환경을 구성합니다.
• 출시 수명 주기 중에 대역 외 보안 어설션을 실행하도록 맞춤 후크를 배포합니다. 사전 배포 후크를 사용하여 타겟 클러스터가 규정 준수 기준을 충족하는지 확인하고 사후 배포 후크를 사용하여 라이브 컨테이너 엔드포인트에 대한 자동 취약점 검사를 시작합니다.

A08: 소프트웨어 또는 데이터 무결성 실패에 관한 다음 권장사항을 검토하세요.

• 단위 테스트 및 정적 분석 테스트가 성공적으로 완료되면 Cloud KMS 및 Artifact Analysis와 Cloud Build를 통합하여 암호화 증명을 만들고 서명합니다.
• cloudbuild.yaml의 빌더 단계에서 변경 불가능한 암호화 SHA-256 다이제스트 (예: golang@sha256:...)를 사용합니다.
• 브랜치 보호 규칙 (예: 풀 요청에 대한 2인 검토 의무화)으로 보호되는 버전 관리 저장소에 빌드 구성을 저장합니다. 사용자 관리 서비스 계정을 사용하여 승인된 플랫폼 관리자에게만 트리거 수정 권한을 제한합니다.
• CI 파이프라인이 스테이징과 프로덕션 간에 매니페스트를 변경하지 못하도록 하면서 사전 렌더링된 동일한 배포 매니페스트와 변경할 수 없는 컨테이너 이미지 다이제스트를 타겟 단계 전반에 걸쳐 승격합니다.
• skaffold.yaml 매니페스트 내에서 자동화된 배포 확인 작업을 정의합니다. Cloud Deploy는 포드가 배포된 후 이러한 확인 컨테이너를 실행하여 동적 상태 점검, 통합 테스트, API 계약 어설션을 실행합니다.
• 카나리아 배포 전략을 사용합니다. 카나리아 단계에서 Skaffold 확인 테스트가 실패하거나 모니터링에서 이상 임곗값을 감지하면 Cloud Deploy에서 출시를 중지하고 트래픽을 마지막으로 알려진 양호한 상태의 출시 버전으로 롤백합니다.
• Binary Authorization 정책을 시행하도록 GKE 클러스터와 Cloud Run을 구성합니다. Cloud Deploy가 매니페스트를 적용하면 대상 허용 컨트롤러가 컨테이너 이미지 다이제스트를 암호화 방식으로 확인하고 신뢰할 수 없는 아티팩트를 거부합니다.

Cloud ID 및 Titan 보안 키

Cloud ID는 Google Cloud및 Google Workspace 전반에서 중앙 집중식 ID, 사용자 인증 정보 수명 주기, 액세스 관리를 제공합니다. Titan 보안 키는 FIDO2 또는 WebAuthn 표준을 기반으로 하는 공개 키 암호화를 사용하는 하드웨어 기반의 피싱 방지 보안 기기입니다.

A07: 인증 실패에 적용됩니다.

다음 권장사항을 검토하세요.

• 중간자 (PITM) 피싱 공격을 방지하려면 2단계 인증 (2SV)을 구성하고 허용된 방법을 보안 키만 (FIDO2, WebAuthn 또는 Titan 보안 키)으로 설정합니다.
• 자동 프로비저닝과 함께 회사 ID 공급업체로 SAML 2.0 또는 OIDC 기반 싱글 사인온(SSO)을 구성합니다.
• 사용자가 주기적으로 재인증하도록 Google Cloud 세션 길이 정책을 낮은 최대 임계값으로 설정합니다.
• Titan 보안 키를 패스키로 등록하여 비밀번호 없는 인증을 사용 설정하면 무차별 대입 및 사용자 인증 정보 도용 위험이 크게 줄어듭니다.
• Cloud ID에서 보안 키 정책을 적용하여 권한이 있는 ID(예: 프로젝트 소유자, 결제 관리자, SecOps팀)에 Titan 보안 키를 사용한 2단계 인증을 의무화합니다. 위험도가 높은 사용자를 고급 보호 프로그램에 등록합니다.

Cloud KMS

Cloud KMS는 호환되는 Google Cloud 서비스 및 자체 애플리케이션의 대칭 및 비대칭 암호화 키를 관리합니다. 대칭 암호화, 비대칭 서명, 비대칭 암호화, MAC 서명을 위한 암호화 키를 생성, 사용, 순환, 폐기할 수 있습니다.

A04: 암호화 실패에 적용됩니다.

다음 권장사항을 검토하세요.

• Cloud KMS Autokey를 사용하여 프로비저닝 및 할당을 자동화합니다. Autokey를 사용하면 키링, 키, 서비스 계정을 미리 프로비저닝할 필요가 없습니다. 대신 키와 키링은 리소스 생성 중에 필요에 따라 생성됩니다.
• 페이로드가 스토리지 버킷이나 데이터베이스로 전송되기 전에 Cloud KMS 키를 사용하여 민감한 페이로드를 암호화합니다. Cloud KMS API 또는 클라이언트 라이브러리를 사용하여 클라이언트 측 암호화에 Cloud KMS 키를 사용할 수 있습니다.
• 전송 중에 체크섬을 검증하여 엔드 투 엔드 데이터 무결성을 확인합니다.
• 엄격한 규정 준수 및 규제 워크로드의 경우 Cloud HSM을 사용하여 암호화 작업을 저장하고 실행하세요. Cloud HSM은 FIPS 140-3 Level 3 검증 하드웨어 보안 모듈에 키를 저장합니다.
• 정해진 기간 (예: 90일마다)에 자동 키 순환 일정 구성

Cloud Load Balancing

Cloud Load Balancing은 여러 백엔드 인스턴스와 리전에 사용자 트래픽을 분산하는 완전 분산형의 소프트웨어 정의 관리형 서비스입니다.

적용 대상:

• A04: 암호화 실패
• A10: 예외 조건의 잘못된 처리

A04: 암호화 실패에 관한 다음 권장사항을 검토하세요.

• 부하 분산기의 프런트엔드에 커스텀 SSL 정책을 구성하고 할당하여 협상을 TLS 1.3 또는 보안 TLS 1.2 프로필로 제한하고 취약한 암호화 스위트를 사용 중지합니다.

A10: 예외 조건의 잘못된 처리에 관한 다음 권장사항을 검토하세요.

• 맞춤 오류 응답 페이지를 사용하여 외부 애플리케이션 부하 분산기를 구성하여 백엔드 실패 코드를 가로채고 표준화된 HTML 또는 JSON 오류 응답을 제공합니다.
• 서비스 중단이나 처리되지 않은 시스템 비정상 종료가 발생할 경우 트래픽이 보조 리전으로 경로를 변경할 수 있도록 교차 리전 장애 조치와 함께 멀티 리전 백엔드 서비스를 배포합니다.

Google Cloud Observability (로깅, 모니터링, Error Reporting)

Google Cloud Observability는 로깅을 통한 전체 스택 로그 관리, 모니터링을 통한 측정항목 및 알림, Error Reporting를 통한 실시간 애플리케이션 비정상 종료 추적을 제공합니다.

적용 대상:

• A09: 보안 로깅 및 알림 실패
• A10: 예외 조건의 잘못된 처리

A09: 보안 로깅 및 알림 실패에 관한 다음 권장사항을 검토하세요.

• 민감한 데이터를 저장하는 가치 높은 데이터 저장소 (예: Cloud Storage, BigQuery, Spanner)에 대해 데이터 액세스 로그를 사용 설정합니다. 데이터 액세스 로그를 사용하면 민감한 데이터의 각 읽기, 쓰기, 쿼리 이벤트를 감사할 수 있습니다.
• 공격자나 승인되지 않은 관리자가 흔적을 숨기기 위해 로그를 삭제하지 못하도록 맞춤 로깅 버킷에 버킷 잠금 및 보관 정책을 적용합니다.
• 집계 싱크를 사용하여 SecOps팀을 위한 단일 중앙 저장소로 로그 항목을 정리하고 라우팅합니다. 데이터 액세스 로그와 같은 대량 로그가 두 개 이상의 위치에 저장되지 않도록 가로채기 집계 싱크를 구성합니다.
• 권한 거부 IAM 오류, 예기치 않은 API 키 생성, 갑작스러운 방화벽 구성 변경과 같은 심각한 침해 지표에 대해 로그 기반 알림 정책을 구성합니다.
• 로그 탐색기 또는 모니터링에서 로그 기반 알림 정책을 배포합니다. 일치하는 로그 항목이 수집될 때 사고 알림이 생성되도록 무단 IAM 정책 수정 또는 KMS 키 취소와 같은 심각도가 높은 이벤트를 타겟팅하는 정확한 필터를 지정합니다.
• Logging에서 로그 기반 카운터 측정항목을 빌드하여 일치하는 로그 항목을 시계열 데이터로 변환합니다. 그런 다음 Monitoring에서 비율이 특정 기준점을 초과할 때 (예: 5분 동안 실패한 로그인 시도가 50회를 초과하는 경우) 사고를 시작하는 측정항목 기반 알림 정책을 빌드합니다.
• Cloud Logging API에 대한 관리 호출을 모니터링하고 예기치 않은 로그 내보내기 싱크 수정 또는 버킷 삭제에 대해 알림을 보내는 로그 기반 알림 정책을 구성합니다.
• 명확한 문서 템플릿으로 알림 채널을 구성합니다. 로그 탐색기 쿼리에 대한 직접 딥 링크, 당직 엔지니어의 표준 운영 절차 (SOP), 신속한 사고 격리를 지원하는 명시적 해결 단계를 포함합니다.

A10: 예외 조건의 잘못된 처리에 관한 다음 권장사항을 검토하세요.

• Error Reporting SDK를 애플리케이션 코드에 직접 통합하거나 구조화된 JSON 예외 형식을 파싱하도록 로깅을 구성합니다.
• 새 예외 클래스가 표시되면 SecOps팀에 알리도록 Error Reporting 알림 채널 또는 모니터링 알림 정책을 구성합니다.

Cloud NGFW

Cloud NGFW는 North-South 트래픽 및 East-West 트래픽에 대해 상태 저장 검사 및 7계층 애플리케이션 제어를 지원하는 관리형 방화벽 서비스입니다.

적용 대상:

• A01: 손상된 액세스 제어
• A05: 삽입

A01: 손상된 액세스 제어에 관한 다음 권장사항을 검토하세요.

• 전역 네트워크 방화벽 정책을 사용하여 네트워크 마이크로 세분화 및 IAM 관리 리소스 태그를 적용하여 백엔드 애플리케이션 계층을 격리하고 서브넷 간의 East-West 통신을 제한합니다.
• 방화벽 규칙에서 Google에서 유지관리하는 위협 인텔리전스 목록을 사용하여 알려진 악성 행위자, C2 서버, 보안 침해된 봇넷에서 시작된 인바운드 연결을 차단합니다.

A05: 주입에 관한 다음 권장사항을 검토하세요.

• SQL 삽입, OS 명령 삽입, 원격 코드 실행 악용 서명과 일치하는 위협을 거부하는 보안 프로필 그룹으로 침입 감지 및 방지 서비스를 구성합니다.
• 인바운드 및 아웃바운드 HTTPS 트래픽을 복호화하고, 일반 텍스트 페이로드에 IPS 삽입 서명 검사를 적용하고, 백엔드로 전송하기 전에 세션을 다시 암호화하도록 Cloud NGFW TLS 검사를 구성합니다.
• 백엔드 데이터베이스와 Compute 서브넷에 FQDN 기반 이그레스 방화벽 규칙을 적용합니다. 취약한 애플리케이션이 승인된 사전 정의된 외부 도메인에 대한 무단 역방향 셸을 생성하지 못하도록 아웃바운드 연결을 제한합니다.
• 위협 방지 프로필에서 방화벽 규칙 로깅을 사용 설정하고 이러한 로그를 Google SecOps로 라우팅하여 차단된 네트워크 삽입 서명을 호스트 수준 원격 분석과 상호 연관시켜 우선순위 패치를 위한 타겟 워크로드를 식별합니다.

Cloud Workstations

Cloud Workstations는 기본 제공 보안 및 맞춤설정을 갖춘 Google Cloud 의 관리형 개발 환경을 제공합니다.

적용 대상:

• A03: 소프트웨어 공급망 실패
• A04: 암호화 실패

A03: 소프트웨어 공급망 실패에 관한 다음 권장사항을 검토하세요.

• 보안 도구, 신뢰할 수 있는 개발자 확장 프로그램, 승인된 언어 런타임이 사전 설치된 Artifact Registry에 저장된 맞춤 기본 컨테이너 이미지를 만듭니다.
• 비공개 IP 인그레스 및 이그레스를 사용하여 VPC 서비스 제어 경계 내에 워크스테이션 클러스터를 배포합니다.
• IAP를 통해 세션 트래픽을 라우팅하도록 Cloud Workstations를 구성합니다. 개발자가 다중 인증(MFA)이 사용 설정된 회사 사용자 인증 정보를 사용하여 인증하도록 요구하고 최소 권한 역할 (예: Cloud Workstations 사용자(roles/workstations.user))을 적용합니다.
• 제한 시간이 짧은 워크스테이션 구성을 구성합니다 (예: 2시간 동안 비활성 상태인 후 자동 중지). 워크스테이션이 다시 시작되면 Cloud Workstations에서 최신 보안 패치 컨테이너 이미지를 가져오므로 개발자가 깨끗한 환경에서 작업할 수 있습니다.

A04: 암호화 실패에 관한 다음 권장사항을 검토하세요.

• CMEK를 사용하여 연결된 영구 디스크를 암호화하도록 워크스테이션 구성을 구성합니다.

CodeMender

CodeMender는 특화된 자율 AI 엔지니어링 에이전트입니다. CodeMender는 새로 발견된 취약점을 패치하고 기존 레거시 코드를 다시 작성하여 기존 취약점을 해결할 수 있습니다. Gemini Enterprise Agent Platform에서 CodeMender를 설치하고 구성할 수 있습니다.

적용 대상:

• A03: 소프트웨어 공급망 실패
• A05: 삽입
• A06: 안전하지 않은 설계

A03: 소프트웨어 공급망 실패에 관한 다음 권장사항을 검토하세요.

• CodeMender CLI를 로컬 개발자 워크스페이스 및 CI/CD 파이프라인에 통합하여 타겟 모듈을 스캔하고, 악용 가능성을 확인하고, 코드가 커밋되기 전에 보안 취약점을 포착합니다.
• 소프트웨어 구성 분석 (SCA) 및 종속 항목 취약점 보고서를 CodeMender로 가져와 개념 증명 익스플로잇 검증을 실행하고 개발자 검토 전에 거짓양성을 필터링합니다.

A05: 주입에 관한 다음 권장사항을 검토하세요.

• 격리된 로컬 샌드박스 내에서 자동 패치 생성을 실행하여 취약한 로직 (예: 입력 정리)을 다시 작성합니다. 단위 테스트가 통과되고 PoC를 더 이상 악용할 수 없는지 확인한 후 풀 요청을 만드세요.

A06: 안전하지 않은 설계에 관한 다음 권장사항을 검토하세요.

• CodeMender의 반복 패치 엔진을 사용하여 기존 또는 보안되지 않은 아키텍처 코드 로직을 리팩터링하고, 애플리케이션 모듈 전반에서 보안 설계 패턴을 적용하기 위한 명시적 코딩 제약 조건을 제공합니다.
• CodeMender에서 생성된 풀 요청 및 차이점에 대해 인간 참여형 검토를 유지하여 제안된 변경사항이 보안 코딩 가이드라인에 부합하는지 확인합니다.

컨피덴셜 컴퓨팅

컨피덴셜 컴퓨팅은 데이터가 처리되는 동안 메모리에서 데이터를 암호화된 상태로 유지하여 사용 중인 데이터를 보호합니다. 컨피덴셜 컴퓨팅은 하드웨어 기반 신뢰할 수 있는 실행 환경 (TEE)을 사용하여 민감한 정보와 암호화 키가 하이퍼바이저, 호스트 운영체제 또는 인프라 관리자에 의해 액세스되지 않도록 합니다.

A04: 암호화 실패에 적용됩니다.

다음 권장사항을 검토하세요.

• 매우 민감한 워크로드 (예: PII, 재무 기록, 독점 AI 모델 가중치)에는 컨피덴셜 VM 또는 컨피덴셜 Google Kubernetes Engine 노드를 사용합니다.
• 여러 조직이 서로 원시 데이터를 노출하지 않고 분석 또는 AI 학습을 위해 민감한 정보를 풀링해야 하는 경우 Confidential Space를 사용하여 암호화 증명 및 데이터 격리를 적용하세요.

Firebase (Firebase 인증, Firebase 앱 체크, Firebase 보안 규칙)

Firebase는 ID, 클라이언트 증명, 데이터베이스 액세스 전반에서 개발자 중심의 보안 제어를 제공합니다. Firebase 인증은 사용자 ID 및 세션 관리를 처리하고, App Check은 클라이언트 앱 무결성을 검증하며, Firebase 보안 규칙은 Firestore 및 Cloud Storage에 대한 속성 기반 액세스 제어 및 스키마 유효성 검사를 적용합니다.

적용 대상:

• A01: 손상된 액세스 제어
• A05: 삽입
• A07: 인증 실패
• A08: 소프트웨어 또는 데이터 무결성 실패

A01: 손상된 액세스 제어에 관한 다음 권장사항을 검토하세요.

• Firebase 보안 규칙에서 인증된 사용자의 ID에 대한 읽기 및 쓰기 범위를 지정합니다. allow read, write: if true;와 같은 허용 기본 규칙을 사용하면 안 됩니다.
• 관리 역할의 경우 Firebase Admin SDK를 사용하여 사용자의 ID 토큰에 커스텀 클레임을 설정하고 클라이언트 측 프로필 쓰기를 허용하는 대신 보안 규칙에서 이러한 클레임을 검증합니다.
• Firebase 보안 규칙에서 앱 체크를 적용하여 데이터베이스 레이어에서 인증되지 않았거나 스푸핑된 클라이언트 액세스를 차단합니다.

A05: 주입에 관한 다음 권장사항을 검토하세요.

• 들어오는 문서 필드 유형, 문자열 길이, 객체 크기를 확인하여 데이터베이스 수집 전에 형식이 잘못되었거나 악의적인 쓰기 페이로드를 거부함으로써 보안 규칙에서 구조적 페이로드 유효성 검사를 적용합니다.

A07: 인증 실패에 관한 다음 권장사항을 검토하세요.

• Identity Platform을 사용한 Firebase 인증으로 업그레이드하여 TOTP를 사용한 MFA 및 차단 함수와 같은 엔터프라이즈 보호 기능을 사용 설정하세요.
• 민감한 애플리케이션 데이터에 대한 액세스 권한을 부여하기 전에 Firebase Admin SDK를 사용하여 백엔드에서 Firebase ID 토큰을 확인하세요.
• 디버그 제공자를 사용하여 스테이징 환경에서 개발자 및 CI/CD 파이프라인을 위한 범위가 지정된 임시 디버그 토큰을 생성합니다.

A08: 소프트웨어 또는 데이터 무결성 실패에 관한 다음 권장사항을 검토하세요.

• 클라이언트 무결성을 확인하도록 하드웨어 기반의 증명 프로바이더를 강제 적용합니다. Android Play Integrity 및 Apple App Attest를 사용하도록 앱 체크를 구성합니다.
• Cloud Run 및 Kubernetes Engine API 백엔드에 App Check 토큰 확인 미들웨어를 배포하여 스크랩된 API 키, 자동화된 스크립트 또는 에뮬레이트된 환경에서 시작된 요청을 거부합니다.

Fraud Defense

Fraud Defense는 웹의 봇, 계정, 거래 보호를 비롯한 사기 및 악용 방지를 위한 통합 플랫폼입니다. Fraud Defense의 일부인 reCAPTCHA는 액세스 시도의 위험 수준을 확인하여 봇과 기타 자동화 및 대량 트래픽 형식에 대해 필터링합니다.

A07: 인증 실패에 적용됩니다.

다음 권장사항을 검토하세요.

• Google Cloud Armor와 같은 기존 WAF와 reCAPTCHA를 통합하여 요청이 인증 엔드포인트에 도달하기 전에 자동 챌린지를 실행하거나 위험도가 높은 봇 트래픽을 차단합니다.
• 로그인, 비밀번호 재설정, 세션 갱신 엔드포인트에서 계정을 보호합니다. 사용자 로그인 속도와 기기 지문을 기반으로 계정 탈취 (ATO) 위험 점수를 획득합니다.
• 아웃바운드 SMS 메시지를 보내기 전에 전화번호 위험 프로필을 평가하여 등록 및 2단계 인증 양식에서 SMS 전화 결제 사기를 방지합니다.
• 오탐을 줄이고 사이트별 위험 평가 모델을 학습시키려면 정기적으로 트랜잭션 의견을 주석으로 달고 전송하세요.
• 사용자 로그인 및 계정 생성 흐름 중에 비밀번호를 확인하여 제출된 사용자 인증 정보가 웹 전반의 서드 파티 정보 유출 데이터베이스에 표시되는지 감지합니다.

Google SecOps

Google Security Operations는 보안 원격 분석 분석(SIEM), 보안 조정, 자동화, 응답 (SOAR), 최전선 Mandiant 위협 인텔리전스를 단일 플랫폼으로 결합하는 보안 운영 플랫폼입니다.

적용 대상:

• A02: 잘못된 보안 구성
• A09: 보안 로깅 및 알림 실패

A02: 보안 구성 오류에 관한 다음 권장사항을 검토하세요.

• Security Command Center의 발견 항목을 Google SecOps에 수집하여 정적 구성 오류 발견 항목 (예: PUBLIC_BUCKET_ACL 또는 CMEK_DISABLED)을 실시간 네트워크 및 방화벽 원격 분석과 결합합니다.
• 자동화된 SOAR 대응 플레이북을 빌드하여 격리 조치를 실행합니다.
• Gemini를 사용하여 잘못된 구성 분류를 가속화하고 잘못 구성된 애셋, 연결된 IAM 역할, 단계별 수정 안내의 합성 요약을 받아보세요.

A09: 보안 로깅 및 알림 실패에 관한 다음 권장사항을 검토하세요.

• 원시 로그 파싱의 오버헤드 없이 빠르고 표준화된 멀티 클라우드 검색 및 상관관계를 지원하도록 로그 원격 분석을 통합 데이터 모델(UDM)로 정규화합니다.
• YARA-L 2.0 감지 규칙을 작성하여 OS 로그인 사용 중지, 로깅 싱크 삭제, VPC 서비스 제어 경계 수정과 같은 위험도가 높은 구성 변경사항을 모니터링합니다.
• Applied Threat Intelligence 선별된 감지를 사용하여 Mandiant 위협 인텔리전스 데이터에 대해 이벤트 데이터를 평가합니다.
• Google SecOps의 Gemini를 사용하여 자연어 설명에서 YARA-L 감지 규칙을 생성하고 복잡한 다단계 인시던트 타임라인을 임원용 인시던트 요약으로 요약할 수 있습니다.

IAP(Identity-Aware Proxy)

IAP는 HTTPS 및 관리 TCP 연결로 액세스하는 애플리케이션을 위한 중앙 승인 레이어를 만듭니다. IAP는 Cloud Run, App Engine, Compute Engine, GKE, 온프레미스 리소스에 대한 액세스 권한을 부여하기 전에 사용자 ID와 컨텍스트를 확인합니다.

적용 대상:

• A01: 손상된 액세스 제어
• A07: 인증 실패

A01: 손상된 액세스 제어에 관한 다음 권장사항을 검토하세요.

• 사용자의 ID, 그룹 멤버십,요청 컨텍스트를 기반으로 웹 애플리케이션, VM, Google Cloud API, Google Workspace 애플리케이션에 세부적인 액세스 제어를 적용합니다.
• Agent Gateway와 통합하여 에이전트 ID에 대한 액세스 제어를 시행합니다.
• IAP TCP 전달을 사용하여 백엔드 인스턴스에 암호화된 HTTPS 터널을 설정하고 인터넷 연결 SSH (포트 22) 및 RDP (포트 3389) 엔드포인트를 삭제합니다.

A07: 인증 실패에 관한 다음 권장사항을 검토하세요.

• IAM 또는 Cloud ID에서 프로비저닝된 ID를 사용하여 IAP를 통해 관리 인터페이스 및 웹 애플리케이션에 액세스하는 사용자를 인증합니다.
• 애플리케이션 레이어의 x-goog-iap-jwt-assertion 헤더 내에서 서명된 JWT 어설션을 확인합니다. Google의 공개 키에 대해 서명을 검증하고 대상 (aud) 클레임이 백엔드 서비스 ID와 일치하는지 확인합니다.
• 공격자가 IAP 인증을 우회하지 못하도록 하려면 Cloud Run 인그레스 설정을 구성하여 내부 및 Cloud Load Balancing 트래픽만 허용하고 백엔드 컨테이너 URL에 대한 직접 공개 액세스를 차단하세요. VM 또는 GKE 노드의 경우 로드 밸런서의 IP 범위에서 시작되는 인그레스 트래픽만 허용하도록 VPC 방화벽 규칙을 구성하세요.

Identity and Access Management

Identity and Access Management (IAM)를 사용하면 Google Cloud의 서비스 및 리소스에 대한 세부적인 액세스를 관리할 수 있습니다. IAM에는 다음과 같은 기능이 포함됩니다.

• Privileged Access Manager: 민감한 Google Cloud 리소스에 대한 주문형 임시 권한 승격을 관리합니다.
• 워크로드 아이덴티티 제휴를 사용하면 워크로드가 제휴 ID를 사용하여 Google Cloud 리소스에 액세스할 수 있습니다.
• 직원 ID 제휴: 사용자가 제휴 ID를 사용하여 Google Cloud 리소스에 액세스할 수 있습니다.

적용 대상:

• A01: 손상된 액세스 제어
• A07: 인증 실패

A01: 손상된 액세스 제어에 관한 다음 권장사항을 검토하세요.

• 사전 정의된 역할 또는 맞춤 역할 (기본 역할 아님)을 사용하여 특정 리소스 또는 사용자 요구사항에 대한 권한을 제한합니다.
• 서비스 계정 사용자(roles/iam.serviceAccountUser) 및 서비스 계정 토큰 생성자(roles/iam.serviceAccountTokenCreator) 역할을 부여할 수 있는 권한을 제한합니다.
• IAM 추천자를 사용하여 조직의 활성 사용 로그를 분석하고 권한이 과도한 계정을 삭제합니다.
• 역할 바인딩에 IAM 조건을 작성하여 컨텍스트 인식 승인을 추가하고 날짜, 시간 또는 발신 IP 주소별로 액세스를 제한합니다.
• 보안 주체 액세스 경계 (PAB) 정책을 배포하여 보안 주체 집합이 액세스할 수 있는 조직, 폴더 또는 프로젝트를 정의합니다. 공격자가 활성 세션을 도용하거나 서비스 계정에 실수로 광범위한 IAM 역할이 부여된 경우 지정된 리소스가 ID의 지정된 경계 외부에 있으면 PAB에서 액세스를 차단합니다.
• 조직 또는 폴더 수준에서 IAM 거부 정책을 연결하여 위험도가 높은 권한 (예: iam.serviceAccountKeys.create 또는 resourcemanager.projects.delete)을 차단합니다.
• IAM 거부 규칙을 구성할 때는 exceptionPrincipals 목록에 전용 비상 모드 보안 그룹을 선언합니다. 거부 조건에 리소스 태그 (예: resource.matchTag('env', 'prod'))를 사용하여 개발 샌드박스 프로젝트에서 개발자의 운영 유연성을 허용하면서 프로덕션 리소스에 대한 파괴적인 작업을 차단합니다.

Privileged Access Manager에 적용되는 A07: 인증 실패에 관한 다음 권장사항을 검토하세요.

• 정적 IAM 바인딩에서 Privileged Access Manager 사용 권한으로 중요 관리 역할 (예: 소유자 (roles/owner), 조직 관리자 (roles/resourcemanager.organizationAdmin), 보안 관리자 (roles/iam.securityAdmin))을 변환합니다. 권한 상승이 부여되기 전에 운영상의 근거가 필요하도록 이러한 권한을 구성합니다.
• 프로덕션 환경의 경우 중앙 SecOps 그룹 또는 팀장과 같은 필수 승인자로 Privileged Access Manager 권한 정책을 구성합니다.
• Privileged Access Manager 사용 권한의 최대 기간을 가장 짧은 현실적인 운영 기간 (예: 표준 유지보수의 경우 2시간, 비상 조치의 경우 30분)으로 구성합니다. 타이머가 만료되면Google Cloud 가 임시 IAM 역할 바인딩을 삭제합니다.
• 비공식 IAM 리소스 (예: google_project_iam_policy 또는 google_project_iam_binding 대신 google_project_iam_member 또는 google_folder_iam_member)를 사용하여 Terraform 인프라를 관리합니다. 이 방법을 사용하면 관리자가 적극적으로 인시던트를 해결하는 동안 Terraform 파이프라인을 덮어쓰거나 임시 Privileged Access Manager 역할 바인딩이 동기화되지 않는 것을 방지할 수 있습니다.
• Privileged Access Manager에서 Cloud 감사 로그를 사용 설정하여 사용 권한 작업 및 만료 이벤트를 기록합니다. 이러한 로그를 Google SecOps에 수집하여 여러 시간 외 권한 상승 요청 또는 예상치 못한 지리적 위치에서의 반복된 요청과 같은 의심스러운 권한 상승 패턴에 대한 알림을 받습니다.

직원 ID 제휴에 적용되는 A07: 인증 실패에 관한 다음 권장사항을 검토하세요.

• SAML 2.0 또는 OpenID Connect (OIDC)를 사용하여Google Cloud와 외부 ID 공급업체를 제휴하여 직원 ID 풀을 배포합니다.
• 제휴 사용자 토큰의 수명을 제한하도록 직원 ID 풀에서 세션 기간을 구성합니다.
• 직원 ID 공급업체에 속성 조건을 적용하여 멀티 테넌트 IdP 토큰 위조 또는 교차 조직 가장을 완화합니다.
• 외부 그룹 멤버십을 매핑하여 제휴 그룹 주 구성원 집합 (예: principalSet://iam.googleapis.com/.../attribute.group/security-engineers)에 IAM 역할을 할당합니다.

워크로드 아이덴티티 제휴에 적용되는 A07: 인증 실패에 관한 다음 권장사항을 검토하세요.

• 외부 워크로드의 워크로드 아이덴티티 풀 및 공급업체를 만듭니다. 단기 OIDC 토큰을 사용하여 보안 토큰 서비스를 통해 몇 분 후에 만료되는 임시 액세스 토큰으로 동적으로 교환합니다.
• 외부 멀티 테넌트 플랫폼이 승인되지 않은 저장소 또는 계정에서 풀에 인증할 수 없도록 워크로드 아이덴티티 공급자에 속성 조건을 적용합니다.
• 커스텀 매핑된 속성으로 필터링된 특정 주 구성원 집합에 IAM 역할을 직접 바인딩합니다.
• 워크로드 액세스를 구성할 때는 타겟 리소스의 제휴 principalSet:// 식별자에 직접 IAM 역할을 부여하세요.
• 워크로드 아이덴티티 제휴를 적용하려면 조직에 constraints/iam.disableServiceAccountKeyCreation 제약 조건을 설정하세요.

Identity Platform

Identity Platform은 Google Cloud 고객을 위한 고객 ID 및 액세스 관리 (CIAM) 플랫폼입니다. Identity Platform은 SDK 및 API를 사용하여 멀티 프로토콜을 지원하는 인증을 제공합니다. Identity Platform은 MFA, 서드 파티 인증 서비스와의 통합, 감사 가능한 활동 추적을 지원합니다.

A07: 인증 실패에 적용됩니다.

다음 권장사항을 검토하세요.

• 사용자 기반 전반에서 MFA를 사용 설정합니다. TOTP (OTP 앱) 또는 WebAuthn (생체 인식 및 보안 키)과 같은 피싱 방지 방법을 우선적으로 사용합니다.
• beforeCreate 및 beforeSignIn 트리거를 사용하여 차단 Cloud Run 함수를 배포하여 사용자가 저장되거나 토큰이 발급되기 전에 맞춤 보안 코드를 실행합니다. 이렇게 하면 일회용 이메일 도메인을 차단하거나, IP 주소를 제한하거나, 이메일 인증을 의무화할 수 있습니다.
• reCAPTCHA Enterprise와 통합하여 로그인, 가입, 비밀번호 재설정 요청에서 봇 트래픽, 크리덴셜 스터핑 시도, 자동화된 악용을 평가합니다.
• 비밀번호 정책을 구성하여 최소 문자 길이를 적용하고, 특정 문자 복잡성(예: 숫자 및 기호)을 요구하고, 예측 가능한 시퀀스를 차단합니다.
• 전화 기반 MFA를 사용하는 경우 SMS 지역을 구성하고 reCAPTCHA SMS 방어를 사용 설정하여 인증 메시지를 타겟 사용자가 거주하는 국가 코드로 제한합니다.

Mandiant AI Security Consulting Solutions

Mandiant AI Security Consulting 솔루션은 개발 수명 주기 초기에 제안된 소프트웨어 아키텍처, 비즈니스 프로세스, 클라우드 배포를 평가할 수 있습니다. Mandiant 컨설턴트는 시스템 설계에 최전선 위협 인텔리전스를 적용하여 단 한 줄의 코드가 작성되기 전에 숨겨진 논리적 결함, 누락된 신뢰 경계, 아키텍처 위험을 노출합니다.

A06: 안전하지 않은 설계에 적용됩니다.

다음 권장사항을 검토하세요.

• 개발이 시작되기 전에 Mandiant 컨설턴트와 협력하여 아키텍처 워크숍을 완료하고 처음부터 보안 제어를 구현하세요.
• 위협 모델링 전문가와 협력하여 애플리케이션의 데이터 흐름 다이어그램을 작성합니다. 민감한 정보가 신뢰 경계를 교차하는 위치를 정의하여 엄격한 인증, 암호화, 유효성 검사 제어를 적용해야 하는 위치를 식별합니다.
• 아키텍처 워크숍 중에 구조화된 위협 모델링 프레임워크 (예: STRIDE)를 사용합니다. Mandiant 컨설턴트는 실제 악용 가능성과 비즈니스 영향을 기반으로 발견된 설계 결함의 우선순위를 지정할 수 있도록 지원합니다.
• 에이전틱 워크플로 및 LLM 배포를 위한 안전한 AI 거버넌스 기준을 수립하여 AI 에이전트, MCP 서버, 엔터프라이즈 백엔드 데이터 소스 간의 명확한 신뢰 경계를 정의합니다.

Model Armor

Model Armor는 LLM 프롬프트, 대답, MCP 도구 호출을 검사하도록 설계되었습니다. Model Armor는 생성형 AI 페이로드를 검사하여 프롬프트 인젝션, 탈옥 시도, 악성 URL, 유해한 콘텐츠, 민감한 정보 유출을 감지하고 차단합니다.

적용 대상:

• A05: 삽입
• A10: 예외 조건의 잘못된 처리

A05: 주입에 관한 다음 권장사항을 검토하세요.

• Apigee 통합 또는 에이전트 게이트웨이를 사용하여 API 게이트웨이 레이어에 Model Armor 정책을 인라인으로 배포하여 트래픽이 추론 엔진이나 도구 런타임에 도달하기 전에 수신 프롬프트와 발신 모델 응답을 검사합니다.
• 조직 또는 폴더 수준에서 최소 기준 설정을 구성하여 개별 프로젝트팀이 우회할 수 없는 필수 기준 보안 가이드라인을 만드세요.
• 공개 엔드포인트에서 프롬프트 인젝션 및 탈옥 감지를 위해 조정된 신뢰도 기준점 (예: LOW_AND_ABOVE 또는 MEDIUM_AND_ABOVE)으로 맞춤설정된 Model Armor 템플릿을 빌드합니다.
• Model Armor 템플릿에서 악성 URL 감지 및 PDF와 파일 스캔을 사용 설정하여 삽입된 URL을 Google의 위협 인텔리전스 데이터베이스와 비교합니다. 실행 전에 멀웨어 또는 피싱 벡터가 포함된 프롬프트를 삭제합니다.
• Model Armor 템플릿에서 Sensitive Data Protection을 사용 설정하여 모델 이그레스 트래픽을 검사합니다. 감지된 민감한 정보가 응답이 경계를 벗어나기 전에 자리표시자로 대체되도록 자동 익명화 또는 마스킹을 구성합니다.

A10: 예외 조건의 잘못된 처리에 관한 다음 권장사항을 검토하세요.

• 시스템이 프롬프트를 실행하거나 원시 예외 추적을 노출하지 않도록 MATCH_FOUND 평결을 가로채고 일반 응답을 반환하도록 애플리케이션 코드를 구성합니다.
• Model Armor API 호출에서 네트워크 시간 초과, 비율 제한 또는 처리되지 않은 HTTP 5xx 오류가 발생하는 경우 수신되는 생성형 AI 프롬프트를 거부하도록 애플리케이션 코드에 fail-closed (fail-secure) 아키텍처를 구현합니다.

조직 정책

조직 정책을 사용하면 조직의 Google Cloud 리소스를 중앙에서 프로그래매틱 방식으로 제어할 수 있습니다.

적용 대상:

• A01: 손상된 액세스 제어
• A02: 잘못된 보안 구성
• A04: 암호화 실패

A01: 손상된 액세스 제어에 관한 다음 권장사항을 검토하세요.

• allUsers 또는 allAuthenticatedUsers에 대한 액세스 권한을 부여하려고 시도하는 버킷 수준 IAM 정책 또는 ACL을 재정의하기 위해 constraints/storage.publicAccessPrevention를 적용합니다.
• constraints/iam.allowedPolicyMemberDomains를 적용하여 IAM 정책 바인딩을 확인된 Google Workspace 또는 Cloud ID 고객 ID로 엄격하게 제한합니다.
• 프로덕션 폴더 전체에 constraints/iam.disableServiceAccountKeyCreation를 적용하여 사용자가 서비스 계정 키를 다운로드하지 못하도록 하고 엔지니어링팀이 워크로드 아이덴티티 제휴와 같은 단기 대안을 채택하도록 강제합니다.
• Google Cloud 이 기본 서비스 계정에 권한이 있는 편집자(roles/editor) 역할을 자동으로 부여하지 않도록 constraints/iam.automaticIamGrantsForDefaultServiceAccounts을 적용합니다.
• 사전 정의된 제약 조건으로 충족되지 않는 요구사항의 경우 맞춤 제약 조건을 배포하여 세부적인 리소스 구성을 적용합니다. 승인된 머신 패밀리로만 VM 생성을 제한하거나, 영구 디스크 프로비저닝 크기를 제한하거나, 특정 네트워크 방화벽 태그 구성을 의무화하는 것을 고려해 보세요.

A02: 보안 구성 오류에 관한 다음 권장사항을 검토하세요.

• constraints/compute.requireShieldedVm을 사용하여 보안 VM을 요구하면 커널 루트킷, 부트킷, 펌웨어 조작으로부터 VM을 보호할 수 있습니다.
• Linux 인스턴스에서 OS 로그인을 사용하도록 constraints/compute.requireOsLogin을 적용하여 SSH 액세스를 사용자의 IAM ID 및 2SV에 직접 연결합니다.
• constraints/compute.disableSerialPortAccess를 적용하여 프로젝트 간 대화형 직렬 콘솔 연결을 차단합니다.
• 기본 VPC 네트워크가 생성되지 않도록 constraints/compute.skipDefaultNetworkCreation를 적용하여 팀이 전용 서브넷과 엄격한 방화벽 정책으로 커스텀 VPC를 빌드하도록 강제합니다.
• Cloud SQL 인스턴스가 비공개 RFC 1918 내부 IP 주소만 수신하도록 constraints/sql.restrictPublicIp를 적용하고 constraints/compute.vmExternalIpAccess를 사용하여 VM의 공개 IPv4 주소를 제한합니다.
• constraints/gcp.resourceLocations을 적용하여 리소스 생성을 승인된 Google Cloud 리전으로 제한합니다.

A04: 암호화 실패에 관한 다음 권장사항을 검토하세요.

• CMEK를 의무화하려면 조직 또는 최상위 폴더에 constraints/gcp.restrictNonCmekServices를 적용하고 정책 유형을 Deny로 설정하고 지원되는 Google Cloud 서비스를 나열합니다. 제약 조건을 적용하기 전에 각 타겟 서비스의 서비스 에이전트가 존재하고 관련 키링에 대한 Cloud KMS CryptoKey 암호화/복호화(roles/cloudkms.cryptoKeyEncrypterDecrypter) 역할이 부여되었는지 확인합니다.
• constraints/gcp.restrictCmekCryptoKeyProjects를 적용하여 키 선택을 전용 Cloud KMS 프로젝트로 제한합니다.

Secret Manager

Secret Manager를 사용하면 애플리케이션과 파이프라인에서 IAM으로 부여된 권한을 기반으로 명명된 보안 비밀의 값에 액세스할 수 있습니다. 사용 설정하면 Secret Manager와의 상호작용으로 감사 추적이 생성되며, 이를 사용하여 포렌식 및 규정 준수 요구사항을 지원할 수 있습니다.

적용 대상:

• A04: 암호화 실패
• A07: 인증 실패

A04: 암호화 실패에 관한 다음 권장사항을 검토하세요.

• CMEK를 사용하여 가치가 높은 보안 비밀을 암호화하여 보안 비밀 페이로드를 래핑하는 기본 암호화 키를 제어, 순환 또는 취소합니다.
• 데이터 무결성 체크섬을 사용하여 보안 비밀 버전을 추가 및 액세스할 때 보안 비밀 데이터의 무결성을 유지 관리하고 확인합니다.
• 지리적 배포 영역 전반에서 고가용성 및 재해 복구를 위해 여러 리전에 보안 비밀을 복제합니다.

A07: 인증 실패에 관한 다음 권장사항을 검토하세요.

• 소스 코드, .env 파일, 컨테이너 빌드 구성에서 API 키와 같은 민감한 값을 삭제하고 Secret Manager에 사용자 인증 정보를 저장합니다. Google Cloud 클라이언트 라이브러리, GKE Secret Store CSI 드라이버 또는 Cloud Run 보안 비밀 바인딩을 사용하여 런타임에 복호화된 값을 가져옵니다.
• 특정 개별 보안 비밀에 직접 IAM 정책 바인딩을 적용하여 마이크로서비스에 필요한 특정 보안 비밀에 대해서만 Secret Manager 보안 비밀 접근자 (roles/secretmanager.secretAccessor) 역할을 부여합니다.
• Secret Manager에서 자동 순환 일정을 구성합니다. 순환 간격이 시작되면 Secret Manager는 지정된 Pub/Sub 주제에 SECRET_ROTATE 알림을 게시합니다. 알림을 읽고, 새 보안 비밀 값을 생성하고, 새 버전을 Secret Manager에 추가하고, 지원 중단된 버전을 삭제하도록 Cloud Run Functions 또는 Cloud Run 서비스를 구성합니다.
• Secret Manager에서 Cloud 감사 로그를 사용 설정하여 비밀 버전 생성, 삭제, 페이로드 액세스 이벤트를 추적합니다. 이러한 로그를 Google SecOps로 라우팅하여 보안 침해된 서비스 계정이 표준 운영 시간 외에 보안 비밀에 액세스하거나 승인되지 않은 보안 비밀 리소스를 읽으려고 시도하는 등 의심스러운 액세스 이벤트에 대한 알림을 받습니다.

Security Command Center Premium

Security Command Center 프리미엄을 사용하면 Google Cloud환경 및 웹 애플리케이션에서 식별 및 인증 실패를 비롯한 보안 구성 오류와 활성 런타임 위협을 찾아 해결할 수 있습니다. Web Security Scanner 서비스는 OWASP 상위 10개 제어 항목을 포함하도록 설계된 스캔을 통해 XML 외부 항목 (XXE) 취약점을 비롯한 애플리케이션 취약점을 모니터링할 수 있습니다.

적용 대상:

• A02: 잘못된 보안 구성
• A05: 삽입
• A07: 인증 실패
• A08: 소프트웨어 또는 데이터 무결성 실패

A02: 보안 구성 오류에 관한 다음 권장사항을 검토하세요.

• 규정 준수 관리자를 사용하여 기본 제공 프레임워크(예: CIS 벤치마크 또는 NIST)를 적용하여 규제 보안 프레임워크 및 업계 벤치마크에 대해 클라우드 구성을 평가합니다.
• 클라우드 인프라 사용 권한 관리를 사용 설정하여 클라우드 배포의 리소스에 액세스할 수 있는 ID를 관리하고 구성 오류로 인한 잠재적인 취약점을 완화하세요.
• Web Security Scanner 결과를 검토하고 수정하여 잘못 구성된 HTTP 응답 보안 헤더, 잘못된 CORS 출처 헤더, 혼합 콘텐츠 제공을 수정합니다.

A05: 주입에 관한 다음 권장사항을 검토하세요.

• Virtual Machine Threat Detection 및 Container Threat Detection과 같은 서비스를 사용 설정합니다. 이러한 서비스는 하이퍼바이저 메모리와 커널 이벤트를 스캔하여 악성 스크립트, 리버스 셸, 멀웨어 설치를 찾습니다 (추가된 바이너리 실행됨 및 추가된 라이브러리 로드됨 감지기 사용).
• 실행 중인 애플리케이션에서 교차 사이트 스크립팅(XSS) 및 SQL 삽입(SQLi) 결함을 모니터링하도록 Web Security Scanner를 구성합니다.
• Security Command Center 발견 항목을 통합하여 Google SecOps 또는 서드 파티 SIEM에서 자동 분류 및 사고 대응을 수행합니다.

A07: 인증 실패에 관한 다음 권장사항을 검토하세요.

• 무차별 대입: SSH 및 지속성: IAM 비정상 부여 감지기를 사용하여 사용자 인증 정보 기반 공격을 포착하도록 로깅 스트림을 모니터링합니다.
• 다단계 또는 비밀번호 없는 인증 사용, API 키에 애플리케이션 제한 설정, API 키 순환 요구 클라우드 컨트롤을 사용하여 MFA가 사용되지 않는 시점을 감지하고 API 키 사용량을 모니터링합니다.
• HttpOnly 및 Secure 플래그가 있는 HTTP 쿠키에 세션 토큰을 저장하도록 웹 백엔드를 구성하여 세션 ID 유출 발견 사항을 해결하세요.

A08: 소프트웨어 또는 데이터 무결성 실패에 관한 다음 권장사항을 검토하세요.

• 서명 기반 실행 버그에 대해 웹 엔드포인트를 스캔하고 애플리케이션이 취약한 Apache Struts 버전을 실행하는 경우 심각도가 높은 STRUTS_INSECURE_DESERIALIZATION 발견 항목을 생성하도록 Web Security Scanner를 구성합니다.
• 취약한 프레임워크 라이브러리 버전을 업그레이드하거나 Assured OSS를 배포하여 Google에서 확인한 대체 항목을 가져와 STRUTS_INSECURE_DESERIALIZATION 발견 사항을 수정합니다.

Sensitive Data Protection

Sensitive Data Protection을 사용하면 의도치 않은 정보 누출을 방지하기 위해 버킷, 데이터베이스, 생성형 AI 프롬프트 또는 스트리밍 애플리케이션 페이로드에 저장된 잠재적으로 민감한 정보를 스캔할 수 있습니다. 허용되지 않은 데이터가 식별되면 Sensitive Data Protection이 이를 플래그 지정하거나 수정할 수 있습니다.

적용 대상:

• A04: 암호화 실패
• A09: 보안 로깅 및 알림 실패

A04: 암호화 실패에 관한 다음 권장사항을 검토하세요.

• 민감한 정보 탐색을 사용 설정하여 스토리지 및 데이터베이스 애셋을 지속적으로 스캔하고, 데이터 프로필을 생성하고, 감사 보고서의 측정항목을 보고합니다.
• 형식 보존 암호화, 암호화 해싱 또는 키 기반 토큰화를 사용하여 민감한 정보를 익명화합니다.
• 재사용 가능하고 중앙에서 관리되는 익명화 템플릿을 배포하여 개발팀 전반에서 일관된 암호화 마스킹 및 검사 정책을 적용합니다.
• 프롬프트 페이로드를 분석하여 민감한 회사 데이터 또는 개인 식별 정보가 생성형 AI 학습 파이프라인으로 유출되지 않도록 합니다.

A09: 보안 로깅 및 알림 실패에 관한 다음 권장사항을 검토하세요.

• 애플리케이션 로그를 Pub/Sub 주제로 전송하도록 Logging 싱크를 구성합니다. Sensitive Data Protection API를 사용하여 최종 로깅 버킷에 정리된 로그를 쓰기 전에 로그 페이로드를 스캔하고 익명화하는 Cloud Run 구독자를 연결합니다.
• 로깅 싱크에서 제외 필터를 사용하여 위험도가 높은 비구조화 로그(예: 원시 애플리케이션 오류, 사용자 등록 페이로드, 트랜잭션 로그)만 삭제 파이프라인을 통해 라우팅합니다.

VirusTotal

VirusTotal API는 의심스러운 파일, URL, 도메인, IP 주소를 분석하여 멀웨어, 트로이 목마, 악성 페이로드를 감지하는 위협 인텔리전스 및 파일 스캔 플랫폼입니다. VirusTotal API를 파일 수집 파이프라인에 통합하면 애플리케이션 시스템에서 파일을 처리하기 전에 신뢰할 수 없는 업로드를 검사할 수 있습니다.

적용 대상:

• A08: 소프트웨어 또는 데이터 무결성 실패
• A05: 삽입

A08: 소프트웨어 또는 데이터 무결성 실패에 관한 다음 권장사항을 검토하세요.

• 맞춤 YARA-X 서명 일치 규칙을 배포하여 수신 파일 구조에서 알려진 악성 바이너리 및 텍스트 패턴을 검사하여 변이된 멀웨어 변형을 탐지할 수 있습니다.

A05: 주입에 관한 다음 권장사항을 검토하세요.

• VirusTotal 비공개 스캔 모듈을 사용하여 민감한 업로드를 격리된 상태로 스캔하고 업로드된 파일을 서드 파티와 공유하지 마세요.
• 수집 코드에서 API 비율 제한 및 예외 처리를 구현하여 HTTP 429 Too Many Requests 상태 코드를 포착합니다.

VPC 서비스 제어

VPC 서비스 제어를 사용하면 Google Cloud 리소스 주변에 경계를 만들어 데이터 무단 반출을 방지하고 서버 측 요청 위조 (SSRF) 공격을 완화할 수 있습니다. VPC 서비스 제어는 인그레스 및 이그레스 규칙에 의해 명시적으로 허용되지 않는 한 경계 경계를 넘는 API 호출을 거부합니다.

적용 대상:

• A01: 손상된 액세스 제어
• A02: 잘못된 보안 구성

A01: 손상된 액세스 제어에 관한 다음 권장사항을 검토하세요.

• 서비스 경계에 중요 서비스 (예: Cloud Storage, BigQuery, Spanner, Agent Platform)를 포함하여 승인된 VPC 네트워크 및 신뢰할 수 있는 ID에 대한 API 액세스를 제한합니다.
• 서버리스 리소스에서 이그레스 경계 규칙을 구성하여 경계 외부 대상에 대한 아웃바운드 API 호출로 인해 발생하는 승인되지 않은 데이터 무단 반출을 차단합니다.
• 승인된 프로젝트 소스, 타겟 API, 호출자 ID를 지정하는 명시적 인그레스 및 이그레스 규칙을 사용하여 경계 간 및 조직 간 API 액세스를 제한합니다.

A02: 보안 구성 오류에 관한 다음 권장사항을 검토하세요.

• 환경 보안 등급 (예: 프로덕션 경계)별로 구성된 전용 경계로 프로젝트를 그룹화합니다. VPC 액세스 가능 서비스를 사용하여 경계 내에서 호출할 수 있는 내부 Google API를 제한합니다.
• 서버리스 워크로드의 아웃바운드 API 요청을 VPC 네트워크를 통해 라우팅합니다. Cloud Run 서비스 및 Cloud Run Functions가 직접 VPC 이그레스 또는 서버리스 VPC 액세스 커넥터를 사용하도록 구성합니다. 이때 인그레스는 내부 전용으로만 엄격하게 설정합니다.
• 회사 IP 서브넷, 인증된 ID 클레임, 엔드포인트 확인 기기 상태 신호의 조합을 평가하는 경계 인그레스 규칙에 Access Context Manager 액세스 수준을 바인딩합니다.
• 긴급 사고 대응을 위해 사전 승인된 비상 관리 프로세스를 유지하고 예기치 않은 경계 위반 이벤트에 모니터링 알림을 설정합니다.

Wiz 서비스

다음 섹션에서는Google Cloud와 통합되는 Wiz 서비스에 관한 OWASP Top 10 권장사항을 설명합니다.

Wiz Code

Wiz Code는 클라우드 보안을 개발자 워크플로 및 CI/CD 파이프라인으로 확장합니다. Wiz Code는 코드-클라우드 원격 분석을 상호 연결하고, 코드형 인프라 (IaC)를 스캔하고, 종속 항목 (SCA)을 분석하고, 노출된 사용자 인증 정보를 감지하고, 정적 애플리케이션 보안 테스트 (SAST)를 실행합니다.

적용 대상:

• A03: 소프트웨어 공급망 실패
• A05: 삽입
• A07: 인증 실패

A03: 소프트웨어 공급망 실패에 관한 다음 권장사항을 검토하세요.

• Wiz CLI를 CI/CD 파이프라인에 통합하여 보호된 브랜치에 심각한 CVE, 노출된 비밀 또는 심각한 IaC 잘못된 구성이 도입되는 경우 병합되지 않도록 풀 요청을 차단합니다.
• 모든 빌드의 SBOM을 생성하고 내보내 Wiz Cloud에서 지속적인 공급망 가시성을 유지합니다.
• Wiz Code IDE 확장 프로그램을 배포하여 실시간 개발자 의견을 제공하고, 코드 커밋 전에 취약한 패키지, 하드코딩된 API 키, 구문 오류를 포착합니다.
• CI/CD 파이프라인에서 Wiz Code를 CodeMender와 통합하여 취약한 서드 파티 종속 항목이 감지되면 pull 요청을 생성, 테스트, 제출합니다.

A05: 주입에 관한 다음 권장사항을 검토하세요.

• SAST 스캐너가 적절한 정리 없이 데이터베이스 쿼리나 OS 명령으로 흐르는 신뢰할 수 없는 사용자 입력을 감지하면 병합에서 풀 요청을 차단합니다.
• 개발자가 안전하지 않은 SQL 쿼리 또는 명령 실행 패턴을 연결하여 입력하는 경우 실시간 알림을 제공하도록 Wiz Code 플러그인을 개발자 IDE에 통합합니다.
• Wiz Code에서 삽입 결함을 신고하면 데이터 흐름 추적을 CodeMender로 라우팅하여 검증된 수정 패치를 작성합니다.

A07: 인증 실패에 관한 다음 권장사항을 검토하세요.

• 개발자 IDE, 로컬 사전 커밋 후크, CI/CD 파이프라인에서 자동 비밀 스캔을 구현하여 노출된 사용자 인증 정보를 포착합니다.
• 사용자 인증 정보 도용을 완화하려면 정적 장기 사용자 인증 정보를 동적 단기 토큰 및 ID 바인딩 액세스 (예: 워크로드 아이덴티티 제휴 또는 OIDC 기반 인증)로 대체하세요.
• 감지된 비밀번호를 코드, 환경 변수, 빌드 로그에서 삭제하는 자동화된 침해 사고 대응 플레이북을 구현합니다.

Wiz Cloud

Wiz Cloud는 멀티 클라우드 환경을 분석하여 보안 잘못된 구성, 민감한 정보 노출, ID 위험을 식별합니다. Wiz 보안 그래프를 사용하여 Wiz Cloud는 인프라 계층 전반의 위험 요소를 상호 연관시켜 중요한 공격 경로를 강조합니다.

적용 대상:

• A01: 손상된 액세스 제어
• A02: 잘못된 보안 구성
• A04: 암호화 실패
• A06: 안전하지 않은 설계

A01: 손상된 액세스 제어에 관한 다음 권장사항을 검토하세요.

• IAM 역할과 정책 전반에서 복잡한 멀티 홉 권한 에스컬레이션 경로를 추적하고 표시하여 공격자가 나중에 측면으로 이동하거나 권한을 에스컬레이션할 수 있는 위치를 식별합니다.
• 사용자 계정, 서비스 계정, AI 에이전트 간의 활성 액세스 권한을 중요한 데이터 저장소에 매핑하고 과도한 권한을 취소합니다.
• ID 권한 부여 결과를 오케스트레이션 플랫폼과 통합하여 영구 관리 역할 바인딩을 적시 (JIT) 액세스로 대체합니다.
• 데이터 이동을 모니터링하고 시각화하여 프로덕션 PII가 보안이 취약한 스테이징 또는 개발 환경에 복사되거나 동기화되는 시점을 감지합니다.

A02: 보안 구성 오류에 관한 다음 권장사항을 검토하세요.

• Wiz 보안 그래프를 사용하여 잘못된 구성과 여러 공격 요소를 연관시켜 클라우드 구성 위험을 평가하고 우선순위를 지정합니다.
• 기본 제공 규정 준수 프레임워크 (예: OWASP 상위 10개, CIS 벤치마크, NIST)를 적용하여 업계 표준에 따라 클라우드 구성을 측정합니다.
• Wiz CLI 스캐너를 CI/CD 파이프라인에 통합하여 배포 전에 빌드를 검토하거나 IaC 잘못된 구성을 수정합니다.

A04: 암호화 실패에 관한 다음 권장사항을 검토하세요.

• 일반 텍스트 사용자 인증 정보, 해싱되지 않은 키 또는 암호화 없이 저장된 민감한 정보가 포함된 데이터베이스와 스토리지 버킷의 수정에 우선순위를 두세요.
• AI 학습 디렉터리, 벡터 데이터베이스, RAG 파이프라인에서 Wiz Cloud 데이터 검색을 실행하여 LLM 수집 전에 독점 데이터와 개인 식별 정보가 수정되었는지 확인합니다.
• 환경을 스캔하여 관리되지 않는 데이터 애셋을 식별하고 중복 데이터를 삭제하여 공격 표면을 최소화합니다.

A06: 안전하지 않은 설계에 관한 다음 권장사항을 검토하세요.

• Wiz Red Agent가 논리적 아키텍처 인터페이스를 분석하고 공격 경로를 시뮬레이션하여 프로덕션 배포 전에 안전하지 않은 설계 결함을 찾도록 지시합니다.
• 검증된 공격 체인 컨텍스트를 Wiz Red Agent에서 CodeMender로 전달하여 근본 원인을 파악하고 테스트된 아키텍처 풀 요청을 생성합니다.

Wiz Defend

Wiz Defend는 클라우드 감지 및 대응 (CDR), 워크로드 런타임 보호, Kubernetes 승인 보안을 제공합니다. Wiz Defend는 컨트롤 플레인 활동을 모니터링하고, 런타임 이상을 감지하고, 컨테이너 허용 정책을 적용하고, 자동 격리를 트리거합니다.

적용 대상:

• A08: 소프트웨어 또는 데이터 무결성 실패
• A09: 보안 로깅 및 알림 실패

A08: 소프트웨어 또는 데이터 무결성 실패에 관한 다음 권장사항을 검토하세요.

• 루트 권한으로 컨테이너를 실행하거나, 호스트 네트워크 네임스페이스를 요청하거나, privileged: true를 사용 설정하려는 Kubernetes 배포 매니페스트를 검사하고 거부하도록 Wiz Defend 허용 규칙을 구성합니다.
• 웹훅에 연결할 수 없는 경우 신뢰할 수 없는 컨테이너를 차단하도록 프로덕션에서 failurePolicy: Fail(실패 시 닫힘)으로 중요한 보안 허용 웹훅을 구성합니다.

A09: 보안 로깅 및 알림 실패에 관한 다음 권장사항을 검토하세요.

• 로그 싱크를 사용하여 감사 로그를 Pub/Sub 주제로 내보내 Wiz Defend가 제어 평면 활동과 워크로드 이벤트를 수집하고 분석할 수 있도록 합니다. Google Cloud
• GKE 클러스터와 가치가 높은 Compute Engine VM에 Wiz 런타임 센서를 배포하여 런타임 위협, 메모리 내 익스플로잇, 활성 침해를 감지합니다.
• 침해된 IAM 서비스 계정을 즉시 사용 중지하거나 침해된 워크로드를 격리하도록 봉쇄 플레이북을 자동화합니다.
• Wiz Blue Agent를 사용하여 런타임 감지를 조사하고, 실시간 프로세스 텔레메트리와 ID 컨텍스트를 상호 연관시켜 근본 원인과 영향을 받는 애셋을 파악합니다.

OWASP Top 10:2025 준수 유지

Wiz에는 보안 상황을 평가하고 모니터링할 수 있는 OWASP Top 10 2025 규정 준수 프레임워크가 포함되어 있습니다. OWASP Top 10 2025 규정 준수 프레임워크는 내장된 Wiz 정책을 관련 OWASP 위험 카테고리에 매핑하고 컨트롤이 규정을 준수하지 않는 경우 발견 항목을 생성합니다. 시간 경과에 따른 규정 준수 점수를 추적할 수 있습니다. 필요한 경우 비즈니스 요구사항에 맞게 OWASP Top 10 2025 규정 준수 프레임워크를 맞춤설정할 수 있습니다.

다음 단계

추가 권장사항은 보안 권장사항 카탈로그를 참고하세요.