Sicher unterwegs in Azure

Sind Sie schon drin?

Hat Ihre Firma einen Azure-Tenant?

Verfügen Sie selbst über einen Azure Active Directory Account?

In vielen Fällen lässt sich diese Frage mit ja beantworten – zum Beispiel, wenn Sie Office365 nutzen.

Auch wenn Sie wissentlich gar keine „klassischen Cloud-Ressourcen“ (Computing, Storage, …) aus Azure nutzen, verfügen Sie mitunter schon über einen Azure AD Account. Sie können das freilich ignorieren – dennoch existiert Ihr Tenant und läuft dann eben mit Default-Einstellungen – und den damit verbundenen Risiken.

Sicherheit in der Cloud

Wir möchten in diesem Artikel nicht über Zertifizierungen reden und auch nicht die langwierige Diskussion aufwerfen, ob denn verschlüsselte Daten in der Cloud sicher sind, wenn der Cloud-Anbieter die Schlüssel speichert. Oder ob es vertrauenswürdig ist, wenn der Anbieter die Kontrolle über das System besitzt, welches die Zugriffsberechtigungen auf sichere Speicherorte der Krypto-Schlüssel wie ein Hardware Security Module (HSM) steuert. Eine Diskussion, die sich zu jedem beliebigen Cloud-Dienst führen lässt. Sagen wir einfach, wir glauben an dieser Stelle mal ohne weitere Paranoia Microsoft und den vielen Zertifizierungen, die für Azure-Umgebungen mittlerweile gelten.

Aufgabenteilung

Mit Blick auf die Sicherheit lässt sich das Thema der Aufgabenteilung ganz platt so formulieren: Microsoft passt auf, dass keiner die „Kisten“ klaut und stellt Ihnen einen Strauß von Werkzeugen und Hilfsmitteln zur Verfügung, um alles Oberhalb vom „Blech“ im Rechenzentrum abzusichern. So sorgt Azure beispielsweise durch die „Storage Service Encryption“ (SSE) dafür, dass alle Daten auf der Festplatte „at Rest“ grundlegend mal verschlüsselt abliegen. Also selbst wenn jemand eine „Kiste“ klaut, sieht er erst mal nur verschlüsselten Datensalat. Im Detail gibt es hier natürlich etwas mehr Granularität.

Wer konkret welche sicherheitsrelevanten Aufgaben hat, hängt von der Art des Dienstes ab und unterscheidet sich zwischen Software-as-a-Service, Plattform-as-a-Service und Infrastructure-as-a-Service. Eine offizielle Darstellung von Microsoft beschreibt die allgemeinen Verantwortlichkeiten für diese Varianten der Cloud-Nutzung so:

Dabei stellt das Diagramm die grundlegenden Aufgaben dar – die Konfiguration der Verschlüsselung des Speichers auf Ebene von virtuellen Maschinen ist beispielsweise im IaaS-Konstrukt durch den Kunden zu verwalten, obgleich die Verantwortung für die Basis-Funktionalität „Speicher“ bei Microsoft liegt – nicht immer auf Anhieb ganz einfach.

Was Microsoft Ihnen nie abnimmt, ist die Verantwortung für die Vergabe von Rollen, Berechtigungen und Zugriffen, sowie den Umgang mit Ihren schützenswerten Daten – also beispielsweise ob Sie diese in Storage Accounts ablegen, die im Internet verfügbar sind oder nur für Sie zur Verfügung stehen.

Empfehlungen und Standards

Microsoft ist stets bemüht, die Sicherheit der Kundendaten in Azure in den Fokus zu rücken. Gemeinsam mit dem Center for Internet Security (CIS) hat Microsoft den „CIS Microsoft Azure Foundations Benchmark“ entwickelt. Dieser Benchmark – also eine Sammlung von Best-Practices-Empfehlungen – bildet auch die Grundlage für die Standard-Policy im Azure Security Center. Die jeweils aktuellste Version des Bechnmarks ist als PDF kostenfrei beim CIS zum Download verfügbar. Microsoft stellt die Version 1.0 des Benchmarks ebenfalls zur Verfügung. Das Azure Security Center zeigt (trotz einiger Einschränkungen in der kostenfreien Variante) jedem Azure Tenant einen aktuellen Score und eine Reihe von Empfehlungen, die auf dem CIS-Benchmark basieren.

