Cloud IAM Google Cloud

※この投稿は米国時間 2022 年 7 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。

Cloud IAM とは

Cloud IAM は、Google Cloud で誰がどこで何をできるかを定義するのに役立ちます。クラウド リソースを一元管理するためのきめ細かなアクセス制御と可視化を実現します。

IAM ポリシーは、Google Cloud リソースのアクセス制御を管理します。これらは IAM バインディングのコレクションであり、それぞれがプリンシパル、ロール、リソース（ポリシーが関連付けられているリソース）を「バインディング」しています。一般に認可グループと考えられているものが Google Cloud の IAM バインディングに相当します。すなわち、特定のリソースまたは階層ノードにバインドされた、ID グループとロールの結合です。バインディングのプリンシパルは次の通りです。

• 組織ドメイン（組織のすべてのメンバーにロールが付与される）

• Workspace と Cloud Identity ユーザー

• Workspace と Cloud Identity グループ

• サービス アカウント（後で説明）

IAM ロールは、関連するきめ細かい権限のセットをグループ化したものです。IAM には、基本ロール、事前定義ロール、カスタムロールの 3 種類のロールがあります。

• 基本ロールは、理解や適用が容易で、幅広い権限や範囲を含む。たとえば、オーナーには編集者のアクセス許可が含まれる。

• 事前定義ロールは、「ユーザーが使用を許可されているサービス」とのモデルに適切にマッピングしやすい。このロールは、サービスごとの許可範囲を狭めるもので、少し手間がかかるが、プリミティブな基本ロールよりも安全である。

• カスタムロールは、組織、プロジェクト、またはサービスレベルで、カスタム定義された権限範囲を定義できる。これは最も安全なオプションであるものの、依存関係や更新を管理するためにかなりの保守作業が必要になる。

IAM Conditions: IAM ポリシーは、リソースやリクエストの属性に基づく条件と結びつけることもできる。これにより、以下のようなユースケースが可能になります。

• 時間制限のあるアクセス: 業務時間内のみアクセスを許可する。

• リソースのサブセットへのアクセス: 「webapp-frontend-」という接頭語を持つ VM のみにアクセスを許可する。

• ネットワーク アドレス空間: 企業ネットワークからのアクセスのみを許可する。

また、IAM Conditions では、ロールの割り当てや取り消しをきめ細かくコントロールできます。実際には、ユーザーがプロジェクトで使用できるサービスを（IAM ロールによって）一元的に管理しながらも、各チームがプロジェクトで直接権限を管理できるように自律性を与えることを意味します（ただし、その権限が承認済みのサービスである場合です）。

IAM Conditions は、セキュアタグにも対応しています。タグは、組織レベルで定義されるアクセス制御された Key-Value リソースで、階層ノード（組織、フォルダ、プロジェクト）に関連付けることができます。ノードに関連付けたタグを IAM Conditions に設定することで、ロールの割り当てのスコープを関連するノードのみに制限できます。

Cloud IAM のベスト プラクティス

Cloud IAM を使用する場合、IAM ポリシーをグループを使用して機能的なアイデンティティにマッピングする必要があります。

• 個々の ID グループを職務上の IAM ロールセットの割り当て先として使用して、権限のスコープと境界（組織、フォルダ、プロジェクト、リソース）を明確に定義する。

• グループを使用して、オンプレミスのワークフロー（ネットワーキング、DevOps など）のミラーリング、新しいクラウド固有のワークフローへのマッピングを行う。

• グループを信頼できる情報源から同期させ、その参加 / 離脱プロセスを共有できる。

• グループ名の命名規則を定義し、適用する。

• フォルダを活用し、IAM ポリシーが適用されるポイントを最小化する。

• 複数のチームの間で共有されるチーム横断的な職務がある場合は、グループをネストできる。

• オプションで、iam.allowedPolicyMemberDomains 組織のポリシーによるドメイン メンバーシップの適用が可能。

