Zum Inhalt springen
Fabian Pauls Portfolio

Case Study 2 · laufend · Infrastruktur · Netzwerk · Security · Backup

Betrieb und Modernisierung der internen IT-Infrastruktur

Technische Gesamtverantwortung für eine breite, heterogene IT-Landschaft: von Arbeitsplatz-IT über Virtualisierung, Netzwerk und Firewall bis zu Microsoft 365, Identity, Fachanwendungen und einer mehrschichtigen Backup-Architektur.

Auftraggeber
Institut für Verwaltungswissenschaften gGmbH · laufend
Rolle
IT-Leitung, technische Gesamtverantwortung
Organisation
rund 10 fest Beschäftigte, über 50 Dozentinnen und Dozenten
Umfang
Proxmox-HA-Cluster (3 Nodes, Ceph), NAS mit rund 200 TB, 10-Gbit-LAN, Samba AD, Microsoft 365, Root-Server und VPS
Schwerpunkte
Infrastruktur · Netzwerk · Virtualisierung · Microsoft 365 · Security · Automatisierung · Betrieb

Ausgangslage und Verantwortungsmodell

Die interne IT umfasst klassische Arbeitsplatz-IT ebenso wie virtualisierte Serverdienste, Netzwerk- und Sicherheitsinfrastruktur, Microsoft-365-Dienste, Datei- und Speichersysteme sowie intern und extern erreichbare Fachanwendungen. Die Herausforderung liegt weniger in der Größe einzelner Systeme als in ihrer Breite: Zentrale Geschäftsprozesse hängen unmittelbar von einer kleinen IT-Organisation ab. Störungen lassen sich daher nicht zwischen spezialisierten Teams weiterreichen.

Client → Netzwerk → Firewall → Virtualisierung → Server → Storage → Identität → Anwendung → Daten

Verantwortungsbereiche

Infrastruktur und Virtualisierung

Ein wesentlicher Teil der Serverlandschaft wird virtualisiert betrieben. Zum Umfeld gehören Proxmox VE, Linux- und Windows-Gastsysteme, LXC-Container, Docker-basierte Anwendungen, persistente Storage- und Datenbankdienste, SMB/CIFS-Dateidienste sowie NAS-Systeme. Dazu gehören Planung von Host- und Gaststrukturen, Wiederherstellung und Migration virtueller Systeme, Analyse von Storage- und Mount-Problemen, Bewertung von Boot-, Kernel- und Secure-Boot-Themen sowie kontrollierte Updates und Neustarts produktiver Dienste.

Wiederherstellung statt reflexhafter Neuinstallation

Bei Problemen mit virtualisierten oder containerisierten Systemen ist die bevorzugte Vorgehensweise zunächst die Rekonstruktion des Fehlerbilds: Welche Schicht ist betroffen? Sind Daten und Anwendung getrennt? Welche persistenten Volumes existieren? Liegt die Störung im Gast, Hypervisor, Storage oder Netzwerk? Welche Wiederherstellungsoption verursacht das geringste zusätzliche Risiko? Damit werden Fehler nicht durch eine schnelle Neuinstallation verdeckt, und vorhandene Datenbestände bleiben möglichst unangetastet.

Netzwerk und Firewall

Die Netzwerkinfrastruktur nutzt OPNsense als zentrale Firewall- und Routingplattform mit mehreren physischen Interfaces, VLAN-basierter Segmentierung (intern, Gast, Internet-Transit mit Haupt- und Backup-Anbindung, Management, DMZ, IoT), Routing zwischen getrennten Netzen, Firewall-Regelwerken, NAT, VPN sowie IPv4/IPv6.

Im Rahmen einer aktuellen Infrastrukturmigration wurde die bestehende Firewallumgebung auf neue Multi-Gigabit-Hardware übertragen. Die Migration umfasste mehrere VLANs und erforderte die Prüfung von physischer Interfacezuordnung, Link-Geschwindigkeit, Routing, Gateway-Auswahl, NAT, Firewallregeln, DHCP/DNS-Abhängigkeiten, VPN, IPv6 und Anwendungs-Sonderpfaden. Ein konkretes Fehlerbild war eine zunächst unerwartete Begrenzung mehrerer Interfaces auf 100 Mbit/s. Statt die Ursache vorschnell der Firewallsoftware zuzuschreiben, wurde die Fehlerkette von der logischen Konfiguration bis zur physischen Verbindung heruntergebrochen.

Security Engineering im Betrieb

