Sichere Referenzarchitekturen

Wir empfehlen die Verwendung von SSL/TLS in öffentlichen Netzwerken und Management-Netzwerken in TLS-Proxies und HTTP-Dienste. Allerdings, wenn die Bereitstellung von SSL/TLS überall zu schwierig ist, empfehlen wir Ihnen, Ihre OpenStack SSL/TLS-Anforderungen zu bewerten und einer der hier besprochenen Architekturen zu folgen.

Das erste, was man bei der Auswertung ihrer OpenStack SSL/TLS-Bedürfnisse tun sollte, ist, die Bedrohungen zu identifizieren. Sie können diese Bedrohungen in externe und interne Angreiferkategorien aufteilen, aber die Linien neigen dazu, verschwommen zu werden, da bestimmte Komponenten von OpenStack sowohl im öffentlichen als auch im Managementnetz betrieben werden.

Für öffentlich zugängliche Dienstleistungen sind die Bedrohungen ziemlich einfach. Die Benutzer werden sich gegen den Horizon und den Keystone mit ihrem Benutzernamen und Passwort benennen. Benutzer werden auch Zugriff auf die API-Endpunkte für andere Dienste mit ihren Keystone-Token haben. Wenn dieser Netzwerkverkehr unverschlüsselt ist, können Passwörter und Token von einem Angreifer mit einem Man-in-the-Middle-Angriff abgefangen werden. Der Angreifer kann dann diese gültigen Anmeldeinformationen verwenden, um böswillige Operationen durchzuführen. Alle realen Einsätze sollten SSL/TLS verwenden, um öffentlich zugängliche Dienstleistungen zu schützen.

Für Dienste, die in Verwaltungsnetzwerken eingesetzt werden, sind die Bedrohungen aufgrund der Überbrückung von Sicherheitsdomänen mit Netzwerksicherheit nicht so klar. Es besteht immer die Chance, dass ein Administrator mit Zugang zum Management-Netzwerk entscheidet, etwas Bösartiges zu tun. SSL/TLS wird in dieser Situation nicht helfen, wenn der Angreifer auf den privaten Schlüssel zugreifen darf. Nicht jeder auf dem Management-Netzwerk wäre erlaubt, auf den privaten Schlüssel natürlich zuzugreifen, also gibt es immer noch Wert bei der Verwendung von SSL/TLS, um sich vor internen Angreifern zu schützen. Auch wenn jeder, der auf Ihr Management-Netzwerk zugreifen darf, 100% vertraut ist, besteht immer noch die Bedrohung, dass ein nicht autorisierter Benutzer Zugriff auf Ihr internes Netzwerk erhält, indem er eine Fehlkonfiguration oder Software-Schwachstelle ausnutzt. Man muss bedenken, dass Sie Benutzer haben, die ihren eigenen Code auf Instanzen in den OpenStack Compute-Knoten ausführen, die im Management-Netzwerk bereitgestellt werden. Wenn eine Sicherheitsanfälligkeit es ihnen ermöglicht, aus den Hypervisor auszubrechen, haben sie Zugriff auf Ihr Management-Netzwerk. Mit SSL/TLS auf dem Management-Netzwerk kann der Schaden minimiert werden, den ein Angreifer verursachen kann.

SSL/TLS-Proxy vorne

Es ist allgemein anerkannt, dass es am besten ist, sensible Daten so früh wie möglich zu verschlüsseln und so spät wie möglich zu entschlüsseln. Trotz dieser bewährten Praxis scheint es, dass es üblich ist, einen SSL/TLS-Proxy vor den OpenStack-Diensten zu verwenden und nachher eine klare Kommunikation zu verwenden:

Einige der Bedenken mit der Verwendung von SSL/TLS Proxies wie oben abgebildet:

• Native SSL/TLS in OpenStack-Diensten werden nicht ausgeführt oder skaliert sowie SSL-Proxies (insbesondere für Python-Implementierungen wie Eventlet).

• Native SSL/TLS in OpenStack-Diensten sind nicht so gut untersucht/geprüft als bewährte Lösungen.

• Native SSL/TLS-Konfiguration ist schwierig (nicht gut dokumentiert, getestet oder konsistent über Services).

• Privilegentrennung (OpenStack-Serviceprozesse sollten keinen direkten Zugriff auf private Schlüssel für SSL/TLS haben).

• Traffic Inspektionsbedarf für Lastverteilung.

Alle oben genannten sind gültige Bedenken, aber keiner von ihnen verhindert, dass SSL/TLS im Management-Netzwerk verwendet wird. Betrachten wir das nächste Einsatzmodell.

