番外編1 応用と最新機能で広がる IAM のセキュアな運用
第 1 章 はじめに
お疲れ様です。SKYこと関谷です。
本記事は「第3回（IAM基本）」では網羅していない、セキュリティを語る上で押さえておきたい 新しい IAM（Identity and Access Management）機能を番外編として紹介します。
IAM は、Google Cloud におけるセキュリティの根幹とも言える重要な機能ですが、基礎の部分だけではなく、さらに効率的かつ安全に運用するにはどうすれば良いか──。本編では、IAM の応用編として、より実践的かつ最新のセキュア運用機能・手法を、わかりやすく丁寧にご紹介します。
以下のような読者を想定しています：
- サービスアカウントのキー管理がちょっと怖い。代わりに安全な認証方法を知りたい。
- IAM 権限の誤付与や削除ミスが心配…しっかりガードレールを設定したい。
- もっと柔軟に、属性やタイミングでアクセスを制御したい。
- 権限を与えっぱなしにしてしまうのが不安…継続的に見直す仕組みを知りたい。
- 基本（第３回 IAM 編参照）だけではない応用機能を把握しておきたい。
このようなお悩みやニーズに寄り添いつつ、以下の応用機能を順に掘り下げていきます：
- サービスアカウントのセキュアな運用強化（Impersonation、Workload Identity Federation）
- IAM Deny ポリシーによる確実なガードレールの構築
- IAM Conditions による柔軟な属性ベース制御（ABAC）
- Policy Intelligence を活用した継続的ガバナンスの強化
- Privileged Access Manager（PAM）による Just-in-Time 制御の実現
原則、Google Cloud の公式ドキュメントやブログ記事に基づいて記載しています。
2025年8月までの情報で記載していますが、最近の情報が漏れている場合も考えられますので、その場合はご指摘頂けると幸いです。
それでは、一緒に IAM 運用の“応用ステージ”へ足を踏み出してまいりましょう。次の章ではまず、サービスアカウント周りのセキュアな運用方法からご案内いたします。
ブログシリーズその他の執筆
本編
第 2 章 サービスアカウントのセキュアな運用強化
本章では、Google Cloud におけるサービスアカウントの運用を、より安全かつ効率的に行うための実践的なポイントをご紹介いたします。キー管理に不安を感じられる方も、多くいらっしゃるかと思いますが、ご安心ください。Google Cloud 公式ドキュメントに基づき、しっかりと丁寧に解説してまいります。
2-1. サービスアカウントを取り巻くリスクと対策の基本
サービスアカウントはとても便利な存在ですが、その強力な権限ゆえに不適切に扱うと、権限のエスカレーションやなりすましといったリスクを招きかねません。Google は、サービスアカウントを「非人間の主体（non-human users）」と位置づけ、リソースとしても扱い、同等の管理を行うことを推奨しています。
実践すべきポイント：
- デフォルトで自動生成されるサービスアカウントは避け、用途ごとに明確な命名規則と説明付きで専用アカウントを作成する。
- 利用目的や担当チームがひと目でわかるように命名し、ドキュメント（コメントや README）にも説明を書き残す。
- 不要になったサービスアカウントは速やかに無効化し、しばらくしてから削除することで、不要な権限を抱えたままにしません。
2-2. Impersonation（権限借用）によるキー管理の回避を目指す
サービスアカウントキーの管理は非常にリスキーです。そこで、Service Account Impersonation（権限借用） を活用することを強くおすすめします。これは、既に認証済みの主体が、一時的にサービスアカウントの権限で処理を実行できる仕組みで、キーを使わず安全にアクセスできる点が最大のメリットです。
活用方法の一例：
-
gcloudコマンドで--impersonate-service-accountオプションを使い、短期間の資格情報で操作を実行。 - または、
gcloud config set auth/impersonate_service_account SERVICE_ACCT_EMAILにより、gcloud CLI 全体のデフォルトとして権限借用を設定可能。 - この方法なら、Cloud Audit Logs にて「誰が誰として動いたか」が記録され、**監査性（non-repudiation）**も確保できます。
2-3. Workload Identity Federation によるキーに頼らない認証構成
サービスアカウントキーに代わる手段として、Workload Identity Federation の利用が急速に注目されています。なぜなら、キーの配布や管理が不要になり、運用の安全性が大幅に向上するからです。
主なメリットと特徴：
- AWS、Azure、GitHub、Okta などの外部 ID プロバイダー（IdP）と連携できる。
- トークン交換により短く有効な認証情報を使って安全にアクセス可能。
-
attribute mappingやattribute conditionsを使えば、認証元の属性に基づくさらなる制御も可能。 - たとえば AWS や Azure 環境においても、Workload Identity Federation を通じて安全に Google Cloud にアクセスできるようになります。
Impersonation vs Workload Identity Federation
2-4. 章のまとめ
サービスアカウントのセキュアな運用は、IAM をより実践的かつ安全に活用するための第一歩です。
| 観点 | 実践ポイント |
|---|---|
| 管理方針 | デフォルトアカウントを避け、用途特化のサービスアカウントを命名＋管理する |
| アクセス方法 | サービスアカウントキーは極力使わない。Impersonation や Federation を活用する |
| 監査性 | Cloud Audit Logs により「誰が」の操作かを記録し、非否認性を担保する |
第 3 章 IAM Deny ポリシーによるガードレール構築
本章では、明示的な「拒否（Deny）」ルールを使った、より強固なアクセス制御手法である IAM Deny ポリシー について丁寧に解説いたします。公式ドキュメントに基づく内容で、具体例を交えながら進めますので、ご安心ください。
3-1. IAM Deny ポリシーとは？
IAM Deny ポリシーは、リソースへのアクセスを明示的に拒否する仕組みです。Allow ポリシー（権限付与）よりも優先的に評価されるため、たとえ IAM ロールで権限が与えられていたとしても、Deny ポリシーによって操作を止めることが可能です。
- 複数の Deny ポリシーを組織、フォルダ、プロジェクト単位で設定でき、最大 500 ポリシーまで添付可能。
- 条件付きの拒否ルールを設定することも可能で、リソースのタグなどに基づいた制御ができます。
IAM Deny ポリシー
3-2. ユースケースと効果的な設定例
IAM Deny ポリシーには、以下のようなユースケースがあります：
-
プロジェクト削除の制限：
project-adminsグループ以外にはプロジェクト削除を拒否し、かつテストタグの付いたプロジェクトには制限を緩和する例。 - キーの作成制限：特定のプロジェクトでサービスアカウントキーの作成／削除を禁止し、例外的に特定グループにだけ許可する構成。
以下は、タグ付きプロジェクトで操作を制限する構成例です：
{
"rules": [
{
"denyRule": {
"deniedPrincipals": ["principalSet://goog/public:all"],
"exceptionPrincipals": ["principalSet://goog/group/project-admins@example.com"],
"deniedPermissions": ["cloudresourcemanager.googleapis.com/projects.delete"],
"denialCondition": {
"title": "Only deny non-test projects",
"expression": "resource.matchTag('12345678/env', 'prod')"
}
}
}
]
}
3-3. Deny ポリシーの階層と適用範囲
Deny ポリシーは組織、フォルダ、プロジェクトのいずれかにアタッチできます。親階層に適用されたポリシーは下位にも継承されるため、組織レベルでのセキュリティ基盤を網羅的に構築可能です。
3-4. 章のまとめ
IAM Deny ポリシーを活用することで、予期せぬ権限の流出や誤操作を防ぎ、組織全体のセキュリティポリシーに整合したアクセス制御を実現できます。
第 4 章 IAM Conditions による柔軟な属性ベース制御（ABAC）
本章では、Google Cloud IAM において、属性や条件に基づいたアクセス制御を可能にする IAM Conditions を解説します。
従来の IAM では「誰が」「どのリソースに」「何をするか」を決めることはできても、「いつ」「どこから」「どんな属性で」という細かな制御は難しいものでした。
IAM Conditions を使うことで、アクセス制御をよりセキュアかつ運用しやすい形へ発展させることができます。
4-1. IAM Conditions の基本概要
IAM Conditions では、ロール付与に「条件」を加えることができます。
たとえば次のようなユースケースを実現できます。
- 社内ネットワークからのアクセスのみ許可する
- 平日 9:00〜18:00 の勤務時間中のみアクセス可能にする
- 特定のタグが付与されたリソースにだけアクセスできるようにする
これにより、従来のシンプルな「権限を付与したら常に有効」という状態を避け、より状況に応じた制御が可能になります。
これは ゼロトラストモデル に近づけるための重要なステップでもあります。
4-2. 条件式（CEL：Common Expression Language）の書き方・構造
IAM Conditions の条件は CEL (Common Expression Language) で記述します。基本構造は以下のとおりです。
"condition": {
"title": "説明的なタイトル",
"description": "任意の説明（オプション）",
"expression": "CEL 式"
}
利用可能な属性は大きく分けて2つです。
-
リクエスト属性：
request.time（アクセス時刻）、request.auth.claims（ID トークンのクレーム情報） など -
リソース属性：
resource.service（対象サービス）、resource.type（リソースの種類）、resource.name（リソース名） など
論理演算子（&& / || / !）を組み合わせることで複雑な条件式も作成できます。
IAM Conditions (ABAC)
4-3. 実用例：時間制限付きアクセス制御
以下は、あるユーザーに対して 特定の時間帯だけ権限を有効にする 設定例です。
{
"members": ["user:example@example.com"],
"role": "roles/compute.networkAdmin",
"condition": {
"title": "5minuteAccess",
"description": "Only during this time window",
"expression": "request.time >= timestamp('2024-03-12T09:15:00Z') && request.time < timestamp('2024-03-12T09:20:00Z')"
}
}
4-4. 追加の実用シナリオ・属性例
IAM Conditions を使えば、多彩なシナリオを実現できます。
-
リソースサービスによる制御
例：resource.service == "compute.googleapis.com"
→ Compute Engine のリソースに限定して権限を有効にする。 -
リソースタイプによる制御
例：resource.type == "storage.googleapis.com/Bucket"
→ Cloud Storage バケットにのみ権限を許可。 -
ネットワークや地理情報を条件に追加
-
ip_in_range(request.ip, '192.168.1.0/24')→ 社内ネットワークからのアクセスに限定。 -
request.location.country_code == 'US'→ 米国内からのアクセスのみ許可。
-
4-5. 章のまとめ
IAM Conditions によって、「誰に」「どの権限を」与えるだけでなく、「どんな状況のときに」権限を発揮させるかを定義できるようになりました。
これにより、セキュリティを高めつつ、運用上の柔軟性も確保できます。
第 5 章 Policy Intelligence による継続的ガバナンス強化
これまでに IAM Deny や IAM Conditions など“静的に定めるセキュリティ”に取り組んできましたが、IAM 運用は設計のまま終わらず、運用しながら改善し続けることが重要です。
そのため、 Google Cloud では、Policy Intelligence という IAM 運用を継続的に安全性を保ちながら改善するためのツール群が用意されています。
Policy Intelligence は、以下の機能から構成されます：
- Recommender（過剰な権限を洗い出して最小限の権限に見直し）
- Policy Troubleshooter（なぜアクセスできないのか／できてしまったのかを可視化）
- Policy Analyzer（誰が何にアクセスできるかを横断的に把握）
- Policy Simulator（設定変更の影響を本番前に試す）
公式でも「セキュリティ強化と運用負荷のバランスを取る」と言及されています。
5‑1. Policy Intelligence とは？—最初に知るべき全体像
Policy Intelligence は、IAM の定期運用に必要な 可視化・自動分析ツール群であり、リスクの可視化・削減・変更影響の事前評価を支援します。
IAM の “設定して終わり”から “使われた状況に応じて見直す仕組み”に進化するための土台です。まず「問題が発生したら Troubleshooter」、「定期的な見直しに Recommender」、変更前には Simulator を使う習慣をつけると、自信のない状態でも安心して運用できます。
5-2. IAM Recommender — 「使われていない権限」をお知らせ
過去 90 日間の利用履歴から「一度も使われなかった権限」や「より小さいロールの方が適切」といった削減プランを提案します。
- 容易な状態確認：IAM コンソールの「おすすめハブ」に表示され、クリック一つで内容確認が可能です。
-
“90 日は長く感じる”と思う方へ：
gcloudコマンドで 30 日や 60 日に短く設定することもできますが、精度が落ちる点に注意。 - 大きな組織で使う場合は BigQuery に出力し分析：権限の増減や担当変更を定量的に追え、安心です。
表：Recommender を使う前後のチェック
観点 適用前チェック 適用後チェック 対象範囲 影響が小さいプロジェクトから 影響が出ていないかエラーログ確認 例外 期末・繁忙期の担当者を除外 除外が続く場合は要ルール化 証跡 変更前後のロール差分を保存 タグ・チケット番号を残す
5-3. Policy Troubleshooter — アクセスの「なぜ？」を解く
あるユーザーがアクセスできない・できてしまった原因を、使われているポリシーの評価に基づいてわかりやすく表示します。
- 「このアカウントがこのアクセスで何が不足か？」を即可視化：権限だけでなく、条件付き設定や境界設定が原因のこともあるので、それも可視化してくれるのが便利です。
- 「設定どれが邪魔している？」を高速特定：アクセス不可な状況はログ探しが大変ですが、このツールなら背景のポリシーを全て解析してくれます。
Policy Troubleshooter
5-4. Policy Analyzer — 「誰が・何に・何ができるか」棚卸しに便利
組織階層内で、Principal／ロール／リソースの組み合わせで検索し、権限構成をリストとして可視化します。
- 監査や棚卸しに強力：例えば「このストレージに書き込めるのは誰か」「VM を停止できるロールは誰か」を一発一覧で確認できます。
- “条件付き”も評価対象：TRUE か CONDITIONAL かで結果を絞り込めるので、より詳細なポリシー設計にも対応できます。
Policy Analyzer
5-5. Policy Simulator — 事前に変更影響を試す
変更前に「適用したらどうなるか」をシミュレーションできます。特に条件付きポリシーは部分的に適用されないなどの注意点も補足されています。
- Simulator を使って確認：Recommender 結果だけで即変更せず、「まずシミュレーション → 問題なければ適用」が安心です。
- Validatorsとして働く道具：Simulator を使ったログを残す仕組みをワークフローに入れると、有事の原因追跡にも役立ちます。
5‑6. 改善サイクル：運用を“磨き続ける”流れ
運用プロセス例
- 問題発生：「このアカウントがアクセスできない！」 → Troubleshooter で原因追及
- 定期レビュー：「誰がどんな権限を持っている？」 → Analyzer で一覧化
- 過剰権限対策：Recommender を確認 → 段階的に絞る
- 変更前検証：Simulator で影響をシミュレーション → 問題なければ適用
改善サイクル
5‑7. 章のまとめ
- **IAM 運用は“設定して終わり”ではなく、**Policy Intelligence を使って「継続的に見直し・改善」することが重要です。
- 特に Recommender と Troubleshooter は毎日の運用に組み込むと効果抜群。
- Analyzer と Simulator は定期メンテや変更前の安全確認として役立ちます。
第 6 章 Privileged Access Manager による Just-in-Time アクセス制御
IAM の運用では「最小権限の原則」が重要です。しかし、実際の運用ではこうした悩みがつきものです。
- 緊急時に権限がなくて作業が止まった
- 権限を広めに与えっぱなしになっている
- 監査で「誰がいつ使ったのか」が説明できない
これを解決するのが Privileged Access Manager（PAM） です。
PAM は「必要な人に、必要なときにだけ、必要な権限を付与する」仕組みで、セキュリティと利便性を両立できます。
6-1. PAMの仕組みと構成要素
Entitlement（利用資格）
利用資格とは「一時的な権限の設計図」です。
- 誰がリクエストできるか
- どのロールを付与するか
- 最大どれくらいの時間か
- 承認が必要かどうか
- 理由入力を必須にするか
- 誰に通知を飛ばすか
利用例
- 「オンコール担当者が本番環境に 2 時間だけ入れる」Entitlement
- 「DB 管理者が月例メンテ時にだけ roles/cloudsql.admin を取得できる」Entitlement
Grant（一時的付与）
Grant とは、Entitlement をもとに実際に発行される一時的な権限です。
- ユーザーが申請（理由入力を含む）
- 必要なら承認を経て付与
- 時間経過で自動剥奪
利用例
- サポート担当者が「顧客からの調査依頼」を理由に一時的に読み取り権限を申請
- 承認後、2 時間だけアクセス可能 → 終了後に自動で剥奪
Privileged Access Manager (PAM)
6-2. PAM導入の運用メリット
1) 最小権限の徹底とリスク低減
常設の過剰権限をなくし、リスクを最小化します。
利用例
- 以前は「全員に Owner 権限を常設」していた組織が、PAM によって「緊急時のみ一時的に付与」に変更 → アカウント乗っ取り時の被害範囲が大幅に縮小。
2) セキュリティと利便性の両立
申請者はセルフサービスでリクエスト可能。承認不要なら即時付与、承認ありでもスムーズです。
利用例
- 開発者が深夜に発生した障害対応で、承認不要の「ReadOnly 本番アクセス」を即時取得し、翌朝までに復旧完了。
3) 緊急対応力の向上
緊急対応用の Entitlement を作っておけば、即時対応が可能です。
利用例
- オンコール担当者が「Compute Admin（1 時間）」を自己申請し、停止した VM をすぐ再起動。
4) ガバナンスと監査性の強化
「誰が・なぜ・どの権限を使ったか」が Cloud Audit Logs に残り、監査が容易になります。
利用例
- 監査チームが「先月の本番アクセス利用履歴」を確認し、理由入力付きで全件レビュー。
6-3. 想定ユースケース
-
緊急対応（ブレークグラスアクセス）
例：障害発生時に「緊急 Admin 権限」を 1 時間だけ取得。
→ 自動剥奪されるため、復旧後に高権限が残らない。 -
本番環境への一時アクセス
例：開発者が本番 DB へ障害調査のため 2 時間だけ入る。
→ 承認者（プロジェクト管理者）の承認を経て付与。 -
サポート対応
例：顧客問い合わせ対応のため、サポート担当者が読み取り権限を申請。
→ 理由として「チケット番号 #12345」を入力。 -
インフラ保守
例：DB 管理者がメンテナンス中だけ roles/cloudsql.admin を付与。
→ 終了後は自動回収。 -
サービスアカウントの一時昇格
例：ジョブ実行中だけストレージ書き込み権限を付与し、終了後に自動剥奪。 -
外部委託スタッフ
例：契約社員がプロジェクト期間中だけ Viewer ロールを持つ。
→ 契約終了日に自動的に権限が外れる。
6-4. 設定パターンとベストプラクティス
-
Entitlement を用途ごとに作成
例：「緊急用」「本番参照用」「DB メンテ用」など。 -
最小権限・最短時間を徹底
例：roles/editor ではなく roles/logging.viewer など必要最小限に。 -
高リスク権限は多段階承認を設定
例：組織管理ロールは「上長＋セキュリティチーム」の二重承認に。 -
理由入力を必須化
例：緊急時のリクエストには「障害 ID やチケット番号」を必須に。 -
通知設定を有効化
例：緊急権限が使われたら SecOps チームに自動通知。 -
IaC ツールとの整合性に注意
Terraform は non-authoritative を利用して競合を避ける。
利用例
- ある企業では「緊急対応用の Entitlement」は即時付与、「本番環境用 Entitlement」は二重承認と明確に分けて運用。結果、セキュリティと運用スピードを両立できた。
6-5. Access Approvalによる監査強化（補足）
PAM は「社内ユーザーの特権管理」の仕組みです。
一方 Access Approval は「Google 社員がユーザーデータにアクセスする際に、必ずお客様の承認を得る」仕組みです。
これにより、社内外のアクセス経路を 完全にコントロール できます。
6-6. 章のまとめ
- PAM により「必要な人に、必要なときだけ、必要な権限」を実現可能。
- Access Approval と組み合わせれば、社内外のアクセスを完全に監査可能。
本回のまとめ
ここまでの第2～6章では、IAMの応用機能を幅広く紹介しました。今回はそのまとめとしてポイントを振り返り、第6回「組織のポリシー」へとつなげていきます。
応用機能の振り返り
-
サービスアカウントのインパーソネーション
管理者がサービスアカウントを一時利用し、秘密鍵なしで必要権限を確保可能。 -
Workload Identity Federation (WIF)
外部ID（AWSやGitHubなど）から直接Google Cloudにアクセス。鍵管理リスクを削減。 -
IAM Deny
明示的に「禁止操作」を設定するガードレール。許可ロールを持っていても実行不可。 -
IAM Conditions
「時間帯」「リソースタグ」「アクセス元」など条件で権限を制御。 -
Policy Intelligence
権限削減提案やアクセス分析でIAM運用を改善。 -
Privileged Access Manager (PAM)
一時的な権限付与。承認・有効期限付きで常時権限を排除。
組織ポリシーへの橋渡し
これらの機能は個別プロジェクトで有効ですが、次のステップは 組織レベルでの統制 です。
第6回の「組織ポリシー」では、応用機能を全社のガードレールとして適用し、全体最適のセキュリティ基盤を築きます。
IAM運用の全体像
- 第3回（IAM基本）: プリンシパル・ロール・ポリシーの基礎。
- 番外編1（IAM応用）本記事: インパーソネーション、WIF、Deny、Conditions、Policy Intelligence、PAM。
- 第6回（組織ポリシー）近日執筆予定: 全社規模のガードレールとして統合。
これにより、柔軟かつ強固なゼロトラスト運用モデルが完成します。
長文お付き合いいただきありがとうございました。
以上、 IAM に関する応用の解説でした。
第3回（IAM基本）第3回（IAM基本）も含めて確認頂けるとより理解が深まるかと思います。
それでは、次回 blog series 第４回 プロジェクトの門番！VPCとファイアウォール基本の「き」 もよろしくお願いいたします。
参照情報
- Service Account Impersonation
- サービス アカウントの使用に関するベスト プラクティス
- サービス アカウントの権限借用を使用する
- サービス アカウントの権限借用
- Workload Identity 連携
- AWS または Azure との Workload Identity 連携を構成する
- Deny Policies
- IAM Conditions
- Policy Intelligence 概要
- Role Recommendations Overview
- IAM Recommender の仕組み
- Policy Troubleshooter
- Policy Analyzer
- Policy Simulator
- Privileged Access Manager 概要
- Entitlements と Grants の仕組み
- PAM のベストプラクティス
- Cloud Audit Logs と PAM の監査
- Access Approval 概要
Discussion