🔧 AWS Config コンフォーマンスパック
& StackSets 自動有効化ガイド

マルチアカウント環境で一貫したコンプライアンス管理を実現する

📌 まず結論!3つのポイント

① AWS Config = リソースの健康診断
AWSリソースの設定変更を記録・評価し、ルール違反を自動検出するサービス
② コンフォーマンスパック = 診断項目セット
複数のConfig Rulesをパッケージ化。業界標準やベストプラクティスに沿った設定集
③ StackSets = 全拠点への自動展開
複数アカウント・リージョンにConfigとコンフォーマンスパックを一括デプロイ

🏨 全国ホテルチェーンで例えると超わかりやすい!

全国100店舗のホテルチェーンを経営していると想像してください。
すべての店舗で同じ品質基準を維持するにはどうしますか?

🔍

品質チェックシステム

= AWS Config

各ホテルの状態を常にモニタリング。
「客室の清掃状況」「アメニティの補充」「設備の動作確認」など、すべてを記録・追跡します。

📋

品質基準マニュアル

= コンフォーマンスパック

「5つ星ホテル基準」というマニュアル。
清掃基準、接客基準、セキュリティ基準など、複数のチェック項目をパッケージ化したもの。

📦

全店舗への一括配布システム

= CloudFormation StackSets

本社から全国100店舗に同じマニュアルを自動配布。
新店舗がオープンしても自動的にマニュアルが適用されます。

🏢

本社による統合管理

= AWS Organizations

全店舗を統括する本社。
どの店舗にどのマニュアルを適用するか、一元的に管理・制御できます。

📊 全体アーキテクチャ図

🏢 管理アカウント(本社)
AWS Organizations + StackSets
⬇️ コンフォーマンスパックを一括デプロイ
📁 OU: 本番環境
Production
📁 OU: 開発環境
Development
📁 OU: セキュリティ
Security
⬇️ 各アカウントに自動適用

🚀 導入ステップ(5ステップで完了!)

1

AWS Organizationsを有効化

まずは本社(管理アカウント)でOrganizationsを有効化し、全店舗(メンバーアカウント)を配下に入れます。

管理アカウントでOrganizationsを作成 → OU構造を設計 → メンバーアカウントを招待/作成
2

AWS Configの有効化テンプレートを作成

全アカウントでAWS Configを有効化するCloudFormationテンプレートを作成します。

AWS::Config::ConfigurationRecorder + AWS::Config::DeliveryChannel を定義
3

StackSetsでConfig有効化を全アカウントにデプロイ

Service-Managed権限を使って、全アカウント・全リージョンにConfigを自動有効化します。

StackSets作成 → デプロイ対象OU指定 → 対象リージョン選択 → デプロイ実行
4

コンフォーマンスパックテンプレートを作成

適用したい規則(Config Rules)をまとめたコンフォーマンスパックのYAMLを作成します。

AWSマネージドルール or カスタムルールを選択 → YAMLでパック定義 → S3にアップロード
5

Organization Conformance Packをデプロイ

管理アカウントから組織全体にコンフォーマンスパックを一括デプロイ!

aws configservice put-organization-conformance-pack コマンドで一発デプロイ 🎉

📦 コンフォーマンスパックの種類

🏛️ AWS提供のサンプルパック

  • Operational Best Practices for CIS(CIS Benchmark準拠)
  • Operational Best Practices for HIPAA(医療データ保護)
  • Operational Best Practices for PCI-DSS(クレジットカード業界基準)
  • Operational Best Practices for NIST CSF(サイバーセキュリティフレームワーク)
  • Operational Best Practices for AWS Well-Architected

🔧 カスタムパック(自社要件)

  • S3バケットの暗号化必須ルール
  • EC2にタグ付け必須ルール
  • 特定リージョン以外へのデプロイ禁止
  • RDSのマルチAZ必須ルール
  • セキュリティグループのSSH制限

💻 実装コード例

