Genehmigung¶
Der Identitätsdienst unterstützt den Begriff der Gruppen und Rollen. Benutzer gehören zu Gruppen, während eine Gruppe eine Liste von Rollen hat. OpenStack-Dienste verweisen auf die Rollen des Benutzers, die versuchen, auf den Dienst zuzugreifen. Die OpenStack Policy Enforcer Middleware berücksichtigt die Richtlinienregel, die jeder Ressource zugeordnet ist, dann die Gruppe/Rollen und Assoziationen des Benutzers, um festzustellen, ob der Zugriff auf die angeforderte Ressource erlaubt ist.
Die Policy Enforcement Middleware ermöglicht eine feinkörnige Zugriffskontrolle auf OpenStack-Ressourcen. Das Verhalten der Politik wird ausführlich diskutiert in Richtlinien.
Festlegung formaler Zugangskontrollrichtlinien¶
Bevor Sie Rollen, Gruppen und Benutzer konfigurieren, dokumentieren Sie die erforderlichen Zugriffskontrollrichtlinien für die OpenStack-Installation. Die Policen sollten mit den gesetzlichen oder rechtlichen Anforderungen der Organisation vereinbar sein. Zukünftige Änderungen an der Zutrittskontrollkonfiguration sollten konsequent mit den formalen Richtlinien erfolgen. Die Richtlinien sollten die Bedingungen und Prozesse zum Erstellen, Löschen, Deaktivieren und Aktivieren von Konten sowie zum Zuweisen von Berechtigungen für die Konten enthalten. Überprüfen Sie regelmäßig die Richtlinien und stellen Sie sicher, dass die Konfiguration den genehmigten Richtlinien entspricht.
Serviceberechtigung¶
Cloud-Administratoren müssen einen Benutzer mit der Rolle von admin für jeden Dienst definieren, wie im OpenStack Administrator Guide beschrieben. Dieses Dienstkonto stellt den Dienst mit der Berechtigung zur Authentifizierung von Benutzern zur Verfügung.
Die Berechnungs- und Objektspeicherdienste können so konfiguriert werden, dass sie den Identitätsdienst zum Speichern von Authentifizierungsinformationen verwenden. Weitere Optionen zum Speichern von Authentifizierungsinformationen sind die Verwendung der „tempAuth“-Datei, die jedoch nicht in einer Produktionsumgebung bereitgestellt werden soll, da das Passwort im Klartext angezeigt wird.
Der Identity Service unterstützt die Client-Authentifizierung für TLS, die aktiviert werden kann. Die TLS-Client-Authentifizierung bietet neben dem Benutzernamen und dem Kennwort einen zusätzlichen Authentifizierungsfaktor, der eine höhere Zuverlässigkeit für die Benutzeridentifizierung bietet. Es verringert das Risiko eines unbefugten Zugriffs, wenn Benutzernamen und Passwörter beeinträchtigt werden können. Allerdings gibt es zusätzliche administrative Overhead und Kosten für die Ausstellung von Zertifikaten an Benutzer, die möglicherweise nicht möglich sind, in jedem Einsatz.
Bemerkung
Wir empfehlen Ihnen, die Client-Authentifizierung mit TLS für die Authentifizierung von Diensten für den Identity-Service zu verwenden.
The cloud administrator should protect sensitive configuration files
from unauthorized modification. This can be achieved with mandatory
access control frameworks such as SELinux, including
/etc/keystone/keystone.conf and X.509 certificates.
Die Client-Authentifizierung mit TLS verlangt, dass Zertifikate an Dienste ausgegeben werden. Diese Zertifikate können von einer externen oder internen
Administrative Benutzer¶
Wir empfehlen, dass Admin-Benutzer authentifizieren werden mit dem Identity-Dienst und einen externen Authentifizierungsdienst, der eine 2-Faktor-Authentifizierung unterstützt, z. B. ein Zertifikat. Dies verringert das Risiko der Komprimittierung von Passwörtern. Diese Empfehlung entspricht der NIST 800-53 IA-2 (1) Anleitung bei der Verwendung von Multifaktor-Authentifizierung für den Netzwerkzugriff auf privilegierte Konten.
Endnutzer¶
Der Identity-Dienst kann direkt eine Endbenutzer-Authentifizierung bereitstellen oder kann so konfiguriert werden, dass er externe Authentifizierungsmethoden verwendet, um den Sicherheitsrichtlinien und Anforderungen eines Unternehmens entsprechen zu können.
