Technische Unternehmensinfrastruktur

0. Management Summary und Zielbild

Dieses Handbuch beschreibt eine professionelle technische Unternehmensinfrastruktur. Es verbindet Netzwerk, Server, Security, Cloud, Backup, Monitoring und Betrieb zu einem steuerbaren Gesamtsystem.

Eine gute Infrastruktur ist nicht nur schnell und erreichbar. Sie muss auch kontrollierbar, dokumentiert, wiederherstellbar und sicher betreibbar sein. Das Ziel ist eine Architektur, in der klare Zonen, definierte Datenflüsse, eindeutige Verantwortlichkeiten und regelmäßige Reviews verhindern, dass technische Schulden oder Sicherheitsrisiken unkontrolliert wachsen.

Leitprinzipien:

1. 1. **Segmentierung statt flachem Netzwerk:** Clients, Server, Datenbanken, Adminzugänge, Gäste, IoT und Backups werden getrennt.
2. 2. **Least Privilege:** Benutzer, Geräte und Systeme erhalten nur die Rechte, die sie wirklich brauchen.
3. 3. **Defense in Depth:** Mehrere Schutzschichten reduzieren das Risiko, wenn eine einzelne Maßnahme versagt.
4. 4. **Zero Trust Denken:** Jeder Zugriff wird geprüft, auch wenn er aus dem internen Netzwerk kommt.
5. 5. **Restore vor Backup-Glaube:** Ein Backup ist erst dann wertvoll, wenn ein Restore getestet wurde.
6. 6. **Dokumentation als Betriebsbestandteil:** Netzwerkplan, IP-Plan, Firewall-Regeln, Asset-Liste und Notfallplan sind Teil der Infrastruktur.
7. 7. **Betriebsfähigkeit:** Monitoring, Patchmanagement, Incident Response und Change Management sind genauso wichtig wie Hardware.

1. Grundlagen: Netzwerk, Server und Unternehmens-IT

Technische Infrastruktur besteht aus mehreren Schichten. Auf der unteren Ebene stehen physische Komponenten wie Switches, Router, Firewalls, Access Points, Server, Storage und Verkabelung. Darüber liegen logische Strukturen wie VLANs, IP-Subnetze, Routing, DNS, DHCP und Identitäten. Auf der obersten Ebene laufen Anwendungen wie ERP, CRM, E-Mail, Dateiablage, Webportale und Cloud-Dienste.

Das wichtigste Missverständnis ist, Infrastruktur nur als Sammlung von Geräten zu betrachten. Professionelle Infrastruktur ist vielmehr ein Betriebssystem für das Unternehmen. Sie legt fest, welche Benutzer auf welche Anwendungen zugreifen, welche Systeme miteinander kommunizieren dürfen, wie Daten gesichert werden und wie ein Notfall beherrscht wird.

Die vier Grundfragen

Warum Architektur wichtig ist

Wenn ein Netzwerk ohne Architektur wächst, entstehen typische Probleme: unbekannte Geräte, veraltete Server, unklare Firewall-Regeln, flache Netze, zu viele Adminrechte, ungetestete Backups und fehlende Dokumentation. Das funktioniert oft jahrelang, bis ein größerer Ausfall, eine Ransomware-Attacke oder ein Audit die Schwächen sichtbar macht.

Eine saubere Architektur macht Risiken sichtbar und reduziert Komplexität. Sie ermöglicht kontrolliertes Wachstum.

2. Zielarchitektur und Zonenmodell

Eine Zielarchitektur trennt die Infrastruktur in Zonen. Jede Zone hat eine definierte Aufgabe, ein definiertes Risiko und definierte Kommunikationsregeln.

Typische Zonen

Architekturprinzip

Die Zonen werden nicht nur gezeichnet, sondern mit Regeln verbunden. Eine Linie im Diagramm bedeutet nicht „alles darf“. Sie bedeutet: Es gibt einen genau definierten Datenfluss, der dokumentiert und geprüft wird.

Beispiel

Ein Client darf DNS und eine interne Anwendung erreichen. Er darf aber nicht direkt auf eine Datenbank oder Backup-Repositories zugreifen. Ein Admin darf Server administrieren, aber nur mit separatem Admin-Konto, MFA, Adminnetz und Logging.

3. OSI-Modell, TCP/IP und praktische Bedeutung

