Google Cloud PAM（Privileged Access Manager）で特権アクセスを期限付きにしてみた

こんにちは、SCSKの齋藤です。
本記事では、Google Cloud PAM（Privileged Access Manager）を使った特権アクセスの期限付き付与についてご紹介します。

はじめに
PAM（Privileged Access Manager）とは
構築の工夫
工夫したところ・ハマったところ
まとめ

はじめに

検証環境を構築・運用していく中で、権限管理の課題に直面しました。開発中はどうしても強い権限（BigQuery Adminやプロジェクト Owner等）が必要になる場面があるのですが、それを常時付与しておくのはセキュリティ的に良くありません。かといって毎回手動でIAMの付与と剥奪を行うのは非常に手間がかかります。人数が増えれば尚更です。

「必要なときだけ、必要な権限を、期限付きで付与する」という仕組みが欲しいと思っていたところ、Google CloudにPAM（Privileged Access Manager）というサービスがあることを知りました。Just-In-Time（JIT）アクセスと呼ばれるパターンをマネージドで実現できるサービスです。

検証環境にPAMを構築してみたところ、権限管理の運用負荷がかなり軽減されました。この記事では、PAMの概要と仕組みを整理しつつ、Terraformで構築する際の設計上の工夫、そして実際に運用してみて感じたことについて書いていきます。特にTerraformでの構築では、複数プロジェクトへの一括適用や承認フローの柔軟な設定など、IaCならではの工夫ポイントがいくつかあったので紹介します。

PAM（Privileged Access Manager）とは

PAM（Privileged Access Manager）は、Google Cloudが提供するJust-In-Time特権アクセス管理のマネージドサービスです。2024年にGA（一般提供）となった比較的新しいサービスです。

従来のIAM運用では、開発者に必要な権限を事前に付与しておくのが一般的でした。しかしこの方式だと、普段使わない強い権限が常時付与されたままになり、セキュリティリスクが高まります。万が一アカウントが侵害された場合、攻撃者がその権限をそのまま行使できてしまいます。これは「最小権限の原則（Principle of Least Privilege）」に反する状態です。

PAMはこの問題を解決するために、「エンタイトルメント（Entitlement）」という概念を導入しています。エンタイトルメントは「誰が」「どの権限を」「最大何時間」「どのような条件で」利用できるかを定義したリソースです。開発者は普段は権限を持たず、必要になったときにエンタイトルメントへのアクセスをリクエストします。設定に応じて承認者の承認を経た上で、期限付きで権限が付与されます。

PAMの動作フローは以下の通りです。

ステップ	アクター	内容
1. リクエスト	開発者	「この権限を◯時間ください」と理由付きで申請
2. 承認	承認者	リクエストを確認し承認/却下
3. 権限付与	PAM	IAMに権限を期限付きで追加
4. 自動剥奪	PAM	期限切れで権限を自動削除

この一連のフローがすべて監査ログに記録されます。

PAMの主なメリットとして、以下が挙げられます。常時付与の強い権限を排除し、セキュリティポスチャを向上できること。権限付与の全履歴（誰が、いつ、どの権限を、どのような理由で利用したか）が自動的に記録され監査に対応できること。承認ワークフローをマネージドで実現でき、カスタムの仕組みを自前で構築する必要がないこと。Terraformで管理可能なためエンタイトルメント定義をIaCとして管理できること。そして組織レベル、フォルダレベル、プロジェクトレベルのいずれでもエンタイトルメントを作成できる柔軟性があることです。

類似のアプローチとしては、Googleグループのメンバーシップを一時的に付与する方式、カスタムのCloud FunctionsでIAM付与・剥奪を自動化する方式、サードパーティのPAMツール（HashiCorp Vault等）を使う方式がありますが、Google Cloud PAMはGCPネイティブで動作し追加インフラが不要という点が優位です。

構築の工夫

for_each でプロジェクトごとに一括作成

複数のプロジェクトに対してエンタイトルメントを作成する必要があったため、Terraformの for_each を使って一括管理しています。


