Policy-Risiken verstehen. Fragen zu Policies in natürlicher Sprache stellen. Demo anfragen →

Published:

Über Least Privilege, JIT und starke Autorisierung

by Rich Mogull

Ich bin seit über 20 Jahren als Sicherheitsexperte tätig. Ich kann unmöglich zählen, wie oft ich die Worte „Least Privilege“ ausgesprochen habe. Es ist eine Art kleines Mantra, das auf derselben Bank sitzt wie „Defense in Depth“ und „Insider Threat“.

Doch jemandem zu sagen, er solle Least Privilege durchsetzen, und dann den Raum zu verlassen, entspricht einem Arzt, der Ihnen sagt, Sie sollten sich „gesünder ernähren“, Sie bei der Versicherungsuntersuchung durchfallen lässt und den Raum verlässt, bevor er Ihnen zu viel berechnet.

Least Privilege ist real. Es ist wichtig. Anders als das Ändern von Passwörtern alle 90 Tage kann es Ihre Sicherheit spürbar verbessern.

Least Privilege ist außerdem wirklich schwierig. Besonders in großem Maßstab. Und für Ihre wichtigsten Benutzer funktioniert es nicht.

Warum? Weil Least Privilege nicht die geringsten Berechtigungen sind, die Sie in diesem Moment benötigen, sondern die geringsten Berechtigungen, die Sie jemals für Ihre Arbeit benötigen könnten … jemals. Und wenn jemand etwas tun muss, das außerhalb des Bereichs liegt, für den diese Berechtigungen ursprünglich zugeordnet wurden, stößt das einen langsamen Änderungsprozess an, der verschiedene Teams und Vorgesetzte durchlaufen muss.

Oder manchmal müssen Sie einfach Bob überreden, Ihnen Zugriff zu geben. Und Bob ist ein ziemlich abweisender Griesgram, weil er niemandem traut und nicht die Schuld tragen will, wenn Sie etwas vermasseln.

Selbst mit Least Privilege gilt: Wenn ein Angreifer an diese Anmeldedaten gelangt (die Hauptursache für Cloud-native Sicherheitsverletzungen), kann er wahrscheinlich trotzdem Schaden anrichten. Denn auch wenn Least Privilege für durchschnittliche Benutzer oder Mitarbeitende nicht allzu schwer umzusetzen ist, lässt es sich bei Entwicklern und Administratoren, die naturgemäß mehr Berechtigungen benötigen, nur sehr schwer durchsetzen.

So wie wir MFA für starke Authentifizierung haben, brauchen wir etwas für starke Autorisierung.

Hier kommt Just in Time (JIT) ins Spiel. Anstatt im Voraus alle Berechtigungen zu ermitteln, die jemand benötigt, können zeitlich begrenzte Berechtigungen jederzeit angefordert werden. Ich bin inzwischen der Überzeugung, dass JIT der Standard für administrativen und sensiblen Zugriff sein sollte.

Ich empfehle: Least Privilege ist ein hervorragendes Konzept für allgemeinen Benutzerzugriff, aber JIT ist besser für jede Form von Admin-, Entwickler- oder sensiblem Zugriff in der Cloud.

Just in Time

JIT ist eine Spielart von PIM/PAM. Privileged Access Management und Privileged Identity Management sind Systeme, die dazu dienen, die Berechtigungen eines Benutzers zu erhöhen. Benutzer arbeiten mit einer niedrigeren Berechtigungsstufe, bis eine Erhöhung nötig ist, und diese Systeme nutzen mehrere Techniken, um erweiterten Zugriff bereitzustellen, in der Regel für eine zeitlich begrenzte Sitzung. Heute ist nicht der Tag, um auf die Feinheiten einzugehen, aber der Vorteil ist, dass sie Flexibilität ermöglichen und gleichzeitig die Sicherheit wahren. Zusätzliche Berechtigungen müssen bei Bedarf angefordert werden, sodass ein Angreifer selbst bei kompromittierten Anmeldedaten eingeschränkt bleibt.

„JIT“ (Just in Time) ist eine Technik für PAM/PIM (oder eigentlich für jede Art von Zugriff). Ein Benutzer verfügt über Basis-Anmeldedaten, die möglicherweise überhaupt keinen Zugriff gewähren, und seine Berechtigungen werden auf Anfrage erhöht. Wir selbst nutzen JIT (und es ist verfügbar in Cloud Defense), und Netflix hat ein Open-Source-Tool namens ConsoleMe veröffentlicht, das auf ihrem internen Tool basiert. Azure verfügt über einen integrierten (aber kostenpflichtigen) Dienst namens Entra ID Privileged Identity Management. (Entra ID hieß früher Azure AD, bevor jemand entschied, dass es eine gute Idee sei, Millionen von Kunden aus Branding-Gründen zu verwirren.) Es gibt weitere Optionen, dies sind nur Beispiele.

Um die Sicherheit zu erhöhen, muss JIT einen Out-of-Band-Genehmigungsprozess verwenden und zeitlich begrenzten Zugriff gewähren. Das sind die Grundlagen. Anfrage und Genehmigung sollten über einen anderen Pfad laufen als die normale Authentifizierung, ähnlich einer Form von MFA. Der Unterschied besteht darin, dass MFA ein Out-of-Band-Faktor für die Authentifizierung ist (der Nachweis, dass Sie die Person sind, die Sie vorgeben zu sein), während JIT eine Form der Autorisierung ist (Sie fordern die Erlaubnis für eine Handlung an und erhalten sie).

Reibungsverluste managen

