(E)SAE DEEP DIVE SERIE TEIL 7 – Tiering Modell - TEAL Technology Consulting GmbH
3022
post-template-default,single,single-post,postid-3022,single-format-standard,bridge-core-2.7.6,,qode-title-hidden,qode-child-theme-ver-1.0.0,qode-theme-ver-26.1,qode-theme-bridge,disabled_footer_top,qode_header_in_grid,qode-wpml-enabled,wpb-js-composer js-comp-ver-6.6.0,vc_responsive

(E)SAE DEEP DIVE SERIE TEIL 7 – Tiering Modell

Nachdem wir in unserem letzten Blog Artikel über das neue Microsoft Securing Privilege Access Model schrieben, möchten wir dieses Mal auf das klassische ESAE Tiering eingehen. Vorweg noch der Hinweis, dass im neuen Microsoft Modell nicht mehr von Tiering gesprochen wird, sondern von Levels of Security (Privileged Access, Specialized Security und Enterprise Security). Dazu gleich mehr, nur behaltet im Hinterkopf, dass wir gleich nochmals auf die Levels of Security zurückkommen werden. Doch nun, als Einführung in diesen Blog, zu unserer Infografik über das Tiering Model:

Warum Tiering?

Warum sollte man die Infrastruktur in verschiedene Tiers oder Levels aufteilen? Microsoft schrieb dazu in der ursprünglichen ESAE Dokumentation:

„The purpose of this tier model is to protect identity systems using a set of buffer zones between full control of the Environment (Tier 0) and the high risk workstation assets that attackers frequently compromise.“ (die deutsche Übersetzung von Microsoft vergessen wir lieber ganz schnell)

Ziel ist also, einen oder mehrere Puffer zwischen Systemen, die die Identitäten verwalten und den Systemen mit hohem Risiko von Angriffen zu schaffen. Ob nur Systeme, die Identitäten verwalten, geschützt werden müssen/sollten und welches die Systeme mit hohem Risiko sind, diskutieren wir im nächsten Abschnitt.

 

Tiering, aber wie?

Auch hier zunächst ein Blick in die Microsoft Dokumentation. Um die Systeme zu schützen, müssen die Accounts mit administrativen Zugängen geschützt werden. Das Tier Modell dreht sich daher um den Schutz dieser Accounts und sieht im Standard 3 Tiers vor:

Tier 0: Administrative Accounts, die direkte oder indirekte Kontrolle über Enterprise Identitäten (im Gegensatz zu lokalen Identitäten z.B. lokalen SQL Accounts) haben

Tier 1: Administrative Accounts, die Kontrolle über Enterprise Server und Anwendungen haben

Tier 2: Administrative Accounts, die Kontrolle über Endbenutzer, Arbeitsplätze und Geräte haben

An dieser Stelle nochmals kurz der Vergleich zu den Levels of Security aus dem neuen Microsoft Model (Privileged Access, Specialized Security und Enterprise Security). Nach wie vor gibt es also 3 Levels oder wollen wir Tiers sagen? 😉

Im neuen Modell ist Privileged Access die sicherste Schicht, also Tier 0, danach folgt Specialized Security (könnte mit Tier 1 verglichen werden) und zuletzt Enterprise Security, das, ähnlich wie Tier 2, sämtliche unternehmensweite Sicherheits-Controls umfasst. Auch wenn Microsoft die Levels neu benannt hat, geht es weiterhin darum, verschiedene Schichten nach Schutzbedarf zu definieren und voneinander abzuschotten. Nun aber wieder zurück zu Tiering….

 

Wie sollen die administrativen Zugänge konkret geschützt werden? Als primären Schutzmechanismus sieht Microsoft hier die Einschränkung der Zugänge:

Dies Bilder sind wie folgt von Microsoft beschrieben:

  • Tier 0 Accounts administrieren die Tier 0 Systeme und können sich interaktiv nur an Tier 0 Systemen anmelden
  • Tier 0 Accounts können Assets in jedem Tier kontrollieren

 

  • Tier 1 Accounts administrieren die Tier 1 Systeme und können sich interaktiv nur an Tier 1 Systemen anmelden
  • Tier 1 Accounts können auf Assets auf Tier 0 lesend zugreifen („via network logon type“)
  • Tier 1 Accounts können Assets in Tier 1 und 2 kontrollieren

 

  • Tier 2 Accounts administrieren die Tier 2 Systeme und können sich nur an Tier 2 Systemen anmelden
  • Tier 2 Accounts können auf Assets in allen Tiers zugreifen („via network logon type“)
  • Tier 2 Accounts können Assets in Tier 2 kontrollieren

 

