Slide 1

Slide 1 text

株式会社 Gunosy Gunosy 技術戦略室 SRE 山口 隆史 2022年11月21日(月) AWS Security Hubの導入から 運用を回すためにやってきたこと

Slide 2

Slide 2 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 2 自己紹介 氏名:山口隆史(やまぐちたかし) 所属:株式会社Gunosy 技術戦略室 SRE 業務:Pure SREとしての活動 略歴:フリーランス、SIer等を渡り歩く→現職(2022/01〜) 自称:プリセールスから運用までこなすフルスタックエンジニア 好きなAWSサービス:AWS WAF、CloudShell、サポート

Slide 3

Slide 3 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 3 株式会社Gunosy ギリシャ語で「知識」を意味する「Gnosis(グノーシス)」+「u(“you”)」 「”Gnosis” for “you”」あなたのための知識  =情報を届けるサービスを提供し続ける、という意味 ■ 2012年11月創業 ■ 2015年4月東証マザーズ上場 ■ 2017年12月東証第一部に市場変更 ■ 従業員数 258名 (2022年5月末現在 連結ベース) ■ 事業内容 – 情報キュレーションサービスその他メディアの開発及び 運営 ■ 提供サービス  グノシー、ニュースパス、 auサービスToday 企業理念「情報を世界中の人に最適に届ける」

Slide 4

Slide 4 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 4 アジェンダ 話すこと - AWS Security Hubとの付き合い方 - 実環境でミスコンフィグを潰す運用の構築 話すさないこと - 情報セキュリティについての詳細 - セキュアな設計に関すること - セキュリティリスクの評価 - AWS Security Hub、AWS Control Towerの詳細 - Shift-left

Slide 5

Slide 5 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 5 目次 1. Security Hub導入の背景 2. GunosyのAWS環境の全体像 3. 開発組織体制と担当 4. Security Hub導入の流れ 5. 本番展開後に発生した問題 6. まとめ

Slide 6

Slide 6 text

(C) Gunosy Inc. All Rights Reserved. 1. Security Hub導入の背景

Slide 7

Slide 7 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 7 Security Hub導入の背景(1/2) セキュリティ対策に対する優先度が上がった キッカケはLog4j問題での対応 - ヤバめの脆弱性情報は個人が Twitter等で拾ってくる体制だった - Log4jはこれで拾えたが取りこぼしがあると致命的 - 調査が人力総力戦だったので、もうやりたくない 定期的・自動的にスキャンして継続的に潰していくサイクルにしたい - セキュリティの設計への組み込みはベストプラクティスに従って対応していたが、レビュワー、実 装者の個人のスキル任せになっていた

Slide 8

Slide 8 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 8 Security Hub導入の背景(2/2) 定期的・自動的にスキャンして継続的に潰していくサイクルにしたい [定期・自動] スキャン DBとの照合 トリアージ 対応 なんかやばいぞってな る 急いで調査 対応 As-Is To-Be

Slide 9

Slide 9 text

(C) Gunosy Inc. All Rights Reserved. 2. GunosyのAWS環境の全体像

Slide 10

Slide 10 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 10 GunosyのAWS環境の全体像(1/2) OrganizationのOU構成 Root - プロダクションOU - プロダクション1本番 - プロダクション1非本番 - ・・・ - SandboxOU - Sandboxアカウント - SecurityOU - Log用アカウント - SecurityGuardRail用アカウント (委任アカウント) OU構成は複雑性を排除した構成 - OUは1階層でネストはしない - プロダクトション用のアカウントは本番・非本番 も同じプロダクション OUに配置 - SandboxOUにはSandboxアカウントのみ配置 - SecurityOUで、Log用アカウントと SecurityGuardRail用アカウント(委任アカウン ト)を切り出した - AWS Control Towerの標準構成

Slide 11

Slide 11 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 11 GunosyのAWS環境の全体像(2/2) AWS環境のイメージ

Slide 12

Slide 12 text

