​Wie Ihr vielleicht auf unseren Social Media Kanälen gesehen habt, haben wir uns eine Woche von Kundenprojekten freigenommen, um uns auf unsere “nächste große Sache” zu konzentrieren😊 .

Wir betrachten den ESAE-Ansatz von Microsoft als Grundlage für modernste unternehmensweite Sicherheit. Unsere Erfahrung bestätigt, dass viele Aspekte von ESAE organisatorische und prozessuale Änderungen erfordern, um die von Microsoft vorgeschlagenen Technologien in der ESAE-Architektur erfolgreich einzusetzen. Neben unserem Active Directory Assessment, das unseren Kunden einen guten Überblick über ihre Sicherheitslage gibt und unsere Projektarbeit zur Unterstützung unserer Kunden bei der Umsetzung effektiver Maßnahmen zur Sicherung ihrer Umgebung, sind wir dabei, ein Training für Active Directory-Administratoren zu entwickeln.

Das Training befähigt die Teilnehmer, Angriffe und Gegenmaßnahmen sowie die Auswirkungen auf Prozesse und ihre tägliche Arbeit besser zu verstehen. Das Training besteht aus einem Teil Theorie und drei Teilen praktischer Inhalte.

Alle Teinehmerinnen / Teilnemer erhalten Zugang zu einer eigenen Umgebung. Diese Umgebungen müssen ad-hoc, schnell, wiederholbar und mit geringem menschlichen Interaktion verfügbar sein. Während unserer Recherche haben wir kein Open-Source-Projekt gefunden, das unseren Bedürfnissen vollständig entspricht, also haben wir uns entschieden, es selbst zu tun 😊. Während unseres Hackathons konnten wir einen funktionierenden Proof of Concept erstellen, den wir mit Euch in diesem Blogbeitrag teilen möchten.

Lab (automatisierungs) Anforderungen:

Die Ausführungen oben, führen zu folgenden Anforderungen:

• • “Single Click” Setup für die Person, die die Labs einrichtet.
  • Labs sollen langfristig für mehrere (Cloud-)Anbieter (mindestens Azure, AWS und Hyper-V) einsetzbar sein.
  • Die Laborinfrastruktur sowie der Konfigurationszustand der Systeme (was sich im AD befindet usw.) sollten modular und auf Basis von Konfigurationsdateien aufgebaut sein.
  • Es muss möglich sein, mehrere Zustände des Labs einzusetzen (z.B. Beginn des Trainings, Beginn des zweiten Tages etc.).
  • Die Skripte müssen für alle Systeme in mehreren parallelen Umgebungen verwendbar sein. Alle Konfigurationsunterschiede stammen aus den Konfigurationsdateien.

Aktuelle PoC-Lösung

Der Prozess zum Auf- und Abbau der Umgebungen erfolgt nach den Prinzipien der Infrastructure-as-Code (IaC). Da wir (langfristig) für mehrere Anbieter verfügbar sein wollen, haben wir uns für Terraform als Engine für IaC entschieden. Im PoC werden alle Netzwerke, Computeressourcen und Berechtigungen etc. über AzureRM (Azure Provider für Terraform) bereitgestellt.

Wir wollen nicht mit benutzerdefinierten Bildern arbeiten oder auf Integrationstools zurückgreifen, die nur in einer der Cloud-Provider-Umgebungen verfügbar sind (z.B. gibt es keinen integrierten Puppet-Agenten für Hyper-V, CloudFormation ist in AWS verfügbar, etc.). Um es einfach zu halten, werden wir für die erste Konfiguration ausschließlich Windows-Umgebungen verwenden, und deshalb haben wir beschlossen, dass die gesamte Maschinenkonfiguration von PowerShell durchgeführt wird. Die Architektur muss es uns aber ermöglichen, das Lab in Zukunft problemlos um Linux-Systeme zu erweitern, z.B. mit Ansible anstelle von PowerShell.

Um eine solche Architektur zu erreichen, ohne in PowerShell unterzugehen, kommt es darauf an, die deklarative Leistungsfähigkeit von Terraform so weit wie möglich zu nutzen. Dies impliziert die Trennung der Infrastruktur-Orchestrierung, definiert als Konnektivitätsdefinitionen und Ressourcenberechtigungsverwaltung, vom VM-Konfigurationsmanagement.

Der interessante Teil der gesamten Übung ist das Abhängigkeitsmanagement zwischen den Rollen der Systeme: insbesondere Domain Controller vs. Domain Clients. Wir möchten, dass Terraform die Abhängigkeiten verwaltet, aber es ist nur auf der Grundlage des Ergebnisses von PowerShell möglich, das die Konfiguration von AD- und Benutzermaschinen richtig konfiguriert ist. Es gibt einige Möglichkeiten, wie Terraform die Abhängigkeit zwischen den Ressourcen verwalten kann.

• • Die erste und offensichtlichste ist die Verwendung eines expliziten depends_on = [“provider.some.resource.name”]]
  • Die zweite ist die Definition einer impliziten Abhängigkeit, indem eine Ressource die andere während ihrer Erstellung verwendet: