Red Hat Training

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

4.13. TLS 設定の強化

TLS (トランスポート層セキュリティー)は、ネットワーク通信のセキュリティー保護に使用する暗号化プロトコルです。優先するキー交換プロトコル、認証方法 、および暗号化アルゴリズムを設定してシステムのセキュリティー設定を強化する際には、対応しているクライアントの範囲が広ければ広いほど、セキュリティーが低くなることを認識しておく必要があります。反対に、セキュリティー設定を厳密にすると、クライアントとの互換性が制限され、システムからロックアウトされるユーザーが出てくる可能性もあります。可能な限り厳密な設定を目指し、互換性に必要な場合に限り、設定を緩めるようにしてください。
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 接続ピアは、安全な再ネゴシエーション indication(RFC 5746)を実装する必要があり、圧縮はサポートせず、CBC -mode暗号(Lucky Thirteen 攻撃)に対するタイミング攻撃手段を実装する必要があります。TLS 1.0 クライアントは、さらにレコード分割(BEAST 攻撃に対する回避策)を実装する必要があります。TLS 1.2 は、既知の問題のない AES-GCM、AES-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 暗号スイートに対応します
Red Hat Enterprise Linux の一部のコンポーネントは、TLS 1.1 または 1.2 のサポートを提供していても、TLS 1.0 を使用するように設定されます。これは、TLS の最新バージョンをサポートしない外部サービスとの最高レベルの相互運用性を提供することです。相互運用性要件に応じて、利用可能な TLS の最新バージョンを有効にします。
重要
SSL v3 の使用は推奨されていません。ただし、一般的な使用では安全ではなく、適切ではないと考えられているにもかかわらず、絶対に SSL v3 を有効にしたままにする必要がある場合でも、stunnel を使用して、暗号化をサポートしないサービスを使用している場合でも、stunnel を使用して通信を安全に暗号化する方法についての 「stunnel の使用」 を参照してください。

暗号化スイート

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

公開鍵の長さ

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

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