AWSアカウントセキュリティ入門

# はじめに
　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による自動修正など）を呼び出す手段として、以下の選択肢がある。
1. サービスから**直接**、後続処理を呼び出し
2. サービスから**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**: メンバーアカウント

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/577028/955a219a-c17d-6074-7d2d-563e4c2731e1.png)

### ガードレールの考え方
 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等による通信の暗号化



# 参考記事
- [AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー](https://www.amazon.co.jp/AWS%E3%81%AE%E8%96%84%E3%81%84%E6%9C%AC%E2%85%A1-%E3%82%A2%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%81%AE%E3%83%99%E3%83%BC%E3%82%B7%E3%83%83%E3%82%AF%E3%82%BB%E3%82%AA%E3%83%AA%E3%83%BC-%E4%BD%90%E3%80%85%E6%9C%A8%E6%8B%93%E9%83%8E-ebook/dp/B08F3BVSJQ/ref=sr_1_2?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&crid=3PWI2TM0E6NUP&keywords=aws+%E3%82%A2%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3&qid=1652139822&sprefix=aws+%E3%82%A2%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%2Caps%2C217&sr=8-2) 
- [Qiita - AWS Security Hub](https://qiita.com/leomaro7/items/0dacee1abea26e54596d)
- [AWSブログ - スタートアップにおけるマルチアカウントの考え方と AWS Control Tower のすゝめ](https://aws.amazon.com/jp/blogs/startup/multi-accounts-and-control-tower/)
- [AWSドキュメント - セキュリティのベストプラクティス](https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/sec-bp.html)