Wenn der Admin zu viele Rechte hat, kommt es im schlimmsten Fall dazu, dass diese Rechte missbraucht werden. So geschehen im Fall von Attila Hildmann. Der Admin des Coronaleugners und Antisemiten hatte dem Hackerkollektiv Anonymous, diversen Medien – darunter Spiegel, NDR und ARD – und Ermittlungsbehörden einen mehr als zwei Terabyte großen Datensatz mit sensiblen Informationen über seinen ehemaligen Arbeitgeber und Freund zugespielt. Sie gewähren offenbar Einblicke hinter die Kulissen des Verschwörungstheoretikers und zeigen, wie rasch sich der ehemalige Vegankoch radikalisierte.

Dass sich der Admin eines durchgedrehten Kochs an dessen sensiblen Daten vergreift, ist das eine. Hildmann hatte seinem Admin offenbar vertraut und ihm umfassenden Zugriff auf sein digitales Leben gegeben. Dem waren die Machenschaften und Verwirrungen Hildmanns offenbar zu viel geworden – und er beschloss, diesen Zugriff zu verwenden, um Hildmann in die Pfanne zu hauen.

Davon abgeleitet, stellt sich die Frage: Wie viel Macht haben Administrator:innen eines Unternehmens eigentlich? Wie wird gewährleistet, dass ein:e Admin zwar Zugriff auf Datenbanken, Server und Netzwerkgeräte hat, um seine oder ihre Arbeit zu erledigen, jedoch nicht so umfassenden Zugriff, dass er oder sie unbemerkt Daten entwenden könnte oder ein erhöhtes Risiko besteht, dass Dritte an diese Zugangsdaten gelangen könnten?

Der Fachbegriff für das Management der Vergabe der erweiterten Benutzerrechte an eine:n Admin lautet Privileged Access Management, kurz PAM. Vor dem Aufkommen von Cloud-Services, Big Data, Dev-Ops und Containertechnologien reichte es aus, dass alle Systemadmins über ein gemeinsames Root-Konto auf einen Server, eine Datenbank oder ein Netzwerkgerät zugreifen konnten.

Die Zugangsdaten für das Rootkonto werden mit einem herkömmlichen PAM-Ansatz in einem gesicherten Repository gesammelt. So wird das Risiko, dass diese Zugangsdaten von Mitarbeiter:innen selbst oder von Außenstehenden missbraucht werden, verringert. Über einen VPN-Tunnel greifen Admins dann auf die entsprechenden Ressourcen zu. Für lokale Ressourcen funktioniert dieser Ansatz gut. Moderne Umgebungen umfassen neben Infrastruktur, Datenbanken und Netzwerkgeräten allerdings auch Cloud-Umgebungen, Big-Data-Projekte, Container und Microservices, die an die Stelle eines einzelnen Servers getreten sind.

An dieser Stelle scheitert der beschriebene PAM-Ansatz. Zum einen aus Gründen der Flexibilität: Cloud-Ressourcen werden ständig – je nach Bedarf – nach oben und unten skaliert. Eine herkömmliche PAM-Lösung scannt Umgebungen in regelmäßigen Abständen, allerdings nicht häufig und schnell genug, um mit der sich ständig ändernden Cloud Schritt zu halten. Dies würde dazu führen, dass die Umgebung zeitweise nicht überwacht würde, wenn sich Unternehmen für ihre Cloud-Umgebungen auf eine herkömmliche PAM-Strategie mit dauerhaften Zugriffskonten mit gleichbleibenden Berechtigungen verlassen.

Zum anderen machen statische Berechtigungen eine Umgebung anfälliger für Angriffe von innen und von außen. Sie gewähren den Administrator:innen dauerhafte Zugriffsrechte auf Ressourcen, die sie zur Ausführung ihrer derzeitigen Aufgaben nicht benötigen.

Zero Trust Privilege nennt sich ein neuerer, besser auf die Bedürfnisse moderner Unternehmen zugeschnittener Ansatz des Privileged Access Managements. Basiert der oben beschriebene frühere Ansatz auf dem Prinzip „Vertrauen und regelmäßig überprüfen“, setzt Zero Trust bei der Vergabe erweiterter Zugriffsrechte auf das Motto „niemals vertrauen, immer überprüfen“ und setzt auf die zeitlich begrenzte Vergabe von Zugriffsrechten, die jeweils nur so weitreichend sind, wie es zur Ausführung einer Aufgabe nötig ist. Überprüft werden dabei sowohl die Person, die den Zugriff beantragt, der Kontext der Anfrage und das daraus entstehende Risiko. Der Zero-Trust-Ansatz sorgt dabei nicht nur für verbesserte Transparenz, sondern kann auch die Einhaltung von Vorschriften erleichtern sowie das Risiko, die Komplexität und die Kosten für moderne Unternehmen verringern.

Um deren veränderten Anforderungen gerecht zu werden, muss ein Zero-Trust-Privilege-Ansatz sowohl mit von Menschen gestellten Zugriffsanfragen, als auch mit solchen, die von Maschinen, Diensten oder APIs gestellt werden, klarkommen. Statt gemeinsam genutzter Accounts empfehlen Best Practices dabei individuelle Identitäten, denen dann je nach Request passgenau die geringstmöglichen Zugriffsrechte erteilt werden können. Die Vergabe von Zugriffsrechten muss damit in einem viel breiteren Rahmen stattfinden und IaaS- und CI/CD-Pipeline-Tools wie AWS, Azure und Ansible oder Hashicorp und Containerlösungen wie Kubernetes und Docker integrieren und auch damit interagieren.