Ein Blick auf das Verständnis der Governance nicht-menschlicher Identitäten

Kann eine Identität existieren, ohne von einer anderen Identität referenziert zu werden? Wie würden wir das wissen?

Das mag für einen Sicherheitstechnik-Artikel etwas philosophisch erscheinen, aber es ist ein wichtiger Punkt, den man im Auge behalten sollte, wenn man das Thema nicht-menschliche Identitäten behandelt. Eine bessere Frage im Zusammenhang mit Sicherheit wäre tatsächlich, „Sollte eine Identität existieren, wenn sie nicht interagiert werden kann?“ Wir könnten die Antwort auf diese erste Frage möglicherweise nicht finden, da es etwas außerhalb des Rahmens der Informatik liegt, die Natur der Realität zu beweisen. Viele Leute haben jedoch hart daran gearbeitet, die NHI-Governance-Tools zu entwickeln, um festzustellen, ob eine Maschinenidentität existiert, warum sie existiert und die Frage zu beantworten, ob sie existieren sollte. 

Die Zukunft der Beseitigung von Geheimnissen liegt darin, die Lebenszyklen und Wechselwirkungen der nicht-menschlichen Identitäten zu beherrschen, die auf Geheimnissen beruhen. Aber warum jetzt? Lassen Sie uns einen Schritt zurücktreten und einige unserer Annahmen über NHIs und deren Existenz neu überdenken.

Was sind nicht-menschliche Identitäten?

Bevor wir fortfahren, lassen Sie uns NHI im Kontext dieses Gesprächs definieren.

In the simplest terms, a non-human identity, also commonly referred to as a machine identity or a workload identity, is any entity that is not human and can perform an action within your system, most commonly interacting exclusively with other non-humans.

Dies könnte ein Kubernetes-Pod sein, der mit einer Datenquelle interagieren muss und die verarbeiteten Daten an ein Meldesystem senden muss. Dies könnte ein Internet der Dinge (IoT)-Sensor sein, der Daten an einen zentralen Server sendet. Dies könnte ein auf Slack basierender Chatbot sein. Wenn nach der anfänglichen Erstellung keine menschliche Eingabe mehr direkt erforderlich ist, damit die Entität arbeiten kann, sollten wir diese Identität als ’nicht-menschlich‘ betrachten.

Die eine Gemeinsamkeit aller dieser Beispiele ist, dass sie mit einem anderen System interagieren. Wenn wir wollen, dass sie mit der gesamten Welt kommunizieren, ist das einfach, da wir einfach auf die anderen nicht-menschlichen Identitäten verweisen und programmgesteuert beschreiben, wie sie interagieren sollen. Allerdings möchten wir höchstwahrscheinlich, dass diese Systeme sicher kommunizieren, indem wir nur bestimmte Identitäten unter bestimmten Umständen autorisieren. Dies hat die Evolution von Geheimnissen für das Zugangsmanagement vorangetrieben, von einfachen Benutzername/Passwort-Paaren zu API-Schlüsseln bis hin zu Zertifikaten.

Zugegeben, das ist eine breite Definition von NHI. Wir können jedoch eingrenzen, was uns an Maschinenidentitäten interessiert, indem wir einen Schritt zurücktreten und betrachten, wie diese Entitäten durch die Linse ihrer Geheimnisse, die Zugang und Kommunikation ermöglichen, zueinander in Beziehung stehen.

Alle NHIs verbinden sich mit anderen Systemen

Können Sie eine eigenständige Anwendung erstellen, die keine Eingaben annimmt, keine Ausgaben produziert und keine adressierbare Schnittstelle hat? Gibt es eine solche Anwendung außerhalb eines Gedankenexperiments? Auch wenn es Spaß macht, darüber nachzudenken, ist die Realität, dass alle NHIs, die uns interessieren, existieren, um mit anderen Identitäten zu kommunizieren.

NHIs erfordern von Natur aus Verbindungen zu anderen Systemen und Diensten, um ihren Zweck zu erfüllen. Diese Interkonnektivität bedeutet, dass jedes NHI zu einem Knoten in einem Netz von Abhängigkeiten wird. Aus der Perspektive der NHI-Governance ergibt sich daraus die Notwendigkeit, ein genaues und dynamisches Inventar dieser Verbindungen zu führen, um die damit verbundenen Risiken zu verwalten. Zum Beispiel, wenn ein einzelnes NHI kompromittiert wird, mit was verbindet es sich, und auf was könnte ein Angreifer zugreifen, um lateral vorzudringen?

