AWS Security Hub を活用してマルチアカウントのセキュリティを強化した話 / Multi-account operation with AWS Security Hub

© SAISON INFORMATION SYSTEMS CO.,LTD. 2021
株式会社セゾン情報システムズ
小杉隼人
2021/3/20
AWS Security Hub を活用してマルチアカウントの
セキュリティを強化した話

View Slide

2
自己紹介
◼小杉隼人
⚫ 所属
⚫ 株式会社セゾン情報システムズ
⚫ テクノベーションセンター
⚫ 先端技術部バイモーダル推進チーム
⚫ 業務
⚫ AWS に関連する事業部支援と技術教育
⚫ 2019/2020 APN AWS Top Engineers
⚫ AWS Community Builder

View Slide

© SAISON INFORMATION SYSTEMS CO.,LTD. 2021 3
会社概要
◇ 社名株式会社セゾン情報システムズ SAISON INFORMATION SYSTEMS CO.,LTD.
◇ 設立年月日 1970 年 9月 1日
◇ 代表取締役社長内田和弘
◇ 資本金 1,367百万円
◇ 事業内容
 フィナンシャル IT サービスビジネス
 流通 IT サービスビジネス
 リンケージビジネス
 HULFTビジネス
◇ 年間売上高 23,560百万円（2020年 3月期連結）
◇ 社員数 749名（2020年 9月末現在連結）
◇ 上場市場東京証券取引所JASDAQスタンダード市場（証券コード 9640 / 1993年 11月公開）
◇ 主要株主（上位 3
社）
 株式会社クレディセゾン
 イーシーエムエムエフ
 イーシーエムマスターフアンドエスピーブイワン
◇ グループ会社
 世存信息技術（上海）有限公司
 HULFT Pte. Ltd.
 HULFT, Inc.
◇ 認定・届出総務省電気通信事業者届出
◇ 品質・セキュリティ
への取り組み
プライバシーマーク付与認定取得登録番号【11820059】
JISQ27001:2014（ISO/IEC27001:2013）認証取得登録番号【JMAQA-S030】

View Slide

4
本日お話させていただく内容
◼AWS Security Hub 導入について
⚫ 導入前の課題
⚫ 制度導入までのながれ
◼AWS Security Hub 導入後の運用
⚫ 準拠状況のモニタリング
⚫ 社内規約に準拠したアカウント作成の自動化

View Slide

AWS Security Hub の導入について

View Slide

6
導入前の課題
◼ AWS アカウントの管理は各部門ごとに実施
• 問題発生時の影響が大きいにも関わらず会社としてのアカウント管理基準がなかった
• どのような AWS アカウントがあるか組織的に管理できていなかった
• 対応は現場まかせ、属人化、そもそも対応していなかったケースも
• 対応していたとしてもそれが第3者的に表現できていなかった
◼ セキュリティインシデントの発生
• セキュリティグループが適切に設定されていない
• ログが取得されていないなどの基本的な知識不足によるもの
既に各部門で多様な運用が行われている環境で
新たなルールを落とし込んで行くには？

View Slide

7
対策として必要だったこと
IAM の管理基準
ガバナンス
組織的な体制の構築
各種ログの取得
インシデント発生時のフォレンジック
ログがないと何が起きたか全くわからない
変更の通知
意図しない設定変更の把握

View Slide

8
◼ CIS Benchmarks™
米国の非営利団体である CIS® (Center for Internet Security, Inc. )が公開している
各種 OS、サーバー、クラウド環境などのセキュリティを強化するためのガイドライン
140 以上の CIS Benchmark が発行されており、PCI DSS などのコンプライアンス要件で
業界で認められているシステム強化標準などの記載があった場合にも参照される
◼ CIS AWS Foundations Benchmark
基本的、テスト可能、アーキテクチャに依存しない設定に重点が置かれた
AWSサービスのセキュリティオプションを設定するためのガイダンスを提供
◼ Security Hub で準拠状況を自動的かつ継続的に確認可能
CIS AWS Foundations Benchmark を採用

View Slide

9
CIS AWS Foundations Benchmark がカバーする領域
IAM
(22項目)
Monitoring
(14項目)
Networking
(4項目)
アカウント内のログ取得と
管理方法に関する推奨事項
VPCのセキュリティに
関する推奨事項
アカウントアクティビティ
のモニタリングに関する
推奨事項
Logging
(9項目)
アカウントやユーザーID
のアクセス管理に関する
推奨事項
※ v1.2.0 時点。 v1.3.0 では Storage が追加

View Slide

