---
title: "GCP 보안 강화 체크리스트 | Snow Tree"
url: "https://www.snow-tree.com/ko/gcp-security-hardening/"
---

안전한 GCP 인프라

# 중소 규모 팀을 위한 GCP 보안 강화 체크리스트

전담 보안 부서 없이 Google Cloud에서 프로덕션 워크로드를 운영하는 팀을 위한 실용적인 기준선입니다. 심각한 사고로 이어질 가능성이 가장 높으면서도 가장 쉽게 줄일 수 있는 경로부터 시작하세요.

## 이 페이지의 내용

1. [일반적인 GCP 위협 경로](https://www.snow-tree.com/ko/#threat-paths)
2. [ID 및 액세스](https://www.snow-tree.com/ko/#identity)
3. [네트워크 및 엣지](https://www.snow-tree.com/ko/#network)
4. [데이터 및 보안 비밀](https://www.snow-tree.com/ko/#data)
5. [GKE 보안 강화](https://www.snow-tree.com/ko/#gke)
6. [탐지 및 복구](https://www.snow-tree.com/ko/#detection)
7. [우선순위가 지정된 30일, 60일, 90일 체크리스트](https://www.snow-tree.com/ko/#checklist)
8. [공식 참고자료](https://www.snow-tree.com/ko/#references)

## 일반적인 GCP 위협 경로

대부분의 클라우드 사고는 소유권이나 구성의 작은 공백에서 시작됩니다. 공격자보다 먼저 다음 경로를 찾아보세요.

- 권한이 과도한 사용자, 서비스 계정 또는 워크로드 ID가 있으면 도난당한 자격 증명 하나가 여러 프로젝트에 걸친 광범위한 액세스로 이어질 수 있습니다.
- 노출된 관리 엔드포인트, 디버그 포트 또는 허용 범위가 넓은 방화벽 규칙은 일반 애플리케이션 트래픽용으로 설계된 모든 제어를 우회할 수 있습니다.
- 공개 스토리지 버킷이나 범위가 지나치게 넓은 서명된 URL은 애플리케이션 침해의 흔적이 없어도 고객 데이터를 노출할 수 있습니다.
- 오래된 이미지, 잊힌 네임스페이스, 사용하지 않는 서비스 계정, 소유자가 없는 리소스가 여전히 배포 가능한 상태로 남아 있으면 방치된 워크로드가 지속적인 위험이 됩니다.
- 감사 증거가 없거나 보존 기간이 짧으면 누가 정책을 변경했는지, 언제 액세스가 시작되었는지, 어떤 데이터에 접근했는지 파악하기 어렵습니다.
- 테스트하지 않은 백업은 희망에 불과합니다. 복원 실패, 불완전한 보존, 액세스할 수 없는 암호화 키로 인해 보안 이벤트가 영구적인 손실로 이어질 수 있습니다.

## ID 및 액세스

ID를 기본 컨트롤 플레인으로 취급하세요. 모든 사람, 자동화 프로세스, 워크로드에는 목적이 제한된 고유한 ID가 있어야 합니다.

### 리소스 경계를 명시적으로 지정

가드레일에는 조직과 폴더를 사용하고, 개발, 스테이징, 프로덕션은 프로젝트 또는 더 강력한 신뢰 경계로 분리하세요. 조직 정책은 실무적으로 가능한 가장 높은 수준에서 적용하고, 서비스 사용을 제한하며, 관련 없는 제품 간에 프로덕션 프로젝트를 공유하지 마세요.

### 가장 좁은 범위에서 최소한의 역할 부여

광범위한 기본 역할 대신 사전 정의된 역할이나 커스텀 역할을 그룹과 워크로드 ID에 부여하고, 리소스 이름이나 태그로 액세스 범위를 좁힐 수 있는 경우에는 IAM 조건을 사용하세요. 사용하지 않는 권한을 검토하고, 긴급 액세스(break-glass) 절차에서만 필요한 상시 프로덕션 액세스를 제거하세요.

### 수명이 긴 자격 증명 제거

Workload Identity Federation for GKE를 사용해 서비스 계정 키를 내보내지 않고도 포드가 단기 자격 증명을 받도록 하세요. 가능한 경우 조직 정책으로 키 생성과 업로드를 차단하고, 남아 있는 키를 모두 목록으로 파악하며, Cloud Audit Logs에서 위험도가 높은 IAM 변경이 감지되면 알림을 보내세요.

## 네트워크 및 엣지

애플리케이션의 어떤 결함이든 결국 네트워크에서 접근 가능해진다고 가정하고, 그 결함이 액세스할 수 있는 범위를 제한하세요.

### 거부에서 시작해 명시한 경로만 추가

최소 권한 VPC 방화벽 규칙을 사용하고, 포드 트래픽에는 Kubernetes NetworkPolicy를 사용하세요. 환경을 별도의 네트워크로 분리하고, 모든 인그레스 경로를 문서화하며, 넓은 주소 범위에서 관리 포트나 모든 프로토콜을 허용하는 광범위한 디버그 규칙을 제거하세요.

### 노드와 컨트롤 플레인을 비공개로 유지

GKE 노드의 외부 IP 주소를 사용 중지하세요. DNS 기반 비공개 컨트롤 플레인 엔드포인트를 우선 사용하고, IP 엔드포인트가 불가피한 경우에는 승인된 네트워크로 제한하세요. 워크로드에는 광범위한 인터넷 액세스 대신 의도적으로 설계한 이그레스 경로를 제공하세요.

### 의도한 공개 서비스만 게시

애플리케이션은 우연히 노출된 포드나 노드 주소가 아니라 검토를 거친 게이트웨이나 부하 분산기를 통해 노출하세요. 관리형 인증서로 TLS를 종료하고, 인그레스 호스트와 경로를 제한하며, 요청 한도와 비율 제한을 적용하고, 관리 인터페이스는 ID 인식 액세스 뒤에 두세요.

## 데이터 및 보안 비밀

저장 중, 전송 중, 사용 중인 데이터를 보호하고, 이를 복구할 수 있음을 입증하세요. 데이터 검색도 통제의 일부입니다.

### 실수로 인한 공개 액세스 방지

Cloud Storage에 공개 액세스 방지와 균일한 버킷 수준 액세스를 적용하세요. 민감도에 따라 버킷을 분류하고, 객체 및 키 액세스를 제한하며, 가치가 높은 데이터에 대해 로깅을 사용 설정하고, 위험 또는 규정 준수 모델에서 요구하는 경우 고객 관리 암호화 키를 사용하세요.

### 보안 비밀을 이미지와 소스 코드에 넣지 않기

자격 증명은 Secret Manager에 저장하고 특정 워크로드 ID와 특정 보안 비밀 버전에만 액세스 권한을 부여하세요. 보안 비밀은 계획적으로 순환하고, Git이나 컨테이너 이미지에 복사하지 말며, 일반 Kubernetes Secrets를 완전한 보호 경계로 간주하지 마세요.

### 백업 생성만이 아니라 복구를 테스트

복구 지점 목표(RPO)와 복구 시간 목표(RTO)를 정의하고, 프로덕션 장애 도메인 밖에 사본을 보관하며, 백업과 암호화 키에 대한 액세스를 워크로드 ID로부터 보호하세요. 정기적으로 격리된 환경에 복원해 데이터를 확인하고, 소요 시간과 모든 수동 단계를 기록하세요.

## GKE 보안 강화

GKE는 관리형 컨트롤 플레인을 보호하지만 클러스터 구성, 네임스페이스, 어드미션 정책, 워크로드의 관리는 여전히 사용자의 책임입니다.

### 네임스페이스를 격리 계약으로 만들기

팀과 환경을 네임스페이스나 클러스터로 분리하고, 그 안에 범위가 좁은 Kubernetes RBAC 역할을 바인딩하며, 리소스 할당량과 NetworkPolicy를 적용하세요. 애플리케이션 딜리버리에 클러스터 전체 쓰기 액세스를 사용하지 말고, 고유한 ID가 필요한 워크로드에는 각각 전용 서비스 계정을 부여하세요.

### 신뢰할 수 있는 이미지와 구성만 허용

제한된(Restricted) Pod Security 표준 또는 이에 상응하는 Policy Controller 규칙을 적용하세요. 이미지는 변경 불가능한 다이제스트로 배포하고, 취약점을 스캔하며, 출처가 중요한 경우 Binary Authorization을 사용하고, 예상치 못한 호스트 액세스, 권한 에스컬레이션, cluster-admin 바인딩을 거부하세요.

### 불필요한 컨테이너 권한 제거

루트가 아닌 사용자로 실행하고, Linux capabilities를 제거하고, 가능하면 읽기 전용 루트 파일 시스템을 사용하며, RuntimeDefault seccomp 프로필을 적용하세요. 필요하지 않으면 서비스 계정 토큰을 마운트하지 말고, 권한 있는(privileged) 컨테이너와 호스트 네임스페이스를 피하며, 노드 서비스 계정의 권한을 최소화하고, Shielded Nodes와 Container-Optimized OS를 사용하세요.

## 탐지 및 복구

통제는 실패할 수 있습니다. 아무도 실수하지 않았으리라는 믿음이 아니라 증거와 미리 연습한 대응에 의존하세요.

### 필요한 증거 수집

Cloud Audit Logs와 GKE 시스템 및 워크로드 로그를 조사 요구 사항에 맞는 보존 기간으로 중앙 대상에 보관하세요. 민감한 데이터에 대해서는 데이터 액세스 감사 로그를 선택적으로 사용 설정하고, 로그 액세스를 제한하며, IAM, 방화벽, 스토리지, 클러스터 구성에 대한 관리 변경을 기록하세요.

### 보안상 의미 있는 변경에 대한 알림

공개 스토리지 노출, 광범위한 방화벽 또는 IAM 변경, 예상치 못한 서비스 계정 키, 어드미션 거부, 컨트롤 플레인 노출, 반복적인 인증 실패, 로깅 사용 중지, 백업 실패, 만료가 임박한 인증서에 대해 알림을 설정하세요. 각 알림은 이를 확인하거나 기각하는 단계와 함께 담당자에게 전달하세요.

### 대응 리허설

자격 증명 유출, 데이터 공개, 워크로드 침해, 리전 또는 프로젝트 손실에 대비한 짧은 런북을 작성하세요. 격리 조치를 승인할 수 있는 사람, 액세스 권한을 취소하는 방법, 증거를 보존하는 방법, 서비스를 복원하는 방법을 포함하세요. 런북은 실제로 사용할 사람들과 함께 테스트하세요.

## 우선순위가 지정된 30일, 60일, 90일 체크리스트

불완전한 기준선에서 시작하는 경우 먼저 노출을 줄이고 나중에 검토를 반복할 수 있도록 작업 순서를 지정하세요.

### 1~30일: 명백한 경로 차단

프로젝트와 소유자의 목록을 작성하고, 사용하지 않거나 수명이 긴 자격 증명을 제거하고, 감사 로깅을 확인하고, 공개 버킷을 차단하고, 범위가 가장 넓은 방화벽 규칙과 IAM 권한 부여를 검토하고, 프로덕션 백업의 공백을 파악하고, 소유자가 없는 공개 엔드포인트를 수정하세요. 모든 발견 사항에 담당자와 기한을 지정하세요.

### 31~60일: 기준선을 반복 가능하게 만들기

네트워크, ID, 워크로드 구성을 검토를 거치는 코드형 인프라(IaC)와 GitOps 딜리버리로 옮기세요. Workload Identity, 비공개 노드, 제한된 Pod Security, 신뢰할 수 있는 이미지 검사, 중앙 집중식 로그, 가장 중요한 변경에 대한 알림을 도입하세요.

### 61~90일: 입증하고 유지하기

복원 테스트와 사고 대응 모의 훈련(테이블탑 연습)을 실시하고, 권한 있는 액세스와 예외 만료를 검토하고, 이미지와 종속 항목을 다시 스캔하고, 소유자가 알림을 받는지 확인하고, 남아 있는 공백을 측정하세요. 증거가 오래되기 전에 이러한 점검을 정기 검토 주기에 포함하세요.

이 체크리스트를 출발점으로 활용하세요. Snow Tree는 관리형 플랫폼 운영 또는 특정 과제에 집중한 컨설팅을 통해 이 기준선을 적용할 수 있습니다.

[관리형 플랫폼](https://www.snow-tree.com/ko/managed-platform/) [컨설팅](https://www.snow-tree.com/ko/consulting/)

## 공식 참고자료

플랫폼 기본값이나 제품 기능이 바뀌면 Google의 최신 안내를 기술적 기준 정보로 삼으세요.

- [Google Cloud: GKE 클러스터 강화를 위한 모범 사례](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster)
- [Google Cloud: GKE 보안 모범 사례](https://docs.cloud.google.com/docs/security/gke-security-bps)

관리형 플랫폼

## Snow Tree가 소프트웨어를 구축하고 호스팅하며 운영합니다.

[프로젝트 시작하기](mailto:support+snow-tree-platform-1-issue-@gitlab.snow-tree.com?subject=Snow%20Tree%20project)