Eine ordnungsgemäße NHI-Governance muss Tools zur Kartierung und Überwachung dieser Beziehungen enthalten. Obwohl es viele Möglichkeiten gibt, dies manuell zu erledigen, ist das, was wir tatsächlich wollen, ein automatisierter Weg, um herauszufinden, was mit was verbunden ist, wofür es verwendet wird und von wem. Beim Nachdenken über die Sicherung unserer Systeme können wir eine weitere wichtige Tatsache über alle NHIs in einer gesicherten Anwendung nutzen, um diese Karte zu erstellen: Sie haben alle notwendigerweise Geheimnisse.

Alle sicheren NHIs müssen ein Geheimnis haben

Um eine vertrauenswürdige Kommunikation zwischen zwei NHIs herzustellen, muss ein eindeutiges Geheimnis wie ein API-Schlüssel, Token oder Zertifikat für diese Entitäten existieren, um sich zu authentifizieren. Wir können das Geheimnis verwenden, um die Identität eines NHIs zu bestätigen und es im Ökosystem zu kartieren. Die Frage lautet, wo suchen wir nach diesen Geheimnissen?

In modernen Unternehmen, insbesondere in größeren Unternehmen, gibt es im Grunde nur zwei Orte, an denen ein Geheimnis existieren kann. Ihre erste Option ist die Best Practice und sicherste Option: ein Secrets Management-System wie CyberArk’s Conjur, Vault von HashiCorp oder AWS Secrets Manager. Die andere Option ist viel weniger sicher, aber leider allzu verbreitet: außerhalb eines Tresors, im Code oder in der Konfiguration im Klartext.

Enterprise-Heimverwaltungsplattformen, oft als Tresore bezeichnet, sind entscheidend für die Speicherung und den Schutz von Geheimnissen, die von NHIs verwendet werden. Tresore können eine einzige Quelle der Wahrheit für alle Geheimnisse bieten, indem sie sicherstellen, dass sie im Ruhezustand verschlüsselt, streng zugangskontrolliert und auf unbefugte Zugriffsversuche überwacht werden. Dies setzt voraus, dass Sie sich auf eine einzige Enterprise-Heimverwaltungsplattform standardisiert haben. Die meisten Organisationen haben tatsächlich viele Tresore gleichzeitig in Gebrauch, was die Synchronisierung zwischen allen Tresoren zu einer zusätzlichen Herausforderung macht.

Teams können alle vorhandenen Maschinenidentitäten basierend auf dem Vorhandensein dieser Geheimnisse abbilden. Für Unternehmen mit mehreren Heimverwaltungs-Lösungen müssen Sie wissen, welche Tresore ein Geheimnis enthalten und welche nicht, um den Aufwand zu reduzieren, denselben Schlüssel redundant über mehrere Tresore zu speichern.

Alle NHI-Geheimnisse haben eine Ursprungsgeschichte

Maschinen können sich keine Berechtigungen und Zugriffe gewähren. Jede Maschinenidentität wurde von oder repräsentiert eine menschliche Identität. Die Governance von NHIs muss die Nachverfolgung der Erstellung von Geheimnissen umfassen, um sicherzustellen, dass jedes Geheimnis auf seinen Ursprung zurückverfolgt, sicher verteilt und mit einer legitimen Identität verknüpft werden kann. Während dieser Aspekt mit dem richtigen Einsatz einer Heimverwaltungsplattform berücksichtigt werden könnte, zeigt unsere Daten immer wieder, dass ein gewisser Prozentsatz von Geheimnissen Jahr für Jahr durchsickert, weil wir diese Tresorlösungen nicht konsequent nutzen.

Wir wissen aus jahrelanger Erfahrung, dass der Ersteller eines Geheimnisses fast immer die Person ist, die die Berechtigung zuerst in ein Ökosystem einführt. Wir können auch aus der Codehistorie oder anderen Zeitstempelinformationen im System erkennen, wann dies zum ersten Mal gesehen wurde, was der wahrscheinlichste Zeitpunkt für die Erstellung oder zumindest das bedeutungsvolle Vorhandensein ist.

