Entwerfen der Benutzerverwaltung für Maschinen

Von Aviad Mizrachi, InfoWorld |

Aufkommende Technologien von Technologen analysiert

Wenn es einem Benutzer an menschlichen Eigenschaften mangelt und er nicht viel Persönlichkeit hat, kann das einen guten Grund haben. Der Benutzer könnte eine Maschine sein.

Heutzutage findet mehr als 90 % des Internetverkehrs zwischen Maschinen statt. In Wirklichkeit sind Maschinen, die Ihre B2B-SaaS-Anwendung nutzen, auch Benutzer – nur eine andere Art von Benutzern. Aus diesem Grund muss jede Online- und SaaS-Anwendung heute gut durchdachte Benutzerverwaltungspraktiken und -richtlinien umfassen, die speziell auf die unterschiedlichen Herausforderungen und Anforderungen von Machine-to-Machine-Interaktionen (M2M) zugeschnitten sind.

Basierend auf jahrelanger Erfahrung in der Unterstützung von B2B-SaaS-Unternehmen bei der Abwicklung von M2M-Interaktionen habe ich eine Kurzanleitung mit Best Practices für eine effiziente, effektive und sichere Maschine-zu-Maschine-Benutzerverwaltung zusammengestellt. Lass uns eintauchen.

Der Kontext mag bei der menschlichen Benutzerverwaltung von entscheidender Bedeutung sein, für Maschinen ist er jedoch noch wichtiger, da Maschinenbenutzer viel weniger Informationen über ihren Status, ihre Situation und ihre Absichten bereitstellen. Maschinenbenutzer greifen häufig nur auf einen einzelnen Dienst oder eine kleine Anzahl von Diensten zu, während menschliche Benutzer auf viele weitere Dienste zugreifen.

Maschine-zu-Maschine-Interaktionen enthalten keine nützlichen Hinweise wie Browser-Agent, MAC- oder NIC-Adresse oder Geolokalisierungsdaten. Es handelt sich eher um einen API-Aufruf in einem häufig verwendeten Protokoll mit einem Minimum an identifizierenden Merkmalen. Der Kontext rund um die Serviceanfragen, die ein Maschinenbenutzer stellt, sollte bestimmen, wie Richtlinien angewendet werden und wie die Benutzerverwaltung gestaltet wird.

Für die M2M-Benutzerverwaltung muss jeder Dienst wissen, wie er mit anderen Diensten kommunizieren kann und mit welchen Diensten er kommunizieren soll. Alle Dienste müssen wissen, wie sie mit einem anderen Dienst kommunizieren und auf welche Schlüsseldienste sie zugreifen dürfen. Dies ist zum Teil das, was API-Gateways und Service Meshes leisten können, aber keiner von beiden verfügt über einen benutzerzentrierten Ansatz (auch nicht für M2M-Benutzer).

Für menschliche Benutzer ist MFA heute ein wichtiger Teil des Sicherheitsvalidierungsprozesses. Für Maschinenbenutzer ist MFA keine Option. Gleichzeitig laufen M2M-Transaktionen in der Regel in Millisekunden ab, da Maschinen viel schneller interagieren können als Menschen. Dadurch entsteht eine neue Angriffsfläche, die viele Cyberkriminelle nun aktiv durch API-Angriffe auszunutzen versuchen. Für SecDevOps-Teams, die Benutzerverwaltungsprozesse für M2M-Interaktionen durchführen, bedeutet dies, dass anderen Sicherheitsmechanismen wie IP-Adressbegrenzung, Anforderungsratenbegrenzung, Zertifikat- oder Schlüsselrotation und im Idealfall entweder von Menschen oder Maschinen generierten Richtlinien viel stärkere Aufmerksamkeit geschenkt werden muss die ungewöhnliche Nutzungsmuster erkennen.

