Objektspeicher

OpenStack Object Storage (Swift) Service bietet Software, die Daten über HTTP speichert und abruft. Objekte (Blobs of Data) werden in einer organisatorischen Hierarchie gespeichert, die anonymen Nur-Lese-Zugriff, ACL-definierten Zugriff oder sogar temporären Zugriff bietet. Object Storage unterstützt mehrere Token-basierte Authentifizierungsmechanismen, die über Middleware implementiert werden.

Anwendungen speichern Daten in Object Storage und rufen diese über eine branchenübliche HTTP RESTful API ab. Back-End-Komponenten von Object Storage folgen dem gleichen RESTful-Modell, obwohl einige APIs, wie jene, die die Haltbarkeit verwalten, privat zum Cluster gehalten werden. Weitere Informationen zur API finden Sie unter OpenStack Storage API.

Die Komponenten von Object Storage sind in folgende Primärgruppen unterteilt:

  1. Proxy-Dienste

  2. Auth Dienstleistungen

  3. Speicherdienstleistungen

    • Kontodienst

    • Container-Dienst

    • Objekt-Dienst

_images/swift_network_diagram-1.png

Ein Beispieldiagramm aus dem OpenStack Object Storage Administrationshandbuch (2013)

Bemerkung

Eine Objektspeicherinstallation muss nicht im Internet sein und könnte auch eine private Cloud gegen eine public Cloud als ein Teil der internen Netzwerkinfrastruktur des Unternehmens switchen.

Netzwerksicherheit

Sichern des Objektspeicherdienstes beginnt mit der Sicherung der Netzwerkkomponente. Wenn Sie das Netzwerk-Kapitel übersprungen haben, kehren Sie zu Vernetzung zurück.

Das rsync-Protokoll wird zwischen Speicherdienstknoten verwendet, um Daten für Hochverfügbarkeit zu replizieren. Darüber hinaus kommuniziert der Proxy-Dienst mit dem Speicherdienst, wenn er Daten zwischen dem Client-Endpunkt und der Cloud-Umgebung hin- und herleitet.

Vorsicht

Object Storage verwendet keine Verschlüsselung oder Authentifizierung mit Inter-Knoten-Kommunikation. Aus diesem Grund sehen Sie in den Architekturdiagrammen einen privaten Switch oder ein privates Netzwerk ([V] LAN). Diese Datendomäne sollte auch von anderen OpenStack-Datennetzen getrennt sein. Für weitere Diskussionen über Sicherheitsdomänen siehe Sicherheitsgrenzen und Bedrohungen.

Tipp

Verwenden Sie ein privates (V) LAN-Netzwerksegment für Ihre Speicherknoten im Datenbereich.

Dies erfordert, dass die Proxy-Knoten Dual-Interfaces (physisch oder virtuell) haben:

  1. Einer als eine öffentliche Schnittstelle für die Verbraucher zu erreichen.

  2. Eine andere als private Schnittstelle mit Zugriff auf die Speicherknoten.

Die folgende Abbildung zeigt eine mögliche Netzwerkarchitektur.

_images/swift_network_diagram-2.png

Objekt Storage Netzwerkarchitektur mit einem Managementknoten (OSAM)

Allgemeine Service-Sicherheit

Führen Sie Dienste als Nicht-Root-Benutzer aus

Wir empfehlen Ihnen, den Objektspeicherdienst zu konfigurieren, der unter einem Nicht-Root-(UID 0) Dienstkonto ausgeführt wird. Eine Empfehlung ist der Benutzername swift mit der primären Gruppe swift. Objektspeicherdienste umfassen beispielsweise proxy-server, `` container-server``, account-server. Detaillierte Schritte für Setup und

Bemerkung

Der obige Link ist standardmäßig auf die Ubuntu-Version eingestellt.

Dateirechte

Das /etc/swift-Verzeichnis enthält Informationen über die Ring- Topologie und die Umgebungskonfiguration. Folgende Berechtigungen werden empfohlen:

