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.
In Teil 1 und 2 der Reihe habe ich unter anderem vom Big Picture gesprochen. Anhand einer fiktiven Infrastruktur-Architektur eines mittelständischen Unternehmens möchte ich im Detail auf das Thema eingehen.
Die wenigstem Menschen sind in der Lage, komplexe Strukturen in allen Details über lange Zeit im Kopf zu behalten. Zudem hat jeder Mensch eine eigene Vorstellungswelt, die nicht unbedingt mit den Vorstellungswelten anderer beteiligter Personen deckungsgleich ist. Last but not Least sind auch Fachbegriffe meist unterschiedlich belegt, so das es zu Unverständnis trotz gleicher Fachsprache kommt.
Diese drei wichtigen Gründe führen dazu, eine gemeinsame Basis zu schaffen, die von allen Beteiligten verstanden und akzeptiert wird. Da Infrastrukturen durch ihre Komplexität nicht sonderlich gut durch Texte beschrieben werden, ist der Weg über ein großes Bild, ein Big Picture der gegebene Weg.
Das Pig Picture hilft dem Team wichtige Infrastruktur- Komponenten und ihre Details im Zusammenhang mit anderen Komponenten in einer einheitlichen Sprache darzustellen. Ein Big Picture zeigt mindestens die Technologieebene des zugrundeliegenden Metamodells auf.
Gerne gehe ich in einem späteren Artikel auf das Thema Metamodell ein. Da sich aber dieser Artikel auf den Aspekt der „Allgemein verfügbaren Infrastruktur- Komponenten der Technologieebene“ beschränkt, soll des erstmal damit genug sein. Wer sich vorab über das Thema informieren möchte, dem lege ich diesen Artikel über Metamodelle ans Herz.
Jede Fachanwendung benötigt Infrastruktur-Komponenten wie Authentifizierung & Autorisierung, File- & Print- Services, Datenbanken, Anwendungsserver, Schnittstellen, Sicherheitsfeatures und Backups usw.. um notwendige Leistung für den Fachbereich zur Verfügung zu stellen.
Diese „Allgemein verfügbaren Infrastruktur- Komponenten“ oder Basis-Infrastruktur sind in der Regel in allen Organisationen in der Mindest-Funktionalität gleich. So bedarf es für den geregelten Betrieb Netzwerkkomponenten , DNS, DHCP, Directory Service wie ADDS, Zertifikatsverwaltung wie AD CS, Server- und Client Deployment, Datenbanken, Sicherheits-Komponenten wie Firewalls und Patch-Management Komponenten uvm.
Alle diese Komponenten stehen in Bezug zueinander. Sie kommunizieren miteinander. Und sie haben unterschiedliche Wertigkeit bezüglich Authentizität, Integrität, und Verfügbarkeit in Abhängigkeit der zu verarbeitenden Daten. Diese Aussagen treffen auf 100% der IT – Infrastrukturen zu.
Technologieebene
Deshalb versuche ich hier, ein allgemein gültiges Bild einer Basis-Infrastruktur – bezugnehmend auf ein mittelständiges Unternehmen mit ca. 500 MA – abzubilden. Bei größeren Unternehmen und über mehrere Standorte kann das Bild weiter diversifiziert werden. Bei kleineren Unternehmen muss sicherlich an der einen oder anderen Stelle mit Abstrichen rechnen.
Das Big Picture ist
Grundlage für das gemeinsame Verständnis von Zusammenhängen und Abhängigkeiten zwischen IT den Fachbereichen und der Geschäftsführung
Grundlage für tiefer gehende (technische) Diskussionen innerhalb der IT
Ankerpunkt für detaillierte technische Plots der Feinarchitektur z.B. für Fachanwendungen
Big Pictures sind wie die zugrunde liegenden Infrastrukturen einem steten Wandel unterzogen. Dabei gibt es aber auch mehrere Konstante: Die einmal getroffene Datenklassifizierung wird sicherlich so schnell nicht mehr grundlegend geändert und Authentifizierung & Autorisierung ist immer erforderlich.
Datenklassifizierung
Daten in einem Unternehmen haben unterschiedliche Gewichtungen hinsichtlich Ihrer Wichtigkeit für den Fortbestand und der Erfolg des Unternehmens. So sind die CRM- Daten und die Einkaufskontrakte eines Handelshauses die Grundlage des Erfolges. Kommen diese Daten in die Hände der Mitbewerber, gefährdet das maßgeblich die Zukunft des Unternehmens Ich bezeichne diese Daten als Kronjuwelen
Eine weitere existentielle Datengruppe sind die Mitarbeiter-Daten. Sie zu vernachlässigen, würde nicht nur gegen geltendes Recht verstoßen, sondern auch Angreifern die Gelegenheit bieten, via Sozial Hacking an die Kronjuwelen zu gelangen.
Die dritte Gruppe sind alle Zugangsdaten zum Unternehmen, sei es physisch wie auch IT-seitig. Diese Daten werden von Angreifern in der Hauptsache genutzt um das Unternehmen auszuspähen und ihm ggfls. zu schaden.
Damit wären die überlebenswichtigen Datengruppen benannt.
Strategische und operative Daten -> die Kronjuwelen
Mitarbeiter- Daten
Zugangsdaten
Aber eigentlich sind all‘ diese Datengruppen die Kronjuwelen des Unternehmens.
Authentifizierung & Autorisierung
Zu dem Thema habe ich mich bereits ausführlich geäußert, so das ich auf die folgenden Artikel verweisen darf:
Tiering-Modelle sind seit langem im Finanz- und Versicherungswesen eingeführte Architekturkonzepte. Sie bilden konzentrische Datenringe, Tiers in Securitylevels ab. In der Regel sind fünf Levels / Tiers für den sicheren Betrieb einer Intrastruktur ausreichend, Sie können segmentiert und, wenn erforderlich, um weitere Tiers ergänzt werden.
generisches Tiering-Modell
TIER 0: DATA existentielle Daten des Unternehmens in Datenbanken, HR-Daten, AD, PKI
TIER 1: SERVICES & APPLICATIONS Applikationsserver, mit Schnittstellen zu internen Systemen in TIER1q und zu Datenbankservern in TIER0.
TIER 2: WORKPLACE Arbeitsplatze und Endgeräte mit geregeltem Zugriff auf Applikationen in TIER1
TIER 4: PERIMETER / DMZ Frontendserver, die mit externen Entitäten via Internet kommunizieren müssen. Die Frontendserver kommunizieren mit Applikationen in TIER1 über geregelte, verschlüsselte und überwachte Schnittstellen und Protokolle.
TIER 5: INTERNET In Menge und Qualität nicht definierbare weltweite Umgebung. Zugriff aus dem Internet auf Frontend-Systeme in Tier4 bei höchst möglicher Sicherheit bezüglich Datensparsamkeit, Identität, Verschlüsselung und Überwachung.
Das Tiering Modell wurde in den letzten Jahren insbesondere durch Microsoft für den Einsatz des Active Directory und den angrenzenden Technologien getrieben. Das das Active Directory das führende Identitäts-Directory ist, ist dieses Modell allgemeingültig geworden.
Stages: Produktion & Support
Es ist sehr wichtig zu erwähnen, das eine Produktionsumgebung unbedingt von äußeren Einflüssen frei zu halten ist. Die Produktionsumgebung unterliegt den Regeln des ITSM und der Sicherheit. So dürfen Änderung an der Produktion nur über definierte Kanäle (Deployment-Chain) und durch die Begleitung eines Change Prozesses durchgeführt werden. Ziel ist die umfassende Betriebssicherheit und vollständige Transparenz der Handlungen.
Entwicklung und Test werden in eigenen Stages durchgeführt. Das sind in der Regel eine Entwicklungs- und Testumgebung, sowie eine Abnahmeumgebung, die funktionsgleich der Produktionsumgebung ist. In komplexen Situationen ist eine Integrationsumgebung sinnvoll.
Ergebnis
Das Ergebnis ist ein durchgängiges Tiering-Modell für die Produktionsumgebung, indem Entwicklung, Test und Abnahme von der Produktionsumgebung getrennt ist. Der administrative Zugriff darf immer nur aus dem Level erfolgen, indem die Server / Services aufgestellt sind. Der Zugriff aus einem niedrigeren Security Level auf ein höheren Security Level zum Zweck der Administration ist streng untersagt. Ansonsten sind Durchgriffe für produktive Aufgaben geregelt, verschlüsselt, überwacht und dokumentiert. Nach Möglichkeit sind Protokollwechsel zwischen den Security Level anzustreben. Es gilt immer die Prämisse der Datensparsamkeit.
Produktion, Entwicklung und Test sind streng voneinander getrennt. Es gibt keinen Durchgriff und keinerlei direkte Verbindung. Einfluss auf die Produktion kann lediglich durch eine geregelte, limitierte und automatisierte Bereitstellung erfolgen.
Im Beispiel wird die Zufuhr von Software, Updates und Patches über einen Dienstleister erbracht. Das ist eine Lösung, die der Unternehmensgröße und Zweck an dieser Stelle gerecht wurde. Dabei sind CI/CD Ansätze noch nicht implementiert.
Auch ist in diesem Beispiel noch VPN als Verbindungstechnik für Mitarbeiter und Administratoren vorgesehen. Darauf würde ich in Zukunft gerne verzichten zugunsten einer dedizierten Service- Bereitstellung über Cloud Funktionalitäten.
VPN hat aus meiner Sicht in der Zukunft höchstenfalls eine administrative Funktion. Sie sollte wenigen Personen und restriktiver Nutzung bereitgestellt werden.
Big Picture eines fiktiven Unternehmens (JPG Format)
Im Big Picture wurde der Focus zunächst auf die On-Premise Umgebung gelegt. Cloud Komponenten sind rudimentär berücksichtigt, werden aber noch im Detail zu deklinieren sein.
Das Big Picture ist ein lebendes Dokument. Es wächst und ändert sich mit den Aufgaben und Erkenntnissen, die in einer IT Organisation anfallen. Ich werde auch das fiktive Infrastruktur-Modell an dieser Stelle weiter pflegen.
Big Picture
Hier können Sie das Big Picture als .pdf Datei in voller Größe herunterladen.
Identitäten (alle Benutzerkonten, die in einem Unternehmen zur Erreichung des Geschäftszieles notwendig sind) müssen besonders geschützt werden. Denn sie sind primäres Ziel der Cyber-Angriffe.
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
Es gibt nur einen Ort zur Verwaltung von Unternehmens- Identitäten
Rollen und Berechtigungen sind strikt zu trennen
Die Administration von Infrastruktur und Fachanwendungen ist stets streng von der Bürokommunikation zu trennen.
Der Status des AD muss jederzeit transparent und nachvollziehbar sein.
Authentifizierung und Autorisierung
Direkter Zugriff auf das Active Directory ist nicht zulässig
Anzahl der Anmeldungen / Passwörter ist auf ein Minimum zu reduzieren
Service Accounts sind besonders zu schützen
Die Identität muss bei der Authentifizierung überprüfbar sein.
Generelle Sicherheit der Infrastruktur
Ein einzelnes ADDS Objekt muss wiederhergestellt werden können
Das Active Directory und die Umsysteme müssen schnell reinstalliert werden können.
Die Produktionsumgebung darf nicht ohne Change Prozess verändert werden
Kerberos – Kommunikation ist auf ein Mindestmaß zu reduzieren.
Alle Kommunikationsverbindungen sind verschlüsselt
Alle Computer sind durch Zertifikate identifizierbar
Sichere
Identitätsverwaltung
Prämisse: Es gibt nur einen Ort zur Verwaltung von Unternehmens- Identitäten
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.
Maßnahme: Alle Endgeräte sind Mitglied der Active Directory Domäne
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.
Maßnahme: Alle Identitäten werden zentral gepflegt. Es gibt keine operativen lokale Accounts auf Servern und anderen Endgeräten.
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.
Prämisse: Rollen und Berechtigungen sind strikt zu trennen
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:
Der manuelle Aufwand ist sehr hoch, da die Berechtigungsvergabe sehr kleinteilig ist.
Es bedarf tiefgehender Kenntnisse der Berechtigungsvergabe für die Fachanwendung, d.h. jede Anpassung, Neuanlage etc. muss durch den Fachanwendungs- Administrator durchgeführt werden.
Das es ein manueller Vorgang ist, werden sich mit der Zeit Fehler und Abweichungen ergeben. Auch gewollte Abweichungen entstehen auf diese Weise.
In der Folge entsteht eine nicht durchschaubare Berechtigungsstruktur, die im schlechtesten Fall Einstiegsmöglichkeiten für Angreifer bietet.
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 – schematische Darstellung via ADDS -und Entra ID
RBAC
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.
Prämisse: Die Administration von Infrastruktur und Fachanwendungen ist stets streng von der Bürokommunikation zu trennen.
Lösung: PAM – Privileged Access Management
Alle Maßnahmen der Verwaltung von erweiterten Rechten werden unter dem Begriff „Privleged Access Management“ PAM zusammengefasst.
Maßnahme: PAW – Privileged Access Workplace
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.
Maßnahme: PAA – Privileged Access Accounts
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.
Enterprise Access Management (EAM)
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.
Prämisse: Der Status des AD muss jederzeit transparent und nachvollziehbar sein.
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.
Maßnahme: Vermeidung von Leichen und Aliens im AD
Monitoring und Reporting am besten Tag- genau.
Jedes Objekt im AD hat eine definierte Aufgabe
Jedes Objekt im AD muss nachvollziehbar dokumentiert sein.
Jedes nicht mehr genutzte Objekt im AD muss unverzüglich entfernt werden.
Authentifizierung &
Autorisierung
Prämisse: Direkter Zugriff auf das Active Directory ist nicht zulässig
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.
Maßnahme: Definition der Authentifizierungs- Zugriffswege
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.)
Maßnahme: Change Management & Automatisierung
Ä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.
Prämisse: Anzahl der Anmeldungen / Passwörter ist auf ein Minimum zu reduzieren
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.
Maßnahmen: SSO & VAULT & Identity Trust
Einführung von SSO wo möglich und sinnvoll.
Einführung eines Passwort Management Systems (Vault) für alle notwendigen Passwörter.
Einführung von Identity Trusts zwischen einem Identity Provider im Unternehmen und dem Service Anbieter im Internet. Damit entfallen Anmeldungen an Cloud Services, die im Unternehmen allgemein zur Verfügung stehen.
Prämisse: Service Accounts sind besonders zu schützen.
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.
Maßnahmen: Verantwortliche, Passwort Generierung und Password Vault
Service Accounts haben immer einen Verantwortlichen im Unternehmen.
Service Account Passwörter sind zu generieren und in einem Vault (virtueller Tresor) zu hinterlegen.
Service Account Passwörter sind nach X Tagen automatisch zu ändern. Sie sind nur den korrespondierenden Systemen bekannt.
Prämisse: Die Identität muss bei der Authentifizierung überprüfbar sein.
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.
Maßnahme: Mehr-Faktor-Authentifizierung
Eine Mehr-Faktor Authentifizierung ist mindestens an den Stellen, an denen ein Security Level verlassen wird, notwendig.
Maßnahme: Benutzerzertifikate
Das Benutzerzertifikat stellt sicher, dass die Identität zum Unternehmen gehört.
Sicherheit der
Infrastruktur
Prämisse: Ein einzelnes Objekt muss wiederhergestellt werden können.
Backup und Restorte auf Objektebene sind zwingend. Da gibt es keine Diskussion.
Prämisse: Das Active Directory muss mit dem aktuellen Stand schnell reinstalliert werden können.
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.
Prämisse: Die Produktionsumgebung darf nicht ohne Change Prozess verändert 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.
Maßnahme: Staging
Für jeden Stage gibt es ein ADDS, eigenes ADCS und ADFS. So können Entwicklungs- und Testaufgaben bis zur Produktionsreife gebracht werden, ohne das ADDS In der Produktion zu kompromittieren.
Es sollte mindestens zwei Stages geben: Test & Entwicklung in einem Stage sowie Produktion. Je nach Größe des Unternehmens und dem betriebenen Entwicklungsaufwand sind drei Stages ideal: Entwicklung, Test, Produktion.
Maßnahme: Einführung ITIL Change Prozess
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.
Prämisse: Kerberos- Kommunikation ist auf ein Mindestmaß zu reduzieren.
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.
Maßnahme: SAML & oAuth & …..
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.
Prämisse: Alle Kommunikationsverbindungen sind verschlüsselt.
Damit Informationen nicht durch „Man in the Middle“ Attacken kompromittiert werden kann, ist jegliche Kommunikation zu verschlüsseln.
Maßnahme: Prüfen und Einführen von TLS 1.3
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.
Prämisse: Alle Computer sind durch Zertifikate identifizierbar
Voraussetzung für viele Prämissen ist ein gültiges, durch eine CA signiertes Maschinenzertifikat.
Maßnahme: Alle Computer werden automatisch mit einen gültigen Maschinenzertifikat ausgestattet.
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.