[ English | English (United Kingdom) | Deutsch | русский | español | Indonesia ]

Sicherheit

Sicherheit ist eine der obersten Prioritäten innerhalb von OpenStack-Ansible (OSA). Viele Sicherheitsverbesserungen für OpenStack-Clouds sind in Bereitstellungen standardmäßig verfügbar. Dieser Abschnitt bietet einen detaillierten Überblick über die wichtigsten Sicherheitsverbesserungen.

Bemerkung

Jeder Deployer hat unterschiedliche Sicherheitsanforderungen. Der OpenStack Security Guide enthält Anweisungen und Ratschläge zum Betrieb und zur Nutzung einer OpenStack-Cloud unter Verwendung der sichersten Methoden.

Verschlüsselte Kommunikation

In jeder OpenStack-Cloud werden vertrauliche Informationen zwischen den Diensten ausgetauscht, einschließlich Benutzeranmeldeinformationen, Dienstanmeldeinformationen oder Informationen zu erstellten Ressourcen. Die Verschlüsselung dieses Datenverkehrs ist in Umgebungen wichtig, in denen das Netzwerk nicht vertrauenswürdig ist. (Weitere Informationen zum Sichern des Netzwerks finden Sie im Abschnitt Sicherstellen des Netzwerkzugriffs auf OpenStack-Dienste.)

Viele der Dienste, die mit OpenStack-Ansible bereitgestellt werden, sind standardmäßig verschlüsselt oder bieten eine Verschlüsselung als Option an. Die Playbooks generieren standardmäßig selbstsignierte Zertifikate, aber die Implementierer können ihre vorhandenen Zertifikate, Schlüssel und CA-Zertifikate verwenden.

Weitere Informationen zum Anpassen der Bereitstellung verschlüsselter Kommunikation finden Sie unter Sichern von Diensten mit SSL-Zertifikaten.

Host-Sicherheit Hardening

OpenStack-Ansible bietet eine umfassende security hardening role, die mehr als 200 Sicherheitskonfigurationen anwendet, wie vom Security Technical Implementation Guide (STIG) der Defense Information Systems Agency (DISA) empfohlen. Diese Sicherheitskonfigurationen sind weit verbreitet und werden von der Regierung der Vereinigten Staaten öffentlich verbreitet.

Host-Security-Hardening wird von mehreren Compliance- und Regulierungsprogrammen gefordert, beispielsweise dem Payment Card Industry Data Security Standard (PCI DSS) (Anforderung 2.2).

Standardmäßig wendet OpenStack-Ansible die Rolle ansible-hardening automatisch auf alle Bereitstellungen an. Die Rolle wurde sorgfältig entworfen, um wie folgt zu funktionieren:

  • Wenden Sie sie unterbrechungsfrei auf eine OpenStack-Produktionsumgebung an

  • Balance Sicherheit mit OpenStack Leistung und Funktionalität

  • Lauf so schnell wie möglich

Weitere Informationen zu den Sicherheitskonfigurationen finden Sie in der Dokumentation security hardening role.

Isolierung

OpenStack-Ansible bietet standardmäßig die Isolation zwischen den Containern, auf denen die OpenStack-Infrastruktur (Steuerungsebene) ausgeführt wird, und zwischen den virtuellen Computern, die von Endbenutzern innerhalb der Bereitstellung generiert werden. Diese Isolierung ist entscheidend, da sie das Ausbrechen von Containern oder virtuellen Maschinen verhindern oder zumindest den Schaden reduzieren kann, den Breakouts verursachen könnten.

Das Linux Security Modules (LSM) -Framework ermöglicht es Administratoren, mandatory access controls (MAC) auf einem Linux-System zu setzen. MAC unterscheidet sich von discretionary access controls (DAC), da der Kernel strenge Richtlinien erzwingt, die kein Benutzer umgehen kann. Obwohl jeder Benutzer in der Lage ist, eine DAC-Richtlinie zu ändern (z. B. chown bob secret.txt), kann nur der Benutzer root eine MAC-Richtlinie ändern.

