はじめに
UCのセキュリティルールの選定に苦戦したため、同じように困っている方の助けになればと思い、書き留めます。
LZA（Landing Zone Accelerator on AWS）とは？
※LZAをよくご存じの方は読み飛ばしてください。
AWSでシステムを運用していると、用途ごとにAWSアカウントを分けることがあります。
例えば、次のような構成です。
本番環境用アカウント
開発環境用アカウント
ログ管理用アカウント
セキュリティ管理用アカウント
ネットワーク管理用アカウント
アカウント数が少ないうちは個別に設定できますが、アカウントが増えると、すべてのアカウントに同じセキュリティ設定を適用することが難しくなります。
例えば、次のような設定を各アカウントで個別に行うのは大変です。
- CloudTrailを有効にする
- 操作ログを専用アカウントへ集約する
- GuardDutyやSecurity Hubを有効にする
- 利用可能なAWSリージョンを制限する
- S3バケットの公開を禁止する
- 共通のネットワークを構築する
- AWS Configでリソースの設定を監視する
このような複数のAWSアカウントに共通する設定を、まとめて構築・管理するための仕組みが、Landing Zone Accelerator on AWS、略して「LZA」と呼ばれます。
LZAでは、設定ファイルに組織構成やセキュリティ設定を記述し、その内容を各AWSアカウントへ展開します。
そのため、AWSアカウントを一つずつ手作業で設定するのではなく、組織全体に統一した設定を適用できます。
Control TowerとLZAの関係
※LZAをよくご存じの方は読み飛ばしてください。
LZAと一緒によく登場するサービスが、AWS Control Towerです。
Control Towerは、AWS Organizationsを利用したマルチアカウント環境を管理するための基盤です。
LZAはControl Towerを土台として、Control Towerだけでは設定しきれないセキュリティ、ネットワーク、ログ管理などの機能を追加します。
簡単に表すと、次のような関係です。
| サービス | 主な役割 |
|---|---|
| AWS Organizations | 複数のAWSアカウントを組織として管理する |
| AWS Control Tower | マルチアカウント環境の基本的なガバナンスを提供する |
| LZA | Control Towerを土台に、より詳細な設定を組織全体へ展開する |
LZA Universal Configurationとは
LZA Universal Configuration、通称UCは、LZAを利用してセキュアなマルチアカウント環境を構築するための、AWS公式の設定テンプレートです。
UCには、主に次の設定が含まれています。
- OrganizationsとOUの構成
- Control Towerのコントロール
- Security Hubのセキュリティ標準
- AWS Configルール
- SCPやRCP
- GuardDuty、Macieなどのセキュリティサービス
- ログの集中管理
- ネットワーク構成
- IAM Identity Center
UCは、Control Towerのベースラインに加えて、LZAによる追加の予防的コントロール、発見的コントロール、セキュリティサービスを組み合わせることで、多層防御を実現しています。
ただし、UCを導入するだけで自動的に特定の規格へ準拠できるわけではありません。
組織のセキュリティ要件に合わせて、各ルールの必要性や適用先を確認し、決定する必要があります。
AWSのマルチアカウント環境でセキュリティを強化しようとすると、次のような疑問が出てきます。
- Control Towerのコントロールを使うべきか
- Security Hubのコントロールを使うべきか
- AWS Configルールを追加するべきか
- 独自のカスタムルールを作るべきか
これらを整理せずに設定すると、同じ内容を複数のサービスで評価してしまい、ルールの重複や運用の複雑化につながります。
そこで本記事では、LZA Universal Configurationにおいてセキュリティ要件を実装するときの考え方を、次の順番で整理します。
Control Tower
↓
Security Hub
↓
AWS Configマネージドルール
↓
AWS Configカスタムルール
先に結論を書くと、これはサービスの「実行優先順位」ではありません。
同じセキュリティ要件を、どのサービスで実装するかを検討する順番です。
セキュリティルールを選ぶ順番
1. 最初にControl Towerのコントロールを確認する
セキュリティ要件が出てきたら、最初にControl Towerのコントロールで実現できないかを確認します。
Control Towerのコントロールには、主に次の3種類があります。
| 種類 | 役割 | 主な実装方式 |
|---|---|---|
| 予防的コントロール | 違反する操作自体を拒否する | SCP、RCP |
| 発見的コントロール | 作成済みリソースの違反を検出する | AWS Configルール |
| プロアクティブコントロール | CloudFormationによる作成前に検査する | CloudFormation Hooks |
例えば、許可されていないリージョンでのリソース作成を禁止する場合は、Control Towerのリージョン拒否コントロールを利用できます。
Control Towerの発見的コントロールも、内部的にはAWS Configルールを利用しています。予防的コントロールはSCPやRCP、プロアクティブコントロールはCloudFormation Hooksによって実装されます。
そのため、Control Towerに同等のコントロールが存在するにもかかわらず、LZA側で同じAWS Configルールを追加すると、評価内容が重複する可能性があります。
Control Towerを最初に確認する理由
- OU単位で一元管理できる
- 新規アカウントにも継続して適用できる
- 予防、検出、作成前チェックを使い分けられる
- Control Towerの管理画面で適用状況を確認できる
- LZAやUCが前提としているガバナンス基盤である
まずはControl Towerのコントロールカタログを確認し、同じ要件を満たすコントロールがないかを探します。
2. 次にSecurity Hubのコントロールを確認する
Control Towerに該当するコントロールがない場合は、Security Hubのセキュリティコントロールを確認します。
Security Hubでは、次のようなセキュリティ標準を利用できます。
- AWS Foundational Security Best Practices
- CIS AWS Foundations Benchmark
- NIST SP 800-53
- PCI DSSなど
公開されているUCのデフォルト設定例では、AWS Foundational Security Best Practices、NIST SP 800-53 Revision 5、CIS AWS Foundations Benchmark v3.0.0が有効化されています。また、複数リージョンの結果を集約する設定も含まれています。
Security Hubのメリットは、単にリソースの準拠・非準拠を判定するだけではない点です。
- 複数のセキュリティ標準を利用できる
- アカウントやリージョンを横断して管理できる
- セキュリティスコアを確認できる
- GuardDutyやInspectorなどの検出結果を集約できる
- EventBridgeを利用した通知や自動対応につなげられる
Security Hubの多くのコントロールは、サービスにリンクされたAWS Configルールを使ってセキュリティチェックを実行します。Security Hubでコントロールを有効化すると、必要なルールが環境内に作成されます。
そのため、Security Hubで既に同じ内容を評価している場合、同等のConfigマネージドルールを追加する必要があるかを慎重に判断します。
3. 不足する場合はAWS Configマネージドルールを使う
Control TowerとSecurity Hubのどちらにも該当するルールがない場合は、AWS Configのマネージドルールを確認します。
AWS Configマネージドルールは、AWSがあらかじめ用意しているルールです。
例えば、次のような設定を評価できます。
- EBSボリュームが暗号化されているか
- 必須タグが設定されているか
- セキュリティグループで特定ポートが公開されていないか
- CloudTrailが有効になっているか
- S3バケットが公開されていないか
マネージドルールでは、評価対象となるリソースや、判定に使用するパラメータを設定できます。
Configマネージドルールが向いているケース
- Control Towerに対象コントロールがない
- Security Hubの標準に対象コントロールがない
- Security Hubでは無効化しているが、特定OUでは評価したい
- 評価対象やパラメータを組織独自に設定したい
- Managementアカウントなど、Control Towerだけではカバーできない場所を評価したい
UCでは、Control Towerからルールを配置できないManagementアカウントに対して、追加のConfigルールを配置する構成も採用されています。
AWSが用意したマネージドルールで要件を満たせるのであれば、独自コードを作るよりも、マネージドルールを利用した方が管理しやすくなります。
4. 最後にAWS Configカスタムルールを作る
Control Tower、Security Hub、Configマネージドルールのいずれでも要件を満たせない場合に、Configカスタムルールを検討します。
Configカスタムルールには、主に次の2種類があります。
- AWS Config Custom Policy Rule
- AWS Config Custom Lambda Rule
Custom Policy Ruleでは、CloudFormation Guardのルール構文を使用して判定条件を記述します。
Custom Lambda Ruleでは、Lambda関数に独自の評価処理を実装します。
カスタムルールが必要になる例
- リソース名が社内の命名規則に従っているか
- 特定システムのリソースだけ独自条件で評価したい
- 複数のリソース設定を組み合わせて判定したい
- AWSのマネージドルールでは設定できない例外条件がある
- 特定のタグ値によって評価内容を変更したい
カスタムルールは柔軟ですが、実装後のテストや保守も必要になります。
特にLambdaを利用する場合は、次の項目も管理対象になります。
- Lambdaのソースコード
- IAMロール
- ランタイムの更新
- エラー処理
- 実行ログ
- 評価対象のスコープ
- Lambdaの実行回数
そのため、カスタムルールは最初から作るのではなく、既存のコントロールやマネージドルールで実現できない場合の最終手段と考えます。
まとめ
セキュリティ要件が出てきた場合は、次の順番で確認します。
整理すると、次のようになります。
| 確認順 | サービス | 主な目的 |
|---|---|---|
| 1 | Control Tower | OU・アカウント全体のガバナンス |
| 2 | Security Hub | セキュリティ標準による継続的評価 |
| 3 | Configマネージドルール | 標準機能で不足する個別要件の評価 |
| 4 | Configカスタムルール | 組織独自の要件の評価 |
Control Towerをガバナンスの土台とし、Security Hubで標準的なセキュリティチェックを行います。
そのうえで不足する要件をConfigマネージドルールで補い、それでも実現できない組織独自の要件だけをカスタムルールとして実装します。
この順番で設計することで、次の効果が期待できます。
- 重複ルールを減らせる
- セキュリティ設定の管理場所を明確にできる
- 独自コードを最小限にできる
- 新しいアカウントにも統一したルールを適用できる
- ルールの変更や廃止を判断しやすくなる
LZAやUCのセキュリティ強化では、単純にルールを増やすことよりも、どのサービスをルールの管理主体とするかを整理することが重要です。