EDV-Umgebungen für kleine und mittelständische Unternehmen

Gewachsene EDV wird teuer, nicht durch Hardware

In Betrieben zwischen 10 und 100 Mitarbeitenden ist die EDV selten geplant entstanden. Ein NAS hier, ein Fileserver dort, ein Domänencontroller aus dem Jahr 2012, Lizenzen an Personen gebunden, Passwörter in einer Tabelle. Das läuft jahrelang erstaunlich gut - bis eine dieser Fragen beantwortet werden muss:

• Wie lange dauert es, bis nach einem Ausfall alles wieder läuft?
• Wer hat Zugriff auf welche Freigabe, und wo ist das dokumentiert?
• Was ist in der Nacht passiert, in der etwas passiert ist?
• Wer betreut das System, wenn der bisherige Dienstleister nicht mehr erreichbar ist?

Die folgende Beispielkonfiguration beschreibt, wie ich eine solche Umgebung aufbaue. Die Dimensionen sind ein Beispiel und werden je Kunde angepasst; die Bausteine sind einzeln nutzbar.

Ausgangslage: 30 Mitarbeitende, zwei Standorte

Angenommen werden rund 30 Arbeitsplätze an zwei Standorten, ein Domänencontroller, ein Fileserver, ein paar Fachanwendungen, kein eigener IT-Mitarbeiter. Typische Befunde in dieser Größenordnung:

• Identitäten und Berechtigungen sind gewachsen, Offboarding läuft über Zuruf.
• Die Sicherung läuft, aber die Wiederherstellung wurde nie geprüft.
• Das Wissen über den Aufbau steckt in den Köpfen von ein bis zwei Personen.
• Es gibt keine Protokolle, also auch keinen Nachweis, wenn etwas war.
• Kunden, Versicherungen und Datenschutz verlangen Auskünfte, die niemand belegen kann.

Die Beispielkonfiguration im Überblick

Aufbau

Die Bausteine im Detail

Virtualisierung: Proxmox VE

Drei Knoten mit lokalem ZFS und Replikation, alternativ Ceph bei größerem Ausbau. Virtuelle Maschinen und Container liegen auf dem Cluster, damit ein Knoten ohne Unterbrechung gewartet werden kann. Ein Cluster braucht Quorum: bei zwei Knoten gehört ein QDevice dazu, sonst verliert der Cluster nach dem Ausfall eines Knotens das Quorum.

Identität und Richtlinien: Samba AD DC mit SAMADCON

Zwei Domänencontroller, verteilt auf beide Standorte, repliziert über die Standortkopplung. DNS ist integriert. Windows-Clients treten normal bei, Linux-Clients über SSSD und realmd. Ein Hinweis aus der Praxis: Samba repliziert SYSVOL nicht selbst, das erledigt ein rsync- oder osync-Lauf per Timer.

Neu in der Verwaltung ist SAMADCON: eine browsergestützte Konsole für Benutzer, Gruppen, Computer, DNS und - das ist der eigentliche Gewinn - für Gruppenrichtlinien inklusive GPO-Editor. Bisher brauchte es dafür einen Windows-Client mit RSAT. SAMADCON läuft als Container, spricht LDAPS, Kerberos und SMB, ist unter AGPL-3.0 veröffentlicht und wird in Deutschland entwickelt.

Ehrliche Einordnung: Das Projekt ist jung. Ich setze es zunächst parallel zu den gewohnten Werkzeugen ein, teste Änderungen an einer Test-OU und halte den Weg über samba-tool offen. Wer GPOs ausschließlich über SAMADCON pflegt, sollte das bewusst entscheiden.

Dateien und Freigaben

Samba-Fileserver auf ZFS, Berechtigungen aus dem AD, Quota je Abteilung, Papierkorb und Shadow Copies für die Eigenrettung durch die Anwender. Snapshots laufen zeitgesteuert und werden auf einen zweiten Standort übertragen.

Netz und Firewall: OPNsense mit Zenarmor

