Slide 1

Slide 1 text

2022年 12月 AWS Organizations を活用したセキュリティ通知のやり方

Slide 2

Slide 2 text

自己紹介 2 STORES 株式会社 セキュリティ本部所属 shimizu yuhei / toripiyo 趣味 - ランニング、投資、読書 好きなAWSサービス - SecurityHub、StepFunctions、Lambda

Slide 3

Slide 3 text

セキュリティ本部の紹介 3 - 外部認証機関(ISMS, PCIDSS など)の監査対応 - 情報セキュリティポリシーの作成・改訂、遵守状況の確認 - 社内のセキュリティ教育コンテンツの作成・取りまとめ - セキュリティを考慮した開発ガイドラインの作成 - セキュリティインシデントに備えたBCP策定・訓練 - 開発・運用工程へのセキュリティ導入 <- 今回はこのあたりの話 - 脆弱性診断 - WEBアプリ、プラットフォーム、モバイル、ソースコード、パブリッククラウド - 脆弱性情報の収集とその影響評価 - セキュリティチェックシートの回答 - 外部サービス利用時のセキュリティチェック - などなど

Slide 4

Slide 4 text

本題:AWS Organizations を活用したセキュリティ通知

Slide 5

Slide 5 text

目次 5 背景 デザイン 実装 運用課題 導入効果 今後の予定 01 02 03 04 05 06

Slide 6

Slide 6 text

背景

Slide 7

Slide 7 text

- パブリッククラウドの監査 - AWS アカウントの設定を監査してチケットに起票 - 問題点 - 設定されてから監査までには時間差がある - 危ない設定があっても監査まで気付けない - 解決法 - 怪しい設定や不正アクセスについて監査前に気付けるように通知の仕組みを導入し よう 問題点 7

Slide 8

Slide 8 text

デザイン

Slide 9

Slide 9 text

○ 将来的なスケールを考えると、SecurityHub を経由させたほうが良いのでは?(ハブというぐ らいだし) 初期案(GuardDutyの場合) 9

Slide 10

Slide 10 text

SecurityHub を追加したイメージ(GuardDutyの場合) 10

Slide 11

Slide 11 text

SecurityHubを経由した構成を採用 11

Slide 12

Slide 12 text

SecurityHub を経由するメリット ● サービス、リージョン、アカウント単位で通知設定をする必要がなくなる ● 通知フォーマットが揃うので、EventBridgeのフィルタリング条件を再利用しやすい ● Slack 通知時のフォーマットがサービス(GuardDuty, IAM Access Analyzerなど)で共通化 ● 通知をオフにするときの手順を統一できる(workflow status を supressed に変更) ● 通知内容に記載のリンクをクリックしてブラウザから内容を確認できる(InspectorなどはURLで絞 り込めない) ● Findings の閲覧権限を持っていれば、別AWSアカウントからも同一のURLで SecurityHub の Findings を参照できる ● Findings の検索やグラフ表示(SecurityHub Insights)機能を利用できる 12

Slide 13

Slide 13 text

実装

Slide 14

Slide 14 text

この構成を実装したい 14

Slide 15

Slide 15 text

サービスの有効化 15

Slide 16

Slide 16 text

AWS Organizations の活用 AWS アカウントを AWS Organizations に追加するだけで有効化できるサービスがある 16 サービス名 有効化方法 IAM Access Analyzer AWS Organizationsに追加で有効化可能 Amazon GuardDuty AWS Organizationsに追加で有効化可能 Amazon Inspector AWS Organizationsに追加で有効化可能 AWS Health デフォルトで有効 AWS Security Hubの Security standards 機能 AWS Organizationsに追加とAWS Configの有効化が実質 必要

Slide 17

Slide 17 text

AWS Organizations の活用 AWS アカウントを AWS Organizations に追加するだけで有効化できるサービスがある 17 サービス名 リージョン単位の設定必要 有効化方法 IAM Access Analyzer Yes AWS Organizationsに 追加で有効化可能 Amazon GuardDuty Yes AWS Organizationsに 追加で有効化可能 Amazon Inspector Yes AWS Organizationsに 追加で有効化可能 AWS Health No デフォルトで有効 AWS Security Hubの Security standards Yes AWS Organizationsに 追加とAWS Configの有効化 が必要

