ELB のセキュリティポリシー変更はブラウザの対応プロトコルを考慮して慎重に
こんばんは、菅野です。 ELB の「事前定義されたセキュリティポリシー」に二つ追加されましたので、今回はそのお話になります。 ELB を使う限り避けては通れない部分なので簡単に書いてみました。
はじめに
ELB や ALB に用意されている「事前定義されたセキュリティポリシー」は https や ssl のリスナーを使う際には必ず選択しなくてはいけません。（ELB はカスタムセキュリティポリシーを使えますが今回その話はしません） では「セキュリティポリシー」とは何か、ですが以下の3つの組み合わせを指します。
- 「セキュリティを要求される通信を行うためのプロトコル」
- 「暗号スイートと呼ばれる暗号技術の組み合わせ」
- 「サーバーの優先順位オプション（今回触れません）」
これら3つを組み合わせた AWS が用意する「おすすめのセット」が「事前定義されたセキュリティポリシー」です。
最近の事前定義されたセキュリティポリシー
最近のものは以下の3つとなります。
- ELBSecurityPolicy-2016-08（以降「Policy-2016-08」）
- ELBSecurityPolicy-TLS-1-1-2017-01（以降「Policy-TLS-1-1」）
- ELBSecurityPolicy-TLS-1-2-2017-01（以降「Policy-TLS-1-2」）
今現在、ELB のリスナーを作成すると自動で選ばれるのは「ELBSecurityPolicy-2016-08」です。 では、最近追加された残りの二つとの違いを見てみましょう。
プロトコル
| Policy-2016-08 | Policy-TLS-1-1 | Policy-TLS-1-2 | |
|---|---|---|---|
| Protocol-TLSv1 | ○ | ||
| Protocol-TLSv1.1 | ○ | ○ | |
| Protocol-TLSv1.2 | ○ | ○ | ○ |
ご覧のように、「TLS-1-1」「TLS-1-2」共に TLS1.0 のサポートを切っていて今回のタイトルである「慎重に」はこの点を指しています。 新しいセキュリティポリシーが出たから使おう！と軽い気持ちでこのどちらかを選択すると、「https で web サイトにアクセスできなくなった！」という事が発生する「可能性」があります。 ではどういった時に発生するのかというと、簡単に言えば「クライアント（ブラウザ）が TLS1.0 しか使えない」場合に発生します。 どのクライアントがどのプロトコルを使えるのかは、以下のページに一覧がありましたので参考ページとして記載します。 Web ブラウザの TLS サポートチェック
暗号スイート
| Policy-2016-08 | Policy-TLS-1-1 | Policy-TLS-1-2 | |
|---|---|---|---|
| ECDHE-ECDSA-AES128-GCM-SHA256 | ○ | ○ | ○ |
| ECDHE-RSA-AES128-GCM-SHA256 | ○ | ○ | ○ |
| ECDHE-ECDSA-AES128-SHA256 | ○ | ○ | ○ |
| ECDHE-RSA-AES128-SHA256 | ○ | ○ | ○ |
| ECDHE-ECDSA-AES128-SHA | ○ | ○ | |
| ECDHE-RSA-AES128-SHA | ○ | ○ | |
| ECDHE-ECDSA-AES256-GCM-SHA384 | ○ | ○ | ○ |
| ECDHE-RSA-AES256-GCM-SHA384 | ○ | ○ | ○ |
| ECDHE-ECDSA-AES256-SHA384 | ○ | ○ | ○ |
| ECDHE-RSA-AES256-SHA384 | ○ | ○ | ○ |
| ECDHE-RSA-AES256-SHA | ○ | ○ | |
| ECDHE-ECDSA-AES256-SHA | ○ | ○ | |
| AES128-GCM-SHA256 | ○ | ○ | ○ |
| AES128-SHA256 | ○ | ○ | ○ |
| AES128-SHA | ○ | ○ | |
| AES256-GCM-SHA384 | ○ | ○ | ○ |
| AES256-SHA256 | ○ | ○ | ○ |
| AES256-SHA | ○ | ○ |
「Policy-2016-08」「Policy-TLS-1-1」の内容は同じです。 「Policy-TLS-1-2」だけが異なっていて、ハッシュアルゴリズムの SHA-1 を非対応としたようです。 認証局では既に SHA-1 を使ったSSLサーバ証明書の発行ができなくなっており、最近では SHA-1 が破られたというニュースも流れましたから、安全の為には「ELBSecurityPolicy-TLS-1-2-2017-01」を使うのが一番なのかもしれません。
まとめ
セキュリティを確保する為には「ELBSecurityPolicy-TLS-1-2-2017-01」を選択したいところですが、セキュリティポリシーを変更する場合は、自分の運営している web サイトへしてくるクライアントの対応状況を調べ、問題が無い（もしくは無視できる）かを検討しましょう。 変更した後も、しばらくの間は web サーバーのアクセス数の変化を監視してビジネスへ悪影響が出ていないか確認しましょう。
最後に
いかがでしたでしょうか。 セキュリティポリシーの変更はセキュリティを向上させる面と、障害を発生させる可能性もある事を覚えておいてください。 このブログ記事が、普段 ELB を使っていてもセキュリティポリシーをあまり意識していなかった人へ、設定を見直すきっかけになってくれれば幸いです。
参考ページ
これらのページを参考にさせていただきました。 ありがとうございました。
![[レポート]NGate：NFCを中継してATMから不正引き出しを行う新型Androidマルウェア – CODE BLUE 2024 #codeblue_jp](https://images.ctfassets.net/ct0aopd36mqt/Zons7RQD2xcZVq9pUY8Dp/4d05341e17a1eb3ccf108b25f8044b03/eyecatch_codeblue_2024_1200x630.png)
