5 minutes reading time (929 words)

ESAE Serie Teil 2 – Kundensituation und Architektur

cyber-security-600_360

Wie in unserem Einleitungsartikel zur ESAE Serie angekündigt, möchten wir hier im zweiten Artikel näher auf die Kundensituation und die Architektur der Lösung eingehen.

Obwohl der Kunde in zahlreichen Ländern weltweit vertreten ist, arbeiteten die einzelnen Landesgesellschaften in der Vergangenheit weitestgehend autark. Es gab nur wenig gemeinsam genutzte Applikationen und kaum gemeinsame Projekte. Mit der neuen Firmenstrategie sollten die Landesgesellschaften näher zusammenrücken und gemeinsam das Geschäft weiter vorantreiben.

Mit dem Wunsch, gemeinsam Applikationen nutzen zu können, stellt sich unweigerlich die Frage, wie sich die Benutzer gegenüber der Applikation authentifizieren sollen. Aktuell hat jede Landesgesellschaft ihren eigenen Verzeichnisdienst (meistens Active Directory). Active Directory Trusts existieren nicht. Eine technische Lösung wäre natürlich, Trusts zwischen den Gesellschaften, die miteinander arbeiten wollen, einzurichten. Voraussetzung dafür ist, dass die Domänencontroller der verschiedenen Firmen miteinander kommunizieren können, was eine dauerhafte Netzwerkverbindung mit entsprechender Firewallkonfiguration zwischen den Gesellschaften bedingt. Da Active Directory Forest Trusts nicht transitiv sind (Microsoft Trust Dokumentation), würde die Lösung zu einer Vielzahl an Trusts führen, die verwaltet werden wollen:



Andererseits funktionieren Pass the Hash (PtH) und Pass the Ticket (PtT) Attacken auch über Trust Grenzen hinweg. Um solch ein Konstrukt sicher betreiben zu können, müssten alle Landesgesellschaften die gleichen Sicherheitsmaßnahmen treffen und diese konsequent überwachen. Im Falle unseres Kunden ist das heute nicht der Fall.

Eine andere Lösung stellt die Claims Based Authentication dar. Mit dem Aufkommen von Cloud Applikationen wurde diese Art der Authentifizierung immer populärer und wichtiger. Dabei geht es darum, dass die Identitäten separat von der Applikation verwaltet werden. Im ersten Schritt geht der Application Provider eine Vertrauensstellung mit einem Identity Provider (z.B. Active Directory Federation Services) ein. Im zweiten Schritt wird der Benutzer anhand von verschiedenen Informationen (Claims) identifiziert. Diese Claims werden mit einem Security Token transportiert.

Quelle: faq-o-matic.net 



Eine ausführlichere Beschreibung ist am Ende des Artikels verlinkt (Link 2). Wie auf dem Bild zu sehen, kann das Verfahren lose gekoppelt über das Internet genutzt werden, muss aber nicht.

Als aufmerksamer Leser werden Sie sich jetzt fragen, ob man damit nicht genau so viele (ADFS-) Trusts braucht wie im oben beschriebenen Szenario. Auf den ersten Blick ja, allerdings können die Microsoft Active Directory Services so konfiguriert werden, dass eine zentrale Instanz quasi als Drehscheibe für die Authentifizierungstokens agiert. Somit muss jede Applikation und jeder Identity Provider (aka Landesgesellschaft) genau einen Trust mit der zentralen Instanz eingehen.


Genau solch ein Konstrukt sollte in einer separaten Lokation neu aufgebaut und mittels ESAE administriert werden.

Die Anforderungen

Jetzt stellt sich natürlich die Frage, welche Komponenten für die Gesamtlösung notwendig sind und nach welchen Prinzipien diese aufgebaut und betrieben werden sollen. Nachfolgend haben wir versucht, das möglichst kompakt zusammenzufassen. Dabei beschränken wir uns auf die Besonderheiten einer ESAE Umgebung und lassen einige Aspekte, die für den Betrieb jeder IT Umgebung notwendig sind (z.B. detaillierte Backup und Desaster Recovery Anforderungen) in der Aufzählung aus.

Schichtentrennung und Least Priviledge Administration

  • Physische und logische Trennung der Tier 0 Systeme von Tier 1 und 2

  • Keine Nutzung von Tier 1 und 2 Services, die ein Tier 0 System kompromittieren könnten (z.B. Monitoringagent)
  • Zugriffsbeschränkung auf Konten (Administration nur auf gleichem Tier. Kein Login auf niedrigerem Tier):


