【AWS】CloudTrail証跡を必ず有効にする方法

目的

CloudTrailの証跡機能が無効になったことを検知して、自動で再有効化させる。
（証跡が有効な状態を自動で担保する）

結論

AWS ConfigのルールとAWS SystemsManagerのAutomationを連携させ、自動で再有効化することが可能です。

AWSアカウントがAWS Organizationsを使用している場合はSCP（サービスコントロールポリシー）での制御を設定すれば、そもそも証跡を無効にすること自体を拒否できます。

本記事作成後にサービス内容や仕様が変更になる可能性があります。実際に設定する際には、公式ドキュメントをご確認のうえ自己責任でお願いします。

前提

• CloudTrailの証跡が正しく設定され、機能していること。
• CloudTrail、SystemsManeger、S3、IAMロールへの操作権限を持ったIAMユーザーで作業出来ること。

CloudTrailについて

CloudTrailは、AWSアカウント上での全ての操作を記録・監視するサービスです。
セキュリティの向上、コンプライアンス順守、監査対応、トラブルシューティングなどの目的で使用されます。
特に本番環境では必須で設定すべきサービスといっていいでしょう。

Configでルールを作成

AWSのマネージドルール「cloudtrail-enabled」（証跡が有効になっているかを確認するルール）が用意されていますので、そちらを使用します。

Configのセットアップから設定していきます。
今回はCloudTrailの情報を取得したいので、「特定のリソースタイプ」を選択し、リソースタイプでCloudTrailを選択します。
情報は常に取得したいため、頻度を「連続」にします。

ログを出力するS3バケット名などを指定したら「次へ」進みます。

ルールについては、前述のとおり今回はAWSのマネージドルール「cloudtrail-enabled」を使用しますので、検索窓から検索してチェックを入れます。

設定が完了したら、レビューページで間違いがないか確認します。
無事作成できましたら、Configのダッシュボードを確認してみましょう。
今回私の方では、検証として証跡を無効にしていたためその情報が収集され「非準拠」として表示されています。

Systems Manager Automation で自動修復

続いて、非準拠状態となった際に実行される修復アクションを設定していまきます。
こちらも既にAWSで用意されているドキュメント「AWS-ConfigureCloudTrailLogging」を使用していきます。

作成したConfigルールを選択し、アクションから「修復の管理」を選択します。

自動修正を選択し、修復アクションから「AWS-ConfigureCloudTrailLogging」を検索します。
修復の再試行回数や秒数の設定は必須なので、適宜設定してください。

パラメーターを入力します。
「CloudTrailArn」は自動修復対象のCloudTrail証跡のArnを設定します。
証跡のArnは「arn:aws:cloudtrail:<リージョン名>: :trail/<証跡名>」です。
「AutomationAssumeRole」はCloudTrail証跡を有効にする操作の許可権限を持ったIAM RoleのArnを指定します。

無事修復アクションが作成されたら、ルールページの下にある「対象範囲内のリソース」で検出されているリソースを確認します。
が、ここでステータスが「アクションの実行失敗」となってしまいました。

CloudTrailのイベント履歴から操作ログを確認してみると、イベント名「StartAutomationExecution」としてJSON形式でイベントが記録されています。
全て転記すると長いので、エラー原因特定となる重要な箇所を一部抜粋します。

"userIdentity": {
        "type": "AssumedRole",
        "principalId": "AROA2RQNPUT4ULT5Q2WDV:AwsConfigRemediation",
        "arn": "arn:aws:sts::<AWSアカウント>:assumed-role/AWSServiceRoleForConfigRemediation/AwsConfigRemediation",
        
"eventSource": "ssm.amazonaws.com",
"eventName": "StartAutomationExecution",
"awsRegion": "ap-northeast-1",
"sourceIPAddress": "config.amazonaws.com",
"userAgent": "config.amazonaws.com",
"errorCode": "InvalidAutomationExecutionParametersException",
"errorMessage": "The defined assume role is unable to be assumed.",

Automationの実行にあたり、AssumeRoleに失敗しているのだろうということが分かります。
結論としては、先ほど修復アクションの設定で指定した「AutomationAssumeRole」の設定で信頼関係の指定方法に誤りがありました。

Configから呼ぶ設定だからと思い込み「config.amazonaws.com」をプリンシパルに指定していたのですが、正確には実行される修復アクションはSystemsManegerから呼び出されるため、「ssm.amazonaws.com」を指定する必要がありました。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "ssm.amazonaws.com"
                ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

CloudTrailのイベント履歴でも、イベントソースが「ssm.amazonaws.com」になっていることを確認できます。

設定が成功すればAutomationが実行され、ダッシュボードでリソースが準拠状態になることを確認できます。

補足：通知を受けたい場合

証跡が無効化された時は「StopLogging」というイベントが発生しますので、CloudTrailとCloudWatchLogsと連携してアラームの設定や通知を受けることも可能です。
またConfigで検知した設定の変更および通知に関する詳細情報を、Amazon CloudWatch Events に送信することも可能です。

OrganizationsのSCPで制御する

SCPでの制御方法としては、アカウントで証跡の無効化アクションを拒否するかたちになります。

Organizationのポリシーからポリシーを作成します。

Organizationの管理アカウントでSCPの操作権限を持つIAMユーザーが必要です。

設定するポリシーは以下の通りです。
証跡の出力停止操作を拒否します。
制御対象の証跡を絞り込みたい場合など、その他条件がある場合は適宜追加します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging"
      ],
      "Resource": "*"
    }
  ]
}

ポリシーを作成したら、適用したいOUにポリシーをアタッチします。
管理しているアカウント全体に適用したい場合は、rootにアタッチしてください。

SCPによる制御を開始してから証跡を無効にしようとすると、権限エラーで操作できなくなったことが分かります。

こちらは証跡の無効のみ拒否するため、証跡を作成して開始することは可能となります。
その他制御したい操作がある場合は、ポリシーに追加していくことで実現可能です。

最後に

ConfigのルールとSystems Manager Automationを組み合わせる方法の場合、無効化から再有効化まで多少のブランクが発生しますので注意が必要です。
そもそもIAMでCloudTrailへのアクセスを制限するなど、AWSでは様々な権限コントロールの方法が用意されています。
その分どの手法を選択すべきか、十分に検討する必要があります。

なお、CloudTrailログの整合性検証方法についても記事を投稿していますので、併せてご参考にされてください。
こちらの記事に、整合性検証によって証跡が記録されなかった期間を確認する方法が記載されています。