(C) Gunosy Inc. All Rights Reserved. 3. 開発組織体制と担当

Slide 13

Slide 13 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 13 開発組織体制と担当 Gunosyの開発チームとSREとの関係とインフラ周り 開発チーム - 開発チームがインフラの構築・運用・オンコー ル対応を含めて自律的に担当している - インフラ周りも含めて自走できている状態 SRE - 「開発チームが 新たなプロダクト価値の創造 に集中できる状態を作る」が Mission - 定例のSLOふりかえりの実施や、セキュリ ティ対策の旗振り役 インフラ周り - 自動化大好き - IaC、CI/CD導入済み - IaCはTerraform

Slide 14

Slide 14 text

(C) Gunosy Inc. All Rights Reserved. 4. Security Hub導入の流れ

Slide 15

Slide 15 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 15 Security Hub導入の流れ(1/2) 既存アカウントへの導入なので手順を踏んで導入する ■ 制約・制限、導入 事例の机上調査 – 既存への影響 確認 – コントロール・ 事例の確認 ■ Sandboxアカウン トに導入してPoC – 検証 – 課題の確認 ■ PoC結果から運用 方法の検討 – 指摘の対応をど う運用するか ■ 本番アカウントに 順次導入 導入・運用 1ヶ月 運用検討 1週間 PoC 1ヶ月 事前調査 1週間 参考URL:https://dev.classmethod.jp/articles/aws-security-hub-key-consideration/

Slide 16

Slide 16 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 16 Security Hub導入の流れ(2/2) 事前調査する前に立てた導入方針 導入方針 - 既存アカウントはAWS Configを有効にしていなかったので、 Control Towerを導入してAWS Configも自動で有効にさせる - AWS Configを有効にしたいだけなんだけど Control Towerを導入した方が複数アカウン トへの設定が楽だしセキュリティも強化されるので一石二鳥 - Security Hubは委任して、複数アカウントへの導入を楽にする

Slide 17

Slide 17 text

(C) Gunosy Inc. All Rights Reserved. 1. 制約・制限、導入事例の机上調査

Slide 18

Slide 18 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 18 制約・制限、導入事例の机上調査(1/2) 既存アカウントに導入した際の影響確認 Control Towerの外せないSCPの確認 - Control Tower配下のOUにアカウントを参加させない限りは問題無さそう - CloudTrail, AWS Configの制約が強いが大きな影響は無さそう CloudTrail周りの確認 - Control Tower導入時に専用のLogアカウントへ集約される - 元々の集約していたので、検索用 Athena周りで変更が必要

Slide 19

Slide 19 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 19 制約・制限、導入事例の机上調査(2/2) Security Hubのコントロール、事例の調査 AWSの公式ドキュメントを調査 - 基準毎のコントロールの内容を一覧でざっと確認して、有効にする基準を決定した - AWS 基礎セキュリティのベストプラクティス - CIS AWS Foundations Benchmark トラブル事例や導入事例を調査 - 有効にしたほうが良いコントロール、無効にして良いコントロール等々の情報 - クラメソブログ、NRIブログ等で参考情報を発見 - 運用の知見 - 調査してみたが自社に適用できそうな事例はなかった - トラブル事例 - 料金高騰事例を発見

Slide 20

Slide 20 text

(C) Gunosy Inc. All Rights Reserved. 2. Sandboxアカウントに導入してPoC

Slide 21

Slide 21 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 21 Sandboxアカウントに導入してPoC(1/2) PoCで実施したこと 導入 - Control Towerを有効化 - Security Hubを有効化(委任) - AWS 基礎セキュリティのベストプラクティス - CIS AWS Foundations Benchmark 検証 - 指摘事項の調査 - 自社での使用方法ではどんな指摘が上がってくるのか - 指摘の対応や抑制してみて、 Security Hubの変化を確認 - 自動修復の挙動の調査 - 委任アカウントからの見え方、メンバーアカウントからの見え方

Slide 22

