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

18K Views

June 10, 22

スライド概要

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

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

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
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.

アジェンダ ● Visional について ● Visional の CCoE について ● クラウド時代のセキュリティの課題 ● クラウドにおける脆弱性とソリューション ● Visional グループにおける取り組み ● まとめ 3

4.

● Visional について ● Visional の CCoE について ● クラウド時代のセキュリティの課題 ● クラウドにおける脆弱性とソリューション ● Visional グループにおける取り組み ● まとめ Visional について 4

5.

グループ概要 設立 :2020年2月(ビジョナル株式会社設立) 創業 :2009年4月(株式会社ビズリーチ創業) 代表者 :ビジョナル株式会社 代表取締役社長 南 壮一郎 グループ従業員数:1,469名(2021年7月末時点) 資本金 拠点 :164億円(資本準備金含む)※2021年5月18日時点 :東京、大阪、名古屋、福岡、静岡、広島 5

6.

グループミッション 6

7.

グループ運営サービス 人材マネジメント( HR Tech)エコシステム 採用プラットフォーム 人財活用プラットフォーム インキュベーション(新規事業領域) 事業承継M&A 物流Tech サイバーセキュリティ Sales Tech 7

8.

グループ経営体制について 株式会社 ビズリーチ HR Techの プラットフォームや SaaS 事業の運営 ビジョナル ・ インキュベーション 株式会社 M&A サクシード トラボックス 株式会社 株式会社 新規事業開発 法人・審査制 M&Aマッチングサイト 「M&Aサクシード」の運営 物流 DX プラットフォーム 「トラボックス」 の運営 株式会社 スタンバイ 求人検索エンジン 「スタンバイ」 の運営 ※Zホールディングス株式会社 との合弁事業会社 ビジョナル株式会社(ホールディングカンパニー) 8

9.

● Visional について ● Visional の CCoE について ● クラウド時代のセキュリティの課題 ● クラウドにおける脆弱性とソリューション ● Visional グループにおける取り組み ● まとめ Visional の CCoE について 9

10.

Visional の CCoE について CCoE(Cloud Center of Excellence)は、クラウド活用をより推進するための専門組織。 < 役割 > < 構造 > ● クラウド戦略計画・推進 ユーザ部門 ● クラウド全体管理 ● クラウドガバナンス ● クラウドプラットフォーム開発運用 ● ナレッジ管理 ● 技術支援 統制 監査 セキュリティ 部門 ● トレーニング バックオフィス (経理、法務、人事) 技術支援 情報提供 提供 相談 問合せ フィードバック ポリシー、ナレッジ、 クラウドプラットフォーム 連携 連携 CCoE 連携 ● コミュニティ活動 ● など 相談 ※クラウド利用者 フィードバック クラウド関連 レポーティング 経営 クラウド ベンダー 活動 外部 コミュニティ 10

11.

Visional のパブリッククラウド利用状況 フルクラウドでサービス運営 ● 2012年に「ビズリーチ」をクラウド移行済 ○ 以後の新規サービスはクラウドにて構築 ● オンプレミス環境は保有していない ● パブリッククラウドがデフォルトの選択肢 パブリッククラウドの利用規模 100 以上 (AWS アカウント数) 75 以上 (GCP プロジェクト数) ※アクティブのみ 11

12.

セキュリティに関わる組織体制 ビジョナル(株)にグループ全体のセキュリティを統括する組織を設置。 事業部 事業部 事業部 (株) ビズリーチ 事業部 事業部 事業部 ビジョナル・ インキュベーション (株) 事業部 事業部 (株) M&A サクシード トラボックス (株) 各事業部にエンジニア チームが存在し、パブ リッククラウドを運用 CISO 管掌組織 抜粋 セキュリティ室 IT統制/セキュリティ推進 グループ 品質管理 グループ セキュリティオペレーション グループ セキュリティ関連文書管理 リスクアセスメント/監査 チェックシート実施 脆弱性診断 コーポレートインフラ監視 プロダクトセキュリティ監視 セキュリティ技術検証 グループ IT室 コーポレート ITグループ クラウドインフラ グループ(CCoE) パブリッククラウドのセキュリティに 関わる業務を “セキュリティ室” と協業 ビジョナル (株) 12