Security ist Bestandteil des Infrastrukturdesigns und kein separates Zusatzprodukt: Segmentierung unterschiedlicher Vertrauensbereiche, restriktive Firewallregeln, kontrollierte Freigabe interner Dienste, VPN-basierte administrative Zugänge, TLS und Zertifikatsverwaltung, Patch- und Schwachstellenbewertung sowie die Reduktion unnötiger Angriffsflächen.

Der Schwerpunkt liegt auf sicherer Architektur und verantwortlichem Betrieb. Grundlegende Schwachstellenklassen sowie CVE- und CVSS-basierte Bewertung sind vertraut; tägliches offensives Pentesting und laufende Threat-Intelligence-Beobachtung sind dagegen kein bisheriger Kernbereich.

Prinzip: interne Systeme bleiben intern

Nicht jeder Dienst wird veröffentlicht, nur weil externer Zugriff komfortabel wäre. Administrative Schnittstellen und interne Identitätssysteme sollen möglichst nicht unmittelbar aus dem Internet erreichbar sein. Wo externe Zugriffe erforderlich sind, werden kontrollierte Zugangspfade und getrennte Authentifizierungsmechanismen bevorzugt. Die Angriffsfläche wird damit bereits durch Architektur reduziert, bevor zusätzliche Security-Produkte eingesetzt werden.

Microsoft 365, Identität und Storage

Die Kollaborations- und Kommunikationsumgebung nutzt Microsoft 365. Administrative Aufgaben umfassen Benutzer- und Kontenverwaltung, Exchange Online, Postfachberechtigungen und Delegierungen, gemeinsame Postfächer, Offboarding, Berechtigungsbereinigung und administrative Audits. Beim Offboarding wird nicht nur das Benutzerkonto betrachtet, sondern auch delegierte Postfächer, einzelne Ordnerfreigaben, Gruppenmitgliedschaften, abhängige Geschäftsprozesse, Datenaufbewahrung und verbleibende Zugriffsrechte.

Für öffentlich erreichbare Dienste wird Keycloak als zentraler Identity Provider eingesetzt. Die Architektur trennt bewusst öffentliche Identitätssysteme und interne Vertrauensbereiche. Zu den Integrationsaufgaben gehören OIDC-Konfiguration, Single-Sign-On, Rollenabbildung, Benutzerimport, Logout-Verhalten, Account-Management sowie die Integration von Moodle, WordPress und weiteren Anwendungen.

Bei Störungen von SMB/CIFS-Ressourcen wird nicht nur die Erreichbarkeit eines Shares geprüft, sondern die gesamte Kette aus Netzwerk, TCP/445, SMB-Protokollversion, Authentifizierung, Kernel-Client, Mountoptionen, Berechtigungen, Namensauflösung und Storage-System. Ein konkretes Fehlerbild: Host erreichbar, TCP/445 erreichbar, Zugriff mit smbclient möglich, Kernel-Mount trotzdem fehlerhaft. Damit ließ sich die Fehlersuche früh auf Protokoll-, Client- und Mount-Ebene begrenzen, statt funktionierende Netzwerkkomponenten unnötig zu verändern.

Backup, Restore und Resilience

Die Backup-Architektur folgt dem Prinzip, dass ein kompromittiertes Produktivsystem seine eigenen Wiederherstellungspunkte nicht zerstören können darf.

Externes Append-only-Backupziel

Geschäftskritische Server- und Anwendungsdaten werden auf einen räumlich getrennten rest-server bei einem externen Hostinganbieter gesichert. Der rest-server wird im Append-only-Modus betrieben: Produktivsysteme können neue Sicherungsstände erzeugen, besitzen jedoch keine Berechtigung, vorhandene Backups nachträglich zu verändern oder zu löschen. Die administrativen Zugangsdaten zum Backupserver befinden sich bewusst nicht auf Produktivsystemen und nicht in der normalen Credential-Infrastruktur, sondern werden ausschließlich offline als Break-Glass-Zugang vorgehalten.

Das ist keine technisch absolute WORM-Speicherung, sondern eine WORM-ähnliche Sicherheitsarchitektur mit bewusst getrenntem administrativem Vertrauenspfad: Produktionssystem → ausschließlich append-only → Backupziel.

Zusätzlicher Air-Gap

Ergänzend wird einmal wöchentlich eine Sicherung auf eine LUKS-verschlüsselte Festplatte geschrieben und das Medium anschließend physisch vom System getrennt. Damit existiert eine Kopie, die im normalen Betrieb nicht adressierbar ist und auch bei einer Kompromittierung der regulären Online-Backupinfrastruktur erhalten bleibt. Die Festplatten werden wöchentlich rotiert und an verschiedenen externen Orten aufbewahrt.

