[アップデート]AWS Control Towerに223件のConfigルールが追加されました

AWS Control Towerに223件のConfigルールが追加されました
#AWS
#AWS Control Tower
#AWS Config
とーち
2025.04.14
お疲れさまです。とーちです。
AWS Control Tower に223件の新しい AWS Config ルールが追加されたというアップデートがあったので、どんな Config ルールが追加されたのかを調べてみました。
https://aws.amazon.com/about-aws/whats-new/2025/04/new-aws-config-rules-control-tower
とはいっても、以前に AWS Control Tower でどのようなコントロールが実装されていたかを調べるのは困難です。ちょうど以下のブログ記事で2024年8月13日時点のコントロールの一覧が公開されていたので、2024年8月13日時点と2025年4月14日現在の差分という形で調べてみました。
https://dev.classmethod.jp/articles/get-all-ct-controls-via-aws-cli/
なお、こちらの公式ドキュメントを見る限り、現在 AWS Control Tower がサポートしている AWS Config ルールの一覧を見るには AWS Management Console の AWS Control Tower の画面から確認するのが一番手っ取り早そうです。
 さらっと紹介されているもう一つのアップデート上記のWhat's NewではAWS Config ルールの追加が前面に出ていますが、実はもう一つのアップデートについても触れられています。AWS ControlTowerに関連したAPIとしてAWS Control Catalogというものがあるのですが、この中の ListControls と GetControl が更新され以下の３つのフィールドが追加されています。AWS Management Console の AWS Control Tower の画面上では従来からあったフィールドですが、それが、AWS Control Catalog APIにも拡充された形です。
Severity：重大度
Implementation：実装タイプとコントロールID、実装タイプは例えば AWS::Config::ConfigRule 等になります。コントロールIDはコントロールを実装したサービスによって割り当てられた、コントロールのサービス固有の識別子なので、例えばAWS Config ルール ID や Security Hub コントロール IDとなります。
CreateTime：AWS のガバナンス機能としてコントロールがリリースされた時刻とのことです。私が確認した限りでは対象のコントロールがControlTowerに実装された日時ではなく、コントロールを実装したサービス（例えばAWS Configとか）側での実装日時のように見えます。
AWS CLIでは v2.25.14 からサポートされています。
https://github.com/aws/aws-cli/blob/v2/CHANGELOG.rst
具体的なレスポンス内容については以下の公式ドキュメントをご参照ください。
GetControl - AWS Control Catalog
ListControls - AWS Control Catalog
 追加されたConfigルールの一覧AWS Control Tower のコントロールとして新たに追加された Config ルールは以下となります。上記の What's New では223件となっていますが、下記の結果では231件になっていますので、厳密に正確な調査ではない点には予めご注意ください。
https://gist.github.com/ice1203/22c4cf9c77fb690bd9bd6aac82377f15
 追加されたConfigルールの重要度別内訳追加された Config ルールの重要度別内訳は以下のとおりとなっています。


重要度
コントロール数


CRITICAL
7

HIGH
55

MEDIUM
126

LOW
43

 重要度CRITICALのコントロール詳細それでは、重要度が CRITICAL のコントロールに絞って内容を見ていきましょう。CRITICAL のコントロールとしては以下の7つとなります。
 1. KMSキーポリシーのパブリックアクセス確認Checks if the AWS KMS key policy allows public access
このルールは、KMS キーポリシーがパブリックアクセスを許可しているかどうかを確認します。こちらの Security Hub コントロールと同様のチェックと思われますが、通常ワイルドカードで KMS キーポリシーを公開したいというケースはないと思います。
 2. KMSキーの削除スケジュール確認Checks if AWS Key Management Service (AWS KMS) keys are not scheduled for deletion in AWS KMS
