Security-JAWS #27 AWS Security Hubの導入から運用を回すためにやってきたこと

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

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

（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 企業理念「情報を世界中の人に最適に届ける」

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

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

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

Hub導入の背景（2/2）定期的・自動的にスキャンして継続的に潰していくサイクルにしたい [定期･自動] スキャン DBとの照合トリアージ対応なんかやばいぞってなる急いで調査対応 As-Is To-Be

（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の標準構成

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

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

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

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

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

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

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

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

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

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

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

2. 無駄な指摘、解決不能な指摘がある（3/4）指摘された場合の対応方法や指摘の内容をまとめておく

2. 無駄な指摘、解決不能な指摘がある（4/4）無効化する場合は無効化の理由を残しておく

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

3. 基準・コントロールを有効化・無効化がメンバーアカウントへ伝搬しない（ 2/2）このソリューションは横田さんにお願いしてクラメソブログに記事化していただきました。（感謝）

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

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

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

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

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

決定した運用方針（1/2）どのSeverityまで対応するか - CRITICAL、HIGHを対応 - MEDIUM以下は放置 - 設計でセキュリティが確保できていれば即座に問題になる指摘ではないと判断誰が対応するか - CRITICALはSREが最速で対応 - HIGHは開発チームがスプリントに積んで対応 - SREが指摘事項をトリアージ、対応方法をサジェストすることで負担感を軽減

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

運用フロー定例のふりかえりの準備 - SREがSecurity Hubの指摘を確認 - 指摘事項をトリアージ、対応事項をサジェストしてスプシにまとめる - CRITICAL指摘があればSREがJIRAチケットを起票して対応定例のふりかえり - SREが開発チームへ対応を依頼 - 開発チームとSREが協議して対応有無を決定し、その場で JIRAチケットを起票 - すでに起票されている JIRAチケットのステータスを確認 - スプシでJIRAチケットのステータスを取れるようにしている

（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環境で委任しているので、招待して受託するフローが不要

お膳立てしておくと導入は簡単お膳立て 1. Organizationsの親アカウントでStackSetを作成 - 作成するリソース：委任アカウントからStackSetを打ち込むためのIAM Role - 設定：サービスマネージド（現 OU指定）、RETAIN 2. 委任アカウントでStackSetを作成 - 作成するリソース：AWSControlTowerExecution Role - 設定：サービスマネージド（現 OU指定）、RETAIN 3. 委任アカウントでStackSetを作成 - 作成するリソース：Security Hubの同期に必要なIAM Role - 設定：サービスマネージド（新 OU指定）

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

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

2. 油断していたら料金爆発してました（1/3）発生した事象 - Configの料金が爆発 - immutableにリソースを使い捨てしていたアカウントで発生 - CI/CD、バッチ回すたびにチャリンチャリン状態 - その時の対象はこれ - ECS TaskDefinition - EC2 NetworkInterface

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

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

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/,$//'

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

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

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

Security-JAWS #27 AWS Security Hubの導入から 運用を回すため...

Security-JAWS #27 AWS Security Hubの導入から 運用を回すためにやってきたこと

More Decks by Takashi Yamaguchi

Other Decks in Technology

Featured

Transcript

Security-JAWS #27 AWS Security Hubの導入から運用を回すため...

Security-JAWS #27 AWS Security Hubの導入から運用を回すためにやってきたこと