サービス、データ、インフラストラクチャが企業が入っているビルを離れ、人間と人間以外の両方のアイデンティティが、あらゆる方法でリソースにアクセスするようになり、かつては見慣れた景色だったプライベートの領域が突如として、クラウド、サービス、ユーザ、APIで埋め尽くされた、混雑した都市になりました。これは、我々の目と鼻の先にある、クラウドのパーミッションの隠された世界であり、変化し続ける未知の世界です。

代表的な3つのクラウドインフラストラクチャ環境であるAmazon AWS、Google Cloud、Microsoft Azureは、主にマシンや「アプリケーション」などのその他のコンピュート、さらには個々の機能も含む広義の「アイデンティティ」の概念を導入することで、広範囲に対応する、アイデンティティとアクセスの複雑なモデルを提供しています。既存のエンタイトルメントモデルをクラウドに瞬間移動しようとすると、ITセキュリティや運用のチームが大きな課題に直面することになります。その課題の最大の問題は、人間の労力では解決できないほど複雑で大規模である点にあります。

I-Robot

クラウドエンタイトルメントモデルの興味深い概念の1つが、人間以外のアイデンティティです。「旧世界」でアプリケーションやアプリケーションコードを実行するマシンがリソースにアクセスする必要がある場合、そのアプリケーションやマシンに管理者の認証情報が付与されるのは当たり前のことでした。結果として、多くのマシンに管理者の認証情報が保存され、過剰な権限が付与されていました。しかしながら、「誰に管理者権限があるか」という問いの答えは、「これらのマシンやアプリケーションにアクセスできる全員」というシンプルなものでした。

クラウドファーストの世界では、エンタイトルメントシステムでマシンやアプリケーションが独自のアイデンティティを所有しており、（直接または想定される役割を通じて）独自のアクセス権限を付与されるべきです。マシン（またはアプリケーション）は、インスタンス化にあたって基底となるインフラストラクチャによって識別され、「認証」トークンが付与され、それを利用してAPIで特権を要求します。

これは、完全なアカウンタビリティの理論や最小特権アクセスモデルに適合する方法ですが、実際にはオペレータに対するペナルティを伴います。第一に、この移行により、管理対象のアイデンティティの数が突如として増加しました。すなわち、アプリケーションやマシンのアイデンティティの数が人間のアイデンティティの数に比例しない可能性があります。IT部門の数十人の従業員のエンタイトルメントを管理していたセキュリティグループが一瞬にして、（マイクロサービス環境などで）数百、数千のマシンやアプリケーションのアイデンティティを管理することになる可能性があります。

アプリケーションやマシンのアイデンティティに付与された不適切または過剰な特権の影響は多くの場合に、手遅れになった後に明らかになります。つまり、マシンやアプリケーションコードに対する何らかのアクセス権がある人（マシンへのログイン認証情報がある個人やアプリケーションにコードを追加する権限があるプログラマなど）は、そのマシンやアプリケーションの特権をすべて利用（または悪用）することができます。そのため、限定的な権限がある従業員のアカウントの侵害のように一見すると小さい問題のように思えるインシデントが、あっという間に大規模な大量ブリーチに発展します。さらには、これらのアイデンティティのエンタイトルメントは、人間のアイデンティティよりはるかに困難であることがわかりました。後者の場合、少なくともその人物にニーズやアクセス要件を問い合わせることができますが、2年間に複数の所有者やプログラマが何度も改訂を繰り返してきたマシンやアプリケーションで同じことをするのは困難です。

クラウドエンタイトルメントの隠れた世界

クラウドエンタイトルメントの世界は、奇妙な新しい概念に満ちています。すべてのサービスやサブサービスに様々な独自のオブジェクトタイプ、専門用語、セマンティクスがあり、それぞれのエンタイトルメントの意味や意義を理解するのは非常に困難になります。さらに悪いことに、モデルと命名規則が大きく（おそらくは意図的に）異なります。

例えばストレージの場合、Amazon AWSには、S3、Glacier、RDS、DynamoDB、さらにはEBSなどの複数のストレージサービスがあり、それぞれに意味合いが異なる権限のセットが付与されています。個々のサービスに限定したとしても、本当の意味のアクセスポリシーを理解するのは至難の業でしょう。S3に注目すると、バケットそのものにバケットポリシーが添付された複雑なモデルであることがわかります。さらには、これらのIAMポリシーがS3オブジェクトを参照する場合がありますが、バケットそのものの一部ではなく、当然ながら、バケット内のサブリソースであるバケットACLやオブジェクトACLの一部です。以上を考慮すると、Amazon AthenaをS3データへのSQLアクセスに使用できることがわかり、Athenaの特権というまったく新しい世界を理解しなければならないことがわかります。混乱や困難は、S3ドメインに限ったことではありません。EBSボリュームの作成、クローニング、マウント、アンマウントが可能なアイデンティティは、データにアクセスするだけでなく、マシンを乗っ取ることもできる可能性があります。そのため、このストレージボリュームの弾力的な世界で、どのアイデンティティに過剰な権限が付与されているかを理解するのは、複雑で知識を必要とする作業です。

