Upgrade to Pro — share decks privately, control downloads, hide ads and more …

コンテナセキュリティ入門ウェビナー ~ECS on Fargate構成に必要なセキュリティ対策...

コンテナセキュリティ入門ウェビナー ~ECS on Fargate構成に必要なセキュリティ対策を知ろう~

こーへい

July 16, 2024
Tweet

More Decks by こーへい

Other Decks in Technology

Transcript

  1. 2 自己紹介 https://dev.classmethod.jp/author/yoshikawa-kohei/ • 吉川 晃平 • クラスメソッド株式会社 • AWS事業本部カスタマーソリューション部

    ◦ ソリューションアーキテクト • この一年で特に関わったAWSサービス ◦ AWS Security Hub
  2. 5 本ウェビナーについて • ターゲット ◦ 現在ECS on Fargate環境を利用していて、コンテナセキュリティに ついて知りたい方 •

    ウェビナーで説明すること ◦ コンテナセキュリティの解説 ◦ コンテナセキュリティでクラスメソッドが提供する支援のご紹介 • ウェビナーの目標 ◦ 参加者の方がコンテナセキュリティ対策への第一歩が踏み出せる状態 になること
  3. 16 埋め込まれたマルウェア • 内容 ◦ イメージ内にマルウェアが存在 • 対応方針 ◦ 信頼できるベースイメージを利用する

    ▪ 信頼できないベースイメージには、マルウェアが意図的に含まれ ている可能性がある ◦ GuardDutyやSysdig等でのセキュリティイベントの監視 ▪ 実際のコンテナ環境でマルウェアが引き起こす動きをチェック • コインマイニング • C&Cサーバーとの通信など
  4. 17 埋め込まれた平文の秘密情報 • 内容 ◦ イメージに平文の機密情報がある場合、流出リスクが高まる ▪ DBの接続パスワード ▪ サードパーティAPIをコールするためのAPIキーなど

    • 対応方針 ◦ Secrets Manager等の管理サービスに機密情報を保存し、コンテナ 実行時に動的に挿入する ▪ 機密情報を専用の管理サービスにて一元的に管理することで、機 密情報の管理場所の把握やアクセス経路を減らせるので流出リス クを下げられる
  5. 18 信頼できないイメージの使用 • 内容 ◦ 下記のようなリスクが含まれる外部イメージの使用 ▪ マルウェアが埋め込まれている ▪ ソフトウェアの脆弱性に存在するなど

    • 対応方針 ◦ 信頼できるイメージの使用 ◦ ECR等でのレジストリサービスでの使用するイメージの一元管理 ◦ イメージ検証による改ざんの有無確認
  6. 22 レジストリ内の古いイメージ • 内容 ◦ レジストリに古くて脆弱性の存在するイメージを放置したまま、誤っ てデプロイされると脆弱性を抱えたコンテナが起動し続けるリスクが 生じる • 対応方針

    ◦ ECRに格納したイメージへの定期的なスキャン ◦ ECRのライフサイクル機能等を活用し、古いイメージを削除するなど 適切なイメージ管理 ◦ コミットIDを一意なタグとして使用し、タグの上書きを禁止すること で、誤ったイメージのデプロイを防止
  7. 23 認証・認可の不十分な制限 • 内容 ◦ レジストリの認証・認可が不十分な場合、攻撃者による意図しないイ メージへのアクセスが発生しうる ▪ イメージをプルして情報流出 ▪

    悪意のあるイメージをプッシュし、そのイメージを起動させる • 対応方針 ◦ 適切な認証認可の設定 ▪ ECRの場合、プライベートリポジトリを使用して認証を必須と し、リソースベースポリシーを使用して適切な認可を行う
  8. 27 不正アクセス • 内容 ◦ オーケストレータへの不正アクセスにより、システムに影響を与える 可能性がある • 対応方針 ◦

    AWSアカウント自体の不正アクセス対策として、ログイン時に必ず MFAを使用する ◦ オーケストレータノード自体への不正アクセス対策は、ECSの場合は AWSの責任範囲のため考慮不要
  9. 29 ワークロードの機微性レベルの混合 • 内容 ◦ 異なるワークロードレベルのコンテナを同一ホストで展開すること で、片方のアプリケーションの侵害によってもう片方のアプリケー ションの侵害リスクが生じる • 対応方針

    ◦ 機微性レベルが異なるコンテナワークロードは適切に分離する ▪ ECS on Fargateの場合、ECSタスクに異なるワークロードのコン テナを混在させない ▪ そもそもVPCやアカウントを分離できないか検討
  10. 35 安全でないコンテナランタイム構成 • 内容 ◦ コンテナランタイムの設定不備 ▪ コンテナから許可されるシステムコールセットを不必要に広げる ▪ コンテナが特権モードで動かす

    ▪ ホスト上に機密ディレクトリをマウントするなど • 対応方針 ◦ ECS on Fargateの場合は、ホストOSがAWSの責任範囲のため考慮不 要
  11. 36 アプリの脆弱性 • 脅威内容 ◦ アプリケーション自体の欠陥や脆弱性 ▪ クロスサイトスクリプティング ▪ SQLインジェクション等

    • 対応方針 ◦ AWS WAFによるアプリケーションレイヤーの攻撃緩和 ◦ GuardDutyやSysdig等でのセキュリティイベントの監視
  12. 37 未承認コンテナ • 内容 ◦ アプリケーション開発者がコードのテストのためなど、許可されてい ないコンテナを起動するとリスクが生じる ▪ 未承認のコンテナは適切な承認フローを経ておらず通常より脆弱 性が存在する可能性が高い

    • 対応方針 ◦ 適切な承認フローの元でしかデプロイできないようにする ▪ 重要度の高い脆弱性が存在するとデプロイできない ▪ CICDからのデプロイのみ許可し、手動のデプロイを禁止するなど ◦ CloudTrailやConfigを有効化し、アクティビティログを残す
  13. 40 大きなアタックサーフェス • 内容 ◦ ホストOSに脆弱性が存在 • 対応方針 ◦ ECS

    on Fargateの場合は、ホストOS部分がAWSの責任範囲のため考 慮不要
  14. 52 Secrets Manager / SSM Parameter Store • 「イメージのリスク」に対応 ◦

    機密情報の管理サービスを使用し、コンテナ起動時に機密情報の動的 挿入することで流出リスクを軽減
  15. 61 Trivy • 「イメージのリスク」に対応 ◦ 現在Aqua Security社が開発しているOSS ▪ https://github.com/aquasecurity/trivy ◦

    イメージに含まれる脆弱性等をスキャンするツール ▪ OSやアプリケーションライブラリの脆弱性 ▪ Aqua Security社によって定義されるDockerfileのベストプラク ティス項目 ◦ CIに組み込まれて使用されることが多い
  16. 63 Dockle • 「イメージのリスク」に対応 ◦ Tomoya Amachi氏が開発したOSS ▪ https://github.com/goodwithtech/dockle ◦

    イメージの設定不備をスキャンするツール ▪ CISによって定義されるベストプラクティス項目 ▪ Docker公式のベストプラクティス等からDockleが定めた項目 ▪ nixCraftのLinuxベストプラクティス等からDockleが定めた項目 ◦ CIに組み込まれて使用されることが多く、Trivyと併せることで「イ メージのリスク」に対して効果的な対策となりうる
  17. 76