Linux-first für KMU · 15–300 Mitarbeitende

Linux-first Büroplattformen. Browser auf, alles da.

Der Arbeitsplatz läuft im Browser: neues Gerät, Login, arbeiten. Weniger Client-Sonderfälle, klarer Betrieb, nachvollziehbare Standards — ohne Lizenzpakete als Grundrauschen.

Erstgespräch Beispiel-Architektur
  • Inhouse oder Hosting in Deutschland
  • Open Source, keine Client-Lizenzen als Standard
  • Von kleinen Systemen bis HA/Cluster – ohne Overengineering

Worum es geht

Betrieb wird planbar, wenn Standards wirklich gelten. Ich liefere keine „Best-of“-Sammlung, sondern eine definierte Plattform mit wenigen Bausteinen und klaren Regeln für Sonderfälle.

Standardisierung

Gleiche Funktionen für alle, weniger Ausnahmen, nachvollziehbare Änderungen.

  • Definierte Rollen/Profiles statt Individual-Desktops
  • Baseline für Clients, Zugriff, Apps und Policies

Wartungsfenster & Changes

Änderungen passieren kontrolliert, messbar und mit Rückfalloption.

  • Change-Log, Freigaben, geplante Slots
  • Updates nach Testpfad, nicht per Zuruf

Backup & Restore

Backups sind nur dann wertvoll, wenn Restore reproduzierbar ist.

  • Backup-Strategie nach Datenklassen
  • Regelmäßige Restore-Proben inkl. Protokoll

Notfall & Runbooks

Im Fehlerfall zählt Zeit: wer macht was, in welcher Reihenfolge.

  • Runbooks für typische Störungen
  • Kontaktkette, Eskalation, klare Verantwortungen

Für wen / für wen nicht

Die Plattform funktioniert gut, wenn Standards akzeptiert werden. Sonderfälle sind möglich — aber bewusst begrenzt und dokumentiert.

Passt gut, wenn …

  • Sie einen Browser-only Arbeitsplatz etablieren möchten
  • IT-Betrieb in Zyklen laufen soll (Wartung, Updates, Review)
  • Kernsysteme kontrolliert bleiben sollen (Inhouse oder DE)
  • Windows nur für klar benannte Spezialfälle gebraucht wird
  • Dokumentation und Zuständigkeiten Teil des Projekts sind

Passt nicht, wenn …

  • jede Person einen individuell gebastelten Desktop erwartet
  • Ad-hoc-Änderungen ohne Prozess dauerhaft Normalzustand sind
  • „Ein Tool pro Team“ wichtiger ist als ein betreibbarer Standard
  • Security- oder Backup-Themen grundsätzlich vertagt werden

Angebot

Vier Bausteine, klar abgegrenzt. So bleibt Aufwand steuerbar, und Sie wissen, was „Betrieb“ konkret bedeutet.

1) Basis: Plattform-Setup

Ergebnis: Betriebsfähige Grundplattform mit dokumentierter Zielarchitektur.

Enthalten:

  • Netzsegmente, Firewall-Regeln, VPN
  • Identity/SSO (z. B. LDAP/Keycloak), Rollen & Gruppen
  • Standard-Apps nach Bedarf (Datei, Office, DMS, Passwörter)

Optionen: HA/Cluster-Variante, separates Management-Netz, Reverse Proxy/DMZ.

2) Betrieb: Updates, Changes, Dokumentation

Ergebnis: Planbarer Betrieb mit festen Wartungsfenstern und Change-Historie.

Enthalten:

  • Patch-Zyklen inkl. Testpfad
  • Dokumentation: Komponenten, Abhängigkeiten, Zugänge
  • Kapazitäts- und Risiko-Review in festem Rhythmus

Optionen: SLA-Varianten, Betriebsübergabe an internes Team, Reporting.

3) Backup & Restore-Betrieb

Ergebnis: Nachweisbare Wiederherstellbarkeit – nicht nur „Backup läuft“.

Enthalten:

  • Backup-Plan nach Systemen und Datenklassen
  • Restore-Proben (stichprobenartig oder geplant), Protokoll
  • Offsite-Strategie (z. B. zweites Ziel, WORM/Immutability je nach Bedarf)

Optionen: Verschlüsselungskonzepte, Air-Gap, Aufbewahrungsregeln.

4) Notfallfähigkeit & Monitoring

Ergebnis: Störungen werden erkannt, eingeordnet und nach Runbook behandelt.

Enthalten:

  • Monitoring (System/Services), Alarmierung, Eskalation
  • Runbooks für Kernfälle (VPN, Storage, Login, App-Ausfall)
  • Notfallplan inkl. Kontaktkette und Wiederanlauf

Optionen: Security-Hardening, regelmäßige Notfall-Übungen.

Beispiel-Architektur

