Credential-Verwaltung für Cloud und Microservices Identity Brokering für Maschinen

Anbieter zum Thema

Vogel IT-Medien GmbH

Fujitsu Technology Solutions GmbH

Cohesity GmbH

HashiCorp, Inc

In Bezug auf die statische Verwaltung von Geheimnissen (Secrets Management) ist eine der häufigsten Fragen: Was ist der Unterschied zwischen einer sogenannten Credential-Verwaltung, also einer einheitlichen Schnittstelle zur Verwaltung und Verschlüsselung von Geheimnissen, und einem zentralen Speicher von Geheimnissen (Secret Store)? Ist erstere dem AWS Secrets Manager oder Azure Key Vault ähnlich? Oder ist es eine Lösung, die cloud-unabhängig ist?

Lösungen für das Abspeichern von statischen Geheimnissen ermöglichen im Allgemeinen eine sichere Speicherung von Geheimnissen und einen API-basierten Abruf. Alle großen Cloud-Service-Provider (CSP) bieten ihre eigenen Systeme zur Speicherung an, deshalb gibt es mehrere agnostische Lösungen auf dem Markt. Einmal bieten die agnostischen Lösungen viel mehr Funktionen, was z.B. die Auditierfähigkeit angeht. Darüber hinaus werden Unternehmen durch Regulatorien auch gezwungen, diesen Teil der Security auf ein Drittsystem auszulagern und letztlich beugen viele Firmen es bereits vor, sich komplett in die Abhängigkeit der Cloud Services zu begeben, weil auch noch andere Premises (weiter Public Clouds oder eigene Rechenzentren) in Zukunft eingebunden werden sollen.

Dabei basiert die Authentifizierung in der Regel auf der nativen Identität, die von der Cloud bereitgestellt wird, z. B. die Identität einer virtuellen Maschine in Azure oder eine IAM-Rolle in AWS. Jedoch nutzen Cloud-unabhängige Speichermöglichkeiten häufig einen vordefinierten Satz von Anmeldeinformationen oder eine zusätzliche Form der Authentifizierung –– einschließlich IP-basierter Ansätze (IP-Bindings) – um Nutzer transaktionsbasiert zu authentifizieren und zu autorisieren.

Neue Herangehensweise

Eine Credential-Verwaltung ist zwar in der Lage, als Secrets Manager zu fungieren und Eins-zu-Eins-Beziehungen zu verwalten. Hauptsächlich aber unterscheidet sie sich zu reinen Schlüsselspeichern durch seine Fähigkeiten als Makler (identity broker) um Identitäten zu vermitteln. Identity Brokerage stellt sicher, dass die ursprüngliche Identität in allen Umgebungen genutzt werden kann – unabhängig davon, ob sie lokal (on-premise) oder über mehrere Clouds hinweg verwendet wird. Dies geschieht, ohne dass eine bestimmte IP oder ein weiteres Authentifizierungsverfahren, wie beispielsweise eine anfängliche Challenge-Response, erforderlich sind.

Identity Brokerage ermöglicht mehr Flexibilität, eine sichere Authentifizierung auf allen Ebenen des Anwendungsstacks und eine bessere Beobachtbarkeit über Systeme hinweg. Da das Brokering für eine Many-to-Many-Beziehung konzipiert ist, wird die betriebliche Komplexität reduziert: Es müssen weniger One-to-One-Beziehungen verwaltet werden. Dies führt zu einem Mehrwert, da die Priorität auf deklarativer, relationaler Authentifizierung und Autorisierung liegt.

Was genau ist Identity Brokerage?

Brokerage, also Maklerdienste, sind in der Geschäftswelt ein recht gängiges Konzept: Privatperson beauftragen einen Finanzmakler, um Zugang zu einem Portfolio von Vermögenswerten zu erhalten. Krankenversicherungsansprüche werden über einen Makler im Auftrag eines Versicherers abgewickelt und aggregiert, damit dieser die Zahlungen konsolidieren kann. Das Konzept der Identitätsmaklers folgt einem ähnlichen Muster.

Die häufigste Anwendung von Identity-Brokerage ist Single-Sign-On (SSO). Die Authentifizierung geschieht einmalig an einem Punkt, um dann Zugang zu einer Vielzahl an Services zu erhalten.

Häufig wird jedoch übersehen, dass auch die Identität von Maschinen verwaltet werden muss – ähnlich wie eben SSO für menschliche Identitäten eingesetzt wird. Da Microservices das Architekturdesign weiter vorantreiben, ist es zunehmend notwendig, dass Anwendungen auf mehrere Ressourcen zugreifen. Eine Anwendung, die beispielsweise auf eine Datenbank, SSH und DataDog zugreifen muss, kann Identity Brokerage nutzen, so dass diese Ressourcen von einem einzigen Authentifizierungsmechanismus verwaltet werden. Bei gemeinsam genutzten Ressourcen wird eine zentralisierte Lösung für die Nachvollziehbarkeit und Kontrolle noch wichtiger, um authentifizierte Ressourcen zu überwachen.

Lohnt sich Identity Brokerage für eine einzelne Cloud?