Das OSI-Modell hilft, Netzwerkprobleme strukturiert zu verstehen. In der Praxis ist es weniger eine starre technische Grenze als ein Denkmodell für Fehlersuche und Architektur.

Praktische Lesart

Typische Fehlersuche

Wenn eine Anwendung nicht erreichbar ist, prüft man nicht zuerst die Anwendung. Man prüft von unten nach oben:

1. 1. Link aktiv?
2. 2. IP-Adresse korrekt?
3. 3. Gateway erreichbar?
4. 4. DNS-Auflösung korrekt?
5. 5. Port offen?
6. 6. TLS/Zertifikat gültig?
7. 7. Anwendung läuft?

Diese Denkweise spart Zeit und verhindert falsche Ursachenannahmen.

4. IP-Adressierung, Subnetting, VLAN und IPAM

Ein sauberer IP-Plan ist eine der wichtigsten Grundlagen. Ohne IPAM und VLAN-Plan entstehen Überschneidungen, unklare Firewall-Regeln und Probleme bei Cloud- oder Standortanbindungen.

Beispiel-VLAN-Plan

IPAM-Best-Practices

• Jedes Subnetz hat einen Owner.
• DHCP-Bereiche und statische Reservierungen sind dokumentiert.
• DNS- und PTR-Einträge werden gepflegt.
• Firewall-Objekte werden aus dokumentierten Netzen abgeleitet.
• Cloud- und Standortnetze überschneiden sich nicht.
• Reserven für Wachstum werden eingeplant.

Subnetting-Entscheidung

Ein /24 ist für viele Server- oder Infrastruktur-VLANs ausreichend. Für Client-Netze kann ein /23 oder mehrere /24 sinnvoll sein. Große flache Client-Netze sollten vermieden werden.

5. Switching, Routing und Campus-Design

In größeren Umgebungen wird das LAN oft in Core, Distribution und Access strukturiert.

Rollen

Kleine Unternehmen haben diese Ebenen oft in einem Switch oder Stack kombiniert. Mittelgroße Unternehmen nutzen häufig redundante Core-Switches und mehrere Access-Switches.

Wichtige Technologien

• **VLANs:** logische Trennung
• **Trunks:** Transport mehrerer VLANs
• **LACP:** Bündelung mehrerer Links
• **STP/RSTP:** Schutz vor Layer-2-Schleifen
• **Routing:** Verbindung zwischen IP-Netzen
• **ACLs:** einfache Filterung auf Netzwerkebene
• **QoS:** Priorisierung von Voice, Video oder kritischem Traffic

Typische Fehler

• ungeplante VLANs
• keine Dokumentation von Trunk-Ports
• flache Netze
• Loops durch falsche Verkabelung
• keine redundanten Uplinks
• fehlende Firmware-Updates

6. Perimeter, Gateway, NAT und Firewall

Der Perimeter ist die Grenze zwischen Unternehmensnetz und Außenwelt. Er besteht häufig aus ISP-Router, Edge Firewall, VPN/ZTNA-Gateway, NAT, IDS/IPS und Logging.

Gateway und NAT

Ein Gateway verbindet Netze. NAT übersetzt private interne IP-Adressen in öffentliche Adressen oder veröffentlicht Dienste über definierte Weiterleitungen.

Beispiel:

• Client 10.10.50.25 nutzt Internet.
• Firewall übersetzt auf öffentliche IP.
• Rückverkehr wird derselben Verbindung zugeordnet.

Firewall-Regeln

Eine professionelle Firewall-Regel ist kein technischer Zufall, sondern ein dokumentierter Datenfluss.

Schlechte Regelmuster

• any to any
• breite Netzfreigaben ohne Zweck
• dauerhafte Dienstleisterregeln
• keine Logs
• keine Owner
• keine Regelreviews
• direkte Portweiterleitung auf interne Server

7. DMZ, Reverse Proxy, WAF und API-Gateways

Die DMZ ist eine Sicherheitszone für Systeme, die von außen erreichbar sein müssen. Sie verhindert, dass externe Zugriffe direkt auf interne Server treffen.

Typische DMZ-Systeme

Datenfluss-Beispiel

Internet → Edge Firewall → WAF → Reverse Proxy → App Server → Datenbank

Die Datenbank bleibt intern und ist niemals direkt aus dem Internet erreichbar.