Ob eine Anfrage von einem internen Computer oder einem externen Benutzer stammt, sollte sehr unterschiedliche Sicherheitsüberlegungen auslösen. Wenn es sich um eine interne Anfrage handelt, die aus einem Kubernetes-Cluster von einem Dienst zu einem anderen kommt, wird die Authentifizierung intern und normalerweise mit einer einfacheren Vorgehensweise durchgeführt. Beispielsweise werden Service Meshes verwendet, um Richtlinien festzulegen, mit denen ein bestimmter interner Dienst eine Verbindung herstellen kann. In der Realität authentifizieren viele Unternehmen immer noch keine internen Maschine-zu-Maschine-Interaktionen, aber CISOs und Risikomanagementteams drängen mit Nachdruck darauf, überall eine Basisauthentifizierung zu implementieren.

Bisher verwenden viele Plattformbetriebe und SecDevOps-Teams für die interne Sicherheit eine naive Authentifizierung – also gemeinsame Geheimnisse. Allerdings erfordert die naive Authentifizierung einen starken Prozess, um Geheimnisse, die verletzt oder auf andere Weise offengelegt wurden, einfach zu ersetzen. Ohne diesen Prozess zum Austausch von Geheimnissen riskiert ein Unternehmen Ausfallzeiten, während neue Geheimnisse erstellt und weitergegeben werden. Im großen Maßstab sind Änderungen an Geheimnissen, die über Paare oder Trios von Maschinenbenutzern hinweg synchronisiert werden müssen, eine Menge Arbeit. Selbst für die interne M2M-Kommunikation gibt es also technologische Herausforderungen.

Bei der externen M2M-Kommunikation und der Maschinenbenutzerverwaltung wird es deutlich komplizierter. Das Teilen von Geheimnissen ist keine ausreichende Sicherheit. Um dies zu veranschaulichen, betrachten Sie das folgende Beispiel. Nehmen wir an, wir haben zwei Dienste – einen Benutzerdienst und einen E-Mail-Dienst. Wir möchten einem Benutzer eine E-Mail senden. Nicht alle Benutzer haben Anspruch auf E-Mails. Um den Benutzer ordnungsgemäß verwalten zu können, muss die Anwendung wissen, welcher Benutzer zum Empfang von E-Mails berechtigt ist und welche E-Mail-Adresse für an diesen Benutzer gesendete Nachrichten angegeben werden soll. Geheimnisse verschwinden in dieser Welt schnell.

Dieser Anwendungsfall verdeutlicht auch, warum M2M-JSON-Web-Tokens (JWTs) generischen M2M-Kommunikationsdiensten vorzuziehen sind. Der Benutzerverwaltungsdienst muss dann ein Token für einen bestimmten Benutzer oder eine bestimmte Organisation generieren. Der Token kann widerrufen oder so eingestellt werden, dass er in bestimmten Abständen erneuert werden muss.

Eine gut konzipierte Token-Lebenszyklusrichtlinie und ein Betriebssystem ermöglichen es Sicherheits- und Benutzerverwaltungsdiensten, den Zugriff schnell zu widerrufen oder Schlüssel ohne Betriebsunterbrechung zu wechseln. Die Richtlinie wird automatisch über Zertifikatssperr- oder Erneuerungslisten angewendet. Wenn Verlängerungen relativ kurzfristig erfolgen, ist es möglich, die Benutzerverwaltung so anzupassen, dass für M2M-Benutzer nahezu Zero Trust gewährleistet wird. JWTs können mehrere Attribute tragen und sind daher besonders nützlich für die Kodierung von Kontext.

Eine zweite Möglichkeit für Organisationen, die externe Authentifizierung zu handhaben, ist das Zugriffstoken, bei dem ein Benutzer eine einzelne Wertzeichenfolge erhält. So funktioniert ein Zugriffstoken:

