【夏休みの自由研究リレー】Google Cloud 組織のアクセス権限 全部消した後、復旧してみた

こんにちは、すらぼです。

当記事はクラスメソッドの有志による『夏休みの自由研究リレー 2026』 第4回のエントリです。
このブログリレーの企画は、普段からクラウドやAIを追いかけているメンバーによって、「やってみた」だけではなく「作ってみた」や「調査/研究してみた」もアウトプットしてみようという企画です。

新たな知見になることは勿論、アイデアを自社やコミュニティの発展に寄与できればと考えておりますので、お付き合い頂けますと幸いです。
今回の記事は『Google Cloud 組織のアクセス権限全部消した後、復旧してみた』です。

今回やること

今回は、気になったことを試してみた結果の検証ブログです。
ふと、「組織に対する権限が間違って全部消えてしまったらどうなるんだろう？」というのが気になりました。

調べてみると、どうやら Cloud Identity の特権管理者であれば権限の復旧作業ができそうということがわかりました。今回はそれを実際に試して動作を確認してみようと思います。

やってみる

早速ですが、組織のアクセス権限を全部消した上で、復旧する方法を実際に試してみます。

組織の権限を全て削除する

まず、組織の IAM 画面を開き、権限を削除していきます。

全ての権限の削除が完了すると、以下のように、組織レベルでアクセス/操作権限が一切ない状態になりました。

組織の権限が全く無い状態

これで、準備は完了です。この状態から、挙動を調べていきます。

特権を持たないユーザーの場合: 何も出来ない

この状態で、まず特権管理者を持たないユーザーでの動作を確認してみます。
Admin Console での権限は、以下のようになっています。また、検証をわかりやすくする目的で、このユーザーには特権以外の全ての権限を付与してみました。

「特権管理者」以外の全ての権限を持っているユーザー

ページをリロードしてみると通常のユーザーでは以下のようにアクセスが拒否されます。
予想通りですね。

また、プロジェクトセレクターを開いても「組織なし」プロジェクトしか表示されません。

当たり前ですが、全てのリソースに対してアクセス権限を失った状態になっていますね。

Cloud Identity の特権管理者の場合: 権限付与が可能

では次に、Cloud Identity の「特権管理者」で挙動を確認してみます。
Admin Console では以下のように「特権管理者」以外の権限はほぼ持っていないユーザーで検証してみます。

特権管理者を持つユーザー

組織の IAM ページにアクセスしてみると、先ほどとは挙動が変わります。
例えば、以下の画面でリロードを繰り返しても、先ほどのようなエラーは表示されず、組織の IAM ページ（何のバインディングも存在しない）が確認できることがわかりました。

特権ユーザーの場合、組織に明示的な権限が存在しなくてもアクセスできる

また、「アクセスを許可」から権限付与も行うことができます。
「組織管理者」のロールを試しに付与してみます。

すると、以下のように権限付与ができました。

他のユーザーに対して権限付与を行うことができるため、万が一 全ての権限を誤って削除するような事態が発生しても、 Cloud Identity 特権管理者を通じて復旧作業が可能である ことがわかりました。面白いですね。

またこのことから、 「Cloud Identity の特権管理者」は暗黙的な IAM 付与権限 を持っていることもわかりました。

IAM の付与以外に何ができるか

IAM の付与ができることはわかりました。
そうなると、次に気になるのは「IAM の付与以外に何ができるのか」です。これも調べてみました。

公式ドキュメントの記述を探すと、ドンピシャの記述は見つけられませんでしたが、以下のような表記が見つかりました。

## サブ組織のロールを制限する
Google Workspace の特権管理者には、取消不能な組織管理者権限が付与されます。通常、この特権管理者は Google Cloud リソースとリソース ポリシーではなく、ID と ID ポリシーを管理します。
https://docs.cloud.google.com/resource-manager/docs/managing-multiple-orgs?hl=ja

上記は「サブ組織」という少し異なるシチュエーションですが、ヒントにはなりそうです。

組織管理者権限（roles/resourcemanager.organizationAdmin）は、以下のような権限を持ちます。

