皆様、こんにちは！
アイレット株式会社 DX開発事業部の楊林と申します。
前回の投稿では、クラウドリソースの階層構造や、リソース管理に関わる割り当て・ラベル・課金について紹介しました。
では実際にリソースを運用する際、どのように安全性を確保すればよいのでしょうか。
今回は、Google Cloud のアクセス管理の基本となる IAM を取り上げます。
IAMとは
IAM（Identity and Access Management）は、Google Cloud 上で「誰が・どの操作を・どのリソースに対して行えるか」を定義する仕組みです。
ここでいう「誰」とはアクセスを行う個人、グループ、またはアプリケーションを指します。
「どの操作」とは特定の権限や操作のことです。
「どのリソース」とはアクセス先となる任意の Google Cloud サービスです。
メンバー
リソースに対して操作を行う主体を IAM では「メンバー」と呼びます。
Google Cloud には次の5種類のメンバーがあります。
Googleアカウント
開発者や管理者、その他 Google Cloud を操作するユーザーを指します。
このアカウントに紐づくメールアドレスが ID として使用されます。Gmail を使わなくても Google アカウントとして利用可能です。
また、Google Cloud ではシングルサインオン（SSO）認証を利用できます。既存の ID システムがある場合は、SSO を構成することで同じ仕組みを継続して使えます。
サービスアカウント
個々のユーザーではなく、アプリケーションやサービス用に作成するアカウントです。
Googleグループ
Google アカウントやサービスアカウントの集合に名前を付けたもので、固有のメールアドレスを持ちます。
グループを使うと、ユーザーの集合に対して IAM をまとめて適用できます。
Google Workspace
組織の Workspace アカウントで作成された全 Google アカウントの仮想的なグループです。
Workspace ドメインは組織のインターネットドメインを表し、ユーザーを追加すると新しいアカウントがその仮想グループに含まれます。
Cloud Identityドメイン
組織内のユーザーやグループを Google アカウントとして管理するためのドメインです。
Workspace と異なり、Gmail や Drive、ドキュメントといったコラボレーション機能は付属していません。
必要なユーザー管理だけを行いたい場合や、既存のメールシステムを使い続けたい組織が利用します。
ロール
権限の集合をロールと呼びます。
メンバーにロールを付与すると、そのロールに含まれるすべての権限が与えられます。
Google Cloud には次の3種類があります。
基本ロール
対象範囲が広く、大まかなレベルの権限を提供するロールです。
プロジェクトに適用すると、プロジェクト内すべてのリソースへ影響します。
基本ロールは次の4つで、権限の違いは以下の表の通りです。
| 権限 | オーナー （Owner） |
編集者 （Editor） |
閲覧者 （Viewer） |
課金管理者 (Billing Admin) |
|---|---|---|---|---|
| リソースを確認 | 〇 | 〇 | 〇 | 〇 |
| リソースを編集 | 〇 | 〇 | × | × |
| 関連つけられた ロールと権限を管理 |
〇 | × | × | × |
| 課金情報の設定 | 〇 | × | × | 〇 |
事前定義ロール
各 Google Cloud サービスが独自に定義しているロールです。
権限と適用範囲があらかじめ決められており、細かい権限制御が可能です。
カスタムロール
より細かい権限設定が必要な場合に作成されるロールです。
カスタムロールを作成するには次の2点を注意する必要があります。
まずカスタムロールの権限の管理が必要で、組織によっては事前定義ロールの使用を優先する場合もあります。
そしてカスタムロールは組織レベルまたはプロジェクトレベルにのみ適用でき、フォルダーレベルには適用できません。
ポリシー
ポリシーは、メンバーをロールに紐づける「バインディング」の集合です。
リソース階層に従って、親リソースのポリシーは子リソースに継承されます。
この継承は一方向で、子リソース側から親の権限を制限することはできません。
階層を変更すると、ポリシーの継承関係も変わります。
リソースポリシーで利用できる権限は、親と子の権限の和集合です。親の制限が緩い場合は、親ポリシーが優先されます。
ポリシー設計では「最小権限の原則」に従うことが推奨されます。
ID・ロール・リソースそれぞれについて、必要最小限のスコープを選択することでリスクを抑えられます。
また、ポリシーは権限の許可だけでなく拒否も定義できます。
拒否ポリシーは付与されたロールより優先され、特定の権限を確実に禁止できます。
拒否ポリシーも階層構造に従って継承されます。
組織に必要な制限をまとめて構成するものは組織ポリシーと呼ばれます。
組織ノードやその配下のフォルダ、プロジェクトに適用でき、子孫リソースはそれを継承します。
例外を設定することも可能ですが、組織ポリシー管理者のロールが必要です。
最後に
今回は、Google Cloud におけるアクセス管理の基礎である IAM について簡単に紹介しました。
次回は、今回触れきれなかったメンバーの種類についてもう少し詳しく説明します。ぜひ続けて読んでみてください。
以前の投稿
【Google Cloud入門】クラウドサービスの特徴とGoogle Cloudの触り方
【Google Cloud入門】リソースマネージメント