Zenn
🐧

プロジェクト運用前に知っておきたいIAMの考え方

に公開
初心者
Google Cloud
Security
IAM
最小権限
tech

はじめに

こんにちは、クラウドエースの梶尾です。

Google Cloud でプロジェクトを立ち上げるとき、ついリソースの作成やサービスの設定に集中してしまいがちです。
でも、実はその前に考えておくべき大切なことがあります。
それが「アクセス管理」、つまり 誰が、どこまで操作できるか というルールを決めることです。

Google Cloud では、このアクセス管理を担っているのが IAM（Identity and Access Management） という仕組みです。
IAM を正しく理解し、使いこなせるようになると、チームの誰に何の権限を与えるかを明確にコントロールでき、プロジェクトの安全性が大きく向上します。
この記事では、これから Google Cloud を本格的に使い始める人のために、IAM の基本的な考え方と設定のポイントをやさしく解説していきます。
また、IAM の設計に加えて、運用フェーズで役立つ機能である IAM Recommender についてもご紹介します。これは、実際の権限使用状況をもとに、より適切なロールへの見直しを支援してくれるツールで、最小権限の原則を実現するうえで大きな助けになります。

運用前にしっかり準備しておくことで、トラブルを未然に防ぎ、安心してプロジェクトを進められるようになります。

IAM って何

IAM（Identity and Access Management）は、Google Cloud 上で「誰が、どのリソースに、どんな操作ができるか」を制御する仕組みです[1]。

IAM では、主に次の 3 つの要素でアクセス管理を行います。

  • プリンシパル（Principal）：
    アクセスを行う主体（例：ユーザー、サービス アカウント など）
  • ロール（Role）：
    どんな操作を許可するかを定義した権限のセット
  • ポリシー（Policy）：
    「このプリンシパルに、このロールを、このリソースに対して与える」という設定

IAM はこの「プリンシパル × ロール × リソース」の組み合わせにより、誰にどんな権限を与えるかを細かく定義できます。
IAM におけるアクセス制御の構成要素

たとえば、プロジェクト A の Cloud Storage バケットに対して、あるユーザーには「閲覧のみ」、別のユーザーには「書き込みまで」を許可する、といった柔軟な制御が可能です。

IAM を適切に活用することで、「必要な人に、必要な操作だけ」を許可できるため、セキュリティと利便性の両立を図ることができます。

アクセス管理に IAM が使われる理由

Google Cloud では、仮想マシンやストレージ、ネットワークなど、さまざまなリソースを自由に作成・管理できます。
ですが、自由であるぶん、「誰が、どこまで操作できるか」を明確にしないと、意図しないトラブルやセキュリティリスクにつながってしまいます。

たとえば、操作に慣れていないメンバーに重要な権限を与えていた場合、うっかり本番リソースを削除してしまったり、アクセス権の設定ミスで機密データが外部から見えてしまったりする可能性もあります。

IAM を使えば、こうしたリスクを最小限に抑えつつ、必要な人にだけ、必要な権限を与えることができます。
たとえば、「この人は読み取りだけ」「この人はストレージの管理も OK」といった細かい制御ができるため、クラウド環境を安心してチームで運用することができるのです。

また、IAM の設定はいつでも見直すことができるので、プロジェクトの成長やチーム構成の変化に応じて、柔軟に対応できる点も大きなメリットです。

IAM のロールについて

IAM では「ロール」という形で、操作権限のまとまりが定義されています[2]。
ユーザーやサービスアカウントには、このロールを割り当てることで「どこまで操作できるか」を制御します。

Google Cloud には、大きく分けて次の 3 種類のロールがあります。

基本ロール

Google Cloud における最も基本的なロールには、以下の 3 つがあります。

読み取り(roles/reader)：

既存のリソースやデータを表示するための読み取り専用のロールです。
リソースの状態に影響を与えることはなく、参照のみが可能です。編集や削除はできません。

書き込み(roles/writer)：

読み取りロールのすべての権限に加え、リソースの作成、変更、削除といった状態を変更する操作が可能です。
ただし、すべてのサービスや操作に対応しているわけではなく、特定のタスクには追加の権限が必要な場合があります。

管理者(roles/admin)：

