IAM und PAM klingen ähnlich, beide behandeln Zugriffe, und beide tauchen in denselben Compliance-Anforderungen auf. Sie lösen jedoch unterschiedliche Probleme – ein vorhandenes IAM beantwortet die Frage nach PAM deshalb nicht mit.
Was ist IAM?
IAM beantwortet die Frage: Welche Identität gehört zu welcher Person – und worauf darf sie zugreifen? Es ist die Verwaltungsebene für sämtliche Identitäten einer Organisation: Mitarbeitende, Partner, Kunden und zunehmend auch technische Identitäten wie Service-Accounts.
Ein funktionierendes IAM sorgt dafür, dass eine neue Kollegin am ersten Arbeitstag genau die Zugänge hat, die sie für ihre Rolle benötigt – und dass diese Zugänge beim Austritt wieder entzogen werden. Typische Bausteine sind das automatisierte Anlegen von Zugängen aus dem HR-System (Provisioning), Single Sign-on, Multi-Faktor-Authentifizierung, rollenbasierte Berechtigungen und die regelmäßige Rezertifizierung.
Der Fokus von IAM liegt auf Produktivität bei kontrolliertem Zugriff, und zwar über viele Identitäten und viele Systeme hinweg. IAM ist damit in die Breite angelegt.
Was ist PAM?
PAM adressiert eine kleine, aber besonders kritische Teilmenge: privilegierte Konten. Dazu zählen Domain-Administratoren, root-Zugänge, Datenbank-Administratoren, Service-Accounts mit weitreichenden Rechten, Notfall-Konten und die Zugänge externer Dienstleister für die Fernwartung.
Diese Konten sind der Grund, warum PAM eine eigene Disziplin ist: Wer sie übernimmt, kann Sicherheitsmechanismen abschalten, Protokolle löschen und sich unbemerkt im Netz bewegen. Entsprechend anders sind die Werkzeuge – Passwörter liegen in einem Tresor statt bei einzelnen Personen, privilegierte Sitzungen werden aufgezeichnet, Rechte gelten nur für die Dauer einer konkreten Aufgabe, und das Least-Privilege-Prinzip wird konsequent durchgesetzt.
Der Fokus von PAM liegt auf Risikominimierung bei wenigen Konten, dafür mit engmaschiger Kontrolle und lückenloser Nachvollziehbarkeit. PAM ist damit in die Tiefe angelegt.
Wo genau liegt der Unterschied?
| IAM | PAM | |
|---|---|---|
| Geltungsbereich | Alle Identitäten – Mitarbeitende, Partner, Kunden, Maschinen | Nur privilegierte Konten – Admins, root, Service-Accounts |
| Leitfrage | Wer darf worauf zugreifen? | Wie sichern und überwachen wir die administrativen Zugänge? |
| Primäres Ziel | Produktivität bei kontrolliertem Standardzugriff | Risikominimierung dort, wo der Schaden am größten wäre |
| Typische Funktionen | Provisioning, SSO, MFA, Rollenmodell, Rezertifizierung | Passwort-Tresor, Session-Aufzeichnung, Just-in-Time-Rechte |
| Größenordnung | Hunderte bis Zehntausende Konten | Einige Dutzend bis wenige Hundert Konten |
| Schaden bei Missbrauch | Zugriff auf die Daten und Systeme einer Person | Kontrolle über ganze Systemlandschaften |
IAM regelt den Normalfall, PAM den Ausnahmefall – und der Ausnahmefall ist der, auf den Angreifer es abgesehen haben.
Warum reicht IAM allein nicht aus?
Weil Angreifer selten dort bleiben, wo sie hereingekommen sind. Der aktuelle Verizon Data Breach Investigations Report meldet eine Verschiebung beim Einstieg: Erstmals seit 19 Jahren sind gestohlene Zugangsdaten nicht mehr der häufigste initiale Angriffsvektor – ausgenutzte Schwachstellen haben sie mit 31 % überholt. Über die Bedeutung von Zugangsdaten insgesamt sagt diese Zahl allerdings wenig aus.
39 %
Der Einstieg erfolgt heute häufiger über eine ungepatchte Schwachstelle – doch was danach geschieht, läuft über Konten. Angreifer eskalieren Rechte, bewegen sich seitlich durch das Netz und greifen dabei auf genau die privilegierten Zugänge zu, die PAM absichert. IAM erfasst diesen Teil des Angriffs häufig nicht, weil er sich zwischen technischen Konten abspielt, die in keiner Rezertifizierung auftauchen.
Besonders deutlich wird das bei Ransomware:
73 %
Vor den meisten Ransomware-Vorfällen gab es also ein sichtbares Warnsignal in Form kompromittierter Zugangsdaten. Wer privilegierte Zugänge in einem Tresor hält, Sitzungen aufzeichnet und Rechte nur temporär vergibt, entwertet gestohlene Zugangsdaten: Sie eröffnen dann keinen nutzbaren Zugriff mehr.
Brauchen wir beides – und womit fängt man an?
Beide Disziplinen sind erforderlich – allerdings nicht gleichzeitig und nicht in beliebiger Reihenfolge.
PAM baut auf IAM auf. Ohne ein sauberes Identitätsverzeichnis weiß eine PAM-Lösung nicht, welcher Mensch hinter einem Admin-Konto steht, und Rollenwechsel oder Austritte hinterlassen Lücken. Umgekehrt gilt: Ein IAM, das die privilegierten Konten aussparen würde, hätte ausgerechnet dort keinen Zugriff, wo das Risiko sitzt.
Daraus ergibt sich diese Reihenfolge:
- Bestandsaufnahme. Welche Identitäten und Berechtigungen existieren überhaupt? Zu erfassen sind dabei auch die Service-Accounts, die keinem Verantwortlichen mehr zugeordnet sind.
- IAM-Grundlagen schaffen. Ein verlässliches Identitätsverzeichnis, das automatisierte Anlegen und Entziehen von Zugängen sowie flächendeckende Multi-Faktor-Authentifizierung.
- Privilegierte Zugänge priorisiert absichern. Dort ansetzen, wo der Schaden am größten wäre: Domain-Administratoren, Fernwartungszugänge externer Dienstleister, Konten mit Zugriff auf Produktionsdaten.
- Nachweisbarkeit herstellen. Protokollierung und Rezertifizierung so aufsetzen, dass sie einem Audit standhalten – und nicht erst kurz davor rekonstruiert werden müssen.
Wenn die Bestandsaufnahme aussteht, ist das der richtige Einstiegspunkt. Genau dafür haben wir unseren Security Kompass entwickelt.
Was fordern NIS-2 und DORA konkret?
Beide Regelwerke nennen weder „IAM“ noch „PAM“ als Produktkategorie – sie formulieren Anforderungen, die ohne diese Disziplinen kaum zu erfüllen sind. NIS-2 verlangt Konzepte für die Zugriffskontrolle, den Einsatz von Multi-Faktor-Authentifizierung und einen kontrollierten Umgang mit Berechtigungen.
Für Finanzunternehmen wird DORA konkreter: Artikel 9 verlangt, den Zugang zu Informations- und IT-Ressourcen auf das für rechtmäßige und zulässige Tätigkeiten erforderliche Maß zu beschränken, dafür eigene Konzepte, Verfahren und Kontrollen für Zugangs- und Zugriffsrechte festzulegen und deren gründliche Verwaltung sicherzustellen – ergänzt um die Vorgabe starker Authentifizierungsmechanismen. Die zugehörigen technischen Regulierungsstandards werden bei den privilegierten Konten dann ausdrücklich: Privilegierter Zugang, Notfallzugang und Administratorzugang sind nach dem Grundsatz der Nutzungsnotwendigkeit zu vergeben und zu protokollieren.
Für Fernwartungszugänge fordert das BSI zusätzlich ausdrücklich Beobachtbarkeit, Kontrolle und zentrale Verwaltung.
Verlangt ist dabei jeweils auch der Nachweis, dass die Maßnahmen greifen. Für privilegierte Zugriffe ist dieser Nachweis ohne PAM kaum zu führen. Wer die konkreten IAM-Anforderungen von NIS-2 im Detail nachlesen möchte, findet sie in unserem Beitrag Was fordert NIS-2 beim Identity and Access Management?.