へのガイド TLS 標準準拠

トランスポート層セキュリティ（TLS）プロトコルは、インターネットを介したネットワーク通信を保護するための主要な手段です。 この記事は、現在のサーバーに対応するように安全なサーバーを構成するのに役立つ簡単なガイドです。 TLS 標準。

概要

　 トランスポート層セキュリティ（TLS) プロトコルは、インターネットを介したネットワーク通信を保護するための主要な手段です。 それ（およびその前身、 Secure SocketsLayerまたはSSL）多くのアプリケーションで何十年も使用されてきましたが、特にブラウザで使用されています。 HTTPS ウェブサイト。 TLS 通常はバックグラウンドで静かに機能しますが、人が考えることに反して、 TLS 機能するブラックボックスではありません。 むしろ、セキュリティ TLS 提供は、さまざまな暗号化アルゴリズムの連携から生じます。 また、 TLSは、以前のSSLと同様に、セキュリティ業界とともに絶えず進化しています。新しいテクノロジーとビジネスの要件を満たし、最新のセキュリティの脅威を軽減する必要があります。 アルゴリズムは時間の経過とともに陳腐化する可能性があり、または慣行が放棄される可能性があり、各変更はの全体的なセキュリティに影響を与えます TLS インスタンス（現在、接続を保護しているインスタンスなど）。

この変動性により、さまざまな標準化団体がガイドライン文書を公開する動機になっているため、 TLS セキュリティは、特定の市場、セクター、またはサービスで確立できます。 残念ながら、そのような規格は数多くあり、セクターごとに異なる適用可能なドキュメントへの準拠が必要ですが、規格自体は また 時間の経過とともに進化し、保護するように設計されたセクターの変化に対応します。

当然のことながら、この標準の海をナビゲートしてモダンな TLS インスタンスは、管理者にとって大きな頭痛の種になる可能性があります。 この記事は、期待に応えるように安全なサーバーを構成するのに役立つ簡単なガイドです TLS 2021年の標準。（さらにヘルプが必要な場合は、で最も人気のあるWebサーバーソリューションの構成例も示します。 付録.)

基準

のためのガイドラインを維持するいくつかのエンティティがあります TLS 米国保健社会福祉省（HHS）や米国国立標準技術研究所（NIST）などのネットワークセキュリティに関して。 簡潔にするために、この記事では、最も採用されているXNUMXつのドキュメントについてのみ説明します。

1. 　 健康保険の携帯性と説明責任に関する法律 （HIPAA）
2. NISTの SP800-52r2ガイドライン
3. 　 ペイメントカード業界のデータセキュリティ基準 （PCI-DSS）

HIPAA

HIPAAは、1996年に米国政府によって制定された、安全な取り扱いに関する規則です。 保護された健康情報 （PHI）。 PHIは、検査結果や診断などのデジタル患者情報を指します。 HIPAA ガイダンス文書 2013年に発行された次のように述べています。

移動中のデータの有効な暗号化プロセスは、必要に応じて、NIST Special Publications 800-52、トランスポート層セキュリティの選択と使用に関するガイドライン（TLS）実装; 800-77、IPsecVPNのガイド。 または800-113、SSL VPNのガイド、または連邦情報処理標準（FIPS）140-2で検証されたその他のもの。

NIST標準

2005年、NISTはSpecial Publication（SP）800-52を発行し、安全に構成するための正しい運用手順を説明しました TLS 政府機関のサーバーのインスタンス。 その後、SP800-52はバージョンSP800-52r1（2014）およびSP 80052r2（2019）に置き換えられました。 この記事は、現在安定しているSP800-52r2のガイドラインに従います。

PCI-DSS

PCI-DSSは、支払いおよびカード情報がeコマースWebサイトでどのように処理されるかを確立する、Payment Card Industry（PCI）Standards Security Council（SSC）によって維持されるコンプライアンス標準です。 の適切な構成について TLS インスタンス、PCI-DSS状態：

「強力な暗号化と安全なプロトコル（NIST SP 800-52およびSP 800-57、OWASPなど）に関する情報については、業界標準とベストプラクティスを参照してください。」

TLS 標準：これらすべてをまとめる