書き込みロールのすべての権限に加えて、以下のような操作が可能です。

  • リソースのタグバインディングなどの機密性の高い操作
  • IAM 権限やロールの管理
  • プロジェクトの課金設定の管理

ただし、管理者ロールでも以下の操作は行えません。

  • Cloud Billing のお支払い情報の変更
  • IAM 拒否ポリシーの作成

管理者ロールはシンプルで分かりやすい反面、操作範囲が非常に広いため、意図しない操作や過剰な権限付与のリスクがあることが問題です。
そのため、現在では新規プロジェクトでの使用はあまり推奨されていません。

ただし、例えば検証目的の一時的な開発環境をチーム内ですばやく立ち上げたい場合や、まだ明確なアクセス要件が定まっていない初期フェーズなどにおいては、利便性を優先して短期間だけ管理者ロールを使うこともあります。
また、検証環境などのセキュリティ要件が本番ほど厳しくないケースでは、手間を減らす目的で使用されることもあります。

一方で、本番環境では、「必要最小限の権限」を意識した事前定義ロールやカスタムロールへの切り替えを早めに検討することが重要です。

事前定義ロール

事前定義ロールとは、Google があらかじめ用意し、サービスごとに設計したきめ細やかなアクセス制御が可能なロールです。
新しい機能やサービスの追加に伴って、Google によって自動的に権限が更新されるため、メンテナンス性にも優れています。

たとえば以下のようなロールがあります。

  • roles/compute.admin（Compute Engine 管理者）
  • roles/storage.objectViewer（Cloud Storage オブジェクトの読み取り）
  • roles/pubsub.publisher（Pub/Sub にメッセージを発行）

同一のユーザーに対して複数の事前定義ロールを割り当てることも可能です。
これらのロールは、必要な操作だけを許可する最小権限の設計がしやすいため、セキュリティ面でも最も推奨される方法です。

カスタムロール

カスタムロールは、必要な権限だけを組み合わせて、自分で作成できる IAM ロールです[3]。
事前定義ロールを使っていると、「このロールだと少し権限が多すぎる」「逆に欲しい操作ができない」といったことがあります。
そういった場合に、本当に必要な権限だけを割り当てたいときに活躍するのがカスタムロールです。

たとえば以下のようなケースで有効です。

  • BigQuery のクエリ実行だけ許可したい
  • Pub/Sub の読み取りだけに限定したい

ただし、どの権限が何に影響するのか、挙動をよく理解して使う必要があるため、IAM の操作にある程度慣れてから利用するのが安心です。

カスタムロールの特徴と注意

カスタムロールの特徴は以下のものがあります。

  • 組織単位またはプロジェクト単位で作成できる
  • 組織およびプロジェクトごとに最大 300 個まで作成できる
  • 作成したロールは作成元の組織／プロジェクト内でのみ使用でき、他の環境では利用できない

カスタムロールの注意点は、Google が自動的に更新してくれるわけではないということです。
たとえば、サービスがアップデートされて新しい権限が追加された場合でも、カスタムロールには反映されません。
そのため、以下のような対応が必要です。

  • 定期的にロールの内容を見直すこと
  • 権限の追加・削除に備えたロール管理体制の構築

こうした性質を踏まえると、まずは 事前定義ロールを使って運用を開始し、どうしても要件に合わない部分が出てきた場合にのみカスタムロールを検討する、という流れが現実的です。

カスタムロールは柔軟で強力な反面、メンテナンスの手間も伴います。導入タイミングと運用ルールをしっかり設計することが、安全なアクセス管理につながります。

適切なロールを選ぶには？

それではどうやって適切なロールを選んだら良いのでしょうか。
IAM ロールを選ぶときに、もっとも大切なのは 「最小権限の原則（Principle of Least Privilege）」 を守ることです。
つまり、「このユーザー（またはサービス）には、この操作だけができればいい」という粒度で権限を設計しましょう。

以下のような順番で選ぶと、リスクを最小限に抑えた設定ができます。

  1. まずは事前定義ロールから探す
  2. 合うものがなければカスタムロールを検討する
  3. 基本ロールは、やむを得ない場合を除いて避ける

