Blog series Google Cloud セキュアな土台作り: 第３回

第3回 Google Cloud をセキュアに利用するポイント IAM編（基本）

はじめに

お疲れ様です。SKYこと関谷です。
前回の第2回では、Google Cloud のリソース階層について学びました。組織（Organization）、フォルダ（Folder）、プロジェクト（Project）、そして具体的なリソース（VM やストレージバケットなど）がどのように階層化され、それぞれに意味があるのかを確認しました。これはいわば、Google Cloud 環境をどのように「建物の構造」として設計するか、という話でした。

では、その「建物」に誰が入ることができ、どの部屋に入って、何をできるのかを制御する仕組みは何でしょうか。これを担っているのが IAM（Identity and Access Management） です。

IAM はクラウド環境におけるセキュリティとガバナンスの中心的存在です。
Google Cloud を導入して間もない組織では、便利さを優先してユーザーに広すぎる権限を与えがちです。しかしその結果、誤操作や不正アクセスによる被害が拡大し、思わぬトラブルにつながります。逆に IAM を正しく理解し、適切に設計・運用できれば、セキュリティを維持しながらスムーズにプロジェクトを展開できます。

今回の第3回では、この IAM をテーマに、以下の流れで解説を進めます。

• 3-1 IAM の心臓部：「誰が」「どのリソースに」「何をするか」
• 3-2 セキュリティの基本原則：「最小権限の原則」
• 3-3 Google グループを使った効率的な権限管理
• 3-4 サービスアカウントの勘所
• 3-5 参照情報（Google Cloud 公式ドキュメント）

「IAM は難しい」と感じる方も多いかもしれませんが、考え方を一つひとつ整理すれば決して複雑ではありません。むしろ「IAM を制することがクラウドセキュリティを制すること」に直結すると言っても過言ではありません。

本稿では、Google Cloud 初心者から中級者へのステップアップを意識し、実際の現場でよくある失敗や工夫を交えながら、IAM の基本と実践的な活用方法を丁寧に解説していきます。

ブログシリーズその他の執筆

＊2025.09.05更新*
本編
https://zenn.dev/densan_techblog/articles/f40922222f37c5
https://zenn.dev/densan_techblog/articles/c34cac120413ee

番外編
https://zenn.dev/densan_techblog/articles/cc0ee6113a11bb

番外編1は、本回の拡張回としての位置付けになります。
応用編として、より実践的かつ最新のセキュア運用機能・手法を記載していますので、こちらも是非ご参照ください。

3-1. IAM の心臓部：「誰が」「どのリソースに」「何をするか」

IAM（Identity and Access Management）は、Google Cloud におけるアクセス制御の基盤です。要点はつねに 「誰が（プリンシパル）」「どのリソースに（スコープ）」「何をするか（ロール／権限）」 の 3 つを結び合わせて考えることに尽きます。

プリンシパル（誰が）

アクセス権を持つ主体（Principal）です。代表的な種類と実務上の注意点は以下のとおりです。

• ユーザー
  Google Workspace や Cloud Identity で管理されるアカウント。人がコンソールや gcloud CLI を操作します。
  例: [e-mail]

• Google グループ
  複数のユーザーをまとめる単位。役割ごとにグループを作り、グループにロールを付与すると運用が安定します。
  例: [e-mail], [e-mail]

• サービス アカウント
  システムやプログラムが利用する専用アカウント。VM や Cloud Run、GKE などの実行環境にアタッチして API を呼び出します。
  例: [e-mail]

• ドメイン
  @example.com のように組織単位で付与。広すぎる対象になるため、用途は慎重に検討します。

• 特殊プリンシパル
  allUsers（匿名を含む全ユーザー）、allAuthenticatedUsers（Google アカウントで認証済みのユーザー全員）。基本は使わない のが原則。どうしても必要なら公開影響を理解したうえで最小範囲で。
  　　> 「インターネット上の匿名を含む不特定多数すべて」を指すため、静的ウェブ公開などを除き、極力使用を避けるべきです。

  • allAuthenticatedUsers は「Google アカウントで認証された全ユーザー」であり、自社だけではなく世界中の Google アカウント所有者が含まれるため、誤って社外に公開しないよう注意が必要です。

ロール（何をするか）

ロールは権限（Permission）の集合です。個々の Permission を直接付与するのではなく、ロールを介して 付与します。

