クラウド、防御者がアタックサーフェスを理解するために頼りにしてきたコンテキストが混乱している。もはや攻撃者は、ネットワーク・スタックの予測可能なレイヤーで可視性を追跡できるような、あるアセットから別のアセットへと直線的なネットワーク・プレーンに沿って移動することはない。クラウド では、攻撃者のあらゆる動きを、彼らが操作しているクラウド インフラとの関係で理解する必要がある。
この投稿では、クラウドを支えるアーキテクチャ、その結果としての脅威モデル、そして最後に攻撃者がこのようなシステムをどのように悪用するかについて議論することで、クラウドシステムを防御するために必要な独自のアプローチを明らかにすることを目指す。
まず、従来のオンプレミスのアーキテクチャと、攻撃者が悪用しようとする変曲点について簡単に説明する。従来の技術スタックと対比されるのが、クラウドサービスプロバイダー(CSP）のアーキテクチャです。ここでは、クラウド アーキテクチャの基本、出現した新たな脅威モデル、その結果、攻撃者がクラウドに配備されたリソースに侵入するために取る手段について説明する。最後に、なぜクラウド が異なるのか、その理由をしっかりと理解した上で、攻撃者が環境を悪用するクラウドネイティブな方法と、防御者がクラウドの可視性についてどのように考える必要があるのかを紹介します。
従来の技術スタックの脅威モデル
読者の多くが従来の技術スタックに精通している場合でも、データセンターアーキテクチャの概要を簡単に説明することは有益です。データセンターアーキテクチャの脅威モデルについて触れておくことは、後述するクラウドの脅威モデルに照らし合わせながら、その位置付けを確認するのに役立つだけでなく、システムを保護する方法について、私たちに組み込まれている前提を再認識するのにも役立ちます。
最初の妥協のベクトルを調べる
- 古典的なアーキテクチャでは、攻撃者がサーバーに直接アクセスできるような管理ポートが露出していることがある。
- また、アプリケーション層の脆弱性に関連するリスクや、OS層へのアクセスに悪用される可能性をモデル化する必要もある。
- 古典的なシステムにおける最初の侵害の他の一般的なポイントは、常に関連するフィッシング攻撃、電子メールで配信されるインプラント、ホスト層の脆弱性の悪用などである。
これらのベクトルは、攻撃者が環境への最初の足がかりを得るために利用されるか、あるいは、データの機密性に影響を与えるような目標を追求するために、システムを通して進行するために利用される。
攻撃者のテクニックは技術スタックの特性によって決まる。
攻撃者はその土地で生活し、自分たちが関わっている技術スタックに自分たちの手法を適応させる。 その単純さにもかかわらず、この普遍的な真理は、脅威アクターがオンプレミスのシステムとクラウドインフラストラクチャを標的とする場合に使用されるテクニックの多様性を説明するのに役立つ。
敵が関与しているオンプレミスのシステムには、おそらく完全に機能するオペレーティング・システムがインストールされている。攻撃対象は、侵害されたワークステーションから、被害者のデータセンター内のルーティング可能なサーバーにピボットするために活用されるかもしれない。
サーバーはエアギャップではなく、ネットワークを介して互いに接続されている。攻撃者はこのネットワークを介して、ホストからホストへと移動することができる。
従来のデータセンター・アーキテクチャでは、往々にして寛容な出口ルールが見受けられます。攻撃者がコマンド&コントロール・トンネルを通じて永続性を確立し、信頼されたネットワーク境界からデータを流出させようとするのは、このアウトバウンド・ネットワーク経路上です。
上の図に示されているオンプレミス型攻撃の進行は、攻撃者が利用できる表面積によって左右されることにお気づきだろうか。次のセクションでは、クラウドアーキテクチャの議論に移りますが、同じ法則が残っていることに気づくでしょう。
クラウドアーキテクチャと新たな脅威モデル
クラウドは、共有インフラストラクチャのコンセプトに基づいて構築されており、顧客はインフラストラクチャ・スタックの特定のレイヤーに対してきめ細かなアクセス権を付与され、リソースの作成と保守を行うことができる。クラウド クラウドの顧客は、IaaSリソースの作成、PaaSサービスの利用、データ転送、アクセスを管理するIAM(Identity and Access Management）ポリシーの作成など、完全な自律性を持つことができる。
機能へのアクセスは 機能へのアクセスは委譲され機能へのアクセスは委譲され、Cloud Control-Plane APIと呼ばれるAPIのレイヤーを通じて顧客に公開される。
クラウド環境とエンドユーザーとのやり取りはすべて、Cloud Control-Plane を介して、一般に公開されている何千もの API によって仲介される。コントロール・プレーンAPIによって、顧客は新しい環境の作成、ユーザーのプロビジョニング、リソースのメンテナンス、マネージドPaaSサービスに保存されたデータへのアクセスなどの管理タスクを実行できる。
コントロールプレーンAPIの責任は以下の通りである：
- 発信者を承認し、要求されたアクションを実行するための正しい権限を持っていることを確認する。
- アクションをダウンストリームコンポーネントにリプレイする。アクションには、VMのパワーサイクル、あるバケットから別のバケットへのオブジェクトのコピー、ユーザーのパーミッションの更新などがある。
クラウドは強力だ！
よく知られた公開APIのセットを介してすべての機能を公開することで、企業はこれまでにないスピードとスケールのインパクトを見出すことができる。cloud 上での構築は、開発サイクルにガソリンを注ぐようなものであり、移行や継続的なクラウド・インフラ・コストがしばしば高額になるにもかかわらず、あらゆる分野でクラウドへの大移動が本格的に進行しているのはそのためである。
この新しいパラダイムを踏まえ、クラウドに保存されたデータが直面する脅威をどのようにモデル化すべきか？
オンプレミスとクラウドの脅威モデルの類似点と相違点を浮き彫りにする素晴らしいレンズであるため、ここでは最初の妥協に焦点を当てることが有効だと思う。
クラウド、最初の妥協のベクトルがいくつか見覚えがあるはずだ。
- クラウド、IaaSリソースの管理ポートが開いていることが原因で、最初の侵害が発生する可能性がある。私たちは皆、SSHやRDPのポートが開いていると不要な注目を集めることに慣れ親しんでいる。クラウドでは、そのようなリスクは残っている。
- また、アプリケーションレイヤーの脆弱性も、まだ完全に関連している。一般に公開されているウェブ・アプリケーションにデプロイされた安全でないコードは、最低でも業務の中断を引き起こし、最悪の場合、攻撃者に DMZ 内への侵入の足がかりを与えてしまいます。
この2つのベクトルによる初期侵害の防止と検知を行ったオンプレミスでの経験は、クラウド 。防止と検知にまつわるルールは、クラウド ネイティブに若干傾くかもしれないが、クラウド環境で発生する場合は基本的に同じである。
しかし、コントロールプレーンAPIについてはどうだろうか？これらはパブリック・エンドポイントであり、認可は顧客によって設定可能である。この攻撃者サーフェイスは全く新しいものであり、精通した攻撃者がクラウドの利便性を利用して目的を達成する場所である。
攻撃者がオンプレミスの攻撃対象(図参照）とは対照的にコントロールプレーンAPIを活用する場合、攻撃の進行はどのようになるかを検証してみよう：
- フィッシングを介した最初の妥協は、頻繁に機能するため、敵対者がよく使う手口である。
- クラウド環境での活動の認証および承認にクレデンシャルが使用される場合、ハーベス トされたクレデンシャルの影響はクラウドに移行する可能性がある。
- 最初の侵害に関連する認証情報が、敵対者に直接的な経路を提供するとは考えにくい。その結果、クラウドにある多くの試行錯誤された特権昇格テクニックの1つが、追加権限を取得するために採用されるかもしれない。
- キャンペーンでは、多くの場合、何らかの形で永続性を確立しようとする。クラウド・コントロール・プレーン上では、それはオンプレミスとは大きく異なって見えるだろう。クラウドにおける永続性は、多くの場合、IAMポリシーの操作によるアカウント・アクセスのバックドアのように見える。
- このような攻撃の進行を経て、私たちはターゲットへのアクセスを獲得した段階にいる。クラウド、これは単にクラウド、ホストされているデータにアクセスするための適切なIAMパーミッションを獲得することを意味する。
- そして最後に、このシナリオでは、目的に対する行動とは、環境からデータを流出させることである。この場合も、クラウド 制御プレーンAPIを使用して、被害者の環境から攻撃者が制御する環境にデータを転送する。
この一連の攻撃は、最初の侵害から影響に至るまで、クラウドサービスプロバイダーの一般に公開されているAPIを通じて組織化された。ネットワークレイヤーやホストレイヤーは一切関与していない。ネットワーク上の予防的なコントロールやセンサーも存在しなかった。
クラウドネイティブデータ流出
CSPの重要な特徴はバックボーン・ネットワークである。 バックボーン・ネットワークとは何か？
- これは、クラウドサービスプロバイダーのサービス・レイヤーであり、CSPの運用バックグラウンド・タスクに使用され、マルチテナント・インフラと通信し、可用性を維持するために使用されるバックチャネル・ネットワークである。
- バックボーンとは、CSPが顧客データを転送するために使用するネットワークのことであり、オープンウェブ上でバイトを運搬することとは異なる。
このバックボーン・ネットワークにより、クラウドストレージ・リポジトリなどの多くのマネージド・サービスが、CSPの他のすべてのストレージ・リポジトリに自動的にルーティング可能になる。
戦術的に言えば、あるS3バケットから別のS3バケットにデータを移動したい場合、必要なのはそのためのIAM権限だけだ。ネットワーク経路は既にCSP (Cloud Service Provider) のバックボーンネットワーク上に切り出されている。
クラウド、コンシューマーはクラウドネイティブストレージ1にあるデータに対してネットワーク制限をかけることはできない。
例えば、2つのS3バケット間のトラフィックをキャプチャするために、ネットワーク層のログを取り込むことはできない。
これは、クラウド環境からデータを流出させようとする攻撃者にとって、魅力的な状況設定となる。
攻撃者が適切な IAM パーミッションを獲得すれば、クラウド コントロールプレーンにレイヤー 7 API リクエストを送信することで、被害者のバケットから攻撃者が管理するアカウントのバケットにデータを移動することができる。
これを実行するために、攻撃者は一般に公開されているクラウド・コントロール・プレーン API のみを利用し、CSP のバックボーン・ネットワーク（顧客にはアクセスできない、事前に設定されたネットワーク・ルート）を活用する。
コントロールプレーン上の可視性
あるバケツから別のバケツに移されたデータは、多くのディフェンダーが慣れ親しんでいるような痕跡を残さない。
- ネットワーク層のログは、あなたのバケツから別のバケツに移動するデータのパケットを明らかにするかもしれません。これらは、クラウド消費者であるあなたには利用できません。
- データの移動はバックボーン・ネットワーク上で行われ、クラウド、顧客はそのデータを見ることができない。
- ホスト層の可視性についてはどうか？
- S3バケットやAzureストレージ・ブロブなどのクラウド・ネイティブ・ストレージは、すべてマネージド・サービスだ。顧客は、Infrastructure as a ServiceモデルのようにホストやOSレベルにアクセスすることはできない。マネージドサービスにはエージェントをデプロイできない。
となると、残るはコントロールプレーンだ。攻撃者がとった行動は、従来のセンサーではどれも特定できなかったが、クラウド制御プレーンが書き込んだログには、活動の指標が現れる。
リソースとクラウド ホストのデータに対するすべてのアクションは、クラウド コントロールプレーンのプロキシAPIによって認可され、何らかの形の記録をもたらす。
- 開発者がバケットを作成する際のアクションが記録され、通常のデータの取り込みと読み込みが記録され、対応するイベントが発生します。
- 逆に、悪者がクラウド制御プレーンAPIを活用すると、彼らの行動は同じイベントとして記録される。
これらのイベント記録は、誰が、どこから、どのような認証情報で、何にアクセスしたか、クラウド環境のストーリーを伝えますが、ユーザーの意図は伝えません。特定のアクションに悪意があるか善意があるかを判断するには、さらにコンテキストの手がかりが必要であり、多くの場合、環境を見るための大きなレンズが必要です。
最終的な収穫
いくつかの教訓
- 攻撃者は、開発者がクラウドを使うのと同じ理由で、クラウドのユニークなアーキテクチャとクラウドネイティブ・サービスを活用する！速い！スケールする！そして、クラウドのコントロール・プレーンAPIは、彼らの目標達成を支援する。
- コントロール・プレーンは、クラウド環境において、悪意のある、あるいはそうでない活動の証拠を見つけることができる場所です。ネットワーク・ベースやホスト・ベースの監視では、必要な可視性は得られません。
[1] VPC（Virtual Private Cloud）サービスコントロール：Googleクラウドのみが、VPCに束縛されないマネージド・サービスの境界を強制する機能を提供https://cloud.google.com/vpc-service-controls#section-6