​

"Welches Recht nimmst du dir bitte heraus, um mir sowas anzutun???"

"Öh … ich bin doch Admin!" 😬

In einem früheren Beitrag habe ich schon mal über alte Rechte geschrieben. Heute beschäftigen wir uns aber mit Berechtigungen, die auch neu, sehr großzügig vergeben werden. Dazu gibt es einen Fachbegriff: "Principle of Least Privilege".

Worum geht es beim Principle of Least-Privilege?

Die Idee dahinter ist ganz einfach: Jeder hat nur Zugriff auf das, was er auch wirklich braucht. Nicht mehr, aber auch nicht weniger.

Das können User, Admins, Anwendungen, Prozesse, Netzwerk-Geräte oder auch Betriebssysteme sein. Was man nicht hat, kann einem nicht weggenommen werden. Das Ziel ist es Risiken drastisch zu minimieren, die Angriffsflächen zu verkleinern und auch die potenziellen Schäden zu begrenzen.

Es ist wie der Master-Key des Haustechnikers. Damit kommt man zu jeder Uhrzeit in jeden Raum hinein. Mit Latzhose und schmutzigen Händen, würde dich nicht mal der CEO fragen, ob du das darfst, wenn du plötzlich in seinem Büro stehst.

Im echten Leben wird der räumliche Zugriff strikt reglementieren, aber in der IT sind alle großzügig und wollen immer mehr Rechte, als sie eigentlich bräuchten.

Es geht um mehr als nur User-Berechtigungen

Nicht jeder User braucht Vollzugriff auf alle Ordner, Datenbanken, oder Anwendungen. Ich könnte jetzt wieder über Rechte- und Rollenkonzepte schreiben, aber das hatten wir schon.

Was ist mit den Datenbanken und Anwendungen selbst?

Oder die Betriebssysteme auf denen sie installiert sind?
Oder die Accounts, unter denen sie gestartet werden?
Oder die Administratoren, die sie verwalten?
Oder die Hardware, auf denen sie laufen?

Hardware

Wenn ein Angreifer die Hardware kontrolliert, kann er auch die Daten direkt aus dem Arbeitsspeicher auslesen. Selbst wenn die Daten auf dem Datenträger verschlüsselt sind, ist exakt dieser Schlüssel im RAM, während das Betriebssystem läuft. Gerade bei Cloud-Rechenzentren ist das ein echtes Security- und Datenschutz-Thema.

Das Konzept der vertikalen Sicherheit habe ich in diesem Beitrag bereits erklärt.

Administratoren

Viele Firmen haben Admins mit sehr weitreichenden Berechtigungen, wie zum Beispiel Admin-Zugriff auf alle Server / alle Clients. Das sind dann sozusagen die Haustechniker unter den Admins. Wenn ein einziger Client gehackt wäre und sich ein Client-Admin darauf anmelden würde, dann wären mit einem Schlag alle Clients kompromittiert.

Mit dem Tool "LAPS" kannst du das für Windows Server und Clients verhindern. Wie genau, habe ich in diesem Beitrag erklärt.

Service-Accounts

Wenn du eine Anwendung auf einem Server installierst, wie zum Beispiel eine Zeiterfassung, dann läuft sie unter einem Standard-Service-Account. Unter Windows ist das meistens SYSTEM und der hat die meisten Berechtigungen. Damit hast du sogar Zugriff auf die Geheimnisse aller anderen lokalen Accounts, weil du als SYSTEM über den Admins stehst.

Möchtest du wirklich, dass der ganze Server samt allen Accounts kompromittiert ist, wenn nur deine Zeiterfassung eine Schwachstelle ist? Ich auch nicht! Ich würde immer einen dedizierten Service-Account verwenden. Aber bitte keinen, wo du dich um das Kennwort selbst kümmern musst, denn das tust du ja sowieso nicht.

Für den Zugriff auf externe Ressourcen eignet sich ein "Managed Service Account", für rein lokale Zugriffe ein "Virtual Account". Schau mal hier, bei Microsoft findest du eine Vergleichstabelle: https://learn.microsoft.com/de-at/windows-server/identity/ad-ds/manage/understand-service-accounts#choosing-your-service-account​

Ach ja, auch übergreifende Service-Accounts, die auf allen Clients / Servern verwendet werden, sind genauso schlecht. Wenn du den "Software Delivery Agent" einsetzt und denselben Account auf allen Geräten benutzt, dann hast du sogar noch ein größeres Problem als im Beispiel oben bei den Admins. Service-Accounts sind nämlich immer eingeloggt, solange die Anwendung läuft, Admins nur sporadisch.

Betriebssysteme

Es gibt auch innerhalb der Betriebssysteme verschiedene Abstufungen der Berechtigungen. Sie basieren auf den Prozessor-Architekturen wie x86/x64 oder ARM/ARM64. Das nennt man "Rings", oder "Exception Levels". Der Kernel des Betriebssystems läuft in einem anderen Bereich der CPU als die User-Anwendungen. So wird verhindert, dass es zu Überschneidungen kommt.

Unter Linux und Unix kommt man als "root" ziemlich weit, genauso wie unter Windows als "SYSTEM" oder Administrator. Unter Windows gibt's verschiedene Härtungsmaßnahmen:

