Zenn
🚫

【Google Cloudでセキュリティの柱を築く】Unified Access Policies(拒否ポリシー)を構成する

に公開
Security
Google Cloud
IAM
CCoE
tech

こんにちは。クラウドアーキテクトの山下です。

Next’25で発表されたセキュリティサービス群について触れていきたいと思います。実は以前から利用でき、今年に入ってから微妙にマイナーチェンジがあったUnified Access Policies(拒否ポリシー)について触れたいと思います。

予防的統制としての認可制御

セキュリティ統制方法としてインシデントや脅威の発生を未然に防ぐ予防的統制とインシデントや脅威そのものまたはその予兆を検出する発見的統制があります。例としては以下のようなものがあげられます。

https://aws.amazon.com/jp/builders-flash/202302/continuous-security/#:~:text=「予防的統制」とは,な統制を指します。

予防的統制の例

  • IAMでユーザーに必要最低限の権限しか与えない(最小権限の原則)
  • 組織ポリシーでクラウド上で行う操作に制限をつける
  • 階層的ファイアウォール/共有VPCでユーザが操作できるIaaSネットワークを制限する

発見的統制の例

  • Cloud Audit Log(監査ログ)でプロジェクトを監視
  • Security Command CenterでCSPM/CWPを適用する
  • SecOpsでSIEM/SOAR監視運用を行う

ここで例示した最小権限の原則を行うためにGoogle CloudではIAMでのユーザ権限付与と組織ポリシーでのサービス利用制限があります。

IAMでのユーザ権限付与

単純にGoogleアカウント(=ユーザアカウント)にロールバインドする際に割り当てるロールを必要最低限のものにする方法です。

極端な話、普段BigQueryやそのデータ格納に関わるサービスしか操作しないのに権限付与や全リソースへの作成/更新/削除できるオーナーロールを付与するのは過剰です。最低限必要な権限だけを与えて、他は与えないようにします。

https://cloud.google.com/iam/docs/using-iam-securely?hl=ja

ユースケースにぴったりのロールがあれば事前定義ロールを選択して適用します。なければ、カスタムロールを作成しAPIのアクション単位(閲覧/作成/更新/削除)を選び作成します。


組織ポリシーでの制限

Google CloudではAWSのOrganizationのSCPのように組織ポリシーという組織配下のフォルダやプロジェクト全体に画一した制限を設けることも出来ます。例えば、CloudShell利用を禁じたり、特定サービスのAPI有効化を禁じたり、自組織ではないgmail.comなどのアカウントへの権限付与を禁じたりなどがあります。

CELといった独自言語での条件付けなど少しハードルはありますが、IAMと同様にカスタムでAPIの特定アクション単位で制限を課すことも出来ます。

※過去の記事にも記載

https://zenn.dev/dyama666/articles/fc0a9238ec2321


最小権限運用の限界

IAMでの権限制御と組織ポリシーでの権限制御どちらも最小権限の原則を実現する事ができるものです。前者はフォルダやプロジェクト単位で各ユーザーに対して制御を与えることができ、後者は組織全体でサービスに制限をかけることができます。

一見すると十分な制御方法に思えますが、対応しきれないケースもあります。具体的に見ていきます。

ケース1: 権限管理が煩雑

IAMはあくまで”許可”を行う設定になります。そのため、ユーザに与えたくない権限と事前定義ロール内の権限を突合する必要があります。

また、ユーザの業務範囲が変化して操作しないといけないリソースが増減するケースもあります。今までBigQueryしか触っていなかったのに、CloudLoggingの権限追加が必要になったり、部署異動や退職で特定のプロジェクトから権限をはく奪したりなどです。

さらに兼務で特定の個人だけ複数のプロジェクトに対して権限を持ち、他のメンバーは各プロジェクトでのみ操作するなどとしたケースもあると思います。

