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

Transcript

1. コンテナセキュリティ入門ウェビナー ～ECS on Fargate構成に必要なセキュリティ対策を知ろう～ クラスメソッド株式会社 カスタマーソリューション部 吉川 晃平
 

2. 2 自己紹介 https://dev.classmethod.jp/author/yoshikawa-kohei/ • 吉川 晃平 • クラスメソッド株式会社 • AWS事業本部カスタマーソリューション部 ◦ ソリューションアーキテクト • この一年で特に関わったAWSサービス ◦ AWS Security Hub
3. 3 自己紹介 • 最近嬉しかったこと ◦ 自転車で琵琶湖一周したこと • 最近の興味 ◦ 麻雀 ◦ 担々麺 https://dev.classmethod.jp/author/yoshikawa-kohei/
4. 4 はじめに 本ウェビナーについて
5. 5 本ウェビナーについて • ターゲット ◦ 現在ECS on Fargate環境を利用していて、コンテナセキュリティに ついて知りたい方 • ウェビナーで説明すること ◦ コンテナセキュリティの解説 ◦ コンテナセキュリティでクラスメソッドが提供する支援のご紹介 • ウェビナーの目標 ◦ 参加者の方がコンテナセキュリティ対策への第一歩が踏み出せる状態 になること
6. 6 本ウェビナーについて
7. 7 コンテナセキュリティについて コンテナセキュリティの考え方
8. 8 コンテナセキュリティについて • 本ウェビナーでは「NIST SP800-190 アプリケーションコンテナセキュ リティガイド」をベースに解説 ◦ コンテナセキュリティの評価に使用できるフレームワークで日本語版 もあるため活用しやすい ◦ IPAが翻訳した日本語版資料 ▪ https://www.ipa.go.jp/security/reports/oversea/nist/ug65 p90000019cp4-att/000085279.pdf
9. • コンテナセキュリティの考え方 ◦ コンテナにはイメージのビルドからデプロイまでのライフサイクルが 存在する ◦ ライフサイクルの中で重要となってくるコンポーネントに存在するリ スクと対策を把握することが大切 9 コンテナセキュリティの考え方
10. 10 コンテナセキュリティの考え方 • 具体的なコンポーネント ◦ イメージ ◦ レジストリ ◦ オーケストレータ ◦ コンテナランタイム ◦ ホスト ◦
11. 11 各コンポーネントのリスク コンテナ環境における代表的なリスクの紹介
12. 12 リスクの紹介 イメージのリスク
13. 13 イメージのリスク • イメージの脆弱性 • イメージの設定の不備 • 埋め込まれたマルウェア • 埋め込まれた平文の秘密情報 • 信頼できないイメージの使用
14. 14 イメージの脆弱性 • 内容 ◦ イメージ内にソフトウェアの脆弱性が存在 • 対応方針 ◦ ECR・Inspector等を使用した定期的・継続的な脆弱性スキャン ◦ イメージの更新(セキュリティアップデート)と再デプロイ
15. 15 イメージの設定の不備 • 内容 ◦ イメージ(Dockerfile)に設定不備が存在 ▪ 例：コンテナプロセスの必要以上の特権での実行 ◦ イメージに含まれるソフトウェアに脆弱性がなくともリスクが高まる • 対応方針 ◦ InspectorやDockle等のツールで、Dockerfileの設定がベストプラク ティスに準じているかのチェック
16. 16 埋め込まれたマルウェア • 内容 ◦ イメージ内にマルウェアが存在 • 対応方針 ◦ 信頼できるベースイメージを利用する ▪ 信頼できないベースイメージには、マルウェアが意図的に含まれ ている可能性がある ◦ GuardDutyやSysdig等でのセキュリティイベントの監視 ▪ 実際のコンテナ環境でマルウェアが引き起こす動きをチェック • コインマイニング • C&Cサーバーとの通信など
17. 17 埋め込まれた平文の秘密情報 • 内容 ◦ イメージに平文の機密情報がある場合、流出リスクが高まる ▪ DBの接続パスワード ▪ サードパーティAPIをコールするためのAPIキーなど • 対応方針 ◦ Secrets Manager等の管理サービスに機密情報を保存し、コンテナ 実行時に動的に挿入する ▪ 機密情報を専用の管理サービスにて一元的に管理することで、機 密情報の管理場所の把握やアクセス経路を減らせるので流出リス クを下げられる
18. 18 信頼できないイメージの使用 • 内容 ◦ 下記のようなリスクが含まれる外部イメージの使用 ▪ マルウェアが埋め込まれている ▪ ソフトウェアの脆弱性に存在するなど • 対応方針 ◦ 信頼できるイメージの使用 ◦ ECR等でのレジストリサービスでの使用するイメージの一元管理 ◦ イメージ検証による改ざんの有無確認
19. 19 リスクの紹介 レジストリのリスク
20. 20 レジストリのリスク • レジストリへのセキュアでない接続 • レジストリ内の古いイメージ • 認証・認可の不十分な制限
21. 21 レジストリへのセキュアでない接続 • 内容 ◦ レジストリへの接続が安全でない場合、通信経路にてイメージに含ま れた機密情報等が傍受される可能性がある • 対応方針 ◦ 暗号化された通信経路を利用する ▪ ECRの場合は暗号化されている
22. 22 レジストリ内の古いイメージ • 内容 ◦ レジストリに古くて脆弱性の存在するイメージを放置したまま、誤っ てデプロイされると脆弱性を抱えたコンテナが起動し続けるリスクが 生じる • 対応方針 ◦ ECRに格納したイメージへの定期的なスキャン ◦ ECRのライフサイクル機能等を活用し、古いイメージを削除するなど 適切なイメージ管理 ◦ コミットIDを一意なタグとして使用し、タグの上書きを禁止すること で、誤ったイメージのデプロイを防止
23. 23 認証・認可の不十分な制限 • 内容 ◦ レジストリの認証・認可が不十分な場合、攻撃者による意図しないイ メージへのアクセスが発生しうる ▪ イメージをプルして情報流出 ▪ 悪意のあるイメージをプッシュし、そのイメージを起動させる • 対応方針 ◦ 適切な認証認可の設定 ▪ ECRの場合、プライベートリポジトリを使用して認証を必須と し、リソースベースポリシーを使用して適切な認可を行う
24. 24 リスクの紹介 オーケストレータのリスク
25. • 制限のない管理者アクセス • 不正アクセス • コンテナ間ネットワークトラフィックの不十分な分離 • ワークロードの機微性レベルの混合 • オーケストレータノードの信頼 25 オーケストレータのリスク
26. 26 制限のない管理者アクセス • 内容 ◦ オーケストレータに対する権限設定が不十分な場合、意図しない操作 によりシステムに影響を与える可能性がある • 対応方針 ◦ ECSの場合は、IAMユーザーに付与するアクセスの適切な管理
27. 27 不正アクセス • 内容 ◦ オーケストレータへの不正アクセスにより、システムに影響を与える 可能性がある • 対応方針 ◦ AWSアカウント自体の不正アクセス対策として、ログイン時に必ず MFAを使用する ◦ オーケストレータノード自体への不正アクセス対策は、ECSの場合は AWSの責任範囲のため考慮不要
28. 28 隔離が不十分なコンテナ間ネットワークトラフィック • 内容 ◦ 異なるアプリケーション間で同じ仮想ネットワーク(VPC)を共有して いる場合、片方のアプリケーションが侵害された場合、もう片方のア プリケーションのリスクが生じる • 対応方針 ◦ VPCやアカウントを分離できないか検討
29. 29 ワークロードの機微性レベルの混合 • 内容 ◦ 異なるワークロードレベルのコンテナを同一ホストで展開すること で、片方のアプリケーションの侵害によってもう片方のアプリケー ションの侵害リスクが生じる • 対応方針 ◦ 機微性レベルが異なるコンテナワークロードは適切に分離する ▪ ECS on Fargateの場合、ECSタスクに異なるワークロードのコン テナを混在させない ▪ そもそもVPCやアカウントを分離できないか検討
30. 30 オーケストレータノードの信頼 • 内容 ◦ オーケストレータの設定不備 • 対応方針 ◦ ECSの場合は、オーケストレータノードがAWSの責任範囲のため考慮 不要
31. 31 リスクの紹介 コンテナランタイムのリスク
32. 32 コンテナランタイムのリスク • ランタイムソフトウェア内の脆弱性 • コンテナからの無制限のネットワークアクセス • セキュアでないコンテナランタイムの設定 • アプリの脆弱性 • 未承認コンテナ
33. 33 ランタイムソフトウェア内の脆弱性 • 内容 ◦ ランタイムソフトウェア(ここでいうランタイムとはconteinerdなど コンテナの起動、停止、リソース管理の役割を担うソフトウェアのこ と)に脆弱性が存在 • 対応方針 ◦ ECS on Fargateの場合は、ホストOSがAWSの責任範囲のため考慮不 要
34. 34 コンテナからの無制限のネットワークアクセス • 内容 ◦ ネットワークトラフィックの隔離が不十分なことによって、コンテナ の侵害が他のコンテナの侵害につながる • 対応方針 ◦ 適切なネットワークの設計 ▪ VPCやアカウント分離 ▪ セキュリティグループによるトラフィック制御
35. 35 安全でないコンテナランタイム構成 • 内容 ◦ コンテナランタイムの設定不備 ▪ コンテナから許可されるシステムコールセットを不必要に広げる ▪ コンテナが特権モードで動かす ▪ ホスト上に機密ディレクトリをマウントするなど • 対応方針 ◦ ECS on Fargateの場合は、ホストOSがAWSの責任範囲のため考慮不 要
36. 36 アプリの脆弱性 • 脅威内容 ◦ アプリケーション自体の欠陥や脆弱性 ▪ クロスサイトスクリプティング ▪ SQLインジェクション等 • 対応方針 ◦ AWS WAFによるアプリケーションレイヤーの攻撃緩和 ◦ GuardDutyやSysdig等でのセキュリティイベントの監視
37. 37 未承認コンテナ • 内容 ◦ アプリケーション開発者がコードのテストのためなど、許可されてい ないコンテナを起動するとリスクが生じる ▪ 未承認のコンテナは適切な承認フローを経ておらず通常より脆弱 性が存在する可能性が高い • 対応方針 ◦ 適切な承認フローの元でしかデプロイできないようにする ▪ 重要度の高い脆弱性が存在するとデプロイできない ▪ CICDからのデプロイのみ許可し、手動のデプロイを禁止するなど ◦ CloudTrailやConfigを有効化し、アクティビティログを残す
38. 38 リスクの紹介 ホストのリスク
39. 39 ホストのリスク • 大きなアタックサーフェス • 共有カーネル • ホストOSコンポーネントの脆弱性 • 不適切なユーザーアクセス権 • ホストOSファイルシステムの改ざん
40. 40 大きなアタックサーフェス • 内容 ◦ ホストOSに脆弱性が存在 • 対応方針 ◦ ECS on Fargateの場合は、ホストOS部分がAWSの責任範囲のため考 慮不要
41. 41 共有カーネル • 内容 ◦ コンテナランタイムとホストOSはカーネルを共有しており、カーネ ル経由での攻撃リスクが存在する • 対応方針 ◦ ECS on Fargateの場合は、ホストOS部分がAWSの責任範囲のため考 慮不要
42. 42 ホストOSコンポーネントの脆弱性 • 内容 ◦ ホストOSが持っているソフトウェアに脆弱性が存在 • 対応方針 ◦ ECS on Fargateの場合は、ホストOS部分がAWSの責任範囲のため考 慮不要
43. 43 不適切なユーザーアクセス権 • 内容 ◦ ホストOSに直接ログインして管理する場合、コンテナに対して広範 な変更が可能なためリスクが生じる • 対応方針 ◦ ECS on Fargateの場合は、ホストOS部分がAWSの責任範囲のため考 慮不要
44. 44 ホストOSファイルシステムの改ざん • 内容 ◦ ホストOSの機密ディレクトリ等をマウントしている場合、ホストボ リュームのファイル改ざんのリスクがある • 対応方針 ◦ ECS on Fargateの場合は、ホストOS部分がAWSの責任範囲のため考 慮不要
45. 45 セキュリティ対策の紹介 コンテナセキュリティを実現する AWSサービスや OSSツールの紹介
46. 46 利用するソリューション AWSサービス
47. 47 ECR(1/2) • 「イメージのリスク」に対応 ◦ スキャンによるコンテナイメージの脆弱性管理が可能 ▪ 基本スキャンと拡張スキャンがある • 参考：https://blog.serverworks.co.jp/ecr-image-scan
48. 48 ECR(2/2) • 「レジストリのリスク」に対応 ◦ 通信経路やイメージ保管時の暗号化による情報漏洩防止 ◦ 認証機能やリソースベースポリシーによる不正アクセス防止 ◦ ライフサイクル機能やタグの上書き禁止機能による誤ったイメージ展 開の防止
49. 49 Inspector • 「イメージのリスク」「ホストのリスク」に対応 ◦ コンテナイメージのスキャンを実施 ◦ Dockerfileの設定不備のチェックも可能に
50. 50 拡張スキャンがCIに組み込みやすくなりました https://dev.classmethod.jp/articles/reinvent2023-inspector-image-scanning-cicd-support/
51. 51 Dockerfileの設定不備も検出可能に https://dev.classmethod.jp/articles/amazon-inspector-sbom-generator-detects-misconfiguration -in-dockerfile/
52. 52 Secrets Manager / SSM Parameter Store • 「イメージのリスク」に対応 ◦ 機密情報の管理サービスを使用し、コンテナ起動時に機密情報の動的 挿入することで流出リスクを軽減
53. 53 Codeシリーズ • 「イメージのリスク」に対応 ◦ CICD(CodeBuild、CodePipeline、CodeCommitなど)を利用するこ とで、イメージのデプロイまでに必要な処理を自動化できる ▪ 脆弱性やDockerfile等の各種スキャン ▪ コードの静的解析(SAST) ▪ 承認プロセスの組み込みなど
54. 54 Security Hub • 「レジストリのリスク」「オーケストレータのリスク」「ホストのリス ク」に対応 ◦ CSPMに相当するサービスで、「AWSリソースのセキュリティ設定が ベストプラクティスから逸脱していないか」を自動でチェックし、脅 威の発生源を特定できる
55. 55 Config • 「レジストリのリスク」「オーケストレータのリスク」「ホストのリス ク」に対応 ◦ AWSリソースの記録や管理を行い、何かセキュリティイベントが発 生した際の調査に役立つ
56. 56 Systems Manager Patch Manager • 「ホストのリスク」に対応 ◦ EC2インスタンスへのパッチインストールの自動化
57. 57 GuardDuty(1/2) • 「コンテナランタイムのリスク」に対応 ◦ Runtime保護によりコンテナランタイム上の脅威検出を行える ▪ コインマイニングやC&Cサーバーへの接続など ◦ サイドカーコンテナ形式でメインのアプリケーションコンテナを監視
58. 58 GuardDuty(2/2) • 「ホストのリスク」「コンテナランタイムのリスク」に対応(EC2のみ) ◦ EBSに存在するマルウェアをスキャンする機能 ▪ ホストがEC2(EBS)の場合に利用可能 • 「オーケストレータのリスク」に対応(EKSのみ) ◦ EKSの監査ログを元に不審なAPI実行をチェックする機能 ▪ ブラックリスト登録されているIPアドレスからのAPI実行など
59. 59 IAM • 全コンポーネントのリスクに対応 ◦ 適切なアクセス制御を行うことで、各種AWSリソースへの侵害を防 止する
60. 60 利用するソリューション OSSツール
61. 61 Trivy • 「イメージのリスク」に対応 ◦ 現在Aqua Security社が開発しているOSS ▪ https://github.com/aquasecurity/trivy ◦ イメージに含まれる脆弱性等をスキャンするツール ▪ OSやアプリケーションライブラリの脆弱性 ▪ Aqua Security社によって定義されるDockerfileのベストプラク ティス項目 ◦ CIに組み込まれて使用されることが多い
62. 62 Trivy https://dev.classmethod.jp/articles/developersio-2022-container-security-with-oss-tools/
63. 63 Dockle • 「イメージのリスク」に対応 ◦ Tomoya Amachi氏が開発したOSS ▪ https://github.com/goodwithtech/dockle ◦ イメージの設定不備をスキャンするツール ▪ CISによって定義されるベストプラクティス項目 ▪ Docker公式のベストプラクティス等からDockleが定めた項目 ▪ nixCraftのLinuxベストプラクティス等からDockleが定めた項目 ◦ CIに組み込まれて使用されることが多く、Trivyと併せることで「イ メージのリスク」に対して効果的な対策となりうる
64. 64 Dockle https://dev.classmethod.jp/articles/devio2023-dockle/
65. 65 利用するソリューション 商用製品
66. 66 Sysdig • 「コンテナランタイムのリスク」に対応 ◦ コンテナランタイムで発生しているセキュリティイベントを検知・記 録する製品 ▪ コンテナ環境では起動・停止が頻繁であり、イベント情報が消え やすくなるため、フォレンジック調査が重要になる
67. 67 Sysdig https://dev.classmethod.jp/articles/guardduty-sysdig-comparison-hibiyatech/
68. • 「コンテナランタイムのリスク」だけでなくコンテナライフサイクルに 沿ったセキュリティ対策も統合的に提供 ◦ イメージのスキャン ◦ 設定不備の検知(CSPM機能)など 68 Sysdig
69. 69 ネクストアクションについて クラスメソッドが提供する支援の紹介
70. 70 ウェビナー後の動き
71. 71 ウェビナー後の動き
72. 1. コンテナ環境のセキュリティ状況可視化支援 2. セキュリティ対策の検討 a. セキュリティ可視化支援のみご希望であればここで終了 b. 導入支援もご希望の場合は3以降に進む 3. セキュリティ対策の導入支援 72 支援の流れ
73. 73 支援イメージ ※具体的な費用等は相談会にて • コンテナ環境のセキュリティ状況可視化支援 a. セキュリティ対策の検討 • セキュリティ対策導入支援 a. ECR設定のレビュー b. GuardDuty Runtime Monitoringの導入 c. Security Hub導入など
74. 74 まとめ まとめ
75. 75 まとめ(話したこと) • コンテナ環境に存在するリスクと対応の説明 • AWSサービスやOSSツールの紹介 • クラスメソッドの提供する支援の紹介