Segmentierung in Server, Arbeitsplätze, Gäste, Verwaltung und Drucker. Das Regelwerk wird dokumentiert, nicht nur konfiguriert - sonst ist es beim nächsten Wechsel niemandem erklärbar. Für Layer-7-Funktionen kommt Zenarmor als Plugin hinzu: Anwendungskontrolle, Webfilter, TLS-Inspection, optional mit AD-Anbindung für benutzerbezogene Regeln. Die kostenlose Edition ist beschränkt (ein Standort, ein Gateway), für mehrere Standorte ist eine Lizenz einzuplanen. Wichtig bei der Inbetriebnahme: Hardware-Offloading muss für netmap abgeschaltet werden.

Namensauflösung und Werbeblocker

Unbound auf der Firewall mit Blocklisten, alternativ AdGuard Home. Geblockt werden Werbung, Tracking, Telemetrie und bekannte Schad-Domains, mit Protokoll pro Client. Das ist kein Sicherheitskonzept, aber es reduziert Angriffsfläche und Traffic spürbar.

Zertifikate ohne Portfreigabe

Der Reverse Proxy (nginx) stellt interne Dienste im LAN und über VPN bereit: Nextcloud, Ticketsystem, Monitoring, SAMADCON. Die Zertifikate kommen von einer öffentlichen CA per ACME-Challenge über DNS-01. Damit ist kein Port 80 oder 443 von außen erreichbar - die Validierung läuft über einen TXT-Record in der DNS-Zone. Auch Wildcard-Zertifikate sind so möglich, und die Anwender sehen keine Zertifikatswarnungen mehr.

Zwei Voraussetzungen, die man kennen muss: Die Zone muss öffentlich delegiert sein, die A-Records dürfen dabei auf private Adressen zeigen (Split-DNS). Und Zertifikate landen in den Certificate-Transparency-Logs, interne Hostnamen werden also veröffentlicht - entweder bewusst nichtssagend benennen oder für rein interne Namen eine eigene CA einsetzen.

VPN: Außenstellen, Cloud und Homeoffice

Standorte, Cloud-Umgebungen und Homeoffice werden über VPN angebunden, nicht über einzelne Portfreigaben. Drei Werkzeuge, je nach Anforderung:

• WireGuard für die Standortkopplung: schlank, schnell, aufeinander abgestimmte Routing- und Firewall-Regeln, gut für dauerhafte Verbindungen.
• OpenVPN, wo mobile Zugänge oder Fremdprodukte es verlangen: etabliert, überall verfügbar, etwas langsamer, aber mit TLS-basiertem Zertifikatsmanagement und feingranularer Konfiguration.
• Netbird als Overlay, wenn viele verteilte Zugänge entstehen: baut auf WireGuard auf, verwaltet Peers zentral und holt sich die Zugriffsregeln aus einer zentralen Steuerung, statt sie auf jeder Firewall einzeln zu pflegen.

Damit ist das Heimnetz eines Mitarbeitenden kein Loch im Perimeter, sondern ein gemanagter Anschluss mit definierten Routen. Für Cloud-Anbindungen gilt dasselbe: die definierten Routen laufen über die Firewall, statt dass Instanzen einzeln aus dem Internet erreichbar sein müssen.

Protokolle und Nachweise: Wazuh und Graylog

Wazuh-Agenten laufen auf Servern und Arbeitsplätzen: Dateiintegrität, Schwachstellen, Windows-Ereignisprotokolle, Policy-Prüfungen. Graylog sammelt alle Protokolle zentral über Syslog, GELF und Beats, mit Index-Sets für Rotation und Aufbewahrung. Die Aufbewahrungsdauer wird je Index-Set festgelegt, Langzeitablage erfolgt in kaltem Speicher - der Funktionsumfang ist je Edition zu prüfen.

Zum Thema NIS2: Die Richtlinie nennt keine konkrete Aufbewahrungsdauer für Protokolle, gefordert sind angemessene Maßnahmen und Nachweisfähigkeit. Die Frist wird deshalb im Projekt mit dem Kunden und seinem Rechtsberater festgelegt, üblich sind zwölf bis vierundzwanzig Monate für sicherheitsrelevante Protokolle.

Endgeräte: Tactical RMM

