TLS と SSL の導入

There are situations where there is a security requirement to assure the confidentiality or integrity of network traffic in an OpenStack deployment. This is generally achieved using cryptographic measures, such as the Transport Layer Security (TLS) protocol.

In a typical deployment all traffic transmitted over public networks is secured, but security best practice dictates that internal traffic must also be secured. It is insufficient to rely on security domain separation for protection. If an attacker gains access to the hypervisor or host resources, compromises an API endpoint, or any other service, they must not be able to easily inject or capture messages, commands, or otherwise affect the management capabilities of the cloud.

All domains should be secured with TLS, including the management domain services and intra-service communications. TLS provides the mechanisms to ensure authentication, non-repudiation, confidentiality, and integrity of user communications to the OpenStack services and between the OpenStack services themselves.

Due to the published vulnerabilities in the Secure Sockets Layer (SSL) protocols, we strongly recommend that TLS is used in preference to SSL, and that SSL is disabled in all cases, unless compatibility with obsolete browsers or libraries is required.

Public Key Infrastructure (PKI) is the framework for securing communication in a network. It consists of a set of systems and processes to ensure traffic can be sent securely while validating the identity of the parties. The PKI profile described here is the Internet Engineering Task Force (IETF) Public Key Infrastructure (PKIX) profile developed by the PKIX working group. The core components of PKI are:

Digital Certificates

Signed public key certificates are data structures that have verifiable data of an entity, its public key along with some other attributes. These certificates are issued by a Certificate Authority (CA). As the certificates are signed by a CA that is trusted, once verified, the public key associated with the entity is guaranteed to be associated with the said entity. The most common standard used to define these certificates is the X.509 standard. The X.509 v3 which is the current standard is described in detail in RFC5280. Certificates are issued by CAs as a mechanism to prove the identity of online entities. The CA digitally signs the certificate by creating a message digest from the certificate and encrypting the digest with its private key.

エンドエンティティ

User, process, or system that is the subject of a certificate. The end entity sends its certificate request to a Registration Authority (RA) for approval. If approved, the RA forwards the request to a Certification Authority (CA). The Certification Authority verifies the request and if the information is correct, a certificate is generated and signed. This signed certificate is then send to a Certificate Repository.

信頼機関

The endpoint that receives the digitally signed certificate that is verifiable with reference to the public key listed on the certificate. The relying party should be in a position to verify the certificate up the chain, ensure that it is not present in the CRL and also must be able to verify the expiry date on the certificate.

Certification Authority (CA)

CA is a trusted entity, both by the end party and the party that relies upon the certificate for certification policies, management handling, and certificate issuance.

登録局 (RA)

An optional system to which a CA delegates certain management functions, this includes functions such as, authentication of end entities before they are issued a certificate by a CA.

Certificate Revocation Lists (CRL)

A Certificate Revocation List (CRL) is a list of certificate serial numbers that have been revoked. End entities presenting these certificates should not be trusted in a PKI model. Revocation can happen because of several reasons for example, key compromise, CA compromise.

CRL issuer

An optional system to which a CA delegates the publication of certificate revocation lists.

Certificate Repository

End Entity が証明され、証明書の廃止リストが保存・参照される場所 - 時々 証明バンドル(Certificate bundle) と呼ばれます。

PKIはデータと認証をセキュアにする暗号アルゴリズム、暗号モード(cipher mode)、プロトコルの フレームワークをバンドルしています。APIエンドポイントの為のTLS 使用を含み、Public Key Infrastructure (PKI)を用いて、全サービスをセキュアにする事をお勧めします。暗号化や通信路・メッセージの署名の為に、これら全ての問題を解決する事は重要です。プライベート証明と鍵の保護の為、ホスト自身がセキュアで、ポリシー、ネームスペース、その他の制御を実装しなければなりません。しかし、キー管理や保護のチャレンジはこれらの制御の必要性を削減したり、その重要性を失ったりはしません。

認証局(CA)

Many organizations have an established Public Key Infrastructure with their own Certification Authority (CA), certificate policies, and management for which they should use to issue certificates for internal OpenStack users or services. Organizations in which the public security domain is Internet facing will additionally need certificates signed by a widely recognized public CA. For cryptographic communications over the management network, it is recommended one not use a public CA. Instead, we expect and recommend most deployments deploy their own internal CA.

OpenStackクラウドアーキテクトには、内部のシステムと顧客が接するサービス用に、分断されたPKIデプロイの使用を検討する事をお勧めします。これは、クラウドをデプロイする人が他の物が内部のシステム用に証明書を要求・署名・デプロイする事を容易にするPKIインフラを制御できるようにします。異なる設定は異なるセキュリティドメイン用にPKIデプロイを分割使用しても構いません。これは、デプロイする人が環境の暗号の分断を管理できるようにし、一方で発行された証明書が他方で認証されない事を保証します。

Certificates used to support TLS on internet facing cloud endpoints (or customer interfaces where the customer is not expected to have installed anything other than standard operating system provided certificate bundles) should be provisioned using Certificate Authorities that are installed in the operating system certificate bundle. Typical well known vendors include Let's Encrypt, Verisign and Thawte but many others exist.

There are management, policy, and technical challenges around creating and signing certificates. This is an area where cloud architects or operators may wish to seek the advice of industry leaders and vendors in addition to the guidance recommended here.

TLS ライブラリー

Components, services, and applications within the OpenStack ecosystem or dependencies of OpenStack are implemented or can be configured to use TLS libraries. The TLS and HTTP services within OpenStack are typically implemented using OpenSSL which has a module that has been validated for FIPS 140-2. However, keep in mind that each application or service can still introduce weaknesses in how they use the OpenSSL libraries.

暗号化アルゴリズム、暗号モード、プロトコル

We recommend that a minimum of TLS 1.2 be used. Older versions such as TLS 1.0, 1.1, and all versions of SSL (TLS's predecessor) are vulnerable to multiple publicly known attacks and therefore must not be used. TLS 1.2 may be used for broad client compatibility, however exercise caution when enabling this protocol. Only enable TLS version 1.1 if there is a mandatory compatibility requirement and you are aware of the risks involved.

When you are using TLS 1.2 and control both the clients and the server, the cipher suite should be limited to ECDHE-ECDSA-AES256-GCM-SHA384. In circumstances where you do not control both endpoints and are using TLS 1.1 or 1.2 the more general HIGH:!aNULL:!eNULL:!DES:!3DES:!SSLv3:!TLSv1:!CAMELLIA is a reasonable cipher selection.

However, as this book does not intend to be a thorough reference on cryptography we do not wish to be prescriptive about what specific algorithms or cipher modes you should enable or disable in your OpenStack services. There are some authoritative references we would like to recommend for further information:

• National Security Agency, Suite B Cryptography

• OWASP Guide to Cryptography

• OWASP Transport Layer Protection Cheat Sheet

• SoK: SSL and HTTPS: Revisiting past challenges and evaluating certificate trust model enhancements

• The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software

• OpenSSL and FIPS 140-2

概要

OpenStack コンポーネントの複雑さとデプロイの発展性を考慮すると、確実に各コンポーネントがTLS証明書・鍵・CAを適切に設定されている事に注意を払う必要があります。以下のサービスは、本書の後の章で議論します。

• Compute APIエンドポイント

• Identity APIエンドポイント

• Networking APIエンドポイント

• ストレージAPIエンドポイント

• メッセージングサーバー

• データベースサーバー

• Dashboard