13.

● Visional について ● Visional の CCoE について ● クラウド時代のセキュリティの課題 ● クラウドにおける脆弱性とソリューション ● Visional グループにおける取り組み ● まとめ クラウド時代のセキュリティの課題 13

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 の自治体や国内企業の個人情報等が設定ミスにより外部か ら閲覧可能であったと報道され、設定ミスによる漏えいが相次いでいる。 引用:「IPA - 情報セキュリティ白書2021」 15

16.

パブリッククラウドの特徴 責任共有モデル サービス利用形態 進化と変化への追従 16

17.

パブリッククラウドの特徴① 責任共有モデル クラウドの利用者とサービスプロバイダの責任分担 例:AWS の責任共有モデル(右図) ● 利用者の責任: クラウド における セキュリティ(Security ‘in’ the Cloud) ● サービスプロバイダの責任: クラウド の セキュリティ(Security ‘of’ the Cloud) クラウド利用者は責任範囲を正しく理解し、責任を持って適切 な対応が必要 責任範囲の認識不足も、設定ミスを招く要因となる。 引用:「AWS / 責任共有モデル 」 17

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 サービスにより利用者の責任範囲のスコープが異なる。 管理する範囲が多いほど自由度は高いが、トレードオフで 責任範囲が広がるため、選定時に考慮 引用:「DX白書2021」 18

19.

パブリッククラウドの特徴② サービス利用形態 パブリッククラウドは、インターネット経由で利用する利用形態。 個々のリソースの設定ミスから重大な事故に繋がる可能性があるため、利用するサービス・リソースごとに適切な アクセス制御や権限管理、防御策を施す必要がある。 従来のネットワーク境界 パブリッククラウド 19

20.

パブリッククラウドの特徴③ クラウドの進化と変化への適応 クラウドの進化は速く、パブリッククラウド毎に年間数千件を超えるアップデートが提供されている。 また、昨今のアジャイル開発の浸透とクラウドの柔軟性により、クラウドは常に変化し続ける。 クラウドのセキュリティは、内部 /外部環境の素早い変化への適応を欠かすことはできない。 引用:「AWS Partner Summit Tokyo 2021基調講演レポート 」 引用:「Google Cloud release notes」 20

21.

パブリッククラウドのセキュリティの課題 パブリッククラウドの特徴を理解し、利用者の責任範囲おいて適切に管理・運用を行う必要がある。 責任共有モデル サービス利用形態 進化と変化への追従 しかし、数多くのクラウドに対して抜け漏れなく設定ミス等の問題を防ぐのは、簡単なことではない。 Visional グループでも、 AWS や GCP のパブリッククラウドを利用して各種サービスを展開しており、 クラウドにおける設定ミスや脆弱性に起因するインシデントが度々発生して課題となっていた。 21

22.

● Visional について ● Visional の CCoE について ● クラウド時代のセキュリティの課題 ● クラウドにおける脆弱性とソリューション ● Visional グループにおける取り組み ● まとめ クラウドにおける脆弱性とソリューション 22

23.

脆弱性について 「脆弱性」とは 「ソフトウェア等におけるセキュリティ上の弱点」のことで「セキュリティホール」とも呼ばれます。 (IPA) 脆弱性はセキュリティのリスクを考える際の要素の1つ。 ○ 機密情報 ○ 個人情報 セキュリティリスク = 資産 × 脆弱性 × 脅威 (Assets) (Vulnerability) (Threats) 資産 ○ コンテンツ Assets ○ etc.. ○ なりすまし ○ バグ ○ 設定ミス ○ 考慮漏れ ○ etc.. ○ 改ざん リスク 脆弱性 脅威 Vulnerability Threats ○ 否認 ○ 情報漏洩 ○ サービス拒否 ○ 特権昇格 23

24.

