이 가이드에서는 Secret Manager 사용 시 몇 가지 권장사항을 소개합니다. 이 가이드에는 권장사항이 모두 포함되어 있지 않습니다. 이 가이드를 읽기 전에 Google Cloud 환경에 대한 전반적인 이해를 돕기 위해 플랫폼 개요 및 Secret Manager 개요를 살펴보는 것이 좋습니다.
액세스 제어
Secret Manager API에 대한 액세스는 IAM으로 보호됩니다. 보안 비밀에 권한을 부여할 때 최소 권한의 원칙을 따르세요.
- 조직 소유권을 보안 최고 관리자 계정으로 제한합니다.
- Google Cloud 시작 영역의 리소스 계층 구조 결정에 설명된 대로 애플리케이션과 환경(스테이징/프로덕션)을 개별 프로젝트로 분할합니다. 이를 통해 프로젝트 수준의 IAM 바인딩으로 환경을 격리하고 할당량이 독립적으로 적용되도록 할 수 있습니다.
- 필요한 최소한의 권한으로 선별된 역할을 선택하거나 필요한 경우 커스텀 역할을 만듭니다.
- 여러 서비스의 보안 비밀이 단일 프로젝트에 있는 경우 보안 비밀 수준 IAM binding 또는 IAM 조건을 사용하여 필요한 보안 비밀의 하위 집합에 대해서만 액세스를 제한할 수 있습니다.
- IAM 추천자는 권한이 과도하게 부여된 IAM binding을 식별하는 데 도움이 될 수 있습니다.
Secret Manager API에 인증하려면 사용자 인증 정보가 필요합니다. 모든 클라이언트 라이브러리도 '애플리케이션 기본 사용자 인증 정보'라는 사용자 인증 정보를 찾기 위해 유사한 전략을 사용합니다.
- 로컬에서 개발할 때는
gcloud auth application-default login을 사용합니다. 그러면 클라이언트 라이브러리에서 자동으로 선택되는 사용자 인증 정보가 포함된 파일이 생성됩니다. - Compute Engine 및 Cloud Functions와 같은 다른 Google Cloud 컴퓨팅 플랫폼에서 클라이언트 라이브러리는 인스턴스 메타데이터 서버를 통해 사용자 인증 정보를 가져옵니다.
- GKE에서 워크로드 아이덴티티는 메타데이터 서비스를 통해 사용자 인증 정보도 제공합니다.
- Amazon Web Services 또는 Microsoft Azure와 같은 다른 플랫폼에서는 기존 ID 메커니즘을 사용하여 Google Cloud API에 인증하는 워크로드 아이덴티티 제휴를 설정하는 것이 좋습니다.
이러한 모든 방법은 Secret Manager API 외부에 추가 보안 비밀을 안전하게 저장하고 액세스할 필요가 없으므로 서비스 계정 사용자 인증 정보를 내보내는 것보다 좋습니다.
코딩 방법
파일 시스템 또는 환경 변수를 통해 애플리케이션에 보안 비밀을 전달하는 것이 일반적이지만 가능한 경우 다음과 같은 이유로 피해야 합니다.
- 파일 시스템에서 보안 비밀에 액세스할 수 있으면 공격자가 보안 비밀 자료를 읽을 수 있으므로 디렉터리 순회 공격과 같은 애플리케이션 취약점의 심각도가 더 높아질 수 있습니다.
- 보안 변수를 환경 변수를 통해 사용할 경우 디버그 엔드포인트 사용 설정 또는 프로세스 환경 세부정보를 로깅하는 종속 항목 포함과 같은 구성 오류가 보안 비밀을 유출할 수 있습니다.
- 보안 비밀 자료를 다른 데이터 저장소(예: Kubernetes 보안 비밀)와 동기화할 때는 다음과 같이 해당 데이터 저장소의 액세스 제어 사항을 고려해 보세요.
- Datastore가 보안 비밀에 대한 액세스를 확장하나요?
- 보안 비밀 액세스를 감사할 수 있나요?
- Datastore가 저장 데이터 암호화 및 리전화 요구사항을 준수하나요?
Secret Manager API를 직접 사용하는 것이 좋습니다(제공된 클라이언트 라이브러리 중 하나를 사용하거나, REST 또는 GRPC 문서 참조).
하지만 서버리스 통합과 같은 일부 제품 통합의 경우 파일 시스템 또는 환경 변수를 통해 보안 비밀을 전달할 수 있습니다. 자세한 내용은 다른 제품에 Secret Manager 사용을 참조하세요.
행정
워크로드에 특정 위치 요구사항(constraints/gcp.resourceLocations 제약조건을 사용하여 시행 가능)이 없는 한 보안 비밀을 만들 때 자동 복제 정책을 선택합니다.
최신 별칭을 사용하는 대신 버전 번호로 보안 비밀 참조 기존 출시 프로세스를 사용하여 버전 번호에 업데이트를 배포합니다. 일반적으로 이는 시작 시 읽는 특정 보안 비밀 버전으로 애플리케이션을 구성하는 것을 의미합니다. 최신 별칭을 사용하는 것이 편리할 수 있지만 보안 비밀의 새 버전에 문제가 있으면 워크로드가 보안 비밀 버전을 사용하지 못할 수 있습니다. 버전 번호를 고정하면 기존 출시 프로세스를 사용하여 구성을 검증하고 롤백할 수 있습니다.
보안 비밀 버전을 폐기하거나 보안 비밀을 삭제하기 전에 보안 비밀 버전을 사용 중지합니다. 이렇게 하면 보안 비밀을 폐기된 것처럼 보이지만 되돌릴 수 있는 상태로 만들어 서비스 중단을 방지할 수 있습니다. 즉, 데이터를 영구적으로 삭제하기 전에 종속 항목이 남아 있는지 확인할 수 있도록 일주일 동안 사용 중지하고 대기할 수 있습니다.
영구적으로 삭제해야 하는 경우가 아니라면 프로덕션 보안 비밀에 만료 시간을 설정하지 마세요. 만료 기능은 임시 환경 자동 정리에 가장 적합합니다. 보안 비밀 만료의 대안으로 시간 기반 IAM 조건을 고려하세요.
다음을 수행하기 위해 주기적으로 보안 비밀을 순환합니다.
- 보안 비밀 유출의 경우 영향을 제한합니다.
- 보안 비밀에 더 이상 액세스할 필요가 없는 사용자는 이전에 액세스한 보안 비밀을 계속 사용할 수 없도록 합니다.
- 순환 흐름을 지속적으로 수행하여 서비스 중단 가능성을 줄입니다.
Cloud 애셋 인벤토리를 사용하여 조직 전반에서 보안 비밀을 모니터링하여 다음을 수행할 수 있습니다.
- 조직의 보안 비밀을 식별할 수 있도록 지원합니다.
- 순환, 암호화 구성, 위치와 같은 조직 요구사항을 준수하지 않은 사항을 확인합니다.
데이터 액세스 로그를 사용 설정하여 AccessSecretVersion 요청 정보를 가져오고 분석합니다. 모든 보안 비밀 또는 프로젝트에서 이를 구성하지 않고 로깅을 시행하려면 폴더 또는 조직 수준에서 이 기능을 사용 설정하세요.
IAM 제어 외에도 조직의 VPC 서비스 제어 경계를 설정하여 네트워크 기반 제어로 Secret Manager API에 대한 액세스를 제한할 수 있습니다.
constraints/iam.allowedPolicyMemberDomains 조직 정책을 사용하여 보안 비밀의 IAM 정책에 추가할 수 있는 ID를 제한할 수 있습니다.
최대 보안 비밀 사용량(동시 애플리케이션 배포 또는 서비스 자동 확장으로 인한 'Thundering Herd' 요청 고려)을 예측하고 프로젝트에 이러한 이벤트를 처리하는 데 충분한 할당량이 있는지 확인합니다. 할당량이 더 필요하다면 증가를 요청하세요.