Burggraben für die Cloud

von Klaus Bierschenk

Die Azure-Infrastruktur bietet ein vielfältiges wie flexibles Cloudsetup und Änderungen sind im Handumdrehen durchgeführt. Doch wie lässt sich gewährleisten, dass die Sicherheit dabei nicht auf der Strecke bleibt? Die Antwort darauf lautet Azure Security Center. Wir stellen dieses wichtige Werkzeug für eine Gesamtsicht auf die Infrastruktursicherheit vor.

Auf den ersten Blick kann für den Administrator die Auswahl des passenden Sicherheitsportals verwirrend sein, denn der Begriff Sicherheitscenter kommt in der Microsoft-Terminologie vielfältig vor. Es beginnt beim M365-Security-Center, geht weiter mit dem Microsoft-Defender-Security-Center bis hin zum Azure-Defender-Portal – und die Liste ist noch länger. Einen Überblick über die verschiedenen Portale bietet der Artikel unter [1] über Microsoft-Cloudportale. Er listet die wichtigsten Portale auf und bietet eine kurze Beschreibung dazu. Wir beschäftigen uns in diesem Beitrag mit dem Azure Security Center (ASC) oder, wie es auch genannt wird, dem Azure-Defender-Portal.

Leichter Einstieg

Administratoren, die einen Teil ihrer Infrastruktur in Azure betreiben, müssen diese vor Angriffen schützen. Genau so geht es aber darum, in täglichen Arbeitsabläufen dafür zu sorgen, dass die Sicherheitseinstellungen richtig dosiert sind. Zu strenge Regularien erschweren Abläufe und ermüden die Anwender. Ist das Setup zu lax, stellt es ein Sicherheitsrisiko dar. Damit Sie den richtigen Mittelweg finden, hilft Ihnen das Azure Security Center. Es bietet durch Richtliniendefinitionen die Möglichkeit, Schwachstellen zu identifizieren und Lücken, wenn möglich, direkt zu schließen. Zusätzlich stehen Branchenstandards zur Verfügung, um das eigene Setup damit zu vergleichen und Unterschiede auszumachen.

Sie müssen das Azure Security Center nicht erwerben, auch eine Aktivierung ist nicht nötig. Sie finden es im Azure-Portal im Ressourcen-Menü als eigenen Punkt. Die Portalseite gibt die Sicherheitslage von Computern, Applikationen, Daten, Netzwerk und von Identitäten kategorisiert wieder. Hier sehen Sie auf einen Blick, was Sache ist. Lediglich beim Wirkungsgrad des Azure Security Centers gibt es Unterschiede zwischen der kostenlosen und der kostenpflichtigen Variante. Im Portal ist dies mit "Defender Plan" betitelt, der entsprechend ein- oder auszuschalten ist. Ob Sie die Funktionen von Defender nutzen oder nicht, entscheiden Sie auf Ebene der Abonnements, dies ist die Einheit für die Kostenabrechnung.

Unter dem Punkt "Verwaltung / Preise und Einstellungen" können Sie den Defender-Plan ein- oder ausschalten. In früheren Versionen des Security-Centers war hier auch von einem "Standard Plan" die Rede. Dieser Begriff taucht auch heute noch in der einen oder anderen Dokumentation auf. Mittlerweile heißt dieser Defender und Sie sehen hier, welche Funktionen zur Verfügung stehen. Hier ist auch schnell ersichtlich, dass das Security-Center nur mit dem Defender-Plan wirklich Sinn ergibt.

Werkzeuge wie "JIT-VM-Zugriff" (Just-In-Time-Zugriff) oder auch die "Berichte zur Einhaltung gesetzlicher Bestimmungen" sind wichtige Funktionalitäten im Cloudkontext, die eigentlich kaum ein Administrator missen möchte. Für ein Feintuning mit Blick auf die Kosten lassen sich aber auch Ressourcen im Wirkungskreis von Defender ein- und ausschließen, was das Ganze preislich entzerrt. So lässt sich Defender zum Beispiel in Bezug auf virtuelle Maschinen verwenden, bei SQL-Datenbanken jedoch ließe sich, wenn gewünscht, darauf verzichten.

Tägliche Routine im Portal

