1．はじめに

SHIFTのナショナルセキュリティ事業部所属の松尾です。

AWS Control Tower シリーズ（下記リンク）でブログを連載していますが、並走してAWSのアップデート情報を記載していこうと思います。アップデート情報の掲載内容は、私の業務メインのITガバナンスに合わせます。

"AWS Control Tower シリーズ"

AWSアップデート情報（2024年11月20日）によると、AWS Control Towerのガードレール機能の1つである、プロアクティブコントロール用のAWS CloudFormation Hooks（以下、「CFn Hooks」）管理を改善したとのことです。どうやら、アップデート前はAWS Control Tower環境下では、AWS利用者が独自カスタマイズしたCFn Hooks（以下、CFn Hooks（拡張機能）を作成できず、AWS Control Towerのガードレール（プロアクティブコントロール）と併用不可であったようです。

今回、アップデート後の検証のため、AWS Control Tower環境下でのCFn Hooksの拡張機能の作成エラーは発生しませんが、AWS Control Towerのガードレール機能（プロアクティブコントロール）共存できるところまで見ようと思います。

2．AWS CloudFormation Hooksとは

AWS CloudFormationはInfrastructure As Code（IaC）サービスであることはご存知の方もいると思いますが、CFn Hooksはどのようなサービスか知っていますでしょうか。私はAWS Control Towerのガードレール機能（プロアクティブコントロール）が実装されてから知りました。CFn HooksについてAWS社の説明は下記リンクとなりますが、日本語は未実装なため、遊び心でGPT-4oに和訳してもらいました（筆者の英語力は内緒）。

"What is AWS CloudFormation Hooks?（AWS）"

要約すると、AWSリソースのプロビジョニング前にリソース構成の準拠性のチェック機能をもつサービスとなります。CFn Hooksについては、以前、"ガードレールの設計（AWS Control Tower シリーズ vol.2）" で、AWS Control Towerのガードレール機能（プロアクティブコントロール）の中で解説しています。つまり、本ブログタイトルのアップデート前は、AWS Control Tower環境下では、AWS Control TowerのCFn Hooks（=ガードレール機能（プロアクティブコントロール））のみ管理可能とし、AWS CloudFormation側でのCFn Hooks（拡張機能）を管理不可とすることで、CFn Hooksの設定をAWS Control Tower側で一元管理して統制をかけていたことになります。今回この制約が緩和され、両方のCFn Hooksが併用可能となったわけです。

3．AWS Control Tower環境下でのAWS CloudFormation Hooks（拡張機能）作成

それでは、AWS control Tower環境下でCFn Hooks（拡張機能）が作成可能か検証してみようと思います。今回はCFn Hooks（拡張機能）をAWS Control Towerのマスタアカウントで作成します。

今回は、AWS CloudFormationのレジストリ＞パブリック拡張機能より、任意サンプル（AWSSamples::Ec2SsmSmOnly::Hooks）からCFn Hooks（拡張機能）を作成することにします。

アクティブ化を押下します。

実行ロール（IAMロール）のARNを指定します（※IAMロールにアタッチするIAMポリシーは検証の便宜上「AdministratorAccess」を設定）。その他のログ記録設定（CloudWatch Log）-オプション等の設定項目を任意で指定し、拡張機能のアクティブ化を押下します。

【実行ロール（IAMロール）の信頼ポリシー（サンプルコード）】

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "hooks.cloudformation.amazonaws.com",
                    "resources.cloudformation.amazonaws.com"
                ]
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "123456789012"
                }
            }
        }
    ]
}

【ログ記録設定（CloudWatch Log）（サンプルコード）】

{
  "logRoleArn": "arn:aws:iam::123456789012:role/CFnHookSampleRole",
  "logGroupName": "LogGroupCFnHookSampleRole"
}

設定エイリアスを「default」とし、設定JSONを指定します。設定JSON内のProperties要素は、設定スキーマ（今回は「AWSSamples::Ec2SsmSmOnly::Hooks」）によって変わります。設定JSON内の各パラメータの解説は以下を参照ください。
"Hook configuration schema syntax reference（左ペイン：Configuration schema）（AWS）"

【設定JSON（設定スキーマ：AWSSamples::Ec2SsmSmOnly::Hooks）（サンプルコード）】

{
  "CloudFormationConfiguration": {
    "HookConfiguration": {
      "TargetStacks": "ALL",
      "FailureMode": "FAIL",
      "Properties": {
        "requireSessionManagerEncryption":"true"
      }
    }
  }
}

AWS Control Tower環境下で、エラーすることなく、CFn Hooks（拡張機能）が作成することができました（おそらく、これでアップデート情報が反映されているとみてよいはず...）。なお、作成したCFn Hooks（拡張機能）は、AWS Control Tower側のコントロール（ガードレール）一覧にはプロアクティブコントロールとして表示されないため、AWS CloudFormation側で管理する必要があります。

4．考察（マネージド機能とカスタマイズ機能の併用）

CFn Hooksに限らず、IAMロールなど、AWS側で一部機能がマネージド管理されるものは多くあります。技術面では基本的にマネージド機能を利用し、マネージド機能で実現不可なものは、AWS利用者が独自でカスタマイズ機能を作成することになります。一方で、運用面で見たときにカスタマイズ機能が増えるにつれて独自ソースの管理の煩雑化などで運用オーバーヘッドがかかり、後任者に独自ソースの構成管理がしっかり引き継がれず、運用が回らなくなるリスクがあります。

私は過去のシステム開発・運用経験を通して、上記課題にあたった際は、そもそもシステムが組織の業務効率化のためにあるということに立ち戻るようにしています。組織とシステム間の整理の流れとしては以下のとおりです。

お問合せはお気軽に

SHIFTについて（コーポレートサイト）

SHIFTのサービスについて（サービスサイト）

SHIFTの導入事例

お役立ち資料はこちら

SHIFTの採用情報はこちら

PHOTO：UnsplashのClark Van Der Beken