[レポート]AWS security services for container threat Detection #SEC329-R #reinvent

セッション

スピーカー：Scott Ward、Mrunal Shah
セッションレベル：300 - Advanced
サービス：Amazon GuardDuty, Amazon Inspector, Amazon Dtective
カテゴリ：セキュリティ

はじめに

AWSの年に一度の祭典 re:Invent 2022に参加しております。
現地オフラインで AWS security services for container threat Detection というセッションに参加してきました。

セッションの概要は以下となります。

概要

コンテナは、多くの AWS のお客様のアプリケーション モダナイゼーション戦略の基礎です。実稼働環境でコンテナーへの依存度が高まっているため、コンテナーのワークロード用に設計された脅威検出が必要です。セキュリティ チームと DevOps チームのコンテナ セキュリティと可視性のニーズを満たすために、最近、新しいコンテナ固有のセキュリティ機能が Amazon GuardDuty、Amazon Inspector、および Amazon Detective に追加されました。このセッションでは、これらの新機能と、AWS コンテナ ワークロードのスケーリングに役立つデプロイと運用化のベスト プラクティスについて学びます。さらに、HBO Max のクラウド セキュリティ責任者が、コンテナ セキュリティ監視のベスト プラクティスを共有しています。

内容

コンテナに関するAWSが提供するセキュリティについて話をしていきます。

コンテナセキュリティのAWSのネイティブサービス

• サポート
• 脅威検出
• 脆弱性管理

コンテナ環境での一般的な課題

• スケーリング
• 根本原因の特定（特定のECGで実行されているコンテナーが増えるので、何が問題なのか特定しにくい）
• コンテナは短命であること（数分または一時間程度の利用時間の間で脆弱性を脅威を引き起こす）
• それぞれのコンテナはそれぞれの設定情報で構成されていて、良い設定が何かを理解することが困難（既存のインフラストラクチャよりも）
• セキュアでないコンテナイメージからビルドされたコンテナ
• コンテナセキュリティに関する十分な専門知識を要していないこと
• 十分なセキュリティな可視性を持てないこと（従来のセキュリティ製品でカバーできていない）

GuardDuty EKS protection

• GuardDutyとは1クリックで有効可能な脅威検出サービス
• CloudTrail、VPC flow logs、Route 53 DNS query logsを情報源として異常検知・機械学習によって脅威を検知

• k8sではAPIによって設定情報の構成や設定の変更を理解する必要がある

• k8sの監査ログはk8sクラスター内のコントロールプレーンのAPIイベント情報をログする
• これらの監査ログはCloudTrailのログとして参照することができ、GuardDutyもログソースとして活用する

既知の悪意のある攻撃者の行動を検知することができる

• Torを使った行動の隠蔽
• 通常とは異なる悪意のあるイベント
• 非常に高い特権モードを利用してOSを操作

• 検知した内容はMitre Attackとマッピングすることができるので、どの攻撃深度でイベントが行われたかを判断し、どう調査したらいいか、軽減方法について活用することができる

• 全体的なFindingsの説明と軽減方法について知ることができる

• マルチアカウント環境全てでGuardDutyを有効にすることを推奨
• サンドボックス、開発環境など複数の役割を複数のアカウントに持たせデプロイする顧客もいる
• 各フェーズでGuardDutyの検知状況を見て、デプロイを実行
• セキュリティチームアカウントから全てのアカウントの検知情報を集約して、集中的に管理する運用が可能

Amazon Detective

• CloudTrail Logs、VPC flow logs、GuardDuty Findings、EKS監査ログを利用して、お互いがどう影響しているか統合的な可視化を提供
• 時系列と相互関係の可視化により、コンプライアンスの違反、通常からの逸脱、通常の運用がどうだったかを理解
• 通常の動作だったのかさらに調査が必要なのかを判断する材料とする
• EKS監査ログからEKSクラスター（クラスター、ポッド、コンテナ）の統合的な可視化が可能