Slide 22 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 22 Sandboxアカウントに導入してPoC(2/2) PoCでわかった課題 1. 点数があてにならない 2. 無駄な指摘、解決不能な指摘がある 3. 基準・コントロールの有効化・無効化がメンバーアカウントへ伝搬しない 4. リソース単位で抑制してもメンバーアカウントへ伝搬しない 5. 自動で修復できるところは修復したいが悩ましい

Slide 23

Slide 23 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 23 PoCでわかった課題(1/9) 1. 点数があてにならない どういうことか - 失敗したコントロール数で按分した点数なので、 CRITICAL、HIGH、MEDIUM、LOW全て同じ 重さで評価した点数になる - CRITICAL、HIGHが0件でも赤点になる - なので、点数がリスク評価を表さない どう解決したか - 点数を気にしない - リスクの低減を目的とする 心の声 - 単純な点数はいらない - リスク評価して欲しい

Slide 24

Slide 24 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 24 PoCでわかった課題(2/9) 2. 無駄な指摘、解決不能な指摘がある(1/4) どういうことか - (自社では)セキュリティ上問題ない無駄な指摘が多い - セキュリティ上問題があるが(自社では)解決できないことを指摘される - AWSのサービス利用時に自動的に作成されるリソースが指摘される - 対応するとすごい料金がかかることを指摘される 例 - [IAM.6] (HIGH)ルートユーザーに対してハードウェア MFA を有効にする必要があります - 対応するとrootでログインするためにだけに出社する羽目になる - アップデートでMFAを複数設定できるようになったので幾分緩和されている - [S3.9] (MEDIUM)S3 バケットサーバーアクセスログ記録を有効にする必要があります - アクセスが多いバケットに設定したら料金爆発する - アクセス経路のどこかでログを収集していれば追跡は可能

Slide 25

Slide 25 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 25 PoCでわかった課題(3/9) 2. 無駄な指摘、解決不能な指摘がある(2/4) どう解決したか - スプシにまとめて、有効化・無効化を検討して設定に反映 - クラスメソッドメンバーズ限定の Classmethod Cloud Guidebookには推奨対応の記載がある ようなので、メンバーの方は活用しましょう - https://dev.classmethod.jp/articles/securityhub-repair-procedure-ec2-21/ 心の声 - この辺は公開されているガイドラインや推奨事項がないので自社のセキュリティポリシー(なけ れば作る!)に合わせて設定していくしかないです - SAさんに相談してもセキュリティポリシーに合わせてくださいレベルの回答しか返ってき ません - セキュリティ周り、AWS周りの深い知識が必要

Slide 26

Slide 26 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 26 PoCでわかった課題(4/9) 2. 無駄な指摘、解決不能な指摘がある(3/4) 指摘された場合の対応方法や指 摘の内容をまとめておく

Slide 27

Slide 27 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 27 PoCでわかった課題(5/9) 2. 無駄な指摘、解決不能な指摘がある(4/4) 無効化する場合は無効化の理由 を残しておく

Slide 28

Slide 28 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 28 PoCでわかった課題(6/9) 3. 基準・コントロールの有効化・無効化がメンバーアカウントへ伝搬しない( 1/2) どういうことか - 委任アカウントでコントロールを無効化しても、メンバーアカウント側は有効のままになっている - Security Hubが情報を集約するダッシュボード機能でしかない どう解決したか - aws_samplesにあったソリューションを導入して委任アカウント →メンバーアカウント間で同期 設定した - https://github.com/aws-samples/aws-security-hub-cross-account-controls-disabler 心の声 - AWSサポートに聞いてもセキュリティスペシャリスト SAに聞いても有効なソリューションが出て こなかったので、標準機能で対応して欲しい

Slide 29

Slide 29 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 29 PoCでわかった課題(7/9) 3. 基準・コントロールを有効化・無効化がメンバーアカウントへ伝搬しない( 2/2) このソリューションは横田さんにお願いしてクラメソブログ に記事化していただきました。(感謝)

Slide 30