• 基本ロール: roles/owner / roles/editor / roles/viewer
  広範囲をカバーしますが、原則として避けます（とくに Owner / Editor）。
  　　:::message
  　　本稿で「基本ロール」（Owner / Editor / Viewer）と呼ばれているものは、実際には現在では レガシー基本ロール（もしくはプリミティブ ロール） として扱われ、より精緻な条件付きIAM（たとえば、時間帯やIP制限などを条件とできる）による制御には対応していない旧式の設計です。現代的なセキュリティ運用を志向する上では、原則としてこれらを避け、代替の細分化されたロールを使用するという意識を持つことが重要です。
  　　:::

• 事前定義ロール（プリデファインド ロール）
  サービスごとに粒度の細かいロールが用意されています。例:

  • roles/storage.objectViewer（Cloud Storage オブジェクトの閲覧）
  • roles/compute.instanceAdmin（Compute Engine インスタンス管理）

• カスタム ロール
  業務に必要な Permission だけを選び、独自に定義します。事前定義ロールでフィットしない差分を最小限で補う用途に有効です。

リソース（どの対象に）

IAM は リソース階層 に従って適用されます。上位に付与したロールは下位へ継承されるため、付与レベル（スコープ）の設計が肝心です。

• 組織（Organization） → フォルダ（Folder） → プロジェクト（Project） → 個別リソース（例: バケット、VM など）
• 付与は「必要最小の範囲」で。 上位に強い権限を付けると下位すべてに影響が及びます。

IAM ポリシーとバインディング

IAM ポリシーは複数の バインディング（Binding） から構成されます。
1 つのバインディング = あるロールを、特定のプリンシパルへ、あるリソースに対して付与。条件付き IAM を使えば時間帯やリクエスト属性で制限も可能です。

例 1（プロジェクトにグループへロール付与）

• 対象: プロジェクト my-dev-prj
• プリンシパル: [e-mail]（開発者のグループ）
• ロール: roles/viewer
  → 目的: 誤操作を避けつつ、まずは閲覧から。

例 2（バケットに監査チームの閲覧権限を付与）

• 対象: バケット audit-logs
• プリンシパル: [e-mail]
• ロール: roles/storage.objectViewer
  → 目的: ログの閲覧のみを許可し、削除や上書きを禁止。

例 3（条件付き IAM の一例）

• 対象: プロジェクト backoffice-prj
• プリンシパル: [e-mail]
• ロール: roles/bigquery.jobUser
• 条件: 平日 09:00–18:00 のみ／社内 IP 範囲のみ
  → 目的: 実運用に合わせた「必要なときだけ使える」権限に制限。

IAM の基本構造

実務例（シナリオで理解する）

ケース A: 開発チームの最初の付与設計

• ねらい: まずは「見える化」。いきなり作成権限は渡さない。
• バインディング案: プロジェクトに [e-mail] へ roles/viewer。
• 発展: 実作業が始まったら、開発用プロジェクトに限って roles/editor を期間限定で付与。

ケース B: 監査チームの横断監視

• ねらい: 監査チームが環境の可視化を横断的に行う。
• バインディング案: 対象プロジェクト群に [e-mail] へ roles/viewer。監査対象が Cloud Storage であれば、対象バケットに roles/storage.objectViewer を追加。

ケース C: データ分析のジョブ実行

• ねらい: BigQuery のジョブは実行できるが、テーブルやデータセット定義の変更は不可。
• バインディング案: プロジェクトに roles/bigquery.jobUser、必要に応じてデータセットに roles/bigquery.dataViewer。

ケース D: バックアップ バケットの厳格な閲覧運用

• ねらい: 読み取り専用でアーカイブを守る。
• バインディング案: バケットに [e-mail] へ roles/storage.objectViewer。アップロード担当は別グループを作り roles/storage.objectCreator のみに限定。

失敗事例（やってはいけない）

1. allUsers を付与してしまい、バケットが全公開
   検証のつもりで公開した設定が残り、本番データが外部に見えてしまう。特殊プリンシパルは基本使わない。

2. 上位スコープで強権限を付与
   便宜上フォルダや組織に roles/editor を付けると、配下すべてのプロジェクトに継承され、影響が読めなくなる。

3. 個人に直接ロールを配り続ける
   人の出入りや異動で管理不能に。最初から Google グループ単位で付与する。

4. 同一人物へ重複ロールを多数付与
   実際に有効な権限が読み解けず、棚卸し不能。ロールは「意図」を反映した最小セットに整理。

5. 条件付き IAM の誤用
   条件の意図と実環境がずれてアクセス不能／過剰許可になる。テストとドキュメント化を徹底。

設定の流れ（概要）