シナリオ

（GuardDutyからのFindings情報）

• GuardDutyのFindingsから調査を開始
• 192.168.30.135のIPアドレスを送信元としたEKSアドミンからAnonymousユーザーへアクセスを与えるFindings

（Detectiveからの調査内容）

• 特定のユーザー（192.168.30.135）がいくつかのAPI実行結果を確認
• EKSアドミンがクラスターを作成して、Anonymousユーザーへアクセス権を与えるAPIコールが発生
• EKSサービスアカウントが侵害していると判断
• ポッドをさらに調査
• ポッドにアサインされているサービスアカウント（デフォルトの読み取り専用ロール）がアドミン権限を付与するAPIを発行

• ポッドが侵害されていると判断
• デフォルトの読み取りアカウントが発行しているAPIを調査
• Secretsを探すためにリスト表示するAPIコールの実行があった

• EKSアドミンアカウントのトークンを取得するAPIコールを発見

• ここまでで読み取り権限を持つポッドのサービスアカウントからアドミントークンを取得してAnonymousユーザーへアクセス権を与えるAPIコール実行までがクリアになった

（このFindingsが実際にどういう影響をおよぼすかさらに調査していく）

• Anonymousユーザーが実行しているAPIを調査
• Cronジョブの作成とポッド名「webapp」にパッチを適用していることを確認

• Cryptcurrecyマイニングのコンテナイメージがデプロイされていることが分かった

• Findingsグループを利用すると、関連しているリソースを紐付けて、Mitre Attackフレームワークに関するインサイトを得ることができる

Malware Protection

• エージェントレスでインストールが不要
• 29のFindingsタイプ
• 独自のコンテナおよびEC2で実行されているECS/EKSが対象
• コンテナ内のマルウェアを検出

Amazon Inspector

• 脆弱性のアセスメントツール
• EC2インスタンスとECRのコンテナイメージが対象
• Security Hubを使っている場合、FindingsをSecurity Hubに通知することが可能
• 開発者をInspectorへの参照権限を与えたくなくて、ECRコンソールかAPIコールで確認させることができる
• 脆弱性のFindingsをAmazon Event Bridgeでサードパーティのソリューションへつなぐことが可能

（コンテナイメージへの脆弱性スキャンの仕組み）

• コンテナイメージをECRにプッシュしたとき、またはInspectorを最初に有効化した時にコンテナのイメージのコピーを取得
• コンテナイメージのOSを確認し、どのパッケージがインストールされているかを確認
• 10のプラグラミング言語をサポート
• ファイルシステムがソフトウェアの依存性があるかを確認し、Outdatedまたは脆弱性がないかを確認する
• プッシュ時以外にもレポジトリ内をスケジュールしてスキャンすることが可能
• CSVまたはJSONでスキャン結果のレポートを出力することが可能

（コンテナパイプラインのユースケース）

• Gitレポジトリにコンテナイメージをプッシュ
• パイプラインが承認されるのを待つ
• InspectorはスキャンしてFindingsのサマリを送信
• Lambdaファンクションが結果を読み込んで、High・Medium・LowなどのSeverityを定義した閾値と比較
• 結果による許可／拒否のメッセージをパイプラインに返す
• 許可の場合は、パイプラインは最終的なデプロイを行い、拒否の場合はパイプラインは終了される
• 脆弱性が多く発見された場合、または重要度の高い脆弱性が発見された場合にパイプラインを中断させる

まとめ

難しいとされているコンテナセキュリティについて、AWSサービスを使った各機能とユースケースについて聞くことができました。
このセッションの中で印象に残ったのは、複雑となるKubernetesをはじめコンテナの設定や変更をおよぼすAPIイベントについて、可視化することと各APIイベントの関連性をつなげていくことが重要であることを学ばせてもらいました。
ぜひ実運用の中でも取り入れていきたいですね。