無効化したアクセスキーを使ったアクセスをCloudTrailで確認できるのか検証してみた
昨今、アクセスキーの漏洩から不正アクセスなどのセキュリティ事故の話が多いですね。AWS外部からAWSリソースを操作するために発行していたアクセスキーが不要になってアクセスキーを無効化したとしましょう。 その無効化したアクセスキーを使ってAWSリソースへアクセスしたらCloudTrailなどにログが残り「無効化したアクセスキーが使われている」と検知できるのか？と気になりました。
今回検証対象のアクセスキーについて
IAMユーザのアクセスキーは、アクセスキーIDとシークレットキーの組み合わせにより、利用期間に期限設定がなく永続的に使える認証情報です。期限はないのですがアクセスキーを有効にする（使える状態）か、無効にする（使えない状態）かは設定できます。
アクセスキーを利用する場合の推奨事項
- アクセスキーを発行する元のIAMユーザの権限を最小化する
- アクセスキーを定期的にローテーションして利用する
- アクセスキー利用状況の定期的な棚卸し
不要になったアクセスキーを無効化した後に、無効化したアクセスキーを使うとCloudTrailにログが記録されるのか？、アクセスキーをローテーションする際に古いアクセスキーを無効化した場合、CloudTrailにログが記録されるのか？という素朴な疑問を調査します。
検証結果
- IAMユーザで発行した永続的に使えるアクセスキーを無効化し、そのアクセスキーを使ったアクセスはCloudTrailにログは残らない
- CloudTrail以外にログが落ちる場所も確認できず
- IAMユーザで発行した永続的に使えるアクセスキーに何も権限を与えずにしてから有効化し、アクセスすればCloudTrailにログを残すことはできる
- 実害がないのであればアクセスキーに権限を与えたままでも良いのですが取り扱いには十分に気をつけてください
検証工程
- テストユーザの作成、アクセスキーの発行
- アクセスキーを使ったアクセスしCloudTrailのログを確認
- テストユーザのアクセスキーを無効化
- 無効化したアクセスキーを使ったアクセスしCloudTrailのログを確認
テストユーザ作成
disabled-access-key-testユーザを作成しました。プログラムによるアクセスのみ許可し、アクセスキーID、シークレットアクセスキーでアクセスする用途です。権限はReadOnlyAccessを設定しました。
アクセスキーID、シークレットアクセスキーを環境変数に入れます。
export AWS_ACCESS_KEY_ID=xxx export AWS_SECRET_ACCESS_KEY=xxx export AWS_DEFAULT_REGION=ap-northeast-1
試しにS3バケット一覧を出力します。出力できたのでリード権限は問題なし。
$ aws s3 ls 2021-05-19 14:02:57 abashiri-image 2021-05-19 12:00:27 abashiri-image-log
今度はS3バケットを作成してみます。ライト権限はないのでAccess Deniedで弾かれました、期待した動作です。
$ aws s3 mb s3://ohmura-new-bucket make_bucket failed: s3://ohmura-new-bucket An error occurred (AccessDenied) when calling the CreateBucket operation: Access Denied
テストユーザの認証情報を使いAWSリソースにアクセスできる検証環境の準備ができました。
CloudTrailのログ確認
イベント履歴からユーザ名で検索しました。ListBucketsとCreateBucketを実行したログを確認できます。
S3バケット作成に失敗したことも確認できます。
テストユーザの実行したアクションをCloudTrailのイベント履歴から追えることを確認しました。
アクセスキーの無効化
アクセスキーを無効化します。
無効化されたアクセスキーを使ってみる
S3バケット一覧を出力します。InvalidAccessKeyIdと表示され、先ほどまで出力できていたS3バケット一覧を出力できません。
$ aws s3 ls An error occurred (InvalidAccessKeyId) when calling the ListBuckets operation: The AWS Access Key Id you provided does not exist in our records.
S3バケット作成も同様にInvalidAccessKeyIdのエラーを確認できました。
$ aws s3 mb s3://ohmura-new-bucket make_bucket failed: s3://ohmura-new-bucket An error occurred (InvalidAccessKeyId) when calling the CreateBucket operation: The AWS Access Key Id you provided does not exist in our records.
EC2インスタンス一覧を出力するとAuthFailureのエラーを確認できました。
$ aws ec2 describe-instances An error occurred (AuthFailure) when calling the DescribeInstances operation: AWS was not able to validate the provided access credentials
Kinesis Data Streamを作成するとUnrecognizedClientExceptionのエラーを確認できました。
$ aws kinesis create-stream --stream-name test --shard-count 1 An error occurred (UnrecognizedClientException) when calling the CreateStream operation: The security token included in the request is invalid.
無効化されたアクセスキーを使ったという各リソース共通のエラーは返ってこないことを確認できました。リソース毎にエラーは返してくれますが、少し試しただけでもエラーメッセージは統一されていないことはわかりました。
CloudTrailのログ確認
無効化したアクセスキーを使ったアクセスの場合、アクセスキー、ユーザ名からCloudTrailにログを確認できませんした。 アクセスキー、ユーザ名での検索は諦め、個々のアクションのログがないか検索しました。 たとえばS3バケットを作成しようとしたログを実行した時間帯付近を確認しましたがログはありませんでした。
つまり、無効化したアクセスキーを使ったアクセスはCloudTrailに記録されないことがわかりました。アクセスキーが存在していないため対象のAWSアカウントを特定できなく、対象のAWSアカウントへ到達すらしていないか、仮に対象のAWSアカウントへ到達していても何もできないためCloudTrailに記録が残らないことと推測されます。何も根拠はなかったのですが勝手に残るものだろうと思っていました。
なんとかアクセスログを残したい
アクセス権限はReadOnlyAccessに設定していました。権限を削除し何も権限がない状態にします。
すべての権限を剥奪した上でアクセスキーを有効化にしました。漏洩し知らないところや、過去にアクセスキーをなにかに埋め込んで今なお動き続けていたらどうなるかわかりませんね。権限を剥奪して有効化した際のリスクを抑えました。
アクセス権がなにもないアクセスキーを使ってみる
以下、アクセス権がないためすべて失敗した実行結果です。エラーメッセージはアクセスキー無効化時とは異なります。後半にメッセージを比較しまとめています。
S3バケット一覧取得
$ aws s3 ls An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied
S3バケット作成
$ aws s3 mb s3://ohmura-new-bucket make_bucket failed: s3://ohmura-new-bucket An error occurred (AccessDenied) when calling the CreateBucket operation: Access Denied
EC2インスタンス一覧取得
$ aws ec2 describe-instances An error occurred (UnauthorizedOperation) when calling the DescribeInstances operation: You are not authorized to perform this operation.
Kinesis Data Stream作成
$ aws kinesis create-stream --stream-name test --shard-count 1 An error occurred (AccessDeniedException) when calling the CreateStream operation: User: arn:aws:iam::123456789012:user/disabled-access-key-test is not authorized to perform: kinesis:CreateStream on resource: arn:aws:kinesis:ap-northeast-1:123456789012:stream/test
エラーメッセージ比較
| アクセスキーの状態 | S3バケット一覧 | S3バケット作成 | EC2一覧 | Kinesis作成 |
|---|---|---|---|---|
| 無効化 | InvalidAccessKeyId | InvalidAccessKeyId | AuthFailure | UnrecognizedClientException |
| 権限なし | AccessDenied | AccessDenied | UnauthorizedOperation | AccessDeniedException |
CloudTrailのログ確認
アクセス権がなく失敗しているためCloudTrailにはエラーコードと共に記録されました。この方法ではあれば権限のないアクセスキーを使ってなにかすると権限がなく失敗したログを残すことができました。CloudTrailからの検索はユーザ名か、アクセスキーで検索すると確認しやすいです。権限なし系のエラーもまちまちなのでエラーメッセージ・コードからの検索するのは大変でした。CloudTrailのログをAthenaからerrorcodeが空以外で検索してみたのですが、ログの量が多くて工夫しないと実用的な確認方法ではないなといった印象です。
まとめ
- 無効化したアクセスキーを使ってもCloudTrailにログが記録されない
- すべての権限を剥奪してアクセスキーを有効化に戻し、アクセスがあれば権限ない系のエラーがCloudTrailに記録が残る
AWS外からAWSリソースへアクセスするなどの理由により、最小権限に設定したIAMユーザのアクセスキーを作成することはあります。運用・管理面を考えるとアクセスキーのローテーションや、古いアクセスキーの使用可否、例えば数年に1度しかアクセスが発生しないサーバにアクセスキーを埋め込み、本当にアクセスキーが使われているのか後々判斷に困ることも考えられます。
以上のことからアクセスキーを管理するのはなにかと苦労も多く大変なため、IAMロールの利用が推奨されております。アクセスキーのローテーションや、棚卸しのタイミングで、アクセスキーを利用しないと本当にやりたいことを実現できないのか見直してみてはいかがでしょうか。
おわりに
アクセスキーを無効化しててもアクセスキー使ったらCloudTrailにしっかり記録されるのではないの？わざわざやったことないけど。という疑問をドキュメントを読んでも情報は見当たらず、手を動かした方が早そうだったので試してみました。 何も根拠のない仮説とは異なった結果となり良い勉強になりました。もしどこどこにログが落ちるよとかご存じの方いらっしゃいましたら是非ご連絡いただけますと、ありがたく検証させてもらいます。