脆弱性について クラウドへアプリケーションを展開する際のレイヤー別の脆弱性 〈/〉 アプリケーション の脆弱性 lib ワークロードの脆弱性 クラウドの脆弱性 ● アプリケーションコード ○ 設計やコーディングにて混入した開発したアプリケーション コードの脆弱性 ● ライブラリ/フレームワーク ○ アプリケーションで利用されるライブラリやフレームワークの 脆弱性 ● インスタンス/コンテナイメージ ○ アプリケーションを動作させるワークロードの脆弱性 ● クラウドの設定 ○ クラウドの設定ミスや考慮漏れによる脆弱性 24

25.

脆弱性について 「クラウドの脆弱性」とは 適切でないクラウドの設定例( AWS の一例) ● セキュリティグループは 0.0.0.0/0 からポート 22 へのインバウンドを許可している ○ SSH ポートへインターネットからの接続を許可した場合、サーバが脅威に晒される可能性がある。 ● RDS(非暗号化)のスナップショットがパブリックで復元可能になっている ○ 秘匿情報の含まれたスナップショットを公開した場合、情報漏洩が起こる可能性がある。 ● S3 バケットでパブリック書き込みアクセスが許可されている ○ 提供するシステムのデータが改竄されてる可能性がある。 ● リソースのログ記録が有効になっていない ○ 直接的なセキュリティ事故には繋がらないが、対象リソースの追跡調査が行えない問題が発生する。 クラウドの設定を誤るとセキュリティ事故や運用上の支障が簡単に発生する。 25

26.

脆弱性に対するソリューション アプリケーション の脆弱性 xAST(Application Security Testing) SCA(Software Composition Analytics) ソースコード / ライブラリ / FW 脆弱性診断 ワークロードの脆弱性 インスタンス / コンテナイメージ クラウドの脆弱性 設定ミス / 考慮漏れ CWPP(Cloud Workload Protection Platform) CSPM(Cloud Security Posture Management) 26

27.

脆弱性に対するソリューション レイヤー アプリケーション ソリューション xAST Application Security Testing SCA Software Composition Analytics ワークロード CWPP Cloud Workload Protection Platform クラウド CSPM Cloud Security Posture Management ソリューション概要 製品・サービス例 SAST(静的)、DAST(動的)、IAST(インタラクティブ) からなるセ キュリティテストツールで主にアプリケーションの脆弱性を検出する。 Coverity、AWS CodeGuru Reviewer、AppScan、Fortify WebInspect、Tenable.io WAS、Contrast Assess、 Seeker ソフトウェアで使用されているオープンソース・ライブラリとコンポーネ ントを特定して脆弱性を検出する。 yamory、Snyk、Black Duck クラウドのワークロードを中心とした監視と保護のセキュリティソ リューションで、脆弱性スキャンを始め、システム整合性保護、 ID ベースのマイクロセグメンテーション、アプリケーション制御、メモリ保 護、動作監視、ホストベースの侵入防止などの機能とマルウェア対策 を行う。 Prisma Cloud、Aqua、 CloudGuard、sysdig クラウドの設定ミスなどの問題の検出やコンプライアンス、ロギング、 レポート、対応の自動化により、クラウドセキュリティの体制を管理す る。 Prisma Cloud、Aqua、 CloudGuard、sysdig 27

28.

● Visional について ● Visional の CCoE について ● クラウド時代のセキュリティの課題 ● クラウドにおける脆弱性とソリューション ● Visional グループにおける取り組み ● まとめ Visional グループにおける取り組み 28

29.

横断的な脆弱性への取り組みに対する考え Visional グループとして ● クラウドを用いたプロダクト開発運用は各個社 ・事業に委ねる ● グループ会社として一定のセキュリティの担保 が必要 ● 厳しいポリシーで縛らず、自由度高く安全なシ ステム運用を目指す 個社・事業 事業 事業 事業 事業 ‥ 評価 (脆弱性診断) セントラル 可視化 クラウド プラットフォーム CCoE とセキュリティ部門が連携し、自動的に脆 弱性を評価する仕組みを提供 セキュリティ部門 CCoE 脆弱性を可視化して問題への対応を促す 29

30.