# chown -R root:swift /etc/swift/*
# find /etc/swift/ -type f -exec chmod 640 {} \;
# find /etc/swift/ -type d -exec chmod 750 {} \;

This restricts only root to be able to modify configuration files while allowing the services to read them through their group membership in the swift group.

Sicherheitsspeicherdienste

Im Folgenden sind die Standard-Listenports für die verschiedenen Speicherdienste aufgeführt:

Dienstname

Port

Art

Kontodienst

6002

TCP

Container-Dienst

6001

TCP

Objektdienst

6000

TCP

Rsync [1]

873

TCP

Wichtig

Die Authentifizierung findet nicht an den Speicherknoten statt. Wenn Sie in der Lage sind, eine Verbindung zu einem Speicherknoten auf einem dieser Ports herzustellen, können Sie Daten ohne Authentifizierung aufrufen oder ändern. Um diese Frage zu sichern, sollten Sie die Empfehlungen über die Verwendung eines privaten Speichersystems beachten.

Objektspeicher-Konto-Terminologie

Ein Objektspeicherkonto ist kein Benutzerkonto oder Anmeldeinformation. Im Folgenden werden die Beziehungen erläutert:

OpenStack Object Storage-Konto

Sammlung von Containern; nicht Benutzerkonten oder Authentifizierung. Welche Benutzer mit dem Konto verknüpft sind und wie sie darauf zugreifen können, hängt vom verwendeten Authentifizierungssystem ab. Siehe Objektspeicher-Authentifizierung.

OpenStack Object Storage Container

Sammlung von Objekten. Metadaten auf dem Container sind für ACLs verfügbar. Die Bedeutung von ACLs hängt vom verwendeten Authentifizierungssystem ab.

OpenStack Object Speicherobjekte

Die eigentlichen Datenobjekte. ACLs auf Objektebene sind auch mit Metadaten möglich und sind abhängig vom verwendeten Authentifizierungssystem.

Auf jeder Ebene haben Sie ACLs, die diktieren, wer welche Art von Zugriff hat. ACLs werden auf der Grundlage des Authentifizierungssystems interpretiert. Die beiden häufigsten Arten von Authentifizierungsanbietern sind Identity Service (Keystone) und TempAuth. Benutzerdefinierte Authentifizierungsanbieter sind auch möglich. Siehe Objektspeicher-Authentifizierung für weitere Informationen.

Sicherung von Proxy-Diensten

Ein Proxy-Knoten sollte mindestens zwei Schnittstellen (physisch oder virtuell) haben: eine öffentliche und eine private. Firewalls oder Service-Bindung schützen die öffentliche Schnittstelle. Der Public-Face-Service ist ein HTTP-Webserver, der Endpunkt-Client-Anfragen verarbeitet, authentifiziert und die entsprechende Aktion ausführt. Die private Schnittstelle benötigt keine Listener-Dienste, sondern wird stattdessen verwendet, um ausgehende Verbindungen zu Speicherknoten im privaten Speichernetzwerk herzustellen.

HTTP-Listener-Ports

Sie sollten Ihren Web-Service als Nicht-Root-Benutzer (keine UID 0) wie `` swift``konfigurieren. Die Verwendung eines Portes größer als 1024 ist erforderlich, um dies einfach zu machen und zu vermeiden, dass ein Teil des Webcontainers als root ausgeführt wird. Normalerweise erhalten Clients, die die HTTP-REST-API verwenden und die Authentifizierung durchführen, automatisch die vollständige REST-API-URL, die sie von der Authentifizierungsantwort benötigen. Die REST-API von OpenStack ermöglicht es einem Client, sich für eine URL zu authentifizieren und dann eine ganz andere URL für den eigentlichen Service zu verwenden. Zum Beispiel authentifiziert ein Client zu https://identity.cloud.example.org:55443/v1/auth und bekommt eine Antwort mit ihrem Authentifizierungsschlüssel und der Speicher-URL (die URL der Proxy-Knoten oder Load-Balancer) von https:/ /wift.cloud.example.org:44443/v1/AUTH_8980.

