SigV2の廃止時期延期を発表: SigV2を利用しているかの調査方法もご紹介します

CS課佐竹です。

既に皆さまご存知かもしれませんが、AWSの公式ブログ（日本語版はこちら）にて表題の件のアナウンスがありましたのでご連絡いたします。また本ブログでは、「S3がSigV2を利用しているかどうか」を調べるための方法も合わせて記載いたします。
※6月17日に記事名を変更しました

要約
- これを受けて利用者はどのようにすべきか
SigV4をS3で利用しているのか調査する方法
まとめ

要約

S3のSigV2のサポートは、2019年6月24日に終了することはなくなりました
2020年6月24日以降に作成された新しいS3バケットではSigV2署名付きリクエストをサポートしていません
2020年6月23日以前に作成された既存のS3バケットは引き続きSigV2をサポートします

これを受けて利用者はどのようにすべきか

もともとのアナウンスにあったのは、2019年6月24日に署名バージョン2を利用した認証がS3で利用できなくなる、というものでした。これを受け、S3を利用しているユーザは、署名バージョンを2から4に変更する必要がありました。
※以後、ここでは基本的に署名バージョン2をSigV2、署名バージョン4をSigV4と記載します

署名バージョン2について詳しく知りたい方は、以下の公式ドキュメントをご覧ください。

付録 B: リクエストの認証 (AWS 署名バージョン 2)
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/auth-request-sig-v2.html

署名バージョン4についての変更点は以下の公式ドキュメントをご覧ください。

AWSAPI リクエストの署名 » 署名バージョン 4 署名プロセス » 署名バージョン 4 の変更
https://docs.aws.amazon.com/ja_jp/general/latest/gr/sigv4_changes.html

今回のアナウンスで、6月24日のSigV2の廃止は見送られることになりました。そのため、既存のS3バケットでは特に問題が出ないということになったため、急ぎの対応(SigV4への切り替え対応)をする必要がなくなりました。しかし「2020年6月24日以降に作成された新しいS3バケットではSigV2署名付きリクエストをサポートしません」という点で注意が必要です。それは、「既存の仕組みを利用し、新しく作成されたバケットに同じ仕組みを適用する」タイミングで、既存の仕組みがSigV2による実装を行っていた場合は、新しいバケットでだけ処理が失敗するということが起きてしまいます。
このような場合「今までうまくいっていたのに、急に動かなくなってしまった」となりますので、問題の切り分けが難しい場合もあるかと思われます。そのため、SigV4への強制的な切り替えはなくなったものの、基本的には仕組みはSigV4へ切り替えをされたほうが良いと考えます。実際、AWSのブログでもSigV4への切り替えを引き続き推奨しています。

SigV4をS3で利用しているのか調査する方法

何社か、お客様より対応方法についてお問い合わせを受けましたため、私が実際に調査した方法をお伝えします。参考にしていただければ幸いです。
以下の簡単なステップで確認が可能です。お客様によっては既に完了されているステップもあるかと存じますため、その場合は「4」から確認されるなどステップを飛ばして頂いて問題ございません。

CloudTrailを有効にします
CloudTrailでAmazon S3 オブジェクトレベルの API アクティビティの記録を有効にします
S3のアクティビティがCloudTrailのS3バケットに保存されるのを待ちます
AthenaでAmazon S3 オブジェクトレベルAPIのアクティビティから署名バージョンを分析します

以下で、それぞれのステップを説明いたします。

1. CloudTrailを有効にします

皆様 CloudTrail はOnにされているでしょうか？弊社のお客様には、証跡管理のためにほぼ必ずとOnにして頂いております機能となります。恐らくですが、多くのご利用者様ではOnになっていると考えられますため、ここでは詳細な設定方法についてはご案内致しません。未設定の場合ですが、以下の公式ドキュメントを参照し、ご設定ください。

AWS CloudTrail » ユーザーガイド » CloudTrail の使用開始 » お使いの AWS アカウントにおける証跡の作成 » コンソールで証跡を作成および更新する » 証跡の作成
https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html

2. CloudTrailでAmazon S3 オブジェクトレベルの API アクティビティの記録を有効にします

この機能は2016年11月にアナウンスされた機能で、意外にも多くのユーザ様が設定されていないように見えます。この機能はリリースと同時に「CloudTrailの利用者には自動的に有効化」されたわけではなく、各利用者様側で追加で有効化していただく必要があります。そのため、今回の調査を行われる場合は以下念のためご確認ください。
補足として、この設定を有効する場合における懸念点ですが、S3のAPIアクティビティの量は膨大です。そのためCloudTrailのS3利用料が少々今まで以上に増加すると想定されます。S3の利用料は非常に安いものですが、利用料が気になる場合は、本調査が完了した後にオフにされても問題ございません。

CloudTrail の更新 – Amazon S3 オブジェクトレベルの API アクティビティのキャプチャと処理
https://aws.amazon.com/jp/blogs/news/cloudtrail-update-capture-and-process-amazon-s3-object-level-api-activity/