ここでは操作手順を細かく書きません（詳細手順は公式ドキュメントに委ねます）。現場で迷わないための 考え方の順序 を示します。

1. 業務と責任の洗い出し（誰が何をしたいのか）
2. スコープの決定（プロジェクト単位か、リソース単位か）
3. ロール選定（事前定義ロールを優先。足りなければカスタム ロール）
4. プリンシパルの単位（個人ではなくグループ／サービス アカウント）
5. 条件の付与（必要なら時間帯やネットワークで絞る）
6. 検証とドキュメント化（想定と実権限を突き合わせ）
7. 棚卸しの仕組み化（定期レビューの計画を作る）

3-2. セキュリティの基本原則：「最小権限の原則」とは？

IAM 設計で最も大切な考え方が 最小権限の原則（Principle of Least Privilege） です。
これは「業務に必要な最小限の権限だけを付与し、それ以上は与えない」というセキュリティの鉄則です。
シンプルですが、実務に落とし込むと奥深いテーマになります。

なぜ最小権限が必要なのか

1. 誤操作のリスクを減らす
   不要な権限を持つユーザーが誤って本番リソースを削除するなど、重大な事故に直結します。

2. アカウント侵害時の被害を最小化する
   もし認証情報が漏洩しても、最小限の権限しかなければ攻撃者の行動範囲を狭められます。

3. 監査・コンプライアンス対応が容易になる
   「誰が」「何をできるのか」が明確になり、監査ログと照合しやすくなります。

ロールごとのリスク比較表

ロール	権限範囲	主な用途	リスクレベル
レガシー基本ロール（プリミティブ ロール）: Owner (roles/owner)	プロジェクト全権限（IAM管理含む）	管理者のみ、極力使用禁止	🔴 非常に高い
レガシー基本ロール（プリミティブ ロール）: Editor (roles/editor)	ほぼすべての操作可能（IAM除く）	開発環境での一時的利用	🟠 高い
Viewer (roles/viewer)	閲覧のみ	監査、運用監視	🟢 低い
事前定義ロール	サービス単位で細分化された権限	API 利用者、個別業務	🟢 低い
カスタムロール	必要な権限を組み合わせて独自作成	特殊な業務要件	🟢〜🟠 状況次第

繰り返しになりますが、「Owner / Editor 等の基本ロール」は、最新の運用では 「レガシー基本ロール（プリミティブ ロール）」 と見なされます。 条件付き IAM（時間帯・IP制限など）には対応せず 、柔軟で安全な制御ができない旧式のため、原則として避け、事前定義ロールやカスタムロールを優先すべき です。

典型的な失敗例

1. 「とりあえず Editor」付与
   開発者全員に Editor を付与し、本番環境まで触れる状態に。誤削除でサービス停止に直結。

2. Owner を安易に利用
   Owner は IAM 設定を含む全権限を持ちます。退職者アカウントに残っていた場合、内部不正や侵入で組織全体が危険に。

3. 棚卸し不足
   一時的な権限付与を削除し忘れ、数年後に不要権限が温存される。内部統制上の重大なリスク。

4. 過剰な Viewer の乱用
   「閲覧だけだから安全」と考えて無制限に付与。結果として情報漏洩につながる。

実務上の工夫

1. 事前定義ロールを優先利用
   例: Cloud Storage 閲覧専用なら roles/storage.objectViewer。安全で粒度も細かい。

2. カスタムロールの活用
   業務に必要な権限を正確に選び、カスタムロールで付与する。

3. 条件付き IAM の利用

   • 特定の IP アドレスからのみ許可
   • 平日 9:00–18:00 のみ許可
   • リソースのラベル条件で許可
     → 「必要なときに必要な範囲だけ」使える IAM を実現。

4. 一時的な権限付与（Just-In-Time Access）
   緊急対応や限定作業時だけ権限を付与し、完了後に速やかに削除する仕組みを導入します。

5. 定期的な棚卸し
   半期や四半期ごとに権限一覧をレビューし、「誰がどのロールを持っているか」をリスト化して不要権限を削除します。

実務シナリオ例

• 開発者のアクセス設計

  • 開発環境：roles/editor を付与
  • 本番環境：roles/viewer のみ付与

• 経理担当のアクセス設計

  • roles/billing.viewer のみ付与し、請求情報を参照可能に。ただしリソース操作は不可。

• 外部委託業者のアクセス設計

  • カスタムロールで業務に必要な最小権限を定義し付与。契約終了後は即時削除。

最小権限の原則

3-3. Google グループを使った効率的な権限管理