Typisches Zielbild: Browser-only, segmentiert, dokumentiert. Mail/DNS/Web können beim Hoster liegen — die Kernsysteme bleiben kontrolliert.

Typische Regeln

  • Clients sind „dumm“: Browser, VPN, ggf. Device-Management – sonst wenig Angriffsfläche.
  • DMZ ist optional: Reverse Proxy für definierte Dienste, keine Querzugriffe ins App-Segment.
  • Identity ist zentral: Gruppen/Rollen, MFA, SSO – keine lokalen Nutzerinseln.
  • Storage/Backups sind getrennt: Betriebssysteme, Daten, Backup-Ziele, Offsite.
  • Windows nur als Ausnahme: isolierte VM/Remote, eigener Zugriffspfad, kein Standardclient.
  • HA/Cluster nur, wenn es betriebswirtschaftlich begründet ist (RTO/RPO, Abhängigkeiten).

Netzplan (vereinfachtes Beispiel)

Segmentierte Linux-first Büroplattform Clients über Internet oder VPN zur Firewall. Optional DMZ mit Reverse Proxy. App-Segment mit Kollaboration und Diensten. Identity/SSO separat. Storage/Backup und Offsite. Optional HA/Cluster mit Management-Netz. Windows-VM isoliert. Legende Edge / Zugang DMZ (optional) App-Segment Core (Identity/Storage) Management (optional) Ausnahme (Windows) Clients Thin Clients / Browser Laptop / BYOD (Browser) Standard: VPN + SSO Internet / VPN WireGuard / OpenVPN MFA optional OPNsense / Firewall Segmente + Regeln VPN-Termination Logging / IDS optional DMZ (optional) Reverse Proxy WAF optional Nur definierte Dienste App-Segment Nextcloud + Collabora Paperless Vaultwarden App-Updates via Wartungsfenster Identity / SSO LDAP Keycloak Rollen, Gruppen, Policies Zentrale MFA-Option Storage / Backup Storage (z. B. ZFS/NFS) Backup-Server Offsite Zweites Ziel (DE) / Vault Immutability optional HA/Cluster (optional) 2–3 Nodes Nur wenn begründet Management-Netz Out-of-band / Admin Windows-VM (Ausnahme) Remote / isoliert
Vereinfachte Darstellung. Konkrete Segmente, Ports und Rollen werden im Setup schriftlich festgelegt.

Stack (Beispiel)

Der Stack ist austauschbar. Das Prinzip bleibt: wenige Bausteine, dokumentiert, upgradebar, betreibbar.

Debian Nextcloud Collabora Vaultwarden Paperless OPNsense VPN LDAP Keycloak optional: Gitea optional: Samba DC

Ablauf

Vier Schritte, jedes Mal gleich: schriftlich, nachvollziehbar, mit definierten Abnahmen.

  1. 1) Analyse (schriftlich)

    Deliverable: Ist-Aufnahme, Zielbild, Risiken, Entscheidungspunkte (Hosting, HA, Identity, Datenklassen).

  2. 2) Standard-Setup

    Deliverable: Segmentierung, Identity/SSO, Basisdienste, Betriebsdoku, Update-/Change-Rhythmus.

  3. 3) Migration

    Deliverable: Cutover-Plan mit Fallback, Tests (Login, Daten, Apps), Abnahme nach Checkliste.

  4. 4) Betrieb (Rhythmus)

    Deliverable: Wartungsfenster, Monitoring/Alarmierung, Restore-Proben, regelmäßige Reviews.

Mini-Portfolio (anonymisiert)

Beispiele aus typischen Projekten. Ohne Logos, ohne Fantasiezahlen.

Browser-Workplace für 40–80 Mitarbeitende

  • Nextcloud/Collabora, Identity/SSO, Rollenmodell
  • Segmentierung + VPN, definierte Wartungsfenster
  • Restore-Proben und Betriebsdokumentation

Inhouse-Setup mit externer Mail/DNS

  • Kernsysteme intern, Mail/DNS beim Hoster
  • Reverse Proxy in DMZ für definierte Services
  • Offsite-Backup in Deutschland

HA-Option für kritische Kernfunktionen

  • 2–3 Nodes, getrenntes Management-Netz
  • Monitoring + Runbooks, klare Eskalation
  • Windows-VM nur für Spezialanwendung (isoliert)

FAQ

Kurz und konkret. Wenn etwas nicht passt, sagen wir das früh.

Kontakt

Wenn Sie ein Zielbild im Kopf haben (oder gerade genau das fehlt), starten wir mit einem kurzen Erstgespräch und einer schriftlichen Einordnung.

E-Mail hallo@deine-domain.de

Hinweis: Das ist ein reines Frontend-Mailto. Keine Formulare, keine Datenspeicherung.