![【Security Hub修復手順】 [ELB.18] Application Load Balancer リスナーと Network Load Balancer リスナーは、安全なプロトコルを使用して転送中のデータを暗号化する必要があります](https://images.ctfassets.net/ct0aopd36mqt/wp-refcat-img-cea52bc8a6ec5cad9021b38df4a08b9e/24c76ee7c1ae7aa7f9676a59c77f8702/aws-security-hub?w=3840&fm=webp)
【Security Hub修復手順】 [ELB.18] Application Load Balancer リスナーと Network Load Balancer リスナーは、安全なプロトコルを使用して転送中のデータを暗号化する必要があります
こんにちは！ほりぐちです。
皆さん、お使いのAWS環境のセキュリティチェックはしていますか？
本記事では、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修復手順をご紹介します。
本記事の対象コントロール
[ELB.18] Application Load Balancer リスナーと Network Load Balancer リスナーは、安全なプロトコルを使用して転送中のデータを暗号化する必要があります
[ELB.18] Application and Network Load Balancer listeners should use secure protocols to encrypt data in transit
前提条件
本記事はAWS Security Hubで「AWS基礎セキュリティのベストプラクティススタンダード」を利用されている方向けの内容となります。
AWS Security Hubの詳細についてはこちらのブログをご覧ください。
対象コントロールの説明
このコントロールは、Application Load Balancer（ALB）またはNetwork Load Balancer（NLB）のリスナーが、転送中のデータを暗号化するプロトコルで構成されているかどうかをチェックします。ALBのリスナーがHTTPSプロトコルで構成されていない場合、またはNLBのリスナーがTLSプロトコルで構成されていない場合に、コントロールが失敗します。
ALBのリスナーをHTTPSに、NLBのリスナーをTLSにすることで、このコントロールは成功します。
暗号化されていないHTTPやTCP/UDPのリスナーでは、クライアントとロードバランサー間で送受信されるデータがそのまま送信されます。パブリックネットワークを経由する通信の場合、この区間のデータは盗聴や中間者攻撃によって傍受・改ざんされるリスクがあります。ログイン情報や個人情報を含むリクエストを扱うシステムでは、このリスクが情報漏洩に直結します。
したがって、ALB・NLBともにリスナーの暗号化対応は必須です。
なお、ALBでHTTPリスナーをHTTPSへのリダイレクト用途として残す構成（[ELB.1] Application Load Balancer should be configured to redirect all HTTP requests to HTTPSで推奨される構成）を採用している場合、そのHTTPリスナー自体はプロトコルがHTTPのままであるため、本コントロールでは引き続き「失敗」として検出されます。この点は修復手順の中で改めて補足します。
修復手順
コントロールの確認方法
- Security Hubコンソールを開く
- 左メニューから「検出結果」を選択
- フィルターで対象のコントロールID「ELB.18」を検索
- 検出結果の詳細を開き、対象のリソースID（ロードバランサーリスナーのARN）を確認する
ステークホルダーに確認
修復を行う前に、以下の点をステークホルダーに確認してください。
- 対象のロードバランサーで使用するドメインと、SSL/TLS証明書の準備状況（AWS Certificate Manager（ACM）での発行を推奨）
- リスナーのプロトコルを変更することによるクライアントへの影響（HTTPやTCPで直接アクセスしているクライアントが接続できなくなる可能性）
- 既存の非暗号化リスナー（HTTP/TCP/UDP）を削除するか、HTTPSへのリダイレクト用途に変更するか
- 変更作業のタイミング（トラフィックの少ない時間帯での実施を推奨）
対応しない場合は、その理由を確認し、Security Hubで当該コントロールを「抑制済み」に設定します。
ALBのリスナーをHTTPSに変更する
Application Load Balancerの場合、以下の手順でHTTPSリスナーを追加します。
- AWS Certificate Manager（ACM）で、ロードバランサーのドメイン名に対するSSL/TLS証明書を発行する（既存の証明書がある場合はそちらを利用）
-
AWSマネジメントコンソールにサインインし、EC2コンソールを開く
-
左側のナビゲーションペインから「ロードバランサー」を選択し、対象のApplication Load Balancerを選択する
-
「リスナーとルール」タブから「リスナーを追加」をクリックする
-
「プロトコル」で「HTTPS」を選択し、ポート（通常443）を指定する
-
「ルーティングアクション」で、既存のHTTPリスナーと同じターゲットグループに転送するよう設定する
-
「セキュリティポリシー」は推奨のセキュリティポリシーを選択する
-
「デフォルトSSL/TLS証明書」で、手順1で準備したACM証明書を選択する
-
「リスナーを追加」をクリックする
-
既存のHTTPリスナー（ポート80）について、HTTPアクセスを引き続き受け付ける場合はルーティングアクションを「HTTPSへリダイレクト」に変更する。HTTPリスナー自体が不要な場合は削除する
補足: HTTPリスナーをHTTPSへのリダイレクト用途として残す場合、そのリスナー自体はプロトコルがHTTPのままであるため、ELB.18の判定上は引き続き「失敗」として検出されます。このリスナーが実データを暗号化なしで送受信していない（リダイレクト応答のみを返す）ことを確認できていれば、当該リスナーに限りSecurity Hubで「抑制済み」に設定する運用も選択肢です。コントロールへ厳密に対応する場合は、HTTPリスナー自体を削除してください。
参考記事:
NLBのリスナーをTLSに変更する
Network Load Balancerの場合、以下の手順でTLSリスナーを追加します。
- ACMで、ロードバランサーのドメイン名に対するSSL/TLS証明書を発行する（既存の証明書がある場合はそちらを利用）
- EC2コンソールの「ロードバランサー」から対象のNetwork Load Balancerを選択する
- 「リスナーとルール」タブから「リスナーを追加」をクリックする
- 「プロトコル」で「TLS」を選択し、ポートを指定する
- 「デフォルトアクション」で、既存のTCPリスナーと同じターゲットグループに転送するよう設定する
- 「セキュリティポリシー」は推奨のセキュリティポリシーを選択する
- 「デフォルトSSL/TLSサーバー証明書」で、手順1で準備したACM証明書を選択する
- 「リスナーを追加」をクリックする
- 既存のTCP/UDPリスナーが不要であれば削除する。クライアントが暗号化なしでの直接接続を必要とする場合は、その要件を事前に確認したうえで削除の可否を判断する
補足: NLBはレイヤー4で動作するため、ALBのようなHTTPからHTTPSへの自動リダイレクト機能はありません。暗号化されていないTCP/UDPリスナーを残す場合、そのリスナーはELB.18の判定上「失敗」のままとなります。
参考記事:
修復確認
修復後、Security Hubで検出結果が「PASSED」になることを確認します。
最後に
今回は、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修正手順をご紹介しました。
コントロールを修正して、お使いのAWS環境のセキュリティをパワーアップさせましょう！
最後までお読みいただきありがとうございました！どなたかのお役に立てれば幸いです。
以上、ほりぐちでした！
