迷いがちな IAM: Google Cloud における ID の入門ガイド

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

ID とアクセスの管理（IAM）は、最初はなだらかな丘のように見えるかもしれません。ログインやパスワードの割り当て、組織における職務に基づくアクセス制御の付与など、管理自体はそれほど難しくないからです。しかし、IAM の構成を進めていくにつれ、そのなだらかな坂道が変化し、突然、急な山の斜面のように感じられることがあります。そして、専門用語や概念が折り重なって、足元から滑り落ちていきます。クラウドにおけるセキュリティの境界は、重要な ID の概念を理解することが基本となるため、これは深刻な問題です。

足元をしっかり固めるために、まず、IAM のアクセス制御の 2 つの基本原則、すなわち、最小権限と職掌分散の概念を理解することから始めましょう。これらは混同されがちですが、明確に異なります。最小権限は、タスクを実行するために必要な最小限の権限のみを割り当てるという考え方で、職掌分散では、これらの権限を職務責任ごとに分離することが求められます。

どちらも、クラウド環境でネガティブな行為が行われた場合の影響を軽減することを目的としています。エベレストの登山隊のなかにもさまざまな役割があるのと同じことです。登山隊のなかにはガイド数名と、さらに少数の登山隊のリーダーがいます。職務によっては責任が重複しているかもしれませんが、ガイドのような特定の仕事は、登山者を山の頂上まで連れて行くことに特に重点を置いています。

たとえば、個人を危険にさらす可能性のある作業を、適当に選んだ一介の登山者に指揮させるのは望ましくありません。そうした作業は、経験豊富な登山隊のリーダーに指揮を執ってもらうことが望ましいでしょう。

アクセス制御の頂点を極める

それでは、アクセス制御の山を登り始めましょう。最小権限と職掌分散の概念をサポートする IAM アーキテクチャを構築するには、組織内のメンバーに ID をマッピングする必要があります。

これは当たり前のことのように見えるかもしれませんが、ペルソナ、プリンシパル、グループ、ロール、許可ポリシー、拒否ポリシーといった用語からは、並大抵のことではない印象を受けるかもしれません。しかしこれらの言葉が何を意味するのか、もう迷う必要はありません。これらの用語をわかりやすく説明し、ベースキャンプから登頂できるようお手伝いします。

Google Cloud で IAM を構成する際に理解する必要がある用語を確認していきましょう。

プリンシパル: Google Cloud のリソースに対してアクションを実行するためにアクセス権を必要とするもの。アクセス権を必要とするものには、エンドユーザーやサービス アカウント、グループ、Google Workspace アカウント、リソースにアクセスできる Cloud Identity ドメインなどがあります。この用語は、「プリンシパルはクラウドのパル（相棒）」とすると覚えやすいかもしれません。

ロール: リソースへのアクセスを許可する権限の集合。

ポリシー: リソースにアタッチされたロールの集合。ポリシーは、プリンシパルによるリソースへのアクセスを許可または拒否します。

グループとペルソナについても触れておきましょう。基本的にこれらは同じものですが、ペルソナは職務です。たとえば、プラットフォーム エンジニアやセキュリティ アナリストというペルソナがあるとします。組織内の人間をこれらの職務、すなわちペルソナにマッピングすると、これらのペルソナはグループになります。権限やロールはプリンシパルに直接割り当てるのではなく、グループに割り当てる必要があるため、このことは重要です。

IAM の管理: 頂点に立ち続ける

これらの概念を実際のシナリオに当てはめてみましょう。たとえば、あなたはスタートアップのプラットフォーム エンジニアとして、最初に各個人のニーズに基づいて権限（ロール）を手動で個人に割り当てます。この場合、全員に「編集者」の権限を与える方が簡単そうなので、基本ロールを使用するかもしれません。

このアプローチはチームが小さいうちはうまく機能しますが、会社が成長してアクセス制御の要件が増えるにつれ、権限の管理も複雑になっていきます。新しい従業員が加わり、チームが再編成され、責任も変わっていきます。このような変更に手作業で対応しようとすると、すぐに悪夢にうなされることになります。最小権限と職掌分散を実現しようとしている場合はなおさらです。

IAM アーキテクチャでこのようなスケーラビリティの課題に対処するには、ペルソナ マッピングが役に立ちます。個々のプリンシパルに焦点を当てるのではなく、組織図の職務に基づいてグループを作成します。たとえば、デベロッパー、プラットフォーム エンジニア、データ サイエンティスト、セキュリティ エンジニアなどのグループを作ります。各グループには、特定のタスクを実行するために必要なロールを割り当てます。

ロールをグループに関連付けることで、管理が簡素化され、同じような職務のユーザーに対して一貫したアクセス権を付与できます。ここで、ソフトウェア エンジニアの Varsha さんが、Google Cloud でホストされているウェブ アプリケーションをデプロイするためのアクセス権を必要としているシナリオを考えてみましょう。ペルソナ マッピングを使用すると、IAM ワークフローは以下のようになります。

1. ペルソナの特定: Varsha さんを、Cloud Run を使用してデプロイされたウェブ アプリケーションのソフトウェア エンジニアに分類します。

2. グループの割り当て: このウェブ アプリケーションのソフトウェア エンジニアを、「web-app-developer」グループにマッピングします。

3. 適切なロールの付与: 「web-app-developer」グループに「Cloud Run デベロッパー ロール」を割り当て、Google Cloud 内の Cloud Run リソースに対して必要な読み取り / 書き込みアクセス権を付与します。

このアプローチにより、管理可能でスケーラブルなアクセス制御フレームワークを維持しながら、Varsha さんや他のソフトウェア エンジニアが必要とするアクセス権を割り当てることができます。さらに、ロールをグループに割り当てることで、IAM 構成の作成が自己文書化され、自動化により管理が容易になります。

要点をまとめると、IAM の構成要素を適切に使用することで可能になるのは以下のとおりです。

• 入社手続きの合理化: 新入社員を職務に基づいた適切なグループに追加するだけで、必要なアクセス権が自動的に付与されます。

• 管理オーバーヘッドの削減: グループレベルで権限を管理し、自己文書化された IAM アーキテクチャを作成することで、時間と労力を節約できます。

• セキュリティの強化: 同じようなロールに一貫したアクセス制御を使用することで、プリンシパルの権限を過剰にプロビジョニングするリスクを最小限に抑えることができます。

• 監査の簡素化: 職務に基づいてグループ名を明確に定義することで、アクセスの追跡や、潜在的な問題の特定がより簡単になります。

これらの基本概念を理解し、ペルソナ マッピングなどの手法を使用することで、険しい山だった IAM をなだらかな丘に戻すことができます。そして組織は、スケーラブルで適応性が高く組織とともに成長する IAM アーキテクチャを使用して、クラウドにおけるより適切なアクセス制御の道を進んでいき、ID ファーストになるでしょう。

IAM の構成要素の詳細については、こちらのドキュメントや、Google Cloud のアーキテクチャ フレームワークの「セキュリティ、プライバシー、コンプライアンス」カテゴリにある ID とアクセスの管理のセクションをご覧ください。また、このモジュール化された自己文書化アプローチへの移行を支援する IAM Policy Intelligence ツールもぜひご参照ください。

ー Google、シニア デベロッパーリレーションズ エンジニア Sita Lakshmi Sangameswaran

ー Google、スタッフ クラウド セキュリティ アドボケイト Michele Chubirka