DMZ-Regel

Von der DMZ ins interne Netz darf nur das, was technisch zwingend notwendig ist. Keine breite Freigabe von DMZ zu internen Servernetzen.

8. VPN, ZTNA und Remote Access

Remote Access ist einer der wichtigsten Sicherheitsbereiche. Früher wurde oft ein VPN-Zugang ins interne Netz gewährt. Heute ist es besser, Zugriff nach Identität, Gerät, Rolle, Anwendung und Risiko zu steuern.

Klassischer VPN-Zugriff

Vorteile:

• einfach
• vertraut
• gut für Standortkopplung

Risiken:

• oft zu breiter Netz-Zugriff
• kompromittierte Geräte können lateral bewegen
• MFA und Geräteprüfung fehlen manchmal

Zero Trust Network Access

ZTNA gibt nicht pauschal Netzwerkzugang, sondern Zugriff auf konkrete Anwendungen.

Geprüft wird:

• Benutzeridentität
• MFA
• Gerätestatus
• Standort
• Rolle
• Risiko
• Anwendung
• Session-Verhalten

Best Practice

Remote User → Identity/MFA → Device Check → Policy → genau erlaubte App

Nicht:

Remote User → gesamtes internes Netzwerk

9. Active Directory, Identity und Berechtigungen

Identität ist das Herz der Infrastruktur. Viele technische Kontrollen sind wertlos, wenn Identitäten, Gruppen und Adminrechte unsauber gepflegt sind.

Active Directory Kernelemente

Berechtigungsmodell

Ein gutes Modell trennt:

• normale Benutzerkonten
• administrative Konten
• Service Accounts
• Notfallkonten
• externe Dienstleisterkonten

Admin-Best-Practices

• Admin-Konten nicht für E-Mail oder Web nutzen.
• MFA für alle Adminzugänge.
• Tiering-Modell für Adminrechte.
• PAM für privilegierte Sitzungen.
• regelmäßiger Review von Gruppenmitgliedschaften.
• keine dauerhaften Domain Admin-Rechte für normale Aufgaben.

9A. LDAP und LDAPS: Verzeichnisdienst für Benutzer, Gruppen und Anwendungen

LDAP steht für Lightweight Directory Access Protocol. Es ist ein Protokoll, mit dem Anwendungen Informationen aus einem Verzeichnisdienst abfragen können. In Unternehmen wird LDAP häufig verwendet, um Benutzer, Gruppen, Organisationseinheiten, Geräte oder Attribute zentral zu verwalten und Anwendungen daran anzubinden.

LDAP ist also nicht einfach „Login“. LDAP ist ein Abfrage- und Zugriffprotokoll für Verzeichnisdaten. Der Verzeichnisdienst kann zum Beispiel Microsoft Active Directory, OpenLDAP, 389 Directory Server oder ein anderes LDAP-kompatibles System sein.

Wofür wird LDAP genutzt?

Typische Einsatzzwecke:

LDAP vs. Active Directory

Active Directory ist ein Verzeichnisdienst von Microsoft. LDAP ist eines der Protokolle, über das man auf Verzeichnisdaten zugreifen kann.

Ein einfaches Bild:

LDAP vs. LDAPS

Best Practice: Anwendungen sollten LDAPS oder LDAP mit StartTLS nutzen, damit Anmeldedaten und Attribute nicht ungeschützt übertragen werden.

Grundbegriffe

Typischer LDAP-Login-Ablauf

Beispiel: Eine Webanwendung nutzt LDAP zur Anmeldung.

1. 1. Benutzer gibt Benutzername und Passwort in der Webanwendung ein.
2. 2. Die Webanwendung verbindet sich per LDAPS mit dem LDAP-Server.
3. 3. Die Anwendung nutzt einen Service Account oder sucht direkt nach dem Benutzer.
4. 4. LDAP sucht das Benutzerobjekt anhand eines Filters.
5. 5. Die Anwendung prüft das Passwort per Bind.
6. 6. LDAP bestätigt erfolgreich oder lehnt ab.
7. 7. Die Anwendung liest Gruppen oder Attribute.
8. 8. Die Anwendung entscheidet, welche Berechtigung der Benutzer erhält.

Beispiel für LDAP-Struktur

