ECS Fargateにおける脅威のモデリング

本文の内容は、2021年3月16日にKaizhe Huangが投稿したブログ(https://sysdig.com/blog/ecs-fargate-threat-modeling/)を元に日本語に翻訳・再構成した内容となっております。

AWS Fargateは、Amazon EC2インスタンスのサーバーやクラスターを管理することなくコンテナを実行するために、Amazon ECSとともに使用できる技術です。AWS Fargateを使用すると、コンテナを実行するために仮想マシンのクラスターをプロビジョニング、構成、またはスケーリングする必要がなくなります。これにより、サーバーの種類を選択したり、クラスターを拡張するタイミングを決めたり、クラスターのパッキングを最適化したりする必要がなくなります。

つまり、ユーザーは仮想マシンの管理をAWSにオフロードし、タスク管理に集中することができます。リソース管理の観点から、多くの複雑さが軽減されます。

セキュリティの観点では、お客様にどのようなメリットがあるのでしょうか？

責任の共有

セキュリティとコンプライアンスは、AWSとお客様の間で責任を共有しています。

この共有モデルは、AWSがホストオペレーティングシステムと仮想化レイヤーから、サービスが動作する施設の物理的なセキュリティに至るまでのコンポーネントを運用、管理、制御する際のお客様の運用上の負担を軽減するのに役立ちます。

お客様は、ゲストOS（アップデートやセキュリティパッチを含む）、その他関連するアプリケーションソフトウェア、およびAWSが提供するセキュリティグループのファイアウォールの設定について、責任と管理を負います。

お客様の責任は、使用するサービス、それらのサービスのIT環境への統合、および適用される法律や規制によって異なるため、お客様は選択するサービスを慎重に検討する必要があります。

また、この共有責任の性質としては、柔軟性とお客様におけるコントロールを可能にするデプロイメントが実現されます。

下の図に示すように、このような責任の分担は、一般的にクラウド”の”セキュリティとクラウド”内”のセキュリティと呼ばれています。

セキュリティの観点として、Fargateでは、より多くのセキュリティ責任をAWSに担ってもらうことになります。

このことは、ウェブサービスのホスティングをクラウドベンダーに依存している中小企業に多くのメリットをもたらします。

MeltdownやSpectreのような脆弱性は、専門のセキュリティチームの努力なしには容易に緩和することができません。ECS Fargateに切り替えれば、コンテナランタイムレベルまでのすべての脆弱性にパッチを当てるのはAWSの責任となります。顧客はその後、コンテナ・イメージ、アプリケーション・セキュリティ、クラウド構成の強化に注力することができます。

このようにセキュリティ責任の一部がオフロードされることで、脅威のモデリングも変化します。

ECS Fargateの脅威モデルをさらに深く理解する

予備知識

EC2 Fargateの基本的な理解、特にどのようなコンポーネントが関係しているのかを知ることから始めると良いでしょう：

• クラスター：Amazon ECSクラスタは、タスクまたはサービスの論理的なグループです。
• タスク：コンテナを実行するために設定する属性のリストを持つ。
  • コンテナイメージ
    • 環境変数
    • ラベル
    • 読み取り専用ファイルシステム
  • CPU/メモリ
  • ネットワークモード
  • エントリポイントコマンド
  • ロギング設定
  • データボリューム
  • IAMロール

詳細はタスクパラメーターをご参照ください。

• サービス： Amazon ECSサービスは、Amazon ECSクラスターでタスク定義の指定された数のインスタンスを同時に実行し、維持することを可能にします。サービス定義の中で、ユーザーはVPC、サービスのセキュリティグループを選択するだけでなく、ロードバランシング・メカニズムを設定する必要もあります。

脅威アクターと資産

脅威アクターとは、資産を保護すべきシステム内で実行されるエンティティやコードのことです。防御の観点からは、まず潜在的な敵が誰なのかを理解していないと、防御戦略が曖昧になりすぎてしまいます。

Fargateの仕組みをある程度理解した上で、いくつかの脅威アクターを以下のように定義することができます。

• エンドユーザー：アプリケーションに接続可能なエンティティ。このアクターのエントリーポイントは通常、ロードバランサー、またはアプリケーションに割り当てられたパブリックIPアドレスとポートです。
• 内部攻撃者：AWS資産の内部に限定されたアクセス権を持つ主体。アプリケーション開発者や侵害されたコンテナなどが内部攻撃者の良い例です。
• 特権を持った攻撃者：ECSクラスター内、あるいはAWS組織全体の管理者権限を持つエンティティ。特権攻撃者の例としては、インフラストラクチャーの管理者や、管理者権限を持つ危険なコンテナが挙げられます。

図のように、次のような脅威のアクターが考えられます：

インフラストラクチャー管理者のアカウントが侵害されると、攻撃者は企業のAWS環境に完全にアクセスできるようになります。

これはゲームオーバーです。

攻撃者がコンテナイメージに悪意のあるコードを混入させたり（コンテナ起動後に攻撃者のマシンにリバースシェルを立ち上げるなど）、アプリケーションの脆弱性を利用してコンテナにアクセスした場合、被害の影響はそのタスクに割り当てられた特権（またはIAMロール）や、そのタスクがアクセスを許可されている他のAWS資産によって異なります。

侵害されたコンテナを介して、攻撃者はS3やRDSの機密情報にアクセスしたり、Lambdaなどの他のAWS製品を介して余分な特権を得たりする可能性があります。

特筆すべきは、侵害されたコンテナを介して、攻撃者がLinuxのネームスペースの分離をジェイルブレイクしてホストマシンへのアクセスを試みる可能性もあることです。

しかし、Fargateでは、コンテナのジェイルブレイクを防ぐのはAWSの責任です。

AWSがFargateのセキュリティを確保するために行っている措置の一例として、Fargateのコンテナは決して特権モードでは実行されず、ホストレベルのネーススペースも使用せず、新しい機能の追加も許可しない。このような設定により、攻撃者がホストにアクセスする可能性を減らすことができます。

ただし、読み取り専用のファイルシステムを有効にするなど、ユーザーが従わなければならないセキュリティ・ベスト・プラクティスの他の部分もあります。

ECS Fargateでの防御戦略

以下は、ECS Fargateの防御戦略を説明するいくつかの例です。上記の脅威モデルに基づいて、それらのすべてがユーザーの責任下にあるべきです。

他のAWS資産の防御戦略は、S3とRDSに指定されたものと同様でなければなりません。IAMポリシーを適切に設定するのはユーザーの責任であり、最小権限の原則に従うことになります。

まとめ

Fargateは、ユーザーがより多くのセキュリティ責任をAWSにオフロードするのに役立ちます。

しかし、ユーザーアカウントのセキュリティとアプリケーションのセキュリティは依然として重要です。攻撃者がFargateコンテナの侵害に成功すると、より多くの特権を得たり、機密情報にアクセスしたりするためのラテラルムーブメントの拠点として使用することができます。

Fargateコンテナの攻撃対象を減らすためには、イメージスキャンのベストプラクティスに従うことが必須ですが、クラウドのセキュリティポスチャー管理は、攻撃の影響範囲を緩和するためのレイヤーを設ける事ができます。

最後になりましたが、cloudtrailを使って異常な活動を検出することで、セキュリティ・インシデントへの対応速度を高めることができます。

Sysdig SecureにおけるSysdig Cloud Connector for CloudTrailを導入することで、AWSにおける脅威検知を実装するために必要なランタイムの可視性を得ることができます。Sysdig Cloud Connector for CloudTrailは、すぐに使えるFalcoルールを備えているため、セキュリティ・イベントの調査に必要なセットアップ作業、レスポンス時間、およびリソースを最小限に抑えることができます。

まだSysdigのアカウントをお持ちでない方は、今すぐ登録して無料トライアルをご利用ください。Sysdig Cloud Connectorを本記事の手順に従って10分以内にデプロイし、より安全なAWSアカウントにしましょう！

SysdigはAWS Marketplaceでも見つけられます。