Wenn Sie sich mit Azure beschäftigen, ist es eine gute Idee hier die ersten Aufwände zur Absicherung Ihrer Umgebung hinein zu investieren. Wie üblich bei der Härtung gilt auch für Azure, dass es Empfehlungen gibt, die dafür sorgen können, dass bestimmte Dinge nicht mehr funktionieren (z. B. Deaktivierung von Legacy-Anmeldeverfahren oder Umsetzung von MFA für alle Accounts). Genauso gibt es auch Empfehlungen, die vielleicht auf den ersten Blick gut scheinen, aber in anderen Themenbereichen Probleme mit sich bringen (z. B. die in Version 1.1. des CIS-Benchmark entfernte Empfehlung, den Azure VM Agent immer zu installieren). Ein bisschen Mitdenken und eine Ladung Trial-and-Error bleiben daher nicht erspart.

Der Benchmark des CIS sorgt für eine Basishärtung des Azure-Accounts (Azure AD, Azure Portal) und der verwendeten Azure-Ressourcen (Virtuelle Maschinen, Speicher, Datenbanken, …), die sich jeder Azure-Nutzer intensiv anschauen sollte. Darüber hinaus bringt Azure insbesondere bei Benutzer- und Zugriffskonzepten einige Herausforderungen mit sich.

Benutzer und Berechtigungen

Identity and Access Management (kurz: IAM) ist einer der wesentlichen Bausteine sicherer IT-Systeme. Das gilt nicht nur für die Cloud. Für die on-premises-Welt propagiert Microsoft seit Jahren das Active Directory administrative tier model – also die saubere Trennung und Abschottung privilegierter bzw. administrativer Accounts und Umgebungen. Während der Ransomware-Angriffe der letzten Jahre erlangte die Absicherung privilegierter Accounts im Windows-Umfeld neuen Aufwind, da selbst IT-nahe Betriebe wie der Heise-Verlag hier noch nicht optimal aufgestellt waren und eben jene Fehler machten, die Ransomware-Angriffe erleichtern. Die Konzepte der lokalen Unternehmenswelt lassen sich prinzipiell mit ein paar Anpassungen auf die Cloud übertragen. Sami Laiho – finnischer Windows-Security-Enthusiast – geht mit der These ins Rennen, dass 99 % der Angriffe durch Multi-Faktor-Authentifizierung verhindert werden können. Für das eine Prozent erfolgreicher Angriffe die übrig bleiben, muss die Umgebung entsprechend abgesichert sein. Heißt für Azure konkret:

Global Administrators des Tenants haben nichts auf Endgeräten zu suchen
Endgeräte-Admins haben keine Global Administrator Rechte zu besitzen
Global Administrators haben nichts als Owner oder Contributer von Subscriptions verloren

Warum es dennoch immer wieder zu solchen Konstrukten kommt ist einfach: Um sich nicht mit Berechtigungen rumschlagen zu müssen, ist es am einfachsten in Azure mit der Rolle Global Administrator zu arbeiten. Der darf alles, kann alles und wird nie abgelehnt. Der Global Administrator kann das Azure AD verwalten, kann jede Subscription (und damit alle Ressourcen im Azure-Tenant) übernehmen, verändern und löschen und kann jede E-Mail lesen, jeden E-Mail-Account umleiten und jede E-Mail-Regel verändern. Damit ist die Rolle Global Administrator etwas für Accounts, die eigentlich 364 Tage im Jahr sicher im Schrank verwahrt werden. Damit das funktioniert, braucht man natürlich entsprechende Alternativen – und muss die Azure Rollen- und Berechtigungen verstehen.

Das Azure AD stellt das zentrale IAM-Element von Azure dar. Jeder, der auf Ressourcen in Azure (oder Office365) zugreifen möchte, besitzt eine Azure AD Identität: Entweder nur im Azure AD oder als Sync zum lokalen AD oder als Gast-User. Dennoch sind Azure AD Rollen (z. B. Global Administrator, Device Administrators, …) grundsätzlich unabhängig von den Azure RBAC-Rollen für den Zugriff auf Ressourcen (Owner, Contributer, …). Letztere werden über ein rollenbasiertes Berechtigungsmodell „Role based access control“ (kurz: RBAC) gesteuert. Das nachfolgende Bild von Microsoft veranschaulicht dies.

Wir empfehlen – wie Microsoft auch – diese Trennung ernst zu nehmen. Das bedeutet im Zweifel, dass Mitarbeiter mit mehreren Accounts in Azure unterwegs sind. Betrachten wir die Risiken, die aus einer Kompromittierung eines Global Administrator Accounts entstehen, dann sollten diese so selten wie möglich irgendwo im Einsatz sein. Ob nun die RBAC-Rollen wie Owner oder Contributer auf Subscription oder Resource Group Ebene vergeben werden, hängt letztlich von den konkreten Anforderungen und Gegebenheiten ab. Wenn jede Abteilung eine eigene Subscription hat, dann spricht nichts dagegen, dass erstmal jeder (berechtigte) Mitarbeiter der Abteilung auch auf dieser Ebene seine Berechtigungen bekommt. Gibt es eine zentral verwaltete Subscription für mehrere Abteilungen, dann sollten die einzelnen Abteilungen höchsten auf Ebene der Resource Group ihre Berechtigungen erhalten. Das kann am Ende kompliziert werden und muss natürlich noch irgendwie zusammen gehalten und überwacht werden.