Im Mittelpunkt des Security-Centers steht die Übersichtsseite. Hier visualisieren und bewerten Sie den Sicherheitsstatus Ihrer IT-Ressourcen. Die dargestellten Informationen umfassen zunächst einmal den "Bestand". Dabei erhalten Sie eine Liste mit allen Ressourcen und es ist ersichtlich, für welche Bereiche eine Überwachung und Auswertung stattfinden sowie ob der Defender-Plan zur Anwendung kommt. Diese Darstellung geht von der Ressource aus und da je nach Ressource mehrere Aspekte bewertet werden, zeigt ein farblicher Indikator in der Spalte "Empfehlung", wie es um das jeweilige Objekt bestellt ist.

Wählen Sie mit einem Mausklick ein Element aus der Liste aus, erhalten Sie weitere Details über den genauen Zustand des Objekts. Wo es möglich ist, lassen sich direkt notwendige Konfigurationen initiieren. Ist dies nicht der Fall, wartet zumindest eine Anleitung mit Arbeitsschritten auf Sie, wie das Defizit am besten zu beheben ist.

Sicherheitsmesslatte: Secure Score

Ganz ähnlich wie beim "Bestand" gibt die Sicherheitsbewertung (Secure Score) Auskunft über die Sicherheitslage in der Infrastruktur. Die Darstellungsweise ähnelt der Anzeige des Bestands. Orientiert sich dieser jedoch an den Ressourcen, geht die Betrachtung der Sicherheitsbewertung von den Sicherheitsfeatures aus. Dabei wird der Zustand ganzer Funktionalitäten bewertet: Wie ist der Stand der Verteilung von Multifaktor-Authentifizierung? Wie sieht es bei allen virtuellen Computern mit der Verschlüsselung der Datenträger aus? Antworten darauf erhalten Sie nach einem Punktesystem, das je nach Gewichtung höher oder geringer ausfällt. Am Ende steht der Secure Score als prozentuale Bewertung der Sicherheitslage – je höher der Wert, umso besser.

Hierbei handelt es sich um Empfehlungen von Microsoft, die nicht alle zwingend umzusetzen sind. Vielmehr gilt es, ein Gefühl für die Sicherheitseinstellungen zu bekommen und relevante Lücken zu identifizieren. Sowohl der "Bestand" als auch die "Sicherheitsbewertung" sind gute Hilfen hierbei – besonders weil sich in den meisten Fällen mit wenigen Klicks Maßnahmen direkt umsetzen lassen. Der Secure Score wird dabei laufend bewertet und die Erkenntnisse aktualisiert.

Eventuell haben sich neue Lücken aufgetan durch neue Konfigurationen oder Sie haben direkt aus dem Dashboard heraus ein "Fix" als Maßnahme gestartet. Die Ansicht gibt sich ein klein wenig träge und bis hier getroffene Maßnahmen berücksichtigt sind, kann es etwas dauern. Als Messlatte für die Sicherheit erledigt der "Secure Score" aber genau das, was er soll.

In komplexen Umgebungen lässt sich die Ansicht mittels ausgeklügelter Filtermöglichkeiten wunschgemäß anpassen. Wem das nicht reicht, der exportiert die Daten in eine CSV-Datei und erledigt die restliche Datenkosmetik in Excel. Übrigens gibt es auch einen "Identity Secure Score" im Azure-AD-Dashboard. Dieser ist mehr statischer Natur und, wie der Name vermuten lässt, auf Identitäten bezogen, aber nichtsdestotrotz ebenfalls einen Blick wert.

Des Weiteren stellt das Security Center mit einem Satz von Branchen- und Regulierungsstandards Konformitätsrichtlinien bereit, die bei der Bewertung der eigenen Azure-Landschaft hilfreich sein können. Sie finden diese Standards bei der Sicherheitsrichtlinie für ein Abonnement und hier sind beispielsweise vorgefertigte NIST- oder ISO-27001-Richtlinien vorhanden. Aber Vorsicht: Microsoft weist darauf hin, dass eine vollständige Konformität gemäß dem jeweiligen Standard nicht sichergestellt werden kann. Die Richtlinien liefern aber sehr wohl Werte und Kriterien und somit erhalten Sie eine grundlegende Einschätzung bezüglich der eigenen Compliance.

Richtlinien im Mittelpunkt

