ALBセキュリティポリシー変更前に既存リクエストへの影響を調査する

SSL/TLS通信で利用が推奨されるTLSのバージョンや暗号スイートは日々更新されています。
新規で構築した時点では最新の推奨セキュリティポリシーだったとしても、運用中にセキュリティチェックや脆弱性診断で指摘が入り、非推奨のTLSのバージョンや暗号スイートを除外する設定変更が必要になることはよくあります。
非推奨になった設定とはいえ、本番稼働しているシステムへの変更となると、事前に既存のリクエストにどれくらい影響があるかを調査して、対応策を講じる必要があります。

ALBのアクセスログにはクライアントがどのTLSプロトコルや暗号スイートで接続しているかが記録されています。
S3に保存されたALBアクセスログをAthenaを使って集計し、廃止予定の設定でALBに接続しているクライアントの状況を事前調査する方法を紹介します。

SSL/TLS通信のプロトコル・暗号スイートの推奨設定についておさらい

IPAが公開している「TLS暗号設定ガイドライン」では、「高セキュリティ型」「推奨セキュリティ型」「セキュリティ例外型」の3つの設定基準が示されており、各設定基準ではどのプロトコルや暗号スイートを許可すべきかを明確にあげています。
設定基準の中でも「推奨セキュリティ型」が推奨されています。

TLS暗号設定ガイドライン　安全なウェブサイトのために（暗号設定対策編）

本ガイドラインでは、安全性もしくは相互接続性についての特段の要求がなければ「推奨セキュリティ型」の採用を強く勧める。
― TLS 暗号設定ガイドライン Ver.3.0.1 p.35より

ALBを利用してHTTPSを提供しているシステムでは、セキュリティポリシーで利用可能なプロトコルおよび、暗号スイートを定義しています。
複数のセキュリティポリシーが提供されており、システムのセキュリティ要件に合わせて選択します。

執筆時点では、マネジメントコンソールから作成するとELBSecurityPolicy-TLS13-1-2-2021-06(推奨)がデフォルトで選択されています。
ただし、AWS CLIでセキュリティポリシーを指定せずに作成した場合はELBSecurityPolicy-2016-08がデフォルト設定になります。
ALBのセキュリティポリシーでTLS1.3をサポートしたのは、2023/03とまだ日が浅いので、ALB構築時には存在しなかったという人も多いと思います。

Application Load Balancer が TLS 1.3 のサポートを開始

以前はマネジメントコンソールから作成する場合もELBSecurityPolicy-2016-08がデフォルトで選択されていましたが、TLS暗号設定ガイドラインの「推奨セキュリティ型」と比較すると、設定基準を満たせないセキュリティポリシーであることがわかります。

プロトコルにTLS1.0/1.1を許可している
鍵交換にRSAを利用する暗号スイートを許可している
メッセージ検証のハッシュ関数にSHA1を利用する暗号スイートを許可している

どのような基準でALBのセキュリティポリシーを選択するかについては、以前本ブログでもとりあげているのでご参照ください。

Athenaでログを調査するために必要な設定

AthenaでALBのログを調査するためには、ALBのアクセスログをS3に保存する設定と、Athenaのデータベース、テーブル作成をする必要があります。
本稿では具体的な手順については記載しません。公式ドキュメントを参照し、設定してください。

以後サンプルで記載する集計用クエリは、パーティション射影を使用した Athena での ALB ログ用のテーブルの作成を利用し、日付でパーティション化されているテーブルを利用するものとします。

ログからセキュリティポリシー変更の影響を調査する

セキュリティポリシー変更の影響範囲を次のような観点で調査してみます。

リクエストが利用しているプロトコル/暗号スイートを集計し、廃止予定のプロトコル/暗号スイートがどれくらい利用されているのか
廃止予定のプロトコル/暗号スイートがどのようなユーザーから利用されているのか
- UserAgent：サポートしているOS/ブラウザからのリクエストなのか
- 接続元IPアドレス：特定のクライアントが弱いプロトコル/暗号スイートで接続しているのか
  - 特定のIPアドレスからのリクエストが多ければ、国や地域、ISPやモバイル回線のIPアドレスなのか調査する
