Ich habe kürzlich eine neue Artikelserie zum Thema IAM begonnen. In dieser Serie geht es vorrangig um die Disziplinen, die im IAM betrachtet werden müssen. Sie werden kurz beschrieben.
Begonnen habe ich die Serie mit einem Überblick und den PLAN Disziplinen. Ich wünsche neue Erkenntnisse.
Sie sind Ziel interner, nicht autorisierter Maßnahmen wie das Ausspähen von Geschäftsgeheimnissen und unkontrollierter Abfluss von strategischen und operativen Daten.
Leider sind Schutzmaßnahmen der IT-Organisationen i.d.R. sehr begrenzt. Sie orientieren sich meist an Software-Schwachstellen und rudimentär vorhandenen Prozessen.
Einen umfassenden Schutz erreicht man, wenn Architekturthemen wie die Anpassung der Authentifizierungs- & Autorisierungs- Infrastruktur und deren Prozesse an die aktuellen Herausforderungen in die Betrachtung aufnimmt.
Grundlage der Betrachtungen ist das Microsoft Active Directory (ADDS), das in dem weitaus größten Teil der Unternehmen als Identitätsdatenspeicher zum Einsatz kommt. Darüber hinaus werden Technologien, die in der Cloud – Welt ihren Anfang nahmen und für den sicheren Betrieb notwendig sind (ADFS / Entra-ID, SAML, Oauth etc.) einbezogen.
ADDS ist im größten Teil der Unternehmen das zentrale Tool für Authentifizierung und Autorisierung und damit ein zentraler Sicherheits-Bestandteil dieser Unternehmen. Deshalb ist es sinnvoll sich an folgenden Prämissen zu halten. Die Prämissen sind in drei thematische Blöcke zusammengefasst.
Sichere
Identitätsverwaltung
Alle Identitäten im Unternehmen sind zentral in einem Repository – Active Directory – zu verwalten. Dadurch ist der Einfluss auf jede Identität zu jedem Zeitpunkt gewährleistet.
Unter Identitäten versteht man alle Konten, die notwendig sind, um den Betrieb der Unternehmens- Infrastruktur zu gewährleisten.
Eine transparente Verwaltung aller Identitäten ist nur möglich, wenn die Hoheit über die Konten in einer Hand liegen. Dazu ist eine zentrale Verwaltung unabdingbar.
Damit die Berechtigungen für die Maschine und der darauf laufenden Dienste verwaltet werden können, sind die zugehörenden Service Accounts im Active Directory verortet. Lokale administrative Konten sind ein Einfallstor für Angreifer. Da sie i.d.R. nicht genutzt werden, sind diese Build-In lokal Accounts disabled.
Damit der Server oder der Client verwaltet werden kann, muss er zwingend Mitglied des der Domäne sein.
Diese Prämisse ist unbedingt einzuhalten. Deshalb ist es sinnvoll, die lokalen Benutzerverwaltungen zu überwachen.
Das gilt auch für „hybride Identitäten“, wie sie in Verbindung mit Cloud Anwendungen wie M365 und Azure auftreten.
In vielen Fällen wird zu Berechtigung eines Mitarbeiters in einer Fachanwendung direkt zugeteilt. Das wird dann über den Benutzernamen und einer teils sehr granularen Berechtigungsvergabe erledigt. Das funktioniert erstmal, hat aber entscheidende Nachteile:
Die Berechtigung auf Funktionen einer Anwendung muss primär im ADDS über Berechtigungsgruppen durchgeführt werden. Berechtigungsgruppen, die thematisch zusammengehören, werden einer Rolle zugewiesen. Die Vergabe an Personen wird durch Rollen durchgeführt.
Niemals wird eine Berechtigung einer Identität direkt zugewiesen !
RBAC (role based access control) ist die Methode, die die Berechtigungsvergabe aufgrund der Rollenzugehörigkeit eines Mitarbeiters regelt. Eine Rolle kann beispielsweise die Zugehörigkeit zu einem Fachbereich, einer Abteilung oder einem Arbeitsbereich sein.
„AGDLP“ ist die technische Umsetzung von RBAC im Active Directory. AGDLP bedeutet:
| A | Account | das Active Directory Konto der Identität / Mitarbeiters |
| G | Globale Gruppe | Architekturelement im AD. Diese Gruppe stellt die Rolle (Abteilung, Arbeitsbereich etc.) dar. |
| DL | (Domain) Lokale Gruppe | Diese Gruppe stellt die Berechtigung dar, eine Ressource innerhalb des Institutes zu nutzen |
| P | Permission | Berechtigung: beschreibt das Recht, eine Ressource zu nutzen wie Nutzung als Mitarbeiter einer Anwendung, oder Nutzung der Dateiablage oder …. |
Namenskonventionen, Gruppentypen und Verschachtelungsstrategien werden empfohlen, um die Berechtigungsverwaltung zu optimieren.
Alle Maßnahmen der Verwaltung von erweiterten Rechten werden unter dem Begriff „Privleged Access Management“ PAM zusammengefasst.
Virtuelle Workplaces, die auf administrative Aufgaben ausgerichtet sind, einzurichten. Sie haben keinen Bezug zur allgemeinen Kommunikation des Unternehmens. Sie sind in eigenen Sicherheitszonen verortet. Diese Sicherheitszonen sind nur per Jump-Server, der in der gleichen Zone wir die PAW steht, zu erreichen.
Wird ein Mitarbeiter Administrator einer Anwendung oder Komponenten in der Infrastruktur, erhält er für diese Aufgabe ein zusätzliches Konto mit erweiterten Rechten zur Erfüllung seiner Aufgabe.
Der Account eines Mitarbeiters hat niemals erweiterte, administrative Rechte.
Erweiterte Rechte werden ausschließlich an „privileged access account“ PAA vergeben. PAA’s sind immer nur für einen Security Level zulässig. Der Zugriff mit einem PAA aus einem niederwertigen Level auf ein Level mit höherem Schutzbedarf ist nicht zulässig.
PAA’s für Enterprise- und Domänen- sowie Datenbank- Administratoren sind sehr stark limitiert. (z.B. maximal drei Personen im Unternehmen sowie Vertreter).
Die Benutzung der PAA dieser Administratoren wird immer überwacht. Das sind Teile des EAM. Die Themen des EAM werden an anderer Stelle beleuchtet.
Objekte im Active Directory, die nicht genutzt werden oder niemandem gehören, stellen eine potentielle Gefahr dar. Wenn diese leicht zu identifizierenden Objekte und unautorisierte Personen genutzt werden, fällt das in der klassischen Umgebung erstmal nicht auf. Nur kann dann schon der Schaden entstanden sin. Aus diesem Grund sind sie unbedingt zu vermeiden.
Authentifizierung &
Autorisierung
Der direkte Zugriff durch Anwendungen (z.B. über die Protokolle Kerberos und LDAPs ) oder die direkte Manipulation durch Administratoren sind Schwachstellen in der Architektur. Dier Schwachstellen können geheilt werden, wenn es keinen direkten Zugriff auf das Active Directory gibt.
Ausnahmen sind Enterprise- und Domänen-Administratoren zur Wartung sowie Eruierung und Behebung von Fehlern.
Named User müssen da, wo es möglich ist, über berührungslose Authentifizierungsverfahren wie SAML oder oAuth Authentifiziert werden.
Kerberos ist nur bedingt zulässig. (wenn kein höherwertiges Protokoll einsetzbar ist.)
Änderungen an allen ADDS Objekten sind zu autorisieren und zu überwachen.
Alle Assets (Server, Clients, Drucker, aktive Komponenten) im Unternehmen sind mit dem ADDS über entsprechende Accounts verbunden.
Änderungen an allen ADDS Objekten (in der Produktionsumgebung) werden immer automatisiert durchgeführt. Der manuelle Eingriff ist im Betrieb strikt verboten.
Named User haben es meist mit einer größeren zweistelligen Anzahl von Accounts zu tun, die sie für Ihre Arbeit benötigen. Das führt zu unsicheren und mehrfach genutzten Passwörtern. SSO ist hier eine Hilfe, diese Flut einzudämmen und Gefahren zu vermeiden.
Service Accounts werden im Betrieb nicht durch Mitarbeiter genutzt. Sie dienen im Verborgenden der Authentifizierung und Autorisierung von automatischen Prozessen. Damit sind sie i.d.R. aus dem Focus der täglichen Arbeit. Das prädestiniert sie als Angriffsziel.
Der Identitätsdiebstahl ist einer der gängigen bekannten Methoden, unautorisierten Zugriff auf Inhalte der Unternehmensinfrastruktur zu erlangen. Hier muss sichergestellt werden, das tatsächlich die Person Zugang bekommt, die nach der Identität auch Zugang erhalten soll.
Eine Mehr-Faktor Authentifizierung ist mindestens an den Stellen, an denen ein Security Level verlassen wird, notwendig.
Das Benutzerzertifikat stellt sicher, dass die Identität zum Unternehmen gehört.
Sicherheit der
Infrastruktur
Backup und Restorte auf Objektebene sind zwingend. Da gibt es keine Diskussion.
Für den Katastrophenfall muss es einen Wiederanlaufplan geben, der u.a. die erneute Bereitstellung des AD innerhalb kürzester Zeit ermöglicht. Die Wiederherstellung sollte im Stundenbereich liegen. Sie muss in regelmäßigen Abständen getestet werden.
Änderungen an der Produktionsumgebung können nur im Rahmen eine regulären Change Prozesses durchgeführt werden. Das hat den Vorteil, das zum einen alle Stakeholder in den Change involviert sind, zum, anderen die notwendigen Maßnahmen zur sicheren und nachvollziehbaren Änderung getroffen wurden.
Das schieß ad-hoc Änderungen, wie sie für Entwicklung und Test notwendig sind strikt aus.
Der Change unterstützt bei der Bereitstellung von Änderungen an den produktiven Systemen durch die genaue Beschreibung der Ausgangssituation, der notwendigen Arbeiten und des Ergebnisses. Er zeigt den Fallback im Detail auf und holt alle Stakeholder ab. Das Ergebnis ist eine architektonische und organisatorische Transparenz, die den Betrieb stark unterstützt und Entscheidungen vereinfacht.
Auf das Kerberos-Protokoll gab es in der Vergangenheit verschiedene erfolgreiche Angriffe, die bei vorausschauender Architektur nicht erfolgreich gewesen wären. Deshalb ist es nicht per se abzulehnen, mit Kerberos zu arbeiten.
Zudem lässt sich Kerberos – Nutzung nicht vollständig verhindern. Man denke nur an die Maschinen Authentifizierung an das ADDS.
Kerberos sollte so weit als möglich durch berührungslose Authentifizierungsverfahren ersetzt werden. Insbesondere gilt das für den Übergang von einem niederwertigen in einen höheren Security Level.
Damit Informationen nicht durch „Man in the Middle“ Attacken kompromittiert werden kann, ist jegliche Kommunikation zu verschlüsseln.
Active Directory verschlüsselt automatisch die Kerberos Kommunikation. Alle weiteren Systeme wie Identity Provider oder die CA sind auf verschlüsselte Kommunikation zu prüfen und ggfls. anzuheben.
Voraussetzung für viele Prämissen ist ein gültiges, durch eine CA signiertes Maschinenzertifikat.
Die Zertifikatsstelle (Certificate Authority) ist dabei auf jeden Fall on-Premise zu verorten. Die Maschinen- Zertifikate sind in zu bestimmenden Abständen automatisch zu aktualisieren. Das kann über verschiedene Wege erfolgen: Autoenrollment via ADDS oder über das ACME Protokoll. Das Thema Zertifikatsverwaltung ist aber so komplex, dass es dazu einen eigenen Artikel braucht.
weiterführende Links