AWS Organizationsを活用したマルチアカウントのセキュリティサービス使用方法 ～4. AWS Config～
Organizationsシリーズ第四弾、AWS Config編です。
AWS Configとは
AWSリソースの設定変更履歴を保存できるサービスです。たとえばあるセキュリティグループに対して、誰がどのような変更を行ったのか履歴で確認できます。
また、Configルールと修復アクションを使用することで、リソースが指定された状態になっているかチェックを行い、自動的に修復することも可能です。たとえば、セキュリティグループで0.0.0.0/0が設定されてインターネットに公開された場合に検知して自動削除するといった運用も可能になります。
Organizationsを使用したマルチアカウント設定
前提として、Config記録が全アカウント、全リージョンで有効になっている必要があります。 以下の手順で実施していきます。
- Organizationsの「信頼されたアクセス」有効化
- メンバーアカウントへ委任
- アグリゲータの作成
- (Option) Configルールの組織適用
Configはアカウントの委任をサポートしているため、集約するアカウントをマネジメントアカウント以外のアカウントに設定できます。
設定手順
1. 「信頼されたアクセス」有効化
Organizationsの設定のため、マネジメントアカウントで実行します。
Configルールで必要なconfig-multiaccountsetup.amazonaws.comの設定が現状CLIのみ実行可能なようなので、CLIで実行します。今回は手軽にCLIが実行できるCloudShell上で実行しました。
有効化コマンド：
$ aws organizations enable-aws-service-access --service-principal config.amazonaws.com $ aws organizations enable-aws-service-access --service-principal config-multiaccountsetup.amazonaws.com
確認コマンド：
$ aws organizations list-aws-service-access-for-organization --output text | grep config ENABLEDSERVICEPRINCIPALS 2020-12-22T04:00:11.418000+00:00 config-multiaccountsetup.amazonaws.com ENABLEDSERVICEPRINCIPALS 2020-12-22T02:27:53.842000+00:00 config.amazonaws.com
2. メンバーアカウントへ委任
こちらも同じくCLIで実行します。
※コマンド上の[委任アカウントID]は実際の環境に合わせて修正が必要です。
委任コマンド：
$ aws organizations register-delegated-administrator --account-id [委任アカウントID] --service-principal config.amazonaws.com $ aws organizations register-delegated-administrator --account-id [委任アカウントID] --service-principal config-multiaccountsetup.amazonaws.com
確認コマンド：
$ aws organizations list-delegated-services-for-account --account-id [委任アカウントID] --output text | grep config DELEGATEDSERVICES 2020-12-22T04:31:39.050000+00:00 config-multiaccountsetup.amazonaws.com DELEGATEDSERVICES 2020-12-22T04:31:31.375000+00:00 config.amazonaws.com
3. アグリゲータの作成
委任が完了したので、委任した監査アカウント上でアグリゲータを作成します。Configの画面上から作成できるため、GUIで実行します。
アグリゲータとは、複数アカウントのConfigの情報を集約して確認、設定できる機能です。
データレプリケーションを許可して、任意のアグリゲータ名を入力します。
組織を追加するを選択して、IAMロールを選択します。IAMロールはあらかじめ用意されているものを選びました。
すべてのリージョンを選択して保存します。
しばらく時間を置いて、アグリゲータの画面を見てみると、組織内の全アカウントのリソースが表示されます。 リソース名をクリックすると、各リソースの詳細も確認できます。
4. Configルールの組織適用
Configルールの組織単位の適用は、Configの画面上から設定できそうな項目は出てきませんでした。CLIで実行できそうなので、委任アカウントのCloudShellを使用してルールを作成してみます。
今回はAWSが管理しているルールであるguardduty-enabled-centralized (GuardDutyが有効になっているか）を使用します。Description内容はConfigマネージドルールで記載されている内容そのままです。
実行コマンド：
aws configservice put-organization-config-rule \ --organization-config-rule-name org-guardduty-enabled-centralized \ --organization-managed-rule-metadata \ Description="AWS アカウントおよびリージョンで、Amazon GuardDuty が有効になっているかどうかを確認します。一元管理用の AWS アカウントを指定した場合、ルールはそのアカウントでの GuardDuty の結果を評価します。GuardDuty が有効であれば、ルールは準拠しています。",\ RuleIdentifier="GUARDDUTY_ENABLED_CENTRALIZED"
実行結果：
{ "OrganizationConfigRuleArn": "arn:aws:config:ap-northeast-1:[委任アカウントID]:organization-config-rule/org-guardduty-enabled-centralized-tvymtmkq" }
しばらくしてConfigの集約ビューからルールを確認すると、以下のとおり組織内の3アカウントのルール準拠状況が確認できます。2アカウントでGuardDutyが有効になっていないです。良くないですね。
なお、ルール単体ではなくルールの集合である適合パックを適用する場合は、以下のコマンドで実行できます。
今回の例ではAWS側のサンプルにある「Operational Best Practices for Amazon S3」を適用しています。 コードはgithub上に上がっているのでそれをダウンロードしておきます。以下のコマンドではcurlコマンドでテンプレートをダウンロードしています。
実行コマンド：
# テンプレートダウンロード $ curl -LO https://raw.githubusercontent.com/awslabs/aws-config-rules/master/aws-config-conformance-packs/Operational-Best-Practices-for-Amazon-S3.yaml # 適合パック適用 aws configservice put-organization-conformance-pack \ --organization-conformance-pack-name org-s3-bestpractice \ --template-body "file://Operational-Best-Practices-for-Amazon-S3.yaml"
実行結果：
{ "OrganizationConformancePackArn": "arn:aws:config:ap-northeast-1:[委任アカウントID]:organization-conformance-pack/org-s3-bestpractice-52tw7yqa" }
適用された適合パックは以下のように見えます。適合パックに含まれる複数のルールが表示されています。
設定手順はここまでです。
さいごに
個人的には、ConfigはCloudTrailと同じくらいセキュリティ的に重要なサービスです。今回の記事ではOrganizationsを使用して組織内のすべてのアカウントに対して情報集約、ルール設定する方法を紹介しました。
Configルールを合わせて活用することで、組織全体の予防的統制、発見的統制に役立つことができると思います。AWSからも様々なルールが公開されていますので、まずは自分の組織に適用できるルールがないか確認し使用していくところから始めると良いと思います。
次回はGuardDutyの予定です。