脆弱性を評価する取り組みの全体像 AWS / GCP のクラウドやワークロード、アプリケーションの脆弱性を評価する取り組み。 利用している SaaS /クラウドサービスは下記の通り。 レイヤー アプリケーション ワークロード クラウド AWS GCP yamory yamory CaaS(コンテナ) Amazon Elastic Container Registry (Image scanning) - IaaS(インスタンス) Amazon Inspector Classic - AWS Config Security Command Center (Security Health Analytics) クラウドやワークロードについては、各クラウドのマネージドサービスを利用して実現 ※ GCP のワークロードは対象リソースが少ないため、現在は個社・事業の管理者へ対応を委ねている。 30

31.

AWS におけるクラウドの脆弱性への取り組み × クラウドレイヤー CSPM (Cloud Security Posture Management) 31

32.

AWS におけるクラウドの脆弱性への取り組み AWS における CSPM ライクのソリューション AWS Control Tower Landing Zone サービス 発見的ガードレールを利用したチェック が可能 ● 必須のガードレール (2項目) ● 強く推奨されるガードレール (11項目) ● 選択式ガードレール (17項目) ※ 項目数は発見的(検出)のみ ※ AWS 組織を Control Tower で管理している場 合のみガードレールを利用可能 マネージド AWS Security Hub AWS Config セキュリティデータの一元管理・可視 化するサービス AWS リソースの設定を記録・評価す るサービス セキュリティ標準によるチェックが可能 マネージドルールやルール群をパッケージ 化した適合パックを利用してチェックや修復 アクションの呼び出しが可能 ● CIS AWS Foundations Benchmark (43項目) ● PCI DSS (46項目) ● AWS Foundational Security Best Practices standard (153項目) ● 適合パック (79種類) ● マネージドルール (276項目) ※ 独自評価ロジックのカスタムルール作成可 柔軟性/ルール数 ※項目数はコントロール/ルールの数(2022.05時点) 32

33.

AWS におけるクラウドの脆弱性への取り組み Visional における ソリューション選定 クラウドの脆弱性の評価には、 AWS Config を採用している。 AWS Config 選定理由(2019年導入当初) ● ControlTower は、当時東京リージョンは未提供。 ● AWS Security Hub のセキュリティ標準は当時 CIS AWS Foundations Benchmark のみでチェッ ク可能な項目数が少なく、また不要なコントロールが無効化できなかった。 自社ポリシーに沿った柔軟な評価を行うため、マネージドルールを選定できて、カスタムルール を作成できる AWS Config を選択。 33

34.

AWS におけるクラウドの脆弱性への取り組み Visional における ルール選定 現在採用しているルール数 ● マネージドルール:約 45 個 ● カスタムルール:約 6 個 マネージドルール選定方針 ● 社内のセキュリティポリシー(規程類)に沿っているか ● ルール非準拠におけるリスクが明確か ● ルールに対する準拠が基本的に必須か 選定していないルールの特徴 ● CCoE で AWS 組織全体で対策が取られているもの ● リスクが明確ではない/優先度の低いルール ○ 不要リソースの検出に関わるルール ○ コスト削減に関わるルール 等 ● 多くの対処不要の例外が発生しうるルール 34

35.

AWS におけるクラウドの脆弱性への取り組み 採用している Config ルールの一例 コントロール データ保護 マネージドルール RDS スナップショットがパブリック公開されていないこと EBS スナップショットがパブリック公開されていないこと アカウント管理 ルートユーザに IAM アクセスキーが存在しないこと ルートアカウントの MFA が有効化されていること 監査ログ管理 各種ログの出力設定が有効化されていること データ復旧 RDS のバックアップが有効になっていること Redshift のバックアップが有効になっていること ネットワークインフラストラクチャ管理 セキュリティグループの認可外ポートをインターネットに開放していないこと RDS インスタンスへパブリックアクセスできないこと DMS レプリケーションインスタンスへパブリックアクセスできないこと Redshift クラスタへパブリックアクセスできないこと AWS Lambda 関数へのパブリックアクセスができないこと ※ コントロールは、CIS Controls v8 により分類 全約 50 個 35

36.