① Config有効化
② コンフォーマンスパック
③ StackSets作成
④ CLIコマンド
config-enable.yaml(Config有効化テンプレート)
AWSTemplateFormatVersion: '2010-09-09' Description: 'AWS Config有効化テンプレート' Parameters: ConfigBucketName: Type: String Description: 'Config記録用S3バケット名' Resources: # Config記録用のIAMロール ConfigRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: config.amazonaws.com Action: sts:AssumeRole ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWS_ConfigRole - arn:aws:iam::aws:policy/AmazonS3FullAccess # Configuration Recorder(設定記録) ConfigRecorder: Type: AWS::Config::ConfigurationRecorder Properties: Name: default RecordingGroup: AllSupported: true IncludeGlobalResourceTypes: true RoleARN: !GetAtt ConfigRole.Arn # Delivery Channel(配信先) ConfigDeliveryChannel: Type: AWS::Config::DeliveryChannel Properties: S3BucketName: !Ref ConfigBucketName ConfigSnapshotDeliveryProperties: DeliveryFrequency: TwentyFour_Hours
security-conformance-pack.yaml(コンフォーマンスパック定義)
# セキュリティベストプラクティスのコンフォーマンスパック Resources: # S3バケット暗号化チェック S3BucketServerSideEncryptionEnabled: Type: AWS::Config::ConfigRule Properties: ConfigRuleName: s3-bucket-server-side-encryption-enabled Description: 'S3バケットのサーバーサイド暗号化が有効か確認' Source: Owner: AWS SourceIdentifier: S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED # S3パブリックアクセスブロック S3BucketPublicReadProhibited: Type: AWS::Config::ConfigRule Properties: ConfigRuleName: s3-bucket-public-read-prohibited Description: 'S3バケットがパブリック読み取り不可か確認' Source: Owner: AWS SourceIdentifier: S3_BUCKET_PUBLIC_READ_PROHIBITED # RDSの暗号化チェック RdsStorageEncrypted: Type: AWS::Config::ConfigRule Properties: ConfigRuleName: rds-storage-encrypted Description: 'RDSストレージが暗号化されているか確認' Source: Owner: AWS SourceIdentifier: RDS_STORAGE_ENCRYPTED # EC2にIMDSv2を強制 Ec2ImdsV2Check: Type: AWS::Config::ConfigRule Properties: ConfigRuleName: ec2-imdsv2-check Description: 'EC2インスタンスでIMDSv2が有効か確認' Source: Owner: AWS SourceIdentifier: EC2_IMDSV2_CHECK # ルートアカウントのMFA有効化チェック RootAccountMfaEnabled: Type: AWS::Config::ConfigRule Properties: ConfigRuleName: root-account-mfa-enabled Description: 'ルートアカウントでMFAが有効か確認' Source: Owner: AWS SourceIdentifier: ROOT_ACCOUNT_MFA_ENABLED
stacksets-deploy.yaml(StackSetsでのデプロイ設定)
AWSTemplateFormatVersion: '2010-09-09' Description: 'StackSetsを使用したAWS Config自動有効化' Parameters: TargetOUs: Type: CommaDelimitedList Description: 'デプロイ対象のOU ID(カンマ区切り)' Default: 'ou-xxxx-xxxxxxxx,ou-yyyy-yyyyyyyy' TargetRegions: Type: CommaDelimitedList Description: 'デプロイ対象のリージョン' Default: 'ap-northeast-1,us-east-1,eu-west-1' Resources: # Config有効化用StackSet ConfigEnableStackSet: Type: AWS::CloudFormation::StackSet Properties: StackSetName: enable-aws-config-org Description: '組織全体でAWS Configを有効化' # Service-Managed権限を使用(推奨) PermissionModel: SERVICE_MANAGED # 自動デプロイ設定 AutoDeployment: Enabled: true RetainStacksOnAccountRemoval: false # デプロイ対象 StackInstancesGroup: - DeploymentTargets: OrganizationalUnitIds: !Ref TargetOUs Regions: !Ref TargetRegions # 並列デプロイ設定 OperationPreferences: RegionConcurrencyType: PARALLEL MaxConcurrentPercentage: 100 FailureTolerancePercentage: 10 # テンプレート本体 TemplateBody: | AWSTemplateFormatVersion: '2010-09-09' Resources: ConfigRecorder: Type: AWS::Config::ConfigurationRecorder Properties: RecordingGroup: AllSupported: true IncludeGlobalResourceTypes: true RoleARN: !Sub arn:aws:iam::${AWS::AccountId}:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig
deploy-commands.sh(AWS CLIコマンド)
#!/bin/bash # =========================================== # AWS Config & コンフォーマンスパック自動デプロイ # =========================================== # 1. 組織全体でAWS Configを有効化(StackSets使用) aws cloudformation create-stack-set \ --stack-set-name enable-aws-config-org \ --template-body file://config-enable.yaml \ --permission-model SERVICE_MANAGED \ --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false \ --capabilities CAPABILITY_NAMED_IAM # 2. StackInstancesをOU全体にデプロイ aws cloudformation create-stack-instances \ --stack-set-name enable-aws-config-org \ --deployment-targets OrganizationalUnitIds=ou-xxxx-xxxxxxxx \ --regions ap-northeast-1 us-east-1 eu-west-1 \ --operation-preferences RegionConcurrencyType=PARALLEL # 3. コンフォーマンスパックをS3にアップロード aws s3 cp security-conformance-pack.yaml \ s3://my-config-bucket/conformance-packs/ # 4. 組織全体にコンフォーマンスパックをデプロイ aws configservice put-organization-conformance-pack \ --organization-conformance-pack-name security-baseline \ --template-s3-uri s3://my-config-bucket/conformance-packs/security-conformance-pack.yaml \ --excluded-accounts 111111111111 # 除外するアカウント(オプション) # 5. デプロイ状況確認 aws configservice describe-organization-conformance-pack-statuses \ --organization-conformance-pack-names security-baseline # 6. コンプライアンス状況確認 aws configservice get-organization-conformance-pack-detailed-status \ --organization-conformance-pack-name security-baseline

