🤴

【Google Cloudでセキュリティの柱を築く】PAM(特権アクセス管理)を構成する

2025/05/22に公開

こんにちは。山下です。
昨年末ごろよりIAMメニューに追加された”PAM”(特権アクセス管理)について触れていきたいと思います。パブリッククラウドを扱う上で欠かせないのが認証と認可です。そして、”最小権限の原則”による認可はもはや当たり前なベストプラクティスです。
しかし、最小権限の原則が正直通用しないケースというのが現実にはいくつかあります。例えば、以下のようなものが挙げられます。
[最小権限の原則が難しいもの]
アドホックでリソースを試しに作成したり削除して検証する時
TerraformなどIaCで多数の関連するリソースをデプロイする時
障害やインシデント発生時の復旧や原因調査をする時
外部の委託先に依頼し各人の役割や権限が明確でない時
人員が少なくメンバーが開発/インフラ兼任となっている時
ユーザーアカウント払い出し/権限付与等を各チームで対応する時
結果として、検証環境を別途設けてそこで必要な権限を洗い出しきってから対応するといった手間や工数が発生したり、利便性を重視して過剰な管理者/書き込みロールをとりあえず配布するといった事態が発生します。納期や人員を考えると自社開発でも委託でも”最小権限の原則”が難しい場面があります。
一時的に権限を付与して外すという手動またはIaCでの運用も出来はしますが、手間もリスクもあります。

 権限昇格/認可の不備によるリスククラウドやワークロード、アプリケーション内の認証/認可情報がソーシャルエンジニアリングやフィッシング、脆弱なパスワード管理などを通じて流出してしまうケースがあります。さらに愚直にブルートフォルスや辞書、レインボーなどで手当たり次第攻撃して奪う方法もあります。
このようなケースで漏洩したアカウントに管理者ロールやAdministrator/rootなど強い権限があった場合にシステムに好き放題操作が行えるようになり、機密情報の漏洩や高額なGPUインスタンスを大量に立てて仮想通貨マイニングが行われたりします。この辺りは一般的な話ですね。
https://www.crowdstrike.com/ja-jp/cybersecurity-101/cyberattacks/privilege-escalation/

 特権アクセス管理常に権限を付与せず、一時的かつ承認を得た場合に限り付与するといったことが特権アクセス管理ソリューションを導入する事で可能です。必要な時に必要な分の権限だけを付与するJust In Time(JIT)であったり、特権昇格に必要な条件としてアクセス元や承認者許可が必要などの条件を付けることが可能です。
また、監査/証跡ログを残すことで権限昇格時に不審な操作が含まれていた場合に検出する事も出来ます。
https://www.cyberark.com/ja/what-is/privileged-access-management/
https://www.okta.com/jp/privileged-access-management/


ユースケース
昇格例
昇格条件例


アドホックでリソースを試しに作成したり削除して検証する時
“閲覧者”から”試すリリースの管理者”
平日の日中帯のみ権限を昇格

TerraformなどIaCで多数の関連するリソースをデプロイする時
“開発PJの編集者”から”本番PJの編集者/オーナー”
新規リリース作業の2時間のみ昇格

障害やインシデント発生時の復旧や原因調査をする時
“開発者”から”PJの閲覧者”
調査開始から数時間のみ昇格、依頼があれば延伸

外部の委託先に依頼し各人の役割や権限が明確でない時
“特定リソースの閲覧者”から”特定リソースの管理者”
特定の時間帯で数時間のみ昇格

人員が少なくメンバーが開発/インフラ兼任となっている時
“開発者”から”リソース管理者”
承認者/責任者を設け承認時のみ昇格

ユーザーアカウント払い出し/権限付与等を各チームで対応する時
“編集者”から”IAM管理者”
ユーザ追加、権限付与作業の時間だけ昇格

上記のように条件や期限を明確にすることで完全に防ぎきるものではありませんが、常に付与されることによる以下のリスクを防ぐことが出来ます。

 [防ぎうるリスク一覧]

内部不正: 特権を持つ悪意のある内部関係者による不正アクセス、データ改ざん、情報漏洩。

外部からの攻撃: 攻撃者が特権アカウントを乗っ取り、システムを完全に制御したり、機密情報を盗み出したりするリスク。

マルウェア感染の拡大: マルウェアが特権アカウントを悪用してシステム全体に感染を広げるリスク。

設定ミスや人的エラー: 特権を持つユーザーによる誤操作や設定ミスによるシステム障害やセキュリティ脆弱性の発生。