Slide 30 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 30 PoCでわかった課題(8/9) 4. リソース単位で抑制してもメンバーアカウントへ伝搬しない どういうことか - 委任アカウント側のSecurity Hubでリソースを抑止(SUPPRESSED)してもメンバーアカウント へ伝搬しないので、次の Security Hubのチェックで再度指摘が上がってくる - 委任アカウントに集約されたダッシュボードでリソースの操作をしても無意味だった どう解決したか - リソース単位での抑止( SUPPRESSED)はメンバーアカウント側で操作する 心の声 - 開発チームに委任アカウントへのアクセスを許可する必要が無くなった良い副作用もあった

Slide 31

Slide 31 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 31 PoCでわかった課題(9/9) 5. 自動で修復できるところは修復したいが悩ましい どういうことか - IaCで管理していないリソース - デフォルトSGが存在するとか、AWS側で自動で作られるリソースが指摘されるので自動 修復したいが、修復タイミングが選べないので何かあった時に気づきにくい - IaCで管理しているリソース - IaCをデプロイすると元に戻ってしまう どう解決したか - 自動修復設定を入れずに IaCで管理、IaCで修正する方向で運用 心の声 - デフォルトで作成されるリソースや設定は、 Security Hubで指摘がされてないセキュアな状態に してほしい

Slide 32

Slide 32 text

(C) Gunosy Inc. All Rights Reserved. 3. PoC結果から運用方法の検討

Slide 33

Slide 33 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 33 (再掲)開発組織体制と担当 Gunosyの開発チームとSREとの関係とインフラ周り 開発チーム - 開発チームがインフラの構築・運用・オンコー ル対応を含めて自律的に担当している - インフラ周りも含めて自走できている状態 SRE - 「開発チームが 新たなプロダクト価値の創造 に集中できる状態を作る」が Mission - 定例のSLOふりかえりの実施や、セキュリ ティ対策の旗振り役 インフラ周り - 自動化大好き - IaC、CI/CD導入済み - IaCはTerraform

Slide 34

Slide 34 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 34 PoC結果から運用方法の検討(1/5) 指摘の対応をどう運用するか(1/2) 決めなければいけないこと - どのSeverityまで対応するか - CRITICAL、HIGH、MEDIUM、LOW - 誰が対応するか - 開発チーム or SRE - 抑制(SUPPRESSED)にする基準をどうするか - なんでもかんでも抑制にするとセキュリティが保てない - 対応のステータスの追跡をどうやるか - 新しい指摘はどうやって確認するか - 通知運用 - 量が多いと誰も見なくなってしまう - 定期確認運用

Slide 35

Slide 35 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 35 PoC結果から運用方法の検討(2/5) 指摘の対応をどう運用するか(2/2) 評価軸 - 開発チームにあまり負担をかけたくない - 通知だけしてあとは自分達でなんとかしてね、は避けたい - (量が多すぎて)これ全部やる必要あるんですか!?という拒絶反応は避けたい - 今のSREの体制で運用が回るか - SREも通常業務があるので負担が増えすぎると回らなくなる - セキュリティは担保したい - セキュリティリスクは可能な限り早く低減したい - セキュリティ指摘にも濃淡があるので、リスクが高いものから対応してきたい - 対応状況を追跡して、タスクが放置される状態を避けたい

Slide 36

Slide 36 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 36 PoC結果から運用方法の検討(3/5) 決定した運用方針(1/2) どのSeverityまで対応するか - CRITICAL、HIGHを対応 - MEDIUM以下は放置 - 設計でセキュリティが確保できていれば 即座に問題になる指摘ではないと判断 誰が対応するか - CRITICALはSREが最速で対応 - HIGHは開発チームがスプリントに積んで対応 - SREが指摘事項をトリアージ、対応方法をサジェストすることで負担感を軽減

Slide 37