SSL/TLS auf denselben physischen Hosts wie API-Endpunkte

Dies ist sehr ähnlich wie die SSL/TLS-Proxy vorne aber der SSL/TLS-Proxy befindet sich auf dem gleichen physischen System wie der API-Endpunkt. Der API-Endpunkt wäre so konfiguriert, dass er nur auf der lokalen Netzwerkschnittstelle hört. Alle Remote-Kommunikation mit dem API-Endpunkt würde durch den SSL/TLS-Proxy gehen. Mit diesem Einsatzmodell adressieren wir eine Reihe von Aufzählungspunkten in SSL/TLS-Proxy vorne Eine bewährte SSL-Implementierung, die gut funktioniert, würde verwendet werden. Die gleiche SSL-Proxy-Software würde für alle Dienste verwendet werden, so dass die SSL-Konfiguration für die API-Endpunkte konsistent sein würde. Die OpenStack-Serviceprozesse hätten keinen direkten Zugriff auf die privaten Schlüssel, die für SSL/TLS verwendet wurden, da Sie die SSL-Proxies als einen anderen Benutzer ausführen und den Zugriff mit Berechtigungen einschränken (und zusätzlich obligatorische Zugriffskontrollen mit SELinux). Wir hätten idealerweise die API-Endpunkte auf einen Unix-Socket zu hören, so dass wir den Zugriff darauf auch mit Berechtigungen und obligatorischen Zugriffskontrollen einschränken konnten. Leider scheint das derzeit nicht in Eventlet aus unserem Test zu arbeiten. Es ist ein gutes zukünftiges Entwicklungsziel.

SSL/TLS über Loadbalancer

Was ist mit Hochverfügbarkeit oder Lastausgleich, die den Verkehr kontrollieren müssen? Das vorherige Bereitstellungsmodell (secure-communication-proxy-on-same-physical-hosts-as-api-endpunkte) würde keine tiefe Paketprüfung ermöglichen, da der Verkehr verschlüsselt ist. Wenn der Verkehr nur für grundlegende Routingzwecke überprüft werden muss, ist es möglicherweise nicht erforderlich, dass der Load Balancer Zugriff auf den unverschlüsselten Verkehr hat. HAProxy hat die Fähigkeit, die SSL/TLS-Sitzungs-ID während des Handshakes zu extrahieren, die dann verwendet werden kann, um Sitzungs-Affinität zu erreichen (Session ID-Konfigurationsdetails hier). HAProxy kann auch die TLS Server Name Indication (SNI) Erweiterung verwenden, um festzustellen, wo der Verkehr weitergeleitet werden soll (SNI Konfigurationsdetails hier). Diese Merkmale decken wahrscheinlich einige der häufigsten Lastenausgleicherbedürfnisse ab. HAProxy wäre in der Lage, den HTTPS-Verkehr direkt in die API-Endpunktsysteme zu übergeben:

Kryptographische Trennung von externen und internen Umgebungen

Was ist, wenn Sie eine kryptografische Trennung Ihrer externen und internen Umgebungen wünschen? Ein öffentlicher Cloud-Provider würde wahrscheinlich wollen, dass ihre Public-Face-Dienste (oder Proxies) Zertifikate verwenden, die von einer CA ausgegeben werden, die bis zu einer vertrauenswürdigen Root-CA, die in der beliebten Webbrowser-Software für SSL/TLS verteilt ist. Für die internen Dienste möchte man stattdessen seine eigene PKI verwenden, um Zertifikate für SSL/TLS auszustellen. Diese kryptographische Trennung kann durch Beenden von SSL an der Netzwerkgrenze erreicht und dann mit den intern ausgegebenen Zertifikaten neu verschlüsselt werden. Der Verkehr wird für eine kurze Zeit auf der Öffentlichkeit mit SSL/TLS-Proxy unverschlüsselt, aber es wird nie über das Netzwerk im klaren übertragen werden. Der gleiche Re-Verschlüsselungsansatz, der verwendet wird, um eine kryptographische Trennung zu erreichen, kann auch verwendet werden, wenn eine tiefe Paketinspektion wirklich auf einem Loadbalaner erforderlich ist. Hier ist, wie dieses Einsatzmodell aussehen würde:

Wie bei den meisten Dingen gibt es Kompromisse. Der Hauptkompromiss wird zwischen Sicherheit und Leistung liegen. Verschlüsselung hat eine Kosten, aber auch wird gehackt. Die Sicherheits- und Leistungsanforderungen werden für jeden Einsatz unterschiedlich sein, also wie SSL/TLS verwendet wird, wird letztlich eine individuelle Entscheidung sein.