Einführung ESAE und Fragen zur Umsetzung

[Symbadisch 10]

Hallo,

wir sind aktuell in der Umsetzung diverser Punkte zu ESAE.

 

Angefangen haben wir mit der Umsetzung der Aufteilung der Systeme in die drei Tiergruppen. Wir haben eine recht überschaubare Umgebung mit ca. 350 Usern und ca. 90 Servern in einer VMware-Umgebung.

 

Für den Zugriff auf die drei Gruppen haben wir jeweils einen Windows Server 2019, welchen wir bei Tier 1 und 2 mit der Rolle des RDS installieren, da wir hier mit mehr als zwei gleichzeitigen Usern rechnen, bei T0 hingegen nicht.

Der Zugriff auf die beiden PAWs erfolgt ausschließlich von unseren Clients und mit zusätzlich benötigtem OTP. 
 

Nun zu meiner Frage:

- Wir melden uns auf den beiden PAWs ja direkt mit dem jeweiligen T-Admin per RDP an, wir haben also direkt Adminzugriff auf dem System. Ist das bereits falsch und kritisch bzw werden die rdp-Anmeldedaten auf unserem normalen Client gespeichert und sind somit abgfreifbar?

 

 

[v-rtc 88]

Bei der PAW (ist ja abgesichert) meldet Ihr Euch am besten mit ner SmartCard z.B. an, nach der Anmeldung solltet Ihr in die Dom Admin Gruppe rutschen und beim abmelden wieder raus.

bearbeitet 2. November 2019 von v-rtc

[falkebo 21]

vor 9 Stunden schrieb Symbadisch:

Nun zu meiner Frage:

- Wir melden uns auf den beiden PAWs ja direkt mit dem jeweiligen T-Admin per RDP an, wir haben also direkt Adminzugriff auf dem System. Ist das bereits falsch und kritisch bzw werden die rdp-Anmeldedaten auf unserem normalen Client gespeichert und sind somit abgfreifbar?

Das Konzept von Microsoft sieht vor dedizierte PAWs nur für administrative Aufgaben bereitzustellen.
Alternativ "darf" man eine VM in die PAW installieren um normale Office Tätigkeiten durchzuführen, nicht jedoch andersrum.

 

Aber zu deiner Frage direkt, ja ist es.
Ist sogar eine Prüfungsfrage für die 70-744.

[Symbadisch 10]

vor 5 Stunden schrieb v-rtc:

Bei der PAW (ist ja abgesichert) meldet Ihr Euch am besten mit ner SmartCard z.B. an, nach der Anmeldung solltet Ihr in die Dom Admin Gruppe rutschen und beim abmelden wieder raus.

Ist das nicht genau das was verhindert werden soll, nämlich das ich als T1-Admin die DomAdmin-Gruppe Rutsche? Oder verwechselst du PAW mit PAM?

vor 53 Minuten schrieb falkebo:

Das Konzept von Microsoft sieht vor dedizierte PAWs nur für administrative Aufgaben bereitzustellen.
Alternativ "darf" man eine VM in die PAW installieren um normale Office Tätigkeiten durchzuführen, nicht jedoch andersrum.

 

Aber zu deiner Frage direkt, ja ist es.
Ist sogar eine Prüfungsfrage für die 70-744.

Sorry, b***d ausgedrückt. Die PAW läuft nicht auf einer VM auf dem Client, sondern auf unser VMware-Umgebung.

Wenn die Anmeldedaten auf unserem Client gespeichert sind, ist das doch aber wenig zielführend, da ein Angreifer ja sofort Admin-Berechtigung auf alle T1-Server hätte, mal von OTPabgesehen. Wie wäre hier also der korrekte Zugriff?

[daabm 1.354]

Die PAW läuft in der VMWare-Umgebung? Und die ist komplett T0? Das ist eines der Probleme bei ESAE - Tier-Traversal... Die PAW ist T0, läuft virtuell auf VMWare, was eigentlich T1 ist. Und schon isses Grütze. Woher ich das weiß?

 

[falkebo 21]

vor 2 Stunden schrieb Symbadisch:

Sorry, b***d ausgedrückt. Die PAW läuft nicht auf einer VM auf dem Client, sondern auf unser VMware-Umgebung.

Ich hab dir mal was passendes zu diesem Thema rausgesucht:
https://docs.microsoft.com/en-US/windows-server/identity/securing-privileged-access/privileged-access-workstations#jump-server

 

Das Problem in deinem Design, du verstößt gegen das "Clean Source" Prinzip.
"The clean source principle requires all security dependencies to be as trustworthy as the object being secured."

In deinem Fall könnte dein Client ja kompromittiert sein. Das Risiko kann durch mehrstufige Authentifizierung am Remote PAW zwar verringert werden, ist aber immer noch da.