クラウドのエンタイトルメントをオンプレミスのエンタイトルメントと同じように考えてしまうことも、混乱の一因です。例えば、S3バケットのアクセスポリシーのレビューにより、管理者が「Authenticated Users」グループにバケットをリストする権限や場合によっては書き込み権限まで付与する傾向があることがわかりました。管理者の意図は、このようなリソースへのアクセスを「Enterprise Users」に限定することであり、これは、オンプレミスで言うところの「Authenticated Users」に相当します。しかしながら結果として、任意のアカウントの任意のAWSユーザがバケットにアクセスできてしまいます。

完璧は善の敵である

すべてのクラウドベンダは、非常に詳細で明確なアプローチを採用して、自らの環境でアクセス特権を確立しています。それぞれの環境におけるアイデンティティは、個別に参照することも、グループとして参照することもできますが、そのグループを分離したり切り離したりすることはありません。アイデンティティはさらに、その人に割り当てられた役割を通じて間接的に参照されることもあります。特権は、事前に定義された特権のセット「コラボレーター」など）や特定のオブジェクトに対する個々の詳細なパーミッションとして表現されます。一部のサービスには、エンタイトルメントの基本構成に使用するシンプルなUIが含まれています。ただし、それと同時に、ほぼすべてのオブジェクト、サービス、アイデンティティ（またはそのグループ）を、非常にわかりやすい言語で記述されたポリシーのセットで装飾し、アイデンティティ、オブジェクト、オペレーションのほぼすべての識別子にワイルドカードを含めることができます。一部の環境（Amazon AWSなど）では、このようなポリシーにタグや条件を使用することを推奨していますが、このことがモデルをさらに複雑にしており、このことは、あるリソースへの特定の方法でのアクセスが許可されている一連のアイデンティティを理解する際の悪夢と言えるものです。クラウド環境のセキュリティプロフェッショナルは、侵害されたアイデンティティがもたらすリスクや脅威を理解したり、一連のリソースに対する脅威となる一連のアイデンティティをまとめたりするのに非常に苦労しています。

誰のコードなのか？

前述のように技術的な問題で事態が複雑化しているところに組織の進化が加わることで、状況はさらに悪化します。「オンプレミスの世界」では、リソース（コンピュータやデータストア）はIT担当者によって一元的にプロビジョニングされ、IT担当者は（通常は）アクセスコントロールやエンタイトルメントを定義する際に、（ITセキュリティチームによって指示された）中央のセキュリティポリシーに従うことになります。クラウドコンピューティングの世界では、DevOpsのパラダイムが支配しており、「すべてのプログラマが王様になれる」ことを意味します。やや大げさではありますが、この例えは現実の完全な誤りというわけではありません。

DevOpsの世界では、個々のアプリケーションの所有者（およびプログラマ）が、オブジェクトやコンピュートのプロビジョニングに責任を負い、合理的な（中央から指示された）セキュリティポリシーの適用にも責任を負うことになるでしょう。環境が弾力的に進化することは、ほとんどの場合に、プロビジョニングされる新しいオブジェクトやコンピューティングに関連する中央のポリシーが存在しないことを意味します（おそらくセキュリティ担当者がプロビジョニングされる新しい環境の設計に事前に関与していないため）。仮にそのようなポリシーがあったとしても、オブジェクトやコンピュートをプロビジョニングできるはずであるすべてのグループに配分する必要があります。もちろん、オブジェクトやコンピュートのプロビジョニングの担当者がそのようなポリシーを受け取ったとしても、それを機能させるには、（前のセクションで述べたように）エンタイトルメントの実装の複雑さにすべて精通している必要があります。

このような環境のエンタイトルメントをレビューしようとすると、作業を開始する段階では自らの過去の判断を見直そうと意気込んでいたセキュリティチームであっても、モデルの細かい要素をすべて収集するだけでなく、（環境の一部をプロビジョニングした）個人の分散するネットワークから情報を収集して、その理論的根拠をまとめるという難題に再び直面することになります。

大数の法則

「大数の法則」は実際には確率の用語ですが、人間は大量のデータを処理するのが難しいという意味で使われるべきでした。大量のデータだけでなく、特定の種類のデータ（複数のソースのエンタイトルメント情報など）の収集、組み立て、処理にも時間がかかり、このような問題の多数のインスタンスに直面すると、我々はたちまち、木を見て森を見ずになってしまいます。

今日のIT環境、特にクラウド環境で、膨大な数のオブジェクト、アイデンティティ、オペレーションをすべて手動で処理することはできません。これは、何らかの特権を付与する場合だけでなく、個人に対して付与されているアクセスやある対象への一連の脅威をレビューする場合にも当てはまります。中規模の環境で、アイデンティティ、オブジェクト、アクションの積が数百万の単位になると、適切なエンタイトルメントポリシーの導入が失敗するのは明白です。同様に、セキュリティチームが企業のエンタイトルメントポスチャの手動でのレビューでも、クラウド環境のミス、リスク、ポリシー違反を確実に発見することはできません。

Zscaler CIEMは、クラウドパーミッションの隠された世界を明らかにし、絶対的なパーミッションコントロールを提供します。すべてのクラウドプラットフォーム、サービス、アイデンティティで継続的かつ自動的に動作することで、すべての隠されたパーミッションを明らかにし、誰が何にアクセスできるかを常に正確に表示します。クラウドでの生活はクラウドでの頭脳を必ずしも意味するものではないため、発生した構成ミスを直ちに発見して修正することで、パーミッションのリスクが災害につながるのを防止できます。

Zscaler CIEMの詳細やデモの予約については、Zscalerに直接お問い合わせください。