各標準は、その機能と処理するデータに基づいて、さまざまなシステムに影響を与えることに注意してください。 たとえば、病院の電子メールサーバーは、交換されたメッセージに患者情報が含まれる可能性があるためHIPAAガイドラインに該当する可能性があり、病院のCRMシステムはクレジットカードやその他の顧客データが含まれる可能性があるため、PCI-DSSに該当する可能性があります。 XNUMXつの標準すべてに準拠するには、共通の TLS すべてのドキュメントに存在するパラメータ。

幸いにも、すべての規格がNISTのガイドラインに従っていることは明らかです。 TLS パラメーター。 つまり、この記事の執筆時点では、SP 800-52r2に準拠していると、サーバーはHIPAAおよびPCI-DSSにも準拠するはずです。 （さて、これは 正確に trueですが、次のセクションで説明が明確になります。）

構成可能 TLS パラメータ

そのセキュリティのレベル TLS が最も影響を受けるのは プロトコルバージョン （つまり、1.0、1.1など）および許可された 暗号スイート。 暗号は、暗号化と復号化を実行するアルゴリズムです。 ただし、 暗号スイート 安全性を確立するために一緒に使用される、暗号、鍵交換アルゴリズム、およびハッシュアルゴリズムを含むアルゴリズムのセットです。 TLS 接続。 最も TLS クライアントとサーバーは複数の選択肢をサポートしているため、共通の接続を選択するために安全な接続を確立するときに交渉する必要があります TLS バージョンと暗号スイート。

TLS プロトコルバージョン

に関する TLS バージョンサポート、NIST SP 800-52r2は次のように述べています。

政府専用アプリケーションをサポートするサーバー 条 を使用するように構成する TLS 1.2と すべき を使用するように構成する TLS 1.3も。 これらのサーバー いけません を使用するように構成する TLS 1.1と してはならない つかいます TLS 1.0、SSL 3.0、またはSSL2.0。

...

市民またはビジネス向けのアプリケーションをサポートするサーバー（つまり、クライアントは政府のITシステムの一部ではない可能性があります） 条 交渉するように構成されている TLS 1.2と すべき 交渉するように構成されている TLS 1.3。 の用法 TLS バージョン1.1および1.0は一般的に推奨されていませんが、これらのバージョンは、市民や企業との対話を可能にするために必要に応じて構成できます…これらのサーバー してはならない SSL2.0またはSSL3.0の使用を許可します。

代理店 条 サポート TLS 1.3 1年2024月XNUMX日まで。この日付以降、サーバー 条 サポート TLS 1.3政府のみのアプリケーションと、市民または企業向けのアプリケーションの両方。 一般的に、サポートするサーバー TLS 1.3 すべき を使用するように構成する TLS 1.2も。 しかしながら、 TLS 1.2をサポートするサーバーでは無効になっている可能性があります TLS 1.3と判断された場合 TLS 相互運用性のために1.2は必要ありません。

一方、 TLS 1.0は禁止されており、 TLS 1.1は政府のサイトでは推奨されていません。NISTガイドラインでは、サードパーティのサービス、政府が管理するサーバーとの互換性のために、 かもしれません 実装する TLS 必要に応じて1.0および1.1。 PCI-DSS 3.2.1（現在のバージョン）では、準拠サーバー サポートを落とさなければならない for TLS 1.0および「最小限に移行する TLS 1.1、できれば TLS 1.2。」 HIPAAは、技術的にすべてのバージョンの使用を許可します TLS。 したがって、一般的にサポートされている最小値 TLS バージョンは1.1です。 ただし、PCI-DSSとNISTは、より安全な使用を強く推奨しています TLS 1.2（そして、上記のように、NISTはの採用を推奨しています TLS 1.3および2024年までにサポートが必要になる予定です）。

暗号スイート

TLS 1.2以前

SP 800-52r2は、さまざまな許容可能な暗号スイートを指定しています TLS 1.2以前。 この標準では、特定の暗号スイートのサポートは必要ありませんが、より強力な暗号スイートを選択するためのガイダンスが提供されています。

1. 静的キーよりもエフェメラルキーを優先します（つまり、DHよりもDHEを優先し、ECDHよりもECDHEを優先します）。 エフェメラルキーは、完全転送秘密を提供します。
2. CBCモードよりもGCMまたはCCMモードを優先します。 認証付き暗号化モードを使用すると、いくつかの攻撃を防ぐことができます（詳細については、[SP 3.3.2-800r52の]セクション2を参照してください）。 これらは以前のバージョンでは利用できないことに注意してください TLS 1.2.
3. CCM_8よりもCCMを優先します。 後者には短い認証タグが含まれているため、認証強度が低くなります。