10
◼ セキュリティアラートの一元的な表示および管理を行い、チェックを自動化する
AWS Security Hub とは
https://aws.amazon.com/jp/security-hub/ より引用

View Slide

11
◼ 一連のルールに対し自動的・継続的なチェックを実行、準拠状況のスコアを提供する
• CIS AWS Foundations Benchmark v1.2.0
• AWS 基礎セキュリティのベストプラクティス v1.0.0
• PCI DSS v3.2.1
◼ Security Hub で自動チェックできない項目
1.15 秘密の質問が AWS アカウントに登録されていることを確認する
1.17 現在の連絡先を最新の状態に維持する
1.18 セキュリティ連絡先情報が登録されていることを確認する
1.19 インスタンスからの AWS リソースアクセスに IAM インスタンスロールが使用されていることを確認する
1.21コンソールパスワードを持つIAMユーザーの初期セットアップ中にアクセスキーを設定しない
4.4 VPCピアリングのルーティングテーブルが「最小アクセス」であることを確認する
Security Hub のセキュリティ標準機能

View Slide

12
Security Hub よるチェックを社内規約化
AWS Security Hub
Account
Administrators
Email
Compliance status
check process
AWS Security Hub
AWS Security Hub
Account
Findings
Findings
Findings
Security Tooling Account Account
AWS Security Hub
Account

View Slide

13
◼ 当社が契約、管理するアカウントすべて
• サプライチェーンの観点で、各製造工程においてもセキュリティを考慮する必要があるため
開発、検証、デモ環境、研修環境等も含む
• 個社向け環境については、セキュリティ要件の取り決めが定義されており、管理プロセスが
確立している場合は事業部長および品質管理部門が協議の上で対象外とすることもできる
◼ 適合基準は以下の 2 項目を除き、全て満たすこと
• CIS 1.9 IAM パスワードポリシーは 14 文字以上の長さが必要です
• CIS 1.10 IAM パスワードポリシーはパスワードの再使用を禁止しています
除外理由: MFA の使用を必須とし、パスワードに対する総当たり攻撃への対策が取られているため
適用範囲

View Slide

14
◼ アカウント管理者
• AWS アカウント毎に正副の管理者を設定
• 非準拠が発生した場合の是正設定を行う
• セキュリティインシデント発生時の対応
◼ 品質管理部門
• 当社でアカウント保有するアカウントおよびその管理者を把握
• アカウント管理者との組織的な体制の構築および維持
• 基準を満たさないアカウントの管理者に対し注意喚起を行う
◼ 技術支援部門
• 技術的な問題が発生した場合の支援を行う
体制
アカウントA アカウントB
…
管理者管理者
技術支援部門品質管理部門
アカウント・管理者の把握
モニタリングの実施

View Slide

15
制度導入までの流れ
2019/6 2019/7 2019/8 2019/9 2019/10 2019/11 2019/12 2020/1 2020/2 2020/3
管理者への
ヒアリング
制度案の
作成
パイロット
運用
社内規定化リリース
在宅勤務
開始
移行期間

View Slide

16
◼ 制度案の説明や現在の運用状況を個別にヒアリング (2019/6～2019/8)
• 時間をかけて全アカウント管理者に対し実施
• 一部アカウントではルートや共有ユーザー使用、CloudTrail 未設定などの状況も判明
• 会社としての基準ができる点においては賛同を得られた
◼ ヒアリングで出た懸念や課題の例
• そもそも設定の仕方がわからない
• 開発アカウントは機密情報を含んでいないので対策が不要だと思いこんでいる
• 各種設定追加によるコスト増加の懸念など
既存アカウント管理者へのヒアリング

View Slide

17
◼ 制度案の作成、パイロット運用 (2019/9～2019/11)
• ヒアリングで得た課題から必要な対策をまとめ、ルール案を作成
• 一部アカウントとリージョンに絞ってパイロット運用を実施
• 設定による既存運用アカウントへの影響やコストを確認するため
◼ 社内規定化とリリース(2019/12)
• 同時期に勉強会を実施し、既存アカウント管理者への対応内容を案内
• 新規アカウント発行はワークフローを整備
• 準拠設定済みのアカウント払い出しを自動化
パイロット運用の実施、制度化

View Slide

18
◼ Security Hub の有効化 (～2020/1)
• 監査用アカウントへの接続
• CloudTrail / Config / CloudWatch など前提サービスの設定
• アカウント管理者に手順および CloudFormation テンプレートを提供
◼ Security Hub のチェックにより非準拠となった項目の是正(～2020/3)
• コントロールごとの修正手順を展開
• リモートでの設定支援や移行期間の確保により大きな問題は発生しなかった
移行期間を3ヶ月確保

View Slide