dc=firma,dc=local
├── ou=Users
│   ├── cn=Max Mustermann
│   └── cn=Ayse Demir
├── ou=Groups
│   ├── cn=VPN-Users
│   ├── cn=ERP-Admins
│   └── cn=Finance-ReadOnly
└── ou=Computers
    ├── cn=PC-001
    └── cn=SRV-FILE-01

Beispiel-DN

cn=Max Mustermann,ou=Users,dc=firma,dc=local

Bedeutung:

Beispiel-LDAP-Filter

(sAMAccountName=max.mustermann)

Sucht in Active Directory nach einem Benutzer mit dem Anmeldenamen max.mustermann.

Weitere Beispiele:

(&(objectClass=user)(memberOf=cn=VPN-Users,ou=Groups,dc=firma,dc=local))

Sucht Benutzer, die Mitglied der Gruppe VPN-Users sind.

(mail=*@firma.de)

Sucht Objekte mit E-Mail-Adressen der Domain firma.de.

LDAP in der Netzwerkarchitektur

LDAP-Server oder Domain Controller sollten in einer internen Identity-Zone stehen, nicht in der DMZ. Anwendungen in der DMZ sollten nur dann LDAP/LDAPS erreichen dürfen, wenn es wirklich notwendig ist. Besser ist oft ein vorgeschalteter Identity Provider oder Reverse Proxy mit SSO.

Typische Regel:

Service Accounts für LDAP

Viele Anwendungen nutzen einen LDAP-Service-Account, um Benutzerobjekte zu suchen. Dieser Account sollte sehr eingeschränkte Rechte haben.

Best Practices:

• kein Domain Admin
• nur Leserechte, wenn möglich
• langes, zufälliges Passwort oder Managed Service Account
• Passwortrotation
• keine interaktive Anmeldung
• Nutzung dokumentieren
• Owner definieren
• Monitoring auf Fehlversuche
• Konto deaktivieren, wenn Anwendung entfernt wird

Sicherheit bei LDAP

Wichtige Sicherheitsregeln:

1. 1. LDAPS verwenden: Keine unverschlüsselte Passwortübertragung.
2. 2. Zertifikate prüfen: Anwendungen müssen dem LDAP-Zertifikat vertrauen.
3. 3. Keine direkten Internetfreigaben: LDAP/LDAPS niemals aus dem Internet öffnen.
4. 4. Service Accounts begrenzen: Nur notwendige Rechte vergeben.
5. 5. LDAP-Signing und Channel Binding prüfen: Besonders in Windows-/AD-Umgebungen relevant.
6. 6. Gruppen regelmäßig prüfen: Alte Berechtigungen entfernen.
7. 7. Logs sammeln: erfolgreiche und fehlgeschlagene Bind-Versuche überwachen.
8. 8. Redundanz einplanen: mehrere Domain Controller oder LDAP-Server.
9. 9. Firewall-Regeln dokumentieren: Quelle, Ziel, Port, Zweck, Owner und Review.
10. 10. Anwendungen modernisieren: Wo möglich SAML, OIDC oder Kerberos statt direkter LDAP-Logins nutzen.

LDAP und moderne Authentifizierung

LDAP ist weiterhin sehr verbreitet, aber moderne Anwendungen nutzen oft SAML, OAuth2 oder OpenID Connect. LDAP bleibt trotzdem wichtig, weil viele Systeme Active Directory oder LDAP als zentrale Quelle für Benutzer und Gruppen nutzen.

Typische Fehler

• LDAP 389 unverschlüsselt für Logins verwenden
• LDAP/AD aus der DMZ breit erreichbar machen
• Service Account mit zu hohen Rechten
• keine Zertifikatsprüfung bei LDAPS
• LDAP-Zugang aus Client- oder Guest-Netzen erlauben
• alte Anwendungen mit fest codierten Passwörtern
• Gruppenmitgliedschaften nie prüfen
• fehlende Logs bei Bind-Fehlern
• keine Redundanz für Domain Controller
• Firewall-Regeln ohne Owner und Review

Mini-Checkliste LDAP

10. PKI, Zertifikate und TLS

Zertifikate schaffen technisches Vertrauen. Sie werden für HTTPS, VPN, WLAN, Geräteauthentifizierung, interne Dienste und Benutzerzertifikate genutzt.

PKI-Bestandteile

Typische Fehler