Die Methode zum Konfigurieren Ihres Webservers zum Starten und Ausführen als Nicht-Root-Benutzer variiert je nach Webserver und Betriebssystem.

Lastenausgleicher

Wenn die Möglichkeit der Verwendung von Apache nicht möglich ist oder für die Leistung, die Sie Ihre TLS-Arbeit auslösen möchten, können Sie einen dedizierten Netzwerkgerät Load Balancer verwenden. Dies ist ein häufiger Weg, um Redundanz und Lastverteilung bei der Verwendung mehrerer Proxy-Knoten zur Verfügung zu stellen.

Wenn Sie sich dafür entscheiden, Ihre TLS zu entlasten, stellen Sie sicher, dass sich die Netzwerkverbindung zwischen dem Load Balancer und Ihren Proxy-Knoten auf einem privaten (V) LAN-Segment befindet, so dass andere Knoten im Netzwerk (möglicherweise kompromittiert) den unverschlüsselten Verkehr nicht verteilen können. Wenn ein solcher Bruch auftreten würde, könnte der Angreifer Zugang zu Endpunkt-Client- oder Cloud-Administrator-Anmeldeinformationen erhalten und auf die Cloud-Daten zugreifen.

Der Authentifizierungsdienst, den Sie verwenden, wie z.B. Identity Service (Keystone) oder TempAuth, wird bestimmen, wie Sie eine andere URL in den Antworten auf Endpunktclients konfigurieren, damit sie Ihren Load Balancer anstelle eines einzelnen Proxyknotens verwenden.

Objektspeicher-Authentifizierung

Object Storage verwendet ein WSGI-Modell, um eine Middleware-Fähigkeit bereitzustellen, die nicht nur eine allgemeine Erweiterbarkeit bietet, sondern auch für die Authentifizierung von Endpunkt-Clients verwendet wird. Der Authentifizierungsanbieter legt fest, welche Rollen und Benutzertypen vorhanden sind. Einige verwenden traditionelle Benutzernamen und Kennwort-Anmeldeinformationen, während andere API-Schlüssel-Token oder sogar clientseitige x.509-Zertifikate verwenden können. Benutzerdefinierte Anbieter können in benutzerdefinierte Middleware integriert werden.

Object Storage kommt standardmäßig mit zwei Authentifizierungs-Middleware-Modulen, von denen jeder als Beispielcode für die Entwicklung einer benutzerdefinierten Authentifizierungs-Middleware verwendet werden kann.

TempAuth

TempAuth ist die Standardauthentifizierung für Objektspeicher. Im Gegensatz zu Identity speichert er die Benutzerkonten, Anmeldeinformationen und Metadaten im Objektspeicher selbst. Weitere Informationen finden Sie im Abschnitt Das Auth System der Objektspeicher (swift) Dokumentation.

Keystone

Keystone ist der häufig verwendete Identity Provider in OpenStack. Es kann auch für die Authentifizierung in Object Storage verwendet werden. Die Absicherung von Keystone ist bereits in Identität abgedeckt.

Andere bemerkenswerte Artikel

In /etc/swift, auf jedem Knoten gibt es eine `` swift_hash_path_prefix``Einstellung und eine swift_hash_path_suffix Einstellung. Diese werden bereitgestellt, um die Wahrscheinlichkeit von Hash-Kollisionen für Objekte, die gespeichert werden, zu verringern und einen Benutzer zu überschreiben, der die Daten eines anderen Benutzers überschreibt.

Dieser Wert sollte zunächst mit einem kryptographisch gesicherten Zufallszahlengenerator eingestellt und über alle Knoten hinweg konsistent sein. Stellen Sie sicher, dass es mit den richtigen ACLs geschützt ist und dass Sie eine Sicherungskopie haben, um Datenverlust zu vermeiden.