security
A
信頼度ランク
| S | 公式ソース確認済み |
| A | 成功実績多数・失敗例少数 |
| B | 賛否両論 |
| C | 動作未確認・セキュリティリスク高 |
| Z | 個人所感 |
AWS Config Rules — コンプライアンス評価と自動修復
AWS Configのマネージドルール vs カスタムルール、設定変更トリガー vs 定期評価、Systems Manager Automationによる自動修復、コンフォーマンスパック、マルチアカウント集約を解説。
一言結論
AWS Configの真価は違反検出だけでなくSystems Manager Automationとの連携による自動修復にあり、コンフォーマンスパックをOrganizations全体に展開することで組織横断の継続的コンプライアンスを実現できる。
AWS Config の概要
AWS Configはリソースの設定変更を継続的に記録し、ルールへの準拠状況を評価するサービスだ。「いつ・誰が・何を変更したか」の履歴管理と、設定違反の検出を担う。
AWS Config の役割:
→ リソースの設定履歴を記録(Configuration Timeline)
→ ルールへの準拠状況を継続的に評価
→ 違反検出時に通知・自動修復
→ マルチアカウントの設定状況を集約
CloudTrailとの違い:
CloudTrail: 「誰が何の操作をしたか」(API操作ログ)
Config: 「リソースの設定がどう変わったか」(設定変更履歴)
マネージドルール vs カスタムルール
マネージドルール(AWS提供):
→ 140以上の定義済みルール
→ すぐに使える(設定値だけ調整)
代表的なマネージドルール:
s3-bucket-public-read-prohibited: S3パブリック読み取り禁止チェック
iam-root-access-key-check: rootアクセスキーの未使用チェック
vpc-flow-logs-enabled: VPCフローログの有効化チェック
encrypted-volumes: EBSボリュームの暗号化チェック
mfa-enabled-for-iam-console-access: IAMユーザーのMFA有効チェック
root-account-mfa-enabled: rootアカウントのMFA有効チェック
カスタムルール(Lambda):
→ 組織固有のルールをLambdaで実装
→ 複雑な判定ロジックを実装可能
カスタムルールの実装
import json
import boto3
config = boto3.client('config')
def evaluate_compliance(configuration_item, rule_parameters):
"""
カスタムコンプライアンス評価ロジック
例: EC2インスタンスが特定のタグを持つかチェック
"""
required_tags = ['Environment', 'Owner', 'CostCenter']
if configuration_item['resourceType'] != 'AWS::EC2::Instance':
return 'NOT_APPLICABLE'
tags = configuration_item.get('tags', {})
for required_tag in required_tags:
if required_tag not in tags:
return 'NON_COMPLIANT'
return 'COMPLIANT'
def lambda_handler(event, context):
invoking_event = json.loads(event['invokingEvent'])
configuration_item = invoking_event.get('configurationItem')
if not configuration_item:
return
compliance = evaluate_compliance(
configuration_item,
json.loads(event.get('ruleParameters', '{}'))
)
config.put_evaluations(
Evaluations=[{
'ComplianceResourceType': configuration_item['resourceType'],
'ComplianceResourceId': configuration_item['resourceId'],
'ComplianceType': compliance,
'OrderingTimestamp': configuration_item['configurationItemCaptureTime']
}],
ResultToken=event['resultToken']
)
トリガータイプ
設定変更トリガー(Configuration Change):
→ リソースの設定が変更された時に評価
→ 即時に違反を検出
→ 例: SG のインバウンドルール変更時に評価
定期評価トリガー(Periodic):
→ 指定した時間間隔で評価(1/3/6/12/24時間)
→ 設定変更が記録されない違反(時間経過で変わるもの)に向く
→ 例: 証明書の有効期限チェック(毎日評価)
# マネージドルールの設定(設定変更トリガー)
aws configservice put-config-rule \
--config-rule '{
"ConfigRuleName": "s3-bucket-public-read-prohibited",
"Source": {
"Owner": "AWS",
"SourceIdentifier": "S3_BUCKET_PUBLIC_READ_PROHIBITED"
},
"Scope": {
"ComplianceResourceTypes": ["AWS::S3::Bucket"]
}
}'
自動修復(Remediation)
# Systems Manager Automationによる自動修復設定
aws configservice put-remediation-configurations \
--remediation-configurations '[{
"ConfigRuleName": "s3-bucket-public-read-prohibited",
"TargetType": "SSM_DOCUMENT",
"TargetId": "AWS-DisableS3BucketPublicReadWrite",
"Parameters": {
"AutomationAssumeRole": {
"StaticValue": {
"Values": ["arn:aws:iam::123456789012:role/ConfigRemediationRole"]
}
},
"S3BucketName": {
"ResourceValue": {
"Value": "RESOURCE_ID"
}
}
},
"Automatic": true,
"MaximumAutomaticAttempts": 3,
"RetryAttemptSeconds": 60
}]'
コンフォーマンスパック
複数のConfigルールをまとめてパッケージ化し、Organizationsで展開する。
# コンフォーマンスパックのデプロイ
aws configservice put-conformance-pack \
--conformance-pack-name "security-baseline" \
--template-s3-uri s3://my-config-bucket/security-baseline.yaml
# Organizationsレベルでの展開
aws configservice put-organization-conformance-pack \
--organization-conformance-pack-name "org-security-baseline" \
--template-s3-uri s3://my-config-bucket/security-baseline.yaml \
--excluded-accounts "111111111111"
試験頻出ポイント
| シナリオ | 回答 |
|---|---|
| リソース設定変更の即時検出 | Config Rules(設定変更トリガー) |
| 証明書の有効期限チェック | Config Rules(定期評価トリガー) |
| 違反リソースの自動修復 | Config Remediation + SSM Automation |
| 組織全体にConfigルールを展開 | コンフォーマンスパック + Organizations |
| Configのリソース変更履歴確認 | Configuration Timeline |
まとめ
AWS Configはリソースの設定変更を継続的に監視し、ルール違反を検出する。マネージドルールで一般的なセキュリティ要件をカバーし、カスタムルールで組織固有の要件を実装する。自動修復機能でコンプライアンス維持を自動化できる。