Sicherheitslücken durch Konfigurationsfehler in Azure 8 gefährliche Fehl­kon­fi­gu­ra­tio­nen in Azure

In Azure gibt es verschiedene Einstellungen, durch die gravierende Sicherheitslücken entstehen können. Wir zeigen acht gefährliche Optionen, mit denen Admins sehr sorgfältig umgehen sollten und erklären, wie Microsoft Defender für Cloud hilft, Sicherheitslücken zu vermeiden.

Microsoft Azure bietet für die verschiedenen Ressourcen zahlreiche Optionen, mit denen sich die Umgebung umfassend anpassen lässt. Wer hier falsche Entscheidungen trifft, öffnet gravierende Sicherheitslücken, gegen die Sicherheitstools in den meisten Fällen nicht helfen, da diese die Option als manuell gesetzt akzeptieren. Wir zeigen nachfolgend acht gravierende Lücken, die Admins verhindern können.

Fehler 1: Externe Benutzerkonten in Azure AD anlegen und nicht mehr entfernen

Mit der Einladung von externen Benutzern ist es möglich, Zugang zu Ressourcen zu schaffen, die im Azure-Abonnement zur Verfügung stehen. Allerdings sollten diese Konten mit bedacht angelegt werden, denn diese können auch im Fokus von Hackern und Malware stehen und es ermöglichen, die Ressourcen in einem Abonnement anzugreifen. Gastkonten und auch externe Konten sollten in jedem Fall nach der Verwendung wieder entfernt werden. Im Abonnement sollten nur die maximal notwendigen externen Konten und Gastkonten vorhanden sein. Die Verwaltung erfolgt in der Verwaltung von Azure AD bei „Benutzer“. Microsoft zeigt die Vorgehensweise auf einer eigenen Hilfeseite zu dem Thema.

Bildergalerie

Bildergalerie mit 8 Bildern

Fehler 2: Benutzerdefinierte Rollen geben Benutzern mehr Rechte als sie brauchen

In den Einstellungen von Abonnements stehen in Microsoft Azure auch Funktionen zur Verfügung, mit denen sich Rechte für Ressourcen und zur Verwaltung des ganzen Abonnements verteilen lassen. Die kritischen Einstellungen dazu sind bei „Zugriffssteuerung (IAM)“ zu finden. Hier lassen sich alle vorhandenen Rollen anzeigen und neue Rollen erstellen. Bei falscher Zuordnung erhalten Anwender Zugriff auf Einstellungen, die sehr kritisch für die Umgebung sind. Microsoft geht auf der Seite „Erstellen oder Aktualisieren von benutzerdefinierten Azure-Rollen über das Azure-Portal“ auf das Thema ein. Generell sollte es möglichst vermieden werden, hier neue Rollen zu erstellen. Nur bei absoluten Ausnahmen macht das Sinn.

Fehler 3: Öffentliche Ports für Azure-VMs öffnen

Bei der Erstellung von Azure-VMs ist es möglich, Zugriff aus dem Internet direkt auf den jeweiligen Server zu nehmen. Dadurch kann der Server direkt von Hackern und Malware angegriffen werden. Öffentliche Ports sollten nur in Ausnahmefällen für Azure-VMs aktiviert werden und auch nur dann, wenn der Zugriff zusätzlich abgesichert ist. Hier sollte parallel Microsoft Defender for Cloud zum Einsatz kommen und zusätzliche Sicherheitseinstellungen bezüglich der Firewall gesetzt werden. Microsoft empfiehlt beim Öffnen von öffentlichen Ports ebenfalls Regeln, um den externen Zugriff auf eine bestimmten IP-Bereich einzuschränken.

Fehler 4: DenyAllIinBound und DenyAllOutBound bei Netzwerksicherheitsgruppen löschen oder falsch konfigurieren

Netzwerksicherheitsgruppen (Network Security Groups, NSG) sind eine wichtige Basis für die Zugriffssteuerung auf Instanzen von Containern, VMs und anderen Ressourcen. Der komplette Netzwerkverkehr der zugewiesenen Ressourcen läuft über die Netzwerksicherheitsgruppen. Beim Anlegen sollte sichergestellt sein, dass die beiden Gruppen „DenyAllinBound“ und „DenyAllOutBound“ aktiv sind und damit der komplette Zugriff blockiert wird, für den es keine Zulassungsregeln gibt. Oft werden diese Regeln gelöscht oder nicht aktiviert.