Neben der Beschränkung der Zugänge listet Microsoft noch zahlreiche weitere Schutzmaßnahmen in der Dokumentation. Die Beschreibung würde allerdings den Rahmen dieses Artikels sprengen. Wir verweisen deshalb nochmals auf die Dokumentation sowie unsere erste (E)SAE Blog Serie.

 

So viel zur Dokumentation. Jetzt noch einige Antworten zu Fragestellungen, denen wir in Projekten begegnet sind.

 

Müssen es genau drei Tiers sein?

Nein, wir haben durchaus schon gesehen, dass das Server Tier (1) nochmal unterteilt wurde in Infrastruktur und Business Server oder auch in schützenswerte und weniger schützenswerte Server. Man sollte in der konkreten Situation den Schutzbedarf analysieren und anderen Aspekten wie der Usability gegenüberstellen und dann entscheiden, wie viele Tiers für den aktuellen Kontext am besten sind.

 

Dürfen nur „Identity Systems“ in Tier 0?

Auch hier: nein. Sollte die Risikoanalyse ergeben, dass ein anderes System den gleichen Schutzbedarf hat wie die „Identity Systems“ und mit den gleichen Prozessen betrieben werden können, kann auch ein anderes System dem Tier 0 zugeordnet werden. Allerdings sollte man dabei den Grundsatz beachten, die Anzahl der Administratoren in Tier 0 so gering wie möglich zu halten. In der Praxis bleibt es daher meistens bei den „Identity Systems“ in Tier 0 und man unterteilt wie oben beschrieben das Server Tier.

Nicht zu vergessen sind aber Systeme, welche ein Tier 0 System kontrollieren können („indirekte Kontrolle von Enterprise Identitäten“). Man denke beispielsweise an einen Monitoring- oder Backup Agenten, der im Systemkontext betrieben wird. Diese Systeme sind zwingend entweder als Tier 0 anzusehen oder es müssen eigene Tier 0 Instanzen aufgebaut werden.

Mindestens folgende Systeme sind aus unserer Sicht als Tier 0 zu behandeln:

  • Active Directory Domain Controller
  • Azure AD connect
  • Federation services
  • PKI Systeme
  • Privilege Administrative Workstations
  • IAM Systeme
  • PAM Systeme
  • Systeme, die andere Tier 0 Systeme verwalten

 

Wie kann diese Trennung in der Praxis umgesetzt werden?

Die Trennung erfolgt mit einer Kombination aus OUs, Gruppen und Gruppenrichtlinien. Vereinfacht dargestellt könnte das so aussehen:

Es gibt pro Tier eine OU mit weiteren Unter-OUs zur logischen Trennung von Servern, Usern und Gruppen etc. In jedem Tier gibt es eine Gruppe, in der alle Admin Accounts Mitglied sind.

Für Tier 1 und 2 gibt es jeweils eine GPO, in der die Logon Einschränkungen konfiguriert werden.

In der Tier 1 Policy wird den Tier 0 Admins der Logon verwehrt.

In der Tier 2 Policy werden sowohl den Tier 0 als auch den Tier 1 Admins der Logon verboten.

Fazit

Das Einführen von Tiering ist, gerade in gewachsenen Umgebungen, eine nicht zu unterschätzende Aufgabe. Allerdings ist es ein wichtiger Eckpfeiler für viele weiterführende Maßnahmen und ein massiver Sicherheitsgewinn, da es das Lateral Movement von Angreifern sehr erschwert. Im Zweifel bietet sich an, zunächst nur Tier 0 Systeme zu isolieren. Erst danach werden Tier 1 und Tier 2 Systeme geschützt. Dies hat den Vorteil, dass man zum einen die wichtigsten Systeme abschottet und gleichzeitig Erfahrung mit dem Tiering Modell sammeln kann. So ist eine Ausweitung auf Tier 1 und 2 im Anschluss einfacher zu bewerkstelligen.

LATEST POSTS