Mit <kes>+ lesen

Warum PAM-Projekte scheitern : ... und wie man das vermeiden kann

Längst nicht alle Privileged-Access-Management-(PAM)-Projekte erreichen die gewünschten, oft hochgesteckten Ziele. In der Praxis sind häufig dieselben Fehler und Versäumnisse zu beobachten. Wer diese Fallen vermeidet, senkt seine Prozessrisiken und sorgt gleichzeitig für bessere Sicherheit.

Lesezeit 11 Min.

Von Martin Grauel, Frankfurt/Main

„Privileged Accounts“, also Konten mit höheren Berechtigungen wie zum Beispiel administrative Accounts, sind der Schlüssel zu hochsensiblen Unternehmensinformationen – einmal ins Visier von Angreifern geraten, werden solche Zugangsdaten leicht als Vehikel für Datenschutzverletzungen missbraucht und gestatten dabei den Zugriff auf die wertvollsten Assets im Unternehmen, von Datenbanken bis hin zu Social-Media-Konten.

Die meisten Unternehmen haben inzwischen in irgendeiner Form Privileged-Access-Management-(PAM)-Lösungen implementiert. Allerdings räumen viele ein, dass diese Initiativen nicht halten, was man sich von ihnen versprochen hat. Es gibt eine Reihe von Gründen, die dazu führen, dass PAM-Projekte nicht den gewünschten Erfolg haben und die meist hohen Erwartungen nicht vollständig erfüllen. Mithilfe einiger praktischer Erkenntnisse lässt sich aber durchaus verhindern, dass derartige Vorzeigeprojekte zum Blindgänger mutieren.

Der falsche Fokus

Beim Start von PAM-Projekten passiert es häufig, dass wesentliche geschäftliche Anforderungen zugunsten von technischen „Nice-to-have“-Features übersehen werden. Einige technische Funktionen mögen durchaus attraktiv erscheinen, obwohl sie für die Geschäftsabläufe keinen Mehrwert bieten: Agentenbasierte PAM-Implementierungen bieten beispielsweise ein scheinbar höheres Maß an forensischer Tiefe und Kontrolle, da sie auf einer tieferen Ebene als nicht-agentenbasierte PAM-Lösungen arbeiten – andererseits schwächeln solche Implementierungen möglicherweise, wenn es gilt einen größeren Umfang an Systemen (zum Beispiel inklusive aller Netzwerkgeräte) abzudecken. Agenten sind außerdem wartungsintensiv und produzieren zusätzlichen Netzwerkverkehr. Darüber hinaus speichern sie potenziell sensible Informationen auf den Endpunkten, die geschützt werden sollen. Für privilegierte Benutzer ist es überdies kein großes Problem, solche Agenten zu umgehen. Und nicht zuletzt stehen sie im Verdacht, den Implementierungsprozess generell zu verzögern.

Es klingt offensichtlich, dennoch ist es hilfreich, Firmen immer wieder zu ermutigen, sich auf ihre Unternehmensziele zu konzentrieren: Es muss klar sein, wie das optimale Ergebnis des PAM-Programms aus technischer und nutzerorientierter Sicht aussehen sollte. Dabei gilt es, das zentrale Anliegen des Projekts mithilfe von Key-Performance- (KPI) und Key-Risk-Indikatoren (KRI) im Auge zu behalten. Diese Indikatoren sind eine gute Hilfe, wenn man entscheiden muss, ob ein bestimmtes Merkmal oder eine bestimmte Funktion im konkreten Fall relevant sind oder nicht.

Man sollte die Rangfolge der Geschäftsziele festlegen und die Fortschritte bei der Umsetzung nachvollziehen. Es ist wichtig, Entscheidungsträger und die verschiedenen Interessengruppen innerhalb eines Unternehmens ins Boot zu holen – und zwar bevor man den technischen Funktionsumfang festlegt. Stellen Sie sicher, dass die Organisation sowohl vor externen als auch internen Bedrohungen geschützt ist. Denken Sie dabei auch an potenzielle Täter, die Insider-Konten stehlen oder missbrauchen, um weitere Datenschutzverletzungen zu begehen.

