RHEL のシステム全体の暗号化ポリシー

注記: これは、Consistent security by crypto policies in Red Hat Enterprise Linux 8 の記事の継続的に更新されるバージョンです。

今日のソフトウェアエコシステムは、オープンソースやクローズドソースかに関係なく、多様性が特徴です。 通常、データベースアプリケーションは、HTTP サービスや SSH サービスなどを開発したチームとは別のチームから作成されます。 各チームは、ソリューションに独自のライブラリー、言語、ユーティリティー、暗号プロバイダーを選択します。 アプリケーション固有のコミュニティーとチームに焦点を当てているため、その多様性は計り知れない強みをもたらします。ただし、システムに一貫した暗号化ポリシーを適用することが困難になることがよくあります。 複数の大学や組織のセキュリティー研究者が、Applied Crypto Hardening ガイドをまとめています。これは、吟味された暗号設定でシステムを設定するための理論や手順を 110 ページにわたって解説したものです。 このガイドでは、Web サーバーアプリケーション (Apache、nginx)、OpenSSH サーバー、メールサーバーでの TLS の使用などについて解説しています。 これは、セキュリティーソフトウェアエコシステムを理解するための大規模で称賛に値する取り組みと言えます。

この取り組みによりさらに明らかになったのは、異種環境を正しく構成するには多大な労力が必要であること、また、そのようなシステムで新しいコンポーネントを賢明に設定するには、多くの場合において、深い暗号化の知識が必要であるということです。 同時に、今日のベストプラクティスガイドに記載されている内容は、将来的には安全でない設定とみなされることから、システムの設定を最新の状態に保つための隠れたコストについて詳細に明らかにしています。 今日、このコストは IT 部門が負担しています。IT 部門は、自動化や設定管理に関係なく、サポートするすべてのサービス上の暗号設定が妥当で、それぞれの機関 (PCI-DSS、DISA、STIG、NIST など) が定義する業界標準プラクティスに確実に従わなければなりません。

ユーザーや IT 部門にそのような専門知識があると想定できるでしょうか? 本質的にはできません。 逆に、ソフトウェアやシステムを設定する人はその分野の専門家であっても、暗号アルゴリズムの詳細の専門家ではないと仮定することで、より安全なシステムが得られると私たちは考えています。 とはいえ、既存および将来の攻撃によるリスクを軽減するには、システムが適切な暗号化設定で動作していることが不可欠です。 さらに、相互運用性を損なわない設定が必要であると同時に、保守的で広く受け入れられている標準に準拠し、問題となる可能性のある従来のプロトコルやアルゴリズムを排除する設定も必要です。

つまり、エンドユーザーまたは IT 部門が対処する責任があるとは考えられない設定上の問題が発生しています。 解決策の説明を続ける前に、このような設定ミスのリスクをより具体的に説明しましょう。

一貫性のない、または古くなった暗号ポリシーのリスクの大きさはどの程度ですか?

新機能により、ソフトウェアが継続的に強化されるにつれて、従来の機能が有効なままになることが多く、攻撃対象領域が継続的に拡大します。 その理由は複数あります。主な理由は、下位互換性を提供するために、多くの場合、アプリケーションの攻撃対象領域を減らすための主要なメカニズムがアプリケーション設定であることが考えられます。 この設定は、エンドユーザーまたはシステム管理者が利用できます。 実際には、前述したように、そのような決定をエンドユーザーやシステム管理者に委任することはあまり効果的ではありません。 必要なスキルセットがこのようなタスクにあったとしても、すべてのアプリケーションにアクセスして、最近の暗号化の進歩に基づいて構成をカスタマイズするのは非常に面倒な作業です。これは、実際には無視されることが多いタスクです。

その後、その注意の欠如により、攻撃者が拡大した攻撃対象領域を利用するリスクが増大します。 実際、最近では POODLE (2014)、FREAK (2015) または DROWN (2016) などの大きな影響を及ぼす攻撃がありました。これらの攻撃は、非推奨となったプロトコルとオプションを利用していました。たとえば、SSL2.0 や SSL3.0 などを利用して、最新かつ安全なプロトコルを使用しているとされるサーバーと同じサーバー上の関連性のないセッションへの攻撃が一部でありました。 その影響は、正確に評価するのは困難ではありますが、現代のシステムの信頼性に対する認識に打撃を与え、システムサービスにおける最新の一貫した暗号化ポリシーの必要性に対する警鐘となりました。

Red Hat Enterprise Linux はどのようにして一貫した暗号化ポリシーを提供しますか?

幸いなことに、RHEL 8 以降を使用している場合は、システム全体の暗号化ポリシーを使用して、これらの攻撃を防ぐことができます。 この一連のポリシーは、実行中のサービスに一貫して適用され、暗号化の進歩に対応するため、ソフトウェア更新の一部として最新の状態に保たれます。

さらに、デフォルトのポリシーとして選択されているのは保守的なポリシーであり、TLS 1.1 以前のバージョンなどの従来の通信プロトコルを無効にすることで、あらゆる種類の脅威を排除します。 同時に、古いシステムとの互換性や、PCI-DSS などの決済業界の要件を満たすために、選択したポリシーをより厳格にしたり緩くしたりするなど、ローカルの要件に合わせて設定を調整するオプションを提供します (crypto policy customization)。

既存の暗号化ポリシーは何をカバーしていますか?