廃止予定のプロトコル/暗号スイートがどのようなリクエストなのか
- 画像やcss、jsファイルを除外した場合のリクエスト数と比較することでクローリングなど機械的なリクエストかを判断する

OSやブラウザを最新にアップデートしていれば「推奨セキュリティ型」で指定されているプロトコル/暗号スイートを利用するはずです。例外のクライアントがどれくらい存在し、それが正規のリクエストなのかを絞り込んでいくことになります。

クエリサンプル：リクエストが利用しているプロトコル/暗号スイートを集計

SELECT substring(date, 1, 7) as month,
    ssl_protocol,
    ssl_cipher,
    count(*) as count
FROM alb_logs
WHERE day >= '2023/03/01'
    AND ssl_cipher <> '-'
GROUP BY substring(date, 1, 7),
    ssl_protocol,
    ssl_cipher
ORDER BY month,
    ssl_protocol,
    ssl_cipher DESC;

月ごとに分けて集計しています
- 傾向を掴むためのサンプルは多いほうがいいので、ある程度長期間のログを対象にすることをオススメします
- 単発で発生している例外リクエストや、クライアントのアップデートによる弱い暗号利用の改善を月ごとの集計でケアします
ssl_cipher <> '-'はHTTPSリスナー以外へのリクエストを除外しています

この集計結果で廃止予定のプロトコル/暗号スイートが利用されていなければ、セキュリティポリシー変更によってサイトにアクセスできなくなるクライアントはいないということになります。
現実ではそんなにお行儀のいいクライアントばかりではないので、大半のリクエストは推奨のプロトコル/暗号スイートを利用しているが、一部非推奨のプロトコル/暗号スイートでサイトに接続している状態だと思います。

セキュリティポリシー変更の影響を受けるクライアントの全体像が分かったので、さらに詳しく調査をしていきましょう。

クエリサンプル：廃止する暗号スイートを利用しているクライアントのIPアドレスとUserAgentを集計

非推奨な暗号スイートで接続してきているクライアントに絞って、接続元のIPアドレスと、UserAgentを集計します。

UserAgent

SELECT ssl_protocol,
    ssl_cipher,
    user_agent,
    count(*) as count
FROM alb_logs
WHERE day >= '2023/03/01'
    AND (
        ssl_cipher = 'AES128-SHA256'
        OR ssl_cipher = 'ECDHE-RSA-AES128-SHA'
    )
    AND target_status_code = '200'
GROUP BY ssl_protocol,
    ssl_cipher,
    user_agent
HAVING count(*) > 10
ORDER BY count DESC

target_status_code = '200'で正常なコンテンツにリクエストをしているログに制限しています
レコードが大量になる場合があるので、HAVING count(*) > 10で数回しかリクエストしていないものを除外しています
- 集計している期間が短い場合は、正規のリクエストを取りこぼす可能性もあるので、環境によって閾値は調整が必要です

IPアドレス

SELECT ssl_protocol,
    ssl_cipher,
    client_ip,
    count(*) as count
FROM alb_logs
WHERE day >= '2023/03/01'
    AND (
        ssl_cipher = 'AES128-SHA256'
        OR ssl_cipher = 'ECDHE-RSA-AES128-SHA'
    )
    AND target_status_code = '200'
GROUP BY ssl_protocol,
    ssl_cipher,
    client_ip
HAVING count(*) > 10
ORDER BY count DESC

クエリサンプル：リクエストから画像やcss、jsファイルを除外して集計する

ユーザーがブラウザからリクエストしている場合は、ページを表示するために画像やcss、jsファイルにもリクエストをしています。これらのファイルへのリクエストを除外して集計し、除外前の値と比較することで、ユーザー操作か機械的なリクエストかを判別します。

SELECT ssl_protocol,
    ssl_cipher,
    client_ip,
    count(*) as count
