Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Security-JAWS #27 AWS Security Hubの導入から 運用を回すため...
Search
Takashi Yamaguchi
November 21, 2022
Technology
1
4.2k
Security-JAWS #27 AWS Security Hubの導入から 運用を回すためにやってきたこと
Security-JAWS#27
AWS Security Hubの導入から 運用を回すためにやってきたこと
Takashi Yamaguchi
November 21, 2022
Tweet
Share
More Decks by Takashi Yamaguchi
See All by Takashi Yamaguchi
CodeCatalyst in Action: Automating PR Creation for Route 53 and IAM Identity Center Management
yamaguchitk333
0
16
DevSecOpsの内回りと外回りで考える持続可能なセキュリティ対策 / Considering Sustainable Security Measures in DevSecOps: Left Loop and Right Loop Perspectives
yamaguchitk333
1
1.3k
DevSecOpsの内回りと外回りで考える持続可能なセキュリティ対策 | Sustainable security measures for DevSecOps inside and outside the DevSecOps system.
yamaguchitk333
4
2.2k
コスト削減のハードスキルとソフトスキル / Hard and Soft skills for cost reduction
yamaguchitk333
0
73
クラウドセキュリティの技術選択と、セキュリティ対応していく中で出て来た課題
yamaguchitk333
0
130
コンテナセキュリティの概要と デプロイフローに組み込んだ後の課題
yamaguchitk333
1
1k
クラウドセキュリティの技術選択と、セキュリティ対応していく中で出て来た課題
yamaguchitk333
0
5.3k
JAWS-UG SRE支部 #7 Security Hubは俺の姑
yamaguchitk333
0
580
JAWS-UG コンテナ支部 × JAWS-UG 千葉支部 #1 コンテナセキュリティ対応でSnykを導入中に 発生した・発生中のいろんなこと
yamaguchitk333
0
1.1k
Other Decks in Technology
See All in Technology
Envoy External AuthZとgRPC Extensionを利用した「頑張らない」Microservices認証認可基盤
andoshin11
0
140
New Relicで実践する外形監視
aeonpeople
1
120
手軽に始める? おうちサーバーのすゝめ
nyagasan
0
180
20分で分かるIAM全機能 (拡大版) / 20240903-jawsug-yokohama-iam
opelab
3
120
リクルート新人研修2024 テキスト生成AI活用
recruitengineers
PRO
10
420
Datadog を使ったプロダクトとクラウドの セキュリティモニタリング
mrtc0
0
450
Evolving DevOps Teams and Flexible Organizational Culture
kakehashi
1
130
エンジニア向け会社紹介資料
caddi_eng
15
250k
目標設定と習慣化で今よりも一歩生産性を上げる
sansantech
PRO
7
2.3k
EitherT_with_Future
aoiroaoino
0
380
FastConnect の冗長性
ocise
0
7.1k
Hyperledger Fabricの成長、成熟を振り返る / Looking back history of Hyperledger Fabric
gakumura
0
180
Featured
See All Featured
What's new in Ruby 2.0
geeforr
340
31k
Code Review Best Practice
trishagee
62
16k
A better future with KSS
kneath
235
17k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
190
16k
In The Pink: A Labor of Love
frogandcode
139
22k
Building Adaptive Systems
keathley
36
2.1k
Designing Experiences People Love
moore
138
23k
Done Done
chrislema
180
16k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
38
9.1k
Art, The Web, and Tiny UX
lynnandtonic
294
20k
Optimising Largest Contentful Paint
csswizardry
28
2.7k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
278
13k
Transcript
株式会社 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. 1. Security Hub導入の背景
(C) Gunosy Inc. All Rights Reserved. PAGE | 7 Security
Hub導入の背景(1/2) セキュリティ対策に対する優先度が上がった キッカケはLog4j問題での対応 - ヤバめの脆弱性情報は個人が Twitter等で拾ってくる体制だった - Log4jはこれで拾えたが取りこぼしがあると致命的 - 調査が人力総力戦だったので、もうやりたくない 定期的・自動的にスキャンして継続的に潰していくサイクルにしたい - セキュリティの設計への組み込みはベストプラクティスに従って対応していたが、レビュワー、実 装者の個人のスキル任せになっていた
(C) Gunosy Inc. All Rights Reserved. PAGE | 8 Security
Hub導入の背景(2/2) 定期的・自動的にスキャンして継続的に潰していくサイクルにしたい [定期・自動] スキャン DBとの照合 トリアージ 対応 なんかやばいぞってな る 急いで調査 対応 As-Is To-Be
(C) Gunosy Inc. All Rights Reserved. 2. GunosyのAWS環境の全体像
(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. 3. 開発組織体制と担当
(C) Gunosy Inc. All Rights Reserved. PAGE | 13 開発組織体制と担当
Gunosyの開発チームとSREとの関係とインフラ周り 開発チーム - 開発チームがインフラの構築・運用・オンコー ル対応を含めて自律的に担当している - インフラ周りも含めて自走できている状態 SRE - 「開発チームが 新たなプロダクト価値の創造 に集中できる状態を作る」が Mission - 定例のSLOふりかえりの実施や、セキュリ ティ対策の旗振り役 インフラ周り - 自動化大好き - IaC、CI/CD導入済み - IaCはTerraform
(C) Gunosy Inc. All Rights Reserved. 4. Security Hub導入の流れ
(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/
(C) Gunosy Inc. All Rights Reserved. PAGE | 16 Security
Hub導入の流れ(2/2) 事前調査する前に立てた導入方針 導入方針 - 既存アカウントはAWS Configを有効にしていなかったので、 Control Towerを導入してAWS Configも自動で有効にさせる - AWS Configを有効にしたいだけなんだけど Control Towerを導入した方が複数アカウン トへの設定が楽だしセキュリティも強化されるので一石二鳥 - Security Hubは委任して、複数アカウントへの導入を楽にする
(C) Gunosy Inc. All Rights Reserved. 1. 制約・制限、導入事例の机上調査
(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. 2. Sandboxアカウントに導入してPoC
(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件でも赤点になる - なので、点数がリスク評価を表さない どう解決したか - 点数を気にしない - リスクの低減を目的とする 心の声 - 単純な点数はいらない - リスク評価して欲しい
(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 バケットサーバーアクセスログ記録を有効にする必要があります - アクセスが多いバケットに設定したら料金爆発する - アクセス経路のどこかでログを収集していれば追跡は可能
(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周りの深い知識が必要
(C) Gunosy Inc. All Rights Reserved. PAGE | 26 PoCでわかった課題(4/9)
2. 無駄な指摘、解決不能な指摘がある(3/4) 指摘された場合の対応方法や指 摘の内容をまとめておく
(C) Gunosy Inc. All Rights Reserved. PAGE | 27 PoCでわかった課題(5/9)
2. 無駄な指摘、解決不能な指摘がある(4/4) 無効化する場合は無効化の理由 を残しておく
(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に聞いても有効なソリューションが出て こなかったので、標準機能で対応して欲しい
(C) Gunosy Inc. All Rights Reserved. PAGE | 29 PoCでわかった課題(7/9)
3. 基準・コントロールを有効化・無効化がメンバーアカウントへ伝搬しない( 2/2) このソリューションは横田さんにお願いしてクラメソブログ に記事化していただきました。(感謝)
(C) Gunosy Inc. All Rights Reserved. PAGE | 30 PoCでわかった課題(8/9)
4. リソース単位で抑制してもメンバーアカウントへ伝搬しない どういうことか - 委任アカウント側のSecurity Hubでリソースを抑止(SUPPRESSED)してもメンバーアカウント へ伝搬しないので、次の Security Hubのチェックで再度指摘が上がってくる - 委任アカウントに集約されたダッシュボードでリソースの操作をしても無意味だった どう解決したか - リソース単位での抑止( SUPPRESSED)はメンバーアカウント側で操作する 心の声 - 開発チームに委任アカウントへのアクセスを許可する必要が無くなった良い副作用もあった
(C) Gunosy Inc. All Rights Reserved. PAGE | 31 PoCでわかった課題(9/9)
5. 自動で修復できるところは修復したいが悩ましい どういうことか - IaCで管理していないリソース - デフォルトSGが存在するとか、AWS側で自動で作られるリソースが指摘されるので自動 修復したいが、修復タイミングが選べないので何かあった時に気づきにくい - IaCで管理しているリソース - IaCをデプロイすると元に戻ってしまう どう解決したか - 自動修復設定を入れずに IaCで管理、IaCで修正する方向で運用 心の声 - デフォルトで作成されるリソースや設定は、 Security Hubで指摘がされてないセキュアな状態に してほしい
(C) Gunosy Inc. All Rights Reserved. 3. PoC結果から運用方法の検討
(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)にする基準をどうするか - なんでもかんでも抑制にするとセキュリティが保てない - 対応のステータスの追跡をどうやるか - 新しい指摘はどうやって確認するか - 通知運用 - 量が多いと誰も見なくなってしまう - 定期確認運用
(C) Gunosy Inc. All Rights Reserved. PAGE | 35 PoC結果から運用方法の検討(2/5)
指摘の対応をどう運用するか(2/2) 評価軸 - 開発チームにあまり負担をかけたくない - 通知だけしてあとは自分達でなんとかしてね、は避けたい - (量が多すぎて)これ全部やる必要あるんですか!?という拒絶反応は避けたい - 今のSREの体制で運用が回るか - SREも通常業務があるので負担が増えすぎると回らなくなる - セキュリティは担保したい - セキュリティリスクは可能な限り早く低減したい - セキュリティ指摘にも濃淡があるので、リスクが高いものから対応してきたい - 対応状況を追跡して、タスクが放置される状態を避けたい
(C) Gunosy Inc. All Rights Reserved. PAGE | 36 PoC結果から運用方法の検討(3/5)
決定した運用方針(1/2) どのSeverityまで対応するか - CRITICAL、HIGHを対応 - MEDIUM以下は放置 - 設計でセキュリティが確保できていれば 即座に問題になる指摘ではないと判断 誰が対応するか - CRITICALはSREが最速で対応 - HIGHは開発チームがスプリントに積んで対応 - SREが指摘事項をトリアージ、対応方法をサジェストすることで負担感を軽減
(C) Gunosy Inc. All Rights Reserved. PAGE | 37 PoC結果から運用方法の検討(4/5)
決定した運用方針(2/2) 抑制(SUPPRESSED)にする基準はどうするか - リスクが許容できることが大前提 - 設計、システム構成、運用上回避できない場合 - 対応する際にリソースの再作成が必要な場合 - 対応すると別の問題が発生する場合 対応のステータスの追跡をどうするか - 対応する場合はJIRAチケットを起票 - 開発チームに依頼する対応内容はスプシにまとめる - JIRAチケットのステータスをスプシで追跡 新しい指摘はどうやって確認するか - SREが定期的にSecurity Hubの指摘を確認
(C) Gunosy Inc. All Rights Reserved. PAGE | 38 PoC結果から運用方法の検討(5/5)
運用フロー 定例のふりかえりの準備 - SREがSecurity Hubの指摘を確認 - 指摘事項をトリアージ、対応 事項をサジェストしてスプシにまとめる - CRITICAL指摘があればSREがJIRAチケットを起票して対応 定例のふりかえり - SREが開発チームへ対応を依頼 - 開発チームとSREが協議して対応有無を決定し、その場で JIRAチケットを起票 - すでに起票されている JIRAチケットのステータスを確認 - スプシでJIRAチケットのステータスを取れるようにしている
(C) Gunosy Inc. All Rights Reserved. 4. 本番アカウントに順次導入
(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環境で委任しているので、招待して受託するフローが不要
(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指定)
(C) Gunosy Inc. All Rights Reserved. PAGE | 42 本番アカウントに順次導入(3/3)
お膳立てをしているので実際の導入はこれだけ 導入 1. メンバーアカウントを Control Tower配下に追加(新OUに移動) - Control TowerがConfigを自動で有効にしてくれる - というか無効にしておかないとエラーになる - StackSetがサービスマネージドなので、アカウントが新 OUに移動すると必要な Roleが自 動で作成される 2. 委任アカウントのマネコンからメンバーアカウントの Securrity Hubを有効化 - Terraformで管理すると差分が毎回発生するのでここは手動で対応
(C) Gunosy Inc. All Rights Reserved. 5. 本番展開後に発生した問題
(C) Gunosy Inc. All Rights Reserved. PAGE | 44 本番展開後に発生した問題(1/5)
1. Security Hubのダッシュボードが使いにくい 発生した問題 - 委任アカウントのSecurity Hubの画面だと絞り込みが使いにくくて、トリアージに時間がかかり すぎる - コントロール✖リソース単位で一覧表示されるので、スプシにまとめるのが大変 - 検索条件が保存できない どう対応したか - メンバーアカウントの Security Hub画面を使用してトリアージ - リソース単位の抑止もメンバーアカウント側で実行する必要があるので、トリアージと同時に実 施 心の声 - Secuity Hubに集約すると使いにくくなるのは矛盾を感じる
(C) Gunosy Inc. All Rights Reserved. PAGE | 45 本番展開後に発生した問題(2/5)
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ブログ等で参考情報を発見 - 運用の知見 - 調査してみたが自社に適用できそうな事例はなかった - トラブル事例 - 料金高騰事例を発見
(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形式で指定) - リソース指定はホワイトリスト方式
(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/,$//'
(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内部サービスで自動的に作成されるリソースへの指摘はどうにかして欲しい
(C) Gunosy Inc. All Rights Reserved. 6. まとめ
(C) Gunosy Inc. All Rights Reserved. PAGE | 51 まとめ
AWS Security Hubとうまく付き合いましょう ▪ 導入よりもその後の運用が大事です – 検知だけして満足しない、修復するまでが運用です ▪ 実環境でミスコンフィグを潰せたら、新たなミスコンフィグを持ち込ませない ようにしましょう – Shift-left大事 ▪ Security Hubを使うとAWSセキュリティを効率よく監査できます – 指摘が細かすぎるところはうまくトリアージしましょう ▪ アクセス権限、不正アクセスはSecurity Hub単体ではチェックできないの で、他のサービスと組み合わせましょう – IAM Access Analyzer – GuardDuty – 等々
情報を世界中の人に最適に届ける