Wichtig ist an dieser Stelle, dass nicht versehentlich die Einstellungen bei Port, Protokoll, Quelle und Zieladresse von „Alle“ auf einen anderen Wer geändert werden. Bei „Aktion“ muss an dieser Stelle „Deny“ stehen. Ist hier „Allow“ zu sehen, blockieren die NSG keinerlei Zugriffe mehr. Es kann bei der Verwaltung der Regeln über „Eingangssicherheitsregeln“ und „Ausgangssicherheitsregeln“ sinnvoll sein, nach der Überprüfung der Standardregeln diese mit „Standardregeln ausblenden“ aus der Ansicht auszublenden, damit nicht versehentliche die Regeln gelöscht oder geändert werden.

Fehler 5: Azure Kubernetes Services und andere Dienste nicht mit RBAC konfigurieren

In Azure haben viele Dienste ein eigenes Rechtemodell, das auf Azure AD basiert, sich aber getrennt von anderen Diensten im Abonnement konfigurieren lassen. Auch bei Azure Kubernetes Services (AKS) lässt sich das RBAC-Modell bei „Zugriff“ konfigurieren. Generell ist es hier meistens sinnvoll, die Optionen „Azure AD-Authentifizierung mit Azure RBAC“ oder „Azure AD-Authentifizierung mit Kubernetes RBAC“ zu verwenden. Es ist meistens nicht sinnvoll, auf „Lokale Konten mit Kubernetes RBAC“ zu setzen, da hier nicht Azure AD zum Einsatz kommt und die Rechteverwaltung nur in Kubernetes abläuft.

Fehler 6: Die falsche Version von Kubernetes in Azure Kubernetes Services einsetzen

Dazu kommt noch die richtige Auswahl der passenden Kubernetes-Version. Hier sollte möglichst auf die aktuellste Version gesetzt werden, um alle verfügbaren Sicherheitspatches auf dem System vorzufinden. Generell sollte bei der eingesetzten Version darauf geachtet werden, dass keine Sicherheitslücken vorhanden sind. Wer hier auf eine ältere Kubernetes-Version setzt, weil die Apps in den Containern keine neuere Version unterstützen, geht ein unnötiges Sicherheitsrisiko ein.

Fehler 7: Fehlerhafte Authentifizierung für Azure Storage Accounts

Bei der Erstellung von Storage Accounts sollte möglichst nicht „Öffentlichen Blobzugriff aktivieren“ gesetzt sein. Dadurch sind anonyme Zugriffe auf den Speicher möglich. Das ist natürlich nicht ideal. Außerdem sollte die Option „Standardmäßig Azure Active Directory-Autorisierung im Azure-Portal“ gesetzt sein, damit der Zugriff über Azure AD gesteuert wird. Bei TLS-Mindestversion sollte hier keinesfalls eine Version unterhalb von 1.2 zum Einsatz kommen. Hinzu kommt die Einstellung „Zulässiger Bereich für Kopiervorgänge“. Hier sollte möglichst nicht „Aus einem beliebigen Speicherkonto“ genutzt werden, sondern besser „Von Speicherkonten im selben Azure AD-Mandanten“ oder „Von Speicherkonten mit privatem Endpunkt zum selben virtuellen Netzwerk“.

Fehler 8: „Microsoft Defender für die Cloud“-Empfehlungen ignorieren

Im Azure-Portal sind bei „Microsoft Defender für Cloud“ über „Empfehlungen“ Sicherheitstipps zu finden, um fehlerhafte Konfigurationen für Ressourcen zu verhindern oder sogar zu ändern. Es ist ein Fehler, diese Empfehlungen nicht zu lesen und entsprechend zu handeln. Für jede Empfehlung kann „Ablehnen“ oder „Erzwingen“ gesetzt werden. Mit „Deny“ lässt sich verhindern, dass fehlerhaft konfigurierte Ressourcen überhaupt erst erstellt werden und „Erzwingen“ korrigiert Fehler bei der Erstellung.

(ID:48922029)