こんな状況を受け入れて必死に権限精査を行い運用を頑張っていく、管理が煩雑なのではじめから広い権限を与えてしまう楽だが危険な運用にする。どちらを選んでも大きなデメリットがあります。

ケース2: 組織ポリシーは細かな制御できない

組織ポリシーはIAMと違い組織全体やフォルダ/プロジェクト単位で拒否を設定できます。一方で、プリンシパル単位での設定や除外を行う事が出来ず、既に作成済みのリソースに対しては殆ど利かないという仕様があります。

そのため、Google Cloudでリソースを作ってしまっているユーザーに対して権限はく奪をするには組織ポリシーでは行えず結局IAMでの運用を行う必要があります。

また、設定範囲の最小単位がプロジェクトレベルのため、リソースレベル(GCEインスタンス単位,BigQueryデータセット単位等)やGoogle アカウントレベルでの制御を与えることはできません。

新しくなった拒否ポリシー

最小権限の原則よりも少し緩めに、しかし、セキュリティ上渡したくない権限を簡単に剥奪できるのが拒否ポリシーです。拒否ポリシーは文字通り、与えたくない権限を拒否(＝強制剥奪)するIAMの機能です。

これによってユーザに与えたくない権限だけに絞って剥奪する事が出来るので、事前定義ロールとの細かな突合やユーザにオーナー/編集者などの強い権限を渡しても封じたい権限を与えずに済みます。

拒否ポリシーの設定方法

拒否ポリシーはgcloud CLIにてIAMのAPIに対して設定する事が出来ます。以下のようなJSON定義にて剥奪する権限及び剝奪対象のプリンシパルを設定できます。

https://cloud.google.com/iam/docs/deny-overview?hl=ja

さらに拒否ポリシーを適用するプリンシパルに属するアカウントやグループを除外する事もできます。例えば、全Google アカウントが所属するGoogle グループから管理者のGoogle アカウントだけ除外する事が可能です。

公式のサンプルを基に設定を確認すると以下のような構成となります。拒否したい権限はIAMロールの作成/更新/削除操作で全Google アカウントに対して剥奪を行っています。一方で、custom-role-admins@example.comのGoogle グループだけは権限が剝奪されず、IAMロールの作成/更新/削除が行えます。

これによって、オーナーロールや編集者ロールを渡しても拒否ポリシーに登録されたIAM権限は剥奪されます。

{
  //拒否したいプリンシパル(Googleアカウント/グループ,サービスアカウント)
  "deniedPrincipals": [
    "principalSet://goog/public:all"
  ],
  //拒否から除外したいプリンシパル
  "exceptionPrincipals": [
    "principalSet://goog/group/custom-role-admins@example.com"
  ],
  //拒否したいIAM権限
  "deniedPermissions": [
    "iam.googleapis.com/roles.create",
    "iam.googleapis.com/roles.delete",
    "iam.googleapis.com/roles.update",
  ]
}

他にも、拒否する権限の範囲を広くとって特定操作だけ除外するという事も可能です。例えば、IAMロールを変更するような操作だけ許可したくなく、閲覧なら良いとする場合は以下のようなポリシーを組むことが出来ます。

本来であれば、上のJSON例のように与えたくない権限一覧を調べて列挙する必要がありますが、このexceptionPermissionsを定義する事で許可してもいい権限に絞って除外が可能です。

閲覧など許可したいものがわずかにあり、他は拒否したい場合に非常に有用な項目になります。

https://cloud.google.com/iam/docs/deny-overview?hl=ja

{
  "deniedPrincipals": [
    "principalSet://goog/public:all"
  ],
  //拒否したいIAM権限(ワイルドカードで広めに設定)
  "deniedPermissions": [
    "iam.googleapis.com/roles.*",
  ],
  //許可してもいいIAM権限(ワイルドカード指定から選択)
  "exceptionPermissions": [
    "iam.googleapis.com/roles.list",
    "iam.googleapis.com/roles.get",
  ]
}