Auditierung und Monitoring – die ersten Schritte

Azure ist für viele Firmen und Administratoren immer noch ein Stückchen Neuland. Es verändert Prozesse und wirft klassische Verantwortlichkeiten durcheinander.

Groß ist die Angst, dass plötzlich Firmendaten im Internet auftauchen – ein Problem, was bei falscher Berechtigungsvergabe oder ungeschickter Konfiguration binnen Sekunden mit wenigen Mausklicks Wirklichkeit werden kann. Auf der anderen Seite bietet Azure von Hause aus aber auch die Möglichkeit, über ein Netz von Alarmierungen, Logging und Monitoring eine Vielzahl sicherheitskritischer Ereignisse im Blick zu haben (Manchmal sogar besser, als in einigen on-premises Umgebungen). Was hier nicht erfasst wird, lässt sich per CLI oder PowerShell zügig selbst zusammen bauen. Doch wonach dort suchen? Und was damit machen?

PowerShell-Module: aZ und AzureAD

Die Verwaltung von Azure-Ressourcen lässt sich im Unternehmen automatisieren. Hierzu können beispielsweise die beiden PowerShell-Module aZ und AzureAD verwendet werden. Nun ist die Automatisierung von Verwaltungsaufgaben sicherlich hilfreich – aber oft erst ein zweiter oder dritter Schritt. Aus Sicht der IT-Sicherheit können wir aber die gleichen Methoden verwenden, um uns schnell und einfach einen Überblick über die aktuelle Lage im Tenant zu verschaffen. Dabei wollen wir nicht das Security Center oder den Azure Monitor nachbauen, sondern die von Azure zur Verfügung gestellten Mittel ergänzen.

In Audits geht es uns meist um die Beantwortung einfacher Fragen – und das Festhalten eines „Ist-Zustands“, also quasi die Anfertigung eines Snapshots der relevanten Azure AD- und Azure-Konfiguration. Eine Basisversion unseres PowerShell-Scripts hierfür haben wir in unserem git Repository abgelegt. Das Script setzt beide PowerShell-Module voraus und fragt die notwendigen Credentials für den Zugriff beim Aufruf ab (funktioniert somit auch mit MFA-geschützten Accounts). Dieses Script legt die Informationen einfach ohne weitere Bewertung als Text ab – natürlich sind auch schönere Ausgabeformate oder die Übernahme in eine Datenbank, sowie direkte Auswertungen denkbar.

Unser Ziel hierbei ist es, die Dinge darzustellen, die wir sonst über verschiedene Orte der Azure-GUI mühsam zusammen suchen müssten, also beispielsweise:

Welche Subscriptions (also „Abrechnungsbereiche“) gibt es im Tenant?
Welche Azure AD-Gruppen (Sicherheitsgruppen, Office365-Gruppen) sind vorhanden?
Welche Benutzerkonten sind im Azure AD vorhanden?
Welche Benutzer haben welche Gruppenmitgliedschaften?
Welche Gruppen haben welche Benutzer als Mitglieder?
Welche Rollen (z. B. Global Administrator, Global Reader) im Azure AD gibt es?
Welche Benutzer sind Mitglieder welcher Rollen?
Welche Ressourcengruppen gibt es in der Subscription?
Welche Ressourcengruppen haben öffentliche IP-Adressen?
Welche Storage-Container sind öffentlich zugreifbar?

Die richtigen Berechtigungen (z. B. Global Reader) vorausgesetzt, liefert die Sammlung von PowerShell-Befehlen die Antworten auf diese Fragen. Hier sind natürlich noch viele weitere Themen denkbar, etwa die Auswertung von Network Security Groups. Das azucar-Projekt ist ein umfangreicheres Auswertungstool für Azure und bietet eine recht umfassende Sammlung an Scriptlets zur Bewertung der Azure-Sicherheit. Unser Script soll lediglich als Idee dienen – und in Kürze sichtbar machen, ob wir typische Sicherheitsprobleme, etwa öffentlich zugängliche Storages oder eine übermäßige Anzahl von Global Administrators haben.

Mit diesen Daten haben wir einen Ist-Stand. Von hier an können wir relativ einfach überwachen, ob beispielsweise eine neue öffentliche IP-Adresse zugefügt – oder eine Gruppenmitgliedschaft verändert wird. Dabei behilflich sind dann wieder Azure Bordmittel.

