Aufbau eines zweistufigen Netzwerks in Azure mit Frontend- und Backend-Tier sowie einem dedizierten Jump-Host für administrativen Zugriff – ein praktisches Lab-Projekt zu Azure Networking, Netzwerksicherheit und Tier-Trennung.

Ein Virtual Network mit drei getrennten Subnetzen, jeweils abgesichert durch eine eigene Network Security Group: Frontend, Backend und ein separates Management-Subnetz mit einem Jump-Host. Auf dem Frontend-Subnetz läuft eine öffentlich erreichbare VM, auf dem Backend-Subnetz eine VM ohne Public IP, die ausschließlich intern erreichbar ist. Der Jump-Host im dritten Subnetz ist der einzige Punkt, von dem aus administrativer SSH-Zugriff auf Frontend und Backend möglich ist.

Ressourcenübersicht

Alle Ressourcen sind konsistent getaggt (Project: TwoTier-Network, Environment: Lab, Purpose: Portfolio, Owner: Nico Miehle, CreatedBy: Manual).

In diesem Lab laufen alle drei VMs auf derselben Größe, wie in den Screenshots unten zu sehen – der Einfachheit halber und weil die Last hier synthetisch bzw. vernachlässigbar ist, nicht weil das die passende Dimensionierung für jede Rolle wäre.

In einer echten Umgebung würde die Größe pro VM-Rolle einzeln bestimmt, üblicherweise anhand von:

• Workload-Profil: CPU-lastig (z. B. ein Web-Frontend mit viel Rendering) und I/O-/speicherlastig (z. B. ein Datenbank-Server mit vielen Lese-/Schreibzugriffen) brauchen unterschiedliche VM-Serien – etwa Dsv5 für ausgewogene Allzweck-Workloads oder Esv5 für speicheroptimierte Workloads wie Datenbanken.
• Baseline-Messung statt Schätzung: Idealerweise startet man mit einer moderaten Größe, beobachtet CPU-, RAM- und Netzwerkauslastung über einen repräsentativen Zeitraum (z. B. via Azure Monitor / VM Insights) und passt die Größe anhand echter Metriken an, statt vorab zu raten.
• Azure Advisor: liefert nach einigen Tagen Betrieb automatisch Rightsizing-Empfehlungen, wenn eine VM dauerhaft unter- oder überdimensioniert läuft.
• Kosten vs. Performance: größere VMs sind linear teurer, aber nicht immer proportional schneller. Für viele Workloads ist es günstiger, mit mehreren kleineren Instanzen horizontal zu skalieren, als eine einzelne große VM vertikal zu vergrößern.
• Rolle im System: Ein Jump-Host wird nur sporadisch für administrative Zugriffe genutzt und kann entsprechend klein bzw. burstable dimensioniert werden (z. B. Standard_B1s), während Frontend und Backend kontinuierlich Last tragen und eine planbare Baseline-Performance brauchen (z. B. Dsv5-Serie statt Burstable-Serie).

Autoscaling statt fester Größe: Für produktionsnahe Szenarien, insbesondere das Frontend, wäre statt einer einzelnen fest dimensionierten VM ein Virtual Machine Scale Set (VMSS) mit Autoscaling-Regeln der nächste Schritt. Azure skaliert dabei automatisch horizontal – also die Anzahl der Instanzen, nicht deren Größe – basierend auf Metriken wie CPU-Auslastung oder Anzahl eingehender Requests. Das macht das System elastisch gegenüber Lastspitzen, ohne dass jede VM dauerhaft überdimensioniert vorgehalten werden muss. Für das Backend ist horizontales Skalieren deutlich komplexer, weil ein zustandsbehafteter Dienst wie eine MySQL-Datenbank nicht einfach durch weitere Instanzen dupliziert werden kann, ohne sich um Datenkonsistenz und Replikation zu kümmern – dort wäre eher vertikales Skalieren oder ein Managed-Database-Service wie Azure Database for MySQL der praxisnähere Weg.

Frontend VM – Übersicht

Backend VM – Übersicht

Jumper VM – Übersicht

Jedes Subnetz ist über eine eigene NSG abgesichert, nach dem Prinzip "nur erlauben, was gebraucht wird". Alles andere wird verworfen.

NSG Jumper (nsg-jumper-001): Nur SSH von meiner eigenen IP erlaubt, alles andere blockiert.

NSG Frontend (nsg-frontend-001): SSH nur vom Jumper, HTTP von überall, alles andere blockiert.

NSG Backend (nsg-backend-001): SSH nur vom Jumper, MySQL nur vom Frontend, alles andere blockiert.

Der SSH-Zugriff auf Frontend und Backend ist ausschließlich der Jumper-VM vorbehalten. Das Frontend darf ausschließlich MySQL zum Backend sprechen, keinen SSH-Zugriff. Web-Angriffsfläche (Frontend) und administrative Zugriffsfläche (Jumper) sind damit getrennte, eigenständige Systeme.

Alle drei Subnetze sind zusätzlich als "privates Subnetz" konfiguriert – Azures implizites Default-Outbound ist damit deaktiviert. Frontend und Jumper haben trotzdem einen expliziten Weg ins Internet über ihre eigene Public IP; das Backend erhält seinen Internetzugang stattdessen ausschließlich kontrolliert über das NAT Gateway nat-backend-001 – nachgewiesen durch ein erfolgreiches apt update auf der Backend-VM, obwohl diese keine eigene Public IP besitzt.

Alle drei VMs sind ausschließlich per Public-Key-Authentifizierung erreichbar, Passwort-Login ist vollständig deaktiviert. Root-Login per SSH ist gesperrt (PermitRootLogin no). Ein individuelles Login-Banner zeigt beim Verbindungsaufbau einen Hinweis auf autorisierten Zugriff und Logging, auf allen drei VMs konsistent umgesetzt.

Der administrative Zugriff läuft ausschließlich über den Jump-Host: von dort aus per SSH zu Frontend oder Backend.

Zur regelmäßigen Installation sicherheitsrelevanter Updates wurde auf allen drei VMs unattended-upgrades eingerichtet. Die Konfiguration entspricht der aus dem Pi-SSH-Fortress-Projekt: tägliche Prüfung auf Sicherheitsupdates um 03:00 Uhr, automatische Installation ohne manuellen Eingriff. Ein Screenshot des eingerichteten systemd-Timers ist dort zu finden.

Auf dem Backend läuft eine MySQL-Instanz. Ein dedizierter Datenbank-User (frontend_user) ist explizit auf Verbindungen aus 10.0.0.% beschränkt. MySQL bindet zusätzlich ausschließlich an die private Backend-IP 10.0.1.5, nicht an alle Interfaces.

Vom Frontend aus wurde eine Verbindung zur Backend-Datenbank aufgebaut, ein Eintrag geschrieben und wieder ausgelesen – Nachweis, dass die Tier-Trennung echten Datenbank-Traffic zulässt, während das Backend von außen weiterhin unerreichbar bleibt.

• Infrastructure as Code (Terraform) für reproduzierbare, versionierte Konfiguration
• Host-basierte Firewall (nftables) auf allen VMs, zusätzlich zu den NSGs
• Least-Privilege-Rechtevergabe (Azure RBAC) statt eines einzelnen Accounts mit vollen Rechten
• IDS/IPS, z.B. über NSG Flow Logs + Log Analytics, oder host-seitig mit Suricata
• Azure Bastion statt selbst verwalteter Jumper-VM
• Just-in-Time VM Access (Microsoft Defender for Cloud)
• Secrets Management über Azure Key Vault statt Passwörtern in Konfigurationsdateien