Tactical RMM bringt einen Agenten auf Arbeitsplätze und Server: Inventar, Patchstand, Checks mit Alarmierung, Skripte, Remote-Shell und Fernsteuerung über die eingebundene MeshCentral-Instanz. Self-hosted, die Daten bleiben im eigenen Netz. Einschränkung, die man vorher wissen sollte: Linux-Agenten sind in der Community-Edition eingeschränkt und Teil des Sponsoring-Modells - bei überwiegend Linux-Clients vorher prüfen.

Datensicherung: PBS, UrBackup, Veeam

• Proxmox Backup Server sichert VMs und Container inkrementell, dedupliziert und verschlüsselt. Zusätzlich ein Sync auf den zweiten Standort oder auf Band.
• UrBackup sichert Arbeitsplätze als Image und als Dateisicherung, servergesteuert, mit Rücksicherung über ein Notfallmedium.
• Veeam kommt dort zum Einsatz, wo Windows-Workloads oder eine bestehende Veeam-Installation es vorgeben.

Die Regel bleibt 3-2-1 mit einem Ziel, das offline oder unveränderlich ist. Und: Ein Wiederherstellungstest pro Jahr mit Protokoll ist Teil des Auftrags, nicht eine Option.

Monitoring

Checkmk überwacht Server, Dienste, Hardware und Zertifikatslaufzeiten, mit Alarmierung per Mail und SMS. Damit werden Störungen erkannt, bevor sie jemand bemerkt und meldet - der Anruf des Kunden ist der Worst Case, nicht der Auslöser. Schwellwerte werden je Kunde festgelegt, damit nicht jeder volle Snapshot nachts jemanden weckt. Wazuh und Graylog liefern die Ereignisse dazu.

Dokumentation, die auch im Krisenfall hilft

• Inventar als Datenquelle: NetBox, gefüllt über die Proxmox-API und Ansible-Fakten, damit die Dokumentation nicht veraltet.
• Runbooks als Markdown im Git, gebaut zu statischem HTML mit MkDocs.
• Export als offline lesbares Paket auf dem NAS und auf einem verschlüsselten Datenträger im Tresor.
• Ein Notfallblatt auf Papier: Ansprechpartner, Wiederanlaufreihenfolge, Verweis auf den Passwortsafe, Hotlines von Provider und Herstellern.

Der letzte Punkt klingt altmodisch und ist der wichtigste. Wenn AD, DNS und der Doku-Server gleichzeitig weg sind, hilft nur das, was ohne Netz verfügbar ist.

Notfallfähigkeit

Wiederanlaufreihenfolge festlegen: Netz, DNS, Domänencontroller, Dateien, Fachanwendungen. Dazu RTO und RPO je System, einmal im Jahr eine Übung mit Protokoll. Danach weiß jeder, wie lange es wirklich dauert.

Betrieb

Die Umgebung wird pauschal pro Monat betreut: Monitoring, Patchmanagement, Überwachung der Sicherungen, Reaktion auf Störungen mit vereinbarten Zeiten, Änderungen über Tickets und ein Quartalsbericht mit offenen Punkten. Das passt zu Betrieben, die keine eigene IT-Abteilung haben und trotzdem belastbare Zusagen brauchen.

NIS2 und Lieferkette

NIS2 adressiert Einrichtungen ab 50 Mitarbeitenden oder 10 Millionen Euro Umsatz in den betroffenen Sektoren; kleinere Betriebe sind meist nicht direkt betroffen. Die Anforderungen kommen trotzdem an: über Kunden, die selbst betroffen sind, über Ausschreibungen und über Fragebögen zur Informationssicherheit. Wer Protokolle, Inventar und Wiederherstellungsnachweise vorlegen kann, beantwortet diese Fragebögen in einer Stunde statt in zwei Wochen.

Einstieg

Drei Wege, je nach Ausgangslage:

• Bestandsaufnahme mit Notfallblatt: Aufbau dokumentieren, Abhängigkeiten und Lücken benennen.
• Sicherheit und Sicherung: Backup prüfen, Rücksicherung testen, Protokollierung und Firewall nachziehen.
• Vollbetrieb: die oben beschriebene Umgebung aufbauen und betreuen.

Für ein Gespräch über die eigene Umgebung sprechen Sie mich gerne an.