• abgelaufene Zertifikate
• private Schlüssel schlecht geschützt
• keine Dokumentation
• Root CA online und ungeschützt
• Zertifikate ohne Owner
• keine Erneuerungsprozesse

11. Server, Virtualisierung und Storage

Serverplattformen stellen Anwendungen, Datenbanken und Basisdienste bereit. In modernen Umgebungen laufen viele Server virtualisiert oder containerisiert.

Virtualisierung

Typische Plattformen:

• VMware
• Hyper-V
• Proxmox
• Nutanix

Vorteile:

• bessere Hardwareauslastung
• schnelle Bereitstellung
• Snapshots
• HA-Funktionen
• einfachere Migration

Storage-Arten

Trennung

Server, Anwendungen und Datenbanken sollten nicht im gleichen Netzwerk wie Clients liegen. Datenbanken erhalten eigene Regeln und sollten nur von Applikationsservern erreicht werden.

12. Dateiablage, Datenbanken und Applikationen

Dateiablagen, Datenbanken und Fachanwendungen sind geschäftskritisch. Deshalb müssen sie technisch und organisatorisch sauber betrieben werden.

Dateiablage

Wichtige Punkte:

• klare Freigabestruktur
• Gruppen statt Einzelberechtigungen
• NTFS- und Share-Rechte konsistent
• regelmäßige Berechtigungsreviews
• Quotas und Klassifizierung
• Backup und Versionierung

Datenbanken

Datenbanken brauchen besonderen Schutz:

• keine direkte Internetverbindung
• kein direkter Clientzugriff, außer zwingend nötig
• getrennte Adminrollen
• Verschlüsselung prüfen
• regelmäßige Backups
• Performance-Monitoring
• Audit-Logs

Applikationen

Applikationen brauchen:

• dokumentierte Abhängigkeiten
• technische Owner
• Wartungsfenster
• Update-Prozess
• Datenflussbeschreibung
• Monitoring
• Backup- und Restore-Test

13. Cloud, Hybrid Cloud und Landing Zone

Cloud ist nicht automatisch sicher. Sie verlagert Verantwortung, hebt sie aber nicht auf. Eine Cloud Landing Zone stellt sicher, dass Netzwerk, Identität, Logging, Backup, Rollen und Kostenkontrolle von Anfang an strukturiert sind.

Bestandteile einer Landing Zone

Hybrid-Anbindung

Möglichkeiten:

• Site-to-Site VPN
• ExpressRoute / Direct Connect
• SD-WAN Cloud On-Ramp
• ZTNA/SASE

Cloud-Netze müssen so geplant werden, dass sie sich nicht mit lokalen Netzen überschneiden.

14. Backup, Restore und Disaster Recovery

Backup schützt vor Datenverlust. Disaster Recovery schützt vor Betriebsstillstand. Beide Themen müssen zusammen geplant werden.

RTO und RPO

3-2-1-1-0

• 3 Kopien
• 2 unterschiedliche Speicherarten
• 1 externe Kopie
• 1 immutable oder offline Kopie
• 0 ungeprüfte Fehler durch Restore-Test

Ransomware und Backup

Ransomware versucht häufig, auch Backups zu löschen. Deshalb:

• Backupnetz trennen
• separate Backupkonten
• immutable Storage
• Offline- oder Offsite-Kopie
• regelmäßige Restore-Tests
• Alarmierung bei ungewöhnlichen Löschvorgängen

DR-Runbook

Ein DR-Runbook enthält Reihenfolge, Verantwortliche, Zugangsdaten-Orte, Prüfschritte und Kommunikationswege.

15. Monitoring, Logging, SIEM und SOC

Monitoring und Logging machen Infrastruktur sichtbar. Ohne Sichtbarkeit werden Ausfälle und Angriffe zu spät erkannt.

Monitoring

Überwacht:

• Server-Verfügbarkeit
• CPU/RAM/Disk
• Dienste
• Backups
• Firewalls
• Switches
• Internetleitungen
• Zertifikate
• Applikationen

Logging

Sammelt Ereignisse:

• Anmeldungen
• Adminänderungen
• Firewall-Blocks
• EDR-Funde
• Cloud-Aktivitäten
• VPN-Logins
• fehlgeschlagene Zugriffe

SIEM