Azure Monitor und Alerts

Wenn wir ein mal einen definierten Zustand erreicht haben, dann sollen nach Möglichkeit keine unbemerkten Veränderungen daran stattfinden. In den meisten Organisationen wird die Berechtigungsvergabe nicht so fein-granular sein, dass unerwünschte Veränderungen allein durch die Berechtigungsvergabe ausgeschlossen werden können. Als Plan B sollten wir zumindest „kritische“ Operationen feststellen – am besten schnell und vor dem nächsten regulären Audit. Hierbei hilft uns die Definition von Alerts. Analog zu den zuvor aufgeworfenen Fragestellungen, können wir hier festlegen, über welche Veränderungen an den Azure Ressourcen eine Benachrichtigung (z. B. per E-Mail) ausgelöst werden soll – beispielsweise, wenn eine neue öffentliche IP-Adresse zu einer Resource Group hinzugefügt wird.

Welche Alarme genau definiert werden sollten, hängt stark von der Organisation, der Struktur der Berechtigungen (Subscription <> Resource Group) und dem gewünschten Freiheitsgrad der Azure-Administratoren bzw. Azure-Nutzer ab. Neben dem Zufügen einer öffentlichen IP-Adresse, könnten beispielsweise auch Veränderungen an den Network Security Groups einen Alarm auslösen, wie es auch vom CIS Benchmark empfohlen wird. Ein solcher Alarm ist beispielhaft im folgenden Screenshot dargestellt:

Azure Policy

Für bestimmte Events ist eine direkte Alarmierung durchaus sinnvoll. Die Organisation kann natürlich noch weitere Vorgaben entwickeln, die bei der Erstellung oder Änderung von Ressourcen berücksichtigt werden sollen – ohne jedes Mal einen Alarm auszulösen. Hier kommen die Azure Policies ins Spiel. Azure Policies haben wir grundsätzlich schon besprochen, da sie die Grundlage für die Empfehlungen im Security Center sind. Darüber hinaus lassen sich beliebige eigene Regeln bauen. Möchten Sie beispielsweise nur Ressourcen in bestimmten Regionen (Deutschland, Europa, …) erlauben, dann lässt sich dies über eine Policy steuern. Im folgenden Demo-Beispiel sind zwei Varianten einer solchen Richtlinie (Initiative) vereint:

Die „Allowed locations – Audit-only“ Policy ist eine Kopie der „Allowed locations“ Policy: Nur dass hier die Erzeugung nicht verboten sondern nur auditiert wird. Im vorliegenden Beispiel bekommen wir also Alarme, wann immer eine Ressource außerhalb von Deutschland deployed wird und verhindern ein Deployment außerhalb der EU-Region.

Auch hier bietet Microsoft Hilfsmittel und Werkzeuge an. Die konkrete Implementierung liegt beim Kunden. Über die Policies lassen sich aber viele Bedenken oder Fragestellungen als auditierbare Anforderung umsetzen.

Sicher geht schon – nicht so kompliziert, aber auch nicht ganz ohne Ihr Zutun

Wenn man dem generellen Konzept der Cloud ein Stück weit vertraut, dann kann man mit Azure – wie mit den übrigen Plattformen auch – mit ein paar Handgriffen eine sichere und gut überwachte Umgebung für das Unternehmen schaffen. Somit sind etwa Zugriffe auf Unternehmensressourcen (MFA, Application Gateways, … ), Office-Anwendungen, E-Mail, Unified Communication und zusätzliche Rechenpower oder Speicherplatz bei Bedarf aus Sicht der IT-Sicherheit in der Regel mit akzeptablem Rest-Risiko möglich. Man muss sich aber mit dem Thema aktiv auseinandersetzen und hat zumindest mal die vier Basisaufgaben:

Empfehlungen des Security Centers bewerten und umsetzen
Benutzer und Berechtigungen sauber gestalten
Network Security Groups prüfen und insbesondere any-any-Zugriffe auf administrative Protokolle vermeiden
Multi-Faktor-Authentifizierung (mindestens für privilegierte Accounts) erzwingen

Je enger Sie die Daumenschrauben im Punkto IT-Sicherheit anziehen möchten, desto mehr Expertise ist notwendig, um alle Schritte nach bestem Wissen durchzuführen. Microsoft hat ein sehr umfangreiches Portfolio an Online-Ressourcen, inklusive der Azure-Learn-Plattform. Hier kann jeder für sich in seinem Tempo die wichtigsten Grundlagen zu Azure erlernen – das benötigt so seine Zeit, lohnt sich aber.

Natürlich helfen auch wir gerne bei Fragen, Konzepten, Reviews oder anderen Themen weiter.

blog