FROM alb_logs
WHERE day >= '2023/03/01'
    AND NOT REGEXP_LIKE(request_url, '(?i)\.(jpg|jpeg|png|gif|ico|css|js)')
    AND (
        ssl_cipher = 'AES128-SHA256'
        OR ssl_cipher = 'ECDHE-RSA-AES128-SHA'
    )
    AND target_status_code = '200'
GROUP BY ssl_protocol,
    ssl_cipher,
    client_ip
HAVING count(*) > 10
ORDER BY count DESC

前述のサンプルクエリの条件にNOT REGEXP_LIKE(request_url, '(?i)\.(jpg|jpeg|png|gif|ico|css|js)')を追加してあります。

一度のクエリでリクエスト数を比較したい場合は下記のように結果をジョインします。
この書き方だとAthenaで一度にスキャンされるデータ量が2倍になるのでご注意ください。

WITH Query1 AS (
  SELECT 
    ssl_protocol,
    ssl_cipher,
    client_ip,
    count(*) as count1
  FROM alb_logs
  WHERE day >= '2023/03/01'
    AND NOT REGEXP_LIKE(request_url, '(?i)\.(jpg|jpeg|png|gif|ico|css|js)')
    AND (
      ssl_cipher = 'AES128-SHA256'
      OR ssl_cipher = 'ECDHE-RSA-AES128-SHA'
    )
    AND target_status_code = '200'
  GROUP BY ssl_protocol, ssl_cipher, client_ip
  HAVING count(*) > 10
),

Query2 AS (
  SELECT 
    ssl_protocol,
    ssl_cipher,
    client_ip,
    count(*) as count2
  FROM alb_logs
  WHERE day >= '2023/03/01'
    AND (
      ssl_cipher = 'AES128-SHA256'
      OR ssl_cipher = 'ECDHE-RSA-AES128-SHA'
    )
    AND target_status_code = '200'
  GROUP BY ssl_protocol, ssl_cipher, client_ip
  HAVING count(*) > 10
)

SELECT 
  q1.ssl_protocol,
  q1.ssl_cipher,
  q1.client_ip,
  q1.count1,
  COALESCE(q2.count2, 0) as count2
FROM Query1 q1
LEFT JOIN Query2 q2
ON q1.ssl_protocol = q2.ssl_protocol
AND q1.ssl_cipher = q2.ssl_cipher
AND q1.client_ip = q2.client_ip
ORDER BY COALESCE(q2.count2, 0) DESC;

UserAgentを見ると、一見最新のブラウザからのアクセスのように見えるリクエストでも、画像やCSS、JSファイルへのリクエストが極端に少ない場合、UserAgentを偽装したクローリングやスキャンなどの機械的なリクエストである可能性が高まります。
接続元のIPアドレスを調べてみて、それが海外のサーバーホスティングサービスから来ている場合は、一般ユーザーからのリクエストである可能性はさらに低くなります。

ここまでで、ALBセキュリティポリシー変更影響を受けそうな実際のリクエスト数が把握できるようになったと思います。
おそらくは、一般ユーザーが古いOSやブラウザからリクエストしている場合か、システム連携の対向プログラムの実行環境が古い場合に限られてくるのではないでしょうか。

まとめ

ALBセキュリティポリシー変更により、影響のでそうなユーザーのリクエストを分析する方法を紹介してきました。
ALBのログ集計用にAthenaのテーブルを作成しておくことで、パフォーマンス確認やセキュリティチェックなど、さまざまな場面で簡単に集計を行うことができるので、ぜひ設定しておくことをオススメします。

今回は、OSやブラウザを更新しているユーザーであれば基本的に推奨型のセキュリティポリシーでも問題なく接続できるはずという方向性の調査となりましたが、システムによっては古い環境や特殊な環境からのリクエストを受け付ける要件があるかと思います。リスクを許容する場合、「TLS暗号設定ガイドライン」では「セキュリティ例外型」のチェックリストも用意されていますので、ご参照ください。

ただし、あくまでもセキュリティ例外型の採用は暫定運用であるべきと指摘されていますので、移行計画の策定や、他施策でのセキュリティ強化とセットでの採用が必要なことにご注意ください。