ラテラルムーブメント (横展開): 侵害されたアカウントを足がかりに、他のシステムやネットワークへ侵入を拡大する攻撃。

 Privileged Access ManagementGoogle Cloudではこの特権アクセス管理サービスを利用する事が出来ます。名前はそのままでPrivileged Access Management(PAM)になります。他社の特権アクセス管理サービスと同様に一時的な権限昇格を管理し、セキュリティと運用性を両立できるような機能です。
普段は最小権限の原則に従い、有事や止む無いタイミングでのみ例外対応するものになります。
また、ユースケースに記載されている通りプリンシパルの指定にサービスアカウントを選択する事も可能です。実際の挙動をドキュメントと共に確認してみます。
https://cloud.google.com/iam/docs/temporary-elevated-access?hl=ja

 利用方法
 ①特権アクセス定義この辺りは他の方も記事に書いているので、、簡単に。PAMの利用資格から作成を選択。
想定される権限昇格のシナリオごとに以下の設定項目を定めていきます。


設定項目
設定値
備考


資格名
ユースケース毎に定義する権限昇格の定義。
この定義事に与えるロールと誰に与えるのかどの期間与えるのかが定義されます

ロール名
付与対象のIAMロールを選択。
なお、ドキュメントに注意書きのある通りsetIamPolicyに関わる権限とiam.roles.updateに関わる権限を組織/フォルダ/プロジェクトに付与すると、PAMを無視してロール付与が出来るのでむやみにProject IAM管理者や管理者ロールを付与すべきではありません。

権限を付与する最大期間：
1時間から24時間までの間で期限指定。
-



設定項目
設定値
備考


リクエスト元のプリンシパル
権限昇格を依頼するGoogleアカウント/グループまたはサービスアカウント
正当な理由が必要とすると、申請時に理由を記入/提出する必要があります。

承認者のプリンシパル
権限昇格を依頼を審査するGoogleアカウント/グループまたはサービスアカウント
正当な理由が必要とすると、承認時に理由を記入/提出する必要があります。



申請者、承認者、第三者のいずれにも通知を送ることが可能です。
ステータスごとに定義でき通知時に承認するかどうかを決められます。
このように申請者側に昇格資格が与えられたことがメールにて通知されます。

 ②権限付与申請申請者にてPAMのメニューにアクセスし、利用資格の欄を確認すると以下のように”権限付与をリクエスト”がクリックできるようになります。
申請期間は1時間の場合、最大1時間付与となり、30分-1時間の間で指定となります。数分だけ付与という事は一応できません。※そこまでセンシティブになる必要はないとは思いますが、、
また、申請理由を必須としている場合は理由を記載する必要があります。申請フォームなどを自社で組まれている方はこちらに移管する事も出来ます。
リクエストにより、申請待ちにステータスが変わり承認者宛に以下のような承認するか却下するかの判断メールが届きます。

 ③権限付与承認承認者にてPAMのメニューにアクセスし、権限付与を承認にアクセスすると承認/拒否が選択できるようになります。
承認欄にて問題なければ承認とします。承認時のコメントを必須にしている場合は記載が必要になります。
権限付与欄からリクエスト依頼者に対して権限付与が行われている状況を確認できます。
これによって申請者に承認された旨のメッセージがメールで届きます。
ちなみに有効期限が切れるまでの間権限は付与され続けるので、権限を返したいとなっても途中で外すことはできません。承認者側でのみ、権限付与を取り消すことが出来ます。

 サービスアカウントでの利用サービスアカウントも当然ながら強い権限の維持は望ましくなく、Terraformで何かをデプロイする、アプリケーションをGKE/CloudRun上にデプロイする時以外権限を渡さない事が出来るのであれば最適です。
一方、サービスアカウントはメールアドレスを持ちませんし、当然ながら人間ではない認証プリンシパルなので少し工夫する必要があります。やり方としては以下を考えてみました。

 ①コンソールで申請/承認するリクエスト元のプリンシパルにサービスアカウントを指定して定義します。承認者は基本的に人間で問題ないと思います。が、より高度に自動化する場合はサービスアカウントが承認者となり、GoogleCloudにアクセスせずとも別の方法で承認したりも可能ではあります。
サービスアカウントの承認で肝となるのがこちらの通知設定です。通知先のリクエスト元で申請をあげる人間のアドレスを指定します。これによって、メール通知を人間側で確認できます。※利用時間制限もあるので

 ②CLIにて申請/承認するgcloudコマンドにてGoogleアカウントないしはサービスアカウントでauthなどで認証して、その認証先で付与リクエストできる権限一覧を表示できます。