Große Videodaten: Replikation und ZFS-Snapshots

Große Videoprojekte werden per rsync über eine dedizierte 10GBASE-LR-Verbindung auf ein räumlich getrenntes ZFS-System innerhalb des Gebäudekomplexes übertragen. Snapshots erhalten historische Datenstände unabhängig vom Zustand der Quelle: Das Quellsystem kann aktuelle Daten replizieren, besitzt aber keine Kontrolle über die Snapshot-Historie. Dieser Sicherungsweg ist bewusst kein geografisches Off-Site-Backup, sondern adressiert Ausfall des Quellspeichers, versehentliches Löschen, logische Beschädigung und schnelle Wiederherstellung großer Datenmengen.

Append-only rest-server

Schutz vor Manipulation vorhandener Backups durch kompromittierte Produktivsysteme

Getrennte Break-Glass-Zugänge

Backupadministration liegt außerhalb des normalen Credential-Pfads

Wöchentliche LUKS-Offlinekopie

Air-Gap gegen Kompromittierung der gesamten Online-Infrastruktur

rsync + ZFS-Snapshots

Schutz großer Datenbestände vor Quellverlust, Löschung und Manipulation

Räumliche Trennung

Reduktion gemeinsamer technischer Fehlerdomänen

Ein belastbares Backup beantwortet nicht nur „Gibt es eine Kopie?“, sondern auch: Kann die Quelle sie löschen? Wer kann historische Zustände verändern? Ist mindestens eine Kopie offline? Wie erfolgt der Restore? Welche gemeinsamen Fehlerdomänen bleiben bestehen?

Fachanwendungen, Plattformen und Automatisierung

Neben klassischer Infrastruktur werden zahlreiche Fachanwendungen betrieben oder technisch betreut: Moodle, BigBlueButton, Keycloak, Microsoft 365, WordPress-basierte Systeme, interne APIs, Docker-basierte Dienste, Datenbankanwendungen und Automatisierungsplattformen. Das intern entwickelte zentrale Verwaltungsprogramm läuft als Docker-Container mit Django/Python-Stack. Die Herausforderung liegt häufig an den Übergängen: Ein Anmeldeproblem in Moodle kann durch Moodle, OIDC-Konfiguration, Keycloak, Reverse Proxy, Browser-Session, Rollenmapping oder Benutzerbestand verursacht werden.

Für digitale Veranstaltungen werden Moodle und BigBlueButton betrieben, einschließlich Integration, Authentifizierung, Netzwerkanbindung, Firewallregeln, TURN-Kommunikation, TLS, Reverse Proxy und Fehleranalyse. Echtzeitkommunikation erfordert eine Diagnose über „Website erreichbar“ hinaus, insbesondere bei NAT-, TURN- und Medienpfaden.

Ein zunehmender Schwerpunkt ist die Automatisierung wiederkehrender administrativer und organisatorischer Prozesse mit Python, Shell, REST-APIs, n8n, Docker, systemd, strukturierten Daten und LLM-gestützten Workflows. Automatisiert wird nicht um der Technik willen, sondern wenn dadurch wiederkehrende manuelle Arbeit entfällt, Fehlerquellen reduziert werden oder eine Organisation mit reduzierter Personalstärke zuverlässig arbeitsfähig bleibt.

Monitoring und Fehleranalyse

Die Fehlersuche folgt einem schichtweisen Ansatz, der früh eingrenzt, welche Komponenten als Ursache überhaupt infrage kommen.

Hardware → Link → Netzwerk → Routing → Firewall → Transport → Betriebssystem → Dienst → Authentifizierung → Anwendung → Daten

Betrieb statt Produktdenken

Die interne IT besteht bewusst nicht aus einem einzelnen Hersteller-Stack. Linux und Windows, On-Premises und Cloud, Standardsoftware und Eigenentwicklung sowie Container und klassische Systeme werden nach Betriebsanforderung, Datenschutz, Kosten, Wartbarkeit und Integrationsbedarf ausgewählt. Zur IT-Verantwortung gehört die wirtschaftliche Bewertung: Hardware- und Softwareauswahl, Lizenzen, SaaS versus Self-Hosting, Dienstleisterbewertung und laufende Kosten, jeweils einschließlich Herstellerabhängigkeit, Datenportabilität, Backupfähigkeit, Integrationsaufwand, Ausfallrisiko und personellem Betriebsaufwand.

Was diese Umgebung über meine Arbeitsweise zeigt