Der Umzug in die Cloud ist komplex und nur selten wird eine einzige Cloud-Strategie verfolgt. Gründe dafür können Strategieänderungen, gesetzliche Vorschriften, Schwierigkeiten bei der Migration von bestehenden älteren Infrastrukturen oder sogar eine Unternehmensübernahme sein. Hinzu kommt, dass Microservice-Architekturen zunehmend allgegenwärtig werden. Das hat zur Folge, dass Ressourcen gemeinsam genutzt werden. Die Weitergabe von Anmeldeinformationen über E-Mail oder Messaging-Dienste kommt weitaus häufiger vor, als man zugeben möchte. Dies stellt ein großes Risiko dar – nicht nur in Bezug auf die Anmeldedaten selbst, sondern auch hinsichtlich deren Weitergabe.

Je mehr Anmeldedaten unkontrolliert im Umlauf sind und in je mehr Anwendungen diese zum Einsatz kommen, umso komplizierter wird es, sie zu verwalten. Außerdem besteht die Gefahr, dass die Identifizierungsinformationen nicht verfügbar sind – insbesondere dann, wenn immer komplexere Architekturen eingeführt werden und damit die Möglichkeiten gemeinsam genutzter Dienste (Shared Service) steigt. Wenn Erika Mustermann, eine Entwicklerin, das Kennwort für die Anmeldung einer Datenbank für Anwendung A ändert, ohne Anwendung B darüber zu informieren, kann dies zu einem Ausfall von Anwendung B führen. Wenn dagegen die Datenbankberechtigungen auf der Grundlage ihrer Identität vermittelt wird, kann Frau Mustermann das Passwort für die Datenbank ändern, ohne dass eine Beeinträchtigung des Dienstes zu befürchten ist.

Derzeit verwenden mehr als 50 Prozent der Unternehmen eine Version von Kubernetes, wobei die Unternehmen, die andere Containersysteme wie Rancher, OpenShift oder Nomad verwenden, nicht mitgerechnet sind. Obwohl es sich bei der Nutzung von Kubernetes um eine Cloud-native Lösung handelt, stellt sie das Identitätsmanagement vor neue Herausforderungen.

Am Beispiel Managed Kubernetes lässt sich erkennen, dass es einen großen Reifeunterschied zwischen den Cloud-Anbietern gibt. In AWS ist es möglich, Cluster mit nativem AWS IAM zu verwalten. Wie bei allen großen Cloud-Anbietern verbleibt die Identität jedoch auf Cluster-Ebene. Dies macht die Identitätsverwaltung auf Pod-Ebene ohne die Verwendung eines CSI-Treibers oder eines Tools eines Drittanbieters fast unmöglich. In Azure ist die Maschinenidentität für AKS nicht verfügbar, was dazu führt, dass die Identitätsverwaltung des Clusters an die Identität des Nutzers gebunden ist. Dies ist alles andere als ideal, wenn die Nichtabstreitbarkeit (non repudiation) eine Priorität ist. Wenn im Fall von GKE beim Start eines neues Pods die Identität des Workloads verwendet wird, können die ersten Sekunden im Leben eines Pods ein Fehlschlag sein. Dies führt zu einer inkonsistenten Verwaltung von Workloads.

Wir brauchen SSO für Menschen, warum also nicht auch für Maschinen?

Seit fast dreißig Jahren verlässt man sich auf SSO für Anwender mit dem Ziel, die Lücke zwischen menschlicher Identität und Authentifizierung zu schließen. Es lässt sich leicht darüber spekulieren, warum die Anwendung von übergreifenden Identitäten nicht stärker in den Vordergrund gerückt ist: Geschah dies wegen der bis vor kurzem noch statischen Natur der Infrastruktur, wegen der allgegenwärtigen Verwendung monolithischer Architekturen oder aufgrund einer Kombination aus beidem? Auf jeden Fall ist der derzeitige Zustand der Anwendungsidentität durch einen fragmentierten, dezentralisierten und hochgradig manuellen Ansatz gekennzeichnet.

Fazit

Während die meisten Cloud-Anbieter über native Identitäten für ihre Ressourcen verfügen, ist die Vereinheitlichung dieser Identitäten in einem einzigen, überprüfbaren und kontrollierten Workflow ohne eine zentrale Vermittlungsstelle komplex. Zudem ist sie für den Menschen nicht lesbar und aufgrund der für die Automatisierung erforderlichen Komplexität nicht skalierbar. Durch den Einsatz eines Brokerage-Mechanismus ist es möglich, einen einheitlichen Workflow über alle erforderlichen Anwendungsebenen hinweg zu gewährleisten – vom Netzwerk bis zur Anwendung und das über mehrere Ressourcen hinweg. Wenn schon Best Practice von Nutzern verlangt, sich per SSO zu authentifizieren – sei es für das VPN oder eine Unternehmensanwendung, warum sollte es bei Maschinen anders sein?

Über den Autor: Sebastian Weiss ist Area Vice President DACH bei HashiCorp. Der versierte Open-Source und Cloud-Experte setzt seinen Fokus auf die Zusammenarbeit mit Technologiepartnern, Systemintegratoren und Resellern in Deutschland, Österreich und der Schweiz. Nach einem Bachelor of Science in Wirtschafsinformatik war Sebastian Weiss in mehreren Vertriebsfunktionen tätig, zuletzt u.a. bei Red Hat, Mirantis, Google Cloud und Microsoft, wo er den Ausbau der Geschäfte in DACH und Europa mitgestaltete.

(ID:49531520)