IAM の運用が進むと「誰にどの権限を付与したか分からなくなる」という問題に直面します。
個人に直接ロールを付与する方法は小規模なら通用しますが、ユーザー数やプロジェクト数が増えるとすぐに限界を迎えます。
そこで有効なのが Google グループを活用した権限管理 です。

個人付与の課題

1. スケーラビリティの欠如
   50 人のユーザー × 10 プロジェクト = 500 件の設定が必要になり、運用が破綻します。

2. 削除漏れリスク
   退職者や異動者の権限削除が漏れると「幽霊権限」となり、セキュリティホールになります。

3. ポリシーの可読性低下
   IAM ポリシーに個人アカウントが並ぶと「誰がどの役割か」が見えにくく、棚卸しも複雑化します。

Google グループ利用のメリット

• 一括管理可能
  グループ単位で権限を付与でき、ユーザーの追加・削除はグループ側で管理すればよい。

• 人事異動への強さ
  異動や退職時もグループの更新だけで権限が整理できる。

• 可視性の向上
  IAM ポリシーには「grp-dev」「grp-auditors」といったグループ名が表示され、役割が明確になる。

• 誤設定の削減
  個別付与の複雑さが減り、設定ミスや削除忘れを防げる。

グループ設計の代表的パターン

パターン	例	メリット	デメリット
部署別	grp-sales、grp-dev	組織改編に合わせやすい	部署全員に同じ権限は不要な場合も
職務別	grp-network-admins、grp-billing-viewers	最小権限を実現しやすい	グループ数が増えすぎる可能性
横断的	grp-auditors、grp-security-team	複数プロジェクトに跨る役割をまとめやすい	権限が広がりやすい

グループ活用の比較（ユーザーアカウントへの直接権限付与）

グループ活用の比較（グループを介した権限付与）

実務シナリオ例

• 開発チーム

  • グループ: [e-mail]
  • 権限: 開発用プロジェクトに roles/editor
  • 効果: 開発環境では自由に操作、本番環境ではアクセスできないようにする。

• 経理チーム

  • グループ: [e-mail]
  • 権限: roles/billing.viewer
  • 効果: 課金情報のみ閲覧可能、他操作は不可。

• 監査チーム

  • グループ: [e-mail]
  • 権限: 組織全体に roles/viewer
  • 効果: すべてのプロジェクトを横断的に監査できる。

よくある失敗例

1. グループのオーナー不明
   管理者が不在のグループは放置され、メンバー管理ができずリスクが高まります。

2. グループのネスト過多
   グループの中にグループが多層構造となり、最終的に誰に権限があるのかが分かりにくくなります。

3. 命名規則がバラバラ
   意図が見えず、IAM ポリシーを確認しても役割が把握しづらくなります。

ベストプラクティス（まとめ）

• 個人ではなく 必ずグループ単位で権限付与
• 命名規則を統一（例： grp-{role}-{team}）
• グループオーナーを明確に管理。オーナーを複数人設定することで、不在時の運用継続を担保します。
• 定期的なメンバーの棚卸しを計画する（例：半年に一度）。グループメンバーが現在も適切かをレビューし、不必要なメンバーを削除して幽霊権限を防ぎます。
• ネストは最小限にすること。

3-4. サービスアカウントの勘所

サービスアカウントは 「システム専用のユーザー」 です。
アプリケーション、バッチ処理、マイクロサービス、CI/CD パイプラインなどが Google Cloud API を呼び出すときに利用されます。
正しく設計すれば便利で安全ですが、誤れば攻撃者にとって格好の侵入口になります。

ユーザーアカウントとの違い

項目	ユーザーアカウント	サービスアカウント
作成方法	Google Workspace / Cloud Identity で発行	プロジェクト内で作成
利用対象	人間（社員や管理者）	システムやアプリケーション
用途	コンソール操作、CLI 実行	API 呼び出し、自動処理
認証方法	パスワード＋MFA	サービスアカウントキー or 実行環境にアタッチ
管理	人事異動や退職に応じて削除	ライフサイクル管理（作成→利用→監査→廃止）

ユーザーアカウント vs サービスアカウント

設計・運用の基本原則

1. 用途ごとに作成する

   • 例: sa-batch-loader, sa-web-frontend, sa-logging-writer
   • 使い回しは追跡困難になるため厳禁。

2. 最小権限の徹底

   • Cloud Storage から読み取りだけなら roles/storage.objectViewer。
   • 「とりあえず Editor」は絶対に避ける。

3. 利用者を制御する

   • サービスアカウントを「誰が使えるか」も制御。
   • roles/iam.serviceAccountUser を無制限に配布しない。