Slide 18

Slide 18 text

ベースライン設定の自動適用 ● CodeBuildを利用してベースライン設定(AWSアカウント作成時に最低限設定するも の)を適用 18

Slide 19

Slide 19 text

SecurityHub の Findings の集約 19

Slide 20

Slide 20 text

SecurityHubの委任設定 ● マネジメントアカウントからセキュリティ本部のアカウントにSecurityHubの 設定権限を委任 20

Slide 21

Slide 21 text

東京リージョンに通知を集約 ● Finding aggregation で東京リージョンに Findings を集約設定 21

Slide 22

Slide 22 text

SecurityHub の Integrations の有効化 ● 各サービスの Findings 情報が SecurityHub に集約されるよう設定 22

Slide 23

Slide 23 text

通知経路の設定 23

Slide 24

Slide 24 text

Terraform の利用 ● Terraform のモジュール機能を利用 ○ Cloudformation も検討したが、社内では Terraform 利用者が多い。 ○ モジュールのパラメータを変更して、AWS リソースをデプロイ。 ○ ChatBot は Terraform で直接提供されていないので、CloudFormationをラッパーしている Terraformモジュールを利用 24 モジュール化

Slide 25

Slide 25 text

通知例 AWS Security Hub の Security standards からの通知 25

Slide 26

Slide 26 text

運用課題

Slide 27

Slide 27 text

AWS Security Hub の Security standards から頻繁に通知が届く ● 一度届いた Finding の workflow status を supressed に変更するようにし て、同じ通知が再び届かないようにした 27

Slide 28

Slide 28 text

セキュリティ本部で全ての通知を確認するのは難しい ● 全AWSアカウントの重要な通知のみ受けるSlackチャンネルを用意 ○ Event pattern を調整すれば、さまざまな通知条件を実現できる 28 # 特定のアカウントの SecurityHubのCRITICAL, HIGH, MEDIUMの通知を受ける { "detail": { "findings": { "AwsAccountId": ["123456789012"], "ProductName": ["Security Hub"], "RecordState": ["ACTIVE"], "Severity": { "Label": ["CRITICAL", "HIGH", "MEDIUM"] }, "Types": ["Software and Configuration Checks/Industry and Regulatory Standards/AWS-Foundational-Security-Best-Practices"], "Workflow": { "Status": ["NEW"] } } }, "detail-type": ["Security Hub Findings - Imported"], "source": ["aws.securityhub"] } # 全てのアカウントの SecurityHubのCRITICALの通知を受ける { "detail": { "findings": { "ProductName": ["Security Hub"], "RecordState": ["ACTIVE"], "Severity": { "Label": ["CRITICAL"] }, "Types": ["Software and Configuration Checks/Industry and Regulatory Standards/AWS-Foundational-Security-Best-Practices"], "Workflow": { "Status": ["NEW"] } } }, "detail-type": ["Security Hub Findings - Imported"], "source": ["aws.securityhub"] }

Slide 29

Slide 29 text

導入効果

Slide 30

Slide 30 text

導入して良かったこと ● 危ない設定がされた時には監査前から気づけるようになった ● 新しく作成されたアカウントについて追加工数なしで通知を受けられるようになった ● 各AWSアカウントの通知の仕組みを設計・実装する工数を削減できるようになった ● 通知箇所の運用費用はいまのところ月あたり10数ドルで済んでいる 30

Slide 31

Slide 31 text

今後の予定

Slide 32

Slide 32 text

今後 AWS Organizations を活用して取り組みたいところ ● SCPの利用 ○ 今回のセキュリティ通知は、発見的統制の考えに沿ったシステムの設計・実装。 ○ SCP を活用して予防的統制の実現にも取り組んでいきたい。 32

Slide 33

Slide 33 text

セキュリティエンジニアを募集中 ● STORES のセキュリティ本部では会社のセキュリティリスクをコントロールする施 策であれば、主体的に取り組める環境にあります。 ● いまの会社では出来ないけれど、セキュリティ施策としてこんなことをやりたいな どありましたら、是非 STORES をご検討いただければと思います。 ● 応募要件や福利厚生など、 詳しくは、STORESの採用サイト(https://jobs.st.inc/)をご覧ください。 33

Slide 34

Slide 34 text

34