Slide 37 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 37 PoC結果から運用方法の検討(4/5) 決定した運用方針(2/2) 抑制(SUPPRESSED)にする基準はどうするか - リスクが許容できることが大前提 - 設計、システム構成、運用上回避できない場合 - 対応する際にリソースの再作成が必要な場合 - 対応すると別の問題が発生する場合 対応のステータスの追跡をどうするか - 対応する場合はJIRAチケットを起票 - 開発チームに依頼する対応内容はスプシにまとめる - JIRAチケットのステータスをスプシで追跡 新しい指摘はどうやって確認するか - SREが定期的にSecurity Hubの指摘を確認

Slide 38

Slide 38 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 38 PoC結果から運用方法の検討(5/5) 運用フロー 定例のふりかえりの準備 - SREがSecurity Hubの指摘を確認 - 指摘事項をトリアージ、対応 事項をサジェストしてスプシにまとめる - CRITICAL指摘があればSREがJIRAチケットを起票して対応 定例のふりかえり - SREが開発チームへ対応を依頼 - 開発チームとSREが協議して対応有無を決定し、その場で JIRAチケットを起票 - すでに起票されている JIRAチケットのステータスを確認 - スプシでJIRAチケットのステータスを取れるようにしている

Slide 39

Slide 39 text

(C) Gunosy Inc. All Rights Reserved. 4. 本番アカウントに順次導入

Slide 40

Slide 40 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 40 本番アカウントに順次導入(1/3) 前提条件の整理 前提 - Control Towerは導入済み - PoCの段階でControl Towerは有効化済みだが既存アカウントへの展開はしていない状 態 - Organizationsは導入済み Security Hubの導入に必要な条件 - メンバーアカウントで Configを有効化 - メンバーアカウントで Security Hub同期用IAM Roleを作成 - 委任アカウントでメンバーアカウントの Security Hubを有効化 - Organizations環境で委任しているので、招待して受託するフローが不要

Slide 41

Slide 41 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 41 本番アカウントに順次導入(2/3) お膳立てしておくと導入は簡単 お膳立て 1. Organizationsの親アカウントでStackSetを作成 - 作成するリソース:委任アカウントからStackSetを打ち込むためのIAM Role - 設定:サービスマネージド(現 OU指定)、RETAIN 2. 委任アカウントでStackSetを作成 - 作成するリソース:AWSControlTowerExecution Role - 設定:サービスマネージド(現 OU指定)、RETAIN 3. 委任アカウントでStackSetを作成 - 作成するリソース:Security Hubの同期に必要なIAM Role - 設定:サービスマネージド(新 OU指定)

Slide 42

Slide 42 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 42 本番アカウントに順次導入(3/3) お膳立てをしているので実際の導入はこれだけ 導入 1. メンバーアカウントを Control Tower配下に追加(新OUに移動) - Control TowerがConfigを自動で有効にしてくれる - というか無効にしておかないとエラーになる - StackSetがサービスマネージドなので、アカウントが新 OUに移動すると必要な Roleが自 動で作成される 2. 委任アカウントのマネコンからメンバーアカウントの Securrity Hubを有効化 - Terraformで管理すると差分が毎回発生するのでここは手動で対応

Slide 43

Slide 43 text

(C) Gunosy Inc. All Rights Reserved. 5. 本番展開後に発生した問題

Slide 44

Slide 44 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 44 本番展開後に発生した問題(1/5) 1. Security Hubのダッシュボードが使いにくい 発生した問題 - 委任アカウントのSecurity Hubの画面だと絞り込みが使いにくくて、トリアージに時間がかかり すぎる - コントロール✖リソース単位で一覧表示されるので、スプシにまとめるのが大変 - 検索条件が保存できない どう対応したか - メンバーアカウントの Security Hub画面を使用してトリアージ - リソース単位の抑止もメンバーアカウント側で実行する必要があるので、トリアージと同時に実 施 心の声 - Secuity Hubに集約すると使いにくくなるのは矛盾を感じる

Slide 45

