Einführung in TLS und SSL¶
Es gibt Situationen, in denen es eine Sicherheitsanforderung gibt, um die Vertraulichkeit oder Integrität des Netzwerkverkehrs in einer OpenStack-Bereitstellung zu gewährleisten. Dies wird in der Regel mit kryptographischen Maßnahmen wie dem Transport Layer Security (TLS) Protokoll erreicht.
In einer typischen Bereitstellung ist der gesamte über die öffentlichen Netze übertragene Verkehr gesichert, aber die Best Practice der Sicherheit bestimmt, dass der interne Verkehr auch gesichert werden muss. Es genügt nicht, sich auf die Sicherheitsdomänen-Trennung für den Schutz zu verlassen. Wenn ein Angreifer Zugang zu den Hypervisor- oder Host-Ressourcen erhält, kompromittiert er einen API-Endpunkt oder einen anderen Dienst, so dass sie nicht in der Lage sind, Nachrichten, Befehle oder sonstige Auswirkungen auf die Verwaltungsfunktionen der Cloud zu erfassen oder zu erfassen.
Alle Domains sollten mit TLS gesichert werden, einschließlich der Management-Domain-Services und Intra-Service-Kommunikation. TLS stellt die Mechanismen zur Verfügung, um die Authentifizierung, Nicht-Ablehnung, Vertraulichkeit und Integrität der Benutzer-Kommunikation zu den OpenStack-Diensten und zwischen den OpenStack-Diensten selbst zu gewährleisten.
Aufgrund der veröffentlichten Sicherheitslücken in den SSL-Protokollen (Secure Sockets Layer) empfiehlt es sich dringend, dass TLS bevorzugt in SSL verwendet wird und dass SSL in allen Fällen deaktiviert ist, es sei denn, Kompatibilität mit veralteten Browsern oder Bibliotheken ist erforderlich.
Public Key Infrastructure (PKI) ist der Rahmen für die Sicherung der Kommunikation in einem Netzwerk. Es besteht aus einer Reihe von Systemen und Prozessen, um sicherzustellen, dass der Verkehr sicher während der Validierung der Identität der Parteien gesendet werden kann. Das hier beschriebene PKI-Profil ist das von der PKIX-Arbeitsgruppe entwickelte Internet Engineering Task Force (IETF) Public Key Infrastructure (PKIX) Profil. Die Kernkomponenten der PKI sind:
- Digitale Zertifikate
Signierte Public-Key-Zertifikate sind Datenstrukturen, die nachvollziehbare Daten einer Entität, ihren öffentlichen Schlüssel zusammen mit einigen anderen Attributen haben. Diese Zertifikate werden von einer Zertifizierungsstelle (CA) ausgestellt. Da die Zertifikate von einer Zertifizierungsstelle unterzeichnet werden, die vertrauenswürdig ist, wird ein einmal verifizierter öffentlicher Schlüssel, der mit dem Unternehmen verknüpft ist, mit der Entität verbunden. Der häufigste Standard für die Festlegung dieser Zertifikate ist der Begriff: X.509 Standard. Der X.509 v3, der der aktuelle Standard ist, ist ausführlich in` RFC5280 beschrieben <http://tools.ietf.org/html/5280>`_. Zertifikate werden von CAs als Mechanismus ausgestellt, um die Identität von Online-Einheiten nachzuweisen. Die CA unterschreibt das Zertifikat digital, indem sie eine Nachricht aus dem Zertifikat erstellt und den Digest mit seinem privaten Schlüssel verschlüsselt.
- Ende Entität
Benutzer, Prozess oder System, das Gegenstand eines Zertifikats ist. Die Endentität sendet ihre Zertifikatsanforderung an eine Registrierungsstelle (RA) zur Genehmigung. Wenn sie zugelassen ist, leitet die RA die Anfrage an eine Zertifizierungsstelle (CA) weiter. Die Zertifizierungsstelle prüft die Anfrage und wenn die Informationen korrekt sind, wird ein Zertifikat generiert und signiert. Dieses signierte Zertifikat wird dann an ein Zertifikats-Repository gesendet.
- Beteiligte Parteien
Der Endpunkt, der das digital signierte Zertifikat erhält, das mit Bezug auf den im Zertifikat aufgelisteten öffentlichen Schlüssel verifizierbar ist. Die verlassende Partei sollte in der Lage sein, die Bescheinigung über die Kette zu überprüfen, sicherzustellen, dass sie nicht in der: term: CRL vorhanden ist und auch in der Lage sein muss, das Verfallsdatum auf dem Zertifikat zu überprüfen.
- Zertifizierungsstelle (CA)
CA ist eine vertrauenswürdige Entität, sowohl von der Endpartei als auch von der Partei, die auf dem Zertifikat für Zertifizierungsrichtlinien, Managementabwicklung und Zertifikatsausgabe beruht.
- Registrierungsstelle (RA)
Ein optionales System, zu dem eine CA bestimmte Verwaltungsfunktionen delegiert, beinhaltet dies Funktionen wie die Authentifizierung von Endentitäten, bevor sie ein Zertifikat von einer CA ausgestellt haben.
- Certificate Revocation Lists (CRL)
Eine Zertifikatsperrliste (CRL) ist eine Liste der Zertifikats-Seriennummern, die widerrufen wurden. Endentitäten, die diese Zertifikate vorstellen, sollten nicht in einem PKI-Modell vertraut werden. Widerruf kann passieren aus mehreren Gründen passieren, zum Beispiel Schlüsselkompromiss, CA Kompromiss.
- CRL-Emittent
Ein optionales System, an das eine CA die Veröffentlichung von Zertifikatssperrlisten delegiert.
- Zertifikat-Repository
Hier werden die endgültigen Zertifikate und Zertifikatssperrlisten gespeichert und nachgeschlagen - manchmal auch als certificate bundle bezeichnet.
PKI baut das Framework auf, auf dem Verschlüsselungsalgorithmen, Chiffriermodi und Protokolle zur Sicherung von Daten und Authentifizierung bereitgestellt werden können. Wir empfehlen dringend, alle Dienste mit Public Key Infrastructure (PKI) zu sichern, einschließlich der Verwendung von TLS für API Endpunkte. Es ist unmöglich für die Verschlüsselung oder Signierung von Transporten oder Nachrichten allein, um alle diese Probleme zu lösen. Hosts selbst müssen sicher sein und implementieren Policy, Namespaces und andere Steuerelemente, um ihre privaten Anmeldeinformationen und Schlüssel zu schützen. Allerdings reduzieren die Herausforderungen der Schlüsselverwaltung und des Schutzes nicht die Notwendigkeit dieser Kontrollen oder verringern ihre Bedeutung.
TLS-Bibliotheken¶
Komponenten, Services und Anwendungen innerhalb des OpenStack-Ökosystems oder Abhängigkeiten von OpenStack werden implementiert oder können für die Verwendung von TLS-Bibliotheken konfiguriert werden. Die TLS- und HTTP-Dienste in OpenStack werden in der Regel mit OpenSSL implementiert, die über ein Modul verfügt, das für FIPS 140-2 validiert wurde. Beachten Sie jedoch, dass jede Anwendung oder jede Dienstleistung immer noch Schwächen einführen kann, wie sie die OpenSSL-Bibliotheken verwenden.
Kryptographische Algorithmen, Chiffriermodi und Protokolle¶
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.
Wenn Sie TLS 1.2 verwenden und sowohl die Clients als auch den Server steuern, sollte die Verschlüsselungssuite auf „ECDHE-ECDSA-AES256-GCM-SHA384“ beschränkt sein. In Situationen, in denen Sie beide Endpunkte nicht kontrollieren und TLS 1.1 oder 1.2 verwenden, ist die allgemeinere `` HIGH:! ANULL:! ENULL:! DES:! 3DES:! SSLv3:! TLSv1:! CAMELLIA`` eine vernünftige Verschlüsselungsauswahl .
Jedoch, da dieses Buch nicht beabsichtigt, eine gründliche Bezugnahme auf die Kryptographie zu sein, möchten wir nicht vorschreiben, welche spezifischen Algorithmen oder Chiffrierungsmodi Sie in Ihren OpenStack-Diensten aktivieren oder deaktivieren sollten. Es gibt einige maßgebliche Referenzen, die wir für weitere Informationen empfehlen möchten:
Zusammenfassung¶
Angesichts der Komplexität der OpenStack-Komponenten und der Anzahl der Bereitstellungsmöglichkeiten müssen Sie darauf achten, dass jede Komponente die entsprechende Konfiguration von TLS-Zertifikaten, Schlüsseln und CAs erhält. Nachfolgende Abschnitte behandeln folgende Leistungen:
Compute API-Endpunkte
Identity-API-Endpunkte
Netzwerk-API-Endpunkte
Speicher-API-Endpunkte
Messaging-Server
Datenbankserver
Dashboard