Eine zentrale Komponente im ASC sind die Sicherheitsrichtlinien. Sie finden diese im Security Center links unterhalb der Verwaltung mit der Option "Sicherheitsrichtlinie". Übrigens gibt es auch eine sogenannte Portalseite in Azure namens "Richtlinie", die sich als gleichnamiger Dienst administrieren lässt. Hier getroffene Einstellungen finden sich genauso im ASC wieder, da es dieselben Richtlinien sind. Das ist auf den ersten Blick nicht ganz schlüssig und wirkt doppelt, jedoch bietet das Azure Security Center allein in Bezug auf Defender und die zusätzlichen Funktionen wie den vielfältigen Export deutlich mehr Gestaltungsraum.

Drei Begriffe tauchen bei der Arbeit im ASC immer wieder auf: Richtliniendefinition, Initiative und Zuordnung. Neben der Standardrichtlinie können Sie beliebig Initiativen erstellen, die im Grunde genommen nichts anderes sind als eine Sammlung zusätzlicher Richtliniendefinitionen. Zuweisungen erklären sich von selbst und finden sich auf Ebene von Verwaltungsgruppen, Abonnements und Ressourcengruppen. Wobei eine Verwaltungsgruppe eine Sammlung von Abonnements darstellt.

Verwaltungsgruppen lassen sich schachteln und in der dabei entstehenden Hierarchie werden die dort zugewiesenen Richtlinien nach unten vererbt. Ähnlich der Zuweisung von Gruppenrichtlinien im Active Directory zu Organisationseinheiten besteht hier auch die Möglichkeit, die Vererbung durch ein Blockieren außer Kraft zu setzen. Das schafft vielfältige Möglichkeiten, um Richtlinien zu verteilen, erfordert aber auch eine gute Planung im Vorfeld und klare Strukturen.

Initiativen in Aktion

Benutzerdefinierte Initiativen finden Sie im Azure Security Center bei den Sicherheitsrichtlinien im unteren Bereich des Portalfensters. Fügen Sie an dieser Stelle eine benutzerdefinierte Initiative hinzu, lassen sich in diesem Arbeitsschritt sowohl Initiativen erstellen als auch direkt zuweisen sowie etwaige Ausschlüsse in der Vererbung einrichten, vorausgesetzt für die Initiative ist die Richtlinienerzwingung nicht aktiv.

Es ergibt Sinn, sich mit den Richtlinien und den damit verbundenen Einstellungs- und Überwachungsmöglichkeiten vertraut zu machen. Die Themen und Aspekte sind vielschichtig. Da kommen übrigens die brandneuen "Security Center Labs" [2] gerade recht. Diese bieten einen guten Einstieg in die Möglichkeiten des ASC. Sie sind nicht nur für Anfänger (Level 100) empfohlen, sondern bieten auch für Experten (Level 300) Lerninhalte, die aus Dokumenten, Videos und Übungen bestehen.

Remote-Zugriff auf VMs einschränken

Es gibt verschiedene Möglichkeiten, um auf Server in Azure zuzugreifen und die virtuellen Computer zu administrieren. Die PowerShell ist eine davon. Es gibt aber Administratoren, die bevorzugen es, sich direkt per RDP am Server einzuloggen. Abgesehen davon geht es manchmal nicht anders und die Server-GUI wird für eine bestimmte Konfiguration benötigt. In diesem Szenario stellt sich die Frage, wie sich der RDP-Zugriff sicher gestalten lässt. Am einfachsten wäre es, wenn das Netzwerk in Azure Teil der übrigen Netzwerkinfrastruktur ist und quasi eine geroutete Verbindung über ein VPN besteht.

Dies ist zum Beispiel in Umgebungen der Fall, in denen der Domänencontroller in Azure-VMs läuft [3]. Die virtuellen Computer besitzen hierbei alle eine private IP-Adresse und es besteht eine ähnliche Sicherheit, als wenn der Zugriff per RDP ins eigene Rechenzentrum erfolge. Es ist also kein Problem, wenn hier Ports geöffnet werden. Aber was tun, wenn dies nicht der Fall ist? Eine Lösung ist es, die Ports zum Zugriff über das Internet zu öffnen. Das geht technisch, ist aber bezogen auf die Sicherheit etwas, was kein Administrator wirklich haben möchte.

Es gibt eine Vielzahl an Möglichkeiten, den Remote-Desktop-Netzwerkverkehr abzusichern, auch mit Tools von Drittherstellern. Ein sehr einfacher Ansatz ist aber im Azure Security Center enthalten und dieser heißt "JIT-VM-Zugriff" (JIT). Die Funktion ist Teil des Defender-Plans, also kostenpflichtig. In der Funktionsweise kommen hier Netzwerksicherheitsgruppen (NSG) zum Einsatz. Die für den Zugriff notwendigen Ports werden nur auf Anforderung geöffnet, indem das Security-Center eine temporäre NSG zuweist. Sie gestattet den Zugriff und wird nach einem definierten Zeitraum wieder entfernt.

