IAMの基本ロールの使用を制限する設定手順
このブログシリーズ 「クラウドセキュリティ 実践集」 では、一般的なセキュリティ課題を取り上げ、「なぜ危険なのか？」 というリスクの解説から、 「どうやって直すのか？」 という具体的な修復手順（コンソール、gcloud CLI、Terraformなど）まで、分かりやすく解説します。
この記事では、IAMの基本ロールの使用を制限する設定手順について、リスクと対策を解説します。
ポリシーの説明
IAMの基本ロール（プリミティブロール）の使用を制限し、より細かな権限制御を実現します。
Google CloudのIAMでは、基本ロール（オーナー、編集者、閲覧者）が提供されていますが、これらのロールは非常に広範な権限を持っています。組織内のユーザーアカウントに対してこれらの基本ロールを直接付与することは、最小権限の原則に反し、セキュリティリスクを高める要因となります。代わりに、事前定義ロールやカスタムロールを使用することで、必要最小限の権限のみを付与することが重要です。
特に本番環境で操作する場合には非常に広い権限となってしまうため、フォルダ及びプロジェクト構成を適切に行なった上で適切に最小限の権限付与となるような構成にしましょう。
修復方法
前提条件
修復作業を開始する前に、以下の点を確認してください：
- 組織管理者またはプロジェクトオーナーの権限を持っていること
- 既存のユーザーの業務要件を理解していること
- 権限変更による影響を評価済みであること
コンソールでの修復手順
Google Cloud コンソールを使用して、基本ロールを削除し、適切な事前定義ロールまたはカスタムロールに置き換えます。
- Google Cloud Consoleにログインし、IAMと管理ページに移動します。
- IAMをクリックして、現在のIAMポリシーを表示します。
- 基本ロールが付与されているユーザーを特定します：
- 「ロール」列で以下のロールを探します：
roles/owner（オーナー）roles/editor（編集者）roles/viewer（閲覧者）
- 「ロール」列で以下のロールを探します：
- 基本ロールを持つユーザーの行で、編集（鉛筆アイコン）をクリックします。
- 現在の基本ロールを削除し、適切な事前定義ロールを追加します。以下は一般的な置き換え例です：
編集者ロールの代替案：
- 開発者向け：
roles/compute.instanceAdmin– VM管理roles/storage.objectAdmin– ストレージ管理roles/logging.viewer– ログ閲覧
- データアナリスト向け：
roles/bigquery.dataEditor– BigQueryデータ操作roles/dataflow.developer– Dataflowジョブ管理
閲覧者ロールの代替案：
- 監査担当者向け：
roles/iam.securityReviewer– セキュリティ設定の確認roles/logging.viewer– ログの閲覧roles/monitoring.viewer– モニタリング情報の閲覧
- 開発者向け：
- 保存をクリックして変更を適用します。
- 組織ポリシーで基本ロールの使用を制限します：
- 組織のポリシーに移動
- 新しいポリシーを作成し、以下の制約を設定：
constraints/iam.allowedPolicyMemberDomains– 許可されるドメインを制限- カスタム組織ポリシーで基本ロールの付与を監視
まとめ
この記事では、IAMの基本ロールの使用を制限する設定手順について、リスクと対策を解説しました。
基本ロールから事前定義ロールやカスタムロールへの移行は、最小権限の原則を実現し、セキュリティを大幅に向上させます。段階的に権限を見直し、業務に必要な最小限の権限のみを付与することで、セキュリティリスクを低減できます。
また、監査ログの活用やアラート設定により、不適切な権限付与を早期に検出し、迅速に対応することが可能になります。
この問題の検出は弊社が提供するSecurifyのCSPM機能で簡単に検出及び管理する事が可能です。 運用が非常に楽に出来る製品になっていますので、ぜひ興味がある方はお問い合わせお待ちしております。
最後までお読みいただきありがとうございました。この記事が皆さんの役に立てば幸いです。
参考情報
- Google Cloud IAM 公式ドキュメント
- IAM ロールの理解と使用ガイド
- IAM ベストプラクティス
- カスタムロールの作成と管理
- 条件付きロールバインディング
- Cloud Asset Inventory
- 組織ポリシーの管理