このルールは、AWS KMS キーが削除予定になっていないかどうかを確認します。個人的には検証環境等では KMS キーの作り直しは多々発生する（その際に KMS キーを削除する）と思うので、有効化する場合は、本番環境を配置した OU でのみ有効化するといった工夫が必要かもしれません。
 3. CloudTrailログのS3バケットのパブリックアクセス設定確認Checks if the S3 bucket configurations for your AWS CloudTrail logs block public access
このルールは、AWS CloudTrail ログで使用する S3 バケットのパブリックアクセスブロック設定が有効かを確認します。CloudTrail の少なくとも1つの S3 バケットがパブリックアクセス可能である場合にルール違反となります。CloudTrail ログを外部に公開するのは避けたいのでこれは有効化しておいても良いかもしれません。
 4. EMRのブロックパブリックアクセス設定確認Checks if an account with Amazon EMR has block public access settings enabled
このルールは、EMR のブロックパブリックアクセス設定が有効かどうかを確認します。私はあまり EMR を使わないのでパブリックアクセスしたいケースがいまいち想像できないのですが、ブロックパブリックアクセスがデフォルトで有効となっていることからもパブリックアクセスが必要なのは特殊なケースでしょう。AWS Control Tower 配下のアカウントで EMR を使うケースがあれば有効化すると良いのではないかと思います。
 5. S3アクセスポイントのVPC制限確認Checks if an Amazon S3 access point does not allow access from the internet (NetworkOrigin is VPC)
このルールは、S3 アクセスポイントがインターネットからのアクセスを許可していないかどうかを確認します。S3 アクセスポイントにはネットワークオリジンという設定があり、これが VPC ではなくインターネットに指定されている場合はインターネットから対象 S3 アクセスポイントに対してアクセスが可能になります。S3 バケットのブロックパブリックアクセスと同様に S3 アクセスポイントも特別な事情がなければパブリックなアクセスは禁止すべきです。
 6. Client VPN認可ルールの確認Checks if the AWS Client VPN authorization rules authorizes connection access for all clients
このルールは、AWS Client VPN 認可ルールがすべてのクライアントからの接続アクセスを認可している場合にルール違反となります。AWS Client VPN 認可ルールは Client VPN を介してアクセスできるネットワーク、およびユーザーを制御するためのルールです。
 7. Amazon MQブローカーのパブリックアクセス確認Checks if Amazon MQ brokers are not publicly accessible
このルールは、Amazon MQ ブローカーがパブリックアクセス可能かどうかを確認します。Amazon MQ ブローカーの「PubliclyAccessible」フィールドが true の場合にルール違反となります。Amazon MQ ではブローカーに対してリクエストすることでキューイングできます。ブローカーをパブリックにするということは認証さえ通せばインターネットのどこからでもキューイングできるということになるので検証目的でなければ PubliclyAccessible は false とするのが望ましいです。
 補足上記の csv ですが、以下のシェルスクリプトで作成しています。せっかくなので載せておきます。
ct_export.sh#!/bin/bash

# 設定
EXISTING_CSV="controls.txt"  # 既存のコントロールリストCSV
OUTPUT_FILE="new_config_rule_controls.csv"  # 出力ファイル
LOG_FILE="script_log.txt"  # ログファイル
JSON_TEMP="controls_temp.json"  # 一時JSONファイル
TMP_OUTPUT="tmp_output.csv"  # 一時出力ファイル

# ログファイルを初期化
> "$LOG_FILE"

log() {
    echo "$(date '+%Y-%m-%d %H:%M:%S') - $1" | tee -a "$LOG_FILE"
}

log "スクリプト開始"

# 既存CSVからコントロール名を抽出（ヘッダー行をスキップ）
log "既存のコントロールリストを抽出中..."
if [ ! -f "$EXISTING_CSV" ]; then
    log "エラー: 既存コントロールリストファイル $EXISTING_CSV が見つかりません"
    exit 1
fi

EXISTING_CONTROLS=$(tail -n +2 "$EXISTING_CSV" | cut -d ',' -f 1 | sed 's/"//g')