resource "google_privileged_access_manager_entitlement" "this" {
  for_each = var.target_projects

  entitlement_id       = "pam-${each.key}"
  parent               = "projects/${each.key}"
  location             = "global"
  max_request_duration = "7200s"  # 最大2時間

  eligible_users {
    principals = var.eligible_users
  }

  privileged_access {
    gcp_iam_access {
      resource      = "//cloudresourcemanager.googleapis.com/projects/${each.key}"
      resource_type = "cloudresourcemanager.googleapis.com/Project"
      role_bindings { role = "roles/bigquery.admin" }
    }
  }
}

キーにプロジェクト識別子を使い、値にそのプロジェクト固有の権限セットや承認者を定義する構造にしました。プロジェクト追加時も変数ファイルにエントリを追加するだけで済みます。

承認あり/なしのdynamic切り替え

検証環境では承認なし（セルフサービス）、本番に近い環境では承認ありにしたいという要件がありました。Terraformの dynamic ブロックを使い、承認者リストが空の場合はapproval_workflowブロックごとスキップする設計にしています。同じモジュールで両方のパターンに対応できるため、環境ごとにモジュールを分ける必要がありません。

リクエスト時の理由記入を必須化

エンタイトルメントの requester_justification_config で、リクエスト時に理由の入力を必須にしています。これにより「誰が、いつ、なぜ権限を必要としたか」の記録が自動的に残ります。セキュリティ監査の観点からも、この設定は入れておいたほうがよさそうです。

工夫したところ・ハマったところ

PAM APIの有効化が必要

エンタイトルメントを作成する前に、対象プロジェクトでPAM APIを有効化する必要がありました。最初これを忘れてterraform applyが失敗しました。Terraformの google_project_service リソースでAPI有効化を先に行い、depends_on でエンタイトルメントリソースとの依存関係を明示する必要がありました。

期限の設定

max_request_duration で権限の最大付与時間を設定できます。短すぎると作業中に権限が切れてしまいますし、長すぎるとJITアクセスの意味が薄れます。検証環境では2〜4時間程度に設定し、延長が必要な場合は再度リクエストしてもらう運用にしています。

Googleグループとの組み合わせ

eligible_users や approvers にはGoogleグループを指定できます。個人のメールアドレスを直接指定すると、メンバーの増減のたびにTerraformを修正する必要が出てくるため、Googleグループ経由で管理するのが運用上楽です。

コンソールからの利用方法

エンタイトルメントへのリクエストはGCPコンソールの「PAM」メニューから行えます。UIは直感的で、リクエスト → 理由入力 → 承認待ち → 権限付与というフローが視覚的にわかりやすくなっています。開発者への展開もスムーズでした。gcloudコマンドやAPIからもリクエスト可能なので、スクリプト化することもできます。

承認者にはメール通知が届きますが、Slackへの通知連携は標準では用意されていません。Cloud Monitoringのアラートポリシーと組み合わせるか、Pub/Subを経由してSlack通知を実装する必要がありました。ここは今後の改善ポイントとして残っています。

運用してみての所感

実際にチームで運用を始めてみると、「権限が必要になるたびにリクエストする」という一手間が加わるわけですが、慣れてしまえば特に負担に感じませんでした。むしろ「この作業にはこの権限が必要」ということを意識するようになり、権限設計の改善にもつながりました。不必要に強い権限をリクエストしていることに気づくきっかけにもなります。

まとめ

– PAMは「必要なときだけ、承認を経て、期限付きで」特権を付与するJust-In-Timeアクセスをマネージドで実現するサービス
– Terraformの for_each + dynamic ブロックで、複数プロジェクト × 承認あり/なしのパターンを柔軟に管理できる
– 検証環境に導入してみたところ、権限の付与・剥奪の運用負荷がかなり軽減された
– Googleグループと組み合わせることで、メンバー管理の手間も最小化できる
– PAM APIの事前有効化を忘れないようにしたいところです
– 権限管理は地味な作業だが、PAMのようなマネージドサービスを使うことで手間を最小化しつつセキュリティを向上できる。Google Cloudのセキュリティ機能として、もっと広まってほしいサービスだと感じた
– 新しいサービスのためまだ日本語の情報が少ないが、TerraformのGoogle Providerでしっかりサポートされているので構築は問題なく行える