Slide 45 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 45 本番展開後に発生した問題(2/5) 2. 油断していたら料金爆発してました(1/3) 発生した事象 - Configの料金が爆発 - immutableにリソースを使い捨てしていたアカウントで発生 - CI/CD、バッチ回すたびにチャリンチャリン状態 - その時の対象はこれ - ECS TaskDefinition - EC2 NetworkInterface

Slide 46

Slide 46 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 46 (再掲)制約・制限、導入事例の机上調査(2/2) Security Hubのコントロール、事例の調査 AWSの公式ドキュメントを調査 - 基準毎のコントロールの内容を一覧でざっと確認して、有効にする基準を決定した - AWS 基礎セキュリティのベストプラクティス - CIS AWS Foundations Benchmark トラブル事例や導入事例を調査 - 有効にしたほうが良いコントロール、無効にして良いコントロール等々の情報 - クラメソブログ、NRIブログ等で参考情報を発見 - 運用の知見 - 調査してみたが自社に適用できそうな事例はなかった - トラブル事例 - 料金高騰事例を発見

Slide 47

Slide 47 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 47 本番展開後に発生した問題(3/5) 2. 油断していたら料金爆発してました(2/3) どう対応したか - Control TowerのSCPで制限されていてAWS Configの設定が直接変更できないので、 Control TowerのStackSetのパラメーターを変更して対応 - LandingZoneをVersionUPすると元に戻るので再度同じ対応が必要 対応の詳細 - 親アカウントのStackSetにAWSControlTowerBP-BASELINE-CONFIGが存在しているので パラメーターを変更して更新 - AllSupported: false - IncludeGlobalResourceTypes: false - ResourceTypes: (記録対象リソースを CSV形式で指定) - リソース指定はホワイトリスト方式

Slide 48

Slide 48 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 48 本番展開後に発生した問題(4/5) 2. 油断していたら料金爆発してました(3/3) CSV形式リソース一覧生成方法 - CloudShellで生成 - grep -v -E で除外するリソースを指定 参考URL - https://qiita.com/leonis_sk/items/45949b268dfa43fac5f6 $ aws configservice list-discovered-resources help \ | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})*)?m//g" \ | grep "o AWS::" | sed -e "s/ *+\x08o //g" \ | grep -v -E "ECS::TaskDefinition|EC2::NetworkInterface" \ | sort | tr '\n' ',' | sed -e 's/,$//'

Slide 49

Slide 49 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 49 本番展開後に発生した問題(5/5) 3. 指摘通りに対応したら障害発生 発生した事象 - [EC2.22] (MEDIUM)未使用の EC2 セキュリティグループを削除する必要があります で指摘さ れたSGを削除したらEKSクラスターのVerupができなくなった - EKSのクラスターセキュリティグループが指摘される - [EC2.18](HIGH)セキュリティグループは、許可されたポートに対してのみ無制限の 受信トラフィックを許可する必要があります でも指摘されていた どう対応したか - EKSクラスターの再作成するしかなかった - クラスターセキュリティグループを設定するコマンド、 I/Fがない 心の声 - AWS内部サービスで自動的に作成されるリソースへの指摘はどうにかして欲しい

Slide 50

Slide 50 text

(C) Gunosy Inc. All Rights Reserved. 6. まとめ

Slide 51

Slide 51 text

(C) Gunosy Inc. All Rights Reserved. PAGE | 51 まとめ AWS Security Hubとうまく付き合いましょう ■ 導入よりもその後の運用が大事です – 検知だけして満足しない、修復するまでが運用です ■ 実環境でミスコンフィグを潰せたら、新たなミスコンフィグを持ち込ませない ようにしましょう – Shift-left大事 ■ Security Hubを使うとAWSセキュリティを効率よく監査できます – 指摘が細かすぎるところはうまくトリアージしましょう ■ アクセス権限、不正アクセスはSecurity Hub単体ではチェックできないの で、他のサービスと組み合わせましょう – IAM Access Analyzer – GuardDuty – 等々

Slide 52

Slide 52 text

情報を世界中の人に最適に届ける