gcloud pam entitlements search \
    --caller-access-type=grant-requester \
    --location=global \
    --RESOURCE_TYPE=RESOURCE_ID
リクエストを出せる権限から付与リクエストも以下のコマンドで出すことが出来ます。
gcloud pam grants create \
    --entitlement=ENTITLEMENT_ID \
    --requested-duration="GRANT_DURATIONs" \
    --justification="JUSTIFICATION" \
    --location=global \
    [--additional-email-recipients=EMAIL_ADDRESS_1,EMAIL_ADDRESS_2] \
    --RESOURCE_TYPE=RESOURCE_ID
また、同様に承認も以下で行う事が出来ます。
gcloud pam grants approve \
    GRANT_ID \
    --entitlement=ENTITLEMENT_ID \
    --reason="APPROVAL_REASON" \
    --location=global \
    --RESOURCE_TYPE=RESOURCE_ID
ここで嬉しいのはコンソールにアクセスせずともgcloud cliの認証を行っていればリクエスト申請をあげられることです。そのため、デプロイの自動化やCI後の成果物PushなどCI/CDツールが自動で権限昇格をリクエストできるようになります。
承認通知をトリガーに昇格し作業をツールが行うといった運用が可能になります。

 まとめこのように従来は手動での権限付与/剥奪で特権を付与していたり、サードパーティー製品でないと管理されていなかった特権アクセス管理がGoogleCloudネイティブ機能で扱えるようになりました。これにより利便性の向上に繋がるだけではなく、セキュリティも担保できる嬉しい機能になります。
また、CloudShellが使えない環境でIAPを用いて一時的にGCEにログインして操作したり、リソースベースポリシーでの応用も期待できます.
GoogleCloudに限られますが、今後AIエージェントが自リソースにアクセスしてくるケースが考えられます。そうしたときにPAMを組み、昇格条件を満たして初めてエージェントが期限付きで役目を果たすといった事に応用できそうです。

ユースケース	昇格例	昇格条件例
アドホックでリソースを試しに作成したり削除して検証する時	“閲覧者”から”試すリリースの管理者”	平日の日中帯のみ権限を昇格
TerraformなどIaCで多数の関連するリソースをデプロイする時	“開発PJの編集者”から”本番PJの編集者/オーナー”	新規リリース作業の2時間のみ昇格
障害やインシデント発生時の復旧や原因調査をする時	“開発者”から”PJの閲覧者”	調査開始から数時間のみ昇格、依頼があれば延伸
外部の委託先に依頼し各人の役割や権限が明確でない時	“特定リソースの閲覧者”から”特定リソースの管理者”	特定の時間帯で数時間のみ昇格
人員が少なくメンバーが開発/インフラ兼任となっている時	“開発者”から”リソース管理者”	承認者/責任者を設け承認時のみ昇格
ユーザーアカウント払い出し/権限付与等を各チームで対応する時	“編集者”から”IAM管理者”	ユーザ追加、権限付与作業の時間だけ昇格

設定項目	設定値	備考
資格名	ユースケース毎に定義する権限昇格の定義。	この定義事に与えるロールと誰に与えるのかどの期間与えるのかが定義されます
ロール名	付与対象のIAMロールを選択。	なお、ドキュメントに注意書きのある通りsetIamPolicyに関わる権限とiam.roles.updateに関わる権限を組織/フォルダ/プロジェクトに付与すると、PAMを無視してロール付与が出来るのでむやみにProject IAM管理者や管理者ロールを付与すべきではありません。
権限を付与する最大期間：	1時間から24時間までの間で期限指定。	-

設定項目	設定値	備考
リクエスト元のプリンシパル	権限昇格を依頼するGoogleアカウント/グループまたはサービスアカウント	正当な理由が必要とすると、申請時に理由を記入/提出する必要があります。
承認者のプリンシパル	権限昇格を依頼を審査するGoogleアカウント/グループまたはサービスアカウント	正当な理由が必要とすると、承認時に理由を記入/提出する必要があります。

権限昇格/認可の不備によるリスク

特権アクセス管理

[防ぎうるリスク一覧]

Privileged Access Management

利用方法

①特権アクセス定義

②権限付与申請

③権限付与承認

サービスアカウントでの利用

①コンソールで申請/承認する

②CLIにて申請/承認する

まとめ

Discussion