essentialcontacts.*
iam.policybindings.*
orgpolicy.constraints.list
orgpolicy.policies.list
orgpolicy.policy.get
resourcemanager.capabilities.*
resourcemanager.folders.createPolicyBinding
resourcemanager.folders.deletePolicyBinding
resourcemanager.folders.get
resourcemanager.folders.getIamPolicy
resourcemanager.folders.list
resourcemanager.folders.searchPolicyBindings
resourcemanager.folders.setIamPolicy
resourcemanager.folders.updatePolicyBinding
resourcemanager.organizations.*
resourcemanager.projects.createPolicyBinding
resourcemanager.projects.deletePolicyBinding
resourcemanager.projects.get
resourcemanager.projects.getIamPolicy
resourcemanager.projects.list
resourcemanager.projects.searchPolicyBindings
resourcemanager.projects.setIamPolicy
resourcemanager.projects.updatePolicyBinding

resourcemanager 系の権限が付与されているため、組織のプロジェクトやフォルダの閲覧が可能です。

しかし、実際に確認をしてみたところ、権限は組織管理者ほどは無さそうなことがわかりました。

まず、以下は、実際に組織管理者を付与した状態で見たプロジェクトの一覧（全て）です。

組織内のプロジェクト全て

次に全ての権限をなくした状態での、Cloud Identity 特権管理者に対する暗黙的な権限は以下のようになります。
プロジェクトなどを閲覧することができず、組織以外のリソースへのアクセス権限を失っていることが伺えます。

Cloud Identity 特権管理者の暗黙的な権限ではプロジェクトが見えない

また、同様に組織ポリシーに関しても閲覧することすらできません。

そのほか、 Essential Contacts についても同様に閲覧権限すら持たない状態になっていました。

Cloud Identity 特権管理者に暗黙的に与えられる権限は、IAM の操作のみが可能な非常に限定的な権限であることが実際の動作から見えてきました。

まとめ

ここまででわかったことを整理してみると以下のようになります。

• Cloud Identity の特権管理者は、暗黙的な IAM 操作権限を持つ
  • 組織の明示的な権限を全て削除しても、この権限は維持される
• 可能な操作は「権限の付与/削除」など非常に限定的で、それ以外の設定・リソースには閲覧権限すら持たない

これらの情報を踏まえると、 Cloud Identity 特権管理者に与えられる暗黙的な権限は「ロックアウトを回避する目的」での権限 であることが伺えます。

ただ一方で、権限付与さえしてしまえば全ての操作を自由に行うことができてしまいます。特権ユーザー自身に権限を追加することもできるので、事実上全てのアクションが可能と言っても差し支えないでしょう。
そのため、 Cloud Identity 特権管理者のログイン情報は慎重に取り扱い、侵害を避けるための取り組みも必須であると言えそうです。

Cloud Identity 特権管理者は明示的な権限がなくても組織に対する権限付与操作が可能 であるため、非常時の復旧に活用できることがわかりました。
しかしその反面、侵害されると一気に Google Cloud 組織全体が脅威にさらされるため、慎重な取り扱いが必要であるということも見えてきました。

終わりに

以上、 Google Cloud 組織の権限を全て削除した場合の復旧方法を通じて、Cloud Identity 特権管理者の暗黙的な権限についても調査してみました。組織に対する権限をうっかり全部消してしまうことがあっても、Cloud Identity 特権管理者にさえアクセスできれば復旧が可能なことがわかり、少し安心しました。

また、特権管理者は Google Cloud 組織で見かけ上権限を全て削除したとしても、暗黙的かつ特殊な権限を持つため、侵害された場合の脅威は非常に大きいものになることも同時にわかりました。MFA を設定するだけでなく、セルフリカバリーの禁止と複数人で特権管理者を管理するなどの安全策を講じることの重要性を改めて感じることができ、良い勉強になりました。

以上、『夏休みの自由研究リレー 2026』の第4回のエントリ『Google Cloud 組織のアクセス権限全部消した後、復旧してみた』でした。

次回は荒巻 美南海さんの『プロンプト入力が面倒なので「呼ぶだけで伝わる」AI アシスタントを作ってみた』の予定です。お楽しみに！！