Quelle: Microsoft

  • Principle of Least Priviledge mit Just in Time Administration

Härtung

  • Alle Systeme müssen nach Best Practice gehärtet werden.
  • Administrativen Zugriff nur über gehärtete Priviledge Admin Workstations mit Multi-Faktor Authentifizierung
  • Verschlüsselung der Festplatten
  • Installation nur von vertrauenswürdigen Quellen (Hash Kontrolle)
  • Lange Passwörter mit kurzen Laufzeiten. Für Dienstkonten möglichst Group Managed Service Accounts

Prozesse und Betrieb

  • Reduktion der Tier 0 Administratoren auf ein Minimum
  • Gut ausgebildetes Personal mit positivem Führungszeugnis

Wer schon länger in der IT unterwegs ist, dem kommen die meisten Anforderungen sicherlich bekannt vor. Wie im Einleitungsartikel dargestellt, handelt es sich bei einer ESAE Umgebung nicht um eine bahnbrechende neue Technologie, sondern größtenteils um die konsequente Umsetzung verschiedener Techniken und Vorgehensweisen. Allerdings hat Microsoft für die Anforderung "Principle of Least Priviledge mit Just in Time Administration" doch eine neue technische Antwort, die genau für die Abwehr von Credential Theft und PtH / PtT Attacken entwickelt wurde.

Genau, Sie haben schon richtig vermutet, es handelt sich dabei um den im Einführungsartikel erwähnten Administrationsforest mit Priviledge Access Management Lösung. Konkret realisiert wird das durch ein neues Active Directory Feature, dem Shadow Principal, in Verbindung mit dem neuen Microsoft Identity Manager (MIM) Modul „Priviledge Access Management (PAM)". Wie das genau funktioniert, beschreiben wir im nächsten Artikel der Serie.

Abschließend zeigen wir noch die konkrete Gesamtarchitektur des Kundenprojektes auf:


Wie auf dem Diagramm zu sehen ist, besteht die Umgebung nur aus einer Handvoll Server. Auf den ersten Blick erscheint es viel Aufwand, eine ESAE Umgebung nur für den Betrieb von zwei ADFS Servern aufzubauen. Dies ist dem Projektvorgehen des Kunden geschuldet, welches den phasenweisen Auf- und Ausbau der Umgebung vorsieht. Die dargestellte Architektur ist nur der erste Schritt. Perspektivisch sollen sowohl weitere kritische Dienste in der Umgebung aufgebaut (z.B. eine globale lPKI) und zum anderen wird die Umgebung durch weitere Sicherheitsmaßnahmen erweitert (z.B. Anbindung an ein SIEM System).

Nachfolgend noch der Vollständigkeit halber eine Liste der Systeme mit einer kurzen Funktionsbeschreibung. Auf die Kernkomponenten werden wir in Folgeartikeln näher eingehen.

  • 2 Hyper-V Server
  • oVirtualisierungsplattform zum Hosten aller weiteren Systeme
  • Externe Firewall und VPN Gateway
  • oEndpunkt für den Aufbau der Administrationsverbindungen
  • oÄußere Firewall
  • Loadbalancer
  • oLoadbalancing für die ADFS Server
  • Interne Firewall
  • oTrennung DMZ und internes Netz
  • 2 Active Directory Domain Controller („Green Forest")
  • oProduktionsforest mit den Diensten, die konsumiert werden sollen
  • 2 Active Directory Domain Controller („Red Forest")
  • oAdministrationsforest mit den Tier 0 Systemen
  • 2 Active Directory Federation Server
  • oDrehscheibe für Claims based Authentication
  • 1 MIM PAM Server
  • oPriviledged Access Management mit Just in Time Administration
  • 1 WSUS Server
  • oInstallation von Microsoft Updates
  • 1 SCOM Server, ein SCOM Gateway und ein SQL Server für die SCOM Datenbanken
  • oÜberwachung der Umgebung
  • 1 NXLog Server
  • oSammeln und weiterleiten von Event Log Einträgen
0
ESAE Serie Teil 1 - Einleitung

Related Posts

 

Comments

No comments made yet. Be the first to submit a comment
Guest
Thursday, 24 May 2018
© 2018 TEAL Technology Consulting GmbH