セキュリティインシデントの多くはIAMの設定ミスが入り口になります。不正アクセス・意図しないデータ公開・コスト爆発——いずれも「間違った権限の付与」が原因となるケースがあります。
この記事では、Google Cloud公式ドキュメントから読み取れるIAM設計のアンチパターンの代表例を6つまとめました。「自分のプロジェクトは大丈夫か」を確認するチェックリストとして使ってください。
根拠について: この記事に書いたアンチパターンは、すべてGoogle Cloud IAMの公式ドキュメント（サービス アカウントをセキュアに使用するためのベスト プラクティス / IAM をセキュアに使用する / Google グループを使用するためのベスト プラクティス）に基づいています。筆者の主観ではなく、Googleの公式にドキュメントから読み取れることだけを取り上げています。
アンチパターン1：本番環境で基本ロールを使う
❌ やりがちなこと
開発時の動作確認を急ぎたいとき、roles/owner（オーナー）や roles/editor（編集者）をパッと付けてしまう。そのまま本番環境でも使い続けているケース。
公式ドキュメントより
「基本ロールには、すべての Google Cloud サービスにかかわる多くの権限が含まれます。本番環境では、他に選択肢がない限り、基本ロールを付与しないでください。」
出典：IAM をセキュアに使用する「最小限の権限」
roles/editor（編集者）は、プロジェクト内のほぼすべてのGCPサービスに対してリソースの作成・変更・削除ができるロールです。Cloud Storageのバケット削除、BigQueryのテーブル書き換え、Cloud Runのデプロイ——これらすべてが1つのロールで許可されます。
本来「このユーザーにはCloud Storageの読み取りだけさせたい」場合でも、roles/editorを付けると数千の余分な権限が一緒についてきます。
基本ロール一覧と権限の広さ
| ロール | ID | リスク |
|---|---|---|
| オーナー | roles/owner |
プロジェクトのIAM設定変更まで可能。最も広い |
| 編集者 | roles/editor |
ほぼ全サービスの読み書き削除が可能 |
| 閲覧者 | roles/viewer |
読み取りのみだが、機密情報を含む全リソースが対象 |
✅ 正しいアプローチ
事前定義ロール（Predefined roles） を使って必要な権限だけを付与する。Cloud Storageの読み取りだけなら roles/storage.objectViewer、BigQueryのデータ閲覧だけなら roles/bigquery.dataViewer のように、目的に合ったロールをピンポイントで付与します。
アンチパターン2：サービスアカウントを複数のサービスで共有する
❌ やりがちなこと
1つのサービスアカウントを Cloud Run・Cloud Scheduler・Cloud Functions など複数のサービスで使い回している。「サービスアカウントをいくつも作るの面倒だから」という理由で。
公式ドキュメントより
「複数のアプリケーションで単一のサービス アカウントを共有すると、サービス アカウントの管理が複雑になる場合があります。」
出典：サービス アカウントをセキュアに使用するためのベスト プラクティス「単一目的のサービス アカウントを作成する」
サービスアカウントを共有すると、そのアカウントが持つ権限は最も広い用途に合わせたものになるという問題が起きます。「Aのサービスには不要だが、Bのサービスには必要な権限」がAにも付いてしまう。
もう1つの問題が 監査ログでの追跡困難 です。1つのサービスアカウントを複数のアプリが使うと、Cloud Auditログに記録されるのは同じプリンシパル名になります。「この操作はどのアプリがやったのか」を後から追跡するのが難しくなります。
✅ 正しいアプローチ
アプリケーションごとに専用のサービスアカウントを作成する。サービスアカウントが増えて管理が大変に感じる場合は、sa-{アプリケーション名} のような命名規則を決めておくと整理しやすいです。各サービスアカウントには、そのサービス/アプリケーションが必要とする権限だけを付与します。
アンチパターン3：サービスアカウントキーをファイルに保存・コードに書く
❌ やりがちなこと
GCPの外側（オンプレ・GitHub Actions・他クラウドなど）からAPIを叩くために、サービスアカウントキーをJSONファイルでダウンロードしてローカルに保存したり、コード・環境変数に埋め込んで使い回している。
公式ドキュメントより
「このような脅威を軽減する最善の方法は、ユーザー管理のサービス アカウント キーを使用せず、可能な限り別の方法でサービス アカウントの認証を行うことです。」
出典：サービス アカウント キーを管理するためのベスト プラクティス「認証情報の漏えいを防ぐ」
サービスアカウントキーには有効期限がありません（デフォルト）。一度漏洩したキーは、削除するまで永遠に有効です。漏洩になりえる経路は様々です。
- Gitリポジトリへの誤コミット
- Slackやメールでの誤送信
- ローカルのダウンロードフォルダに放置
- Dockerイメージへの埋め込み
- CI/CDの設定ファイルへの記述
キーが漏洩しても「誰が使ったか」の特定が難しく、攻撃者は2段階認証なしでGCPリソースにアクセスできます。
✅ 正しいアプローチ
Workload Identity Federationを使うと、サービスアカウントキーなしで外部環境からGCPに認証できます。
| 外部環境 | 推奨認証方法 |
|---|---|
| GitHub Actions | Workload Identity Federation（OIDC） |
| GitLab CI | Workload Identity Federation（OIDC） |
| AWS上のワークロード | Workload Identity Federation（AWS） |
| Azure上のワークロード | Workload Identity Federation（Azure AD） |
| GCE/GKE上のワークロード | Attached service account（マネージドアイデンティティ） |
| Cloud Run / Cloud Functions | Attached service account |
GCP内のサービス同士であれば、サービスアカウントキーは不要です。Compute EngineやCloud Run、GKEにはサービスアカウントを「アタッチ」するだけで、コード側は認証を意識せずにAPIを叩けます。
アンチパターン4：個人ユーザーに直接ロールを付与する
❌ やりがちなこと
開発者が増えるたびに、1人ずつ個別にロールを付与している。alice、bob、carol……とメンバーが増えるにつれ、IAMポリシーに個人のメールアドレスがずらりと並んでいく。
公式ドキュメントより
「職務のユーザーが必要とするすべてのリソースへのアクセス権をグループに付与します。その後、その職務のユーザーをグループに追加することで、必要なアクセス権をユーザーに付与できます。この方法では、各ユーザーに同じロールを付与せずに済みます。」
出典：Google グループを使用するためのベスト プラクティス「アクセス グループを管理する」
3人のうちに気づかないかもしれませんが、組織が大きくなるにつれ「誰が何の権限を持っているか」の把握が指数関数的に難しくなります。
最大のリスクは退職・異動時の権限剥奪漏れです。個人付与の場合、退職した人のアカウントに権限が残り続けることがあります。公式ドキュメントも「ユーザーの組織変更への対応遅れ」をリスクとして挙げています。
✅ 正しいアプローチ
Googleグループ経由でロールを付与する。グループにロールを付与しておけば、メンバーの追加・削除だけで権限管理が完結します。退職者をグループから外すだけで権限も自動で失われるため、剥奪漏れが起きません。公式ドキュメントでは、アクセス制御専用の「アクセスグループ」を職務機能ごとに作成するパターンを推奨しています。
アンチパターン5：Compute Engineのデフォルトサービスアカウントをそのまま使う
❌ やりがちなこと
VM（Compute Engine）を作成するとき、サービスアカウントの設定を変えずにそのまま起動する。GCPコンソールのVM作成画面で「サービスアカウント」のプルダウンを見ると、最初から Compute Engine default service account が選択されています。これをそのまま使い続けているケース。
公式ドキュメントより
「デフォルトのサービス アカウントに編集者のロールが自動的に付与されないようにするには、組織に対してデフォルトのサービス アカウントに対する IAM ロールの自動付与の無効化の制約を有効にします。」
出典：サービス アカウントをセキュアに使用するためのベスト プラクティス「デフォルトのサービス アカウントへの自動的なロール付与を使用しない」
Compute Engineのデフォルトサービスアカウントには、プロジェクト内の大多数のGCPサービスを操作できる広い権限が付与されています。
問題は、このサービスアカウントがプロジェクト内のすべてのCompute Engineインスタンスで使い回せる状態になっていることです。VM上で動くコードは、このアカウントの権限を使ってGCPのAPIを呼べます。悪意のあるコードや脆弱なコードが混入した場合、攻撃者がプロジェクト全体に影響する操作をできてしまうリスクがあります。また、デフォルトサービスアカウントを複数のVMで共有すると、「どのVMがどのAPIを呼んだか」の監査が困難になります。
✅ 正しいアプローチ
VMの用途ごとに専用のサービスアカウントを作成し、必要最小限の権限のみ付与する。Webサーバー用VMにはCloud Storageの読み取りだけ、バッチ処理用VMにはBigQueryへの書き込みだけ、というように、VMの役割に応じた権限設計をします。VMを作成するときに「デフォルト」ではなく専用のサービスアカウントを指定することで、権限の範囲が明確になり監査ログでの追跡も容易になります。
アンチパターン6：リソースレベルで絞れるケースでもプロジェクトレベルで権限を付与してしまう
❌ やりがちなこと
「このアプリはCloud Storageを使う」という理由でプロジェクト全体のCloud Storageに対してアクセス権を付与してしまう。実際に使うのは特定のバケット1つだけなのに。
公式ドキュメントより
「必要最小限の範囲のロールを付与してください。たとえば、Pub/Sub トピックをパブリッシュするアクセス権だけを必要とするユーザーには、そのトピックのパブリッシャーのロールを付与します。」
出典：IAM をセキュアに使用する「最小限の権限」
プロジェクトレベルで roles/storage.objectAdmin を付与すると、プロジェクト内のすべてのバケット・すべてのオブジェクトに対して作成・読み取り・削除ができます。
実際のアプリが使うのは1つのバケットだけなのに、他の10個のバケットも操作できる状態になっています。万が一そのサービスアカウントが侵害された場合、被害範囲がプロジェクト全体に広がります。
✅ 正しいアプローチ
リソースレベルで権限を付与する。IAMポリシーはプロジェクト・フォルダ・組織レベルだけでなく、個別のGCSバケット・BigQueryデータセット・Pub/SubトピックなどリソースレベルでもIAMポリシーを設定できます。スコープを絞れる場合は絞ることが原則です。
まとめ：今すぐ確認できるチェックリスト
以下の6点を確認してみてください。
| チェック項目 | 確認場所 |
|---|---|
本番で roles/owner or roles/editor を使っていないか |
GCPコンソール → IAM |
| サービスアカウントを複数サービスで共有していないか | IAM → サービスアカウント一覧 |
| ダウンロードしたSAキーが残っていないか | IAM → サービスアカウント → キー |
| 個人ユーザーに直接ロールを付与していないか | GCPコンソール → IAM |
| デフォルトSAをそのまま使っているVMがないか | Compute Engine → VMインスタンス |
| プロジェクトレベルで絞れる権限を絞っていないか | GCPコンソール → IAM |
IAMの設定ミスは「動いているから気づかない」のが最大の問題です。定期的に棚卸しする習慣が、長期的なセキュリティリスクを下げる一番の対策になります。
参考ドキュメント