# 既存コントロール数を確認
EXISTING_COUNT=$(echo "$EXISTING_CONTROLS" | wc -l)
log "既存コントロール数: $EXISTING_COUNT"

# 最新のコントロールリストを取得
log "最新のコントロールリストを取得中..."

# AWS CLI認証を確認
aws sts get-caller-identity > /dev/null 2>&1
if [ $? -ne 0 ]; then
    log "エラー: AWS認証に失敗しました。AWS認証情報を確認してください。"
    exit 1
fi

# 最新のコントロールリストをJSON形式で取得して一時ファイルに保存
log "AWS Control Tower コントロールを取得中..."
aws controlcatalog list-controls --output json > "$JSON_TEMP"
if [ $? -ne 0 ] || [ ! -s "$JSON_TEMP" ]; then
    log "エラー: コントロールリストの取得に失敗しました。"
    exit 1
fi

# JSONファイルの構造を確認
if ! jq -e '.Controls' "$JSON_TEMP" > /dev/null 2>&1; then
    log "エラー: JSONデータの形式が予期しないものです。Controls配列が見つかりません。"
    log "JSONデータの最初の部分:"
    head -n 20 "$JSON_TEMP" >> "$LOG_FILE"
    exit 1
fi

# 出力CSVのヘッダーを作成
echo "\"Name\",\"Behavior\",\"Severity\",\"Implementation Type\",\"Implementation ID\",\"Description\",\"CreateTime\"" > "$OUTPUT_FILE"
> "$TMP_OUTPUT"

log "コントロール情報を処理中..."

# JSONファイルを処理して新規コントロールを抽出
jq -r '.Controls[] | select(.Implementation.Type == "AWS::Config::ConfigRule") | [.Name, .Behavior, .Severity, .Implementation.Type, .Implementation.Identifier, .Description, .CreateTime] | @csv' "$JSON_TEMP" > "$TMP_OUTPUT"

# 新規コントロールをカウント
NEW_CONTROLS=0

# 一時ファイルから新規コントロールを抽出して出力ファイルに追加
while IFS=, read -r name behavior severity impl_type impl_id description create_time; do
    # ダブルクォートを削除
    name=$(echo "$name" | sed 's/^"//;s/"$//')
    
    # 既存のコントロールリストに存在するか確認
    if ! echo "$EXISTING_CONTROLS" | grep -q "^$name$"; then
        # 新規コントロールとして追加
        echo "$name,$behavior,$severity,$impl_type,$impl_id,$description,$create_time" >> "$OUTPUT_FILE"
        log "新規コントロール検出: $name ($impl_id)"
        NEW_CONTROLS=$((NEW_CONTROLS + 1))
    fi
done < "$TMP_OUTPUT"

# 結果を表示
log "処理が完了しました。"
log "新規の AWS::Config::ConfigRule コントロール数: $NEW_CONTROLS"
log "結果は $OUTPUT_FILE に保存されました。"

# 出力ファイルの内容を確認
if [ $NEW_CONTROLS -gt 0 ]; then
    log "検出された新規コントロール:"
    tail -n +2 "$OUTPUT_FILE" | cut -d ',' -f 1,2,3,5 | while read -r line; do
        log "  $line"
    done
else
    log "新規コントロールは検出されませんでした。"
fi

# 一時ファイルの削除
rm -f "$JSON_TEMP" "$TMP_OUTPUT"

log "スクリプト終了"
 まとめ以上、簡単でしたが、AWS Control Tower に223件の Config ルールが追加されたというアップデートの紹介でした。AWS Config ルールが大量に追加されたことで、AWS Control Tower でカバーできるガバナンス範囲も増えたのではないでしょうか？
ぜひどんなルールがあるかを改めて確認頂き、組織の統制に有用そうなルールがないかをチェックして頂ければと思います。
以上、とーちでした。