OpenStack-Ansible verwendet derzeit AppArmor, um MAC-Richtlinien auf Infrastrukturservern und Hypervisoren bereitzustellen. Die AppArmor-Konfiguration legt die Zugriffsrichtlinien fest, um zu verhindern, dass ein Container auf die Daten eines anderen Containers zugreift. Für virtuelle Maschinen verwendet libvirtd die Erweiterungen sVirt , um sicherzustellen, dass eine virtuelle Maschine nicht auf Daten oder Geräte von einer anderen virtuellen Maschine zugreifen kann.

Diese Richtlinien werden auf Kernel-Ebene angewendet und verwaltet. Jedem Prozess, der gegen eine Richtlinie verstößt, wird der Zugriff auf die Ressource verweigert. Alle Ablehnungen werden in auditd protokolliert und sind unter /var/log/audit/audit.log verfügbar.

Das geringste Privileg

Das principle of least privilege wird in OpenStack-Ansible verwendet, um den Schaden zu begrenzen, der verursacht werden könnte, wenn ein Angreifer Zugriff auf Anmeldeinformationen erhält.

OpenStack-Ansible konfiguriert eindeutige Benutzernamen- und Kennwortkombinationen für jeden Dienst, der mit RabbitMQ und Galera/MariaDB interagiert. Jeder Dienst, der eine Verbindung zu RabbitMQ herstellt, verwendet einen separaten virtuellen Host zum Veröffentlichen und Verwenden von Nachrichten. Die MariaDB-Benutzer für jeden Dienst erhalten nur Zugriff nur auf die Datenbanken, die sie abfragen müssen.

You can also run OpenStack-Ansible with non-root user by leveraging the Ansible privilege escalation method. For more details, please reffer to the running as non-root.

Sicherstellen des Netzwerkzugriffs auf OpenStack-Dienste

OpenStack-Clouds stellen Endbenutzern zahlreiche Dienste zur Verfügung, mit denen sie Instanzen erstellen, Speicher bereitstellen und Netzwerke erstellen können. Jeder dieser Dienste stellt dem Netzwerk einen oder mehrere Service-Ports und API-Endpunkte zur Verfügung.

Einige der Dienste in einer OpenStack-Cloud sind jedoch für alle Endbenutzer zugänglich, während andere nur für Administratoren oder Betreiber in einem gesicherten Netzwerk zugänglich sind.

  • Dienste, auf die alle Endbenutzer zugreifen können

    • Zu diesen Diensten gehören Compute (nova), Object Storage (swift), Networking (Neutron) und Image (glance).

    • Diese Dienste sollten in einem ausreichend eingeschränkten Netzwerk angeboten werden, das allen Endbenutzern den Zugriff auf die Dienste ermöglicht.

    • Um den Zugriff auf das Netzwerk zu beschränken, muss eine Firewall verwendet werden.

  • Dienste, auf die nur Administratoren oder Operatoren zugreifen können

    • Zu diesen Diensten gehören MariaDB, Memcached, RabbitMQ und der Admin-API-Endpunkt für den Identity (Keystone) -Dienst.

    • Diese Dienste müssen in einem stark eingeschränkten Netzwerk angeboten werden, das nur für Benutzer mit Administratorrechten verfügbar ist.

    • Um den Zugriff auf das Netzwerk zu beschränken, muss eine Firewall verwendet werden.

Die Beschränkung des Zugriffs auf diese Netzwerke hat mehrere Vorteile:

  • Ermöglicht die Netzwerküberwachung und -benachrichtigung

  • Verhindert nicht autorisierte Netzwerküberwachung

  • Reduziert die Wahrscheinlichkeit des Diebstahls von Anmeldeinformationen

  • Reduziert den Schaden durch unbekannte oder ungepatchte Service-Schwachstellen

OpenStack-Ansible stellt HAProxy-Backends für jeden Dienst bereit und beschränkt den Zugriff für hochsensible Dienste, indem sie nur im Verwaltungsnetzwerk verfügbar gemacht werden. Implementierer mit externen Load Balancern müssen sicherstellen, dass die Backends sicher konfiguriert sind und dass Firewalls den Datenverkehr zwischen den Netzwerken verhindern.

Weitere Informationen zu empfohlenen Netzwerkrichtlinien für OpenStack-Clouds finden Sie im Abschnitt API endpoint process isolation and policy im Abschnitt OpenStack Security Guide