説明
組織の管理外にある個人アカウントに業務権限を付与すると、権限回収や認証方針の統一が難しくなる場合があります。メールのドメインだけでは管理状況や MFA の適用は判断できず、承認された外部協力者の利用が正当な場合もあります。
想定される影響
- 退職や共同作業の終了後も権限が残る場合があります。
- 認証や復旧手順が組織の基準に合わないと、アカウント侵害への対応が難しくなる場合があります。
対処方法
- 組織が管理する業務アカウントを優先し、ライフサイクル、MFA、復旧方針を確認してください。外部アカウントには管理責任者と期限または見直し手順を定めてください。
- 必要最小限のロールを付与し、不要なメンバーを取り除いてください。アカウントやグループの変更後は、必要なアクセスと旧権限の回収を確認してください。
例
プロジェクトとメールは承認された値に置き換えてください。example.com のアドレスだけでは組織管理を保証せず、roles/editor も広い権限のままです。このバインディングが管理するロールの他の必要なメンバーは保持してください。
変更前
hcl
resource "google_project_iam_binding" "example" {
project = "your-project-id"
role = "roles/editor"
members = [
"user:jane@gmail.com",
]
}
変更後
hcl
resource "google_project_iam_binding" "example" {
project = "your-project-id"
role = "roles/editor"
members = [
"user:jane@example.com",
]
}
補足:
- 変更前: 個人用メールドメインのユーザーに Editor ロールを付与します。適用される管理方針の確認が必要です。
- 変更後: メールドメインを変更します。組織管理、認証制御、最小権限まで保証する変更ではありません。