Ein SIEM korreliert Ereignisse. Beispiel: Viele fehlgeschlagene Logins, danach erfolgreicher Login aus unbekanntem Land und anschließend Adminaktion. Solche Muster sind manuell schwer zu erkennen.

SOC

Ein SOC bewertet Alarme, priorisiert Vorfälle und koordiniert Reaktion. Kleine Unternehmen können ein Managed SOC nutzen.

16. Security-Architektur und Angriffsszenarien

Security-Architektur muss typische Angriffe berücksichtigen. Das Ziel ist nicht perfekte Sicherheit, sondern Risikoreduktion, Sichtbarkeit und Wiederherstellungsfähigkeit.

Häufige Angriffe

Sicherheitsprinzip

Jede Schutzmaßnahme sollte eine Frage beantworten: Verhindert sie Angriff? Erkennt sie Angriff? Begrenzt sie Schaden? Hilft sie Wiederherstellung?

17. Patchmanagement, Vulnerability Management und Hardening

Patchmanagement reduziert bekannte Schwachstellen. Vulnerability Management priorisiert, welche Lücken zuerst geschlossen werden. Hardening reduziert Angriffsfläche.

Patchprozess

1. 1. Inventar
2. 2. Schwachstellenbewertung
3. 3. Test
4. 4. Rollout in Ringen
5. 5. Kontrolle
6. 6. Ausnahmebehandlung

Priorisierung

Nicht jede Schwachstelle ist gleich dringend. Kritisch sind:

• Internet-exponierte Systeme
• aktive Ausnutzung
• hohe Kritikalität
• einfache Ausnutzbarkeit
• Systeme mit sensiblen Daten
• Systeme mit Adminrechten

Hardening

• unnötige Dienste deaktivieren
• sichere Baselines
• lokale Adminrechte reduzieren
• Firewall aktivieren
• Logging aktivieren
• Default-Passwörter entfernen
• sichere TLS-Konfiguration

18. WLAN, NAC, IoT und Geräte-Netze

WLAN ist oft der einfachste Zugang ins Netzwerk. Deshalb braucht es klare Trennung und Authentifizierung.

WLAN-Zonen

NAC

Network Access Control prüft Geräte, bevor sie ins Netzwerk kommen. 802.1X mit RADIUS kann Benutzer oder Geräte authentifizieren und VLANs dynamisch zuweisen.

IoT

Drucker, Kameras und Sensoren sind oft schlecht geschützt. Sie sollten isoliert werden und nur notwendige Dienste erreichen.

19. SD-WAN, WAN, MPLS und Standortvernetzung

Standortvernetzung verbindet Zentrale, Filialen, Produktion, Cloud und Rechenzentren.

Optionen

Architekturfragen

• Welche Standorte sind kritisch?
• Gibt es lokale Internet-Breakouts?
• Wo läuft Security Inspection?
• Wie wird Cloud erreicht?
• Gibt es zentrale oder dezentrale Firewalls?
• Welche Anwendungen brauchen geringe Latenz?

20. Betrieb: ITIL, Change, Incident und Dokumentation

Betrieb entscheidet, ob eine Architektur dauerhaft funktioniert. Gute Technik ohne Prozesse wird schnell unsicher.

Kernprozesse

Dokumente

• Netzwerkplan
• Rackplan
• IP-/VLAN-Plan
• Firewall-Regelmatrix
• Serverliste
• Applikationsliste
• Asset-Liste
• Backup-Konzept
• Notfallplan
• Wartungsverträge
• Kontaktliste

21. Planungs-Input-Canvas und Workshop-Vorgehen

Das Planungs-Input-Canvas ist die zentrale Vorlage für Erstaufnahme und Zielarchitektur. Es verhindert, dass man direkt Technik einkauft, bevor Anforderungen geklärt sind.

Workshop-Struktur

1. 1. Unternehmensprofil erfassen
2. 2. Anwendungen und Daten klassifizieren
3. 3. Netzwerk und Standorte aufnehmen
4. 4. Zugriffsmodell und Security prüfen
5. 5. Betrieb und Monitoring bewerten
6. 6. Backup und Notfallfähigkeit prüfen
7. 7. Architekturentscheidungen ableiten
8. 8. Roadmap erstellen

Ergebnisdokumente

