第2章 暗号化および鍵管理
デバイス間通信は、セキュリティー上の重大な問題です。Heartbleed などの重大な脆弱性や、BEAST や CRIME などのより高度な攻撃に見られるように、ネットワーク上での安全な通信手段はますます重要になっています。しかし、暗号化は、より大きなセキュリティー戦略の一部に過ぎません。エンドポイントが侵害されると、攻撃者は使用されている暗号を解読する必要がなくなり、システムで処理されるメッセージを閲覧したり操作したりすることができるようになります。
本章では、TLS (Transport Layer Security) を設定して社内外のリソースを保護するための機能を確認し、特に注意すべきシステムのカテゴリーを紹介します。
OpenStack のコンポーネントは、様々なプロトコルを使用して相互に通信しますが、その通信には機密データが含まれる場合があります。攻撃者は、機密情報にアクセスするために、チャネルを盗聴しようとするかもしれません。そのため、すべてのコンポーネントが安全な通信プロトコルを使用して相互に通信することが重要です。
2.1. TLS と SSL の概要
OpenStack の導入において、ネットワークトラフィックの機密性や完全性を保証するためのセキュリティー要件が必要となる場合があります。一般的には、TLS プロトコルなどの暗号化手段を用いて設定します。一般的な導入では、パブリックネットワークを介して送信されるすべてのトラフィックをセキュリティーで強化する必要がありますが、セキュリティーのグッドプラクティスでは、内部トラフィックもセキュリティーで保護されなければならないと考えられています。セキュリティーゾーンの分離に頼った保護では不十分です。攻撃者がハイパーバイザーやホストのリソースにアクセスしたり、API エンドポイントを侵害したり、その他のサービスにアクセスした場合は、メッセージやコマンドを簡単に注入したりキャプチャしたり、クラウドの管理機能に影響を与えたりすることができないようにする必要があります。
管理ゾーンのサービスやサービス内通信を含め、すべてのゾーンを TLS でセキュリティー強化する必要があります。TLS は、OpenStack サービスへのユーザー通信、および OpenStack サービスとサービスの間で、認証、否認防止、機密性、および完全性を確保するメカニズムを提供します。
SSL (Secure Sockets Layer) プロトコルの脆弱性が公開されているため、SSL よりも TLS 1.2 以上の使用を検討し、旧式のブラウザーやライブラリーとの互換性が必要な場合を除き、すべてのケースで SSL を無効にしてください。
2.1.1. 公開鍵インフラストラクチャー
PKI (Public Key Infrastructure) とは、データや認証を保護するための暗号化アルゴリズム、暗号モード、プロトコルを提供するためのフレームワークです。これは、当事者の身元を確認しながら、トラフィックを確実に暗号化して送信するための一連のシステムとプロセスで設定されています。ここで説明する PKI プロファイルは、PKIX ワーキンググループによって開発された Internet Engineering Task Force (IETF) の Public Key Infrastructure (PKIX) プロファイルです。PKI の中核となるコンポーネントは以下の通りです。
- デジタル証明書 - 署名入り公開鍵証明書は、エンティティーの検証可能なデータ、その公開鍵、およびその他の属性を持つデータ構造です。これらの証明書は、認証局 (CA) によって発行されます。証明書は信頼できる CA によって署名されているため、一度検証されれば、エンティティーに関連付けられた公開鍵は、当該エンティティーに関連付けられていることが保証されます。これらの証明書を定義するための最も一般的な規格は、X.509 規格です。現在の標準である X.509 v3 は、RFC5280 に詳細が記載されており、RFC6818 で更新されています。証明書は、オンラインエンティティーのアイデンティティを証明する仕組みとして、CA によって発行されます。CA は、証明書からメッセージダイジェストを作成し、そのダイジェストを自分の秘密鍵で暗号化することで、証明書にデジタル署名します。
- エンドエンティティー - 証明書の対象となるユーザー、プロセス、またはシステム。エンドエンティティーは、その証明書要求を登録機関 (RA) に送り、承認を得ます。承認された場合、RA は要求を認証局 (CA) に転送します。認証局はリクエストを検証し、情報が正しければ証明書を生成して署名します。この署名された証明書は、証明書レポジトリに送られます。
- 依拠当事者 - 証明書に記載されている公開鍵を参照して検証可能なデジタル署名された証明書を受け取ったエンドポイント。依拠当事者は、チェーン上の証明書を検証し、CRL に存在しないことを確認し、また、証明書の有効期限を検証できる立場にある必要があります。
- 認証局 (CA) - CA は、認証ポリシー、管理処理、および証明書の発行において、エンドパーティと、証明書に依存するパーティの両方から信頼されるエンティティーです。
- RA (REgistration Authority): CA が特定の管理機能を委譲するオプションのシステムです。これには、CA が証明書を発行する前の、エンドエンティティーの認証などの機能が含まれます。
- 証明書失効リスト (Certificate Revocation List、CRL): 証明書失効リスト (CRL) は、失効した証明書シリアル番号の一覧です。これらの証明書を表示するエンティティーは、PKI モデルでは信頼できません。たとえば、鍵が不正アクセスし、CA 侵害などの理由によって失効が発生することがあります。
- CRL 発行者: CA が証明書失効リストの公開を委譲するオプションのシステム。
- 証明書リポジトリー: エンドエンティティー証明書および証明書失効リストが保存され、クエリーされる場所 (証明書バンドルと呼ばれることもあります)。
API エンドポイント用の TLS の使用を含め、セキュリティーで公開鍵インフラストラクチャー (PKI) を使用してすべてのサービスを強化することが強く推奨されます。これらの問題すべてを解決するには、暗号化またはメッセージの署名だけでは不可能です。さらに、ホスト自体は強化され、ポリシー、名前空間、およびその他のコントロールを実装して、プライベートの認証情報および鍵を保護する必要があります。ただし、キー管理および保護の課題は、これらの制御の必要性が低くなったり、それらの重要度が低下することはありません。
2.1.2. 認証局
多くの組織には、独自の認証局 (CA)、証明書ポリシー、および内部 OpenStack ユーザーまたはサービスの証明書を発行するのに使用する公開鍵インフラストラクチャーが確立されています。パブリックセキュリティーゾーンがインターネットに接続される組織には、一般に認識されるパブリック CA によって署名された証明書が必要です。管理ネットワークを介した暗号化通信には、パブリック CA を使用しないことが推奨されます。その代わりに、ほとんどのデプロイメントでは独自の内部 CA をデプロイすることが推奨されます。
TLS の効果的な使用では、DNS のドメインまたはサブドメインが付与されたデプロイメントに依存します。これはワイルドカードまたは内部 CA のいずれかで使用できる、または一連の特定証明書の問題です。TLS 証明書を効果的に検証できるようにするには、プラットフォームサービスへのアクセスは、これらの DNS レコードを通じて行う必要があります。
OpenStack クラウドアーキテクトは、内部システムおよび顧客がアクセスするサービス用に別の PKI デプロイメントを使用することを検討することを推奨します。これにより、クラウドデプロイヤーが PKI インフラストラクチャーの制御を維持でき、内部システムの証明書の要求、署名、デプロイが容易になります。高度な設定では、異なるセキュリティーゾーンに別の PKI デプロイメントを使用する場合があります。これにより、OpenStack のオペレーターは環境の暗号化の分離を維持でき、発行された証明書が別の方法で認識されないようにします。
インターネット向けのクラウドエンドポイント (またはお客様が標準オペレーティングシステムが提供する証明書バンドル以外のインストールを期待しない) で TLS をサポートするために使用される証明書は、オペレーティングシステムの証明書バンドルにインストールされている認証局を使用してプロビジョニングする必要があります。
証明書の作成および署名に関する管理、ポリシー、および技術的な課題があります。これは、クラウドアーキテクトまたはオペレーターが推奨するガイダンスに加えて、業界のリーダーとベンダーのアドバイスを求めたい領域です。
2.1.3. director を使用した暗号化の設定
デフォルトでは、オーバークラウドはサービスに暗号化されていないエンドポイントを使用します。これは、オーバークラウドの設定に、パブリック API エンドポイントに SSL/TLS を有効化するための追加の環境ファイルが必要であることを意味します。オーバークラウドの高度なカスタマイズ には、SSL/TLS 証明書を設定して、オーバークラウドの作成プロセスの一部として追加する方法を説明します。
2.1.4. TLS ライブラリー
OpenStack エコシステム内の一部のコンポーネント、サービス、およびアプリケーションは TLS ライブラリーを使用するように設定できます。OpenStack 内の TLS および HTTP サービスは、通常、FIPS 140-2 で検証されているモジュールが含まれる OpenSSL を使用して実装されます。ただし、各アプリケーションまたはサービスは、OpenSSL ライブラリーを使用する方法においても脆弱点が発生することを考慮してください。
2.1.5. TLS 1.0 が非推奨に
FedRAMP 認可システムは、TLS 1.0 から離れる必要があります。推奨されるレベルは 1.2 で、幅広い互換性が必要な場合に 1.1 を使用できます。詳細は、https://www.fedramp.gov/assets/resources/documents/CSP_TLS_Requirements.pdf を参照してください。
Red Hat OpenStack Platform 13 デプロイメントでは、HAProxy によって TLS 1.0 接続が許可されません。これにより、TLS 対応の API の TLS 接続を処理します。これは、no-tlsv10 オプションで実装されます。InternalTLS が有効な HA デプロイメントでは、コントローラープレーン上のノード間のトラフィックも暗号化されます。これには、RabbitMQ、MariaDB、Redis などがあります。MariaDB と Redis の TLS1.0 が非推奨になり、RabbitMQ の非推奨化がアップストリームからバックポートされることが予想されます。
2.1.5.1. TLS 1.0 が使用されているかどうかを確認する
cipherscan を使用して、TLS 1.0 がデプロイメントで提示されているかどうかを判断できます。暗号スキャンは、https://github.com/mozilla/cipherscan からクローンできます。この出力例は、horizon から受信した結果を示しています。
実稼働以外のシステムから cipherscan を実行すると、初回実行時に追加の依存関係をインストールする場合があるためです。
$ ./cipherscan https://openstack.lab.local .............................. Target: openstack.lab.local:443 prio ciphersuite protocols pfs curves 1 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 ECDH,P-256,256bits prime256v1 2 ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 ECDH,P-256,256bits prime256v1 3 DHE-RSA-AES128-GCM-SHA256 TLSv1.2 DH,1024bits None 4 DHE-RSA-AES256-GCM-SHA384 TLSv1.2 DH,1024bits None 5 ECDHE-RSA-AES128-SHA256 TLSv1.2 ECDH,P-256,256bits prime256v1 6 ECDHE-RSA-AES256-SHA384 TLSv1.2 ECDH,P-256,256bits prime256v1 7 ECDHE-RSA-AES128-SHA TLSv1.2 ECDH,P-256,256bits prime256v1 8 ECDHE-RSA-AES256-SHA TLSv1.2 ECDH,P-256,256bits prime256v1 9 DHE-RSA-AES128-SHA256 TLSv1.2 DH,1024bits None 10 DHE-RSA-AES128-SHA TLSv1.2 DH,1024bits None 11 DHE-RSA-AES256-SHA256 TLSv1.2 DH,1024bits None 12 DHE-RSA-AES256-SHA TLSv1.2 DH,1024bits None 13 ECDHE-RSA-DES-CBC3-SHA TLSv1.2 ECDH,P-256,256bits prime256v1 14 EDH-RSA-DES-CBC3-SHA TLSv1.2 DH,1024bits None 15 AES128-GCM-SHA256 TLSv1.2 None None 16 AES256-GCM-SHA384 TLSv1.2 None None 17 AES128-SHA256 TLSv1.2 None None 18 AES256-SHA256 TLSv1.2 None None 19 AES128-SHA TLSv1.2 None None 20 AES256-SHA TLSv1.2 None None 21 DES-CBC3-SHA TLSv1.2 None None Certificate: trusted, 2048 bits, sha256WithRSAEncryption signature TLS ticket lifetime hint: None NPN protocols: None OCSP stapling: not supported Cipher ordering: server Curves ordering: server - fallback: no Server supports secure renegotiation Server supported compression methods: NONE TLS Tolerance: yes Intolerance to: SSL 3.254 : absent TLS 1.0 : PRESENT TLS 1.1 : PRESENT TLS 1.2 : absent TLS 1.3 : absent TLS 1.4 : absent
サーバーのスキャン時に、Cipherscan インターバリーが、ネゴシエートする最大の TLS バージョンである特定の TLS バージョンのサポートをアドバータイズします。ターゲットサーバーが TLS プロトコルを正しく従うと、相互に対応している最新バージョンで応答します。これは、最初にアドバータイズされた Cipherscan よりも低くなる可能性があります。サーバーが特定のバージョンを使用するクライアントとの接続を確立し続けると、そのプロトコルバージョンに対する耐性があるとみなされません。(指定されたバージョンまたは下位バージョンを使用する) 接続を確立しない場合は、そのバージョンのプロトコルの耐性があることが考慮されます。以下に例を示します。
Intolerance to: SSL 3.254 : absent TLS 1.0 : PRESENT TLS 1.1 : PRESENT TLS 1.2 : absent TLS 1.3 : absent TLS 1.4 : absent
この出力では、TLS 1.0 および TLS 1.1 のイントレランスは PRESENT として報告されます。これは、接続を確立できず、その Cipherscan がこれらの TLS バージョンのアドバタイズメントサポート中に接続できなかったことを意味します。そのため、スキャンされたサーバーでプロトコルの (およびそれより低い) バージョンが有効ではないことを確認する必要があります。
2.1.6. 暗号化アルゴリズム、暗号モード、およびプロトコル
TLS 1.2 のみを使用することを検討してください。TLS 1.0 や 1.1 などのその他のバージョンは複数の攻撃に対して脆弱であり、多くの政府機関や規制対象者によって表現的に禁止されています。お使いの環境で TLS 1.0 を無効にする必要があります。TLS 1.1 は幅広いクライアント互換性に使用される場合がありますが、このプロトコルを有効にする際には注意が必要です。互換性要件が必須で、関係するリスクを認識している場合は、TLS バージョン 1.1 を有効にします。すべてのバージョンの SSL (TLS への前提条件) は、複数のパブリック脆弱性により使用すべきではありません。
TLS 1.2 を使用し、クライアントとサーバーの両方を制御する場合、暗号スイートは ECDHE-ECDSA-AES256-GCM-SHA384 に制限される必要があります。エンドポイントの両方を制御しておらず、TLS 1.1 または 1.2 を使用している場合、より一般的な HIGH:!aNULL:!eNULL:!DES:!3DES:!SSLv3:!TLSv1:!CAMELLIA は、妥当な暗号選択です。
本ガイドは暗号化の参照として意図されておらず、OpenStack サービスで有効化または無効化する必要のある特定のアルゴリズムまたは暗号モードに関する規定はありません。
