Privileged Access Management. Der Schutz von Identitäten und Zugängen ist elementar

„Wer kann sich bei Ihnen eigentlich mit Administratorrechten anmelden?“ Auch das ist eine dieser Fragen, auf die es in der Praxis erstaunlich oft keine eindeutige Antwort gibt. Meistens sind die offensichtlichen Admin-Konten bekannt. Spannend wird es bei lokalen Administratoren, Servicekonten, technischen Benutzern oder alten Zugängen, die irgendwann einmal eingerichtet wurden und seitdem einfach funktionieren.

Genau hier setzt Privileged Access Management, kurz PAM, an.

Wenn IAM die Regeln definiert, setzt PAM sie technisch durch

In meinem letzten Beitrag ging es um Identity & Access Management und darum, Berechtigungen strukturiert zu vergeben, regelmäßig zu überprüfen und nach dem Least-Privilege-Prinzip auf das tatsächlich Notwendige zu beschränken. PAM ist für mich die technische Veredelung eines solchen IAM- und Berechtigungskonzepts.

Denn gerade privilegierte Konten benötigen einen besonderen Schutz. Ein normales Benutzerkonto kann bereits erheblichen Schaden verursachen, wenn es kompromittiert wird. Mit einem Administrator-, Root- oder hoch privilegierten Cloud-Konto sieht die Situation noch einmal ganz anders aus. Wer solche Zugänge kontrolliert, besitzt oft weitreichende Möglichkeiten: Systeme konfigurieren, Benutzer anlegen, Sicherheitsmechanismen verändern oder auf besonders sensible Daten zugreifen.

Deshalb reicht es nicht zu wissen, wer Administrator sein darf. Es muss auch kontrolliert werden, wie diese privilegierten Rechte tatsächlich genutzt werden.

PAM ist mehr als ein Passwort-Tresor

PAM wird häufig zuerst mit einem sicheren Speicher für Administrator-Passwörter verbunden. Das ist ein wichtiger Bestandteil, greift aber zu kurz.

Eine PAM-Lösung kann privilegierte Zugangsdaten zentral verwalten und Passwörter automatisiert ändern. Im Idealfall kennt der Administrator das eigentliche Kennwort überhaupt nicht mehr. Darüber hinaus können privilegierte Zugriffe kontrolliert vermittelt und nachvollziehbar gemacht werden.

Typische Möglichkeiten sind beispielsweise:

• zentrale Verwaltung privilegierter Zugangsdaten
• automatische Passwortrotation
• Multi-Faktor-Authentifizierung für kritische Zugriffe
• zeitlich begrenzte Berechtigungen
• Freigabeprozesse für besonders sensible Systeme
• Protokollierung und Aufzeichnung administrativer Sitzungen
• kontrollierter Zugriff auf Server, Datenbanken, Netzwerkgeräte oder Cloud-Systeme
• Verwaltung technischer Accounts und Secrets

Besonders interessant finde ich den Gedanken hinter Just-in-Time Access: Administratorrechte werden nicht dauerhaft vergeben, sondern nur dann bereitgestellt, wenn sie tatsächlich benötigt werden. Das entspricht letztlich genau dem Least-Privilege-Prinzip aus dem IAM. Nur eben technisch konsequenter umgesetzt.

Nicht nur Administratoren sind privilegiert

Bei PAM denken viele zuerst an Domain Admins oder klassische Serveradministratoren. In der Realität liegt ein großer Teil der Herausforderung aber an anderer Stelle.

Servicekonten, Datenbankbenutzer, lokale Administratoren, technische Schnittstellen oder API-Zugangsdaten besitzen teilweise erhebliche Berechtigungen. Gleichzeitig stehen diese Identitäten deutlich seltener im Fokus.

Ein Servicekonto kann jahrelang existieren. Das Passwort wird nicht geändert, weil niemand genau weiß, welche Anwendung danach möglicherweise nicht mehr funktioniert. Der ursprüngliche Verantwortliche ist längst nicht mehr im Unternehmen und trotzdem läuft der Account weiter.

Genau solche Situationen machen PAM-Projekte interessant – und manchmal auch unangenehm. Denn bevor ich privilegierte Zugänge schützen kann, muss ich sie zunächst kennen.

Die wichtigste Vorarbeit: Transparenz schaffen

Ein PAM-Projekt sollte deshalb meiner Meinung nach nicht mit der Frage beginnen: „Welches Produkt kaufen wir?“

Die erste Frage sollte lauten: Welche privilegierten Identitäten und Zugänge haben wir überhaupt?

Und direkt danach: Welche davon sind wirklich kritisch?

Diese Discovery- und Analysephase ist elementar. Neben den klassischen Administratoren müssen beispielsweise lokale Admin-Konten, Service Accounts, Datenbankzugänge, Netzwerkgeräte, Backup-Systeme, Cloud-Rollen und technische Accounts betrachtet werden.