AWS におけるクラウドの脆弱性への取り組み 状況の可視化 評価結果は組織の全アカウント /リージョンの 結果を集約して、 Amazon OpenSearch Service へストアし、OpenSearch Dashboard を利用し て、一元的に可視化。 可視化項目 ● ● ● ● ● ● 全体/アカウント毎の準拠率 準拠率や準拠/非準拠数の推移 ルール毎の準拠/非準拠数 アカウント毎の準拠/非準拠数 重要度ラベル毎の非準拠数 非準拠リソースのRAWデータ(詳細情報等) 36 ‥

37.

AWS におけるクラウドの脆弱性への取り組み 通知 非準拠検出時に通知 ルールに違反した非準拠のリソースが検出された場合、 Slack にて担当者とセキュリティ部門へ ”非準拠通知” を自 動送信。 担当者は早い段階でリスクのある設定を検知して早期に対 処することができる。 非準拠解決後 対処後の評価で準拠となると、 ”解決通知” を自動送信。 メッセージを解決へ更新 37

38.

AWS におけるクラウドの脆弱性への取り組み レポート ‥ ルール準拠状況レポートを通知 月次でアカウント全体のルール準拠状況に関するサマ リーレポートを自動で通知。 「準拠率や改善率(前月比)の高いアカウントの賞賛」や 「準拠率の低いアカウントへ危機意識を醸成」するための 機会としている。 38 ‥

39.

AWS におけるクラウドの脆弱性への取り組み システム構成 アカウント群のセットアップ ● AWS Config 有効化 AWS 組織全体へのルールの展開 ● Organization Config Rule AWS 組織全体の評価結果集約 ● Config Aggregator で結果集約 ニアリアルタイムの通知 ● Event Bridge のイベント集約 ※システム構成の詳細は以下参照 「AWS Config による継続的コンプライア ンス実現に向けた取り組み」 https://speakerdeck.com/nagahara/co ntinuous-compliance-with-aws-config 39

40.

AWS におけるクラウドの脆弱性への取り組み 運用開始後の状況 2020年4月運用開始後、当初の 80% 以上の非準拠リソースを改善。運用途中の検出にも適宜対応。 非準拠リソース数の推移 CloudTrail 組織証跡 設定により大幅な改善 ルール追加に よる増加 40

41.

AWS におけるクラウドの脆弱性への取り組み エンジニアが自律的に対応する文化 担当者へ非準拠を通知することにより、各担当者が自律的に対処する文化が定着してきている。 41

42.

GCP におけるクラウドの脆弱性への取り組み × クラウドレイヤー CSPM (Cloud Security Posture Management) 42

43.

GCP におけるクラウドの脆弱性への取り組み GCP における CSPM ライクなソリューション Security Command Center (SCC) ● GCP 向けのセキュリティおよびリスク管理プラットフォーム ● スタンダードティア(無償) と プレミアムティア(有償) の 2 つのティアの提供 機能 機能概要 スタンダードティア(無償) プレミアムティア(有償) Security Health Analytics クラウドの脆弱性と構成ミスを 自動的に検出 一部利用可(19項目のみチェック) 利用可(CIS など各種基準に対する 140項目以上のチェック) Web Security Scanner アプリケーションの脆弱性ス キャン 一部利用可(公開 URL と IP のアプ リケーションのみスキャン) 利用可(アプリ脆弱性を含めスキャン) Event Threat Detection クラウドの脅威検知 利用不可 利用可 Container Threat Detection コンテナへの攻撃を検知 利用不可 利用可 43

44.

GCP におけるクラウドの脆弱性への取り組み Visional におけるソリューション選定 Security Command Center(SCC)のプレミアムティア を採用 Security Command Center プレミアムティアの選択理由 ● クラウドの設定ミスや脆弱性を検出する Security Health Analytics の検出タイプがス タンダードティアでは少ない ● クラウドの脅威検出を合わせて行うためスタンダードティアでは利用できない ● 組織レベルでの利用だけでなく、フォルダ /プロジェクトレベルで IAM ロールの付与 をサポートする。 プレミアムティアの料金(年契約 / 月単位の支払い) ● GCP 全体の利用料金の 5% ● 最小年間料金 $25,000 44

45.