4. サービスアカウントキーを極力使わない

   • JSON 形式の秘密鍵は漏洩リスクが極めて高い。
     JSON形式の秘密鍵は一度漏洩すると無効化するまで誰でも使用できる「恒久的な認証情報」なので、漏洩時の影響が非常に大きく、利用は極力避けるべきです。

5. 監査と棚卸しを徹底

   • Cloud Audit Logs で利用履歴を確認。
   • 使われていないアカウントやキーは削除・無効化。

ライフサイクル管理

1. 作成: 用途を明確にして作成。命名規則を統一。
2. 権限付与: 最小限のロールを割り当て。
3. 利用: 実行環境にアタッチし、API を安全に利用。
4. 監査: 定期的に Cloud Audit Logs を確認。
5. 廃止: 不要になったら削除または無効化。

実務シナリオ例

• バッチ処理用サービスアカウント

  • 役割: BigQuery データを読み取り、Cloud Storage へ書き込む。
  • 権限: roles/bigquery.dataViewer + roles/storage.objectCreator
  • ポイント: 出力専用権限のみ。削除は不可にしてデータ保全。

• Web アプリ用サービスアカウント

  • 役割: 認証済みユーザーのデータを Firestore から取得。
  • 権限: roles/datastore.user のみ。
  • ポイント: 読み取りと必要な書き込みに限定。

• 監査ログ転送用サービスアカウント

  • 役割: Cloud Logging からログをエクスポートし、外部 SIEM に転送。
  • 権限: roles/logging.configWriter のみ。
  • ポイント: ログ閲覧や削除は不要。転送設定に必要な権限だけ。

典型的な失敗例

1. 複数システムでの使い回し

   • 追跡が困難になり、事故対応が遅れる。

2. 過剰権限の付与

   • VM に Editor ロールをアタッチ → VM 侵入で環境全体が乗っ取られる。

3. サービスアカウントキーの漏洩

   • JSON キーを GitHub に公開 → 攻撃者が不正利用。
   • 数時間で高額請求やデータ流出に発展する危険あり。

命名規則のベストプラクティス

• sa-{system}-{role}
• 例: sa-batch-storage-reader, sa-webapp-logging-writer
• ログで用途が一目で分かり、棚卸しも容易。

Workload Identity Federation

外部システムや他クラウドから Google Cloud API を呼び出す場合、
サービスアカウントキーを配布せずに認証できる仕組みが Workload Identity Federation です。

• 鍵不要で一時トークンを利用
• GitHub Actions、AWS、Azure からの安全なアクセスを実現
• 標準的な OIDC / SAML フェデレーションに対応

3-4.本回のまとめ

今回の記事は、まさに「第2回でつくった“型”（階層・命名・ガードレール）の上に、“誰が”“何を”“どこまで”できるかをどのように重ねるか」によって、Google Cloud のセキュアな土台を一気に仕上げていく構成でした。

• IAM の構造（プリンシパル・リソース・ロール）を明快に整理し、設計の“骨格”を提示

• 最小権限の原則を軸に、安全性と運用のバランスを取る考え方を丁寧に解説

• Google グループやサービスアカウントなど、運用の生やしどころのコツを実務シナリオで落とし込む

IAM は意外に深いテーマで、このように手順と事例を積み重ねれば、むしろ「クラウドセキュリティを制する力」になり得ます。応用機能の解説番外編1もぜひご確認ください。

本回を振り返り、IAMを通じて「誰が」「どのリソースに」「何をできるのか」を緻密に設計し、最小権限の原則を中心に据えることで、クラウド環境の土台を堅牢に築けることが明らかになりました。サービスアカウントや Google グループを活用した具体的実務設計も、実戦の現場で役立つ内容であったかと考えています。

ここまで整えてきたのは、いわば「人と権限」のレイヤー。第4回ではその上に、「ネットワークと通信」のレイヤーを丁寧に重ねていきます。VPC（Virtual Private Cloud）やファイアウォールの基本を取り上げ、クラウド環境の“入り口”をどう守るかを解説していく予定です。
次回もよろしくお願いします！

参照情報

本章の内容は Google Cloud の公式ドキュメントを基に整理しています。さらに学習を深めたい場合は以下をご参照ください。

• IAM の概要
• IAM を安全に使用する - ベストプラクティス
• IAM Conditions 概要 (Google Cloud)
• IAM Conditions 属性リファレンス (Google Cloud)
• Google グループの使用に関するベスト プラクティス
• サービス アカウントのベスト プラクティス