• Ist-Architektur
• Zielarchitektur
• Zonenmodell
• Datenflussmatrix
• Firewall-Regelmatrix
• VLAN/IP-Plan
• Backup- und DR-Konzept
• Monitoring-Konzept
• Umsetzungsroadmap

Entscheidungslogik

Jede technische Entscheidung sollte auf einem dokumentierten Input beruhen. Beispiel: Eine DMZ wird nicht gebaut, „weil man das so macht“, sondern weil öffentliche Dienste vorhanden sind, die vom internen Netz getrennt werden müssen.

22. Praxisbeispiel: 50 Mitarbeitende

Ein Unternehmen mit 50 Mitarbeitenden benötigt meistens keine überdimensionierte Enterprise-Architektur. Es braucht aber klare Mindeststandards.

Zielbild

• Business Firewall mit VLANs, VPN und IDS/IPS
• getrenntes Gäste-WLAN
• VLANs für Clients, Server, Management, Guest und IoT
• Microsoft 365 oder Google Workspace mit MFA
• EDR auf allen Clients
• NAS oder Cloud-Backup
• Restore-Test
• Dokumentation
• externer IT-Dienstleister mit zeitlich begrenztem Zugriff

Prioritäten

1. 1. MFA
2. 2. Backup und Restore-Test
3. 3. Gäste-WLAN trennen
4. 4. lokale Adminrechte reduzieren
5. 5. EDR ausrollen
6. 6. Firewall-Regeln dokumentieren
7. 7. Netzwerkplan erstellen

23. Praxisbeispiel: 500 Mitarbeitende

Ein Unternehmen mit 500 Mitarbeitenden und mehreren Standorten braucht stärker strukturierte Infrastruktur.

Zielbild

• redundante Firewalls
• zwei Provider
• Core Switches redundant
• DMZ mit WAF/Reverse Proxy
• VLANs für Client, Server, App, DB, Admin, Backup, Guest und IoT
• SD-WAN für Standorte
• Cloud Landing Zone
• SIEM oder Managed SOC
• PAM für Adminzugriff
• immutable Backup
• DR-Runbook
• Change Management

Prioritäten

1. 1. Segmentierung
2. 2. Adminschutz
3. 3. Monitoring und SIEM
4. 4. Backup-Härtung
5. 5. Cloud-Governance
6. 6. Standort-Redundanz
7. 7. Incident Response

24. Praxisbeispiel: Produktion und IT/OT

Produktionsunternehmen haben neben Büro-IT auch OT-Systeme wie SCADA, HMI, PLCs, Roboter, Sensoren und Produktionslinien. Diese Systeme dürfen nicht wie normale Büro-IT behandelt werden.

Prinzipien

• IT und OT trennen
• kontrollierte Übergänge über OT-DMZ
• keine direkten Office-Clients auf PLCs
• Patchfenster mit Produktion abstimmen
• OT-Monitoring passiv betreiben
• Remote-Zugriffe streng kontrollieren
• Backup von Steuerungsprogrammen und Konfigurationen

Typische Zonen

25. Roadmap: Umsetzung in 12 Monaten

Eine Infrastruktur wird selten in einem Schritt modernisiert. Besser ist eine Roadmap nach Risiko und Abhängigkeiten.

0–30 Tage

• Asset Inventory starten
• MFA aktivieren
• Backup prüfen
• Restore-Test durchführen
• wichtigste Firewall-Regeln exportieren
• Netzwerkplan skizzieren

31–60 Tage

• VLAN/IP-Plan erstellen
• Adminrechte prüfen
• EDR-Abdeckung prüfen
• Gäste-WLAN trennen
• Dienstleisterzugänge prüfen

61–90 Tage

• DMZ-Konzept
• Adminnetz
• zentrale Logs
• Monitoring-Basis
• Firewall-Regelreview

3–6 Monate

• PAM oder Bastion
• SIEM oder Managed SOC
• Immutable Backup
• Cloud Security Review
• Patchmanagement standardisieren

6–12 Monate

• Zero Trust / ZTNA
• SD-WAN oder WAN-Optimierung
• Cloud Landing Zone
• DR-Übung
• Reifegradmessung und Audit

26. Großes Glossar

Dieses Glossar enthält zentrale Begriffe aus Netzwerk, Server, Security, Cloud, Backup und Betrieb. Es ist als gemeinsame Sprache für IT, Management und Dienstleister gedacht.