GCP におけるクラウドの脆弱性への取り組み Security Health Analytics のカテゴリ(ルール)の選定方式 Security Health Analytics(SHA)は、全てのカテゴリがプロジェクト全体で自動的に評価される。 全てのカテゴリの評価後に結果も踏まえて対応すべきカテゴリを選定する。 SHA のカテゴリ選定の流れ SCC 導入 結果 確認 AWS Config のルール選定の流れ カテゴリ ルール ルール 選定 選定 導入 カテゴリの数に関わらず費用は一定のため 最後に必要なものに絞り込む 結果 確認 ルール ( 見直し ) ルール評価数当たりの従量課金のため 事前に評価するルールに絞り混む 選定の方針は AWS と同様で、社内ポリシーとも突き合わせて対応必須なものを選定している。 対応する対象として選定したカテゴリは以下。 ● カテゴリ:約 60 個 ● カスタムカテゴリ: 1 個 45

46.

GCP におけるクラウドの脆弱性への取り組み 採用している SHA のカテゴリの一例 コントロール データ保護 カテゴリ Compute Engine イメージがパブリック公開されていないこと BigQuery データセットが一般公開されていないこと ログシンクとして使用されているストレージバケットが一般公開されていないこと Cloud KMS 暗号鍵または Cloud KMS キーリングが一般公開されていないこと 組織の資産とソフトウェアの安全な構成 Dataproc クラスタは、Apache Log4j 2 ユーティリティのセキュリティの脆弱性による影響を受ける Dataproc イメージ バージョンを使用していないこと アカウント管理 組織外のユーザーにプロジェクトまたは組織のIAM 権限が付与されていないこと MySQL データベースのルートアカウントに脆弱なパスワードが設定されていないこと 監査ログ管理 各種ログの出力設定が有効化されていること データ復旧 Cloud SQL の自動バックアップが有効になっていること ネットワークインフラストラクチャ管理 ファイアウォールルールにて認可外ポートを一般開放していないこと Cloud SQL データベースに、パブリックIP アドレスがないこと Compute Engine インスタンスに脆弱な SSL ポリシーがないこと ※ コントロールは、CIS Controls v8 により分類 全約 60 個 46

47.

GCP におけるクラウドの脆弱性への取り組み カスタムカテゴリの評価 スケジューラ実行される Cloud Functions にて Cloud Asset Inventory のリソース情報を参照してカスタムロジック による評価と SCC へ独自のセキュリティソースの Findings を登録する。 47

48.

GCP におけるクラウドの脆弱性への取り組み 検知結果の可視化 SCC のダッシュボードで選定したカテゴリのみ可視化。組織 /フォルダ/プロジェクトの単位で閲覧可能。 48

49.

GCP におけるクラウドの脆弱性への取り組み ミュートルールの設定 選定したカテゴリ以外をミュートルールに設定することで、 ダッシュボードでは対応すべき脆弱性を直感的に把握することが可能 ● Mute Rules は検出結果やリソースの情報を Query による条件を設定 ※ミュートされた検出結果も「Include muted findings」より閲覧が可能 49

50.

GCP におけるクラウドの脆弱性への取り組み 通知 現状では通知は行っていない。選定したカテゴリだけでも多くの脆弱性が検出されているため、優先度の高 いものを計画的に対応を進めているフェーズ。 既存の脆弱性の対処が進んだ後に、カテゴリに違反したリソースが検出された場合は、担当者へ通知して早 期に対処を行う運用を開始する予定。 通知を行う場合は、以下のアーキテクチャにて Cloud Functions 経由にて Slack 等への通知が可能。 引用:「リアルタイム メールとチャットの通知を有効にする 」 50

51.

AWS におけるワークロードの脆弱性への取り組み × ワークロード レイヤー CWPP (Cloud Workload Protection Platform) 51

52.