JIT in der Praxis

Nehmen wir als Beispiel an, Sie haben in Azure einen virtuellen Computer namens "LabVM-2" in Betrieb und möchten vermeiden, dass permanent die Ports 3389 (RDP) und 22 (SSH) geöffnet sind. Um dafür den Zugriff via JIT zu steuern, navigieren Sie im Azure Security Center in den Bereich "Azure Defender". Im Defender-Dashboard wählen Sie den Punkt "JIT-VM-Zugriff". Der nächste Bildschirm ist selbsterklärend und neben einleitenden Informationen erhalten Sie hier eine Liste der virtuellen Computer angezeigt. Navigieren Sie zum Tab "Nicht konfiguriert" und wählen Sie den oder die gewünschten virtuellen Computer aus, in unserem Beispiel "LabVM-2".

Auf einer weiteren Konfigurationsseite können Sie jetzt noch die gewünschten Ports angeben. Die wichtigsten "Remote Management Ports" sind hier bereits vordefiniert. Abschließend hinterlegen Sie, wie lange der Zugriff gestattet sein soll. Im Hintergrund erstellt ASC für die ausgewählten VMs eine NSG, die den Zugriff der jeweiligen Ports verbietet, und zwar mit der höchsten Priorisierung. Aufgrund der hohen Priorität ist es für bereits vorhandene Regeln unerheblich, ob diese einen der Ports geöffnet haben – jetzt ist er geschlossen.

Als Administrator können Sie nun den Zugriff anfordern, indem Sie im ASC in den Bereich "JIT" navigieren, wie eben beschrieben, und dort für die entsprechende VM den Punkt "Zugriff anfordern" wählen. Genauso können Sie in den Eigenschaften der VM unter "Einstellungen" den Befehl "Verbinden" nutzen. Hier erscheint nun ein Hinweis, dass der Zugriff erst angefordert werden muss, was Sie an Ort und Stelle auslösen können.

Das Ergebnis ist jeweils das Gleiche: Ist der Zugriff angefragt, wird eine zusätzliche NSG mit den Portregeln erstellt, die den Zugriff ermöglichen, und zwar in unserem Beispiel mit genau der Quell-IP-Adresse der Admin-Workstation, von der die Anfrage kam. Die NSG bleibt für den angegebenen Zeitraum zugeordnet und hat die höchste Priorität, setzt somit die zuvor erstellte NSG erst einmal außer Kraft. Ist der Zugriff wieder beendet, wird sie gelöscht und übrig bleibt dann wieder die NSG, die den Zugriff zu dem Port blockiert.

Auf einen Aspekt sei hier noch hingewiesen, und zwar befindet sich in der Liste mit den für JIT konfigurierten VMs rechts das Dreipunkte-Menü. Hier haben Sie die Möglichkeit, nachträglich Änderungen an den Ports vorzunehmen. Genauso findet sich hier, leider etwas versteckt, ein Aktivitätsprotokoll mit Hinweisen darüber, wer zu welchem Zeitpunkt den Zugriff für eine VM angefordert hat.

Lokale Server überwachen

In der Liste der überwachten Ressourcen wird die Vielzahl der überwachten Ressourcetypen ersichtlich. Virtuelle Computer aus Azure sind automatisch und ohne weitere Maßnahmen im Security-Center integriert. Möchten Sie aber auch Server aus dem lokalen Rechenzentrum in ASC berücksichtigen, zum Beispiel im "Secure Score", ist dies auch möglich und geht am schnellsten über Azure Arc und den Log-Analytics-Client. Was im Detail notwendig ist und welche Installationsvarianten es für die Integration noch gibt, finden Sie mit der Suche nach entsprechenden Schlagwörtern im Microsoft-Dokumentationsfundus zum Azure Security Center [4].

Aus Sicht von Microsoft bedeutet derweil eine hybride Infrastruktur nicht nur, die lokale Umgebung mit einem Cloudsetup zu betreiben, sondern es gehören Amazon Web Services (AWS) und die Google Cloud Plattform (GCP) ebenfalls dazu. Dieser Multicloud-Ansatz findet sich auch im Security-Center wieder und der Wirkungskreis lässt sich in Richtung dieser beiden Anbieter erweitern. Ein Vorteil, wenn Sie Ihre Infrastruktur nicht nur Microsoft anvertrauen, aber das Azure Security Center primär nutzen möchten.

