Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

4.13. TLS 設定の強化

TLS (Transport Layer Security)は、ネットワーク通信のセキュリティー保護に使用する暗号化プロトコルです。優先する 鍵交換プロトコル認証方法、および 暗号化アルゴリズム を設定してシステムのセキュリティー設定を強化する際には、対応するクライアントの範囲が広ければ広いほど、セキュリティーのレベルが低くなることを認識しておく必要があります。反対に、セキュリティー設定を厳密にすると、クライアントとの互換性が制限され、システムからロックアウトされるユーザーが出てくる可能性もあります。可能な限り厳密な設定を目指し、互換性に必要な場合に限り、設定を緩めるようにしてください。
Red Hat Enterprise Linux 7 に含まれるライブラリーが提供するデフォルト設定では、ほとんどのデプロイメントで十分な安全です。TLS 実装は、可能な場合は、安全なアルゴリズムを使用する一方で、レガシーなクライアントまたはサーバーとの間の接続は妨げません。セキュアなアルゴリズムやプロトコルに対応しないレガシーなクライアントまたはサーバーが、接続、または許可されていない、厳密なセキュリティー要件のある環境で、本セクションで説明されている設定を適用します。

4.13.1. 有効にするアルゴリズムの選択

複数のコンポーネントを選択し、設定する必要があります。以下の各設定は、その構成の強力性(クライアントにおけるサポートレベル)、または解決策がシステム上にある計算需要に影響します。

プロトコルのバージョン

最新バージョンの TLS は、最高のセキュリティーメカニズムを提供します。古いバージョンの TLS (または SSL)のサポートを含むように複雑でない限り、システムは最新バージョンの TLS だけを使用して接続をネゴシエートできます。
SSL バージョン 2 または 3 を使用したネゴシエーションはできません。これらのバージョンには、どちらも重大なセキュリティー脆弱性があります。TLS バージョン 1.0 以降を使用するネゴシエーションのみを許可します。TLS の現行バージョンである 1.2 は、常に優先されるべきです。
注記
現在、すべてのバージョンの TLS のセキュリティーは、TLS エクステンションの使用、特定の暗号(下記参照)その他の回避策によって異なることに注意してください。すべての TLS 接続ピアは、セキュアな再ネゴシエーション機能(RFC 5746)を実装する必要があります。圧縮はサポートしていないため、CBC-mode 暗号(Lucky Thirteen 攻撃)に対するタイミング攻撃の軽減方法を実装する必要があります。TLS 1.0 クライアントは、レコード分割を追加で実装する必要があります(BEAST 攻撃に対する回避策)。TLS 1.2 既知の問題がない AES-GCMAES-CCM、または Camellia-GCM などの割り当て られたデータ(AEAD)モード暗号で認証される暗号化 をサポートします。上記のすべての軽減策は、Red Hat Enterprise Linux に含まれる暗号化ライブラリーに実装されています。
プロトコルのバージョンの概要と推奨される使用方法は、表4.6「プロトコルのバージョン」 を参照してください。

表4.6 プロトコルのバージョン

プロトコルのバージョン使用法法
SSL v2
使用しないでください。深刻なセキュリティー上の脆弱性があります。
SSL v3
使用しないでください。深刻なセキュリティー上の脆弱性があります。
TLS 1.0
必要に応じて相互運用性の目的で使用します。相互運用性を保証した方法では軽減できない既知の問題があるため、軽減策はデフォルトで有効になりません。最新の暗号スイートには対応しません。
TLS 1.1
必要に応じて相互運用性の目的で使用します。既知の問題がありますが、Red Hat Enterprise Linux のすべての TLS 実装に含まれるプロトコルの修正に依存します。最新の暗号スイートには対応しません。
TLS 1.2
推奨されるバージョン。最新の AEAD 暗号スイートをサポートします。
TLS 1.1 または 1.2 のサポートがある場合でも、Red Hat Enterprise Linux の一部のコンポーネントは TLS 1.0 を使用するように設定されています。これは、最新バージョンの TLS をサポートしない可能性がある外部サービスとの最高レベルの相互運用性の実現を試みるためです。相互運用性の要件に応じて、利用可能な最新バージョン TLS を有効にします。
重要
SSL v3 使用は推奨されません。ただし、一般的に非セキュアであるとみなされ、SSL v3 を有効にしておく必要があるものの、暗号化をサポートしないか、または非セキュア暗号化モードのみを使用できる場合でも、stunnel を使用して通信を安全に暗号化する方法を、「stunnel の使用」 を参照してください。

暗号化スイート

旧式で安全ではない 暗号化スイート には、最近の、より安全なものを使用してください。暗号化スイートの eNULL および aNULL は、暗号化や認証を提供しないため、常に無効にしてください。可能な場合は、深刻な短い RC4 または HMAC-MD5 をベースとする暗号化スイートも無効にする必要があります。いわゆるエクスポート暗号化スイートも同様です。エクスポート 暗号化スイートは意図的に弱くなっているため、侵入が容易になっています。
128 ビット未満のセキュリティーしか提供しない暗号化スイートでは直ちにセキュリティーが保護されなくなるというわけではありませんが、短い便利なライフサイクルには考慮されません。128 ビット以上のセキュリティーを使用するアルゴリズムは、少なくとも数年間は大きなものであることが期待されているため、強く推奨されます。3DES 暗号は 168 ビットを使用していると言われていますが、実際には 112 ビットのセキュリティーが提供されることに注意してください。
サーバーの鍵が危険にさらされた場合でも、暗号化したデータの機密性を保証する (perfect)前方 Secrecy (PFS)をサポートする暗号スイートを常に優先します。ルールは高速の RSA 鍵交換は除外されますが、ECDHE および DHE を使用できます。この 2 つのうち、ECDHE が高速であるため、推奨の選択肢になります。
また、AEAD 暗号に、パディングオラクル攻撃に対して脆弱ではないため、AES-GCM の前に CBCなどの 暗号に優先する必要があります。さらに、多くの場合、AES-GCM は、特にハードウェアに AES の暗号アクセラレーターがある場合など、CBC モードの AES よりも高速です。
また、ECDSA 証明書で ECDHE 鍵交換を使用すると、トランザクションは純粋な RSA 鍵交換よりも速くなります。レガシークライアントに対応するため、サーバーには証明書と鍵のペアを 2 つ(新しいクライアント用の ECDSA キー)と、RSA キー(レガシー用)の 2 つをインストールできます。

公開鍵の長さ

RSA キーを使用する場合は、SHA-256 以上で署名され、鍵の長さが 3072 ビット以上のものが常に推奨されます(これは、実際に 128 ビットであるセキュリティーに対して十分な大きさです)。
警告
システムのセキュリティーは、チェーンの弱いリンクが弱いため、システムのセキュリティーが強力であることに留意してください。たとえば、強力な暗号化だけではすぐれたセキュリティーは保証されません。鍵と証明書ほど重要で、認証局 (CA)が鍵の署名に使用するハッシュ機能と鍵も重要になります。

このページには機械翻訳が使用されている場合があります (詳細はこちら)。