- IAMはGoogle Cloudのアクセス制御の中核であり、すべてのGCPサービスに横断的に適用される
- 最小権限の原則・サービスアカウント設計・条件付きバインディングなど、本番運用に必須のセキュリティ知識を網羅
- 組織ポリシーやVPC Service Controls、Security Command Centerとの連携まで、SES案件で即活用できるレベルで解説
- Google Cloud 完全攻略 Ep.1: GCPの基礎知識とプロジェクト作成
- Google Cloud 完全攻略 Ep.2: Cloud RunとCloud SQLで実現するスケーラブルなコンテナ運用
- Google Cloud 完全攻略 Ep.3: BigQueryではじめるデータ分析入門
- Google Cloud 完全攻略 Ep.4: Cloud Functionsで学ぶサーバーレスアーキテクチャ入門
- Google Cloud 完全攻略 Ep.5: Cloud Storageで学ぶオブジェクトストレージ運用入門
- Google Cloud 完全攻略 Ep.6: IAMとセキュリティ設計で学ぶクラウド権限管理（本記事）
SES案件でクラウドインフラに携わるとき、最初にぶつかるのが**「権限まわり」**の壁です。「デプロイしようとしたら権限エラーで止まった」「サービスアカウントの鍵が漏洩してインシデントになった」——こうしたトラブルは、IAMの仕組みを正しく理解していれば未然に防げます。
Google CloudのIAM（Identity and Access Management）は、**「誰が」「何に対して」「何をできるか」**を一元管理するセキュリティの基盤です。AWS IAMやAzure RBACに相当しますが、Google Cloud独自のリソース階層モデルと組み合わさることで、より柔軟かつ強力なアクセス制御を実現しています。
本記事では、IAMの基本概念から、サービスアカウントの設計パターン、組織ポリシー、そしてSES現場で求められるセキュリティベストプラクティスまで、体系的に解説します。
IAMの基本概念——3つの要素を理解する
Google Cloud IAMは、プリンシパル（誰が）、ロール（何ができるか）、**リソース（何に対して）**の3要素で構成されます。
プリンシパル（Principal）
アクセス主体を表します。以下の種類があります。
- Googleアカウント: 個人ユーザー（
user:[email protected]） - サービスアカウント: アプリケーションやVMが使うアカウント（
serviceAccount:[email protected]） - Googleグループ: 複数ユーザーをまとめたグループ（
group:[email protected]） - Google Workspace / Cloud Identityドメイン: 組織全体（
domain:example.com）
ロール（Role）
権限（パーミッション）の集合です。3種類に分類されます。
| ロール種別 | 説明 | 例 |
|---|---|---|
| 基本ロール | Owner / Editor / Viewer。権限が広すぎるため本番非推奨 | roles/owner |
| 事前定義ロール | サービスごとに細分化された推奨ロール | roles/storage.objectViewer |
| カスタムロール | 必要な権限だけを組み合わせた独自ロール | roles/myCustomRole |
リソース階層とポリシー継承
Google Cloudのリソースは階層構造になっており、上位で設定したIAMポリシーは下位に継承されます。
組織（Organization）
└── フォルダ（Folder）
└── プロジェクト（Project）
└── リソース（VM, バケット, データセット等）Ep.1のGCP基礎で作成したプロジェクトは、この階層の中に位置しています。組織レベルで設定したポリシーは全プロジェクトに適用されるため、ガバナンスの起点として極めて重要です。
最小権限の原則——IAM設計の基本
**最小権限の原則（Principle of Least Privilege）**は、IAM設計の最も重要な指針です。「必要な権限だけを、必要な範囲で、必要な期間だけ付与する」というシンプルなルールですが、実践するには体系的なアプローチが必要です。
基本ロール vs 事前定義ロール
# ❌ BAD: 基本ロール（Editor）の付与 — 権限が広すぎる
gcloud projects add-iam-policy-binding my-project \
--member="user:[email protected]" \
--role="roles/editor"
# ✅ GOOD: 事前定義ロールで必要最小限に
gcloud projects add-iam-policy-binding my-project \
--member="user:[email protected]" \
--role="roles/run.developer"基本ロールのEditorは数千のパーミッションを含みます。対してCloud RunのDeveloperロールは、Cloud Runの操作に必要な権限だけに絞られています。SES案件で初めてのGCP環境に入った際、既存メンバーにEditorやOwnerが大量に付与されているのは典型的なアンチパターンです。
条件付きIAMバインディング
特定の条件下でのみ権限を有効にするIAM Conditionsは、最小権限を実現する強力な機能です。
# 営業時間内のみアクセスを許可
gcloud projects add-iam-policy-binding my-project \
--member="user:[email protected]" \
--role="roles/bigquery.dataViewer" \
--condition='expression=request.time.getHours("Asia/Tokyo") >= 9 && request.time.getHours("Asia/Tokyo") < 18,title=business-hours-only'
# 特定のリソース名パターンに限定
gcloud projects add-iam-policy-binding my-project \
--member="serviceAccount:[email protected]" \
--role="roles/storage.objectViewer" \
--condition='expression=resource.name.startsWith("projects/_/buckets/data-lake-prod"),title=data-lake-only'IAM Conditionsは、BigQuery（Ep.3）のデータアクセス制御や、Cloud Storage（Ep.5）のバケットアクセスを細かく制限する場面で特に有効です。
IAM Recommender——Googleの推奨に従う
Google Cloudには、実際のアクセスパターンを分析して不要な権限の削減を提案するIAM Recommenderがあります。
# IAMの推奨事項を確認
gcloud recommender recommendations list \
--project=my-project \
--recommender=google.iam.policy.Recommender \
--location=global
# 推奨事項の詳細を確認
gcloud recommender recommendations describe RECOMMENDATION_ID \
--project=my-project \
--recommender=google.iam.policy.Recommender \
--location=global「90日間使用されていない権限」を検出してくれるため、定期的に確認する運用を推奨します。
サービスアカウント設計——アプリケーション認証のベストプラクティス
サービスアカウントは、人間ではなくアプリケーションやワークロードがGCPリソースにアクセスする際のIDです。SES案件では、Cloud Runのデプロイ、CI/CDパイプライン、バッチ処理など、あらゆる場面で使用します。
サービスアカウントの作成と権限付与
# サービスアカウントの作成
gcloud iam service-accounts create cloud-run-app \
--display-name="Cloud Run Application" \
--description="Cloud Runで稼働するWebアプリ用"
# 必要なロールを付与
gcloud projects add-iam-policy-binding my-project \
--member="serviceAccount:[email protected]" \
--role="roles/cloudsql.client"
gcloud projects add-iam-policy-binding my-project \
--member="serviceAccount:[email protected]" \
--role="roles/storage.objectViewer"設計パターン：1ワークロード＝1サービスアカウント
❌ BAD: 全アプリで共有
my-app-sa → Cloud Run + Cloud Functions + バッチ処理
✅ GOOD: ワークロードごとに分離
cloud-run-web@... → Cloud Run Webアプリ
cloud-func-etl@... → Cloud Functions ETLジョブ
batch-processor@... → バッチ処理ワークロードごとにサービスアカウントを分けることで、あるサービスが侵害されても被害を局所化できます。Cloud Run（Ep.2）とCloud Functions（Ep.4）では、それぞれ専用のサービスアカウントを割り当てましょう。
サービスアカウントキーの管理——鍵を作らない設計
サービスアカウントキー（JSONキーファイル）はセキュリティリスクの最大の原因です。鍵が漏洩すれば、その権限をすべて悪用されます。
# ❌ 避けるべき: キーファイルの生成
gcloud iam service-accounts keys create key.json \
[email protected]
# ✅ 推奨: Workload Identity（GKE / Cloud Run）
# Cloud Runはデフォルトでサービスアカウントを利用可能
gcloud run deploy my-app \
--service-account=cloud-run-app@my-project.iam.gserviceaccount.com
# ✅ 推奨: Workload Identity Federation（外部IdP連携）
# GitHub ActionsからGCPにキーレスでアクセス
gcloud iam workload-identity-pools create github-pool \
--location="global" \
--display-name="GitHub Actions Pool"Workload Identity Federationを使えば、GitHub Actions、AWS、Azure ADなど外部の認証基盤から鍵なしでGCPリソースにアクセスできます。CI/CDパイプラインでは必ずこの方式を採用しましょう。
サービスアカウントの権限借用（Impersonation）
管理者が一時的にサービスアカウントの権限を使う場合、鍵を作るのではなく**権限借用（Impersonation）**を使います。
# サービスアカウントの権限を借用してコマンド実行
gcloud storage ls gs://restricted-bucket/ \
--impersonate-service-account=data-reader@my-project.iam.gserviceaccount.comこの方法なら、操作は監査ログに「誰が借用したか」まで記録されるため、トレーサビリティが確保されます。
組織ポリシー——ガバナンスの仕組み化
個々のプロジェクトでのIAM設定だけでは、大規模な組織ではガバナンスが追いつきません。**組織ポリシー（Organization Policies）**を使えば、組織全体にセキュリティルールを強制できます。
よく使う組織ポリシー
# サービスアカウントキーの作成を禁止
gcloud resource-manager org-policies enable-enforce \
constraints/iam.disableServiceAccountKeyCreation \
--organization=ORGANIZATION_ID
# 外部ユーザーへのIAM付与を禁止
gcloud resource-manager org-policies enable-enforce \
constraints/iam.allowedPolicyMemberDomains \
--organization=ORGANIZATION_ID
# 公開アクセスの防止（Cloud Storage）
gcloud resource-manager org-policies enable-enforce \
constraints/storage.publicAccessPrevention \
--organization=ORGANIZATION_ID
# 許可するリージョンを制限
gcloud resource-manager org-policies set-policy policy.yaml \
--organization=ORGANIZATION_ID| ポリシー | 効果 | 推奨度 |
|---|---|---|
iam.disableServiceAccountKeyCreation | SA鍵の作成を禁止 | ★★★ |
iam.allowedPolicyMemberDomains | 外部ドメインへの権限付与を制限 | ★★★ |
storage.publicAccessPrevention | バケット公開を組織全体で禁止 | ★★★ |
compute.vmExternalIpAccess | VMの外部IPを制限 | ★★☆ |
gcp.resourceLocations | リソースのリージョンを制限 | ★★☆ |
VPC Service Controls——データ漏洩の防止
VPC Service Controlsは、GCPサービスへのアクセスを**セキュリティ境界（ペリメーター）**で囲い、データの流出を防ぐ機能です。
# アクセスポリシーの作成
gcloud access-context-manager policies create \
--organization=ORGANIZATION_ID \
--title="My Access Policy"
# サービスペリメーターの作成
gcloud access-context-manager perimeters create my-perimeter \
--policy=POLICY_ID \
--title="Production Perimeter" \
--resources="projects/123456789" \
--restricted-services="bigquery.googleapis.com,storage.googleapis.com" \
--access-levels="accessPolicies/POLICY_ID/accessLevels/corp-network"ペリメーター内のBigQueryデータセットやCloud Storageバケットには、許可されたネットワーク・IDからしかアクセスできなくなります。金融・医療系のSES案件では、VPC Service Controlsの設計・運用経験は高く評価されるスキルです。
監査ログ（Cloud Audit Logs）——誰が何をしたかを追跡する
セキュリティインシデントの調査や、コンプライアンス要件の充足には監査ログが不可欠です。
監査ログの種類
| ログ種別 | 内容 | デフォルト |
|---|---|---|
| 管理アクティビティ | リソースの作成・変更・削除 | 常時有効（無料） |
| データアクセス | データの読み取り・書き込み | 手動で有効化（有料） |
| システムイベント | Googleによる自動メンテナンス | 常時有効（無料） |
| ポリシー拒否 | アクセス拒否イベント | 常時有効（無料） |
# データアクセスログの有効化
gcloud projects get-iam-policy my-project --format=json > policy.json
# policy.json に auditConfigs を追加して適用
gcloud projects set-iam-policy my-project policy.jsonCloud Loggingでの監査ログ検索
# 過去24時間のIAM変更を検索
gcloud logging read 'logName="projects/my-project/logs/cloudaudit.googleapis.com%2Factivity" AND protoPayload.methodName="SetIamPolicy"' \
--freshness=1d \
--format=json
# サービスアカウントキーの作成ログを検索
gcloud logging read 'protoPayload.methodName="google.iam.admin.v1.CreateServiceAccountKey"' \
--freshness=7d監査ログをBigQueryにエクスポートして定期的に分析するパターンは、Ep.3のBigQueryで学んだスキルが直接活きる場面です。
Security Command Center——セキュリティの統合ダッシュボード
**Security Command Center（SCC）**は、GCPのセキュリティ状態を一元的に可視化するサービスです。
主要機能
- Security Health Analytics: IAMの設定不備、公開バケット、ファイアウォールの脆弱性を自動検出
- Event Threat Detection: 不審なアクティビティ（暗号通貨マイニング、データ流出等）をリアルタイム検知
- Web Security Scanner: Webアプリケーションの脆弱性を自動スキャン
# SCCの検出結果を一覧表示
gcloud scc findings list ORGANIZATION_ID \
--source="-" \
--filter="state=\"ACTIVE\" AND severity=\"HIGH\""
# 特定の検出結果をミュート（対応済み）
gcloud scc findings update-marks FINDING_ID \
--organization=ORGANIZATION_ID \
--source=SOURCE_ID \
--security-marks="reviewed=true"SES案件でセキュリティ監査やコンプライアンス対応を求められた場合、SCCの活用経験は大きなアドバンテージになります。
SES案件で使えるIAM設計テンプレート
環境別アクセス制御
本番（prod）
├── roles/viewer → 開発チーム全員（読み取りのみ）
├── roles/run.developer → デプロイ担当（Cloud Runの操作）
├── roles/cloudsql.admin → DBA（Cloud SQLの管理）
└── roles/owner → インフラリーダーのみ
ステージング（stg）
├── roles/editor → 開発チーム全員
└── roles/owner → テックリード
開発（dev）
├── roles/editor → 開発チーム全員
└── 自由にリソース作成可能CI/CDパイプラインのIAM設計
# GitHub Actions用のWorkload Identity Federation
# 1. プールの作成
gcloud iam workload-identity-pools create github-pool \
--location="global"
# 2. プロバイダーの追加
gcloud iam workload-identity-pools providers create-oidc github-provider \
--location="global" \
--workload-identity-pool="github-pool" \
--issuer-uri="https://token.actions.githubusercontent.com" \
--attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository"
# 3. サービスアカウントへのバインディング
gcloud iam service-accounts add-iam-policy-binding [email protected] \
--role="roles/iam.workloadIdentityUser" \
--member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/github-pool/attribute.repository/my-org/my-repo"IAMのトラブルシューティング
よくある権限エラーと対処法
# Policy Troubleshooterで権限不足の原因を調査
gcloud policy-troubleshoot iam \
--resource="//cloudresourcemanager.googleapis.com/projects/my-project" \
--principal-email="[email protected]" \
--permission="run.services.create"| エラーメッセージ | 原因 | 対処 |
|---|---|---|
PERMISSION_DENIED | ロール不足 | Policy Troubleshooterで不足権限を特定 |
403 Forbidden | 組織ポリシー違反 | 組織管理者に確認 |
The caller does not have permission | サービスアカウント権限不足 | IAMバインディングを確認 |
まとめ——セキュリティはアーキテクチャの一部
IAMとセキュリティは、クラウドアーキテクチャの「後付け」ではなく、設計段階から組み込むべき基盤です。本記事で解説した内容を振り返ります。
- 最小権限の原則を徹底し、基本ロール（Owner/Editor）の使用を排除
- サービスアカウントはワークロードごとに分離し、鍵は作らない
- Workload Identity FederationでCI/CDからのキーレス認証を実現
- 組織ポリシーでガバナンスを仕組み化し、人的ミスを防止
- VPC Service Controlsでデータ漏洩のリスクを構造的に排除
- 監査ログとSecurity Command Centerで継続的な監視体制を構築
まずはGCPの基礎（Ep.1）でプロジェクトを作成し、本記事のコマンドを実際に試してみましょう。Cloud Run（Ep.2）やCloud Functions（Ep.4）のデプロイでは、ここで学んだサービスアカウント設計を適用できます。また、Cloud Storage（Ep.5）の署名付きURLやバケットポリシーも、IAMの理解があってこそ正しく設計できます。
セキュリティ設計の経験は、SESエンジニアとしての市場価値を大きく高めます。特にIAM・監査ログ・VPC Service Controlsの知識は、金融・医療・官公庁案件で必須のスキルです。
次回のGoogle Cloud 完全攻略もお楽しみに！
出典・参考資料
- IAM の概要 — Google Cloud
- IAM ロールについて — Google Cloud
- サービスアカウントのベストプラクティス — Google Cloud
- Workload Identity Federation — Google Cloud
- 組織ポリシーの制約 — Google Cloud
- VPC Service Controls — Google Cloud
- Security Command Center — Google Cloud
関連記事