Dies ist ein kritisches Detail, das möglicherweise nirgendwo anders richtig protokolliert oder dokumentiert wurde. Sobald Sie verstehen, wer ein Geheimnis erstellt hat, um ein NHI nutzen zu können, verstehen Sie wirklich den Beginn unseres NHI-Lebenszyklus.

Alle NHI-Geheimnisse müssen eine bestimmte Menge an Berechtigungen gewähren

Bei der Erstellung muss jedem NHI-Geheimnis eine bestimmte Menge an Berechtigungen zugewiesen werden. Der Umfang bestimmt, welche Aktionen eine Identität durchführen kann und auf welchen Systemen. Dies macht die Festlegung und Durchsetzung von Berechtigungen zu entscheidenden Komponenten der Governance.

Im Wesentlichen gibt es zwei Risiken, die das Verständnis des Umfangs eines Geheimnisses für die Unternehmenssicherheit kritisch machen. Erstens können falsch konfigurierte oder überprivilegierte Geheimnisse unbeabsichtigt den Zugriff auf sensitive Daten oder kritische Systeme gewähren, was die Angriffsfläche erheblich vergrößert. Stellen Sie sich vor, Sie geben versehentlich Schreibrechte für ein System, das auf die PII Ihrer Kunden zugreifen kann. Das ist eine tickende Uhr, die darauf wartet, dass ein Bedrohungsakteur sie findet und ausnutzt.

Ebenso besorgniserregend ist, dass ein Team ein geheimes Schlüssel nicht ersetzen kann, bis es zuerst versteht, wie diese Berechtigungen konfiguriert wurden. Zum Beispiel, nehmen wir an, Sie wissen, dass das Geheimnis eines mission-kritischen Mikrodienstes versehentlich in ein öffentliches GitHub-Repository gepusht wurde. In diesem Fall ist es nur eine Frage der Zeit, bevor es von jemandem außerhalb Ihrer Organisation entdeckt und genutzt wird. In unserem aktuellen Bericht „Voice of the Practitioner“ gaben IT-Entscheidungsträger zu, dass es im Durchschnitt 27 Tage dauerte, um diese kritischen Geheimnisse zu rotieren. Teams sollten in der Lage sein, in Sekunden oder Minuten zu handeln, nicht in Tagen.

Werkzeuge, die zusätzlichen Kontext über erkannte Geheimnisse bieten, einschließlich ihrer Rollen und Berechtigungen, sind erforderlich. Das schnelle Verständnis darüber, welche Vermögenswerte exponiert sind, wenn ein Leck auftritt und welchen potenziellen Schaden ein Bedrohungsakteur anrichten kann, ist entscheidend für die Reaktion auf einen Vorfall. Genau zu wissen, wie man es aus einer Dashboard-Ansicht oder API-Aufruf ersetzt, kann den Unterschied zwischen einem Datenleck und einem frustrierten Angreifer ausmachen, der herausfindet, dass der Schlüssel, den er hat, ungültig ist.

Alle NHI-Geheimnisse müssen rotiert werden

Eine Maschinenidentität kann, und sollte wahrscheinlich auch, im Laufe ihrer Lebensdauer viele Geheimnisse haben. Wenn Anmeldeinformationen monatelang oder jahrelang, oder im schlimmsten Fall für immer, bestehen bleiben, wird die Exposition oder Kompromittierung von NHI-Geheimnissen zunehmend wahrscheinlich. Manuelle Rotation ist fehleranfällig und betrieblich belastend, insbesondere in Umgebungen mit Tausenden von NHIs. Die Automatisierung des Geheimrotationsprozesses ist ein Grundpfeiler der NHI-Governance, die sicherstellt, dass Geheimnisse erneuert werden, bevor sie ablaufen oder geleakt werden.

Für jedes der Geheimnisse in Ihren Tresoren sollte die Rotation eine einfache Angelegenheit des Skriptings sein. Die meisten Geheimnisverwaltungsplattformen bieten Skripte oder ein anderes Mechanismus an, um den sensiblen Prozess des sicheren Ersetzens und Widerrufens des alten Geheimnisses zu verwalten.

