🔊 Play

GCPで作業を進める上で、最も重要と言っても過言ではないのが「IAM（Identity and Access Management）」です。これは、GCPのリソースに対する「アクセス権」を管理する仕組みのことです。簡単に言えば、**「誰が（プリンシパル）」「何に（リソース）」「何ができるか（ロール）」**を細かく設定するためのセキュリティの要となります。

例えるなら、IAMはあなたの会社のセキュリティシステムです。

• 誰が（プリンシパル）: 会社の従業員や、特定の業務を代行するロボット
• 何に（リソース）: 会社の部屋、書類棚、特定のプロジェクトの資料
• 何ができるか（ロール）: その部屋に入れる、書類を閲覧できる、資料を編集できる、など

セキュリティはクラウドでも非常に重要なので、この章はしっかり理解しておきましょう。

1. 誰が？：プリンシパル（Principals）

「誰が」GCPのリソースにアクセスできるのか、その「人」や「実体」をGCPでは**「プリンシパル」**と呼びます。主なプリンシパルは以下の通りです。

• Google アカウント（ユーザー）:
  • 一番身近なのがこれ。あなたのGmailアドレスのような個人のGoogleアカウントです。例えば、your-name@gmail.com や、会社で利用している your-name@your-company.com のようなアカウントです。
  • 個人の開発者や、特定のユーザーに直接権限を付与する場合に使います。
• サービスアカウント（Service Accounts）:
  • これは**「GCP上のプログラムやサービス自身」**のための特別なアカウントです。人間ではありません。
  • 例えば、あるWebアプリケーションがデータベースにアクセスしたり、仮想マシンがCloud Storageにファイルをアップロードしたりする際に、このサービスアカウントの「身分」を使ってGCPのリソースにアクセスします。
  • 人間がパスワードを入力するように、プログラムにパスワードを直接埋め込むのはセキュリティ上良くないので、サービスアカウントを使うのがベストプラクティスです。
• Google グループ:
  • 複数のGoogleアカウントをまとめて管理するためのグループです。
  • 例えば、「開発チーム」というGoogleグループを作り、そのグループに権限を付与すれば、グループ内の全てのメンバーが同じ権限を持つことになります。メンバーの入れ替えがあった場合も、グループのメンバーリストを変更するだけで済むので、個々に権限を付与するよりも管理が楽になります。
• Google Workspace または Cloud Identity ドメイン:
  • 会社全体など、GCPを利用している組織の全てのユーザーに一括で権限を付与したい場合に利用します。

2. 何に？：リソース（Resources）

「何に」対してアクセスを許可するのか、その対象となるものを**「リソース」**と呼びます。GCPのリソースは階層構造になっています。

• 組織（Organization）:
  • GCPの最も大きな単位で、企業全体を表します。全てのGCPプロジェクトはこの組織の下にぶら下がります。組織レベルで設定した権限は、その下の全てのフォルダ、プロジェクト、リソースに継承されます。
• フォルダ（Folders）:
  • 組織の下に作れる、プロジェクトをまとめるための論理的なグループです。部署ごとや環境ごと（開発、本番など）にプロジェクトを整理するのに便利です。フォルダに設定した権限は、その下のプロジェクトやリソースに継承されます。
• プロジェクト（Projects）:
  • 前回の説明で出てきた、GCPにおける作業の基本単位です。ほとんどのリソースはプロジェクトの中に作成されます。
• リソース（個別）:
  • プロジェクト内にある個々のサービス（例: Compute Engineの仮想マシン、Cloud Storageのバケット、Cloud SQLのインスタンスなど）

権限は、この階層の上位から下位へ継承されます。例えば、プロジェクトに対して「閲覧者」の権限を与えると、そのプロジェクト内の全ての仮想マシンやストレージも「閲覧」できるようになります。

3. 何ができるか？：ロール（Roles）

「何ができるか」を定義するのが**「ロール（役割）」です。ロールは、特定のGCPリソースに対して許可される「権限（Permissions）」**の集まりです。

• 権限（Permissions）:
  • 「compute.instances.start」（Compute Engineのインスタンスを起動する）や「storage.objects.get」（Cloud Storageのオブジェクトを取得する）のように、個々の具体的な操作を許可するものです。
• ロール（Roles）:
  • これらの個々の権限が、特定の役割に合わせて事前にまとめられています。
  • 基本的なロール:
    • オーナー（Owner）: プロジェクト内の全てのリソースに対する全権限を持ち、他のユーザーに権限を付与することもできます。非常に強力な権限なので、付与は慎重に！
    • 編集者（Editor）: リソースの作成、変更、削除など、ほぼ全てのリソース操作ができますが、他のユーザーに権限を付与することはできません。
    • 閲覧者（Viewer）: リソースの情報を閲覧することのみができます。変更や削除はできません。
  • 事前定義ロール（Predefined Roles）:
    • GCPがサービスごとに予め定義している、特定の役割に特化したロールです。例えば、「Compute Engine インスタンス管理者」や「BigQuery データ閲覧者」、「Storage オブジェクト作成者」など、数千種類ものロールがあります。通常はこれらのロールを使用することが推奨されます。
  • カスタムロール（Custom Roles）:
    • 事前定義ロールでは満たせない、より細かく特定の権限のみを許可したい場合に、自分で権限を組み合わせて作成するロールです。
    • これは、本当に必要な最小限の権限のみを付与する「最小権限の原則（Principle of Least Privilege）」を実践するために非常に役立ちます。

IAM ポリシー：権限の設定方法

これらの「プリンシパル」「リソース」「ロール」の組み合わせを「IAMポリシー」と呼びます。GCPの各リソースには、このIAMポリシーが設定されています。

• ポリシーの構成:
  • 「Aさん（プリンシパル）は、このプロジェクト（リソース）で、閲覧者（ロール）の役割を持つ」
  • 「Webサーバーのサービスアカウント（プリンシパル）は、特定のCloud Storageバケット（リソース）に対して、オブジェクト作成者（ロール）の役割を持つ」

あなたはGoogle Cloud コンソールの「IAM」セクションから、これらの設定を簡単に行うことができます。

まとめ：IAMの重要性

IAMは、GCPを安全に利用するための基盤です。

• 誰が何をできるかを明確にすることで、不正アクセスや誤操作を防ぎます。
• 特にサービスアカウントの利用は、アプリケーションのセキュリティにおいて非常に重要です。
• 「最小権限の原則」に従い、必要最小限の権限のみを付与するように常に心がけましょう。これにより、万が一アカウントが不正利用されても、被害を最小限に抑えることができます。

最初のうちは少し複雑に感じるかもしれませんが、実際にプロジェクトを作成し、チームメンバーやサービスアカウントに権限を付与する経験を重ねるうちに、IAMの概念は自然と身についていきます。GCPの安全な運用には不可欠な知識ですので、じっくりと学んでいきましょう！