AWS Fargateワークロードのセキュリティを確保：ファイル整合性監視(FIM)の要件を満たす

By 清水 孝郎 - MAY 9, 2021

SHARE:

本文の内容は、2021年5月4日にAlba Ferriが投稿したブログ(https://sysdig.com/blog/securing-aws-fargate)を元に日本語に翻訳・再構成した内容となっております。

AWS Fargateのサーバーレスワークロードのセキュリティの確保は、AWSが内部の仕組みについてあまり詳細を提供していないため、厄介なものです。結局のところ…それはあなたのビジネスではなく、AWSがあなたのために基礎的なリソースのスケーリングを管理しているのです。:)

Fargateのシステムにおけるセキュリティと安定性は固有の機能ですが、Fargateは責任共有モデルを採用しており、アプリケーションに固有の部分のセキュリティには気を配る必要があります。

AWS FargateのようなCaaS環境をそのライフサイクルを通して保護するためには、すべてのユースケースをカバーする必要があります。これには、クラウドセキュリティ、イメージスキャン、ランタイム保護、クラウド脅威検知のほか、可能であれば包括的な監査証跡を確立することも含まれます。



この記事では、Sysdigを使用してAWS Fargateワークロードを右から左へセキュアにする方法を説明します。

厄介なセキュリティイベントが発生

まず、ここで例を挙げてみましょう。

SysdigエージェントがインストールされたAWS Fargateのワークロードタスクが稼働しています。すぐに使えるFalcoランタイムポリシーの1つである「Suspicious Filesystem Changes」により、ポリシーがトリガーされました：



このポリシーには、一般的に不審な活動に対するルールが含まれています。このケースでは、ポリシーをトリガーしたルールは、Modify binary dirsでした。

実際のFalcoルールは次のようになっています：

- rule: Modify binary dirs
  condition: >
    bin_dir_rename and
    modify and
    not exe_running_docker_save and
    not user_known_modify_bin_dir_activities
  output: File below known binary directory renamed/removed (user=%user.name user_loginuid=%user.loginuid command=%proc.cmdline pcmdline=%proc.pcmdline operation=%evt.type file=%fd.name %evt.args container_id=%container.id image=%container.image.repository)
  description: an attempt to modify any file below a set of binary directories.
  tags: SOC2_CC7.1, PCI_DSS_10.2.7, SOC2_CC6.8, NIST_800-53_CM-5, SOC2, filesystem, mitre_persistence, NIST_800-190_3.4.4, PCI, NIST_800-53_SI-7, NIST_800-53_SI-4, NIST_800-190, NIST_800-53

タグの欄をよく見ると、このポリシーがいくつかのコンプライアンス標準にマッピングされていることがわかります。これはFile Integrity Monitoring (FIM)の一般的なチェック項目であるため、Sysdigは、すぐに使えるルールとして提供しています。

ほとんどのコンプライアンス標準においてFIMは必須です。PCI-DSS（Payment Card Industry Data Security Standard）を例にとると、要件番号11.5で次のように規定されています。”重要なシステムファイル、構成ファイル、またはコンテンツファイルの不正な変更を担当者に警告するために、変更検出メカニズム（例えば、ファイル整合性監視ツール）を導入すること。”

このポリシーは、内部犯行、ゼロデイ脆弱性の悪用、マルウェアなどによるあらゆるデータ侵害について警告します。適切なファイル整合性監視を実施することは、Fargateタスクの内部であっても、PCIコンプライアンスを達成するのに役立ち、また、より安全で信頼性の高い企業となります。

問題の深堀り

アラートで提供されている情報を詳しく見てみましょう：

  • agent.tag.aws-account-id 845151661675
  • agent.tag.aws-container-image 845151661675.dkr.ecr.us-west-1.amazonaws.com/qa/secure-event-generator:0.1.5
  • agent.tag.aws-fargate-cluster-arn arn:aws:ecs:us-west-1:845151661675:cluster/lugobad-stack-QASecureEventGeneratorCluster-yPudobodwok6
  • agent.tag.aws-fargate-task-arn arn:aws:ecs:us-west-1:845151661675:task/lugobad-stack-QASecureEventGeneratorCluster-yPudobodwok6/1dddc34c883f4dd9b26b39af1a8b30be
  • agent.tag.image-id sha256:1a8d6454ed77bd59f19d6204d453fceb8ceceefea432ce5da8796f21dd807071
  • container.name QASecureEventGenerator
  • process.name touch /usr/bin/2597de70-c942-4424-b039-5e15a86fd380