📊 手動設定 vs StackSets自動化 比較

項目 🔧 手動設定 🚀 StackSets自動化
初期設定時間 各アカウント×リージョンごとに設定
(10アカウント×3リージョン = 30回の作業)
1回のデプロイで完了
新規アカウント追加時 毎回手動でConfig有効化が必要 自動的に適用される
設定の一貫性 ヒューマンエラーのリスクあり 100%統一された設定
ルール変更時 全アカウントを個別に更新 1回の更新で全アカウントに反映
監査対応 各アカウントの設定を個別に確認 一元的なコンプライアンスレポート
運用コスト 高(継続的な管理工数) 低(初期設定のみ)

🎯 よくあるユースケース

🏦 金融機関のコンプライアンス

PCI-DSSやSOC2準拠のためのセキュリティ基準を全アカウントに自動適用

例:全S3バケットの暗号化、アクセスログ有効化、パブリックアクセス禁止を強制

🏥 医療機関のデータ保護

HIPAA準拠のためのデータ保護ルールを統一的に適用

例:RDSの暗号化必須、CloudTrail有効化、VPCフローログ必須

🏢 エンタープライズのガバナンス

社内セキュリティポリシーを全部門のAWSアカウントに自動展開

例:タグ付けポリシー、特定リージョン制限、IAMパスワードポリシー

🚀 スタートアップのスケール対応

新サービス立ち上げ時に自動でセキュリティベースラインを適用

例:新アカウント作成時に自動でWell-Architectedベストプラクティスを適用

✨ ベストプラクティス

📁 OU単位でパックを分ける

本番環境には厳格なルール、開発環境には緩やかなルールなど、用途に応じてコンフォーマンスパックを使い分けましょう。

🔄 段階的にロールアウト

まずはサンドボックスOUでテストし、問題なければ本番OUに展開。いきなり全アカウントへのデプロイは避けましょう。

📊 集約アカウントで監視

Security HubやConfig Aggregatorを使って、全アカウントのコンプライアンス状況を一元監視しましょう。

🔧 自動修復を検討

違反が検出されたら自動で修復するSSM Automationを組み合わせると、より強固なガバナンスが実現できます。

⚠️ 注意点・落とし穴

  • Config有効化が前提: コンフォーマンスパックを適用する前に、各アカウントでAWS Configが有効化されている必要があります
  • コスト発生: Config Rulesの数に応じて料金が発生。大量のルールを適用する前にコスト試算を行いましょう
  • リージョン制限: グローバルリソース(IAM等)の記録は1リージョンのみで有効化。重複記録を避けましょう
  • 除外アカウントの管理: 管理アカウント自体や特殊な用途のアカウントは除外設定が必要な場合があります
  • StackSetsの権限: Service-Managed権限を使う場合、事前に信頼されたアクセスを有効化する必要があります

❓ よくある質問(FAQ)

Q. 既存のConfig Rulesとコンフォーマンスパックは共存できる?
はい、共存可能です。ただし、同じルールが重複すると評価も重複するため、既存ルールとの重複がないか確認することをお勧めします。
Q. コンフォーマンスパックの更新はどうやる?
put-organization-conformance-pack コマンドを同じ名前で再実行すると、既存のパックが更新されます。StackSetsを使っている場合は、StackSetの更新で一括反映されます。
Q. 特定のアカウントだけ除外したい場合は?
put-organization-conformance-pack の --excluded-accounts オプションで除外するアカウントIDを指定できます。StackSetsでもOU単位やアカウント単位での除外が可能です。
Q. カスタムルール(Lambda関数)も使える?
はい、カスタムConfig RulesをLambda関数で定義し、コンフォーマンスパックに含めることができます。Lambda関数は各アカウントにデプロイする必要があるため、こちらもStackSetsで展開すると効率的です。
Q. コンプライアンス違反が検出されたら通知は来る?
デフォルトでは通知は来ません。EventBridgeでConfig Rulesのコンプライアンス変更イベントをキャッチし、SNSやSlackに通知する仕組みを別途構築する必要があります。Security Hubを使うとより簡単に一元監視できます。

🎉 まとめ

🔍

AWS Config

リソースの設定変更を記録・評価
ルール違反を自動検出

📦

コンフォーマンスパック

複数ルールをパッケージ化
業界標準への準拠を簡単に

🚀

StackSets

全アカウント・リージョンに一括デプロイ
新規アカウントにも自動適用

🏨 ホテルチェーンのように考えよう!
全店舗(アカウント)に同じ品質基準(コンフォーマンスパック)を
本社(管理アカウント)から一括配布(StackSets)すれば、
一貫したコンプライアンスが実現できます!

Created by SSuzuki1063

AWS SAP Learning Resources