19
注力した点
◼ すでに個別の運用が確立してる環境にどう浸透を図っていくか
アカウント管理者へのヒアリング
困っていること、課題に感じていることを制度案に反映させる
なぜ実施するのか、利用者にどんなメリットが有るのかを伝える
アカウント管理者の知識の底上げ
専用 Slack チャンネルでの問い合わせ対応、非準拠発生時のサポート
CloudFormation テンプレートの提供

View Slide

20
CIS Benchmark と Security Hub 導入によって得られたもの
◼ “アカウント” 観点で Foundational な設定を統一、維持
◼ チェック対象としているリソースの準拠率は 99 % 以上
◼ 準拠状況を可視化し、継続的にモニタリングできる仕組み
◼ 管理者の意識、スキルの向上

View Slide

21
◼月にもよるが、全請求額の 1～2 % 程度
参考: Security Hub の支払い料金
https://aws.amazon.com/jp/security-hub/pricing/ より引用

View Slide

AWS Security Hub 導入後の運用

View Slide

23
◼ 全リージョンが対象
• すべてのリージョンで 100% を目指しているわけではない
• 一部の項目は単一リージョンのみに設定されていれば OK としている
◼ Logging の CloudTrail 関連の設定
• マルチリージョン証跡(単一リージョンですべてのリージョンの証跡)を設定するため
• CIS 2.2, 2.3, 2.6
◼ Monitoring の CloudWatch アラーム
• CloudTrailのアクティビティからメール通知を行うため、複数リージョンの設定は不要
• CIS 3.1～3.14 および 1.1 ( 3.3 に規定されている監査手順でチェックを行うため)
準拠状況のモニタリング

View Slide

24
◼ 組織内のルールに応じて特定のコントロールを無効化できる
• マスターアカウントで無効化した場合、メンバーアカウントの結果は確認できなくなり、
個々のメンバーアカウントでは引き続きチェックが行われる
• メンバーアカウントで無効化した場合、マスターアカウントの結果一覧から除外される
個々のコントロールの無効化機能
無効化した日付や理由を残すことが可能
Security Hub はセキュリティチェックの回数
で課金されるため、コスト最適化にもつながる

View Slide

25
◼ 特定のグループ化条件とフィルタでリソースや環境毎にデータを集約
• マスターアカウントでは AWS アカウントごとに検出結果を集約できる
• e.g., AWS アカウントごとの非準拠リソース数
カスタムインサイト
アカウントID をクリックして、リージョン内の非準拠リソースを即座に確認できる

View Slide

26
◼ 非準拠状態が続く場合、管理者にメールで通知する
• 連続7日以上→アカウント管理者に通知
• 連続21日以上→アカウント管理者の上長を含め通知
◼ 違反状態の定義をバッチ側で吸収
• 全リージョンで PASSED であるべき項目
• 何れかのリージョンで PASSED であればよい項目
• 特定アカウントの除外項目など
◼ 現状、違反項目の自動修正までは行ってない
準拠状況をモニタリングするバッチ処理

View Slide

27
◼ AWS Security Blog で公開されているサンプル実装
• カスタムインサイトで Findings をサマリし、結果を Email で送信する
参考: How to set up a recurring Security Hub summary email
アラートはセキュリティチームに集約されるが、
実際の調査・修正は多くの場合、実務担当者が行うため、
メールやチャットツールでの通知は有用
https://aws.amazon.com/jp/blogs/security/how-to-set-up-a-recurring-security-hub-summary-email/ より引用

View Slide

28
◼ AWS Solution Library に公開されているアドオンソリューション※1
• CIS AWS Foundations Benchmark v1.2.0 の一部の推奨事項について自動修正を行うことが可能
• マスターアカウントの Service Catalog にリージョン毎にデプロイする必要がある
• 特定のメンバーアカウントのみに実装したい場合は、AWS Blog ポスト※2 の内容を検討
参考: Automated Response and Remediation
※1 https://aws.amazon.com/jp/solutions/implementations/aws-security-hub-automated-response-and-remediation/
※2 https://aws.amazon.com/jp/blogs/news/automated-response-and-remediation-with-aws-security-hub/ より引用
デフォルトでは Security Hub のカスタムアクションを
使用してプレイブックを手動起動
設定により、リアルタイム検知とプレイブックの自動実行が可能

View Slide