サービス アカウントとは

サービス アカウントは、アプリケーションやサービスによって使用される特別なタイプのアカウントです。Google Cloud の API やサービスへの人間以外のアクセスは通常、サービス アカウントを使用して行われます。他のリソースと同様に、プロジェクト内で作成し、管理されます。一般的にサービスで使用されるため、関連するパスワードを持たず、ブラウザや Cookie でログインすることもできません。

認証には、秘密鍵と公開鍵のペア（Google 管理または顧客管理）か ID 連携が使用されます。

サービス アカウントの種類

サービス アカウントの種類によっては、Google Cloud サービスに組み込まれているものもあります。

• ユーザー管理型: お客様が作成し、他のすべてのリソースと同様に管理。IAM ロールはデフォルトでは割り当てられない。鍵、VM 関連付け、またはなりすましで使用可能。

• サービスのデフォルト: API 起動時に作成。カスタマー サービス アカウントが選択されていない場合、デフォルトで使用される。たとえば、Compute Engine には、VM 用のデフォルトのサービス アカウントがある。これらは固定の命名規則があり、作成時に編集者の IAM ロールが割り当てられる。

• Google 管理型（ロボットやサービス エージェント）: API 起動時に作成。Google Cloud サービスがお客様のリソースに対してアクションを実行するために使用されるため、特定の IAM ロールが割り当てられて作成される。Compute Engine のロボット アカウントは、Google が管理するサービス アカウントの一例である。

サービス アカウント認証情報

サービス アカウントの認証情報を管理し、アクセスする方法はさまざまです。

Google 管理の鍵: 鍵ペアの一般公開部分と秘密部分の両方が Google Cloud に保存され、自動ローテーションされ、セキュリティが確保されています。使用するには、サービス アカウントを VM またはその他のコンピューティング サービスに関連付けるか、別の ID から権限を借用します。

ユーザー管理の鍵: お客様が顧客として、一般公開部分と非公開部分の両方を所有し、ローテーションとセキュリティに責任を持ちます。鍵ペアは Google Cloud で作成することも、外部で作成して公開部分を Google Cloud にアップロードすることもできます。

信頼されたアイデンティティに対してリソースへの限定的なアクセスを許可する必要がある場合、短期間のみ有効な認証情報を使用することがベスト プラクティスです。

サービス アカウントのベスト プラクティス

• ワークフローの観点から、デフォルトのサービス アカウントはアクセス許可が容易（例: プロジェクト編集者）。アプリごとにアカウントを作成し、必要な権限のみを付与することが好ましい。

• サービス アカウントをファイアウォールを適用するアプリケーションを選択するために使用可能。たとえばサービス アカウント「webapp-fe」の VM に対してポート 443（HTTPS）を開放する。

• 専用プロジェクトにサービス アカウントを作成し、一元管理する。

• ユーザー管理の鍵のセキュリティ リスクには、悪意を持って鍵を公開すること、誤って鍵をコードに埋め込んで公開することがある。このリスクを軽減するために、鍵のローテーションを頻繁に行うようにする。

• VPC Service Controls は、Google Cloud サービスにアクセスできる人を制限するのに便利（これがサービス アカウントが役立つ理由である）。たとえば、オンプレミスの IP 範囲からのアクセスのみ許可する場合がある（相互接続時）。このようなアクセス制限を導入することで、攻撃対象領域を最小化できる。

• さらにプロアクティブなアプローチとして、ローテーションが必要な古い鍵に関するアラートを Forseti で設定する。

以上、Google Cloud における Cloud IAM とサービス アカウントを使った認可について簡単に説明しました。詳細については、Google Cloud のセキュリティ基盤に関するホワイト ペーパーをご覧ください。  #GCPSketchnote をさらにご覧になるには、GitHub リポジトリをフォローしてください。同様のクラウド コンテンツについては、Twitter で @pvergadia をフォローしてください。thecloudgirl.dev もぜひご覧ください。