Danach braucht es ein Berechtigungskonzept. Wer benötigt welchen privilegierten Zugriff? Muss dieser dauerhaft bestehen? Wer genehmigt ihn? Wie lange darf er verwendet werden? Was passiert im Notfall?

Auch technische Abhängigkeiten müssen verstanden werden. Gerade bei Servicekonten kann eine unüberlegte Passwortänderung schnell dazu führen, dass eine Anwendung nicht mehr funktioniert.

PAM ersetzt diese Vorarbeit nicht. Im Gegenteil: Eine PAM-Plattform kann nur sinnvoll automatisieren, was vorher organisatorisch verstanden und definiert wurde.

Eine der größten Herausforderungen sitzt vor dem Bildschirm

PAM verändert Arbeitsweisen. Ein Administrator, der sich bisher direkt auf einen Server verbunden hat, soll plötzlich über eine zentrale Plattform gehen. Vielleicht ist zusätzlich MFA notwendig, vielleicht eine Freigabe oder ein definierter Workflow.

Technisch ist das sinnvoll. Für den Administrator bedeutet es zunächst aber häufig zusätzliche Schritte. Und genau hier entscheidet sich ein Stück weit der Erfolg.

Eine PAM-Lösung, die in der täglichen Arbeit nur als Hindernis wahrgenommen wird, erzeugt früher oder später Umgehungslösungen. Deshalb sollten die betroffenen Administratoren frühzeitig eingebunden werden.

Security muss sicher sein – aber sie muss auch praktikabel bleiben.

Das gilt auch für Session Recording und Protokollierung. Ziel sollte nicht sein, Administratoren unter Generalverdacht zu stellen. Es geht um Nachvollziehbarkeit bei besonders kritischen Zugriffen. Im Falle eines Fehlers oder Security Incidents kann genau diese Transparenz für alle Beteiligten wertvoll sein.

Auch bei PAM: nicht alles auf einmal

Wie beim IAM halte ich wenig davon, PAM direkt als riesiges Gesamtprojekt zu starten. Man kann mit besonders kritischen Zugängen beginnen. Zum Beispiel mit Domain-Administratoren, zentralen Servern oder hoch privilegierten Cloud-Rollen.

Danach lässt sich der Schutz schrittweise erweitern: Servicekonten, Netzwerkkomponenten, Datenbanken, Backup-Systeme, Secrets oder weitere administrative Plattformen können nach und nach integriert werden.

So wächst nicht nur die technische Lösung, sondern auch das Know-how innerhalb der Organisation. Das ist aus meiner Sicht wesentlich nachhaltiger als der Versuch, am ersten Tag jedes privilegierte Konto im Unternehmen abzudecken.

Der eigentliche Erfolg zeigt sich nach dem Projekt

Ein PAM-Projekt kann technisch sauber umgesetzt sein und trotzdem langfristig scheitern. Dann nämlich, wenn nach dem Go-live niemand mehr dafür sorgt, dass neue Systeme und Konten aufgenommen werden.

Privileged Access Management ist kein einmaliges Projekt. Neue Server entstehen. Anwendungen kommen hinzu. Cloud-Rollen verändern sich. Servicekonten werden angelegt und Mitarbeiter wechseln ihre Aufgaben.

Deshalb muss bereits während der Einführung geklärt werden, wie PAM später betrieben wird. Wer ist verantwortlich? Wie werden neue privilegierte Konten erkannt und aufgenommen? Wer überprüft bestehende Ausnahmen? Wie werden Notfallzugänge behandelt? Und wer stellt sicher, dass die PAM-Plattform selbst aktuell und verfügbar bleibt?

Ein gutes Betriebsmodell ist für mich mindestens genauso wichtig wie die technische Einführung.

Denn ein PAM schützt nur die privilegierten Zugänge, die es auch kennt.

Zusammengefasst

Für mich gehört PAM heute zu den wichtigsten technischen Bausteinen eines ausgereiften Identity & Access Managements. Das IAM definiert die Regeln und Verantwortlichkeiten. Das Berechtigungskonzept legt fest, wer welche Rechte benötigt. PAM macht daraus kontrollierbare technische Zugriffe.

Und auch hier gilt wieder: Man muss nicht sofort perfekt sein. Entscheidend ist, die besonders kritischen Zugänge zu identifizieren und anzufangen.

Eine gute Standortbestimmung beginnt deshalb mit einer einfachen Frage:

Könnten Sie heute nachvollziehen, wer zuletzt mit privilegierten Rechten auf Ihren wichtigsten Systemen gearbeitet hat – und warum dieser Zugriff notwendig war?

Wenn die Antwort nicht eindeutig ausfällt, wäre das für mich ein ziemlich guter Grund, sich mit PAM etwas genauer zu beschäftigen.

Die Grundlagen dazu – Governance, Rollen, Rezertifizierung und das Least-Privilege-Prinzip – behandelt der vorherige Beitrag: Identity & Access Management – wer darf hier eigentlich was?