Prüfen Sie, welche Benutzer und Benutzergruppen Sie einbeziehen wollen:

  • Endbenutzer: Anwender, die administrative Funktionen von Computersystemen und Anwendungen als Bestandteil ihrer täglichen Arbeit nutzen. Die Zugriffe dieser Nutzer und ihre auf den Systemen ausgeführten Aktivitäten müssen kontrolliert werden – ebenso die damit verbundenen Prozesse hinsichtlich des Zugriffs auf Passwörter für privilegierte Konten und auf andere geheime Informationen (wie etwa API-Schlüssel). Immer wieder einmal ist die Rede von „reibungsloser“ Sicherheit – man muss sich fragen, was genau damit im Kontext privilegierter Zugriffe gemeint ist: Wenn Benutzer sich über PAM beschweren, dass etwa durch die Einführung solcher Systeme die Zugriffsprozesse komplizierter werden, findet man oft Äußerungen wie „Muss ich mich jetzt noch in ein weiteres System (PAM) einloggen, um auf ein Passwort zuzugreifen?“ – oder auch „Wie kann ich auf das PAM-System selbst zugreifen? Etwa mit einem weiteren Passwort?“ Fragen Sie sich selbst, wie Sie Sicherheitskontrollen so implementieren könnten, dass keine Reibungsverluste entstehen und existierende Arbeitsprozesse nicht beeinträchtigt werden. Das lässt sich beispielsweise über transparente Proxies bewerkstelligen, die Sessions aufzeichnen und zugleich die Passwortvergabe automatisieren.
  • Administratoren: Wer sind die für die tägliche Verwaltung des Systems verantwortlichen Administratoren? Sind das externe Mitarbeiter eines Managed-Service-Providers oder Herstellers? Wie werden ihre Zugriffe überwacht und wer überwacht die Einhaltung bestehender Richtlinien? Gibt es eine benutzerfreundliche Zwei-Faktor-Authentifizierung innerhalb dieses Prozesses? Wird Single Sign-on bei der Bereitstellung der verbundenen Identitäten genutzt?
  • Stakeholder und Interessengruppen: verlangen Berichte und Nachweise. Ist das PAM-System beispielsweise in der Lage, wichtige Events in das im Unternehmen verwendete SIEM-Tool zu exportieren? Dies sind etwa solche Events, die sich auf Veränderungen an der System-Konfiguration beziehen (siehe Administratoren). Kann das System Events übermitteln, die kritische Benutzer-Aktivitäten betreffen? Dazu gehören etwa das Ändern von Richtlinien zur Passwortvergabe oder der Zugriffskontrolle.

Ja, ein Unternehmen muss sicher sein und datenschutzkonform agieren – das sollte allerdings kein Anlass sein, um Benutzer zusätzlich zu belasten. Sonst gefährdet man am Ende die Effizienz des eigenen Hauses. PAM-Lösungen, die nur minimal in die Arbeitsabläufe der Benutzer eingreifen, werden langfristig besser funktionieren.

Zu viel Vertrauen

Es ist leichter als man denkt, ziel­sicher in die Falle zu tappen, Menschen zu sehr oder/und zu lange zu vertrauen. Die Rechtevergabe bei privilegierten Konten ist üblicherweise sehr weit gefasst und deckt einen großen Bereich ab. Das mag zunächst notwendig erscheinen, wenn man gewährleisten will, dass ein Unternehmen reibungslos funktioniert. Doch nicht selten werden solche Zugriffsberechtigungen dauerhaft vergeben – und das macht die Sache gefährlich. Denn braucht ein bestimmter Nutzer die vergebenen erhöhten Berechtigungen wirklich für immer?

Ein Beispiel hierfür ist das Hinzufügen eines Benutzers zu einer Domain-Administratoren-Gruppe im Active Directory (AD), anstatt fein abgestufte Zugriffsberechtigungen zu vergeben. Es versteht sich fast von selbst, dass das Risiko für eine schwerwiegende Datenschutzverletzung umso höher ist, je mehr Privilegien vergeben werden. So hat eine kürzlich durchgeführte Umfrage ergeben, dass zwei Drittel der weltweit Befragten sogar Partnern, Auftragnehmern oder Drittanbietern Zugriff auf privilegierte Konten gestatten.

Auf einen zu großen Vertrauensvorschuss sollte man vor allem bei Partnern außerhalb des Unternehmens aufgrund des zu hohen Risikos verzichten. Das Sicherheitsmodell, das für ein bestimmtes Unternehmen passgenau ist, wird hinsichtlich des Anforderungsprofils einzigartig sein, aber es gibt durchaus einige Best-Practice-Empfehlungen, die selbstverständlich sein sollten, wie etwa das Modell der minimalen Rechtevergabe. Wenn ein Nutzer mit administrativen Aufgaben für den DHCP-Server betraut ist, braucht er dann unbedingt auch Zugriff auf sämtliche Active-Directory-Domainserver?

Eine andere Möglichkeit ist ein „Trust but Verify“-Ansatz für privilegierte Zugriffe: Unternehmen können damit bestehende Zugriffsprozesse mit nur wenigen zusätzlichen Schritten aufrechterhalten – das kann etwa eine Multi-Faktor-Authentifizierung sein, kombiniert mit einem Monitoring und der Analyse des Benutzerverhaltens. Dadurch wird sichergestellt, dass die privilegierten Rechte nur im Rahmen der unternehmerischen Erfordernisse eingesetzt werden und der Endbenutzer die volle Verantwortung für diese Aktionen trägt.