Aber was ist mit den NHI-Geheimnissen, die außerhalb dieser Tresore leben, oder vielleicht demselben Geheimnis, das über mehrere Tresore verteilt ist? Eine gute Geheimnisscan-Plattform benötigt nahtlose Integration mit diesen Tresoren, damit Ihr Team diese Geheimnisse leichter finden und sicher im Geheimnismanager speichern kann und den Weg für die automatisierte Rotation ebnet. Die Referenzimplementierung von GitGuardian mit CyberArks Conjur geht detaillierter darauf ein, wie Sie den gesamten Speicher- und Rotationsprozess vollständig automatisieren können.

Durch die Identifizierung aller NHIs und das Wissen über deren Erstellungszeitpunkt können wir auch vorhersagen, wann sie ausgetauscht werden müssen. Während jedes Team genau beurteilen wird, wie lange jeder Schlüssel leben sollte, sind alle Schlüssel, die seit der Erstellung nie ausgetauscht wurden, reif für den Austausch. Jeder Schlüssel, der älter als ein Jahr ist oder für einige systemkritische Systeme sogar nur wenige Tage alt ist, sollte ebenfalls prioritär für den Austausch behandelt werden.

Alle NHIs werden ein End-of-Life haben

NHIs haben, wie ihre menschlichen Gegenstücke, endliche Lebenszyklen. Sie können außer Betrieb genommen werden, wenn ein Dienst eingestellt, ersetzt oder nicht mehr benötigt wird. Ohne die Deaktivierung und Bereinigung von NHIs zu adressieren, um die Persistenz ungenutzter Schlüssel oder veralteter Verbindungen zu verhindern, schaffen wir Sicherheitslücken. Aber wie wissen wir, wann wir am Ende des Weges für ein NHI angekommen sind, insbesondere wenn sein Schlüssel noch gültig ist?

Eine Antwort ist, dass es nicht mehr existieren sollte, wenn ein NHI keine Verbindung mehr zu einem anderen aktiven System herstellt. Dies gewährleistet, dass Angreifer nicht ausgediente NHI-Schlüssel ausnutzen können, um in Ihre Umgebung einzudringen. Denken Sie daran, dass Angreifer sich nicht darum kümmern, wie ein Schlüssel ordnungsgemäß verwendet werden sollte; sie kümmern sich nur darum, was sie damit tun können.

Indem Sie alle Beziehungen kartieren, die die Schlüssel eines NHI ermöglichen, können Sie feststellen, wann ein System nicht mehr mit einer anderen Identität verbunden ist. Sobald es keine weiteren Möglichkeiten gibt, für eine Identität zu kommunizieren, sollte sie und ihre Schlüssel nicht mehr existieren. Das bedeutet auch, dass der Schlüssel nicht mehr in Ihren Secrets Managern gespeichert werden muss, was Ihnen eine Sache weniger zum Speichern und Verwalten gibt.

Das Verständnis der Welt um Ihre NHIs ist entscheidend für die Sicherheit.

Im Jahr 2022 zeigte die Forschung von CyberArk, dass für jede menschliche Identität in einer Umgebung mindestens 45 nicht-menschliche Identitäten verwaltet werden müssen. Dieses Verhältnis liegt heute wahrscheinlich näher bei 1 zu 100 und nimmt stetig zu. Die beste Zeit, sich mit der Verwaltung und dem Lifecycle-Management von NHI auseinanderzusetzen, war vor Jahren. Die nächstbeste Zeit ist genau jetzt.

Es ist an der Zeit für einen ganzheitlichen Ansatz zur Sicherheit nicht-menschlicher Identitäten, der nicht nur darauf abzielt, wo sich Ihre NHI-Geheimnisse befinden, sondern ebenso wichtig ist, welche anderen NHIs verbunden sind. Wir sind in allen Branchen überfällig, NHI-Governance im großen Maßstab umzusetzen. Das Auffinden und ordnungsgemäße Speichern Ihrer Geheimnisse ist erst der Anfang der Geschichte. Wir müssen den Umfang der NHI-Geheimnisse besser dokumentieren und verstehen, ihr Alter, wer sie implementiert hat, und andere kontextbezogene Informationen wie beispielsweise wann sie rotiert werden sollten.

Auch wenn Maschinenidentitäten die Anzahl der menschlichen Wesen übertreffen, gibt es keinen Grund, alleine an der Lösung dieses Problems zu arbeiten; wir stecken alle gemeinsam darin.