In vielen Azure-Tenants, die ich betreue, stoße ich immer wieder auf dasselbe Problem: virtuelle Maschinen, deren RDP- oder SSH-Ports direkt aus dem Internet erreichbar sind. Manchmal steckt Unkenntnis dahinter, manchmal Zeitdruck oder schlicht das Fehlen einer Alternative. Für Brute-Force-Angriffe und Credential Stuffing ist das jedenfalls eine Einladung. Dabei gibt es mit Azure Bastion schon seit Jahren einen Weg, sicher auf virtuelle Maschinen zuzugreifen, ohne Management-Ports nach außen zu öffnen.

Mit Azure Bastion verschwinden die offenen Management-Ports

Setzt man Azure Bastion ein, sind die klassischen Management-Ports 3389 (RDP) und 22 (SSH) über keine öffentliche IP mehr erreichbar. Der Zugriff läuft stattdessen über einen PaaS-Dienst, der zentral in ein virtuelles Netzwerk eingebunden wird und meiner Erfahrung nach oft unterschätzt wird. Verbinden kann man sich bequem im Browser, je nach SKU auch mit nativen Clients. Einen guten Einstieg in die Funktionsweise bietet die Übersicht zu Azure Bastion.

Mittlerweile stehen vier SKUs zur Auswahl: Developer, Basic, Standard und Premium. Developer kam erst im Herbst 2024 dazu und ist als günstiger Einstieg für kleine Testumgebungen oder zum Lernen gedacht. Basic kennt man seit Langem als Grundangebot. Standard erlaubt mehr parallele Verbindungen und verbessert die Netzwerksegregation, Premium legt unter anderem die Sitzungsauditierung obendrauf. Wer die Unterschiede im Detail nachlesen möchte, findet sie in der offiziellen Bastion-SKU-Matrix.

Für Compliance und Nachvollziehbarkeit ist vor allem eine Funktion wertvoll: Ab der Premium-SKU lassen sich Sitzungen auditieren und aufzeichnen. Standard und Premium bringen außerdem „Native Client Support“ mit, man arbeitet dann direkt mit mstsc.exe oder einem SSH-Client und ist nicht auf den Browser angewiesen. Ebenfalls ab Standard gibt es „Shareable Session Links“, die etwa im Support nützlich sind. Man erzeugt einen Zugriffslink und schickt ihn einem berechtigten Kollegen, der sich selbstverständlich trotzdem authentifizieren muss.

In produktiven Umgebungen nehme ich mindestens die Standard-SKU, damit native Tools und Zugriffslinks zur Verfügung stehen. Für Lern- oder Testzwecke genügt oft Developer, aber eben auch nur dafür.

Just-in-Time-Zugriff öffnet VM-Ports nur befristet und automatisch

In bestehenden Installationen sehe ich häufig einen ergänzenden Ansatz, den Just-in-Time-VM-Zugriff (JIT) über Defender for Cloud. Ports wie RDP oder SSH werden dabei nur bei Bedarf und nur für eine begrenzte Zeit freigeschaltet, und zwar ausschließlich für die Quell-IP-Adressen, die ausdrücklich angefordert wurden. Die Angriffsfläche schrumpft dadurch deutlich. Wenig bringt das allerdings, wenn Admins aus Bequemlichkeit doch „Any“ eintragen oder JIT gleich ganz umgehen. JIT setzt Defender for Servers Plan 2 voraus. Mehr dazu steht in meinem Beitrag zur Wahl zwischen Defender for Servers Plan 1 und Plan 2. Ablauf und typische Szenarien beschreibt Microsoft in der Dokumentation zum Just-in-Time-VM-Zugriff.

Resource Graph und Defender for Cloud spüren offene Management-Ports auf

Wo noch Management-Ports offen stehen, finde ich auf zwei Wegen heraus. Entweder über Defender for Cloud → Empfehlungen, wo exponierte Ports unter „Externe Zugriffsmöglichkeiten minimieren“ auftauchen, oder mit einer kurzen Abfrage im Azure Resource Graph Explorer. Dazu im Portal → Suche nach „Resource Graph Explorer“ → folgende Abfrage ausführen:

resources
| where type == "microsoft.network/networksecuritygroups"
| mv-expand rules = properties.securityRules
| where tolower(rules.properties.destinationPortRange) in ("3389", "22")
| where rules.properties.access =~ "Allow"
| where rules.properties.direction =~ "Inbound"
| where rules.properties.sourceAddressPrefix in ("*", "0.0.0.0/0")
| project nsg = name, port = rules.properties.destinationPortRange, source = rules.properties.sourceAddressPrefix, resourceGroup

Dafür braucht man mindestens Reader auf Abonnementebene. Das Ergebnis zeigt auf einen Blick, wo noch nachgebessert werden muss.

Windows- und Linux-VMs akzeptieren auch eine Anmeldung mit Entra ID

Oft vergessen wird die Möglichkeit, sich an Azure-VMs direkt mit Entra ID (früher Azure AD) anzumelden. Vor allem auf Windows-Servern und aktuellen Linux-Distributionen lassen sich Administratorrollen so zentral vergeben und mit Conditional Access absichern. Unter Windows aktiviert man den Entra-ID-Login direkt in der VM-Konfiguration, unter Linux sind ein paar zusätzliche Pakete und Konfigurationsschritte nötig. Ist die VM entsprechend vorbereitet, unterstützt die Bastion-Konsole die Entra-ID-Anmeldung auf beiden Plattformen. Schwache, lokal gespeicherte Passwörter werden damit seltener, und Zugriffe lassen sich besser nachvollziehen.

Bastion kostet spürbar Geld, lässt sich aber bequem per CLI nutzen

In Projekten wird ein Punkt gern unterschätzt: Azure Bastion ist nicht billig, erst recht nicht, wenn viele parallele Sitzungen oder mehrere vNETs abgedeckt werden sollen. Die Developer-SKU kostet wenig, taugt aber nur für Einzelbenutzer und laborähnliche Szenarien. Basic und vor allem Standard und Premium sind deutlich teurer, monatlich kommt der Traffic noch hinzu (siehe Azure-Preisliste). In produktiven Infrastrukturen gehören diese Kosten deshalb von Anfang an ins Budget. Auf der anderen Seite spart man Aufwand bei Sicherheitsmaßnahmen, Incident Response und Compliance.

Angenehm ist, wie gut sich Bastion in CLI-Workflows einfügt. Eine RDP-Sitzung von der lokalen Konsole aus startet man beispielsweise so:

az network bastion rdp \
  --name <BastionName> \
  --resource-group <ResourceGroup> \
  --target-resource-id <VMResourceId>

Dafür braucht man die Azure CLI ab Version 2.0.83 und auf der Ziel-VM mindestens die Rolle „Virtual Machine User Login“.

Offene Management-Ports aus dem Internet sind heute vermeidbar

RDP oder SSH direkt aus dem Internet erreichbar zu machen, halte ich inzwischen für fahrlässig. Mit Azure Bastion als Standard und Just-in-Time-Zugriff für Sonderfälle gibt es dafür keinen Grund mehr. Welche SKU passt, hängt vom Szenario, den Compliance-Vorgaben und dem Budget ab. Für viele Organisationen führt an Standard oder Premium heute kein Weg vorbei. Wie die Komponenten zusammenspielen, zeigt die folgende Übersicht:

flowchart TD
  User["Admin"] --> GUI["Azure Portal/CLI"]
  GUI --> Bastion["Azure Bastion"]
  Bastion --> VM["VM im vNET"]
  Defender["Defender for Cloud JIT"] -- "optional Portfreigabe" --> VM
  Entra["Entra ID Login"] -- "optional Auth" --> Bastion

Abbildung: Sichere VM-Verwaltung mit Bastion, JIT und Entra ID

Wer offene Management-Ports bisher toleriert hat, sollte das jetzt ändern. Bastion und die übrigen Bausteine sind heute mit überschaubarem Aufwand eingerichtet, und die Sicherheit steigt erheblich.