Ein Zugriffstoken eignet sich sehr gut für einfache Transaktionen, kann jedoch in komplizierteren Szenarien zusammenbrechen und einen Single Point of Failure erzeugen. Wenn beispielsweise das Zugriffstoken aus irgendeinem Grund nicht validiert ist, gibt es keinen einfachen Rückgriff und keinen anderen Mechanismus zur Vertrauensbewertung. Die Ausführung auf einer Microservice-Architektur bedeutet einen komplizierteren Ablauf, der schwieriger zu verwalten ist. Ein Maschinenbenutzer würde eine sofortige Validierung benötigen, die an einen separaten Validierungsserver und einen separaten Service-Track erfolgt. Bei JWTs muss der Dienst lediglich wissen, ob der Benutzer über ein gültiges JWT verfügt, das den gesamten Zugriffskontext speichert. Es ist nicht erforderlich, einen separaten Prozess auszuführen, um dies zu validieren.

Ein dritter Weg sind Client-Anmeldeinformationen. Hierbei handelt es sich um eine Reihe von Identifikationsinformationen, die von einer Anwendung bereitgestellt werden, z. B. eine Client-ID und ein Geheimnis, die zur Authentifizierung der Anwendung und zur Autorisierung des Zugriffs auf einen Ressourcenserver verwendet werden. Client-Zugangsdaten beinhalten oft JWTs und haben den Vorteil, dass sie sicherer sind, da sie zwei Identifikationsnachweise erfordern. Auch wenn Client-Zugangsdaten möglicherweise weniger benutzerfreundlich sind, stellt dies weniger ein Problem dar, wenn der Benutzer kein Mensch ist.

Bei Client-Zugangsdaten muss das System jedoch sorgfältig konzipiert werden, um eine schnelle Behebung von Fehlern und die Linderung von Engpässen zu ermöglichen. Dies kann besonders schwierig sein, wenn Sie sich auf andere verteilte Systeme wie Google oder OAuth oder ein Cloud-Zertifikat oder eine Token-Autorität eines Drittanbieters verlassen. In diesem Szenario könnte sich eine Organisation auf ein JWT verlassen, das sie nicht generiert oder kontrolliert.

Ein Mittelweg zwischen Client-Anmeldeinformationen und Zugriffskontrollen könnte gegenseitiges TLS (mTLS) sein. mTLS stellt sicher, dass die Parteien an jedem Ende einer Netzwerkverbindung die sind, für die sie sich ausgeben, indem überprüft wird, ob beide über den richtigen privaten Schlüssel verfügen. Dadurch werden zusätzliche Mechanismen zur Vertrauensvalidierung am Handshake-Punkt hinzugefügt. Einige Service Meshes, Reverse-Proxys und API-Gateways wenden mTLS standardmäßig an, aber die Synchronisierung von mTLS über Ihren gesamten Infrastruktur-Stack erfordert echtes Systemdesign und sorgfältige Überlegungen.

Da die Anzahl der Dienste und Microservices weiter zunimmt und immer mehr Anwendungen auf APIs basieren, wird die Entwicklung einer starken Benutzerverwaltungsstrategie und -praxis für M2M-Interaktionen immer wichtiger. Das heisst:

Denken Sie daran: Auch Maschinen sind Benutzer. Sie müssen sie wie Benutzer behandeln, um sicherzustellen, dass die von ihnen genutzten Dienste verfügbar, schnell, skalierbar und sicher sind.

Aviad Mizrachi ist CTO und Mitbegründer von Frontegg.

—

Das New Tech Forum bietet einen Ort, um neue Unternehmenstechnologien in beispielloser Tiefe und Breite zu erkunden und zu diskutieren. Die Auswahl ist subjektiv und basiert auf unserer Auswahl der Technologien, die wir für wichtig und für die InfoWorld-Leser von größtem Interesse halten. InfoWorld akzeptiert keine Marketingmaterialien zur Veröffentlichung und behält sich das Recht vor, alle beigesteuerten Inhalte zu bearbeiten. Senden Sie alle Anfragen an [email protected].

Lesen Sie als nächstes Folgendes:

Blog