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.

Zertifizierungsstellen

Viele Organisationen verfügen über eine etablierte Public Key Infrastructure mit einer eigenen Zertifizierungsstelle (CA), Zertifikatsrichtlinien und Management, für die sie Zertifikate für interne OpenStack-Benutzer oder -Dienste ausstellen sollen. Organisationen, in denen die public Sicherheits-Domain zum Internet gerichtet ist, benötigt zusätzlich von einer anerkannten öffentlichen CA unterzeichnete Zertifikate. Für die kryptografische Kommunikation über das Management-Netzwerk wird empfohlen, dass man keine öffentliche CA verwendet. Stattdessen erwarten wir und empfehlen den meisten Bereitstellungen, ihre eigene interne CA bereitzustellen.

Es empfiehlt sich, dass der OpenStack Cloud Architekt die Verwendung von separaten PKI-Implementierungen für interne Systeme und Kundenbereitstellung berücksichtigt. Damit kann der Cloud-Deployer die Kontrolle über ihre PKI-Infrastruktur beibehalten und unter anderem das Anfordern, Signieren und Bereitstellen von Zertifikaten für interne Systeme erleichtern. Erweiterte Konfigurationen können separate PKI-Bereitstellungen für verschiedene Sicherheitsdomänen verwenden. Dies ermöglicht es den Mitarbeitern, eine kryptographische Trennung von Umgebungen aufrechtzuerhalten, um sicherzustellen, dass Zertifikate, die an eine Ausgabe ausgegeben werden, nicht von einem anderen erkannt werden.

Zertifikate, die zur Unterstützung von TLS im Internet mit Cloud-Endpunkten (oder Kundenschnittstellen, bei denen der Kunde nicht erwartet wird, dass es andere als Standard-Betriebssystem-bereitgestellte Zertifikatsbündel installiert hat) unterstützt werden, sollten mit Zertifikatsautoritäten bereitgestellt werden, die im Betriebssystem-Zertifikatsbündel installiert sind. Typische bekannte Anbieter sind Let’s Encrypt, Verisign und Thawte, aber viele andere existieren.

Es gibt Management-, Politik- und technische Herausforderungen bei der Erstellung und Signierung von Zertifikaten. Dies ist ein Bereich, in dem Cloud-Architekten oder Betreiber vielleicht den Rat von Branchenführern und Anbietern zusätzlich zu den hier empfohlenen Anleitungen suchen möchten.

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