クラウド時代の脆弱性への取り組み 〜AWS・GCP編〜 / Vulnerability in the Cloud

ITmedia Security Week 2022 夏
https://enq.itmedia.co.jp/on24u/form/sec2206
日付：2022年6月10日(金)
テーマ：「クラウド時代の脆弱性管理（ポスチャ管理）」

Visional の CCoE 組織で取り組むパブリッククラウド（AWS / GCP）の脆弱性に対する取り組みについての発表資料です。

Transcript

1. クラウド時代の脆弱性への取り組み 〜AWS/GCP編〜 2022-06-10 ビジョナル株式会社 グループIT室クラウドインフラグループ Yuuki Nagahara
2. 長原 佑紀（Nagahara, Yuuki） 所属：ビジョナル株式会社 　　　グループIT室 クラウドインフラグループ（CCoE） 経歴： • 2006年〜 独立系SIer ◦ 主に通信系のシステム開発や研究開発 • 2015年〜 株式会社ビズリーチ ◦ 2015年よりビズリーチ事業のインフラエンジニアとして従事し、後 にチームリーダとして複数事業のインフラを担当 ◦ 2018年より全社横断となるプロダクト非機能要件改善組織に立ち 上げより参画 • 2021年〜 ビジョナル株式会社（株式会社ビズリーチより出向） ◦ CCoE Tech Lead として、Visional グループのパブリッククラウド 全体管理やクラウド共通プラットフォームの開発運用、クラウド活 用推進を担当 好きなクラウドサービス： AWS Lambda 自己紹介 2
3. アジェンダ 3 • Visional について • Visional の CCoE について • クラウド時代のセキュリティの課題 • クラウドにおける脆弱性とソリューション • Visional グループにおける取り組み • まとめ
4. Visional について • Visional について • Visional の CCoE について • クラウド時代のセキュリティの課題 • クラウドにおける脆弱性とソリューション • Visional グループにおける取り組み • まとめ 4
5. 5 グループ概要 設立　　 ：2020年2月（ビジョナル株式会社設立） 創業　　 ：2009年4月（株式会社ビズリーチ創業） 代表者　 ：ビジョナル株式会社 代表取締役社長　南 壮一郎 グループ従業員数：1,469名（2021年7月末時点） 資本金　 ：164億円（資本準備金含む）※2021年5月18日時点 拠点　　 ：東京、大阪、名古屋、福岡、静岡、広島
6. 6 グループミッション
7. 7 グループ運営サービス インキュベーション（新規事業領域） 採用プラットフォーム 人財活用プラットフォーム 人材マネジメント（HR Tech）エコシステム 事業承継M&A 物流Tech Sales Tech サイバーセキュリティ
8. 8 グループ経営体制について ビジョナル株式会社（ホールディングカンパニー）　 株式会社 ビズリーチ ビジョナル ・ インキュベーション 株式会社 株式会社 M&A サクシード 株式会社 スタンバイ HR Techの プラットフォームや SaaS 事業の運営 新規事業開発 法人・審査制 M&Aマッチングサイト 「M&Aサクシード」の運営 求人検索エンジン 「スタンバイ」 の運営 ※Zホールディングス株式会社 との合弁事業会社 トラボックス 株式会社 物流 DX プラットフォーム 「トラボックス」 の運営
9. Visional の CCoE について 9 • Visional について • Visional の CCoE について • クラウド時代のセキュリティの課題 • クラウドにおける脆弱性とソリューション • Visional グループにおける取り組み • まとめ
10. < 役割 > • クラウド戦略計画・推進 • クラウド全体管理 • クラウドガバナンス • クラウドプラットフォーム開発運用 • ナレッジ管理 • 技術支援 • トレーニング • コミュニティ活動 • など < 構造 > 10 Visional の CCoE について CCoE（Cloud Center of Excellence）は、クラウド活用をより推進するための専門組織。 CCoE クラウド ベンダー セキュリティ 部門 ユーザ部門 経営 バックオフィス （経理、法務、人事） ポリシー、ナレッジ、 クラウドプラットフォーム 連携 相談 問合せ 提供 技術支援 情報提供 相談 フィードバック 統制 監査 連携 連携 フィードバック クラウド関連 レポーティング ※クラウド利用者 外部 コミュニティ 活動
11. 11 フルクラウドでサービス運営 • 2012年に「ビズリーチ」をクラウド移行済 ◦ 以後の新規サービスはクラウドにて構築 • オンプレミス環境は保有していない • パブリッククラウドがデフォルトの選択肢 パブリッククラウドの利用規模 Visional のパブリッククラウド利用状況 100 以上 （AWS アカウント数） 75 以上 （GCP プロジェクト数） ※アクティブのみ
12. ビジョナル (株) 12 セキュリティに関わる組織体制 (株) ビズリーチ ビジョナル・ インキュベーション (株) トラボックス (株) 事業部 CISO 管掌組織 抜粋 ビジョナル（株）にグループ全体のセキュリティを統括する組織を設置。 各事業部にエンジニア チームが存在し、パブ リッククラウドを運用 (株) M&A サクシード 事業部 事業部 事業部 事業部 事業部 事業部 事業部 セキュリティ室 グループIT室 IT統制/セキュリティ推進 グループ 品質管理グループ セキュリティオペレーション グループ クラウドインフラ グループ（CCoE） セキュリティ関連文書管理 リスクアセスメント /監査 チェックシート実施 脆弱性診断 コーポレートインフラ監視 プロダクトセキュリティ監視 セキュリティ技術検証 コーポレート ITグループ パブリッククラウドのセキュリティに 関わる業務を “セキュリティ室 ” と協業
13. クラウド時代のセキュリティの課題 13 • Visional について • Visional の CCoE について • クラウド時代のセキュリティの課題 • クラウドにおける脆弱性とソリューション • Visional グループにおける取り組み • まとめ
14. 国内のパブリッククラウドサービス市場 • 2021年 1兆5879億円 (前年比28.5％増) • 2026年予測 3兆7,586億円（2021年比約2.4倍） 引用：「IDC japan - 国内パブリッククラウドサービス市場予測を発表」 パブリッククラウドの市場動向 14 パブリッククラウドの市場は益々加速する見込み
15. 2020 年に公表された情報漏えい事例（ Web やクラウドのシステムからの漏 えい）は 99 件あり、約 2,500 万件の情報漏えいが公表された。 発生原因の 51.5% が「脆弱性」を悪用した攻撃であった。「不明・未公表」を 除くと、「不正ログイン」（14.1%）、「設定ミス」（5.1%）と続く。「設定ミス」の件数 は少ないものの、漏えいした情報の件数では約 2,156 万件と全体の 9 割を 占めた。 2021 年にも38 の自治体や国内企業の個人情報等が設定ミスにより外部か ら閲覧可能であったと報道され、設定ミスによる漏えいが相次いでいる。 クラウドサービスからの情報漏洩事例が後を絶たない クラウドの情報漏洩事例 15 引用：「IPA - 情報セキュリティ白書 2021」
16. パブリッククラウドの特徴 16 責任共有モデル サービス利用形態 進化と変化への追従
17. パブリッククラウドの特徴① クラウドの利用者とサービスプロバイダの責任分担 例：AWS の責任共有モデル（右図） • 利用者の責任： クラウド における セキュリティ（Security ‘in’ the Cloud） • サービスプロバイダの責任： クラウド の セキュリティ（Security ‘of’ the Cloud） クラウド利用者は責任範囲を正しく理解し、責任を持って適切 な対応が必要 責任範囲の認識不足も、設定ミスを招く要因となる。 17 責任共有モデル 引用：「AWS / 責任共有モデル 」
18. クラウドサービスのサービス種類 • IaaS：Infrastructure as a Service • CaaS：Container as a Service • PaaS：Platform as a Service • FaaS：Function as a Service • SaaS：Software as a Service サービスにより利用者の責任範囲のスコープが異なる。 管理する範囲が多いほど自由度は高いが、トレードオフで 責任範囲が広がるため、選定時に考慮 パブリッククラウドの特徴① 18 責任共有モデル 引用：「DX白書2021」
19. パブリッククラウドは、インターネット経由で利用する利用形態。 個々のリソースの設定ミスから重大な事故に繋がる可能性があるため、利用するサービス・リソースごとに適切な アクセス制御や権限管理、防御策を施す必要がある。 パブリッククラウドの特徴② 19 サービス利用形態 従来のネットワーク境界 パブリッククラウド
20. クラウドの進化は速く、パブリッククラウド毎に年間数千件を超えるアップデートが提供されている。 また、昨今のアジャイル開発の浸透とクラウドの柔軟性により、クラウドは常に変化し続ける。 クラウドのセキュリティは、内部 /外部環境の素早い変化への適応を欠かすことはできない。 パブリッククラウドの特徴③ 20 クラウドの進化と変化への適応 引用：「AWS Partner Summit Tokyo 2021基調講演レポート 」 引用：「Google Cloud release notes」
21. パブリッククラウドのセキュリティの課題 21 パブリッククラウドの特徴を理解し、利用者の責任範囲おいて適切に管理・運用を行う必要がある。 しかし、数多くのクラウドに対して抜け漏れなく設定ミス等の問題を防ぐのは、簡単なことではない。 Visional グループでも、AWS や GCP のパブリッククラウドを利用して各種サービスを展開しており、 クラウドにおける設定ミスや脆弱性に起因するインシデントが度々発生して課題となっていた。 責任共有モデル サービス利用形態 進化と変化への追従
22. クラウドにおける脆弱性とソリューション 22 • Visional について • Visional の CCoE について • クラウド時代のセキュリティの課題 • クラウドにおける脆弱性とソリューション • Visional グループにおける取り組み • まとめ
23. 「脆弱性」とは 　「ソフトウェア等におけるセキュリティ上の弱点」のことで「セキュリティホール」とも呼ばれます。 （IPA） 脆弱性について 23 ◦ なりすまし ◦ 改ざん ◦ 否認 ◦ 情報漏洩 ◦ サービス拒否 ◦ 特権昇格 資産 Assets 脆弱性 Vulnerability 脅威 Threats ◦ バグ ◦ 設定ミス ◦ 考慮漏れ ◦ etc.. ◦ 機密情報 ◦ 個人情報 ◦ コンテンツ ◦ etc.. セキュリティリスク ＝ 　資産　×　脆弱性　×　脅威 （Assets） （Vulnerability） （Threats） リスク 脆弱性はセキュリティのリスクを考える際の要素の１つ。
24. 脆弱性について 24 クラウドの脆弱性 • アプリケーションコード ◦ 設計やコーディングにて混入した開発したアプリケーション コードの脆弱性 • ライブラリ/フレームワーク ◦ アプリケーションで利用されるライブラリやフレームワークの 脆弱性 • インスタンス/コンテナイメージ ◦ アプリケーションを動作させるワークロードの脆弱性 アプリケーション の脆弱性 ワークロードの脆弱性 • クラウドの設定 ◦ クラウドの設定ミスや考慮漏れによる脆弱性 クラウドへアプリケーションを展開する際のレイヤー別の脆弱性 〈/〉 lib
25. • セキュリティグループは 0.0.0.0/0 からポート 22 へのインバウンドを許可している ◦ SSH ポートへインターネットからの接続を許可した場合、サーバが脅威に晒される可能性がある。 • RDS（非暗号化）のスナップショットがパブリックで復元可能になっている ◦ 秘匿情報の含まれたスナップショットを公開した場合、情報漏洩が起こる可能性がある。 • S3 バケットでパブリック書き込みアクセスが許可されている ◦ 提供するシステムのデータが改竄されてる可能性がある。 • リソースのログ記録が有効になっていない ◦ 直接的なセキュリティ事故には繋がらないが、対象リソースの追跡調査が行えない問題が発生する。 脆弱性について 25 クラウドの設定を誤るとセキュリティ事故や運用上の支障が簡単に発生する。 「クラウドの脆弱性」とは 適切でないクラウドの設定例（ AWS の一例）
26. CSPM（Cloud Security Posture Management） 脆弱性に対するソリューション 26 クラウドの脆弱性 設定ミス / 考慮漏れ xAST（Application Security Testing） SCA（Software Composition Analytics） CWPP（Cloud Workload Protection Platform） 脆弱性診断 アプリケーション の脆弱性 ソースコード / ライブラリ / FW ワークロードの脆弱性 インスタンス / コンテナイメージ
27. 脆弱性に対するソリューション 27 レイヤー ソリューション ソリューション概要 製品・サービス例 アプリケーション xAST Application Security Testing SAST（静的）、DAST（動的）、IAST（インタラクティブ） からなるセ キュリティテストツールで主にアプリケーションの脆弱性を検出する。 Coverity、AWS CodeGuru Reviewer、AppScan、Fortify WebInspect、Tenable.io WAS、Contrast Assess、 Seeker SCA Software Composition Analytics ソフトウェアで使用されているオープンソース・ライブラリとコンポーネ ントを特定して脆弱性を検出する。 yamory、Snyk、Black Duck ワークロード CWPP Cloud Workload Protection Platform クラウドのワークロードを中心とした監視と保護のセキュリティソ リューションで、脆弱性スキャンを始め、システム整合性保護、 ID ベースのマイクロセグメンテーション、アプリケーション制御、メモリ保 護、動作監視、ホストベースの侵入防止などの機能とマルウェア対策 を行う。 Prisma Cloud、Aqua、 CloudGuard、sysdig クラウド CSPM Cloud Security Posture Management クラウドの設定ミスなどの問題の検出やコンプライアンス、ロギング、 レポート、対応の自動化により、クラウドセキュリティの体制を管理す る。 Prisma Cloud、Aqua、 CloudGuard、sysdig
28. Visional グループにおける取り組み 28 • Visional について • Visional の CCoE について • クラウド時代のセキュリティの課題 • クラウドにおける脆弱性とソリューション • Visional グループにおける取り組み • まとめ
29. CCoE とセキュリティ部門が連携し、自動的に脆 弱性を評価する仕組みを提供 脆弱性を可視化して問題への対応を促す 評価 横断的な脆弱性への取り組みに対する考え 29 事業 事業 事業 事業 セキュリティ部門 CCoE クラウド プラットフォーム セントラル 個社・事業 Visional グループとして • クラウドを用いたプロダクト開発運用は各個社 ・事業に委ねる • グループ会社として一定のセキュリティの担保 が必要 • 厳しいポリシーで縛らず、自由度高く安全なシ ステム運用を目指す 可視化 （脆弱性診断） ‥
30. AWS / GCP のクラウドやワークロード、アプリケーションの脆弱性を評価する取り組み。 利用している SaaS /クラウドサービスは下記の通り。 脆弱性を評価する取り組みの全体像 30 レイヤー AWS GCP アプリケーション yamory yamory ワークロード CaaS（コンテナ） Amazon Elastic Container Registry （Image scanning） - IaaS（インスタンス） Amazon Inspector Classic - クラウド AWS Config Security Command Center （Security Health Analytics） クラウドやワークロードについては、各クラウドのマネージドサービスを利用して実現 ※ GCP のワークロードは対象リソースが少ないため、現在は個社・事業の管理者へ対応を委ねている。
31. AWS におけるクラウドの脆弱性への取り組み 31 クラウドレイヤー × CSPM （Cloud Security Posture Management）
32. Landing Zone サービス 発見的ガードレールを利用したチェック が可能 • 必須のガードレール (2項目) • 強く推奨されるガードレール (11項目) • 選択式ガードレール (17項目) ※ 項目数は発見的（検出）のみ ※ AWS 組織を Control Tower で管理している場 合のみガードレールを利用可能 32 AWS における CSPM ライクのソリューション AWS Control Tower AWS Security Hub AWS Config マネージド 柔軟性/ルール数 セキュリティデータの一元管理・可視 化するサービス セキュリティ標準によるチェックが可能 • CIS AWS Foundations Benchmark (43項目) • PCI DSS (46項目) • AWS Foundational Security Best Practices 　 standard (153項目) ※項目数はコントロール/ルールの数（2022.05時点） AWS におけるクラウドの脆弱性への取り組み AWS リソースの設定を記録・評価す るサービス マネージドルールやルール群をパッケージ 化した適合パックを利用してチェックや修復 アクションの呼び出しが可能 • 適合パック (79種類) • マネージドルール (276項目) 　 ※ 独自評価ロジックのカスタムルール作成可
33. クラウドの脆弱性の評価には、 AWS Config を採用している。 選定理由（2019年導入当初） • ControlTower は、当時東京リージョンは未提供。 • AWS Security Hub のセキュリティ標準は当時 CIS AWS Foundations Benchmark のみでチェッ ク可能な項目数が少なく、また不要なコントロールが無効化できなかった。 自社ポリシーに沿った柔軟な評価を行うため、マネージドルールを選定できて、カスタムルール を作成できる AWS Config を選択。 33 Visional における ソリューション選定 AWS Config AWS におけるクラウドの脆弱性への取り組み
34. 現在採用しているルール数 • マネージドルール：約 45 個 • カスタムルール：約 6 個 マネージドルール選定方針 • 社内のセキュリティポリシー（規程類）に沿っているか • ルール非準拠におけるリスクが明確か • ルールに対する準拠が基本的に必須か 34 Visional における ルール選定 AWS におけるクラウドの脆弱性への取り組み 選定していないルールの特徴 • CCoE で AWS 組織全体で対策が取られているもの • リスクが明確ではない/優先度の低いルール ◦ 不要リソースの検出に関わるルール ◦ コスト削減に関わるルール　等 • 多くの対処不要の例外が発生しうるルール
35. コントロール マネージドルール データ保護 RDS スナップショットがパブリック公開されていないこと EBS スナップショットがパブリック公開されていないこと アカウント管理 ルートユーザに IAM アクセスキーが存在しないこと ルートアカウントの MFA が有効化されていること 監査ログ管理 各種ログの出力設定が有効化されていること データ復旧 RDS のバックアップが有効になっていること Redshift のバックアップが有効になっていること ネットワークインフラストラクチャ管理 セキュリティグループの認可外ポートをインターネットに開放していないこと RDS インスタンスへパブリックアクセスできないこと DMS レプリケーションインスタンスへパブリックアクセスできないこと Redshift クラスタへパブリックアクセスできないこと AWS Lambda 関数へのパブリックアクセスができないこと 35 採用している Config ルールの一例 AWS におけるクラウドの脆弱性への取り組み ※ コントロールは、CIS Controls v8 により分類 全約 50 個
36. 評価結果は組織の全アカウント /リージョンの 結果を集約して、 Amazon OpenSearch Service へストアし、OpenSearch Dashboard を利用し て、一元的に可視化。 可視化項目 • 全体/アカウント毎の準拠率 • 準拠率や準拠/非準拠数の推移 • ルール毎の準拠/非準拠数 • アカウント毎の準拠/非準拠数 • 重要度ラベル毎の非準拠数 • 非準拠リソースのRAWデータ（詳細情報等） 36 状況の可視化 AWS におけるクラウドの脆弱性への取り組み ‥
37. ルールに違反した非準拠のリソースが検出された場合、 Slack にて担当者とセキュリティ部門へ ”非準拠通知” を自 動送信。 担当者は早い段階でリスクのある設定を検知して早期に対 処することができる。 対処後の評価で準拠となると、 ”解決通知” を自動送信。 37 通知 非準拠検出時に通知 メッセージを解決へ更新 非準拠解決後 AWS におけるクラウドの脆弱性への取り組み
38. ルール準拠状況レポートを通知 月次でアカウント全体のルール準拠状況に関するサマ リーレポートを自動で通知。 「準拠率や改善率（前月比）の高いアカウントの賞賛」や 「準拠率の低いアカウントへ危機意識を醸成」するための 機会としている。 38 レポート AWS におけるクラウドの脆弱性への取り組み ‥ ‥
39. システム構成 AWS におけるクラウドの脆弱性への取り組み ※システム構成の詳細は以下参照 「AWS Config による継続的コンプライア ンス実現に向けた取り組み」 39 アカウント群のセットアップ • AWS Config 有効化 AWS 組織全体へのルールの展開 • Organization Config Rule AWS 組織全体の評価結果集約 • Config Aggregator で結果集約 ニアリアルタイムの通知 • Event Bridge のイベント集約 https://speakerdeck.com/nagahara/co ntinuous-compliance-with-aws-config
40. 40 運用開始後の状況 2020年4月運用開始後、当初の 80% 以上の非準拠リソースを改善。運用途中の検出にも適宜対応。 CloudTrail 組織証跡 設定により大幅な改善 ルール追加に よる増加 AWS におけるクラウドの脆弱性への取り組み 非準拠リソース数の推移
41. 41 エンジニアが自律的に対応する文化 担当者へ非準拠を通知することにより、各担当者が自律的に対処する文化が定着してきている。 AWS におけるクラウドの脆弱性への取り組み
42. GCP におけるクラウドの脆弱性への取り組み 42 × CSPM （Cloud Security Posture Management） クラウドレイヤー
43. • GCP 向けのセキュリティおよびリスク管理プラットフォーム • スタンダードティア（無償） と プレミアムティア（有償） の 2 つのティアの提供 43 GCP における CSPM ライクなソリューション Security Command Center (SCC) GCP におけるクラウドの脆弱性への取り組み 機能 機能概要 スタンダードティア（無償） プレミアムティア（有償） Security Health Analytics クラウドの脆弱性と構成ミスを 自動的に検出 一部利用可（19項目のみチェック） 利用可（CIS など各種基準に対する 140項目以上のチェック） Web Security Scanner アプリケーションの脆弱性ス キャン 一部利用可（公開 URL と IP のアプ リケーションのみスキャン） 利用可（アプリ脆弱性を含めスキャン） Event Threat Detection クラウドの脅威検知 利用不可 利用可 Container Threat Detection コンテナへの攻撃を検知 利用不可 利用可
44. Security Command Center（SCC）のプレミアムティアを採用 プレミアムティアの選択理由 • クラウドの設定ミスや脆弱性を検出する Security Health Analytics の検出タイプがス タンダードティアでは少ない • クラウドの脅威検出を合わせて行うためスタンダードティアでは利用できない • 組織レベルでの利用だけでなく、フォルダ /プロジェクトレベルで IAM ロールの付与 をサポートする。 44 Visional におけるソリューション選定 Security Command Center GCP におけるクラウドの脆弱性への取り組み プレミアムティアの料金（年契約 / 月単位の支払い） • GCP 全体の利用料金の 5% • 最小年間料金 $25,000
45. Security Health Analytics（SHA）は、全てのカテゴリがプロジェクト全体で自動的に評価される。 全てのカテゴリの評価後に結果も踏まえて対応すべきカテゴリを選定する。 選定の方針は AWS と同様で、社内ポリシーとも突き合わせて対応必須なものを選定している。 対応する対象として選定したカテゴリは以下。 • カテゴリ：約 60 個 • カスタムカテゴリ：1 個 45 Security Health Analytics のカテゴリ（ルール）の選定方式 GCP におけるクラウドの脆弱性への取り組み ルール 選定 SCC 導入 結果 確認 結果 確認 カテゴリ 選定 ルール評価数当たりの従量課金のため 事前に評価するルールに絞り混む カテゴリの数に関わらず費用は一定のため 最後に必要なものに絞り込む AWS Config のルール選定の流れ SHA のカテゴリ選定の流れ ルール 導入 ルール 見直し ( )
46. コントロール カテゴリ データ保護 Compute Engine イメージがパブリック公開されていないこと BigQuery データセットが一般公開されていないこと ログシンクとして使用されているストレージバケットが一般公開されていないこと Cloud KMS 暗号鍵または Cloud KMS キーリングが一般公開されていないこと 組織の資産とソフトウェアの安全な構成 Dataproc クラスタは、Apache Log4j 2 ユーティリティのセキュリティの脆弱性による影響を受ける Dataproc イメージ バージョンを使用していないこと アカウント管理 組織外のユーザーにプロジェクトまたは組織の IAM 権限が付与されていないこと MySQL データベースのルートアカウントに脆弱なパスワードが設定されていないこと 監査ログ管理 各種ログの出力設定が有効化されていること データ復旧 Cloud SQL の自動バックアップが有効になっていること ネットワークインフラストラクチャ管理 ファイアウォールルールにて認可外ポートを一般開放していないこと Cloud SQL データベースに、パブリック IP アドレスがないこと Compute Engine インスタンスに脆弱な SSL ポリシーがないこと 46 採用している SHA のカテゴリの一例 GCP におけるクラウドの脆弱性への取り組み ※ コントロールは、CIS Controls v8 により分類 全約 60 個
47. 47 カスタムカテゴリの評価 GCP におけるクラウドの脆弱性への取り組み スケジューラ実行される Cloud Functions にて Cloud Asset Inventory のリソース情報を参照してカスタムロジック による評価と SCC へ独自のセキュリティソースの Findings を登録する。
48. SCC のダッシュボードで選定したカテゴリのみ可視化。組織 /フォルダ/プロジェクトの単位で閲覧可能。 48 検知結果の可視化 GCP におけるクラウドの脆弱性への取り組み
49. 49 ミュートルールの設定 GCP におけるクラウドの脆弱性への取り組み 選定したカテゴリ以外をミュートルールに設定することで、 ダッシュボードでは対応すべき脆弱性を直感的に把握することが可能 • Mute Rules は検出結果やリソースの情報を Query による条件を設定 ※ミュートされた検出結果も「Include muted findings」より閲覧が可能
50. 現状では通知は行っていない。選定したカテゴリだけでも多くの脆弱性が検出されているため、優先度の高 いものを計画的に対応を進めているフェーズ。 既存の脆弱性の対処が進んだ後に、カテゴリに違反したリソースが検出された場合は、担当者へ通知して早 期に対処を行う運用を開始する予定。 通知を行う場合は、以下のアーキテクチャにて Cloud Functions 経由にて Slack 等への通知が可能。 50 通知 GCP におけるクラウドの脆弱性への取り組み 引用：「リアルタイム メールとチャットの通知を有効にする 」
51. 51 AWS におけるワークロードの脆弱性への取り組み CWPP （Cloud Workload Protection Platform） ワークロード レイヤー ×
52. 52 AWS のワークロード保護に関わるソリューション Amazon Inspector (Classic) Amazon Elastic Container Registry インスタンス脆弱性スキャン • EC2 インスタンスの動的スキャン • Inspector Agent を導入したインスタンス をスキャン可能 • CVE評価の他にネットワーク到達可能性 評価やホスト評価（ CISベンチマーク）も 可能 コンテナイメージ脆弱性スキャン • コンテナイメージの静的スキャン • スキャンの費用は無料 • 同イメージは24時間あたり1回のスキャン が上限 AWS におけるワークロードの脆弱性への取り組み AWS では CWPP に相当するサービスは提供されていないが、ワークロード（コンテナイメージ、インスタン ス）の脆弱性をスキャンするサービスを提供。 Amazon Inspector (v2) 脆弱性管理サービス • AWS re:Invent 2021 にて発表（2021/11） • EC2 インスタンスとコンテナイメージの脆弱性 スキャンに対応 • コンテナイメージは、プッシュ時や脆弱性情 報更新時の継続的な自動スキャン • インスタンスは、 SSM Agent を用いて構成変 更時と脆弱性情報更新時の継続的な自動ス キャン
53. 53 Visional における選定 Inspctor Classic & ECR Scanning Inspector (Classic) ECR Amazon Inspector v2 のリリース前に構築したプラットフォームのため、現在 は Inspector Classic と ECR Scanning の組み合わせで AWS 組織全体のインス タンスとコンテナイメージの脆弱性スキャンを実施。 Inspector v2 への移行を検討したが、コンテナイメージでは以下の制約が あったため移行は先送りとしている。 • 「30日間プッシュされていないコンテナイメージはスキャンされない」＆ 「手動スキャンが行えない」 ◦ 30日以上更新のないイメージにおいてもプロダクション環境で動 作するものは脆弱性スキャン対象としたいため AWS におけるワークロードの脆弱性への取り組み
54. 54 可視化 AWS におけるワークロードの脆弱性への取り組み スキャン結果は組織の全アカウント /リー ジョンの結果を Amazon OpenSearch Service へ集約し、OpenSearch Dashboard を利用して、一元的に可視化。 以下のデータを可視化。 • 深刻度毎の現在の脆弱性件数/推移 • アカウント毎の脆弱性の件数/推移 • アカウント/リージョン/深刻度毎の割合 • 最新の脆弱性詳細一覧 ‥
55. 現在 AWS 組織全体のワークロードの評価 は週次で行っている。 評価完了後にセキュリティ部門へ通知し、 結果確認の上で一定の深刻度以上の脆 弱性については、担当者へ連絡する形で 運用を行っている。 55 通知 コンテナイメージ インスタンス AWS におけるワークロードの脆弱性への取り組み
56. 56 システム構成（インスタンスのスキャン） AWS におけるワークロードの脆弱性への取り組み 初期セットアップ • 全 AWS アカウントの Inspector サービスの有効 化、評価ターゲットと評価テンプレートの作成 • 各インスタンスへエージェントの導入 脆弱性情報収集機能（Load Vulnerability Info） • アドバイザリ（NVD）より脆弱性情報を最新 化（PoC の情報収集） 評価機能（IaaS Execute Assessment） • 定期実行と手動実行の実行契機 • セキュリティアカウントより全アカウントへ評価 実行指示 • 全評価完了後に評価結果の Findings を取得し て独自の深刻度判定結果と付加情報を加えて SecurityHub の Findings を更新（更新後データ は OpenSearch Service へ連携） • 最後に結果の集計と Slack通知
57. 57 システム構成（コンテナイメージのスキャン） AWS におけるワークロードの脆弱性への取り組み ※右側はインスタンスの スキャンと共通 脆弱性情報収集機能（Load Vulnerability Info） • アドバイザリ（NVD）より脆弱性情報を最新化 ◦ PoCの情報収集 ◦ ECR の Findings には CVSS v2 の情報しか含 まれないため、CVSS v3 の情報取得 評価機能（CaaS Execute Image Scan） • 定期実行と手動実行の実行契機 • セキュリティアカウントより全アカウントへ評価実行 指示 ◦ 各レポジトリの imagePushedAt が最新のイメー ジを対象 • 全評価完了後に ECRより評価結果の Findings を取 得して独自の深刻度判定と独自情報を付加して SecurityHub の ASFF（AWS SecurityHub Findings Format）にて SecurityHub へ Findings として登録（登 録データは OpenSearch Service へ連携） • 最後に結果の集計と Slack 通知
58. 深刻度（Critical/High/Medium/Low）はマネージドサービスによる結果ではなく独自ロジックにて判定 外部からの攻撃を受ける可能性が高い脆弱性 /環境特性を優先的に対応 58 独自の深刻度判定 AWS におけるワークロードの脆弱性への取り組み 脆弱性のリモート攻撃の適否 攻撃コード（PoC）の有無 アタックサーフェイスの適否 脆弱性の CVSS v3 Base Metrics の Attack Vector (AV) が Network か否か （インスタンスのみ） Inspector のネットワーク到達可能性 スキャンにて外部から到達が可能な インスタンスか 脆弱性の攻撃コード（Proof of Concept code）が公開されているか 合致する場合、 CVSS v3 Score に応じて優先対応の深刻度を設定
59. 59 SCA （Software Composition Analytics） × アプリケーションの脆弱性への取り組み アプリケーション レイヤー
60. 60 アプリケーションの脆弱性への取り組み 「yamory」は、アプリケーション、ミドルウェア、 OS の 脆弱性対策 と ライセンス違反検知 を行える国産のクラウドサービスです。 ソフトウェアの 利用状況を自動把握 yamory独自の 脆弱性データベースと照合 １ 2 3 脆弱性を危険度別に一元管理 脆弱性管理クラウド「yamory」
61. 61 アプリケーションの脆弱性への取り組み 複数のツール・部門で管理していた、様々な階層のオープンソースの脆弱性を 「ワンストップ」で横断的に可視化・一元管理できる環境を実現 OS 言語実行環境 WebApp サーバー ライブラリ フレームワーク Jackson, Hibernate など ライブラリ フレームワーク WebAppサーバー 言語実行環境 OS Spring, Struts など Apache Tomcat など Java など Linux など 全体ダッシュボードで 一元管理！ セキュリティチーム （開発チームの横断管理が可能） 開発チーム （開発チーム間での情報共有は不可） 脆弱性管理クラウド「yamory」
62. 脆弱性を評価する取り組みの全体像（再掲） 62 レイヤー AWS GCP アプリケーション yamory yamory ワークロード CaaS（コンテナ） Amazon Elastic Container Registry （Image scanning） - IaaS（インスタンス） Amazon Inspector Classic - クラウド AWS Config Security Command Center （Security Health Analytics）
63. • クラウド利用者はアジリティを損なうことなく、 脆弱性を検知して素早く対処することが可能 • クラウドのルールへの適合状況により会社 で定めた一定のセキュリティを保証 • 横断的なソリューションの展開により個別事 業の業務を効率化 • 組織全体のクラウドに関わる脆弱性を可視 化して状況を把握 • グループ会社として脆弱性に対するリスクコ ントロールが可能 • 新規事業の立ち上げのしやすさを獲得 事業（開発部門） グループ会社 グループ会社におけるクラウド全体の脆弱性を可視化 取り組みを通して 63
64. 課題や今後の展望 • 脆弱性への対応促進 ◦ AWS のクラウドの改善は一定進んだが、その他は未だ多くの脆弱性が存在 脆弱性の対応を促進するためのソリューションの展開や横断的な対策の実施 • マルチクラウド/マルチレイヤーの管理効率化 ◦ 各クラウド・レイヤー毎に個別のサービスを利用しているが管理が煩雑化 改めてサードパーティのサービス活用も含めて効率的な管理・運用方法を検討 • 開発組織に最適化したセキュリティの実装 ◦ 高いセキュリティを実現するには開発ライフサイクルへのセキュリティの統合が必須 各開発組織へ DevSecOps を浸透を進め、セキュアで迅速な開発・運用を目指す 64
65. まとめ 65 • Visional について • Visional の CCoE について • クラウド時代のセキュリティの課題 • クラウドにおける脆弱性とソリューション • Visional グループにおける取り組み • まとめ
66. • 変化の速いクラウドは、継続的な評価により脆弱性を早期に検出し対処していくことが重要。 ◦ 共通で利用されるクラウドには横断的なソリューションを展開可能。 ◦ 各開発組織でも開発ライフサイクルにセキュリティを組み込む。 • 組織全体で脆弱性に適切に対応し続ける体制を構築し、セキュリティとアジリティを両立する。 • クラウドの設定 まとめ 66 • クラウド市場は今後も成長、脆弱性や設定ミスによるセキュリティ事故への十分な備えが必要。 • クラウドの責任範囲を正しく理解し、サービス /ツールを活用して各レイヤーの脆弱性を評価する。 クラウドの脆弱性 アプリケーション の脆弱性 ワークロードの脆弱性 CSPM（Cloud Security Posture Management） xAST（Application Security Testing） SCA（Software Composition Analytics） CWPP（Cloud Workload Protection Platform） • アプリケーションコード • ライブラリ/フレームワーク • コンテナイメージ • インスタンス 〈/〉 lib
67. 67 We are hiring. https://www.visional.inc/ja/careers.html Visional Tech Blog https://engineering.visional.inc/blog/ Thank you.
68. Appendix 68
69. • AWS Summit Online Japan 2020 「大規模な組織変遷と100以上のAWSアカウントの横断的セキュリティガードレール運用について」
 ▪ https://pages.awscloud.com/rs/112-TZM-766/images/CUS-06_AWS_Summit_Online_2020_Visional%20Inc.pdf 
 • Visional Engineering Blog 「100を超えるAWSアカウント運用におけるガードレール構築事例」
 ▪ https://engineering.visional.inc/blog/171/awssummit_securityguardrail/ 
 • Security-JAWS 第19回 「AWS Config による継続的コンプライアンス実現に向けた取り組み」
 ▪ https://speakerdeck.com/nagahara/continuous-compliance-with-aws-config 
 • AWS Dev/Cloud Alliance 第1回 「CCoE による Terraform を活用した Infrastructure as Code」
 ▪ https://speakerdeck.com/nagahara/iac-by-terraform-in-ccoe 
 • CloudNative Days Tokyo 2021 「実践：Cloud Center of Excellence を中心としたクラウド戦略」
 ▪ https://speakerdeck.com/_awache/the-practice-of-cloud-center-of-excellence 
 • Google Cloud Security Summit 「Visional における CCoE 組織とセキュリティ ガードレール整備の取り組み」
 ▪ https://services.google.com/fh/files/events/security-d1-05.pdf 
 • 書籍 「DXを成功に導くクラウド活用推進ガイド CCoEベストプラクティス」（先進事例企業として登場）
 ▪ https://www.amazon.co.jp/dp/4296070150 
 69 参考情報