AWS におけるワークロードの脆弱性への取り組み AWS のワークロード保護に関わるソリューション AWS では CWPP に相当するサービスは提供されていないが、ワークロード(コンテナイメージ、インスタン ス)の脆弱性をスキャンするサービスを提供。 Amazon Inspector (Classic) Amazon Elastic Container Registry Amazon Inspector (v2) インスタンス脆弱性スキャン コンテナイメージ脆弱性スキャン 脆弱性管理サービス ● EC2 インスタンスの動的スキャン ● Inspector Agent を導入したインスタンス をスキャン可能 ● CVE評価の他にネットワーク到達可能性 評価やホスト評価( CISベンチマーク)も 可能 ● コンテナイメージの静的スキャン ● スキャンの費用は無料 ● 同イメージは 24時間あたり 1回のスキャン が上限 ● AWS re:Invent 2021 にて発表(2021/11) ● EC2 インスタンスとコンテナイメージの脆弱性 スキャンに対応 ● コンテナイメージは、プッシュ時や脆弱性情 報更新時の継続的な自動スキャン ● インスタンスは、 SSM Agent を用いて構成変 更時と脆弱性情報更新時の継続的な自動ス キャン 52

53.

AWS におけるワークロードの脆弱性への取り組み Visional における選定 Inspctor Classic & ECR Scanning Inspector (Classic) ECR Amazon Inspector v2 のリリース前に構築したプラットフォームのため、現在 は Inspector Classic と ECR Scanning の組み合わせで AWS 組織全体のインス タンスとコンテナイメージの脆弱性スキャンを実施。 Inspector v2 への移行を検討したが、コンテナイメージでは以下の制約が あったため移行は先送りとしている。 ● 「30日間プッシュされていないコンテナイメージはスキャンされない」& 「手動スキャンが行えない」 ○ 30日以上更新のないイメージにおいてもプロダクション環境で動 作するものは脆弱性スキャン対象としたいため 53

54.

AWS におけるワークロードの脆弱性への取り組み 可視化 スキャン結果は組織の全アカウント /リー ジョンの結果を Amazon OpenSearch Service へ集約し、OpenSearch Dashboard を利用して、一元的に可視化。 以下のデータを可視化。 ● ● ● ● 深刻度毎の現在の脆弱性件数/推移 アカウント毎の脆弱性の件数/推移 アカウント/リージョン/深刻度毎の割合 最新の脆弱性詳細一覧 54 ‥

55.

AWS におけるワークロードの脆弱性への取り組み 通知 コンテナイメージ インスタンス 現在 AWS 組織全体のワークロードの評価 は週次で行っている。 評価完了後にセキュリティ部門へ通知し、 結果確認の上で一定の深刻度以上の脆 弱性については、担当者へ連絡する形で 運用を行っている。 55

56.

AWS におけるワークロードの脆弱性への取り組み システム構成(インスタンスのスキャン) 初期セットアップ ● 全 AWS アカウントの Inspector サービスの有効 化、評価ターゲットと評価テンプレートの作成 ● 各インスタンスへエージェントの導入 脆弱性情報収集機能(Load Vulnerability Info) ● アドバイザリ(NVD)より脆弱性情報を最新 化(PoC の情報収集) 評価機能(IaaS Execute Assessment) ● 定期実行と手動実行の実行契機 ● セキュリティアカウントより全アカウントへ評価 実行指示 ● 全評価完了後に評価結果の Findings を取得し て独自の深刻度判定結果と付加情報を加えて SecurityHub の Findings を更新(更新後データ は OpenSearch Service へ連携) ● 最後に結果の集計と Slack通知 56

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 通知 ※右側はインスタンスの スキャンと共通 57

58.

AWS におけるワークロードの脆弱性への取り組み 独自の深刻度判定 深刻度(Critical/High/Medium/Low)はマネージドサービスによる結果ではなく独自ロジックにて判定 外部からの攻撃を受ける可能性が高い脆弱性 /環境特性を優先的に対応 脆弱性のリモート攻撃の適否 攻撃コード(PoC)の有無 アタックサーフェイスの適否 脆弱性の CVSS v3 Base Metrics の Attack Vector (AV) が Network か否か 脆弱性の攻撃コード(Proof of Concept code)が公開されているか (インスタンスのみ) Inspector のネットワーク到達可能性 スキャンにて外部から到達が可能な インスタンスか 合致する場合、 CVSS v3 Score に応じて優先対応の深刻度を設定 58

59.

アプリケーションの脆弱性への取り組み × アプリケーション レイヤー SCA (Software Composition Analytics) 59

60.

