Hybride Self-Hosted-Infrastruktur & Betrieb
Ein mit Ansible verwaltetes hybrides Infrastrukturlabor, das öffentlichen Ingress von privater Administration über Linux- und Windows-Systeme hinweg trennt – mit Azure-Arc-Governance, Monitoring und repräsentativer Recovery-Validierung.
Rolle
Ich habe dieses hybride Infrastrukturlabor entworfen und konfiguriert und betreibe es heute – einschließlich Public-/Private-Grenzen, Linux- und Windows-Administration, Ansible-Automatisierung, Host-Firewalls, Azure-Arc-Integration, Monitoring und Recovery-Validierung.
Kernergebnisse
- Public-/Private-Trennung
- Ingress und Administration
- Linux + Windows
- Ansible-verwaltete Konfiguration
- Ausgehendes HTTPS
- Azure-Arc-Governance
- Restore getestet
- Isolierter Recovery-Nachweis
Problem
Ausgewählte Web-Workloads benötigten einen kontrollierten öffentlichen Einstieg, während die Administration über lokale und externe Compute-Ressourcen hinweg privat bleiben sollte. Zusätzlich waren wiederholbare Linux- und Windows-Konfiguration, Runtime-Sichtbarkeit, geschützte Backups mit Wiederherstellungsnachweis und umgebungsübergreifende Governance erforderlich, ohne die Systeme nach Azure zu verlagern.
Architekturüberblick
Das Labor umfasst einen Public Edge VPS, eine lokale Proxmox- und Debian-Plattform sowie eine externe Windows-Server-Umgebung. Tailscale transportiert die private Administration und den Edge-to-Application-Pfad; Git und Ansible liefern versionierten Sollzustand sowie automatisierte Linux- und Windows-Konfiguration. Azure Arc ergänzt ausgehend angebundene Inventarisierung und Governance, ohne die verwalteten Systeme zu hosten.
Abbildung 1 — Hybride Infrastruktur im Überblick
Überblick über die hybride Infrastruktur mit öffentlichem Ingress, lokalen und externen Compute-Ressourcen, privatem Konfigurationsmanagement sowie umgebungsübergreifender Governance und Betrieb.
Designentscheidungen
- Public Edge VPS: trennt öffentlichen HTTP-/HTTPS-Ingress vom Hauptanwendungshost und exponiert keine Administrationsdienste öffentlich
- Tailscale: stellt verschlüsselte private Konnektivität für Administration und verteilte Systempfade bereit, ohne Managementdienste zum Internet zu öffnen
- Proxmox und der On-site Server: trennen die lokale Virtualisierungsschicht von Debian- und Docker-Compose-Anwendungsworkloads
- Hybrid Windows Lab: ergänzt praktische Windows-Server-Administration und -Härtung und bleibt vom öffentlichen Ingress isoliert
- Git und Ansible: liefern versionierten Sollzustand, wiederholbare Linux- und Windows-Konfiguration, Check-Mode-Prüfung, Audits und Idempotenzkontrollen
- Azure Arc: ergänzt Inventarisierung und Governance über mehrere Umgebungen hinweg, ohne Ansible, Tailscale oder die zugrunde liegenden Compute-Plattformen zu ersetzen
Architektur und Vertrauensgrenzen
Abbildung 2 — Architektur und Vertrauensgrenzen
Hybrides Infrastruktur-Deployment mit öffentlichem Ingress, privater Administration über Tailscale und ausgehend angebundener Azure-Arc-Governance.
Öffentlicher Anwendungsverkehr
Öffentlicher HTTP(S)-Verkehr erreicht den Public Edge VPS und wird über den verschlüsselten Tailscale-Pfad an eingeschränkte PROXY-Protocol-Listener auf dem On-site Server weitergeleitet. Nginx Proxy Manager bewahrt die ursprüngliche Client-Adresse, bevor freigegebener Verkehr zum Anwendungscontainer geroutet wird.
Privater Managementverkehr
Der Administration Controller erreicht verwaltete Linux-Systeme über SSH und das Hybrid Windows Lab über WinRM via Tailscale; RDP und die private IIS-Seite bleiben im selben privaten Administrationsnetz.
Azure-Arc-Steuerungsebene
Der On-site Debian Server und das Hybrid Windows Lab verbinden sich ausgehend über HTTPS-Port 443 mit Azure Arc für Hybrid-Inventarisierung, Ressourcensichtbarkeit und Azure Resource Graph; ein eingehender Azure-Arc-Managementport ist nicht erforderlich.
Umsetzung und Automatisierung
Git speichert den gewünschten Konfigurationszustand und die Betriebsdokumentation. Ansible wendet Linux-Konfiguration über SSH und Windows-Konfiguration über WinRM via Tailscale an. Relevante Änderungen werden vor der Anwendung mit Syntaxprüfungen, Check Mode und Diffs geprüft; Assertions, Post-Change-Verifikation und wiederholte Läufe decken konnektivitätssensitive Firewall-, SSH- und RDP-Änderungen ab. Der Administration Controller dient außerdem als erster Canary für geprüfte Linux-Hardening-Änderungen.
Sicherheitsmodell
Das Sicherheitsmodell folgt Defense in Depth: Öffentlicher Ingress ist von der Administration getrennt, Managementpfade nutzen Tailscale und Host-Firewalls beschränken eingehende Zugriffe. Der Public Edge VPS verwendet UFW und Fail2ban; der On-site Server kombiniert UFW mit einer persistenten Docker-aware Firewall-Policy, die die privaten Web-Listener auf den vertrauenswürdigen Edge-Peer beschränkt. CrowdSec verarbeitet Reverse-Proxy-Logs mit erhaltener Client-Adresse für Erkennung und Community Threat Intelligence; ein aktiver Bouncer wird nicht behauptet. Unter Windows bleiben Microsoft Defender und Windows Firewall aktiv, RDP erfordert Network Level Authentication, WinRM Basic Authentication und unverschlüsselte Kommunikation sind deaktiviert, SMBv1 ist abgeschaltet, unsichere SMB-Gastanmeldungen sind blockiert und IIS bleibt privat.
Hybrid Windows Lab und Azure-Arc-Governance
Die getrennte Windows-Server-2022-Datacenter-Umgebung erweitert das Labor über Linux- und Docker-Betrieb hinaus. Azure Arc bildet sowohl das Hybrid Windows Lab als auch den On-site Debian Server über ausgehendes HTTPS als verbundene Hybridmaschinen für Inventarisierung, Tags und Sichtbarkeit in der Steuerungsebene ab. Tailscale bleibt der private Administrationspfad; kostenpflichtige Azure-Erweiterungen und Azure-Benefits bleiben deaktiviert.
Umsetzung
- Tailscale stellt den privaten Administrationspfad bereit. Öffentliche Zugriffe über RDP, WinRM und IIS wurden getestet und als geschlossen bestätigt; die Windows Firewall beschränkt RDP, WinRM und die private IIS-Seite auf den Administration Controller.
- Ansible verwaltet Windows-Rollen und den Firewall-Zustand über PowerShell und WinRM mit NTLM-Nachrichtenverschlüsselung. Basic Authentication und unverschlüsselte WinRM-Nutzdaten sind deaktiviert; die Zugangsdaten verbleiben in einem verschlüsselten Vault außerhalb von Git.
- Ein eigenes Hardening-Playbook erstellt die eingeschränkte RDP-Regel vor der Deaktivierung breiter integrierter RDP-Regeln, prüft anschließend Firewall-Zustand und Konnektivität und stellt bei einer fehlgeschlagenen Prüfung die vorherigen Regeln wieder her.
- Ein Read-only-Sicherheitsaudit prüft Defender, Firewall-Profile, RDP mit Network Level Authentication, SMB-Einstellungen, lokale Administration, TLS-Konfiguration und Update-Status. SMBv1-Serverunterstützung und unsichere SMB-Gastanmeldungen sind deaktiviert.
- Azure-Arc-Onboarding für den On-site Debian Server und das Hybrid Windows Lab, die private IIS-Konfiguration, das Sicherheitsaudit und die Remote-Access-Härtung sind als Code dokumentiert.
Dieses Enterprise-inspirierte Labor zeigt praktische Windows-Server-2022-Administration, Azure-Arc-Onboarding für Windows und Debian sowie PowerShell-/WinRM-Automatisierung. Es ist weder ein produktiver Windows-Workload noch eine in Azure gehostete Compute-Umgebung und verarbeitet keinen öffentlichen Anwendungsverkehr.
Betrieb, Automatisierung und Recovery
Abbildung 3 — Betrieb, Automatisierung und Recovery
Infrastruktur-Betriebsworkflow mit versionierter Konfiguration, Validierung, Ansible-Automatisierung, Monitoring, Backup-Integrität und repräsentativen Recovery-Tests.
Verifikationsnachweise
- Debian-Azure-Arc-Audit: changed=0, unreachable=0, failed=0.
- Windows-Sicherheitsaudit: keine Baseline-Verletzungen; changed=0, unreachable=0, failed=0.
- Idempotenzprüfung der Windows-Remote-Access-Härtung: changed=0, failed=0.
- Private-IIS-Validierung: Öffentlicher Zugriff blieb blockiert, während der private Zugriff über Tailscale HTTP 200 lieferte.
- Recovery-Validierung: SHA-256- und Archivprüfungen waren erfolgreich; PostgreSQL wurde in einem isolierten temporären Container wiederhergestellt und die ClickHouse-Dateisystemextraktion wurde verifiziert.
Monitoring und Betrieb
Uptime Kuma überwacht die interne Service-Verfügbarkeit, Better Stack liefert eine externe Website-Prüfung und einen unabhängigen Host-Heartbeat, Netdata stellt Host-Metriken bereit und CrowdSec ergänzt Detection-Sichtbarkeit. Eine wiederkehrende systemd-Health-Prüfung deckt Datenträgerzustand und Backup-Aktualität ab; operative Benachrichtigungen werden über Telegram versendet.
Abbildung 4 — Bereinigtes Betriebsdashboard
Bereinigte Betriebsübersicht mit dokumentiertem Service-Management, Security-Transparenz, hybrider Governance und repräsentativer Recovery-Validierung für Anwendungen und Daten.
Backup und Recovery
Der Backup-Workflow nutzt Fail-fast-Ausführung, Locking, atomare Archivveröffentlichung, eingeschränkte Berechtigungen, Integritätsprüfungen und SHA-256-Prüfsummen-Sidecars. Recovery-Prüfungen gehen über die reine Backup-Erstellung hinaus: Restic-Repository-Integrität und vollständiges Lesen der Daten waren erfolgreich, PostgreSQL wurde mit 50 vorhandenen Anwendungstabellen in einem isolierten temporären Container wiederhergestellt und die ClickHouse-Dateisystemextraktion wurde verifiziert, bevor temporäre Klartext-Staging-Daten entfernt wurden. Dies ist ein repräsentativer Nachweis für die Wiederherstellung von Anwendungen und Daten, kein abgeschlossener vollständiger Infrastruktur-Disaster-Recovery-Test.
Backups gelten erst dann als belastbar, wenn die Wiederherstellung getestet wurde.
Aktuelle Grenzen
Die Umgebung ist bewusst klein gehalten und bietet weder Hochverfügbarkeit noch automatisches Failover. Die externe Restic-Kopie wird manuell statt zeitgesteuert ausgelöst; die aktuellen Wiederherstellungsnachweise decken Anwendungs- und Datenbankdaten statt einer vollständigen Infrastrukturrekonstruktion ab. Ein Teil der Ressourcenprovisionierung liegt außerhalb der Ansible-verwalteten Konfiguration.
Nächste Verbesserung
Ein zweites rotierendes oder unabhängiges unveränderliches Backup-Ziel ergänzen und ein verifiziertes, regelmäßig ausgeführtes VPS-Backup etablieren.
Technische Erkenntnisse
- Architekturdiagramme werden verständlicher, wenn Compute, Konnektivität, Konfigurationsmanagement, Governance und Observability als getrennte Aspekte dargestellt werden.
- Private Administration reduziert die öffentliche Angriffsfläche, benötigt aber weiterhin Host-Firewalls und Authentifizierungskontrollen.
- Konfigurationsautomatisierung wird verlässlicher, wenn sie mit Review, Read-only-Audits, Post-Change-Checks und Idempotenzprüfung kombiniert wird.
- Backup-Integrität ist unvollständig, solange repräsentative Daten nicht isoliert wiederhergestellt und geprüft wurden.
- Hybride Governance erfordert nicht, jeden Workload auf einer einzigen Cloud-Plattform zu zentralisieren.
Technologien
Compute & Betriebssysteme
Container & Ingress
Automatisierung & private Administration
Hybrid-Governance
Sicherheit
Monitoring & Wiederherstellung