설명
같은 주체에 Cloud KMS 관리 역할과 암호화 작업 역할을 함께 부여하면 키 관리와 데이터 사용의 책임 분리가 약해집니다. 관리 역할 자체가 복호화를 허용하는 것은 아니지만, IAM 변경 권한까지 포함한 실제 권한 조합을 검토해야 합니다.
잠재적 영향
- 계정이 침해되면 키 설정이나 권한을 변경하고, 접근 가능한 암호문을 복호화하는 데 악용될 수 있습니다.
- 변경 승인과 독립적인 감사가 어려워질 수 있습니다.
해결 방법
- 키 관리와 암호화 작업 역할을 필요한 별도 주체에 부여하세요. 그룹·상속·커스텀 역할로 같은 권한이 다시 결합되는지도 확인하세요.
- 키와 데이터에 대한 접근을 최소화하고 IAM 변경 및 키 사용 기록을 검토하세요. 권한 변경 후 필요한 암호화 작업이 정상 동작하는지 확인하세요.
예시
google_project_iam_policy는 프로젝트의 전체 IAM 정책을 교체합니다. 이 일부 예제를 적용할 때 다른 필수 바인딩을 보존해 관리 접근이 끊기지 않도록 하세요. 예제 프로젝트와 계정도 실제 값으로 바꾸세요.
변경 전
hcl
resource "google_project_iam_policy" "project_policy" {
project = "your-project-id"
policy_data = data.google_iam_policy.project_policy.policy_data
}
data "google_iam_policy" "project_policy" {
binding {
role = "roles/cloudkms.admin"
members = [
"user:jane@example.com",
]
}
binding {
role = "roles/cloudkms.cryptoKeyDecrypter"
members = [
"user:jane@example.com",
]
}
}
변경 후
hcl
resource "google_project_iam_policy" "project_policy" {
project = "your-project-id"
policy_data = data.google_iam_policy.project_policy.policy_data
}
data "google_iam_policy" "project_policy" {
binding {
role = "roles/cloudkms.admin"
members = [
"user:jane@example.com",
]
}
binding {
role = "roles/cloudkms.cryptoKeyDecrypter"
members = [
"user:jane2@example.com",
]
}
}
설명:
- 변경 전: 같은 사용자에게 관리와 복호화 역할을 부여합니다.
- 변경 후: 역할을 서로 다른 사용자에게 나눕니다. 상속이나 다른 바인딩에 남은 권한도 별도로 확인해야 합니다.