Ein kompromittiertes Konto ist vor allem deshalb gefährlich, weil es nach dem ersten Sicherheitsverstoß bestimmte Aktionen ausführen kann. Wenn ein gestohlener Benutzerzugang auf jeden Server zugreifen kann, ein Administrator einer Agentur jede Kundenumgebung verändern darf oder ein Dienstkonto Backups löschen kann, kann aus einem einzelnen Vorfall ein unternehmensweiter Ausfall werden.
Das Prinzip der geringsten Rechte ist ein praktischer Ansatz, um diesen Schadensradius zu begrenzen. Jede Identität erhält nur den Zugriff, der für ihre aktuelle Aufgabe erforderlich ist, für den kürzest sinnvollen Zeitraum und innerhalb des kleinstmöglichen Geltungsbereichs. Wird ein Konto kompromittiert, übernimmt der Angreifer diese Begrenzungen, statt einen freien Weg durch die gesamte Umgebung zu erhalten.
Geringste Rechte sind keine einzelne Einstellung. Dazu gehören Zugriffskontrolle, rollenbasierte Zugriffskontrolle, starke Authentifizierung, Netzwerkdesign, Berechtigungsprüfungen, Überwachung und Wiederherstellungsplanung. Außerdem erfordert dieser Ansatz Disziplin bei Konten, die häufig übersehen werden: Dienstidentitäten, API-Schlüssel, Notfalladministratoren und Backup-Zugangsdaten.
Was das Prinzip der geringsten Rechte tatsächlich begrenzt
Zugriff hat mehrere Dimensionen. Ein Benutzer darf sich möglicherweise an einem Server anmelden, aber ein bestimmtes Verzeichnis nicht lesen. Ein Administrator darf eine Kundenumgebung verwalten, aber keine andere. Ein Datenbankkonto darf ausgewählte Tabellen lesen, aber keine Schemata ändern oder neue Benutzer anlegen. Ein Backup-Prozess darf Wiederherstellungsdaten schreiben, aber vorhandene Wiederherstellungspunkte nicht löschen.
Eine sinnvolle Zugriffsentscheidung stellt daher vier Fragen:
- Wer fordert Zugriff an: ein namentlich bekannter Mitarbeiter, Administrator, Dienst, eine API oder ein Notfallkonto?
- Welche Ressource ist betroffen: ein Server, eine Datenbank, ein Dateisystem, eine Verwaltungskonsole oder ein Backup-Repository?
- Welche Aktionen werden benötigt: Lesen, Schreiben, Ausführen, Konfigurieren, Erstellen, Löschen oder Wiederherstellen?
- Wann und von wo aus soll der Zugriff gültig sein?
Das Prinzip der geringsten Rechte reduziert unnötige Kombinationen dieser Berechtigungen. Es garantiert nicht, dass ein Konto nicht kompromittiert werden kann, und ersetzt weder Patchmanagement noch Endpoint-Sicherheit oder Netzwerküberwachung. Sein Wert liegt in der Eindämmung: Ein Angreifer, der eine Identität übernimmt, sollte auf wirksame Grenzen stoßen.
Trennen Sie Rollen, bevor Sie Berechtigungen vergeben
Die Trennung von Rollen ist eine der wirksamsten Methoden, um zu verhindern, dass ein kompromittiertes Konto zu einem uneingeschränkten Administratorkonto wird. Ein kleines Unternehmen könnte normale Arbeit, Serveradministration, Backupverwaltung sowie den Zugriff auf Finanz- oder Kundendaten voneinander trennen. Eine Agentur benötigt möglicherweise separate Rollen für ihre eigene Infrastruktur und für jede Kundenumgebung.
Rollenbasierte Zugriffskontrolle macht diese Grenzen wiederholbar. Statt Berechtigungen direkt an einzelne Personen zu vergeben, definieren Sie Rollen wie Serveroperator, Datenbankleser, Deployment-Engineer, Sicherheitsauditor und Backup-Operator. Weisen Sie Personen die benötigten Rollen zu und überprüfen Sie die Rollendefinitionen, wenn sich Systeme ändern.
Betrachten Sie rollenbasierte Zugriffskontrolle nicht als Begründung dafür, eine übergroße Rolle namens Administrator zu erstellen. Eine Rolle sollte eine tatsächliche Arbeitsfunktion und einen begrenzten Geltungsbereich abbilden. Ein Deployment-Engineer darf beispielsweise einen bestimmten Anwendungsdienst neu starten und dessen Release-Verzeichnis aktualisieren, sollte aber keine Betriebssystembenutzer anlegen oder Datenbank-Backups entfernen können.
Halten Sie Administratoridentitäten getrennt
Personen, die Server administrieren, sollten normalerweise ein Standardkonto für E-Mail, Surfen und alltägliche Aufgaben sowie eine separate privilegierte Identität für die Administration haben. Dadurch sinkt das Risiko, dass ein Phishing-Angriff auf ein täglich verwendetes Konto sofort Administratorrechte offenlegt.
Administrative Identitäten sollten namentlich zugeordnet, nachvollziehbar und individuell geschützt sein. Gemeinsame Administratorzugänge verhindern eine eindeutige Verantwortlichkeit und erschweren den Widerruf. Wenn mehrere Personen dasselbe Passwort kennen, wird eine Änderung während eines Vorfalls störend, und Protokolle können nicht zuverlässig zeigen, wer eine Aktion ausgeführt hat.
Wenn ein gemeinsames Notfallkonto unvermeidbar ist, bewahren Sie es in einem geeigneten Zugangsdaten-Tresor auf, verlangen Sie eine dokumentierte Entnahme, protokollieren Sie seine Nutzung und ändern Sie die Zugangsdaten nach dem Zugriff. Es sollte eine Ausnahme für die Wiederherstellung sein, nicht die normale Art, wie ein Team Server administriert.
Nutzen Sie Just-in-Time-Zugriff für privilegierte Aufgaben
Dauerhafte Berechtigungen schaffen dauerhaft eine Möglichkeit für Angreifer. Just-in-Time-Zugriff reduziert dieses Risiko, indem erhöhte Berechtigungen nur dann gewährt werden, wenn eine Aufgabe sie erfordert. Die Genehmigung kann manuell oder automatisiert erfolgen, sollte aber Zielsystem, angeforderte Rolle, Grund und Dauer festlegen.
Ein Support-Engineer könnte beispielsweise 45 Minuten lang Zugriff auf einen Produktionsserver erhalten, um den Ausfall eines Dienstes zu untersuchen. Nach Ablauf dieses Zeitfensters sollte die Berechtigung automatisch verschwinden, ohne darauf angewiesen zu sein, dass jemand an deren Entfernung denkt. Für sensible Aktionen sollte eine zweite Person den Zugriff oder die Änderung selbst genehmigen.
Zeitlich begrenzter Zugriff ist besonders für Agenturen nützlich. Ein Entwickler benötigt möglicherweise während eines Deployments vorübergehend Zugriff auf einen Kundenserver, während ein externer Spezialist einmaligen Diagnosezugriff braucht. Keiner von beiden sollte dauerhaft umfassenden Zugriff auf alle Kundenumgebungen behalten.
Auch der Notfallzugriff sollte diesem Prinzip folgen, selbst wenn es auf Geschwindigkeit ankommt. Halten Sie eine kleine Anzahl von Break-Glass-Konten mit klar begrenztem Geltungsbereich, starker Authentifizierung und unabhängigen Wiederherstellungsmethoden vor. Lösen Sie bei jeder Nutzung einen Alarm aus, erfassen Sie den Grund und, soweit möglich, die ausgeführten Befehle und prüfen Sie das Ereignis unmittelbar danach. Ein Notfallprozess, der nie getestet wurde, ist kein zuverlässiger Prozess. Testen Sie ihn daher, ohne die Zugangsdaten dauerhaft verfügbar zu machen.
Richten Sie die Authentifizierung auf geringste Rechte aus
Ein Passwort beweist lediglich, dass jemand ein Geheimnis kennt. Es beschränkt nicht, was diese Identität nach der Anmeldung tun kann. Geringste Rechte und Authentifizierung lösen unterschiedliche Probleme: MFA hilft, unbefugten Zugriff zu verhindern, während Zugriffskontrollen den Schaden begrenzen, falls Zugriff erlangt wird.
Nutzen Sie MFA für Administrator-, VPN-, Cloud-, Backup- und andere Konten mit hoher Auswirkung. Bevorzugen Sie phishing-resistente Methoden, sofern die Umgebung diese unterstützt, und behandeln Sie SMS nicht als einzigen Schutz für kritische Administration. Erzwingen Sie separate Authentifizierungsrichtlinien für privilegierte Identitäten, statt sie die schwächste Richtlinie gewöhnlicher Benutzer übernehmen zu lassen.
Der Widerruf von Zugangsdaten muss schnell erfolgen und geübt werden. Führen Sie ein Inventar der Benutzer, SSH-Schlüssel, API-Tokens, Zertifikate, Dienstzugangsdaten und Integrationen von Drittanbietern. Wenn der Verdacht besteht, dass ein Konto kompromittiert wurde:
- Deaktivieren oder sperren Sie die Identität und widerrufen Sie aktive Sitzungen.
- Entfernen Sie Gruppenmitgliedschaften, Schlüssel, Tokens und delegierte Berechtigungen.
- Blockieren Sie bekannte Quelladressen oder Geräte, sofern angemessen, ohne anzunehmen, dass dies ausreicht.
- Ändern Sie Geheimnisse, die das Konto lesen, verwenden oder offenlegen konnte.
- Prüfen Sie Protokolle auf Aktivitäten vor und nach dem Widerruf.
Verlassen Sie sich nicht allein auf das Zurücksetzen eines Passworts. Ein Angreifer könnte bereits ein weiteres Konto erstellt, ein API-Token kopiert, einen SSH-Schlüssel hinzugefügt oder sich über eine geplante Aufgabe dauerhaft Zugriff verschafft haben.
Beschränken Sie Dienstkonten und API-Zugriffe
Dienstkonten erhalten häufig übermäßige Rechte, weil sie ohne anwesende Person ausgeführt werden. Das ist ein häufiger Schwachpunkt: Eine Anwendung muss eine Datenbank lesen, aber ihr Konto kann jede Datenbank auf dem Server administrieren. Ein Deployment-Token muss eine Anwendung veröffentlichen, kann aber das Betriebssystem verändern.
Erstellen Sie separate Dienstidentitäten für unterschiedliche Anwendungen und Umgebungen. Zugangsdaten für Produktion, Staging und Entwicklung sollten nicht austauschbar sein. Geben Sie jeder Identität nur die für ihre Funktion erforderlichen Berechtigungen und verbieten Sie die interaktive Anmeldung für Konten, die ausschließlich Dienste ausführen sollen.
Beschränken Sie Tokens für APIs nach Vorgang, Endpunkt, Umgebung, Quellnetzwerk und Ablaufzeit. Speichern Sie Geheimnisse außerhalb des Anwendungscodes und ändern Sie sie nach einem festgelegten Zeitplan oder nach einem Personalwechsel. Überwachen Sie ungewöhnliche Mengen, geografische Herkunft, fehlgeschlagene Anfragen und Versuche, eine API außerhalb ihrer vorgesehenen Funktion zu nutzen.
Gehen Sie nicht davon aus, dass ein Dienstkonto sicher ist, nur weil kein Mensch sein Passwort kennt. Auf dem Anwendungsserver laufende Malware kann möglicherweise seine Zugangsdaten verwenden, und eine verwundbare Anwendung kann einem Angreifer erlauben, über die Dienstidentität zu handeln. Die Berechtigungen des Kontos müssen daher eng genug gefasst sein, um diesen Angriffsweg zu begrenzen.
Wenden Sie geringste Rechte auf Server, Dateisysteme und Datenbanken an
Verwenden Sie sudo-Richtlinien statt uneingeschränktem Root-Zugriff
Verwenden Sie auf Linux-Systemen individuelle Konten und sorgfältig definierte sudo-Regeln, statt jedem Administrator uneingeschränkten Root-Zugriff zu geben. Wer lediglich einen Dienst neu starten muss, sollte nicht automatisch Dateien zur Authentifizierung bearbeiten, Pakete installieren oder Protokolle löschen können.
Legen Sie erlaubte Befehle und, soweit praktikabel, erlaubte Argumente und Zielhosts fest. Seien Sie vorsichtig mit Befehlen, die Editoren, Shells oder Skripte aufrufen, da eine scheinbar eng begrenzte Regel durch einen indirekten Ausbruch zu vollständigem Root-Zugriff werden kann. Überprüfen Sie sudo-Richtlinien als Code oder Konfiguration, testen Sie sie und entfernen Sie temporäre Regeln nach Abschluss der Aufgabe.
Kontrollieren Sie Dateisystemberechtigungen
Trennen Sie Anwendungscode, Konfiguration, hochgeladene Inhalte, Protokolle und Backups. Der Webprozess muss möglicherweise in ein Upload-Verzeichnis schreiben, sollte aber keinen ausführbaren Code verändern oder private Konfigurationsdateien mit Zugangsdaten lesen können. Datenbankprozesse sollten keinen allgemeinen Zugriff auf fremde Benutzerverzeichnisse haben.
Nutzen Sie, wo angemessen, Eigentümer, Gruppen, Zugriffssteuerungslisten und die Isolation von Diensten. Achten Sie auf vererbte Berechtigungen: Ein neues Verzeichnis oder Konto kann versehentlich Zugriff von einer weit gefassten übergeordneten Gruppe erhalten. Testen Sie Berechtigungen mit der tatsächlichen Dienstidentität und nicht nur mit einem Administratorkonto, das alles sehen kann.
Begrenzen Sie Datenbankberechtigungen
Datenbankbenutzer sollten nach Anwendung und Funktion getrennt werden. Ein Reporting-Konto benötigt möglicherweise SELECT-Zugriff auf definierte Ansichten, während ein Anwendungskonto ausgewählte Tabellen lesen und aktualisieren, aber weder das Schema verändern noch Benutzer anlegen oder Daten löschen darf. Der administrative Datenbankzugriff sollte einer kleinen Gruppe vorbehalten bleiben und über namentlich zugeordnete Identitäten erfolgen.
Trennen Sie Lese- und Schreibzugangsdaten, sofern die Anwendungsarchitektur dies ermöglicht. Beschränken Sie Datenbankverbindungen nach Host oder Netzwerksegment, verschlüsseln Sie Verbindungen und protokollieren Sie administrative Vorgänge. Wird eine Webanwendung kompromittiert, können eingeschränkte Datenbankberechtigungen verhindern, dass der Angreifer aus dem Zugriff auf die Anwendung eine uneingeschränkte Datenzerstörung macht.
Nutzen Sie Netzwerksegmentierung als weitere Berechtigungsgrenze
Identitätsberechtigungen reichen nicht aus, wenn jeder Server frei eine Verbindung zu jedem anderen Server herstellen kann. Segmentieren Sie Netzwerke und definieren Sie explizite Verkehrsregeln zwischen Benutzergeräten, Anwendungsservern, Datenbanken, Verwaltungsschnittstellen und Backup-Systemen.
Ein Frontend-Server muss möglicherweise einen Anwendungsport erreichen, und die Anwendung muss eventuell einen Datenbankport erreichen. Keiner von beiden benötigt zwangsläufig SSH-Zugriff auf jede Maschine. Verwaltungsschnittstellen sollten nur über genehmigte Administrationswege erreichbar sein, etwa ein kontrolliertes VPN oder ein Verwaltungsnetzwerk. Backup-Repositories sollten aus Produktions-Workloads nicht allgemein erreichbar sein.
Segmentierung begrenzt die laterale Bewegung nach der Kompromittierung eines Kontos oder Servers. Sie macht außerdem ungewöhnliche Aktivitäten sichtbarer: Wenn ein Webserver versucht, eine Verwaltungsschnittstelle zu erreichen, oder ein Arbeitsplatzrechner Kontakt zu einem Backup-Repository aufnimmt, sollte dies eine Untersuchung auslösen.
Schützen Sie Backups vor kompromittierten Produktionskonten
Ein Backup, das über dasselbe Konto oder denselben Server erreichbar ist, den es schützt, kann während eines Angriffs zerstört werden. Ransomware versucht häufig, Backup-Software, Repositories und Zugangsdaten zu finden, bevor sie Produktionsdaten verschlüsselt. Eine erfolgreiche Wiederherstellung hängt davon ab, den Backup-Zugriff von der Produktionsadministration zu trennen.
Verwenden Sie eine dedizierte Backup-Identität mit den geringstmöglichen Berechtigungen. Ein Produktionskonto sollte Backup-Daten weder löschen noch verändern oder ihre Aufbewahrungsdauer verkürzen können. Wo es das Design erlaubt, sollte die Backupverwaltung einen separaten Verwaltungsweg, separate Zugangsdaten und MFA verwenden. Auch der Wiederherstellungszugriff sollte kontrolliert werden: Personen, die die Produktion betreiben, benötigen nicht automatisch die Berechtigung, die Backup-Historie zu löschen.
Für Server, die der Kunde kontrolliert, bietet Safenix ein externes Backup an, das mit einem Schlüssel verschlüsselt wird, den Safenix niemals besitzt, in Deutschland gespeichert und für die Dauer des Aufbewahrungszeitraums unveränderbar ist. Diese Trennung ist wichtig, wenn ein kompromittiertes Serverkonto die Live-Umgebung beschädigen kann. Mehr darüber erfahren Sie in diesem Beitrag darüber, wie Safenix verschlüsselte Backups schützt und kontrolliert, wer sie lesen kann.
Safenix schützt geschäftliche Server, die vom Kunden kontrolliert werden. Es bietet keinen Backup-Plan für Websites auf Shared-Hosting, bei denen der Kunde den zugrunde liegenden Server nicht kontrolliert. Dieser Unterschied ist wichtig bei der Beurteilung, ob ein Backup-Design die Wiederherstellungsdaten tatsächlich von den Produktionszugangsdaten isolieren kann.
Überprüfen Sie Zugriffe kontinuierlich statt routinemäßig einmal jährlich
Berechtigungen häufen sich an. Mitarbeiter wechseln ihre Rollen, Agenturen schließen Projekte ab, Auftragnehmer verlassen das Unternehmen und temporärer Troubleshooting-Zugriff wird dauerhaft. Inaktive Konten sind für Angreifer besonders attraktiv, weil sie weiterhin nützliche Rechte besitzen können, aber wenig Aufmerksamkeit erhalten.
Führen Sie ein Zugriffsverzeichnis, das Folgendes umfasst:
- Namentlich zugeordnete Benutzer- und Administratorkonten
- Gruppen, Rollen und delegierte Berechtigungen
- SSH-Schlüssel, API-Tokens, Zertifikate und Anwendungsgeheimnisse
- Dienstkonten und geplante Aufgaben
- Externe Agenturen, Auftragnehmer und Supportanbieter
- Notfall- und Break-Glass-Identitäten
- Konten für Backup, Überwachung und Infrastrukturverwaltung
Überprüfen Sie Zugriffe nach dem Eintritt, Rollenwechsel und Ausscheiden von Personen, nach dem Ende eines Projekts sowie nach größeren Infrastrukturänderungen. Eine planmäßige Prüfung kann für privilegierte Zugriffe monatlich und für umfassendere Zugriffe vierteljährlich erfolgen, wobei die Häufigkeit dem Risiko angepasst werden sollte. Bitten Sie den Ressourcenverantwortlichen nicht nur zu bestätigen, dass ein Konto der richtigen Person gehört, sondern auch, dass jede Berechtigung weiterhin erforderlich ist.
Agenturen sollten vererbte Berechtigungen über Kundenumgebungen hinweg vermeiden. Ein Techniker, der Kunde A unterstützt, sollte keine Rolle erhalten, die automatisch Zugriff auf die Kunden B, C und D gewährt. Verwenden Sie, wo immer möglich, separate Mandanten, Konten, Gruppen, Schlüssel oder Verwaltungsbereiche. Wenn zentrale Werkzeuge die Trennung erschweren, betrachten Sie dies als Designrisiko, statt umfassenden Zugriff als unvermeidbar hinzunehmen.
Überwachen Sie die Nutzung von Berechtigungen und bewahren Sie Beweise
Das Prinzip der geringsten Rechte funktioniert am besten, wenn Sie sehen können, wie Berechtigungen genutzt werden. Protokollieren Sie Authentifizierung, Rechteerweiterungen, Rollenänderungen, neue Schlüssel, Token-Erstellung, Berechtigungsänderungen, Datenbankadministration und Backup-Aktionen. Erfassen Sie Identität, Ziel, Zeitpunkt, Quelle, Ergebnis und, sofern angemessen, das mit der Aktion verknüpfte Ticket oder die Genehmigung.
Leiten Sie wichtige Protokolle von den verwalteten Systemen weg, damit ein Angreifer die Beweise nicht unbemerkt umschreiben kann. Schützen Sie den Protokollzugriff mit separaten Berechtigungen und definieren Sie eine Aufbewahrungsdauer, die Untersuchungen sowie rechtliche oder regulatorische Anforderungen unterstützt. Synchronisierte Zeit auf allen Servern macht die Korrelation von Ereignissen deutlich zuverlässiger.
Die Überwachung sollte sich auf aussagekräftige Signale konzentrieren, statt Alarme zu erzeugen, die niemand bearbeiten kann. Beispiele:
- Ein normaler Benutzer erhält eine Administratorrolle
- Ein Notfallkonto wird außerhalb eines erklärten Vorfalls verwendet
- Ein Dienstkonto führt eine interaktive Anmeldung durch
- Ein Token wird aus einem unbekannten Netzwerk oder zu einer ungewöhnlichen Zeit verwendet
- Umfangreiche Berechtigungsänderungen in mehreren Kundenumgebungen
- Versuche, auf Backup-Daten zuzugreifen, diese zu löschen oder zu verändern
Wenn ein Alarm ausgelöst wird, sichern Sie relevante Protokolle, Befehlshistorien, Authentifizierungsaufzeichnungen und den Systemzustand, bevor Sie Änderungen vornehmen, die Beweise zerstören könnten. Verzögern Sie gleichzeitig die Eindämmung nicht, während Sie versuchen, eine perfekte forensische Sammlung zu erreichen. Dokumentieren Sie, was von wem und wann geändert wurde, und arbeiten Sie bei schwerwiegenden Vorfällen mit qualifizierter Unterstützung für die Reaktion auf Sicherheitsvorfälle zusammen.
Häufige Schwachstellen beseitigen
Viele Programme für geringste Rechte scheitern eher an betrieblichen Abkürzungen als an technischer Unmöglichkeit. Achten Sie auf folgende Muster:
- Gemeinsame Administratorzugangsdaten: Sie verhindern eine zuverlässige Zuordnung, erschweren das Offboarding und machen einen schnellen Widerruf störend.
- Dauerhafter Agenturzugriff: Ein Dienstleister benötigt möglicherweise gelegentlich Zugriff auf einen Server, aber keinen ständigen Zugriff auf jede Kundenumgebung.
- Inaktive Konten: Alte Mitarbeiter-, Auftragnehmer- und Testkonten können noch lange nach Ende ihres ursprünglichen Zwecks wertvolle Berechtigungen besitzen.
- Vererbte Berechtigungen: Weit gefasste Gruppen und verschachtelte Rollen können unbemerkt Zugriff auf Kunden, Server oder Datenspeicher gewähren.
- Ein Konto für jede Funktion: Die Kombination von Deployment-, Datenbank-, Betriebssystem- und Backup-Berechtigungen schafft ein einzelnes Ziel mit hoher Auswirkung.
- Temporäre Ausnahmen ohne Ablauf: Notfall-Sudo-Regeln, Firewall-Freigaben und API-Tokens benötigen Verantwortliche und automatische Enddaten.
- Backups aus der Produktion verwaltet: Wenn derselbe Administrator sowohl Live-Systeme als auch Wiederherstellungsdaten verändern kann, kann dies möglicherweise auch ein Angreifer tun.
Für weitere Recherchen lesen Sie praktische Hinweise zum Prinzip der geringsten Rechte und zu kompromittierten Konten und übertragen Sie die Ideen anschließend auf die Systeme und Verantwortlichkeiten, die Ihr Unternehmen tatsächlich betreibt.
Praktische Prioritäten für kleine Unternehmen und Agenturen
Kleine Teams benötigen keine umfangreiche Identitätsplattform, um spürbare Fortschritte zu erzielen. Beginnen Sie damit, kritische Systeme und die Identitäten aufzulisten, die sie administrieren, verändern oder löschen können. Entfernen Sie gemeinsame Zugangsdaten, deaktivieren Sie inaktive Konten und verlangen Sie MFA für privilegierte Zugriffe.
Trennen Sie anschließend Produktions-, Administrations- und Backup-Berechtigungen. Erstellen Sie namentlich zugeordnete Administratorkonten, beschränken Sie Dienstidentitäten, begrenzen Sie Datenbankbenutzer und schränken Sie Netzwerkpfade zwischen Servern ein. Führen Sie einen Genehmigungs- und Ablaufprozess für externen Zugriff ein, selbst wenn dieser anfangs nur ein Ticket und eine Kalendererinnerung umfasst.
Testen Sie schließlich die Reaktion. Können Sie den Zugriff eines Mitarbeiters schnell deaktivieren? Können Sie ein Mitglied einer Agentur widerrufen, ohne andere Kunden zu beeinträchtigen? Können Sie feststellen, welches Konto eine Firewall-Regel geändert hat? Können Sie Daten wiederherstellen, wenn der Produktionsadministrator kompromittiert wurde? Wenn die Antwort unklar ist, handelt es sich nicht nur um ein Problem der Zugriffskontrolle, sondern auch um ein Problem der Widerstandsfähigkeit.
Das Prinzip der geringsten Rechte kann bei ungewöhnlichen Aufgaben ein wenig zusätzliche Reibung verursachen. Diese Reibung ist nützlich, wenn sie verhindert, dass normale Konten zerstörerische Aktionen ausführen. Entwickeln Sie sinnvolle Rollen, ermöglichen Sie eine schnelle Just-in-Time-Erhöhung von Berechtigungen und halten Sie den Notfallzugriff kontrolliert verfügbar. Das Ziel besteht nicht darin, legitime Abläufe zu blockieren. Es geht darum sicherzustellen, dass eine einzige gestohlene Identität nicht zur Berechtigung wird, das gesamte Unternehmen zu kontrollieren.