さらに、これらは 許可 暗号スイート、 TLS サーバーは多種多様なプラットフォームやクライアントを処理しないため、これらのアルゴリズムのごく一部のみを使用することをお勧めします。 より多くの暗号スイートを許可すると、新しいプロトコルの脆弱性が発見された場合（またはその場合）にのみ、攻撃対象がサーバーに広がる可能性があります。

TLS 1.3

TLS 1.3には、はるかに短い暗号スイートのリストがあります。

• TLS_AES_128_GCM_SHA256 (0x13, 0x01)
• TLS_AES_256_GCM_SHA384 (0x13, 0x02)
• TLS_AES_128_CCM_SHA256 (0x13, 0x04)
• TLS_AES_128_CCM_8_SHA256 (0x13, 0x05)

まとめ

この簡単なガイドがあなたの理解を深めるのに役立つことを願っています TLS、および構成時に支援します TLS 自分のサーバーで。 これまでに説明した標準と推奨事項に関して、次のセクションには、最も一般的なWebサーバーソリューションに適用できるはずの構成例が含まれています。 オンラインコンプライアンスを維持する方法について質問がある場合は、メールでお気軽にお問い合わせください Support@SSL.com または、この画面の下部にあるライブチャットボタンをクリックします。

付録：例 TLS 構成

XNUMXつの仕様ドキュメントに記載されているルールを収集すると、最新の安全なサーバーは実装する必要があります TLS 1.2および/または TLS 1.3、選択された暗号スイートの短いが多様なリスト。 クイックリファレンスとして、市場で最も人気のあるWebサーバーの構成例を以下に示します。 これらは、Mozillaで生成された「中間」（汎用）構成です。 SSL構成ジェネレーター:

... SSLProtocol all -SSLv3-TLSv1  - TLSv1.1 SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256：ECDHE-RSA-AES128-GCM-SHA256：ECDHE-ECDSA-AES256-GCM-SHA384：ECDHE-RSA-AES256-GCM-SHA384：ECDHE-ECDSA-CHACHA20- POLY1305：ECDHE-RSA-CHACHA20-POLY1305：DHE-RSA-AES128-GCM-SHA256：DHE-RSA-AES256-GCM-SHA384 SSLHonorCipherOrder off SSLSessionTickets off

... ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

... ssl.openssl.ssl-conf-cmd =（ "Protocol" => "ALL、-SSLv2、-SSLv3、-TLSv1、-TLSv1.1 "）ssl.cipher-list =" ECDHE-ECDSA-AES128-GCM-SHA256：ECDHE-RSA-AES128-GCM-SHA256：ECDHE-ECDSA-AES256-GCM-SHA384：ECDHE-RSA-AES256-GCM- SHA384​​20：ECDHE-ECDSA-CHACHA1305-POLY20：ECDHE-RSA-CHACHA1305-POLY128：DHE-RSA-AES256-GCM-SHA256：DHE-RSA-AES384-GCM-SHAXNUMX "ssl.honor-cipher-order =" disable "

...

ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256：TLS_AES_256_GCM_SHA384：TLS_CHACHA20_POLY1305_SHA256 ssl-default-bind-options Preferred-client-ciphers no-sslv3 no-tlsv10いいえ-tlsv11いいえ-tls-tickets

ssl-default-server-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
ssl-default-server-ciphersuites TLS_AES_128_GCM_SHA256：TLS_AES_256_GCM_SHA384：TLS_CHACHA20_POLY1305_SHA256 ssl-default-server-options no-sslv3 no-tlsv10いいえ-tlsv11いいえ-tls-切符売場

...ポリシー：-PolicyName：Mozilla-intermediate-v5-0 PolicyType：SSLNegotiationPolicyType属性：-名前：Protocol-TLSv1.2値：true-名前：Server-Defined-Cipher-Order値：false-名前：ECDHE-ECDSA-AES128-GCM-SHA256値：true-名前：ECDHE-RSA-AES128-GCM-SHA256値：true-名前：ECDHE-ECDSA-AES256-GCM-SHA384値：true-名前：ECDHE-RSA-AES256-GCM-SHA384値：true-名前：DHE-RSA-AES128-GCM-SHA256値：true-名前：DHE-RSA -AES256-GCM-SHA384値：true