この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
AWS Blog や AWS Health Dashboard などで、案内されている通り AWS API エンドポイントにおける TLS 1.0 および 1.1 での接続が終了します。その対応に向けて AWS Blog で紹介されている内容を確認しながら、利用状況の確認方法を実際にやってみました。
そもそも、どういう話？
2023 年 6 月 28 日までにすべての AWS リージョンで、すべての AWS API で TLS バージョン 1.0 と 1.1 が使用できなくなることを意味します。
AWS サービスへの通信は TLS により暗号化した上で、サービスエンドポイントとの接続を行います。その通信において利用される TLS バージョンの最小要件が 1.2 となり TLS 1.0 や 1.1 での通信が不可となります。そのため、AWS SDK や CLI等を利用して API エンドポイントへ TLS 1.0 や 1.1 で通信を行なっている場合は、クライアント側で TLS1.2 以上で接続を行うように変更が必要となります。
上記ブログでは、確認方法以外にもこのような概要や FAQ、先立って実施された FIPS（連邦情報処理標準に準拠したエンドポイント）での情報へのリンクが記載されているため、対応を検討されている方には有益な情報も多いかと思います。
確認方法
AWS Blog 内では、TLS に関する情報を tlsDetails フィールドとしてレコードで取得が可能となった（全サービスへの対応は今後数ヶ月で実装予定とのことなので、22/8/5 時点ではサービスによっては検出されないこともあり得ます） CloudTrail を用いた TLS 利用状況の確認方法が3つ紹介されています。
個人的な所感で表にしてみました。調査に必要なリソースや設定が既に作成されている等、対象アカウントの状況によって最適な方法は異なってきますが、まずやってみるなら AWS CloudTrail Lake（以降、CloudTrail Lake） が手頃に調査が開始出来るのではないかと思います。今回は CloudTrail Lake での確認をやってみました。
2022/09/21 更新
下記アップデートにより AWS CloudTrail Lake でも過去証跡を取り込むことで確認することが可能となりました。
AWS CloudTrail Lake now supports import of CloudTrail Logs from Amazon S3
| 方法 | 特徴 | 注意点 |
|---|---|---|
| AWS CloudTrail Lake | ・CloudTrail Lake だけで利用可能 ・サンプルクエリあり |
設定後から検索対象となるため設定前の状況は確認できない |
| Amazon CloudWatch Log Insights | ・サンプルクエリあり ・ログ保管状況次第で長期間での確認が可能 |
事前準備が必要（CloudTrail データを CloudWatch Logへ連携） |
| Amazon Athena | S3 保存状況次第で長期間での確認が可能 | ・CloudTrail ログ TLS をクエリするためのサポートを追加予定 ・事前準備が必要(CloudTrail データをS3へ連携、Athena テーブル作成) ・クエリの作成が必要 |
また共通する注意点としては、いずれの方法も費用が発生するため調査が終了した後には有効化や作成したリソースは、無効化やリソース削除を行うことを推奨します。
CloudTrail Lake での確認
CloudTrail Lake での確認方法は 「 AWS Blog | Using AWS CloudTrail Lake to identify older TLS connections to AWS service endpoints 」 で紹介されている方法を参考に進めます。
1. イベントデータストア（EDS）の作成
CloudTrail ＞＞＞ レイク ＞＞＞ イベントデータストア ＞＞＞ イベントデータストアの作成
イベントタイプは、今回は管理イベントのみとしています。データイベントを対象とするには別途料金が必要なため、管理イベントで検出できなかった場合に有効化するなどが良いかもしれません。
※ CloudTrail イベントの種類については 「 CloudTrail のコンセプト 」をご確認ください。
すぐにイベントデータストアが作成されます。
2. サービス単位での TLS 1.0 および 1.１ の利用数を確認
CloudTrail Lake がデフォルトで用意しているサンプルクエリを利用して、サービス単位での利用状況を確認していきます。
レイク ＞＞＞ サンプルクエリ ＞＞＞ TLS で検索 ＞＞＞ クエリ SQL
eventTime を変更（UTC で有効化した時間以降） ＞＞＞ 実行
ステータス欄が ”成功しました” というレコードが表示されれば OK です。
今回は、有効化してからの期間が短いのと検証環境のため、TLS 1.0 および 1.1 の利用が検出されなかったと推察されます。これでは悲しいので、 TLS 1.2 および 1.3 の利用にクエリを変更して実行してみます。
検出されました！ これで、先ほどは環境に起因して結果がなかっただけで、設定やクエリ等には問題なく、安心と判断することができます。
「クエリ結果」 タブへ切り替えると、サービス単位でどれだけ利用されているかを確認することができます。今、ブログ記事を書くために CloudTrail を利用しているの結果が表示されていますね。
3. 詳細情報を確認
ブログ内で紹介されているカスタム SQL クエリ を利用して、eventName などより詳細な情報を取得し、利用方法や箇所を特定するための情報を得ていきます。
レイク ＞＞＞ エディター ＞＞＞ +
AWS Blog よりクエリをコピーして貼り付けます。 そのまま実行するとエラーになるので、クエリから２箇所修正します。
・ eventTime → サンプルクエリと同様に有効化以降の日付へ修正
・ ＄EDS_ID → 作成したイベンドデータストアのIDへ修正（画面左に記載があります）
実行
上記.2 と同様に利用は検出されませんでした。これは先ほど同様に環境起因の結果なので、また TLS バージョンを変更して実行してみます。
検出されたら、「クエリ結果」 タブを切り替えます。 詳細な情報一覧を得ることが出来ました。これらの情報や、さらに条件を追加していくことで、利用箇所の調査に役立つ情報が得られるかと思います。
4. 環境削除
CloudTrail Lake はそのままにしておくと費用が発生するため、イベントデータストアを削除します。
レイク ＞＞＞ イベントデータストア ＞＞＞ 該当イベントデータストアを選択 ＞＞＞ アクション ＞＞＞ 終了保護の変更 ＞＞＞ 無効 ＞＞＞ 保存
アクション ＞＞＞ 削除
7日間保留になった後に削除されます。
さいごに
実際に利用終了となるのは 2023年6月28日とされていますが、早めに対応計画を策定することが大切です。そのため通知を受けた場合には、まずは対象箇所を特定するために、本ブログや AWS Blog をご確認の上、ご対応いただければと思います。
0