Unterschätzte Komplexität

Eine durchaus gängige Fehleinschätzung lautet: PAM ist ein einfach zu lösendes Problem und keine vielschichtige Sicherheitsstrategie. Auf einer solchen Basis greifen viele Lösungen zu kurz, erreichen die anvisierten Ziele nicht oder scheitern komplett – eine Problematik, wie man sie auch aus anderen Bereichen des Identity- und Access-Managements (IAM) kennt. Silo-Denken ist bei PAM-Projekten noch weniger hilfreich als sonst und die Ergebnisse bleiben ohne eine umfassende Betrachtungsweise enttäuschend – nicht zuletzt entstehen dadurch auch unnötige Risiken.

Einer der größten Fehler, den Unternehmen typischerweise machen, ist die Gleichsetzung von Passwort-Management (PM) mit „PAM-Projekt“. Ein PM ist zwar ein nützlicher Teil einer PAM-Strategie, aber keine ausreichende Maßnahme. Und sie ist schon gar nicht geeignet, sämtliche mit privilegierten Benutzern verbundene Herausforderungen zu lösen. Nicht selten schafft man zusätzliche Hürden bei den Zugriffen, zum Beispiel wenn man gezwungen ist, ein Passwort erst manuell abzurufen, bevor man auf das betreffende System zugreifen kann.

Erst zusätzliche Sicherheitslayer wie Session-Monitoring (mit automatisierter und transparenter Passwort-Injection) inklusive Analyse sorgen dafür, dass sich Investitionen an dieser Stelle bezahlt machen und der gesamte Prozess effizienter abläuft. Multi-Faktor-Authentifizierung ist grundsätzlich ein wirksames Tool, um den berechtigten Zugriff zu sichern. Wenn man sie allerdings nicht mit anderen PAM-Komponenten wie der Analyse des Benutzerverhaltens kombiniert, beeinträchtigt sie die Benutzererfahrung – etwa durch unnötige Authentifizierungsanfragen während einer einzigen Arbeitssitzung.

Nur einige wenige Disziplinen zu behandeln, kann man eben nicht als vollständiges PAM-Programm betrachten. Ein ganzheitlicher PAM-Ansatz sollte zumindest die nachfolgend aufgeführten Komponenten umfassen.

Multi-Faktor-Authentifizierung

Moderne Verfahren wie aktive Push-Benachrichtigungen verbessern die Benutzererfahrung und senken die Reibungsverluste bei der Einführung von PAM. Die richtigen Leute müssen zudem zur richtigen Zeit über wichtige Sicherheitsvorkommnisse wie zum Beispiel ausstehende Bewilligungen informiert werden.

Passwort-Verwaltung

Mit dem Begriff PAM wird oft assoziiert, dass es sich um ein Speichersystem für Zugangsdaten wie Passwörter handelt. Diese Technik gibt es schon eine Zeit lang und sie ist entsprechend ausgereift: Endbenutzer sind weder gezwungen, sich komplizierte Passwörter zu merken noch zu notieren oder sie mit Kollegen austauschen. Passwörter dürfen komplexer und länger sein. Passwörter für gemeinsam genutzte Konten kann man in sogenannten Vaults abgelegen – und es existiert ein einheitlicher Prozess für den Abruf dieser Passwörter. Nach jedem abgeschlossenen Zugriff werden Passwörter dann automatisch und gemäß den vergebenen Richtlinien neu generiert.

Allerdings kann es passieren, dass diese Veränderungen bestehende Geschäftsprozesse beeinträchtigen, was zu Reibungsverlusten am Arbeitsplatz führen kann. Das trifft besonders auf „remote“ oder ausgelagert arbeitende Beschäftigte zu, bei denen die Geschäftsprozesse Teil der zugrunde liegenden Service-Level-Agreements sind.

Delegation

  • Unix-Root-Delegation: Mit Unix- oder Mac-Betriebssystemen jeglicher Couleur sind oftmals Bedenken in Zusammenhang mit dem Root-Level verbunden, den alle Unix-basierten Systeme gemeinsam haben. Compliance-Anforderungen lassen sich aber über das Delegieren von Rechten und Techniken wie einem Active-Directory-Bridging abbilden. Das Konzept der minimalen Rechtevergabe, kombiniert mit der Integration in Active Directory, senkt das Risikopotenzial und ergänzt die Administration von Unix-Systemen um wertvolle Sicherheitsaspekte.
  • Delegieren von Administrator-Rechten in Active Directory: Dies erhöht die Sicherheit und senkt die Risiken, da AD- und Azure-Active-Directory-(AAD)-Administratoren nur genau die Rechte zugewiesen bekommen, die sie brauchen, um ihre Aufgaben zu erledigen – nicht mehr und nicht weniger. Vorkonfigurierte Vorlagen decken die meisten der üblichen Delegations-Szenarien ab (einschließlich der Administration von Office365 und Exchange Online). Gleichzeitig stehen komplett individualisierbare Vorlagen für spezifische PAM-Anforderungen zur Verfügung.
  • Delegieren lokaler Windows-Administratorrechte: Echtzeit-Anfragen für erhöhte Rechte (auf Administratorenebene) auf lokaler Ebene verknüpft mit einem Genehmigungs-Workflow gewährleisten die Sicherheit lokaler Windows-Systeme und stellen die erforderlichen Berechtigungen für Endbenutzer bereit. In der Praxis heißt das: deutlich weniger Help-Desk-Anrufe und geringere Angriffsfläche.

