
Organizations環境でConfigルールを展開する方法を確認してみた
この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは。たかやまです。
Organizations環境でConfigルールを組織全体にデプロイしたいことはありませんか?
現在、組織全体にConfigルールを展開する方法は大きく分けて2つになります。
- CloudFormation StackSetsで組織内にデプロイする
 - Config API 
PutOrganizationConfigRuleで組織内にデプロイする 
CloudFormation StackSetsを使った場合とConfig APIを使った場合で設定されるConfigルールの設定に違いがあるので今回はこちらをまとめていきたいと思います。
さきにまとめ
| CloudFormation StackSets | Config API | |
|---|---|---|
| Configルールへの設定可否 | Configルールへ修復の管理、メンバーアカウントでのルール編集ができる | Configルールは「サービスにリンクされているAWS Configルール(SLR)」でデプロイされ、修復の管理、メンバーアカウントから編集はできない | 
| デプロイ範囲 | サービスマネージド型でデプロイした場合、管理アカウントへConfigルールはデプロイされない | Organizations参加しているすべてのアカウントにデプロイできる | 
| 自動デプロイ | 自動デプロイオプションでOrganizations参加アカウントへ自動デプロイ/削除の設定が可能 | 強制的にOrganizations参加アカウントへ自動デプロイ/削除を行う | 
確認してみた
前提条件
前提条件として、以下の設定は事前に行っています。
- 各アカウントでのConfig有効化
 - Organizationsの信頼されたアクセスの有効化
- CloudFormation StackSets : AWS Organizations で信頼されたアクセスを有効にします。 - AWS CloudFormation
 - Config : 
aws organizations enable-aws-service-access --service-principal config-multiaccountsetup.amazonaws.comの実行 
 
CloudFormation StackSets
CloudFormation StackSetsで展開する場合、ConfigルールをCloudFormationで設定する必要があります。
Configマネージドルールの場合AWSでCloudFormationテンプレートが公開されているので、こちらの内容を利用することで簡単に展開するテンプレートを用意することができます。
利用できるConfigマネージドルールの一覧はこちらです。
ここでは restricted-common-ports のConfigルールを使っていきたいと思います。
Configルールのページを開くと、識別子が記載されているのでこちらをコピーします。

コピーした識別子をこちらのURLのTHE_RULE_IDENTIFIERに入れることで目的のCloudFormationテンプレートを確認することができます。
http://s3.amazonaws.com/aws-configservice-us-east-1/cloudformation-templates-for-managed-rules/<THE_RULE_IDENTIFIER>.template

あとは展開したいConfigルールのテンプレートをCloudFormation StackSetsでデプロイしていきます。
CloudFormation StackSetsのデプロイでは先ほど確認したURLをテンプレートの指定に設定することでそのまま利用することができます。

利用するConfigルールのパラメータ設定をします。

他のオプションは環境に合わせて設定していきます。

デプロイが完了すると、各アカウントでConfigルールを確認することができます。
後述する、PutOrganizationConfigRuleでデプロイされるConfigルールは編集/アクションを利用することはできませんが、CloudFormation StackSetsで展開されたルールは編集/アクションの利用が可能です。

また、このときCloudFormation StackSetsをサービスマネージド型でデプロイしている場合、組織の管理アカウントにはデプロイされないのでご注意ください。

