Messaging-Sicherheit

In diesem Abschnitt werden Sicherheitshärtungsansätze für die drei häufigsten Nachrichtenwarteschlangenlösungen beschrieben, die in OpenStack verwendet werden: RabbitMQ, Qpid und ZeroMQ.

Messaging-Transportsicherheit

AMQP-basierte Lösungen (Qpid und RabbitMQ) unterstützen die Sicherheit auf der Sicherheitsebene mit TLS. ZeroMQ Messaging unterstützt nicht nativ TLS, aber Transport-Level-Sicherheit ist möglich mit markierten IPsec- oder CIPSO-Netzwerk-Labels.

Wir empfehlen dringend, die Kryptographie der Transport-Ebene für Ihre Nachrichtenwarteschlange zu aktivieren. Die Verwendung von TLS für die Messaging-Client-Verbindungen bietet den Schutz der Kommunikation von Manipulation und Abhören von In-Transit zum Messaging-Server. Im Folgenden finden Sie Anleitungen, wie TLS in der Regel für die beiden beliebten Messaging-Server Qpid und RabbitMQ konfiguriert ist. Bei der Konfiguration des Bündels der vertrauenswürdigen Zertifizierungsstelle (CA), die Ihr Messaging-Server zur Überprüfung von Clientverbindungen verwendet, empfiehlt es sich, dass nur die für Ihre Knoten verwendete CA, vorzugsweise eine intern verwaltete CA, beschränkt ist. Das Bündel von vertrauenswürdigen CAs bestimmt, welche Client-Zertifikate autorisiert werden sollen, und übergeben den Client-Server-Bestätigungsschritt für die Einrichtung der TLS-Verbindung. Beachten Sie bei der Installation des Zertifikats und der Schlüsseldateien, dass die Dateiberechtigungen eingeschränkt sind, z. B. mit chmod 0600, und das Eigentum ist auf den Messaging-Server-Daemonbenutzer beschränkt, um den unbefugten Zugriff durch andere Prozesse und Benutzer auf der Messaging-Server.

RabbitMQ Server SSL Konfiguration

Folgende Zeilen sollten der systemweiten RabbitMQ-Konfigurationsdatei hinzugefügt werden, typischerweise /etc/rabbitmq/rabbitmq.config:

[
  {rabbit, [
     {tcp_listeners, [] },
     {ssl_listeners, [{"<IP address or hostname of management network interface>", 5671}] },
     {ssl_options, [{cacertfile,"/etc/ssl/cacert.pem"},
                    {certfile,"/etc/ssl/rabbit-server-cert.pem"},
                    {keyfile,"/etc/ssl/rabbit-server-key.pem"},
                    {verify,verify_peer},
                    {fail_if_no_peer_cert,true}]}
   ]}
].

Beachten Sie, dass die ``tcp_listeners``Option auf ``[] ``gesetzt ist, um zu verhindern, dass es auf einem Nicht-SSL-Port zuhört. Die `` ssl_listeners``Option sollte eingeschränkt werden, um nur das Management- Netzwerk für die Dienste zu hören.

Weitere Informationen zur RabbitMQ SSL-Konfiguration finden Sie unter:

Qpid Server SSL Konfiguration

Die Apache-Stiftung hat einen Messaging-Sicherheitsleitfaden für Qpid. Sehen Sie:

Warteschlangenauthentifizierung und Zugriffskontrolle

RabbitMQ und Qpid bieten Authentifizierungs- und Zugriffssteuerungsmechanismen für den Zugriff auf Warteschlangen. ZeroMQ bietet keine solchen Mechanismen.

Einfache Authentifizierung und Sicherheit Layer (SASL) ist ein Framework für die Authentifizierung und Datensicherheit in Internet-Protokolle. Sowohl RabbitMQ als auch Qpid bieten SASL und andere steckbare Authentifizierungsmechanismen über einfache Benutzernamen und Passwörter hinaus, die eine erhöhte Authentifizierungssicherheit ermöglichen. Während RabbitMQ SASL unterstützt, unterstützt die Unterstützung in OpenStack derzeit nicht die Anforderung eines bestimmten SASL-Authentifizierungsmechanismus. Die RabbitMQ-Unterstützung in OpenStack ermöglicht entweder Benutzername und Passwort-Authentifizierung über eine unverschlüsselte Verbindung oder Benutzername und Passwort in Verbindung mit X.509-Client-Zertifikaten, um die sichere TLS-Verbindung herzustellen.

