--- title: 第197回 雲勉 Google Cloud IAM 入門 tags: #googlecloudiam #iam #iam入門 #gcp入門 #権限管理 #アクセス制御 #クラウドセキュリティ #クラウドエンジニア author: [雲勉.iret](https://www.docswell.com/user/kumoben_iret) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/VEPKG9NP78.jpg?width=480 description: 【概要】 クラウドを安全に利用する上で避けては通れないアクセス管理の仕組み「IAM（Identity and Access Management）」について、わかりやすく解説します。 ※今回ご紹介した内容は、2026年9月時点での情報です。 本勉強会の動画は下記からご視聴いただけます！ https://youtu.be/oWwCH1OPnEQ published: September 24, 26 canonical: https://www.docswell.com/s/kumoben_iret/ZGNV78-2026-09-24-162306 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/VEPKG9NP78.jpg) 第 197 回 雲勉 Google Cloud IAM 入門 三宅 雄大 KDDIアイレット株式会社 # Page. 2 ![Page Image](https://bcdn.docswell.com/page/27VV6MKV7Q.jpg) Profile み や け ゆ う た 三宅 雄大 KDDIアイレット株式会社 クラウドインテグレーション事業部 ● 所属：第二セクション 第二グループ ● 入社歴：2年目 ● インフラエンジニアとして従事 お写真 # Page. 3 ![Page Image](https://bcdn.docswell.com/page/5JGLNGQ17L.jpg) アジェンダ 01 サービス概要 02 ユースケース 03 料金体系 04 事例 05 まとめ # Page. 4 ![Page Image](https://bcdn.docswell.com/page/47QYQXKNEP.jpg) サービス概要 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/KE4WN6P3J1.jpg) 認証とは システムやサービスにおいて、アクセスしようとしている人や端末が 「正当な本人であるか」を確認・特定する手続き ① ログイン要求 本人確認OKです！ ログイン前ユーザー ② 本人確認の実施 サーバー ③ 認証成功 ログイン後ユーザー 5 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/L71Y5V9ZJG.jpg) 認可とは システムやサービスにおいて、正当な本人に対して 「システム内で何をしてよいか」の権限を割り当て、許可する手続き 動画再生機能： OK ③ 許可 / 拒否 無課金ユーザー ① リクエスト ② 権限の確認 ダウンロード機能： NG 6 # Page. 7 ![Page Image](https://bcdn.docswell.com/page/G7WG5LQ6E2.jpg) Identity and Access Management（IAM）とは IAMとは、システムを利用する「誰が」・「何をしてよいか」を 安全かつ適切に管理する仕組み IAM 認証 (Authentication) 認可 (Authorization) 誰が 何をしてよいか 7 # Page. 8 ![Page Image](https://bcdn.docswell.com/page/4JZLNMWRE3.jpg) Google CloudのIAMとは Google Cloud上のリソースに対するアクセス権を統合的に管理するサービス 「誰が」「何をしてよいか」「どのリソースに対して」を定義し、権限を制御 誰が 操作権限 リソース ユーザー グループ 作成・削除 ストレージ サーバー IAM 8 # Page. 9 ![Page Image](https://bcdn.docswell.com/page/YE6W8NG1EV.jpg) Google Cloud IAMの基本要素 プリンシパル (Principal) ロール (Role) ユーザー、グループ、 サービスアカウントなど 閲覧や編集など、権限のまとまり リソース (Resource) IAMポリシー (Policy) 対象となるGoogle Cloudの サービス 上記3つを紐づけて、 アクセス権を定義する設定 9 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/GE5M95VLE4.jpg) プリンシパルとは 「誰が」を定義したもの 実務でよく使われる主な 3種類を紹介 個人ユーザー用 チーム・組織用 アプリケーション・サーバー用 Google アカウント Google グループ サービスアカウント 個人単位で直接権限を付与する際 に使用 ★権限付与のベストプラクティス メン バーの権限管理が容易 サーバーなどが他のサービスにア クセスする際に使用 10 # Page. 11 ![Page Image](https://bcdn.docswell.com/page/97292N33JR.jpg) ロールとは 「何をしてよいか」を定義したもの 大きく3種類に分かれる 基本ロール 事前定義ロール カスタムロール プロジェクト全体の広範な権限 サービス単位で細かく設定された権 限セット 例：Storage オブジェクト閲覧者 ユーザーが独自の権限を自由に組 み合わせて作成 「閲覧者」「編集者」「オーナー」の3つ 本番環境では非推奨 ★最小権限を実現するための推奨 設定 管理コストが高いため、多用は厳 禁 11 # Page. 12 ![Page Image](https://bcdn.docswell.com/page/DJY4YP187M.jpg) リソースとは 対象となるサービスや実体そのものを指す Compute Engine （サーバー） Cloud Storage （データ保存場所） BigQuery （データ分析基盤） Cloud SQL （データベース） Cloud Run （コンテナ実行環境） Apigee （API管理） 12 # Page. 13 ![Page Image](https://bcdn.docswell.com/page/V7NYP529E8.jpg) IAMポリシーとは 「誰に」「どの権限を渡すか」をまとめたアクセス許可リストのこと 「プリンシパル（誰が）」と「ロール（何を）」の組み合わせを定義したルール IAMポリシー プリンシパル（誰が） ロール（何を） 開発グループ 作成・削除 ※ 1つのポリシーに、複数の『プリンシパル + ロール』を登録できる 13 # Page. 14 ![Page Image](https://bcdn.docswell.com/page/YJ9P3Y1373.jpg) Google Cloud のアーキテクチャ上の特徴 権限は「ユーザー」ではなく、「リソース側」に直接紐づく ★ Google Cloud のアーキテクチャ上の特徴 ● ユーザーにポリシーを付与するのではなく、リソース側で『誰に何を許すか』を管理する 仕組み IAMポリシー プリンシパル（誰が） 開発グループ dev-team@xxx.com ロール（何を） ストレージ管理者 適用 Compute Engine （サーバー） Cloud Storage （データ保存場所） 14 # Page. 15 ![Page Image](https://bcdn.docswell.com/page/GJ8DM64LJD.jpg) 階層構造とポリシーの継承 上の階層（親）で付与した権限は、下の階層（子）に自動的に引き継がれる 階層構造とは Google Cloud のリソースは「組織 ＞ フォルダ ＞ プロジェクト」の階 層で管理される ポリシー付与 組織 フォルダ 監査グループ 閲覧者 ポリシーの継承とは 親階層に設定したポリシーは子階層のすべてのリソースに自動適用 される メリット 共通の権限（例：監査グループの閲覧権限）を一括管理できる プロジェクト Compute Engine Cloud Storage 15 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/LJLM396QER.jpg) 権限がない場合の例 必要なロールが付与されていないと、リソースの閲覧や操作がブロックされる コンソール画面での見え方 「権限がありません」という警告や、操作ボタンの横に「必要な権限」を示すポップアップが表示される 権限範囲外の操作は すべてブロック される。 足りない権限（ロール）が警 告文として表示 される。 16 # Page. 17 ![Page Image](https://bcdn.docswell.com/page/47MYDZGK7W.jpg) IAM運用の注意点・ベストプラクティス ベストプラクティス とは セキュリティリスクを最小限に抑えるための、 Google Cloudの推奨ルール 【大前提】 デフォルトは『すべて拒否』 権限を明示的に付与されない限り、リソースにはアクセスできない Google Cloud プロジェクト Cloud Storage （データ保存場所） ユーザー アクセス 拒否 Compute Engine （サーバー） BigQuery （データ分析基盤） 17 # Page. 18 ![Page Image](https://bcdn.docswell.com/page/P7R946Z6E9.jpg) IAM運用の注意点・ベストプラクティス ▼ 前項の前提を踏まえ、安全に権限を付与するための2つの鉄則 「基本ロール」は基本使わない 「最小権限の原則」を守る 許可範囲が広すぎるため、実務での利用は非推奨 操作対象を限定し、事故を防ぐ ❌ 悪い例（基本ロール） ⭕ 良い例（事前定義） ポリシー(プロジェクトに付与): ユーザーA = 編集者 ポリシー(プロジェクトに付与): ユーザーA = Storage管理者 Google Cloud プロジェクト Google Cloud プロジェクト ⭕ ⭕ Cloud Storage （データ保存場所） Compute Engine （サーバー） �� ⭕ BigQuery （データ分析基盤） ⚠ プロジェクト内の全リソースが操作可能になり危険！ Cloud Storage （データ保存場所） Compute Engine （サーバー） �� BigQuery （データ分析基盤） ✨ Storageのみ操作可能で安全！ 18 # Page. 19 ![Page Image](https://bcdn.docswell.com/page/PJXQ2M9D7X.jpg) ユースケース # Page. 20 ![Page Image](https://bcdn.docswell.com/page/3JK9MGPDJD.jpg) ユースケース①：新メンバーへの権限付与 【要望】 「新人エンジニアAさんに、アプリのエラー調査をお願いしたい」 ● 業務に必要な操作を分解し、最適な「事前定義ロール」を組み合わせて付与する ▼ 要件分解とロール選択のプロセス ● ● 必要な作業①：エラーの記録（ログ）を見たい➡ ログ閲覧者 ロールを選択 必要な作業②：保存された画像ファイルの中身を確認したい➡ Storage オブジェクト閲覧者 ロールを選択 IAMポリシー [新人A + ログ閲覧者] [新人A + Storage オブジェクト閲覧者] Google Cloud プロジェクト 適用 Logging（ ログ） 新人エンジニア A Storage（ストレージ） Compute Engine（サーバー） 20 # Page. 21 ![Page Image](https://bcdn.docswell.com/page/LE3WYNXPE5.jpg) ユースケース②：システムやアプリへの権限付与 【要望】 「サーバー（Compute Engine）上で動くアプリから、ユーザーが投稿した画像を Cloud Storageに自動保存したい」 ▼ 解決策：「サービスアカウント」を使用する ● プログラムやシステムに割り当てるための「非人間用」の専用アカウント ● 開発者個人のアカウントをシステムに埋め込むのは、退職時の権限消失や漏洩リスクがあるためNG ● アプリが動くサーバーにこのアカウントを適用し、必要なロール（例：Storage オブジェクト作成者 ）だけを付与す る サービスアカウント IAMポリシー [サービスアカウント ＋ 「Storage オブジェクト作成者] 適用 写真アップロード 保存可能 適用 サーバー（Compute Engine） ストレージ（Cloud Storage） 21 # Page. 22 ![Page Image](https://bcdn.docswell.com/page/8EDK5W237G.jpg) 料金体系 # Page. 23 ![Page Image](https://bcdn.docswell.com/page/V7PKG91PJ8.jpg) IAMの料金 無料 ⚠ 唯一の注意点（課金の対象） IAM自体は無料ですが、権限を与えられたユーザーが 「作成・利用したリソース（Compute Engineのサーバーや、Cloud Storage等）」 に対しては、料金が発生 23 # Page. 24 ![Page Image](https://bcdn.docswell.com/page/2JVV6MYVJQ.jpg) 事例 # Page. 25 ![Page Image](https://bcdn.docswell.com/page/5EGLNG91JL.jpg) 導入事例： 最新のAI開発における IAMの活用 ▼ 事例：生成 AIを活用したシステム開発（ cloudpack 導入事例 より） 【セキュリティへの配慮】 Cloud Run環境で最新のAIアプリケーションを開発するにあたり、インシ デント発生時の被害を最小限に抑えるセキュアな設計が求められた 【IAMを活用した解決策：最小権限の徹底】 Cloud Run上で動くAIアプリに、専用の「サービスアカウント」を設定 そのアカウントに対し、AIの動作に必要な「最小限の権限」のみを付与 することで、不正なリソース操作のリスクを排除 【導入の効果】 安全かつ堅牢なクラウド環境でAIアプリを稼働させ、業務効率化を実 現！ 25 # Page. 26 ![Page Image](https://bcdn.docswell.com/page/4JQYQXWN7P.jpg) まとめ # Page. 27 ![Page Image](https://bcdn.docswell.com/page/K74WN6K3E1.jpg) まとめ ▼ 本日のまとめ ① IAMの基本の「キ」 IAMとは「誰が」「何ができるか」を、リソースごとに管理する仕組み Google Cloudのセキュリティの根幹となる重要なサービス ② 安全を守る「最小権限の原則」 権限は必要以上に広く与えないこと 役割に応じて必要な「事前定義ロール」を組み合わせて付与する ③ 「ユーザー」と「システム」の使い分け ユーザー ：Googleアカウントに権限を付与する システム ：必ず「サービスアカウント」を利用する 27 # Page. 28 ![Page Image](https://bcdn.docswell.com/page/LJ1Y5VXZEG.jpg) ご清聴ありがとうございました