説明
同じ主体に 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",
]
}
}
補足:
- 変更前: 同じユーザーに管理ロールと復号ロールを付与します。
- 変更後: ロールを別のユーザーに分けます。継承や他のバインディングに残る権限も別途確認が必要です。