誰かが/usr/binの下にファイルを作ったことがわかります(process.name touch /usr/bin/2597de70-c942-4424-b039-5e15a86fd380)。

特定のFargateタスク(arn:aws:ecs:us-west-1:845151661675:task/lugobad-stack-QASecureEventGeneratorCluster-yPudobodwok6/1dddc34c883f4dd9b26b39af1a8b30be)から。

845151661675のAWSアカウントで、us-west-1ゾーンのECSクラスターで動作しています。

このような情報があれば、すでに調査を続け、同じアカウントの他のクラウド資産が侵害されていないかどうかを手動で確認することができます。しかし、これは面倒な作業になります。
幸いなことに、Sysdig Secureはコンテナワークロードとクラウドインフラの両方に対応した統合脅威検知機能を提供しており、これを活用することで調査を迅速に行うことができます。Cloud Activity Insightsのようなクラウドセキュリティ機能を利用して、数クリックでこのインシデントに関連する疑わしいアクティビティを見つけることができるでしょう。

そこで、Cloud Activity Insightsにアクセスし、クラスターの名前でフィルタリングしてみると…。

おっと! 誰かが実際に削除したのか！？



しかも、それは小さな動きではありません。

このイベントの詳細を見ると、誰がそれをやったのかがわかります。

aws.user  badlugo

ユーザーの名前があるので、Cloud User Activity Insightsセクションで検索を微調整することができます：



このユーザーが正しく行動していないことは明らかです。このユーザーは、MFAを使用せずにログインしており、この特定のセキュリティコントロールアクセスが必要な環境にいます。また、CloudTrailの証跡を削除していますが、これは自分の足跡を消そうとしている可能性があります。そして忘れてはならないのが、クラスターを削除していたという事実です。

これで、何が起こったのか、非常に明確に把握できました。クラウドアカウントのユーザー権限を剥奪したり、CloudTrailの証跡を再度有効にするなどの対応が可能です。

これは防ぐことができたのでしょうか？

Sysdigでは、セキュリティをシフトレフトさせることがいかに重要であるかを常に強調しています。アプリケーションのライフサイクルのできるだけ早い段階でセキュリティを実装することで、セキュリティリスクが現実の問題になる前に対応することができます。

この原則をAWS Fargateのワークロードに適用するには、AWS Fargateのタスクで実行されるイメージのスキャンを自動化することで可能です。

今回の例でそれを行っていたら、イメージスキャンの結果に大きな警告が表示されていたでしょう。つまり、私たちのイメージは、多くの開発者が（いまだに）行っている最も一般的なバッドプラクティスの1つである、コンテナをrootとして実行することに違反しているのです。





まとめ

AWS Fargateタスク上で実行されるコンテナワークロードにおけるセキュリティの確保が、コンテナとクラウドにおけるセキュリティの要素を共有することを見てきました。

AWS Fargateタスクは、他のクラウド資産と同様にセキュリティを確保する必要があります。コンテナワークロードの実行方法（Docker、Kubernetes、Fargate）に関係なく、コンテナワークロードを監視（または2つ）する必要があります。脅威の検知は、ホスト、ノード、仮想マシンでは簡単ですが、コンテナでは少し厄介です。また、CaaSプラットフォーム上で動作するワークロードとなると、また違った難しさがあります。

Sysdigでは、コンテナにおけるセキュリティの確保で実績のある、システムコールのポリシーやイベントを計測する機能を、AWSのFargateタスクにも導入しています。PCIコンプライアンスのためのFIMなどをAWS Fargate内で行うことができるので、CaaS環境でアプリケーションを実行することを選択した場合に、コンプライアンスを満たさないことを心配する必要がなくなります。

 

クラウドプロバイダーからのコンテキストを統一されたタイムラインビューに追加できることは、どのクラスター、リージョン、ユーザーが関係しているかを理解する上で重要です。また、セキュリティ問題が発生する前と後に何が起こったのか、ストーリーをマッピングします。

近々、Securing AWS Fargate lifecycle」についてお話しする予定です。Sysdig SecureとAWSを使って、自信を持ってAWS Fargate環境を保護する方法を聞いてみませんか？

これらの機能をご自身で試してみませんか？Sysdig Secureの30日間無料トライアルをお申し込みください。クレジットカードは不要で、わずか数分でご利用いただけます。