アプリケーションの脆弱性への取り組み 脆弱性管理クラウド「yamory」 「yamory」は、アプリケーション、ミドルウェア、 OS の 脆弱性対策 と ライセンス違反検知 を行える国産のクラウドサービスです。 1 ソフトウェアの 利用状況を自動把握 2 yamory独自の 脆弱性データベースと照合 3 脆弱性を危険度別に一元管理 60

61.

アプリケーションの脆弱性への取り組み 脆弱性管理クラウド「yamory」 複数のツール・部門で管理していた、様々な階層のオープンソースの脆弱性を 「ワンストップ」で横断的に可視化・一元管理できる環境を実現 セキュリティチーム (開発チームの横断管理が可能) ライブラリ ライブラリ フレームワーク フレームワーク WebAppサーバー WebApp サーバー Jackson, Hibernate など Spring, Struts など Apache Tomcat など 言語実行環境 言語実行環境 Java など OS Linux など OS 全体ダッシュボードで 一元管理! 開発チーム (開発チーム間での情報共有は不可) 61

62.

脆弱性を評価する取り組みの全体像(再掲) レイヤー アプリケーション ワークロード クラウド AWS GCP yamory yamory CaaS(コンテナ) Amazon Elastic Container Registry (Image scanning) - IaaS(インスタンス) Amazon Inspector Classic - AWS Config Security Command Center (Security Health Analytics) 62

63.

取り組みを通して グループ会社におけるクラウド全体の脆弱性を可視化 グループ会社 事業(開発部門) ● 組織全体のクラウドに関わる脆弱性を可視 化して状況を把握 ● クラウド利用者はアジリティを損なうことなく、 脆弱性を検知して素早く対処することが可能 ● グループ会社として脆弱性に対するリスクコ ントロールが可能 ● クラウドのルールへの適合状況により会社 で定めた一定のセキュリティを保証 ● 新規事業の立ち上げのしやすさを獲得 ● 横断的なソリューションの展開により個別事 業の業務を効率化 63

64.

課題や今後の展望 ● 脆弱性への対応促進 ○ AWS のクラウドの改善は一定進んだが、その他は未だ多くの脆弱性が存在 脆弱性の対応を促進するためのソリューションの展開や横断的な対策の実施 ● マルチクラウド /マルチレイヤーの管理効率化 ○ 各クラウド・レイヤー毎に個別のサービスを利用しているが管理が煩雑化 改めてサードパーティのサービス活用も含めて効率的な管理・運用方法を検討 ● 開発組織に最適化したセキュリティの実装 ○ 高いセキュリティを実現するには開発ライフサイクルへのセキュリティの統合が必須 各開発組織へ DevSecOps を浸透を進め、セキュアで迅速な開発・運用を目指す 64

65.

● Visional について ● Visional の CCoE について ● クラウド時代のセキュリティの課題 ● クラウドにおける脆弱性とソリューション ● Visional グループにおける取り組み ● まとめ まとめ 65

66.

まとめ ● クラウド市場は今後も成長、脆弱性や設定ミスによるセキュリティ事故への十分な備えが必要。 ● クラウドの責任範囲を正しく理解し、サービス /ツールを活用して各レイヤーの脆弱性を評価する。 〈/〉 lib ● アプリケーションコード ● ライブラリ/フレームワーク ● コンテナイメージ ● インスタンス ● クラウドの設定 アプリケーション の脆弱性 xAST(Application Security Testing) SCA(Software Composition Analytics) ワークロードの脆弱性 CWPP(Cloud Workload Protection Platform) クラウドの脆弱性 CSPM(Cloud Security Posture Management) ● 変化の速いクラウドは、継続的な評価により脆弱性を早期に検出し対処していくことが重要。 ○ 共通で利用されるクラウドには横断的なソリューションを展開可能。 ○ 各開発組織でも開発ライフサイクルにセキュリティを組み込む。 ● 組織全体で脆弱性に適切に対応し続ける体制を構築し、セキュリティとアジリティを両立する。 66

67.

Thank you. We are hiring. https://www.visional.inc/ja/careers.html Visional Tech Blog https://engineering.visional.inc/blog/ 67

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