コンテンツに移動
セキュリティ & アイデンティティ

IAM: リソース階層を使った冒険

2023年6月19日
Google Cloud Japan Team

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

パブリック クラウドでの初プロジェクトでその使い方を学ぶことは、秘境の迷宮で宝探しをしたり、火を噴くドラゴンと戦ったりするようなものです。覚えるべき専門用語や、理解すべき数式など、沼にはまる要素はいくらでもあります。しかし、新しい景色の中で進路を見極める作業は、ある意味、未知の世界への胸躍る冒険でもあります。

安全に旅をし、盗賊や(デジタルの)魔術師からリソースを確実に守る術はあります。歩を進めるに従って、強力な IAM(Identity and Access Management)ポリシーによってプロジェクトやリソースを守る必要性を感じることでしょう。さもなければ、そこは卑劣な盗賊の無法地帯と化します。

では、とにかくそこに飛び込んで、細かいことは後で考えればよいのでしょうか。もちろん「手探りで進む」アプローチを使う手もないわけではないですが、石城を建設する前に、土台となるアーキテクチャをしっかりと検討しておきたいと思われるのではないでしょうか。さもないと、出来上がった城が沼に沈みかねません。最悪の場合、火事になって崩れ落ちてから、沼に沈むというシナリオもありえます。このような事態は誰もが回避したいと思うはずです。重要なのは、クラウド リソースを整理するためのメンタルモデルを用意し、これらのリソースを確実に守れるようにすることです。

Google Cloud のリソース階層を使って、信頼の境界線を作る

まず最初に、組織がどのように機能しているかをよく把握し、それをクラウドのツリー階層にマッピングする必要があります。たとえば、最上位が組織全体で、その下に事業部門が、そのさらに下に部署や課があり、最下位に各種チームが位置付けられる、といった構造です(この最下位レベルにプリンシパルがいます)。このような組織構造をクラウドの階層に落とし込む必要があります。そうすることで、ID 管理によるアクセス制御がはるかにシンプルになります。

架空の大陸である中つ国をリソース階層の要素に当てはめた例をご覧ください。重要なリソースへのアクセス制限がはるかに簡単になることがおわかりいただけるでしょう。

https://storage.googleapis.com/gweb-cloudblog-publish/images/LOTR_resource_hierarchies1.max-1700x1700.jpeg

フォルダを使用するメリット

フォルダは、環境間に境界線をひき、互いを分離するために便利です。この境界線は、いわば、リソースという領地を仕切る壁、山、川のようなものです。リソース階層は、事業部門を分けるだけでなく、ビジネスルールを反映させるためにも使用できます。たとえば、本番環境と非本番環境を異なるフォルダに分けることができます。また、規制対象の環境を切り出して、そこに含まれるリソース一式について集中的にコンプライアンス要件に取り組むことも可能です。

この構造においてどこにリソースを置き、リソースへのアクセスをどのロールに許可すべきかをよく検討しましょう。誰もが女王(クラウド管理者)になれるわけではありません。小公国の公爵や伯爵のごとく、限定された権限で我慢しなければならないユーザーもいます。また、境界線を設けることは、領土侵害ならびにそれに伴う混乱や内戦を回避するためにも効果的です。誰もが自らの領域を把握していれば、管理者はクラウド王国全体で平和が保たれていると安心できます。

組織構造にマッチした階層を作成することで、セキュリティ問題が発生した場合にその波及範囲の封じ込めも簡単にできるようになります。具体的には、「最小権限と職掌分散」に基づいて、グループ化したロールに対して権限を割り当てるようにします。リソース階層を使用すれば、権限を簡単に委任でき、個々のプリンシパルやロールに権限を割り当てる手間を省けます。このアプローチは、クラウド(中つ国)において、アクセス制御やリスク軽減のために ID がいかに重要であるかを示しています。

https://storage.googleapis.com/gweb-cloudblog-publish/images/LOTR_resource_hierarchies_detail2.max-1800x1800.jpeg

なお、リソース階層ではアクセスが継承されるという点にご注意ください。組織全体で、特定の役職にグローバルに適用すべき制限があるかどうかを検討しましょう。たとえば、マーケティング担当者にはアクセスを許可し、技術担当者にはアクセスさせたくないようなリソースはありませんか?リソース階層はデフォルトで推移的継承を行います。したがって、権限を継承したプリンシパルのアクセス権を取り消すには、明示的に指定する必要があります。

ランディング ゾーンによって労力を削減

自分でゼロから構築する必要はありません。設計や実装が大変に感じるなら、Google Cloud のアーキテクチャ センターでランディング ゾーンという設計コンセプトを提供していますので、ご利用ください。

ランディング ゾーンとはモジュラー型のアーキテクチャ パターンであり、安全なクラウド インフラストラクチャを構築するための構成の指針を示します。ランディング ゾーンには、ID、リソース階層、ネットワーキング、セキュリティなど、アーキテクチャのさまざまな側面が含まれています。ランディング ゾーンを使うことで、組織の目の前のニーズを満たすのはもちろん、将来的なスケーリングにも対応可能な、よく考え抜かれた設計のアーキテクチャを作成することができます。  

手短かに言うと、リソース階層の使用を始めるには、以下が必要になります。

Google Cloud の堅牢な ID 管理機能を使って、クラウド インフラストラクチャのセキュリティ改善にさっそく乗り出しましょう。新たなクエストの始まりであれ、既存の領土に安全や平和をもたらしたい場合であれ、リソース階層を使うことで、あなたのインフラストラクチャ王国を発展させることができます。ID ベースの強力なアクセス制御を取り入れて、安全性重視の設計というミッションを達成しましょう。


- Google Cloud、セキュリティ アドボケイト Michele Chubirka
- Google Cloud、デベロッパー リレーション エンジニア Max Saltonstall

投稿先