この機能がリリースされるまで、CloudTrailはS3の操作は「バケット単位」でのみ履歴を保持していました。つまり、Create Bucketなど、バケットを作成するようなイベントは記録されていたのですが、S3のオブジェクト操作である「GetObject、DeleteObject、PutObject」などの API オペレーションは履歴に保持されていませんでした。これを有効化することができる機能がこちらになります。このようなイベントをAWSでは「データイベント」と呼んでおり、これらのデータイベントを保存するにはS3とLambdaそれぞれで有効化が必要となります。なお本調査ではS3のオブジェクト操作をAthenaにて検索しますため、この設定が必ず必要になってきます。

証跡のデータイベントと管理イベントのログ記録：データイベント
https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/logging-management-and-data-events-with-cloudtrail.html#logging-data-events

上記URLリンクに実際の設定方法が記載されていますが、以下参考までに画面キャプチャも添えておきます。

マネジメントコンソール上での設定方法

マネジメントコンソールから、CloudTrailの画面を表示します。Trailsを表示したら、設定済のCloudTrailを選択します。

赤枠で囲ってあるCloudTrailのNameを選択すると設定詳細画面に遷移します。

詳細設定の画面に遷移すると、「データイベント」の画面が現れます。何も設定されていない場合、上画像の通りの画面表示になるりますので、ここで「Configure」ボタンを押下して設定を進めます。

Configureを押下すると、上画像が表示されます。ここで「特定のバケットだけにデータイベントのロギングを設定する」ということもできますが、今回は全てのS3バケットに設定を行います。

「Select all S3 buckets in your account」にチェックを入れ、「Save」を押下します。

上の通り保存されましたら、S3のデータイベントのロギング設定は完了です。設定完了直後から、CloudTrailがS3のデータイベントを保存し始めます（過去に遡って実行ログの履歴を保存し直してくれることはありません）。

3. S3のアクティビティがCloudTrailのS3バケットに保存されるのを待ちます

先ほど「2」の設定を実施頂いたアカウントでは、実際のオペレーションが行われることで、「S3のオブジェクトレベルの API アクティビティ」がCloudTrailのS3バケット内に溜まるのを待つ必要があります。通常のオペレーションでは、1か月ほどのサイクルを待てば十分と考えますため、30日程度待って頂くのが良いと考えております。
既に前から「1」の手順も「2」の手順も完了しており、分析に十分なログが既にCloudTrailのS3バケットに保存されているユーザは次のステップに進んでください。

4. AthenaでAmazon S3 オブジェクトレベルAPIのアクティビティから署名バージョンを分析します

やっと調査の本題です。ただ、ここからはSQLを利用しますので、SQLになれていない方は少々戸惑われるかもしれません。ですがやってみると意外に簡単なので、一度お試しください。

分析用のテーブルを作成する

まずは、公式のドキュメントに則り、AthenaでCloudTrailのS3バケットを分析するテーブルを作成します。

Amazon Athena » ユーザーガイド » AWS のサービスのログのクエリ » AWS CloudTrail ログのクエリ
https://docs.aws.amazon.com/ja_jp/athena/latest/ug/cloudtrail-logs.html

公式ドキュメントにある「次の DDL ステートメントをコピーして Athena コンソール内に貼り付けます。」以下にあります「CREATE EXTERNAL TABLE cloudtrail_logs ～」から始まるのがそれになります。なお、このCreate Table DDLをお客様の環境に応じて変更すべき点は以下の2つです。

1. 必須変更項目
LOCATION 's3://CloudTrail_bucket_name/AWSLogs/Account_ID/';

s3:// 以下は、S3のバケットのフォルダを指し示す必要があります。この設定通りに実行しても、S3のバケット名と、アカウントIDが不一致となりSQLは失敗します。修正のコツは以下の通りです。

まずは「CloudTrail_bucket_name」を実際にCloudTrailで利用している、調査対象のS3 バケット名に変更する
「Account_ID」を分析対象のアカウントIDに変更する
1と2の変更だけでは検索対象が多すぎるため、リージョンと年月日を絞り込む。具体的には「's3://cloudtrail-satake/AWSLogs/111122223333/CloudTrail/ap-northeast-1/2019/06`」とする

特に重要なのは「3」です。CloudTrailのS3バケットには、「過去全ての操作履歴」が残っているようになっていますので、アカウントID配下の全てのデータにSQLを実行してしまうと、すさまじいレコード数になり、SQLのレスポンスが返ってこなくなるほど遅くなります。そのため、特定のリージョンと年月日を絞り込まれるべきです。今回は1か月分の調査を目的としているため、2019年の6月を対象フォルダとしました。

2.推奨変更項目
CREATE EXTERNAL TABLE cloudtrail_logs