[v-rtc 88]

2 hours ago, Symbadisch said:

Ist das nicht genau das was verhindert werden soll, nämlich das ich als T1-Admin die DomAdmin-Gruppe Rutsche? Oder verwechselst du PAW mit PAM?

Sorry, b***d ausgedrückt. Die PAW läuft nicht auf einer VM auf dem Client, sondern auf unser VMware-Umgebung.

Wenn die Anmeldedaten auf unserem Client gespeichert sind, ist das doch aber wenig zielführend, da ein Angreifer ja sofort Admin-Berechtigung auf alle T1-Server hätte, mal von OTPabgesehen. Wie wäre hier also der korrekte Zugriff?

Nein. T0 Konto, was erst mit der Anmeldung in die DomAdmin Gruppe rutsch und beim Abmelden wieder raus.

Die PAW ist ja nur für T0 oder? (Ja gibt dann auch eine für T1 und T2)

bearbeitet 2. November 2019 von v-rtc

[daabm 1.354]

Ich werf mal die Shadow Principals noch in den Raum, dann wird die Diskussion komplett wirr

[falkebo 21]

vor 3 Minuten schrieb daabm:

Ich werf mal die Shadow Principals noch in den Raum, dann wird die Diskussion komplett wirr

Die Jungs bei MS waren auf jeden Fall kreativ beim ESAE Design

[daabm 1.354]

Ja. Frei von Kostendruck und Organisationshemmnissen, einfach mal machen, was ginge. Ich find's gut, aber Du kriegst es nicht umgesetzt. Erstens zu teuer, zweitens zu viele organisatorische Hindernisse... Wir machen, was halt machbar ist.

[falkebo 21]

vor 2 Stunden schrieb Symbadisch:

Wie wäre hier also der korrekte Zugriff? 

Um vielleicht nochmal einen Denkansatz zu geben.
MS Empfehlung: Dedizierte PAW Kiste, Windows 10 Enterprise mit Credential Guard, Device Guard und Bitlocker.
Durch Security Templates mit GPOs gehärtet.

[v-rtc 88]

1 minute ago, falkebo said:

Um vielleicht nochmal einen Denkansatz zu geben.
MS Empfehlung: Dedizierte PAW Kiste, Windows 10 Enterprise mit Credential Guard, Device Guard und Bitlocker.
Durch Security Templates mit GPOs gehärtet.

Dazu kann man dann noch SCAMA machen wenn gewünscht und Geld vorhanden 

[Symbadisch 10]

Erstmal vielen Dank für all euren Input und die Aufschlauung - das ganze Thema ist echt nicht ohne.

 

Bin auch froh hier nachgefragt zu haben, auch wenn es unser Konzept etwas durcheinander wirft. Muss auch zum Hintergrund sagen, sind bei dem Thema gelandet da es mir schon lange ein Dorn im Auge ist das wir Admins aktuell alle mit einem persönlichen DomainAdmin-User unterwegs sind, der auch für die Clientadministration genutzt wird. Das zu ändern ist für uns die höchste Prio.

 

Ich denke wir können unsere Umgebung aktuell nicht komplett ESAE-konform machen, da fehlen uns die Ressourcen aktuell. 

 

Zurück zum Thema: Werden für jeden Admin einen Jump-Host einrichten, welcher nicht in der Domain ist und entsprechend gehärtet wird, von diesem springen wir dann auf die T-Adminmaschinen. Werden das allerdings mit Win2019 machen. Theoretisch könnten wir die JumpHosts auch auf eigener VM-Hardware installieren, aber das ganze soll auch noch praktikabel sein und im Vergleich zum aktuellen Ist-Stand haben wir dadurch schon einen enormen Sicherheitsgewinn und einen Schritt in die richtige Richtung.

 

Für nächstes Jahr haben wir einige Investitionen im Bereich IT-Security geplant, haben die letzten Jahre hier definitiv viel zu wenig gemacht. Hier werden wir uns auch einen bzw. mehrere Dienstleister ins Haus holen, welche uns auf dem weiteren Weg begleiten werden. 

 

Bis dahin leben wir mit dem Kompromiss und machen das was mit überschaubarem Aufwand umsetzbar ist.

 

 

[Dukel 454]

Das wichtigste ist das die Tiers nicht gemischt werden und z.B. Credentials von Unterschiedlichen Tiers nicht auf der gleichen Maschine gespeichert werden.

Das geht entweder mit Unterschiedlichen Jump Servern / Maschinen oder Credential Guards.

[v-rtc 88]

Hallo noch mal,

 

kurz eine Frage. WSUS für Clients, Tier 1 oder Tier 2? Kollege und ich knobeln gerade.

Grüße