他にも許可と同様にIAM Conditions(IAM条件)も拒否ポリシーでは定義する事が出来ます。

やりやすくなった拒否ポリシー

2024年では拒否ポリシーを設定する場合、上記のようなJSON定義を用意してAPIに対して設定を命令する事でしか適用する事が出来ませんでした。そのため、CloudShellが使えない、VPC-SCでAPIにアクセスできる対象が狭いといった環境では設定のためのハードルが大きいものでした。そのうえ、設定状況の確認もコンソール上からは行えずAPI経由でのみ確認できる煩雑なものでした。

2025年年明けごろからIAM画面で許可しないという項目が追加されるようになりました。

そこから拒否ポリシーの作成を選択すると・・・JSON項目と全く同じ設定メニューが選択できるようになっています。拒否/除外したいプリンシパル、拒否/除外したい権限を設定することが出来ます。


これだけで簡単に拒否ポリシーが作成できます。また、拒否ポリシーを用途別に定義する事も一つの拒否ポリシーの中に複数の拒否内容を定義する事も出来ます。

留意事項

拒否ポリシーは全ての権限をサポートしているわけではありません。大方のサービスはカバーできているように見えますが、新しくPreviewサービスなどには効かない可能性があるので万全ではないです。

https://cloud.google.com/iam/docs/deny-permissions-support

また、数分の猶予がある一方で拒否ポリシーはIAM権限をすぐに剥奪するものです。そのため、ユーザ影響が発生しかねないものです。特にサービスアカウントから拒否剥奪を行う事にも注意する必要があります。今までGCEやGKE上のコンテナなどサービスアカウントが他のGoogle Cloudサービスにアクセスするケースでは途端に権限不足でサービス停止に繋がってしまいます。

簡単に設定できる反面、既存サービスへの適用は慎重に行うべきです。これをサポートするのがシミュレーション機能です。

https://cloud.google.com/policy-intelligence/docs/deny-simulator-overview?hl=ja

過去90日間の監査ログを確認して剥奪する権限及び対象のプリンシパルに対して該当のAPIアクセスが行われていたか、拒否するとどのような影響があるかを確認できます。これにより、拒否前に細かく権限チェックを行う事が可能です。

まとめ

Google CloudではIAMと組織ポリシーという2つの権限統制を行う選択ができます。IAMはそもそも許可がないと一切Google Cloudを操作できないので不可欠なものですが、最小権限の原則を組織ポリシーと組み合わせて実現できるものでした。

しかし、見てきた通りこれらだけでは通用しない場面も多くあります。そのため、拒否ポリシーも組み込む事でこれをカバーできます。これらは選択肢なのではなく、それぞれ設定する事で真価が発揮できるものです。まずは出来るところから適用するのをお勧めします。

制御方法 出来る事 スコープ ユースケース
IAM(許可) 特定のプリンシパルに許可を与える Google アカウント/グループ,サービスアカウントと組織/フォルダ/プロジェクト 特定のアカウントへ必要最低限の権限を付与(※必要不可欠)
IAM(拒否) 特定のプリンシパルから許可を強制的に剥奪 Google アカウント/グループ,サービスアカウント ユーザに絶対に渡したくない権限だけを奪う(誤って付与しても剥奪される,将来を見越して権限を広く渡せる)
組織ポリシー 組織/フォルダ/プロジェクトに対してAPI操作を制限 組織/フォルダ/プロジェクト 組織全体でサービスの利用制限を簡単に設定する(プリンシパルでなく組織単位で設定)

これ以外にも”プリンシパルアクセス境界”という制御方法もあります。この内容については別途紹介したいと思います。

拒否ポリシーはサービスアカウント(≒非人間)のアカウントにも認可の制御をかけることが出来ます。今後増えるであろうAIエージェント内のツールやAPIアクセスに関わる操作を簡単に制御できるものでもあります。人間以外の対象に向けても認可を制御する手段としても有用になるかと思います。

Discussion