Sowohl Least Privilege als auch JIT erzeugen Reibung. Nun ja, alles, was wir in der Sicherheit tun, erzeugt irgendeine Form von Reibung, besonders Bob. Bei Least Privilege besteht die Hauptreibung im Aufwand, Berechtigungen zu definieren und auszurollen, und darin, was kaputtgeht, wenn jemandem benötigte Berechtigungen fehlen. Bei JIT besteht die Reibung im Prozess des Einreichens und Erhaltens einer Genehmigung.

Da ich sowohl Least Privilege als auch JIT lange genutzt und erforscht habe, kenne ich inzwischen Techniken, um die Reibung zu verringern. In manchen Fällen erhalten Sie am Ende schnellere und bessere Prozesse, als wir sie historisch hatten

  • Der Anfrage- und Genehmigungsprozess muss in Echtzeit ablaufen. Das bedeutet Genehmigungen über ChatOps, Textnachrichten oder den 5G-Chip, der Ihnen mit der COVID-Impfung implantiert wurde.
  • Für Zugriffe mit geringeren Berechtigungen, etwa Lesezugriff auf bestimmte Logs, können und sollten Sie eine Selbstgenehmigung unterstützen. Wie hilft das? Weil dabei weiterhin der Out-of-Band-Prozess genutzt wird und es für einen Angreifer schwerer wird, verlorene, gestohlene oder offengelegte Anmeldedaten auszunutzen.
  • Sie können auch automatische Genehmigungen unterstützen, bei denen Sie nicht einmal zur Selbstgenehmigung wechseln müssen. Wie hilft das? Sie können automatisch genehmigen und dennoch Ihren Out-of-Band-Kanal nutzen, um über die Erhöhung der Berechtigungen zu informieren. Sie haben das wahrscheinlich schon erlebt, wenn Sie Ihrem Konto ein Netflix- oder Hulu-Gerät hinzugefügt haben. Allein die Aufmerksamkeit kann außerordentlich wirksam sein.
  • Wenn dies für Entwickler gedacht ist, müssen Sie die Kommandozeile und die anderen von ihnen genutzten Tools unterstützen. Gehen Sie zu ihnen. Machen Sie die Nutzung denkbar einfach. Wenn Sie sie zwingen, sich in ein Sicherheitstool einzuloggen, wird das Projekt scheitern.
  • Wenn die genehmigenden Personen nicht reagieren, und zwar sofort, werden Sie scheitern. Machen Sie Bob nicht zum einzigen Genehmiger.

Bringen Sie diese Funktion Ihren Entwicklern und Administratoren in den Tools nahe, die sie ohnehin nutzen. Machen Sie es schnell und reibungslos. Idealerweise einfacher und schneller, als einen Passwortmanager zu öffnen oder sich durch ein SSO-Portal mit 374 zur Auswahl stehenden Cloud-Konten zu klicken. Kaufen Sie Bob ein paar Kekse. Mit Schokostückchen. (Ach Moment, das bin ja ich.)

Sie können Automatisierung auch nutzen, um die Reibung bei Least-Privilege-Zugriffen zu verringern. Die Duckbill Group hat mit Unterstützung von Chris Farris eine eigene Version von automatisiertem Least Privilege mit anderer Technik umgesetzt. Tools wie AWS Access Advisor helfen Ihnen dabei, genutzte Berechtigungen zu überwachen und einzugrenzen. Automatisierung hilft Ihnen, Least Privilege in großem Maßstab umzusetzen, und kann auch eine Ergänzung zu JIT sein.

Wann was einzusetzen ist

Least Privilege ist keineswegs ein überholtes Konzept. Es ist nach wie vor der Goldstandard für alltägliche Benutzer und Mitarbeitende, die ein ziemlich gleichbleibendes Zugriffsniveau benötigen. JIT eignet sich am besten für höher privilegierte Zugriffe, insbesondere auf Produktionsumgebungen und ganz besonders in der Cloud, wo offengelegte Anmeldedaten DIE größte Ursache für Sicherheitsverletzungen sind. Hier setzen wir es selbst ein:

  • Lesezugriff von Entwicklern auf die Produktion.
  • Änderungszugriff von Entwicklern auf die Produktion (außerhalb von CI/CD). Weitaus stärker eingeschränkt und mit mehr erforderlichen Genehmigern.
  • Administrativer Zugriff auf Produktionskonten.
  • Zugriff für Incident Response.
  • Zugriff auf einige Entwicklungskonten, da dies schneller sein kann, als zum SSO-Portal zurückzukehren, insbesondere bei der Arbeit auf der Kommandozeile.

Ich halte Least Privilege allein nicht mehr für ein tragfähiges Konzept für nennenswert privilegierte Zugriffe in der Cloud (IaaS/PaaS), selbst wenn wir starke MFA einsetzen. Es ist zu schwierig, Berechtigungen in großem Maßstab und über die Zeit hinweg sauber zuzuschneiden. JIT ist in diesen Anwendungsfällen die weitaus bessere Option. Least Privilege bleibt sehr sinnvoll, wenn über längere Zeit gleichbleibende Berechtigungen benötigt werden, insbesondere in Kombination mit guter Zugriffsprotokollierung und MFA. JIT ist das Gegenstück zu MFA. Es ist die starke Autorisierung als Ergänzung zu Ihrer starken Authentifizierung. Während wir immer mehr kritische Abläufe in Management-Ebenen verlagern, die dem Internet ausgesetzt sind, ist JIT der richtige Weg.

Least Privilege, JIT und starke Autorisierung | FireMon