CloudTrail イベントに”errorMessage”: “CallerValidation check failed”と記録されたときに気にすること

AWS の API によっては実行できるアカウント種別が限定されているものがあります。それらは条件を満たしていないと検証で弾かれるようです。

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

CallerValidation check failed?

コンバンハ、千葉(幸)です。

CloudTrail イベントに以下のようなエラーが記録されたことがありました。(イベントの中身は大幅に削っています。)

{
    "eventVersion": "1.08",
    "eventTime": "2022-10-25T06:39:45Z",
    "eventSource": "organizations.amazonaws.com",
    "eventName": "ListAccounts",
    "awsRegion": "us-east-1",
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36",
    "errorCode": "AccessDenied",
    "errorMessage": "CallerValidation check failed",
    "requestParameters": null,
    "responseElements": null,
    "readOnly": true,
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "eventCategory": "Management",
    "tlsDetails": {
        "tlsVersion": "TLSv1.2",
        "cipherSuite": "ECDHE-RSA-AES128-GCM-SHA256",
        "clientProvidedHostHeader": "organizations.us-east-1.amazonaws.com"
    },
    "sessionCredentialFromConsole": "true"
}

"errorCode": "AccessDenied"はよく見る気がしますが、"errorMessage": "CallerValidation check failed"というのは見慣れない気がします。

イベントに記録されていた IAM ユーザーはかなり強い権限を有していたので、権限不足によるエラーでもない気がします。

どういった時に記録されるものなのか確認してみました。

まとめ

  • Organizations のオペレーションの中には、マネジメントアカウントもしくは委任された管理者アカウントからしか実行できないものがある
  • 通常のメンバーアカウントから当該オペレーションを実行すると"errorMessage": "CallerValidation check failed"が記録される
  • Organizations と統合可能な AWS サービスのコンソールを操作していると意図せず Organizations 関連のオペレーションが実行されていることがある

ひとまず今回の結論としてはこんなところです。他の要因で"errorMessage": "CallerValidation check failed"が記録される可能性もありますが、公式情報は見つけられませんでした。

Organizations オペレーションを実行してみる

ひとまずイベントに記録されていた Organizations オペレーションListAccountsを明示的に実行してみます。なお、実行する AWS アカウントは Organizations のメンバーアカウントです。

% aws organizations list-accounts

An error occurred (AccessDeniedException) when calling the ListAccounts operation: You don't have permissions to access this resource.

↑ エラーが発生しました。実行したユーザーにはAdministratorAccessがアタッチされているので、IAM での権限不足ということはなさそうです。

記録された CloudTrail イベントを確認すると冒頭で載せたイベントと同様に"errorMessage": "CallerValidation check failed"が記録されていました。

...
    "eventTime": "2022-11-26T07:22:13Z",
    "eventSource": "organizations.amazonaws.com",
    "eventName": "ListAccounts",
    "awsRegion": "us-east-1",
    "userAgent": "aws-cli/2.9.1 Python/3.9.11 Darwin/22.1.0 exe/x86_64 prompt/off command/organizations.list-accounts",
    "errorCode": "AccessDenied",
    "errorMessage": "CallerValidation check failed",
    "requestParameters": null,
    "responseElements": null,
...

なお Organizations の CloudTrail イベントは us-east-1 リージョンにのみ記録されますので、コンソールで確認する際にはリージョンを意識してください。

AWS Organizations の CloudTrail に関するすべての情報は、米国東部 (バージニア北部) リージョンのみで表示できます。CloudTrail コンソールで AWS Organizations アクティビティが表示されない場合は、右上隅のメニューを使用して、コンソールを 米国東部 (バージニア北部) に設定します。

Organizations API を実行できるアカウント

今回実行した API ListAccountsのリファレンスを確認してみると以下の文言があります。

This operation can be called only from the organization's management account or by a member account that is a delegated administrator for an AWS service.

マネジメントアカウントもしくは委任された管理者アカウントでのみ実行が可能、とあります。今回実行したアカウントは通常のメンバーアカウントでしたので、それにより API コールの検証に失敗したということのようです。

ほかの Organizations の API でも実行できるアカウント種別が限定されているものがありますので、意識しておくと良さそうです。

どんな時に ListAccounts が呼び出されているのか

今回の冒頭の例では特に Organizations に関する操作を明示的に行なったわけではありませんでした。イベントが記録された時刻の周辺のイベントと付き合わせていくと、Amazon Inspector コンソールを操作していた際に付随してListAccountsが実行されていたことがわかりました。

Organizations ではいくつかの AWS サービスと連携し、それらを統合管理できます。その一覧は以下にまとまっており、その中に Amazon Inspector も含まれています。

対象のサービスのコンソールを操作する際、ものによっては裏側で Organizations の API が呼びされていることがありそうです。

どう対応するのか

CloudTrail イベントのエラーを気にされる方は、CloudTrail イベントを何らかの仕組みでモニタリングされているのではないでしょうか。

今回は、以下ページのように CloudTrail イベントを CloudWatch Logs に出力しメトリクスフィルターおよび CloudWatch アラームを設定しているケースを想定します。

メトリクスフィルターの設定例は以下です。

{($.errorCode="*UnauthorizedOperation") || ($.errorCode="AccessDenied*")}

ListAccountsによるAccessDeniedを除外したい場合は以下のように変えてあげれば回避できます。

{(($.errorCode="*UnauthorizedOperation") || ($.errorCode="AccessDenied*"))&&($.eventName!="ListAccounts")}

ただ、もし SecurityHub で CIS ベンチマークのスタンダードを有効化している場合、メトリクスフィルターが規定のものでないと評価に失敗することが確認できています。

SecurityHub_Console_CIS

この場合の対応方針としては以下のあたりになるかと思います。

  • メトリクスフィルターを変えずに通知を静観する
  • メトリクスフィルターを変えずに CloudWatch アラームの閾値を上げる *1
  • メトリクスフィルターを変更した上で SecurityHub を抑制する

終わりに

"errorMessage": "CallerValidation check failed"という見慣れないメッセージが記録された場合、原因としてどこを気にするべきか、というエントリでした。

Organizations の API はものによっては実行できるアカウント種別が限定されており、それに合致しない場合は当該エラーが発生する、ということが分かりました。API の実行エラーとなると IAM ポリシーや SCP を思い浮かべてしまいましたが、それらとは別軸の話になるのが面白いところです。

ユーザーが意図して実行しなくともコンソールによって裏側で呼び出されていることがある、と覚えておくと役に立つかもしれません。

以上、 チバユキ (@batchicchi) がお送りしました。

参考

脚注

  1. この対処法で SecurityHub の評価に合格できるかは未検証です