Dieses Mal ein Novum: ein ausführlicher Gastbeitrag von meinem Kollegen Andreas Wach, der sich intensiv mit der Thematik auseinander setzt und dieser Inhalt in meinen Augen so wichtig ist, dass ich ihm hier den Raum gebe, es allen kund zu tun:
Der folgende Artikel wurde von mir, Andreas Wach, privat in meiner Freizeit verfasst und wurde NICHT explizit von Microsoft freigegeben.
Inhalt
- Intro
- Was ist ein SOC
- Braucht jeder 24/7?
- Was war DAP?
- Was ist GDAP
- Alles so komplex! Wo anfangen?
- So viele Tenants!?
- Was sind die Voraussetzungen?
- Welche Services sollte ein SOC bedienen?
- Was muss eingerichtet werden?
- Wie wird Sentinel Connect & Azure Lighthouse angebunden?
- Quellen
Intro
Jeder Partner / Kunde sollte sich Gedanken machen, ob er ein SOC (Security Operation Center) betreibt / konsumiert, da dies aus mehreren Perspektiven wichtige Vorteile bietet:
- Skalierbares Security Monitoring
- Angriffe erkennen bevor großer Schaden entstanden ist, damit rechtzeitig Gegenmaßnahmen eingeleitet werden können
- „nutzen“ der Fachkräfte (vom Partner) anstatt eigene Security Spezialisten (auf dem leeren Jobmarkt) zu suchen
- „Around the clock“ (24/7) Sicherheit (und nicht nur 8-17 Uhr oder jeden Freitag, wenn der Netzwerkadmin mal Zeit hat in die Logs zu schauen)
Was ist ein SOC?
„Ein Security Operations Center (SOC) ist ein Zentrum, das Dienstleistungen für die IT-Sicherheit bietet: ein Verfahren zur Vorbeugung und Behandlung von unvorhergesehenen Schwierigkeiten. Die Aufgabe dieser Infrastruktur ist die Vorbeugung gegen das Risiko, das alle Aktivitäten der IT-Sicherheit mit Hilfe von Zentralisierung und Analyse aller menschlichen Ressourcen sowie der Hardware und Software zur Verwaltung des Sicherheitssystems beinhaltet. Dabei vereint es die drei Teilbereiche Menschen, Prozesse und Technologien um die Sicherheitslage einer Organisation zu steuern und zu verbessern.“
Quelle Security Operations Center – Wikipedia
Sehr schön wurde das hier CISO Series: Lessons learned from the Microsoft SOC—Part 1: Organization – Microsoft Security Blog aufbereitet, inkl. Rollen und Tiers.
Braucht jeder 24/7?
NEIN!
Warum, nein? Das widerspricht doch dem Rest des bisherigen Artikels!?
Aus meiner Sicht „schreien“ alle Kunden immer: „wir brauchen 24/7“. Jedoch muss hier ganz klar betrachtet werden, dass nicht nur der Partner in seinem SOC 24/7 liefern muss, sondern viel wichtiger: der Kunde muss in der Lage sein, IMMER (jeden Tag, jede Minute, am Wochenende, an Feiertagen, an Heiligabend und Silvester, … IMMER) auf die Anfrage vom Partner zu reagieren. Gerade das bringt mich zu der Aussage, dass NICHT alle Kunde sofort einen SOC mit 24/7 brauchen. Ich sehe es gerade bei kleineren Kunden aktuell so, dass diese oft (noch) nicht in der Lage sind die notwendigen Ressourcen und Schichtmodelle bereitzustellen.
Anders sieht dies für Kunden aus, die bereits eine längere Reise zusammen mit ihrem vertrauten SOC Partner/Dienstleister gemacht haben und am schon „geübt“ sind, ebenso wie größere Kunden und diejenigen, die überregional oder multi-national aufgestellt sind.
Was war DAP?
„Delegierte Administratorrechte (Delegated Administration Privileges, DAP) ermöglichen es einem Microsoft Partner, Dienste oder Abonnements/Tenants eines Kunden in dessen Namen zu verwalten.“
Quelle: Häufig gestellte Fragen zu delegierten Administratorrechten (DAP) – Partner Center | Microsoft Learn
Problem hierbei, der Partner hat immer direkt Global Admin Rechte im Kunden Tenant erhalten.
DAP ist abgekündigt:
„Ab dem 17. Januar 2023: Microsoft erstellt keine DAP-Beziehungen mehr, wenn eine neue Kunden- oder Handelspartnerbeziehung erstellt wird. Partner müssen Azure AD-GDAP-Rollen von Kunden anfordern, um sie verwalten zu können. Microsoft beginnt damit, inaktive DAP-Beziehungen zu entfernen, die seit mindestens 90 Tagen nicht verwendet wurden.“
Quelle: Häufig gestellte Fragen zu GDAP – Partner Center | Microsoft Learn
Also muss der Partner jetzt handeln und nicht nur bestehende DAP Verbindungen zu GDAP (Granular Delegated Admin Privileges – auf Deutsch: differenzierten delegierten Administratorrechten) überführen, sondern auch neue Kunden Verbindungen nur noch via GDAP erstellen!
Was ist GDAP?
„GDAP-Funktionen ermöglichen es Partnern, den Zugriff auf die Workloads ihrer Kunden zu steuern, um ihre Sicherheitsbedenken besser zu erfüllen. Partner können Kunden, die mit den aktuellen Ebenen des Partnerzugriffs möglicherweise unangenehm sind, weitere Dienste anbieten. Sie können auch Dienstleistungen für Kunden anbieten, die gesetzliche Anforderungen haben, die den Zugriff auf Partner mit den geringsten Berechtigungen erfordern.“
Quelle: Einführung in granulare delegierte Administratorrechte (GDAP) – Partner Center | Microsoft Learn
Was soll erreicht werden?
Das Ziel ist es, einen SOC bereitzustellen, der…
- …über mehrere Mandanten (Tenants) hinweg sicher betrieben werden kann (Skalierbarkeit)
- …eine Abgrenzung von Kundendaten hat (Compliance)
- …für den SOC Analysten eine „Single View“ bietet (Verwaltbarkeit)
- …hoch verfügbar ist, um schnell auf „Vorkommnisse“ reagieren zu können (Verfügbarkeit)
- …besondere Absicherung beim Zugriff auf Kundendaten und -umgebungen bietet (Sicherheit)
Alles so komplex! Wo anfangen?
Starten wir einfach mit der Tenant Struktur, die (vermutlich) heute bei jedem Partner bereits vorhanden ist:
Auf der linken Seite die beiden Partner Tenants, welche gemäß Microsoft Best Practice bereits heute in einen „Partner Tenant“ und einen „Partner CSP Tenant“ („Partner Cloud Solution Provider Tenant“) unterteilt sind (siehe Abbildung 1).
Auf der rechten Seite die Kunden Tenants, welche später mit einem SOC Service bedient werden sollen.
Darüber hinaus erläutere ich im weiteren Verlauf dieses Artikels, warum die Architektur durch einen „Partner SOC Admin Tenant“ ergänzt werden sollte, welche Vorteile diese bietet und welche Konfigurationen dafür durchgeführt werden müssen, bevor der erste Kunde mit dem Service bedient werden kann (siehe Abbildung 2).
So viele Tenants!?
Welcher Tenant ist für was?
Die Vielzahl (drei unterschiedliche) Tenants, ist durch die jeweilige, unterschiedliche Funktion und die daraus resultierende unterschiedliche Zielgruppe definiert.
Außerdem können dadurch zielgerichtet unterschiedliche Maßnahmen zur Absicherung getroffen werden (Stichwort Härtung / Hardening, Least Privileges/geringste Rechte und Zero Trust).
Wichtig ist hierbei die Unterschiedlichen Rollen von jedem einzelnen Tenant beim Partner zu verstehen (Abbildung 3).
- Partner Tenant
- Das ist der „Heimat-Tenant“ von dem Mitarbeitenden beim Partner (z.B. @partnername.de)
- Partner SOC Admin Tenant (z.B. @partnername-soc-admin.onmicrosoft.de)
- Seperater Tenant, bei dem jeder SOC Analyst ein eigenes (Cloud only) Konto hat.
- Partner CSP Tenant (z.B. @csp-partnername.de)
- Tenant für CSP Lizensierung und um Tickets im Namen des Kunden zu erstellen.
Was muss auf jedem Tenant gemacht werden?
Nachdem die Zwecke und Rollen der Tenants nun klar sind, geht es im nächsten Schritt um die Tätigkeiten, welche auf dem jeweiligen Tenant durchgeführt werden (Abbildung 4):
- Partner Tenant
- Dies stellt den produktiven Tenant der Partnerunternehmung dar, hier werden Emails versendet, Dateien geteilt, gechattet, etc.
- Partner SOC Admin Tenant
- hier erhält der SOC Analyst eine zentrale Ansicht auf alle „Vorkommnisse“ aus allen unterschiedlichen Kundentenants und kann direkt darauf reagieren (z.B. via Playbooks).
- Partner CSP Tenant
- Der CSP Tenant dient dazu, Lizenzen und Azure Subscriptions via CSP (direct / indirect) dem Kunden bereitzustellen. Außerdem werden über den CSP Tenant Microsoft Supporttickets für den Kunden erstellt und bearbeitet.
Was sind die Voraussetzungen?
Was sind die Partner Center Voraussetzungen?
Pro Partner Tenant kann auf ein dediziertes Partnercenter zugegriffen werden, das bedeutet also, dass es mehr als nur ein Partner Center gibt. Der Zugriff auf das entsprechende Partner Center ist nur möglich, wenn der Tenant auch als Partner Tenant eingestuft wird.
Ein neu erstellter, „leerer“ Tenant hat keinen Zugriff auf das Partner Center, da dieser als Kundentenant anzusehen ist.
Das Partner Center wird pro Tenant für unterschiedliche Aufgaben verwendet (Abbildung 5).
- Partner Tenant
- Partner Center ist vorhanden, wird aber nicht verwendet.
- Partner SOC Admin Tenant
- Partner Center wird benötigt für die GDAP Assoziation zu den Kunden Tenants.
- Es wäre ebenfalls möglich, von diesem Tenant aus Lizenzen dem Kunden bereitzustellen, dies sollte aber organisatorisch unterbunden werden.
- Partner CSP Tenant
- Bereitstellung von Azure Subscription und M365 Lizenzen via CSP in die Kunden Tenants
Empfehlungen zur Tenant Härtung (Hardening)
Durch die unterschiedlichen Tenants ergeben sich unterschiedliche Härtungsmaßnahmen, welche umgesetzt werden müssen (Abbildung 6).
- Partner Tenant
- Partner SOC Admin Tenant
- Multi Factor Authentifizierung, da es sich hierbei um Zugriffe auf Kundendaten handelt.
- Privileged Identity Management (PIM), damit die administrativen Berechtigungen auf den Kundentenant nur dann zur Verfügung stehen, wenn Sie benötigt werden.
- Privileged Admin Worksation (PAW) / Secure Admin Workstation (SAW), für den Zugriff auf den Admin Tenant. Diese Maschine ist speziell gehärtet und verbietet nahezu alles, außer den Zugriff aufs Admin Portal des Partner SOC Admin Tenants.
- Eine CA Rule auf jedem Kundenteant, welcher nur den Zugriff der Konten aus dem „Partner SOC Admin Teanant“ zulässt. Darüber hinaus den Zugriff nur von der Azure PAW IP zulassen.
- Partner CSP Tenant
- Multi Factor Authentifizierung (MFA)
- PIM für alle Adminrollen im Azure AD Tenant
- In Bezug auf CSP/GDAP/Admin On Behalf Of (AOBO) ist es wichtig zu kontrollieren, wer das Recht zum Ändern von Gruppenmitgliedschaften hat, da sich diese Administrativen Rollen sonst selbst Berechtigungen geben könnten.
- Nested groups unter der Security Group “AdminAgents” und “HelpdeskAgents”. Diese beiden Gruppen können nicht direkt für PAG konfiguriert werden, die Zuweisung der Rollen können auch über Security Groups geregelt werden, die als Nested groups darunter hängen. Die Zuweisung von Agent-Rollen generell sollte dann nicht im Partner Center, sondern im Azure AD durchgeführt werden.
- Security Groups die für GDAP genutzt werden
- Die mindestens benötigten Rechte um Supporttickets für Kunden eröffnen zu können sind Service Support Admin (Für M365 & D365) und Directory Reader
Was sind die Lizenzvoraussetzungen?
- Partner Tenant
- Wir nehmen in diesem Beispiel an, dass jedem Benutzer im Partner Tenant eine M365 E5 zugewiesen ist.
- Partner SOC Admin Tenant
- Aus lizenzrechtlicher Sicht ist für den SOC Analyst keine Lizenz erforderlich, da die Person, welche hinter dem Account steht, bereits in einem anderen Tenant lizensiert ist. In unserem Fall im Partner Tenant mit der angesprochenen M365 E5.
- Es benötigt jedoch trotzdem eine technische Lizenz, da sonst PIM (Privileged Identity Management) nicht funktioniert. Für PIM ist es notwendig, dass jeder Benutzer, der PIM verwenden soll, eine AAD P2 Lizenz zugewiesen hat. Hierfür stellt Microsoft aktuell 25 AAD P2 Lizenzen kostenfrei für ein Jahr zur Verfügung.
- Partner CSP Tenant
- Aus Lizenzrechtlicher Sicht ist für die CSP Tenant Benutzer keine Lizenz erforderlich, da die Person, welche hinter dem Account steht, bereits in einem anderen Tenant lizensiert ist. In unserem Fall im Partner Tenant mit der angesprochenen M365 E5.
- Die wenigen administrativen Accounts benötigen jedoch trotzdem eine technische Lizenz, da sonst PIM (Privileged Identity Management) nicht funktioniert. Für PIM ist es notwendig, dass jeder Benutzer, der PIM verwenden soll eine AAD P2 Lizenz zugewiesen hat. Hierfür stellt Microsoft aktuell 25 AAD P2 Lizenzen kostenfrei für ein Jahr zur Verfügung.
Welche Services sollte ein SOC bedienen?
Gerade bei dem SOC ist es wichtig, eine gute Basis zu haben. Viele schreien immer „wir brauchen ein SIEM“, jedoch kann ein SIEM z.B. Microsoft Sentinel seine Stärke nur ausspielen, wenn genug Ereignisse (Events) geliefert werden. Daher sind die Blau aufgezeigten Lösungen (siehe Abbildung 8) die Basis für ein SOC. Diese können dann im zweiten Schritt nach Belieben durch weitere Lösungen (Gelb in der Grafik) ergänzt werden.
Dies ist in etwa wie beim Hausbau, es sollte erst das Fundament und der Keller stehen, bevor mit dem ersten Stock angefangen wird.
Was muss eingerichtet werden?
Die GDAP-Einrichtung ist in folgendem Artikel sehr gut beschrieben: Step-by-step guide: Transitioning to GDAP (Anmeldung im Partner Network erforderlich)
Ich werde dies im nächsten Artikel dediziert aufgreifen.
Wie wird Sentinel Connect & Azure Lighthouse angebunden?
Folgt ebenfalls im nächsten Artikel.
Quellen:
Partner journey map | Securing the channel: Journey to Zero Trust
Einführung in granulare delegierte Administratorrechte (GDAP) – Partner Center | Microsoft Learn
Step-by-step guide: Transitioning to GDAP (Anmeldung im Partner Network erforderlich)