29
◼ AWS Landing Zone の Account Vending Machine をカスタマイズ
• 申請情報元に AWS Service Catalog へ登録済みのアカウント作成処理を起動
• 実体は CloudFormation テンプレート & Lambda 関数
ルールに準拠したアカウント作成の自動化
https://aws.amazon.com/jp/solutions/implementations/aws-landing-zone/
IAM ユーザーにAWS Organizations 等の操作権限は不要
Service Catalog 製品の起動自体が CLI/SDK から自動化可能
ワークフローから以下の情報を受け取る
• アカウント名
• アカウントメールアドレス
• アラート通知先メールアドレス

View Slide

30
◼ Security Hub の設定
• マスターアカウントからの招待
• メンバーアカウントでの有効化および招待の承認
• 特定コントロールの無効化
◼ 各種サービスの設定
• CloudTrail 証跡設定
• CloudWatchモニタリング設定
• IAM: パスワードポリシー、サービスロールの作成
• Config 有効化
• デフォルト VPC の削除
• アカウントレベル S3 パブリックアクセスブロック
主なカスタマイズ内容
実装当時は eu-north-1 で StackSets が使用できなかったため
全リージョンに設定が必要な設定は API 経由とした
CloudFormation に対応していないリソースも API で操作

View Slide

31
アカウント作成と Security Hub 有効化の流れ
AWS Organizations
Lambda function
OrganizationAccountAccessRole
AWS Security Hub
Master
Security Account
New Account
Management Account
AWS Security Hub
Member
1. アカウント作成
2. メンバーの作成と招待
4. 招待の承認
3. サービス有効化
AWS Service Catalog

View Slide

32
◼ 同一組織内でサポートされる機能
• 組織の管理アカウントから Security Hub の管理者アカウントを委任
• 招待&承認のプロセスが不要に
• 新規アカウントをメンバーアカウントとして自動的に追加
• メンバーアカウント自身での関連付けの解除を防止
参考: AWS Organizations との統合機能 (New 2020/11/23)
管理者アカウントの指定はリージョン毎に設定する
指定するアカウントは同一でなければならない

View Slide

33
◼ 大阪リージョンはオプトインではなく、デフォルトで有効
• 追加で CIS Benchmark の準拠対応を行う必要がある
• Security Hub は 2021/3/20 時点で大阪リージョンに未対応
• 準拠作業は進めつつ、大阪リージョン対応後は AWS Organizations 統合で自動有効化したい
大阪リージョン正式リリースの対応
EC2 の DescribeRegions API で有効なリージョンのリストを取得していたため、無慈悲にも処理がエラーに
AWS Organizations 統合に移行すれば今後同様の事象は回避できそう

View Slide

34
運用時に苦労した点
◼ 主に AWS 側のサービス仕様
Security Hub API の Rate Limit
アカウントセットアップ時、Too Many Requests が頻繁に発生
AWS SDK 側で適切にリトライするように設定する必要がある
CloudFormation と API 操作の挙動が一致しない場合がある
例: CFn で Security Hub を有効化した際に、同時に有効になるセキュリティ標準
CIS のみ → どれも有効化されない → CIS/AWS基礎 (現在) と数ヶ月の間に変化
アナウンス無しで変更されており、サポート問い合わせで判明

View Slide

35
まとめ
◼ 既存運用環境への導入においては、ヒアリングと移行期間の確保に注力
• 管理者が感じていた課題や不安を軽減できた
◼ アカウント発行時の初期セットアップ
• アカウント管理者が設定する項目は必要最小限に
◼ 全リージョンの状況をモニタリングするには工夫が必要だった
• Security Hub はリージョナルサービス
• リージョンによってチェック項目数を変更
• アカウント全体での監視条件を定義し、バッチ処理でチェック

View Slide

36
参考リンク
◼ CIS AWS Foundations Benchmark v1.3.0 の変更点
https://qiita.com/hayao_k/items/fed7c07c9f05c445ce1f
◼ Boto3 に追加されたリトライ処理モードを利用する
https://qiita.com/hayao_k/items/1f20df24927a9a7776ca
◼ AWS Security Hubで特定のコンプライアンスチェック項目を無効化する
https://qiita.com/hayao_k/items/a186c461dbc7bd523b5a
◼ AWSアカウント作成時にSecurity Hubのマルチアカウント設定を行う
https://qiita.com/hayao_k/items/a06c53c542dd1fd1ee5e
◼ kube-benchの実行結果をAWS Security Hubに連携して管理する
https://qiita.com/hayao_k/items/510c038efce81a1abeca

View Slide

View Slide

AWS Security Hub を活用してマルチアカウントのセキュリティを強化した話 / Multi-account operation with AWS Security Hub

AWS Security Hub を活用してマルチアカウントのセキュリティを強化した話 / Multi-account operation with AWS Security Hub

hayao_k

More Decks by hayao_k

Other Decks in Business

Featured

Transcript