2つ目はテーブルの名称です。同じ名前のテーブルは2つ作成できないため、今回であれば「cloudtrail201906_tokyo_logs」などと、後からみてもわかりやすいテーブル名に変更しましょう。変更した点はリージョンと年月ですので、その2つを明示的にテーブル名に含めていきます。なおテーブル名には -(ハイフン) が利用できません。ですのでテーブル名にap-northeast-1を入れようとするとエラーになります（Athenaあるあるネタの1つです）。そのため、tokyoと記載したり、ap_northeast_1としたりして、これを回避しましょう。

上記変更を行ったDDLでテーブルを作成します。ここまできましたら、あとは作成したテーブルに対してSQLを実行するだけです。

調査用SQLを実行する

作成したテーブルにおける、「additionaleventdata」というカラムに、SignatureVersionがSigV2なのかSigV4なのか結果が保存されます。試しに以下のSQLを実行し、結果を比較してみてください。
まずは、SigV2を検索するSQLです。お試しSQLなので、数は30行に制限しています。

SELECT *
FROM "cloudtrail201906_tokyo_logs"
WHERE additionaleventdata LIKE '{"SignatureVersion":"SigV2",%'
        AND eventsource = 's3.amazonaws.com'
        AND useridentity.arn <> '' limit 30;

こうするとadditionaleventdataカラムには以下のような結果が出力されているはずです。

{"SignatureVersion":"SigV2","CipherSuite":"AES128-SHA","bytesTransferredIn":0.0...

次に、SigV4を検索するSQLを試してみます。SQLの差は、数字を2から4に変更したのみです。

SELECT *
FROM "cloudtrail201906_tokyo_logs"
WHERE additionaleventdata LIKE '{"SignatureVersion":"SigV4",%'
        AND eventsource = 's3.amazonaws.com'
        AND useridentity.arn <> '' limit 30;

このSQLだと、additionaleventdataカラムには以下のような結果が出力されているはずです。

{"SignatureVersion":"SigV4","CipherSuite":"ECDHE-RSA-AES128-SHA","bytesTransferredIn":0.0...

このように、additionaleventdataカラムを利用することで、実際にS3に対してSigV2が利用されているかどうかが判断可能です。ただ、多くの場合SigV2のAPIコールは多すぎます。よってSQLを改善し、どのIAM UesrやIAM Roleが実行を行っているのか？を特定するSQLを書いていく必要があります。例を以下にあげさせて頂きます。

SELECT count(useridentity.arn) AS count_arn,
         useridentity.arn
FROM "cloudtrail201906_tokyo_logs"
WHERE additionaleventdata LIKE '{"SignatureVersion":"SigV2",%'
        AND eventsource = 's3.amazonaws.com'
        AND useridentity.arn <> ''
GROUP BY  useridentity.arn
ORDER BY  count_arn DESC limit 30;

このSQLを実行すると、どの arn がSigV2を実行しているのか？というのが操作回数と共に確認可能です。実際の結果を画面キャプチャとして例として掲載いたします。
※注意：Limitを30にしているために、30行以上結果が表示されません。それ以上に結果が返る可能性がある場合はLimitを100などに増加させてください

このように、どのIAM Userがその月に何回SigV2の著名バージョンでS3に対してデータイベントを発行したのかが確認可能です。10行目と11行目にあります結果は、stsのassumed-roleの結果で、特定のInstanceがIAM Roleを経由してキックしていることがわかります。ここにはRole名とInstance idも記載されますので、EC2 InstanceがIAM Roleでキックしている場合でも拾うことが可能です。

arn (IAM User / Instance id)が判明しましたので、最初のSQLへ戻りWhere区を修正して対象 (例：IAM User) ごとに詳細な調査が可能です。以下では、 useridentity.arn に先ほど得た IAM User の1つを指定( useridentity.arn = 'arn:aws:iam::111122223333:user/satake' )して実行しています。この結果として「このIAM Userは具体的にどのような操作をS3に対して実行しているのか？」を確認できます。

SELECT *
FROM "cloudtrail201906_tokyo_logs"
WHERE additionaleventdata LIKE '{"SignatureVersion":"SigV2",%'
        AND eventsource = 's3.amazonaws.com'
        AND useridentity.arn = 'arn:aws:iam::111122223333:user/satake'
limit 30;

他にも様々なSQLの書き方があると思いますが、今回はここまでで調査方法については説明を終えます。

まとめ

まずは、S3のSigV2のサポートは、2019年6月24日に終了することはなくなりましたので、急な対応に追われることはなくなりました。しかし、SigV2を利用し続けるよりも、SigV4に切り替えることはAWSが未だに推奨している状況です。もしかすると、2020年以降にやはりSigV2のサポートを終了されるとも限りませんので、計画的にSigV4への切り替えを検討されることを推奨いたします。

なお、具体的な移行方法は以下の公式ドキュメントにまとまっていますので、合わせてご確認頂けますと幸いです。