IAM のロール設計は、セキュリティや管理のしやすさに直結します。
プロジェクトの進行や組織の構成変更に応じて、定期的に見直すことも大切です。

IAM Recommender とは

IAM Recommender は、IAM 設計の“その後”を支える Google Cloud のアクセス権最適化ツールです。
IAM のロールは設計して終わりではなく、運用中に継続的な見直しが求められます[4]。

たとえば、「このロールは今も必要か？」「過剰な権限が与えられていないか？」といった疑問が出てきたとき、IAM Recommender がその判断を支援してくれます。
IAM Recommender は、こうした課題に対して以下のような提案を自動で行ってくれます。

  • 過去 90 日間の権限使用状況を分析し、不要な権限を検出する
  • 未使用ロールの削除提案
  • 権限を搾ったロールへの置換提案
  • 使用された権限だけを含むカスタムロールの提案

こうした情報は、Google Cloud Console の [IAM ページ] や [おすすめハブ] に表示されます。以下はその一例です。

IAM Recommenderのセキュリティ分析情報について
上記の画像は、Google Cloud Console の IAM ページにおける「セキュリティ分析情報」の表示例です。

このセクションでは、現在割り当てられているロールに含まれる権限のうち、どれだけが過剰かが数値で示されています。たとえば「9625/9625 件の過剰な権限」と表示されている場合、そのロールに含まれるすべての権限が過去 90 日間に一度も使用されていないことを意味します。

これは、IAM Recommender が「このロールは削除または見直しの対象になり得る」と判断したことを示しています。こうした情報は、IAM 運用を定期的に見直す際の重要な判断材料になります。

ロールの権限詳細
上記の画像は、IAM Recommender による「過剰な権限」の内訳を示した詳細画面の一部です。
どの権限が「過去 90 日間使用実績がない」のかを一覧で確認することができます。
このような一覧をもとに、不要な権限の削除や、より限定的なロールへの置換を検討することができます。

注意点として、これはあくまで「提案」であり、自動で適用されるわけではありません。
また、IAM Recommender を活用することで、「設計 → 割り当て → 見直し」という IAM 運用のサイクルを回しながら、最小権限の原則を長期的に維持することができます。

IAM Recommender によって表示される分析結果は、日々の運用負荷を軽減しながらセキュリティの維持に貢献してくれます。とくに中〜大規模なプロジェクトでは、誰にどんなロールを付与したかの把握が難しくなっていきますが、このツールを使えば 実際の使用状況に基づいてロールの過不足を可視化でき、属人化しやすい IAM 管理を仕組み化する一歩となります。

また、誤って過剰な権限を与えてしまっていたことに気づくきっかけにもなり、「意図しないリスクを抱えている状態」を早期に発見できるという意味でも、セキュリティと運用の両面に効果的です。

さいごに

IAM の設計は一度きりの作業ではなく、継続的な見直しが求められる領域です。
プロジェクトの規模が大きくなったり、チームの構成が変わったり、新しいサービスを導入したりするたびに、「誰にどのような権限を与えるべきか」という問いは必ず出てきます。

この記事では IAM の基本からロールの選び方、そして運用フェーズで効果を発揮する IAM Recommender までを紹介しました。
これらをうまく活用すれば、セキュリティとチームの生産性のバランスを保ったアクセス管理が実現できます。

特に IAM Recommender は、運用後の「権限、これで本当に大丈夫？」といった悩みに対して客観的な気づきを与えてくれます。設計から割り当て、そして見直しという IAM の運用サイクルを回すうえで、非常に頼もしい存在です。

もし IAM の設定が今あいまいな状態にあるなら、一度立ち止まって見直してみるのもよいタイミングかもしれません。
そして、この記事がその見直しのきっかけになれば、とても嬉しく思います。

脚注

  1. IAM の概要: https://cloud.google.com/iam/docs/overview?hl=ja#access-overview ↩︎

  2. ロールと権限: https://cloud.google.com/iam/docs/roles-overview?hl=ja ↩︎

  3. カスタムロールを作成する: https://cloud.google.com/iam/docs/creating-custom-roles?hl=ja#creating ↩︎

  4. ロールの推奨事項の概要: https://cloud.google.com/policy-intelligence/docs/role-recommendations-overview?hl=ja ↩︎

Discussion