Session-Monitoring

Ein transparentes Session-Monitoring beeinträchtigt weder die Workflows der Nutzer noch die Auswahl der nutzbaren Admin-Tools – dank „Proxy“-Modus kann ein solches Monitoring für Nutzer und Server gleichermaßen unsichtbar im Hintergrund ablaufen: Administratoren können bestehende Client-Applikationen, mit denen sie vertraut sind, weiterhin nutzen und ohne Unterbrechung auf Server und Anwendungen zugreifen. Gleichzeitig deckt das Session-Monitoring fragwürdige oder als böswillig einzustufende Aktivitäten auf und beendet entsprechende Sessions bei Bedarf.

Analyse des Verhaltens privilegierter Nutzer

Zunächst ist zu definieren, was als „normal“ gelten soll. Hierzu dienen regelmäßig wiederkehrende Muster im täglichen Ablauf und die Art und Weise, wie Administratoren üblicherweise mit Systemen interagieren. Weicht ein Verhalten von dieser erlernten „Baseline“ ab, schickt das System eine Benachrichtigung an die Sicherheitsabteilung, ist aber – in Abhängigkeit von der jeweiligen Systemkonfiguration – auch in der Lage, Zugriffsberechtigungen unmittelbar zu entziehen.

Vergessene Identity-Governance

Im Rahmen der Privileged-Identity/Account-Governance (PIG/PAG) ist die Erkenntnis wichtig, dass es sich bei privilegierten Konten um ein Hauptziel von Angreifern im Zusammenhang mit Datenschutzverletzungen handelt. In größeren Unternehmen hat das dazu geführt, dass der Wunsch nach einer umfassenden, zentralisierten Identity-Governance-Strategie größer geworden ist. Dazu gehört nicht nur eine PAM-Lösung: Eine solche Strategie schließt sämtliche Informationen zu Benutzeridentitäten, Zugriffsberechtigungen und Assets mit ein.

Für Unternehmen liegt darin ein großer Vorteil, denn sie können auf dieser Basis Risikobewertungen hinsichtlich ihrer kompletten Geschäftstätigkeit durchführen und sämtliche Bereiche potenzieller Gefährdungen adressieren. Erfolgreiche PAM-Programme sind zumeist eine Kombination aus der richtig ausgewählten Technik sowie internen Richtlinien und Mitarbeitern, die alle gleichermaßen daran arbeiten, eine übergreifende Governance zu erreichen. Zwar ist die Wahl der passenden Technik und Verfahren wichtig – sobald man PAM jedoch nur als „Technologie“ versteht, werden die grundlegenden Probleme nicht gelöst, sondern vergrößern sich eher. Jedes PAM-Projekt sollte also unter der Leitlinie „Governance“ durchgeführt werden!

Fazit

Wer in seinem Unternehmen mit einer PAM-Initiative startet, der sollte sich in erster Linie auf die geschäftlichen Erfordernisse konzentrieren und weniger auf technische Features um der Features willen. Man sollte einen bewährten und nachvollziehbaren Ansatz implementieren, der verschiedene PAM-Sicherheitsebenen miteinander kombiniert. Diese Ebenen sollten nahtlos integriert werden können und miteinander interagieren. Die Gesamtlösung sollte entweder aus einer Hand stammen oder doch mit möglichst wenigen Anbietern auskommen.

Wer das Optimum aus seinen Investitionen herausholen will, sollte versuchen, ein Gesamtbild zu visualisieren und die altbekannte „Project-in-a-Box“-Mentalität ad acta legen. Die übergreifende Leitlinie für alle Aspekte ist Governance.

Wenn Unternehmen sich beim Planen und Umsetzen eines PAM-Projektes an diese grundlegenden Überlegungen halten, läuft der Prozess sehr viel effizienter ab. Gleichzeitig sinkt das Risiko für Angriffe auf unzureichend verwaltete privilegierte Konten.

Martin Grauel ist Technical Sales Manager EMEA bei One Identity.

Diesen Beitrag teilen: