第141回 雲勉 Amazon Inspectorによる脆弱性管理~ECR コンテナイメージ編~

下記、勉強会での資料です。
https://youtu.be/-_rc8m-Gq-s

Transcript

1. 第141回 雲勉 Amazon Inspectorによる 脆弱性管理 ~ECR コンテナイメージ編~
2. ０．講師自己紹介 2 ◼ 大瀬戸 拓帆 • (所属) アイレット株式会社 クラウドインテグレーション事業部 • (経歴) 20代後半で異業種からIT業界に転職、アイレット歴 1年=AWS利用歴 • (何か一言) 初めての雲勉。外部発信をこれから頑張りたい • ご質問は YouTubeのコメント欄で受け付けております。 後日回答させていただきます！
3. アジェンダ 3 0. 自己紹介 1. はじめに 2. 脆弱性対応の運用について 3. 脆弱性対応の運用に必要な設定 4. 脆弱性対応の運用を破綻させないために 5. よりセキュアに 6. [宣伝]Sysdig運用サービスの紹介
4. 本日のゴール 4 • InspectorとSecurity Hubによる脆弱性対応の運用において便利な機能を理解する。 • 脆弱性対応の運用を継続していくためのポイントを理解する。
5. 1. はじめに 5
6. 1．はじめに 6 ・お客様の環境にAmazon Inspectorを導入したことがありますが、 脆弱性対応のツールとしてうまく使えていないことがありましたので InspectorとSecurity Hubでの運用方法や便利な機能を紹介できればと思います。 (詳しい設定方法はドキュメントのリンクのみとします) ・Inspectorの脆弱性スキャンの対象としてEC2、ECR、Lambdaがあります。 特にECRはCI/CDで開発を行う環境だとイメージが多くなり脆弱性管理が難しいため 今回はECRの場合に絞ってお話しします。 EC2やLambdaが対象でも通ずる話もありますので、お聞きいただけばと思います。 ・運用方法の正解は1つではありません。一意見として参考にして頂ければ幸いです。
7. 2. 脆弱性対応の運用について 7
8. 2.脆弱性対応の運用について 8 ▪脆弱性対応はしていますか？ ・影響度の大きい脆弱性に関するニュースの時だけ、確認してませんか？ ・脆弱性検知のツールを入れてみたものの、活用できてない。。なんてことないですか？ ▪脆弱性を検知・管理するサービスを使いこなしましょう ・脆弱性対応に便利なAWSのサービスや便利な機能を紹介 ・サービス導入しっぱなしにならないよう運用方法も紹介します
9. 2.脆弱性対応の運用について 9 ▪脆弱性対応の運用で大事なこと ・調査が面倒 ・脆弱性多すぎ ・優先順位わからない ◦必要なこと ・脆弱性スキャン ・脆弱性の評価 ・対応進捗の管理 ◦ツールなしで脆弱性対応をする場合
10. 2.脆弱性対応の運用について 10 ▪脆弱性対応のツール ECRイメージに対応した脆弱性検知のサービスは各ベンダーが出していますが、 今回はAWSサービスとして提供している脆弱性検知サービスであるAmazon Inspectorと AWSのセキュリティ状態を包括的に把握するサービスであるAWS Security Hubを利用した 脆弱性対応の運用を紹介します
11. 2.脆弱性対応の運用について 11 ▪AWSサービスで脆弱性対応の運用 ・Inspectorを有効化し、Security Hubと統合するだけ！(マルチアカウント対応可能)
12. 2.脆弱性対応の運用について 12 ▪運用方法の提案 No. 対応タイミング 対象 内容 No.1 通知即時対応 優先度【高】の脆弱性 ・脆弱性を修正、対応不要・保留の判断 No.2 週次または月次 優先度【高】の脆弱性 ・No.1で保留とした脆弱性の進捗確認 ・必要に応じて優先度のチューニング No.3 月間の中で任意のタイミング 優先度【中】の脆弱性 ・脆弱性を修正、対応不要・保留の判断 No.4 月次 優先度【中】の脆弱性 ・優先度中度の脆弱性を連絡 ・前月までの優先度中度の脆弱性対応の進捗確認 ・必要に応じて優先度のチューニング ・No.1~No.4を各タイミングで実施する ・No.3~No.4はNo.1~No.2の対応に余裕があった時のみとする ・会社のセキュリティポリシーやリソース状況に応じて優先度のチューニングを適宜行う
13. 2.脆弱性対応の運用について 13 ▪No.1 通知即時対応(優先度【高】の脆弱性)
14. 2.脆弱性対応の運用について 14 ▪No.2 週次または月次対応(優先度【高】脆弱性)
15. 2.脆弱性対応の運用について 15 ▪No.3 月間の中で任意のタイミングで対応(優先度【中】の脆弱性)
16. 2.脆弱性対応の運用について 16 ▪No.4 月次対応(優先度【中】の脆弱性)
17. 3.脆弱性対応の運用に必要な設定 17
18. 3.脆弱性対応の運用に必要な設定 18 ▪脆弱性管理画面 検出された脆弱性結果は以下のサービスから確認・管理できる サービス メリット 注意点 ECR ・イメージごとの脆弱性が確認しやすい ・スキャン対象外のイメージを確認できる ・脆弱性のフィルタリング機能が弱い Inspector ・検出結果の検索方法が豊富 ・検出結果やSBOMのエクスポート可能 ・検知抑止可能 ・検知抑止した脆弱性の確認方法 Security Hub ・ワークフローステータスや ユーザー定義が設定可能 ・オートメーションやカスタムアクションで 上記を自動や手動で設定可能 ・カスタムインサイトでフィルタリングを 保存可能 ・Inspectorとフィルタリングの 項目名が違う
19. 3.脆弱性対応の運用に必要な設定 19 ▪ECRの脆弱性管理画面 既知の悪用の有無などで フィルタリングできない イメージごとの脆弱性が 確認できる
20. 3.脆弱性対応の運用に必要な設定 20 ▪Inspectorの脆弱性管理画面 エクスポート機能 様々な検索方法 抑制ルール フィルタリング機能
21. 3.脆弱性対応の運用に必要な設定 21 ▪Inspectorのダッシュボード 各表示項目をフィルタリングはできない⇒今後のアップデートに期待
22. 3.脆弱性対応の運用に必要な設定 22 ▪Security Hubの脆弱性管理 ・他のセキュリティサービスによる検出結果も集計している ・ワークフローステータスやユーザー定義で フィルタリング可能 ・カスタムインサイトでフィルタリングを保存できる ・オートメーションやカスタムアクションで 脆弱性検出結果のステータスなどを更新できる
23. 3.脆弱性対応の運用に必要な設定 23 ▪Security Hubのダッシュボード ・グラフのフィルタリングができない⇒今後のアップデートに期待
24. 3.脆弱性対応の運用に必要な設定 24 ▪通知設定 通知はInspectorまたはSecurity Hubどちらからも通知できる ⇒Security Hubからの通知がおすすめ ・Security Hubからの通知の方が情報量が多い ・ワークフローステータスで通知をフィルターできる ・Slackから通知を抑制できる https://docs.aws.amazon.com/chatbot/latest/adminguide/slack-setup.html https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/securityhub-cwe-event-formats.html 通知設定方法のドキュメント
25. 3.脆弱性対応の運用に必要な設定 25 ▪脆弱性の検出結果 Inspector Security Hub Security Hubは以下がわかる ・脆弱性の内容 ・新規脆弱性かどうか ・重要度
26. 3.脆弱性対応の運用に必要な設定 26 ▪優先度は任意で設定 ・会社のセキュリティポリシーや脆弱性対応に割けるリソース次第 ・対応が逼迫したり、まだ余力がある場合はチューニングが必要 ▪優先度を設定する上で考慮するフィルター フィルター項目名がInspectorとSecurity Hubで少し違う 項目 Inspectorの 項目名 Security Hubの 項目名 値 脆弱性の トリアージ結果 重大性 重要度ラベル Critical ~ Information (Untriaged) 脆弱性スコア Inspectorスコア (CVSSスコアに 基づく) なし 10 ~ 0 既知の悪用の有無 考えられる攻撃 ソフトウェアの脆弱性 エクスプロイトが 利用可能 Yes or No 修正バージョンの 有無 使用可能な修正 ソフトウェア脆弱性 修正可能 Yes or No https://docs.aws.amazon.com/inspector/lates t/user/findings-understanding-severity.html 重要度ごとのスコアの内訳
27. 3.脆弱性対応の運用に必要な設定 27 ▪通知設定時の注意点 ・Security HubやInspectorは脆弱性の検出結果を1つのデータとして扱う。 例えば脆弱性CVE-〇〇に該当するイメージが4件あれば4件を管理。⇒データ数がかなり多くなる。 ・通知設定をワークフローステータスでフィルタリングしてなければ脆弱性情報の更新がある度に通知される。 ・脆弱性CVE-〇〇に脆弱性情報の更新があれば4件の通知が一気に来る(ノイズの原因)。
28. 3.脆弱性対応の運用に必要な設定 28 ▪Security Hubワークフローステータス設定で通知を絞る { "source": ["aws.securityhub"], "detail-type": ["Security Hub Findings - Imported"], "detail": { "findings": { "ProductName": ["Inspector"], "RecordState": ["ACTIVE"], "Severity": { "Label": ["CRITICAL"] }, "Vulnerabilities": { "ExploitAvailable": ["YES"] “FixAvailable”:[“YES”] }, "Workflow": { "Status": ["NEW"] } } } } 通知のEventBridgeイベントルール https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/security hub-findings-format-syntax.html ・通知条件にワークフローステータス:NEWを設定 ・NOTIFIEDやSUPPRESSにした検出結果は 脆弱性情報に更新があっても通知が来ない ◦ワークフローステータスの値 ・NEW ・NOTIFIED ・SUPPRESS ・RESOLVED https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/finding-workflow-status.html ⇒脆弱性対応の進捗に応じて 適切にワークフローステータスを設定していくことが重要
29. 3.脆弱性対応の運用に必要な設定 29 ▪Security Hub ワークフローステータスの意味付け(例) ワークフロー ステータスの値 ステータスの 意味付け(任意) NEW 検出直後 NOTIFIED 即時対応予定 SUPPRESS 保留・月次対応 RESOLVED 対応不要・対応完了 ワークフローステータスに自分なりに上記の意味付けをして 運用をしていけば優先順位もつけやすくなってくる
30. 3.脆弱性対応の運用に必要な設定 30 ▪Security Hub ワークフローステータスの設定方法 ・Security Hubの検出結果画面から手動で変更 https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/securityhub-insights.html ・Slack画面から手動でSUPPRESSEDに変更(IAMロール設定必要) https://aws.amazon.com/jp/blogs/security/use-aws-chatbot-in-slack-to-remediate-security-findings-from-aws-security-hub/ ・Security Hubオートメーション 例）対応保留としたCVE-〇〇の脆弱性はワークフローステータスをSUPPRESSEDに自動変更 https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/automation-rules.html
31. 3.脆弱性対応の運用に必要な設定 31 ▪Slack画面から手動でSUPPRESSEDに変更(IAMロール設定必要) https://aws.amazon.com/jp/blogs/security/use-aws-chatbot-in-slack-to-remediate-security-findings-from-aws-security-hub/
32. 3.脆弱性対応の運用に必要な設定 32 ▪Security Hub オートメーションの設定例 ・対応保留としたCVE-〇〇の脆弱性はワークフローステータスをSUPRESSEDに自動変更 ⇒月次で対応方針再検討 ・修正バージョンの有無がNoの脆弱性はワークフローステータスをSUPRESSEDに自動変更 ⇒月次で修正バージョンが出てないか確認 ・脆弱性の対象イメージが所属するリポジトリにosetoを含む場合は ユーザ定義で「Key:in-charge、Value:oseto」を自動設定 ⇒リポジトリに応じて担当者を自動設定
33. 3.脆弱性対応の運用に必要な設定 33 ▪Security Hub オートメーションの設定画面例
34. 3.脆弱性対応の運用に必要な設定 34 ▪Security Hub ユーザ定義フィールドの例 ・オートメーションやカスタムアクションで設定可能 ・設定したユーザ定義をもとにフィルタリング検索が可能 Key Value 定義の意味 In-charge oseto 担当者 priority 1 優先度 project Project-A プロジェクト
35. 3.脆弱性対応の運用に必要な設定 35 ▪カスタムアクション ・カスタムアクションを実行するとLambdaで定義したBatchUpdateFindingsアクションを EventBridge経由で実行できる https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/finding-update-batchupdatefindings.html ・例えば、任意の脆弱性検出結果に対して「担当者：A」(ユーザ定義)を設定できる
36. 3.脆弱性対応の運用に必要な設定 36 ▪カスタムアクションの設定画面例
37. 3.脆弱性対応の運用に必要な設定 37 ▪Security Hubのカスタムインサイトでフィルタリングを保存 https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/securityhub-custom-insights.html ・インサイト作成を選択 ・フィルタリングとグループ化条件を設定し作成⇒次回以降、確認が簡単
38. 4.脆弱性対応の運用を破綻させないために 38
39. 4.脆弱性対応の運用を破綻させないために 39 ▪脆弱性対応の運用を破綻させないためのポイント ・使わないイメージは削除する(ECRのライフサイクルポリシールール) ・Inspectorのエクスポート機能で脆弱性を定点取得して整理 ・脆弱性対応するイメージを絞る ・抑制ルール設定には注意が必要 ・脆弱性検知ができてないイメージやCVEがないか確認
40. 4.脆弱性対応の運用を破綻させないために 40 ▪使わないイメージは削除する(ECRのライフサイクルポリシールール) ・ECRにライフサイクルポリシールールを設定し、イメージを自動削除する ・イメージをリポジトリ内で世代管理や、プッシュから指定日数経過後に削除などが可能 ・イメージタグの命名規則やリポジトリの割り振りを工夫しよう
41. 4.脆弱性対応の運用を破綻させないために 41 ▪Inspectorのエクスポート機能で脆弱性を定点取得して整理 https://docs.aws.amazon.com/ja_jp/inspector/latest/user/findings-managing-exporting-reports.html ・特に脆弱性運用を開始する前に検出結果やSBOM(Software Bill of Materials )を定点で出力 することで対応すべき脆弱性の全体像や優先度が見えてくる。 (SBOMとはソフトウェアのコンポーネントとそれらの依存関係をリスト化したデータ) ・InspectorやSecurity HubのGUIだと、どんどん新しい脆弱性も検知していくので整理しにくい。 出力結果はCSVやJSONなのでデータ加工をして自分なりに分析も可能。 ・月次で脆弱性対応の進捗を確認する場合は定点で取得した方が前月と比較しやすい。
42. 4.脆弱性対応の運用を破綻させないために 42 ▪脆弱性対応するイメージを絞る ・イメージを世代管理している場合はプッシュ日が最も新しいイメージだけ修正するなど工夫する。 古いイメージの脆弱性はSecurity HubオートメーションやInspector抑制ルールで抑止するなど。 ・Amazon Detectiveでイメージがコンテナで実行されているか確認する。
43. 4.脆弱性対応の運用を破綻させないために 43 ▪抑制ルール設定には注意が必要 ・「Inspectorの抑制ルール」または「Security Hubのオートメーション」で検知や通知を抑制可能。 ・抑制しても検知は実施されるが、検出結果を検索する際に見落としてしまったり、 抑制ルールを設定しすぎると管理しきれなくなるので注意が必要。
44. 4.脆弱性対応の運用を破綻させないために 44 ▪Inspector抑制ルールのメリット ・Inspectorの設定でフィルターをかけた項目(リポジトリや脆弱性タイトル(CVE-〇〇)など) ごとに検知を抑制するルールを設定できる(検知しないわけでない) ・抑制ルールの画面から抑制ルールによって抑制された脆弱性を確認できる
45. 4.脆弱性対応の運用を破綻させないために 45 ▪Inspector抑制ルールの注意点1 ・抑制ルールの対象となった脆弱性検知結果はFinding StatusがSuppressedになる ・デフォルトではFinding StatusがActiveになっているため、デフォルトでは検出結果が見えない ⇒見たい場合はFinding StatusをSuppressedかShow Allに変更する必要がある
46. 4.脆弱性対応の運用を破綻させないために 46 ▪Inspector抑制ルールの注意点2 ・Inspector抑制ルールの対象となった脆弱性検知結果は、 Security Hubではレコードの状態がACTIVEからARCHIVEに変更される ・Security Hubの検出結果のデフォルトではレコードの状態が ACTIVEでフィルターをかけられているので、デフォルトで検出結果が見えない ⇒検出結果を見るにはフィルターを外す必要がある
47. 4.脆弱性対応の運用を破綻させないために 47 ▪Security HubオートメーションとEventBridgeの組み合わせで通知抑制 (例)重要度:CRITICALの脆弱性は全て通知するよう設定しているが、 対応保留中のCVE-2020-27619に関しては通知を一時的にオフにする ・EventBridgeで重要度:CRITICAL、ワークフローステータス:NEWのみを通知するよう設定 ・Security HubオートメーションでCVE-2020-27619を検知時にワークフローステータスを NEWからNOTIFIEDやSUPPRESSEDに変更する設定 ⇒ 通知されない ・InspectorのFinding StatusやSecurity Hubのレコードの状態はActiveのまま ⇒脆弱性管理画面確認の際に、見落とししにくい
48. 4.脆弱性対応の運用を破綻させないために 48 ▪Security Hubオートメーションの例
49. 4.脆弱性対応の運用を破綻させないために 49 ▪脆弱性検知ができてないイメージがないか確認(※ECRから確認) ・OSが対象外 https://docs.aws.amazon.com/ja_jp/inspector/latest/user/supported.html ・OSが古すぎてサポートが切れた(Health Dashboardで事前に通知がくる) ・スキャンの有効期限が切れた(スキャン期間の設定内容確認)※デフォルトは90日
50. 4.脆弱性対応の運用を破綻させないために 50 ▪脆弱性検知ができてないCVEがないか確認 ・Inspectorの「Vulnerability database search」で CVEを検索し、スキャンの対象になっているか確認できる https://docs.aws.amazon.com/inspector/latest/user/vulnerability-search.html 検知していない ≠ 安全 ・対象のCVEはInspectorのデータベースに入っているか確認しよう
51. 5.よりセキュアに 51
52. 5.よりセキュアに 52 ▪パイプラインの中にInspectorを組み込み、 CI/CDでデプロイ前に脆弱性チェック ・Jenkins ・TeamCity ・GitHub Actions ・CodeCatalyst actions ⇒脆弱性があればデプロイをしないという選択もできるのでよりセキュアに
53. 5.よりセキュアに 53 ▪脆弱性監視+ワークロード監視 ・GuardDutyで不正ワークロードを監視 ・Amazon Detectiveで調査
54. 5.よりセキュアに 54 ▪Security Hubでセキュリティ基準の到達度を組織全体でスコアリングおよび管理
55. 6.[宣伝]Sysdig運用サービスの紹介 55
56. 6.[宣伝]Sysdig運用サービスの紹介 56 ▪ここまで説明しておいて、なんですが。。 Inspector + Security Hub + GuardDutyでの運用が負担であるようなら アイレットが提供するSysdig 運用サービスをご紹介 https://cloudpack.jp/service/cloud-service/sysdig-maintenance.html Sysdigのライセンス料を割引しながら 脆弱性監視 + ランタイム監視 + 一次対応などをアイレットがサービスとして提供 主なサービス内容 ・脆弱性スキャンによる検知・評価 ・ワークロードの脅威を検知(検知した攻撃のブロックが可能) ・MLベースの検知 ・アイレットが24/365で有人監視 +一次対応 ・検知ルールのチューニングが可能 ・組織全体でセキュリティ基準の到達度をスコアリングおよび管理 などなど
57. ご清聴ありがとうございました 57