暗号ポリシーは Red Hat Enterprise Linux のコンポーネントであり、TLS、IPSec、DNSSec、および Kerberos プロトコルをカバーするコア暗号化サブシステムを設定します。つまり、これは、ベースオペレーティングシステム上でサポートされている安全な通信プロトコルです。 これは、管理者が選択できる小さなポリシーのセットを提供します。デフォルトは、今日の脅威モデルに安全な設定を提供する保守的なポリシーです。 アプリケーションが RHEL で実行されると、アプリケーションはデフォルトまたは選択されたポリシーに従います。これは、ユーザーがアプリケーションに明示的に要求しない限り、ポリシーに含まれないアルゴリズムやプロトコルへのフォールバックを拒否します。 つまり、このポリシーは、システム提供の設定で実行されているアプリケーションのデフォルトの動作に適用されます。ただし、必要に応じてアプリケーション固有のベースでユーザーがオーバーライドできます。

例外:

• go 言語アプリケーションはまだシステム全体のポリシーに従っていません (今後の RHEL 8 リリースで対応予定)。
• libssh アプリケーションは、libssh-0.9.0-4.el81 以降のシステム全体のポリシーに従います。
• gnupg2 アプリケーションはシステム全体のポリシーに準拠していません。

提供されているポリシーはどれですか?

"LEGACY"、"DEFAULT"、"FUTURE"、および "FIPS" という名前で、4 つのポリシーが提供されます。 各ポリシーで利用可能な設定の詳細は、こちらのリンク先の記事 および update-crypto-policies の man ページにまとめられています。

暗号化ポリシーはどのように使用しますか?

以下に示すように、システムのポリシーは update-crypto-policies アプリケーションを使用して設定および照会できます。 update-crypto-policies ツールを使用して、実行中のシステムをデフォルトのポリシーからより厳密な FUTURE ポリシーに切り替えます。 このツールのオプションのより詳細な概要は、update-crypto-policies の man ページに記載されています。

$ update-crypto-policies --show
DEFAULT

# update-crypto-policies --set FUTURE
Setting system policy to FUTURE

このポリシーの変更後に開始されたサービスまたはアプリケーションは、新しいポリシーに切り替わります。

クライアントアプリケーションの例

上記の例では、依然として広く使用されている SHA-1 が許可されないモードにシステムを切り替えます。 次の例は、システムがそのアルゴリズムを禁止する FUTURE モードのときに、SHA-1 で署名された証明書を含むサーバーに接続しようとした結果を示しています。

# update-crypto-policies --set FUTURE
# yum install -y wget curl

$ wget https://sha1-intermediate.badssl.com
--2018-10-12 05:27:40--  https://sha1-intermediate.badssl.com
Resolving sha1-intermediate.badssl.com (sha1-intermediate.badssl.com)... 104.112.42.112
Connecting to sha1-intermediate.badssl.com (sha1-intermediate.badssl.com)|104.112.42.112|:443... connected.
ERROR: The certificate of ‘sha1-intermediate.badssl.com’ is not trusted.
ERROR: The certificate of ‘sha1-intermediate.badssl.com’ was signed using an insecure algorithm.



$ curl https://sha1-intermediate.badssl.com
curl: (60) SSL certificate problem: EE certificate key too weak
More details here: https://curl.haxx.se/docs/sslcerts.html

サーバーアプリケーションの例

上記の例では、両方のアプリケーションがそのサーバーへの接続を拒否しました。 これが RHEL 8 で実行されているサーバーにどのような影響を与えるかを見てみましょう。 次の例では、Apache Web サーバーをセットアップし、gnutls-cli TLS デバッグツールを使用して接続を試みます。 最初は、接続は TLS 1.3 がアドバタイズされたバージョンであるデフォルト設定を使用します。その後、サーバーの DEFAULT ポリシーで許可されていない TLS 1.1 プロトコルに切り替えるようにツールに指示します。

# update-crypto-policies --set DEFAULT
# yum module install -y httpd
# yum install -y gnutls-utils
# systemctl start httpd

$ gnutls-cli localhost --insecure </dev/null
...
- Description: (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
- Ephemeral EC Diffie-Hellman parameters
 - Using curve: SECP256R1
 - Curve size: 256 bits
- Version: TLS1.3
- Server Signature: RSA-PSS-RSAE-SHA256
- Cipher: AES-256-GCM
- MAC: AEAD
- Options:
- Handshake was completed

最初の接続試行は成功しました。 次に、クライアントによってアドバタイズされる唯一のバージョンである TLS 1.1 を使用して接続してみます。

$ gnutls-cli localhost --insecure --priority "NORMAL:-VERS-ALL:+VERS-TLS1.1" </dev/null
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [70]: Error in protocol version
*** handshake has failed: A TLS fatal alert has been received.

これにより、サーバーの DEFAULT ポリシーによって禁止されているオプションに制限されているクライアントは、TLS 警告メッセージを通じて通知され、接続が閉じられることがわかります。

まとめ

上記の例では、クライアントアプリケーションとサーバーアプリケーションの両方がシステム全体の暗号化ポリシーを尊重していることがわかります。これにより、Red Hat Enterprise Linux システムのデフォルトインストールのセキュリティーバーが増加します。しかし、これだけでなく、さらに重要なことに、暗号化アルゴリズムとプロトコルの適切な設定を決定するという、管理者のタスクが軽減されます。