Die notwendigen Arbeitsschritte finden Sie unter [5]. Sind die Connectoren erst einmal im Azure Security Center eingerichtet, lassen sich die meisten Betriebssysteme in das ASC integrieren. Neben Windows wird Ubuntu dabei automatisch unterstützt. Bei anderen Linux-Derivaten ist eventuell ein manuelles Eingreifen erforderlich. Für eine Integration der beiden genannten Cloud-anbieter benötigen Sie jeweils den Plan "Windows Defender für Server".

Vielseitige Automatisierung

Das Azure Security Center ist ein Werkzeug, das ein interaktives Arbeiten erfordert: ermitteln, analysieren und beheben. So richtig viel Platz ist da nicht für Automatismen. Trotzdem ist es möglich, ASC für einige Verwaltungsaufgaben im Hintergrund zu verwenden. Da wäre zum Beispiel der obligatorische E-Mail-Versand, der Sie über Warnungen informiert.

Alle Einstellungen hierzu bearbeiten Sie im Bereich "Preise und Einstellungen" und diese beziehen sich auf ein Abonnement. Das gilt auch für den nachfolgend beschriebenen "Fortlaufenden Export" und die "Workflows". Diese erfordern zwar insgesamt mehrmalige Einstellungen, ermöglichen aber einen hohen Grad an Flexibilität. Gerade beim Mailversand lässt sich unterscheiden, wer Nachrichten für verschiedene Abos erhalten soll – zum Beispiel "Besitzer" oder ausschließlich Benutzer in der Rolle "AccountAdmin". Neben einer Liste an E-Mail-Adressen hinterlegen Sie hier noch, bei welchem Schweregrad Nachrichten herausgehen.

Mit dem "Fortlaufenden Export" haben Sie die Möglichkeit, lückenlos ASC-Ergebnisse wie etwa den "Secure Score" zur weiteren Analyse bereitzustellen. Sie haben beispielsweise einen Log-Analytics-Arbeitsbereich und Warnungsregeln, die mittels Log-Analytics-Abfrage (KQL) Reaktionen auslösen? Dann sollten Sie in Betracht ziehen, den "Fortlaufenden Export" für einen Log-Analytics-Arbeitsbereich zu aktivieren.

Somit lassen sich die Daten von ASC dort gleichfalls auswerten und finden Berücksichtigung bei Warnungen. Übrigens beziehen sich die dabei entstehenden Kosten nur auf den Arbeitsbereich und fallen nicht für das Security-Center an. Somit ist dieser Punkt auch für Administratoren ohne Defender eventuell von Interesse. Der "Fortlaufende Export" kann neben Log-Analytics auch Event Hubs als Zieldefinition aufweisen.

Ein weiteres leistungsfähiges Tor zur Außenwelt ist die Workflow-Automatisierung. Der limitierende Faktor hier ist einzig die Phantasie des Administrators. Per Workflow-Automatisierung lassen sich sogenannte Logik-Apps auslösen, wenn bestimmte Trigger auftreten. Diese "Auslöser" beziehen sich auf Datentypen in ASC, Schweregrade oder sogar Zeichenketten, die in einer Warnung enthalten sind. Es lassen sich mehrere automatisierte Workflows gleichzeitig hinterlegen und das Ganze parallel, beispielsweise zum "Fortlaufenden Export". Im Grunde genommen spielt es keine Rolle, welches etablierte SIEM- oder ITSM-System Sie einsetzen – Sie können davon ausgehen, dass sich die Informationen aus dem Security Center dort integrieren lassen [6].

Fazit

Zugriffe in die Azure-Infrastruktur erfolgen über das Internet, zumeist ohne VPN und direkt aus einem Browser heraus. Welcher Admin weiß schon in allen Fällen, ob und was in welcher Form immer verschlüsselt ist? Da ist es gut, eine Umgebung zu nutzen, die den Sicherheitseinstellungen auf den Zahn fühlt – wie das Security-Center. Es spannt sich quasi wie ein Regenschirm über die Infrastruktur und wirft unter Zuhilfenahme von Microsoft vordefinierter oder individueller Richtlinien ein Auge auf Ihr Azure-Setup. Missstände lassen sich dadurch ermitteln und gegebenenfalls direkt beheben.