StackSets は、管理アカウントが組織内または組織の OU 内にあっても、スタックインスタンスを組織のマスターアカウントにデプロイしません。
管理アカウントへデプロイする場合、セルフマネージド型で管理アカウントを明示的に指定するか個別にCloudFormationをデプロイする必要があります。
Config API
次にConfig APIでのデプロイを確認していきます。
Config API PutOrganizationConfigRuleはAWS CLIやCloudFormationでデプロイすることができます。
AWS CLIで実行する場合のコマンドはこちらです。
(コマンド直打ちだとInputParameters部分でエラーが出てしまうためここではcli-inputの機能を使っています)
aws configservice put-organization-config-rule --cli-input-json file://input.json
# input.jsonの中身
{
  "OrganizationConfigRuleName": "restricted-common-ports",
  "OrganizationManagedRuleMetadata": {
    "Description": "Checks whether security groups that are in use disallow unrestricted incoming TCP traffic to the specified ports.",
    "RuleIdentifier": "RESTRICTED_INCOMING_TRAFFIC",
    "InputParameters": "{\"blockedPort1\":\"20\",\"blockedPort2\":\"21\",\"blockedPort3\":\"3389\",\"blockedPort4\":\"3306\",\"blockedPort5\":\"4333\"}",
    "ResourceTypesScope": [
      "AWS::EC2::SecurityGroup"
    ]
  }
}
put-organization-config-rule — AWS CLI Command Reference
デプロイが完了すると、Configルール上にOrgConfigRule-<OrganizationConfigRuleName>-xxxxxxxxの形式でルールが追加されます。

Config APIでデプロイされたルールは一部操作に制約があります。
見ていただくと分かる通り、Config APIでデプロイされたルールはサービスにリンクされているAWS Configルール(SLR)*1となり、編集機能がグレーアウトになり使えなくなっています。編集/削除する場合には管理アカウントからConfig APIで変更する必要があります。
1 SLRで代表的なものとしてSecurity Hubで展開されるConfigルールがあります。

また、アクションも再評価以外は利用することはできません。
修復の管理を実装したい場合にはCloudFormation StackSetsで展開する必要があります。

デプロイ範囲もCloudFormation StackSetsと違い、Config APIでデプロイする場合は管理アカウントを含めたOrganizations管理下すべてのアカウントにデプロイすることが可能です。(--excluded-accountsで一部アカウントを除外する設定も可能)
Organizationsにアカウントを追加/削除した場合は、自動的にConfig APIでデプロイしているConfigルールが展開/削除されます。
新しいアカウントが組織に参加すると、ルールまたはコンフォーマンスパックはそのアカウントにデプロイされます。アカウントが組織を離脱すると、そのルールまたはコンフォーマンスパックは削除されます。

Config APIは基本CLIベースで操作することになりますが、CloudFormationでデプロイすることも可能です。
Config APIでデプロイしたConfigルールはDescribeOrganizationConfigRulesを使って確認する必要がありますがいちいちCUIで確認するのは、正直メンテナンス性が悪いので、個人的にはCloudFormationを使うのが管理しやすくおすすめです。
今回デプロイした内容をCloudFormationで実装する場合のテンプレートはこちらです。
---
AWSTemplateFormatVersion: 2010-09-09
Resources:
  RestrictedCommonPorts:
    Type: 'AWS::Config::OrganizationConfigRule'
    Properties:
      OrganizationConfigRuleName: 'restricted-common-ports'
      OrganizationManagedRuleMetadata:
        Description: 'Checks whether security groups that are in use disallow unrestricted incoming TCP traffic to the specified ports.'
        RuleIdentifier: 'RESTRICTED_INCOMING_TRAFFIC'
        InputParameters: '{"blockedPort1":"20","blockedPort2":"21","blockedPort3":"3389","blockedPort4":"3306","blockedPort5":"4333"}'
        ResourceTypesScope:
          - 'AWS::EC2::SecurityGroup'
最後に
CloudFormation StackSetsとConfig API PutOrganizationConfigRuleを使って組織にConfigルールを展開する場合の違いをご紹介しました。
ご紹介したとおりConfig APIを使った場合ルールはSLRとなり一部操作に制約が発生します。
逆にSLRとして展開することでメンバーアカウントから削除を防止するといった使い方もできるかと思います。
ただ、SLRでは修復機能が使えなくなるので、一長一短を確認いただき修復機能が必要な場合にはCloudFormation StackSetsでの展開をご検討ください。
以上、たかやま(@nyan_kotaroo)でした。






