はじめに
AWSのアカウントセキュリティ系のサービスは年々利便性が向上しており、AWSユーザや企業でも今後利用が拡大していくものと思われます。
複数アカウント利用の場合に有用な、下記のサービスについて、どのような役割や機能を持っているか学習したため、備忘録としてまとめました。
※ ハンズオン的な内容は含んでません。
- SecurityHub
- CloudFormation StackSets
- ControlTower
- （おまけ）AWSセキュリティのベストプラクティスと具体的な実装
SecurityHub
機能
- AWSのセキュリティ系サービスは現在20以上と非常に多くあり便利な反面、バラバラに各サービスによる検知状況を確認するのは大変。（運用の複雑化）
- Security Hubにより各サービスを一括してモニタリングする機能が提供されており、上記問題の解決手段となる。
- Security Hubでは、以下のようなセキュリティサービスが統合されており一括可視化できる。
- Config
- GuardDuty
- Macie
- Inspector v2
- Firewall Manager
- IAM Access Analyzer
- AWS Health
- Trusted Adviser
- Detective
- 単体のアカウントだけでなく、ControlTowerで管理されている複数のAWSアカウントの状況も一括して管理（可視化） できる。
- また、コンプライアンスへの準拠状況をチェックする機能もある。
統合か？個別検知か？
SecurityHubへの統合がサポートされているセキュリティ系サービスでは、検知からEventBridge経由で後続処理（Lambdaによる自動修正など）を呼び出す手段として、以下の選択肢がある。
- サービスから直接、後続処理を呼び出し
- サービスからSecurityHub経由で後続処理を呼び出し
SecurityHub経由する場合（上記2.）では下記の通り、自動/手動いずれでも後続処理の呼び出し可能。
-
Security Hub Findings - Imported：自動呼び出し（EventBridgeに送信） -
Security Hub Findings - Custom Action：ユーザがマネジメントコンソールからFindingsを確認し、対応必要と判断したら手動で後続処理呼び出し（EventBridgeに送信）
上記より、個人的には以下がおすすめなシステムなのではないかと考えている。
- 検出経路が複雑化回避のため、各セキュリティサービスから直接後続処理の呼び出し（上記1.）は、基本しない。
- SecurityHubに統合サポートされているサービスはできる限り統合し、SecurityHub経由（上記2.）で全て後続処理を呼び出す構成とする。
-
リアルタイムで自動的に防御すべきものは、
Security Hub Findings - Importedを利用する。 -
リアルタイム性低く、内容を人間が把握すべきものは
Security Hub Findings - Custom Actionを利用する。
-
リアルタイムで自動的に防御すべきものは、
CloudFormation StackSets
機能
StackSetsは、複数リージョンや複数アカウントに一括でCFnテンプレートを流せる機能。
Organization連携によるマルチアカウント管理
Organizationsと連携することで、メンバーアカウント作成時に自動でCFnを流してセキュリティのベースラインを確保できる。
- OU単位でどの環境にどのテンプレートを流すか設定できる。
- メンバーアカウントでのセキュリティサービス（CloudTrail, GuardDuty, Config等）のセットアップを自動化可能
ControlTower
機能
最近では、企業内で顧客別 / プロダクト別 / 環境別にAWSアカウントを分けることが当たり前になってきている。
そこで問題となるのが、各アカウントがバラバラに管理されていると、セキュリティのベースライン確保や脅威発生時の通知方法などの統制が難しく、アカウント増加につれて運用に工数がかかってしまうことである。
ControlTowerは複数のAWSアカウントを一元管理し、AWS OrganizationsやCloudFormation等と連携して簡単に統制できるようにできるサービス。
アカウントの分割目的
そもそも、AWSアカウントを分けることのメリットは何か？それは下記のような、主に運用のシンプル化としての利点が挙げられる。
管理面でのメリットだけでなく、開発面でも新規サービスの立ち上げやリリース速度を高速にできるというメリットもある。
-
1. 環境の分離
開発/ステージング/本番など環境別でアカウントを分けることで、- セキュリティ対策・ガバナンス統制を分離できる。
- セキュリティ監査がしやすい。
- SLOが異なるシステムが同一環境に同居することによる問題が起きない。
-
2. 請求の分離
部門やプロダクト単位でAWS利用料を明確に分離できる。 -
3. 権限管理がシンプル
- OrganizationsやSSOを利用することで、部門別でアカウントに持たせる権限管理を明確・簡単化できる。
-
4. ワークロードの分離
ワークロードで（プロダクトや環境別で）アカウントを分離することで、- 変更による他システムへの影響を縮小できるため、意思決定を早めることができ高速な変更が可能。
- AWSのリソース数上限にかかる可能性を緩和できる。
デフォルトアカウント
ControlTower有効化時に、最低で以下のAWSアカウントが作成される。
- マスターアカウント （有効化したアカウント）
- ログ管理用アカウント
- 監査用アカウント
上記のようにメンバーアカウントだけでなく、管理用のアカウントも分割しているのは、下記理由がある。
-
1. 一元管理
各アカウントでログ保存するのではなく、用途別で集約して、トラブル発生時に管理者が簡単に参照できるようにする。 -
2. 改ざん防止
例えば、メンバーアカウントから監査アカウントへのログの書き込み権限のみだけ付与し、既存ログの変更・削除はできないようにする。
メンバーアカウント内のログであれば、そのアカウントのAdministrator権限持っていれば削除等できるが、リアルタイムにログ/監査アカウントに集約するようにすれば改ざんは防げることになる。
OU
- CoreOU: 管理用の上記3アカウント
- CustomOU: メンバーアカウント
ガードレールの考え方
ControlTowerには、ガードレールという機能がある
ガードレールの設計思想はブレーキをかけるのではなく、どんなスピードを出しても安全なセキュリティ。
問題の発生しそうな操作を完全にできなくするのではなく、検知して自動or手動で対処することで、セキュリティを担保した上で迅速なシステム構築や開発を可能にする。
予防
そもそも特定の操作ができないようにする。
実体：Organizations SCP
検知
脅威となる可能性のある設定権限を完全に剥奪するのではなく、それが実行された場合は検出して対処する。
実体：Config Rules
ガードレールの実装
ControlTowerには予防/検出でガードレールの初期設定がある。
必須事項は無効化できない。
その他推奨事項は任意で有効化するか、ユーザでカスタム作成し有効化する。
（おまけ）AWSセキュリティのベストプラクティスと具体的な実装
AWS Well-Architectedフレームワークの柱のうち、セキュリティでは以下のベストプラクティスが紹介されている。
- セキュリティ
- アイデンティティ管理とアクセス管理
- 発見的統制（検出）
- インフラ保護
- データ保護
- インシデント対応
上記太文字の項目に絞り、具体的にAWSサービスでどのように対策をとるべきかをまとめる。
発見的統制
リスクの発生後に、そのリスクに対処すること。
（対になるものが予防的統制だが、これはIAM, Organizations SCPがある。）
発見的統制は、以下のフローを意識して実装していく。
-
定義
取得すべきログ、メトリクス、アラート要件を決める -
ログ取得の実装
AWSではおもに、以下のようなログ取得の方法がある。- CloudTrail
- VPC FlowLog
- CloudFront, WAF等のサービスログ→S3に出力
- コンピューティング環境でのOSログ、アプリケーションログ
-
検出、アラートの実装
- CloudWatchアラーム
- GuardDuty
- Athena
- QuickSight
インフラ保護
-
ネットワークの保護
- CloudFront
- WAF
- Shield
- VPC設定の保護→ConfigRulesで違反検知してSSM Automationで自動修正するなど
-
コンピューティングの保護
- Inspector v2によるOS,ミドルウェアの脆弱性検出
- SystemsManager PatchManagerによるパッチ適用
データ保護
-
データの分類
- MacieによりS3に格納された機密情報を分類し、アラートを出すことが可能。
-
データ保護
- S3,EBSの暗号化
- それぞれ暗号化強制orされていない場合の検知するためにSCP, Config利用する。
-
データ転送
- ACM, VPN等による通信の暗号化