• Kernel / User Mode Separation
• Virtualization-Based Security
• Credential Guard
• Hypervisor-Enforced Code Integrity
• Protected Process Light.

Unter Linux gibt es unter anderem:

• Kernel Page Table Isolation
• Supervisor Mode Access/Execution Prevention
• Usercopy Protection
• Linux Security Modules
• Speculative Execution.

Die CPU-Schwachstellen der letzten Jahre, wie Spectre und Meltdown, haben die Trennung zwischen Kernel und User umgangen. Das war natürlich eine Katastrophe.

Erweiterungen des Prinzips

Need to know

Das kommt ursprünglich aus der Compliance. Wenn du es richtig anwendest, kann es dir echt den Arsch retten. Ein Server-Admin muss vielleicht den Datenbank-Server administrieren, braucht aber nicht unbedingt Zugriff auf die Inhalte der Datenbank.

Oder ein Abteilungsleiter muss nur auf die Zeitlisten seiner Teamleiter zugreifen, nicht aber automatisch auf alle Mitarbeiter darunter.

Das reduziert nicht nur ungewollte Datenabflüsse durch Mitarbeiter, sondern erschwert auch Angreifern, große Datenmengen von einzelnen Usern abzugreifen.

Just-in-Time-Administration

Ich liebe dieses Prinzip. Es erhöht die Sicherheit für Administratoren drastisch und stellt auch Compliance zufrieden. Statt den Server-Admins ständig Vollzugriff auf hunderte oder tausende Server zu geben, bekommen sie die Rechte nur für eine bestimmte Zeit.

Admins besitzen nicht den Master-Key die ganze Zeit, sondern es wird für sie ein eigener Schlüssel angefertigt, um nur einen einzelnen Raum betreten zu können … äh … einzelnen Server zu managen. 😅

Das funktioniert über Privileged Access Management Tools. Dort können Admins den Zugriff auf berechtigte Systeme anfragen und bekommen sie nur dafür. Nach Ablauf der definierten Zeit, verfällt die Berechtigung automatisch. Zum Beispiel 30 Minuten Zugriff für ein Update.

Die Anfrage kann einen Genehmigungsprozess auslösen, oder die Berechtigung wird sofort erteilt. Normalerweise muss man sich vorher über Multifaktor-Authentication noch zusätzlich verifizieren. Der Start- und Stop-Zeitpunkt wird genau protokolliert und Admins haben ein geringeres Risiko, falls ihr Passwort geleakt wurde.

Separation of Duties

Auf Deutsch: Aufgabentrennung

Kritische Aktionen dürfen nicht von einzelnen Personen durchgeführt werden. Im Finanzwesen ist es üblich, dass Überweisungen, die einen gewissen Betrag übersteigen, eine zweite, oder dritte Freigabe brauchen.

In der Softwareentwicklung gibt's auch ähnliche Prozesse. Der Entwickler schreibt den Code und darf ihn nur in das Development-Code-Repository einpflegen. Ein zweiter Verantwortlicher darf den Code nicht verändern, sondern ihn nur 1:1 in die Test-Umgebung verschieben. Erst wenn alle Tests erfolgreich waren und freigegeben wurden, kommt der Code in die Produktion und wird von dort ausgerollt.

Das verhindert, dass Entwickler unbeabsichtigt und direkt die Produktion lahmlegen können, aber auch, dass der Code vor Freigabe noch unwissentlich verändert wird.

Wie reduziere ich Rechte?

Das Problem bei der Sache ist oft das Ego der Menschen.

Je mehr Berechtigungen, desto größer ist das gefühlte Vertrauen in die Person. Wenn du den Super-Admins die Rechte entziehst, dann ist das circa genau so, als würdest du einem Teenager das Smartphone wegnehmen. Rechne mit Gegenwind! 😡

Es ist besser, wenn du die Kommunikation in Richtung Verantwortung und Schutz lenkst. Argumentiere, dass es nicht um Misstrauen geht, sondern darum, dass Angreifer die Rechte ausnutzen könnten, wenn der Account gehackt wird.

Ein Admin möchte natürlich nicht, dass wegen ihm/ihr alle Server verschlüsselt werden. Wenn du das Schadensausmaß verringern möchtest, könntest du mehrere Accounts verwenden, oder Just-in-Time-Administration implementieren.

Du kannst auch gerne kreativ mit der Fragestellung sein, um eine Bedarfsanalyse zu machen.

"Wenn du heute einen neuen Account bekämst, welche Rechte bräuchtest du unbedingt, um deine Arbeit zu machen?" 🤔

"Was meinst du, was passiert, wenn ein Hacker deinen Account hackt? Für welche Altlasten würde dir dann der IT-Leiter den Kopf abreißen?" 😅

Fazit

Wenn du deinen Mitarbeitern und auch Admins nur die Rechte gibst, die sie auch tatsächlich für ihre Arbeit brauchen, dann reduzierst du das Risiko deutlich für Datenlecks, Compliance-Verstöße, oder ungeplante Ausfälle.

Anders gesagt: Es zahlt sich für das Unternehmen finanziell aus, weniger Berechtigungen zu vergeben. 🤑