Wir empfehlen die Konfiguration von X.509-Clientzertifikaten auf allen OpenStack-Dienstknoten für Clientverbindungen zur Messaging-Warteschlange und wo möglich (derzeit nur Qpid) die Authentifizierung mit X.509-Clientzertifikaten durchzuführen. Bei der Verwendung von Benutzernamen und Passwörtern sollten Konten pro Service und Knoten für feinere körnige Auditierbarkeit des Zugriffs auf die Warteschlange erstellt werden.

Stellen Sie vor der Bereitstellung die TLS-Bibliotheken in Betracht, die die Warteschlangenserver verwenden. Qpid nutzt die NSS-Bibliothek von Mozilla, während RabbitMQ das TLS-Modul von Erlang verwendet, das OpenSSL verwendet.

Authentifizierungskonfigurationsbeispiel: RabbitMQ

Auf dem RabbitMQ Server löschen Sie den Standard ``guest``Benutzer:

# rabbitmqctl delete_user guest

Auf dem RabbitMQ-Server für jeden OpenStack-Dienst oder -Knoten, der mit der Nachrichtenwarteschlange kommuniziert, werden Benutzerkonten und Berechtigungen eingerichtet:

# rabbitmqctl add_user compute01 RABBIT_PASS
# rabbitmqctl set_permissions compute01 ".*" ".*" ".*"

Ersetzen Sie RABBIT_PASS durch ein passendes Passwort.

Weitere Konfigurationsinformationen finden Sie unter:

OpenStack Service Konfiguration: RabbitMQ

[DEFAULT]
rpc_backend = nova.openstack.common.rpc.impl_kombu
rabbit_use_ssl = True
rabbit_host = RABBIT_HOST
rabbit_port = 5671
rabbit_user = compute01
rabbit_password = RABBIT_PASS
kombu_ssl_keyfile = /etc/ssl/node-key.pem
kombu_ssl_certfile = /etc/ssl/node-cert.pem
kombu_ssl_ca_certs = /etc/ssl/cacert.pem

Authentifizierungskonfigurationsbeispiel: Qpid

Für Konfigurationsinformationen siehe:

OpenStack Service Konfiguration: Qpid

[DEFAULT]
rpc_backend = nova.openstack.common.rpc.impl_qpid
qpid_protocol = ssl
qpid_hostname = <IP or hostname of management network interface of messaging server>
qpid_port = 5671
qpid_username = compute01
qpid_password = QPID_PASS

Optional können Sie bei Verwendung von SASL mit Qpid die verwendeten SASL-Mechanismen angeben, indem Sie Folgendes hinzufügen:

qpid_sasl_mechanisms = <space separated list of SASL mechanisms to use for auth>

Message Queue Prozess Isolation und Policy

Jedes Projekt bietet eine Reihe von Diensten, die Nachrichten senden und verbrauchen. Jede Binärdatei, die eine Nachricht sendet, wird erwartet, dass sie Nachrichten, wenn auch nur Antworten, aus der Warteschlange verbrauchen.

Message-Queue-Service-Prozesse sollten voneinander getrennt sein und andere Prozesse auf einer Maschine.

Namensräume

Netzwerk-Namespaces werden für alle Dienste empfohlen, die auf OpenStack Compute Hypervisors ausgeführt werden. Dies wird dazu beitragen, die Überbrückung des Netzwerkverkehrs zwischen VM-Gästen und dem Management-Netzwerk zu verhindern.

Bei der Verwendung von ZeroMQ-Messaging muss jeder Host mindestens einen ZeroMQ-Nachrichtenempfänger ausführen, um Nachrichten aus dem Netzwerk zu empfangen und Nachrichten über IPC an lokale Prozesse weiterzuleiten. Es ist möglich und ratsam, einen unabhängigen Nachrichtenempfänger pro Projekt innerhalb eines IPC-Namespaces zusammen mit anderen Diensten innerhalb desselben Projekts auszuführen.

Netzwerkpolicy

Warteschlangenserver sollten nur Verbindungen vom Verwaltungsnetzwerk akzeptieren. Dies gilt für alle Implementierungen. Dies sollte durch die Konfiguration von Diensten implementiert und optional durch globale Netzwerkpolitik erzwungen werden.

Bei der Verwendung von ZeroMQ-Messaging sollte jedes Projekt einen separaten ZeroMQ-Empfängerprozess auf einem Port ausführen, der für Dienste gedacht ist, die zu diesem Projekt gehören. Dies entspricht dem AMQP-Konzept des Kontrollaustausches.

Obligatorische Zugriffskontrollen

Verwenden Sie sowohl obligatorische Zugriffskontrollen (MACs) als auch diskretionäre Zugriffskontrollen (DACs), um die Konfiguration für Prozesse nur auf diese Prozesse zu beschränken. Diese Einschränkung verhindert, dass diese Prozesse von anderen Prozessen isoliert werden, die auf derselben Maschine laufen.