はじめに
クラウドを利用する上で、セキュリティの要となるのが IAM（Identity and Access Management） です。
「誰が」「何に対して」「どのような操作ができるか」を適切に管理しないと、思わぬセキュリティ事故につながる可能性があります。
この記事では、Google CloudにおけるIAMの仕組みを基礎から解説し、現場で使える権限設計のベストプラクティスを紹介します。
1. IAMの基本概念（3つの柱）
Google CloudのIAMを理解するには、以下の3つの要素の関係性を把握することが重要です。
プリンシパル（Principal）
「誰が」にあたる部分です。IAMポリシーで権限を付与される主体を指します。
かつては「メンバー」と呼ばれていましたが、現在はプリンシパルという名称に統一されています。
主な種類は以下の通りです。
- Googleアカウント: 個人のユーザー
- サービスアカウント: アプリケーションやVMなどのプログラム
- Googleグループ: 複数のGoogleアカウントをまとめたグループ
ロール（Role）
「何をできるか」にあたる権限の集合体です。
Google Cloudでは、個別の権限（例: compute.instances.start）を直接ユーザーに付与することはできません。必ず「ロール」というパッケージ単位で付与します。
ポリシー（Policy）
「誰（プリンシパル）」に「どの役割（ロール）」を紐付けるかを定義したものです。
このポリシーをプロジェクトやリソースにアタッチすることで、アクセス制御が有効になります。
2. リソース階層と継承
Google Cloudのリソースは階層構造になっており、権限はこの階層（Organization > フォルダ > プロジェクト > リソース）に沿って継承されます。
重要なポイント
上位階層（例：組織やフォルダ）で付与された権限は、下位階層（プロジェクトや個別のリソース）に自動的に引き継がれます。
例えば、組織レベルで「オーナー」権限を持っているユーザーは、その組織下の全プロジェクトでオーナーとして振る舞うことができます。これを制限するために「拒否ポリシー」などが存在しますが、基本は 「上位で強い権限を与えすぎない」 ことが鉄則です。
3. ロールの種類と使い分け
ロールには大きく分けて3つの種類があります。これらを適切に使い分けることが、セキュアな環境構築の第一歩です。
基本ロール（Basic Roles）
GCPプロジェクトが作成される前から存在する、古いタイプのロールです。
- 閲覧者（Viewer）: 読み取り専用
- 編集者（Editor）: 状態を変更可能
- オーナー（Owner）: 編集者に加え、権限管理や課金設定も可能
注意点: 権限の範囲が広すぎるため、本番環境での利用は推奨されません。検証環境や、プロジェクトの初期セットアップ時のみに限定して使用しましょう。
事前定義ロール（Predefined Roles）
Googleがサービスごとに用意している、より粒度の細かいロールです。
-
roles/storage.objectViewer（Cloud Storageのオブジェクト閲覧のみ） -
roles/compute.networkAdmin（ネットワーク管理のみ）
通常運用では、この 「事前定義ロール」 をメインに使用します。必要なサービスに必要な分だけの権限を与えることができます。
カスタムロール（Custom Roles）
事前定義ロールでは要件を満たせない場合、個別の権限（Permission）を組み合わせて自作するロールです。
管理コストがかかるため、どうしても必要な場合のみ作成するようにしましょう。
4. サービスアカウント（Service Account）とは
サービスアカウントは、人間ではなく「アプリケーション」や「リソース」がAPIを操作するために使用する特別なアカウントです。
例えば、Compute Engine上のプログラムがCloud Storageにデータをアップロードする場合、そのVMインスタンスにサービスアカウントを割り当て、そのサービスアカウントに「Storage オブジェクト管理者」ロールを付与します。
キーの管理リスク
サービスアカウントには認証用の「キー（JSONファイル）」を発行できますが、これの漏洩は重大なセキュリティリスクになります。
Google Cloud上で動くリソースであれば、キーを発行せずともIAM認証が可能です（Managed Identity）。ローカル開発環境やオンプレミスから接続する場合を除き、キーのダウンロードは極力避ける のが安全です。
5. IAM運用のベストプラクティス
最後に、現場ですぐに実践できるIAM設計のポイントを紹介します。
最小権限の原則（Least Privilege）を徹底する
「とりあえず編集者権限」は厳禁です。
作業に必要な最小限の権限（事前定義ロール）だけを付与しましょう。最初は権限不足でエラーが出ることもありますが、Cloud Loggingで不足権限を確認しながら追加していく方が安全です。
個人ユーザーへの直接付与を避ける
個々のGoogleアカウントに直接ロールを紐付けると、異動や退職時の管理が煩雑になります。
Googleグループを作成し、そのグループに対してロールを割り当てましょう。ユーザーの追加・削除はGoogle Workspace（またはCloud Identity）側で行うことで、IAMポリシーを触る必要がなくなります。
デフォルトサービスアカウントの権限に注意する
Compute Engineなどを有効化すると自動作成される「デフォルトのサービスアカウント」には、初期状態で編集者（Editor）という強力な権限が付与されていることが多いです。
本番環境ではこのデフォルトアカウントを使用せず、用途ごとに専用のサービスアカウントを作成し、必要な権限だけを付与して利用しましょう。
まとめ
IAMはクラウドセキュリティの要です。以下のポイントを押さえて、安全なGoogle Cloud環境を構築しましょう。
- 基本概念: プリンシパル、ロール、ポリシーの関係を理解する
- ロール: 基本ロールは避け、事前定義ロールを活用する
- サービスアカウント: キーの発行は最小限にし、VM等にはManaged Identityを使う
- 運用: 最小権限の原則を守り、Googleグループ単位で管理する
最初は面倒に感じるかもしれませんが、初期段階で適切なIAM設計を行うことが、将来的な運用コストとセキュリティリスクの大幅な削減につながります。
※本記事の内容は執筆時点（2025年12月）の情報に基づきます。最新の仕様は公式ドキュメントをご確認ください。