Zum Inhalt springen
MSP-Konzept
Esc
↑↓navigate↵open⌘Jpreview
Auf dieser Seite

Lesen des Konzepts

Dieses Konzept beschreibt den verbindlichen Aufbau, die Standards und die Betriebsvorgaben der Infrastruktur. Diese Startseite erklärt, wie das Konzept aufgebaut ist, wie die Standards zu lesen sind und wie man sich innerhalb der Dokumentation orientiert.

Zweck des Konzepts

Aufbau der Dokumentation

Das Konzept ist in Kapitel gegliedert. Jedes Kapitel bündelt thematisch zusammengehörige Seiten:

  • Kapitel 1: Konzeptstrategie

    • 1.1 Strategie: Beschreibt das GitOps-Automatisierungskonzept mit Forgejo, OpenTofu und Ansible-Pull inklusive CMDB-Deploy und Drift-Management.
    • 1.2 Workflow: Definiert den standardisierten Lebenszyklus einer Infrastrukturkomponente von der Deklaration in Git bis zum automatisierten Drift-Check.
    • 1.3 Inventarisierung: Beschreibt Netbox als zentrale, dynamisch gepflegte Inventardatenbank für den Ist-Zustand der Infrastruktur.
    • 1.4 Secretsmanagement: Legt fest, wie OpenBAO als zentraler Geheimnis-Tresor für Zugangsdaten, Identitäten und interne PKI eingesetzt wird.
    • 1.5 No Microslop: Begründet den verbindlichen Verzicht auf Microsoft-Produkte zugunsten offener, automatisierbarer Alternativen.
    • 1.6 Backup und Restore: Definiert Sicherungsklassen, Mindeststandards, Schutzmaßnahmen und die verbindliche Reihenfolge zur Wiederherstellung nach einem Totalausfall.
    • 1.7 Patch- und Updatestrategie: Legt die produktneutrale Update-Reihenfolge, beschleunigte Sicherheitsupdates und Wartungsfenster-Vorgaben fest, abgegrenzt vom Drift-Management.
    • 1.8 Compliance & Audit: Bündelt den Nachweiskatalog aus bestehenden Quellen, den Prüfungsschwerpunkt Custom-Scripts sowie Access Reviews und Audit-Nachweiserstellung.

  • Kapitel 2: Netzwerk-Geräte

    • 2.1 Router: Legt Abhängigkeiten und Hardware-Mindeststandards (Ports, CPU, RAM, Failover, WLAN) für den Router fest.
    • 2.2 Modem: Definiert Anforderungen an Modems im Bridge-Mode inklusive Zugangstechnologien, WAN-Failover und Sicherheitsvorgaben.
    • 2.3 Managed Switch: Beschreibt Rolle, Mindeststandards und Port-Zuweisungsprinzipien (Trunk/Access) von Managed Switches in der VLAN-Architektur.
    • 2.4 Access Point: Regelt die Rolle des Access Points als reinen WLAN-Zugangspunkt mit striktem SSID-zu-VLAN-Mapping ohne eigene Routing-Funktion.
    • 2.5 WLAN Übersicht: Definiert hardwareunabhängige Mindeststandards für Funkstandards, Verschlüsselung und Kanalplanung im WLAN.
    • 2.6 Dedizierte Firewall: Beschreibt die dedizierte Enterprise-Firewall als zentrale Durchsetzungsinstanz für Zonentrennung, Default-Deny und Sicherheitsfunktionen.
    • 2.7 OOBM: Definiert Out-of-Band-Management als vom Produktivpfad unabhängigen Notfallzugang zu Infrastrukturkomponenten.
    • 2.8 Physische Infrastruktur: Regelt Racks, strukturierte Verkabelung, Klimatisierung, Erdung und physische Sicherheit als Fundament der Infrastruktur.
    • 2.9 USV: Definiert USV-Bauarten, Dimensionierung, Stromverteilung und das automatisierte Shutdown-Konzept bei Stromausfall.

  • Kapitel 3: Netzwerk-Grundlagen

    • 3.1 VLAN-Definitionen: Legt den verbindlichen Katalog aller VLAN-IDs, Kurznamen und deren Zweck als Referenzquelle für die gesamte Infrastruktur fest.
    • 3.2 IP-Adressierungsplan: Übersetzt jede VLAN-ID in konkrete IPv4- und IPv6-Netze samt Gateway- und Adressvergaberegeln.
    • 3.3 Zonenmodell: Definiert Vertrauensstufen der Sicherheitszonen und die verbindlichen Kommunikationsregeln zwischen ihnen.
    • 3.4 Namenskonventionen: Legt den verbindlichen Namensraum für Hostnamen, Domain-Struktur und Firewall-Zonenobjekte der Infrastruktur fest.
    • 3.5 VPN & Remote-Access: Definiert Regeln für Remote-Access- und Site-to-Site-VPN inklusive Authentifizierung und Terminierung am Perimeter.
    • 3.6 Egress- und Internetfilter: Legt die Egress-Policy je Sicherheitszone, den verbindlichen Forward-Proxy für Web-/Content-Filterung und die DNS-basierte Filterung fest.
    • 3.7 Portkonventionen: Legt fest, für welche exponierten Dienste vom Standardport abgewichen wird, nach welchem Prinzip der abweichende Port vergeben wird und wo diese Zuordnung dokumentiert ist.

  • Kapitel 4: Netzwerk-Dienste

    • 4.1 DNS: Regelt Split-Horizon-DNS, Resolver-/Server-Rollen, Zonenstruktur und den Auflösungspfad der internen Namensauflösung.
    • 4.2 DHCP: Definiert die Relay-Architektur, Optionsverteilung, Redundanz und Lease-Verwaltung der dynamischen IP-Adressvergabe.
    • 4.3 NTP: Legt die hierarchische Zeitsynchronisation, Serverplatzierung und Absicherung gegen manipulierte Zeitquellen fest.
    • 4.4 PKI: Legt die zweistufige CA-Hierarchie, Zertifikatsarten samt Laufzeiten und die Vertrauensverteilung auf verwaltete Endgeräte fest.
    • 4.5 IAM: Definiert zentrales Identity- und Access-Management mit SSO, Gruppenrechten und verpflichtender Multi-Faktor-Authentifizierung.
    • 4.6 Logging: Regelt zentrale, unveränderliche Protokollierung aller sicherheits- und betriebsrelevanten Ereignisse samt Aufbewahrungsfristen.
    • 4.7 Monitoring: Regelt die aktive Metrikerfassung, Schwellwertauswertung mit Eskalationsstufen und Dashboards, getrennt von Alarmzustellung und Logging.

  • Kapitel 5: Virtualisierung

    • 5.1 Server-Hardware: Definiert Mindestanforderungen an physische Hypervisor-Hardware für Enterprise-Rackserver, HomeLab-Mini-PCs und gemietete Root-Server.
    • 5.2 Hypervisor: Legt Proxmox VE als verbindliche Virtualisierungssoftware samt Netzwerk, Storage, Vorlagen, API-Zugriff und Cluster-Grundlagen fest.
    • 5.3 Storage-Konzept: Legt die Wahl zwischen lokalem, hyperkonvergentem (Ceph) und externem Storage samt Redundanz- und Kapazitätsplanung fest.
    • 5.4 High Availability: Legt Quorum, Mindest-Clustergröße, HA-Failover, Fencing und Anti-Affinity für redundante Dienstpaare fest.
    • 5.5 Container-Runtime: Legt Docker als verbindliche Container-Runtime samt Deployment-Modell, Image-Versionierung, Netzwerk und Datenhaltung fest.

  • Kapitel 6: Automatisierung

    • 6.1 GitOps-Prinzipien: Legt die produktneutralen Engineering-Regeln für jedes Repository fest: Deklarativ vor imperativ, Review- und Freigabepflicht, Branch-Strategie und die Übersicht der Repository-Typen.
    • 6.2 OpenTofu-Standards: Legt Repository- und Modulstruktur, Zustandsverwaltung über die Forgejo-Package-Registry sowie die Workspace-Trennung nach Standort, Betriebsform und Stage fest.
    • 6.3 Ansible-Pull & Playbook-Struktur: Legt Installation und Taktung von ansible-pull, den Aufbau von /etc/cmdb-deploy, den Playbook-Einstiegspunkt sowie Protokollierung und Fehlerbehandlung eines Pull-Laufs fest.
    • 6.4 CI/CD-Pipeline-Design: Legt das Stufenmodell (Lint, Plan/Check, Review, Apply) jeder Pipeline sowie das Freigabe-Gate über Atlantis in der Enterprise-Umgebung fest.

  • Kapitel 7: Software-Stack

    • 7.1 Netzwerkdienste
    • 7.2 Identity, Security & Ingress
      • 7.2.1 Keycloak: Platzhalterseite, Inhalt folgt.
      • 7.2.2.1 Installation: Systembenutzer, Verifikation der Binary per Checksumme und GPG-Signatur, systemd-Dienst sowie die initiale Versiegelung (Initialisierung/Unsealing).
      • 7.2.2.2 Konfiguration: Auth-Method AppRole, Secrets-Engines (KV, PKI) sowie Audit-Logging gemäß 1.4.1 Rolle von OpenBAO.
      • 7.2.2.3 Update: Ablauf für ein OpenBAO-Release-Update inklusive Sicherung und erneutem Unsealing nach dem Neustart.
      • 7.2.3 Traefik: Platzhalterseite, Inhalt folgt.
    • 7.3 IaC & Orchestrierung
      • 7.3.1.1 Installation: Systempakete, PostgreSQL-Datenbank sowie die NetBox-Binary und der zugehörige Systembenutzer.
      • 7.3.1.2 Konfiguration: Pflicht-Attribute für die FQDN-Generierung (Site, Tenant, environment, stage), configuration.py, Custom Fields sowie die systemd-Dienste.
      • 7.3.1.3 Update: Ablauf für ein NetBox-Release-Update inklusive Minor- und Major-Updates der zugrunde liegenden PostgreSQL-Instanz.
      • 7.3.1.4 Organisation: Konventionen für das gesamte Organisation-Menü: Regionen, Standortgruppen, Standorte und Lokationen, Mandanten und Mandantengruppen sowie Kontakte, Kontaktgruppen, Kontaktrollen und Kontaktzuweisungen.
      • 7.3.1.5 Racks: Konventionen für Racktypen, Racks, Rackrollen, Rackreservierungen und die Rackübersicht.
      • 7.3.1.6 Geräte: Konventionen für Geräte, Module, Geräterollen, Betriebssysteme, Gerätetypen, Hersteller, Gerätekomponenten und MAC-Adressen.
      • 7.3.1.7 Verbindungen: Konventionen für Kabel, Kabelbündel und Funkverbindungen, inklusive Labeling nach DIN EN 50174-1.
      • 7.3.1.8 Funknetze: SSID- und WLAN-Gruppen-Konventionen, löst das bisher offene SSID-VLAN-Mapping aus 2.1 und 2.5 auf.
      • 7.3.1.9 IPAM: Bildet den VLAN-Katalog aus 3.1 und den IP-Adressierungsplan aus 3.2 als Netbox-Objekte ab: Aggregate, Prefixe, IP-Bereiche/-Adressen, VLANs/VLAN-Gruppen, VRFs, FHRP-Gruppen und Anwendungsdienste.
      • 7.3.1.10 VPN: Bildet die in 3.5 VPN & Remote-Access festgelegten Kategorien als Netbox-Objekte ab: Tunnel, Tunnelgruppen, Tunnelabschlusspunkte sowie IKE-/IPSec-Struktur.
      • 7.3.1.11 Virtualisierung: Konventionen für Cluster, Clustertypen/-gruppen, virtuelle Maschinen, Schnittstellen, virtuelle Festplatten und VM-Typen.
      • 7.3.2 OpenTofu: Platzhalterseite, Inhalt folgt.
      • 7.3.3 Ansible: Legt den Zuschnitt von ansible_role_*-Repositories fest, das Drop-in-Muster für geteilte Infrastruktur, Rollen-Abhängigkeiten über meta/main.yml, Port-Dokumentation für die Firewall-Automatisierung sowie die Rollen-Zuweisung über die Node Types eines Hosts.
      • 7.3.4 Loom: Beschreibt die Django-basierte CMDB Loom, die anhand von Manifest und Vorlagen aus ansible_role_*-Repositories sowie den Node Types aus Netbox die initiale Host-Konfiguration erzeugt und Vorlagen-Änderungen zum Abgleich bereitstellt.
    • 7.4 CI/CD & Code Management
      • 7.4.1.1 Installation: Systempakete, PostgreSQL-Datenbank, PGP-Verifikation der Binary sowie Systembenutzer und systemd-Dienst für Forgejo.
      • 7.4.1.2 Update: Ablauf für ein Forgejo-Release-Update inklusive Backup, Binary-Austausch und PostgreSQL-Updates.
      • 7.4.2.1 Installation: Docker, PGP-Verifikation, Runner-Binary, Systembenutzer, Konfiguration, Registrierung und systemd-Dienst für den Forgejo-Runner.
      • 7.4.2.2 Beispiel-Workflows: Ansible- und OpenTofu-Workflow als Anwendungsbeispiele für das Label debian-latest.
      • 7.4.3.1 Installation: Aptly-Paketquelle, Systembenutzer, Signierschlüssel für veröffentlichte Repositories, aptly.conf sowie der systemd-Dienst der REST-API.
      • 7.4.3.2 Konfiguration: Debian- und Ubuntu-Mirror, lokales Repository für eigene Pakete, Snapshot- und Publish-Workflow sowie die hostbasierte Bereitstellung dreier Repositories über Traefik.
      • 7.4.3.3 Update: Laufende Aktualisierung von Mirrors und Snapshots getrennt vom Versionsupdate der Aptly-Software selbst.
    • 7.5 Monitoring & Logging
    • 7.6 Backup & Disaster Recovery
      • 7.6.1.1 Borg Backup: Beschreibt die pull-basierte, verschlüsselte Sicherung der Klassen A/B mit BorgBackup samt Aufbewahrung, Integritätsprüfung und Restore-Verfahren.
      • 7.6.1.2 Proxmox Backup Server: Beschreibt die image-basierte VM-/LXC-Sicherung mit PBS samt Datastore-Struktur, Privilegienmodell, Verschlüsselung und pull-basierter Auslagerung über Sync-Jobs.
    • 7.7 Kommunikation
      • 7.7.1 Mattermost: Definiert Mattermost als selbstgehostete Chat-Plattform mit SSO-Anmeldung, Kanalstruktur und Trennung von automatisierten Meldungen.
      • 7.7.2 ntfy: Beschreibt ntfy als eigenständigen, redundanten Dienst zur Zustellung kritischer System-Alarme getrennt vom Chat.
    • 7.8 Office
      • 7.8.1 OnlyOffice: Legt OnlyOffice als selbstgehostete Microsoft-Office-Alternative mit zentral versionierter Konfiguration und Vorlagen fest.
      • 7.8.2 Paperless-ngx: Legt Paperless-ngx als zentrales Dokumentenmanagementsystem mit Dokumentkategorien, Aufbewahrungsfristen und rollenbasiertem Zugriff fest.
    • 7.9 Projektmanagement

  • Kapitel 8: Kunden

    • 8.1 Microsoft Produkte: Grenzt die interne No-Microslop-Strategie gegenüber kundeneigenen Microsoft-Workloads und -Cloud-Diensten ab und regelt Bereitstellung, Zugriff und Absicherung.

  • Kapitel 9: Normen & Standards

    • 9.1 DSGVO: Legt die DSGVO-spezifischen Anforderungen fest: Verantwortlichkeit, Verzeichnis von Verarbeitungstätigkeiten, technische und organisatorische Maßnahmen, Auftragsverarbeitung mit Kunden, Betroffenenrechte und Meldung von Datenschutzverletzungen.

  • Kapitel 10: Projektmanagement

    • 10.1 Projektmethodik: Legt Scrum als gemeinsamen Rahmen aller Projekte fest und regelt, welche Rollen, Artefakte und Zeremonien bei Team- gegenüber Einzelprojekten gelten.
    • 10.2 Projektarten
      • 10.2.1 Kundenprojekte: Beschreibt den allgemeinen Ablauf von Kundenprojekten von Anfrage bis Übergabe in den Regelbetrieb, mit der Migration einer Kundenumgebung als Beispiel.
      • 10.2.2 Entwicklungsprojekt Loom: Regelt die Weiterentwicklung der CMDB Loom als aktuell als Einzelprojekt geführtes internes Entwicklungsprojekt.
      • 10.2.3 Entwicklungsprojekt Ansible: Regelt die Weiterentwicklung der ansible_role_*-Repositories als aktuell als Einzelprojekt geführtes internes Entwicklungsprojekt.
    • 10.3 Projektvorlagen: Stellt werkzeugneutrale Vorlagen für Backlog-Einträge samt Beispiel-Userstories, Sprints, Retrospektiven und den Projektsteckbrief für Kundenprojekte bereit.

  • Kapitel 11: Windows-Infrastruktur

    • 11.1 Strategie und Architektur: Grenzt die zentrale Verwaltung mehrerer Windows-PCs und -Server gegenüber dem Einzelfall aus 8.1 ab und gibt die Komponentenübersicht aus Samba AD DC, WSUS und Tactical RMM.
    • 11.2 Samba AD DC: Legt Samba AD DC als Linux-basierten Verzeichnisdienst je Kunden-Mandant samt Domänenstruktur und Gruppenrichtlinien fest.
    • 11.3 WSUS: Beschreibt WSUS als einzige Windows-Server-Rolle des Kapitels für zentrales Patch-Management, abgebildet auf die Update-Ringe aus 1.7.
    • 11.4 Tactical RMM: Legt Tactical RMM als Endpoint-Management mit Linux-Backend für Inventar, Fernwartung und Softwareverteilung fest.
    • 11.5 Clients und Namenskonventionen: Definiert Hardware-Mindeststandards und das Namensschema für Windows-PCs sowie den Rollout-Ablauf eines neuen Geräts.
    • 11.6 Netzwerk und Abgrenzung: Ordnet die Windows-Infrastruktur eines Mandanten einer eigenen Zone zu und regelt die benötigten Kommunikationsbeziehungen und Egress-Freigaben.
    • 11.7 Betrieb und Onboarding: Ordnet jede Komponente einer Sicherungsklasse zu und beschreibt den vollständigen Onboarding-Ablauf für einen neuen Mandanten.

Nummerierungsschema

Jede Seite und jeder Abschnitt folgt einer durchgängigen, hierarchischen Nummerierung nach dem Muster Kapitel.Seite.Abschnitt.Unterabschnitt:

Diese Nummern sind stabil und dienen als eindeutige Referenz für Querverweise zwischen den Seiten.

Standards richtig lesen

Die Standards unterscheiden grundsätzlich zwischen zwei Umgebungstypen. Jede Anforderung ist mit einem Badge markiert, das angibt, für welche Umgebung sie gilt:

Badge Umgebung Bedeutung
Enterprise Produktiv-/Unternehmensumgebung Höchste Anforderungen an Leistung, Redundanz und Ausfallsicherheit.
HomeLab Test-/Heimlaborumgebung Reduzierte Mindestanforderungen für den privaten oder experimentellen Betrieb.

Wiederkehrende Bausteine

Damit die Seiten einheitlich lesbar bleiben, verwenden sie durchgängig die gleichen Bausteine:

  • Abhängigkeiten-Tabelle → Zu Beginn jeder Komponentenseite (Abschnitt x.y.1) wird aufgelistet, von welchen anderen Themen die Komponente abhängt und wohin verwiesen wird. Hier immer zuerst schauen, um Voraussetzungen zu verstehen.
  • Mindeststandards → Tabellen mit den nicht unterschreitbaren Hardware- bzw. Konfigurationswerten, getrennt nach Umgebung.
  • <Panel>-Hinweisboxen → Enthalten verbindliche Erläuterungen, Ausnahmen oder wichtige Begründungen zu einer Anforderung.

Orientierung & Navigation

Namens- und Domainkonventionen

Standards und HomeLab-Umgebungsdetails

Domains im HomeLab

  • Alle interne Domains erhalten die Endung intra.heyer.systems.
  • Alle externe Domains erhalten die Endung heyer.systems.

Aus Sicherheitsgründen werden hier Domains der HomeLab-Umgebung genannt. Diese müssen für die Produktivumgebung entsprechend angepasst werden.

Einsatz von KI beim Schreiben der Dokumentation

Sollte KI beim schreiben zum Einsatz gekommen sein und von mir noch nicht getestet worden sein, werde ich dies auf jeden Fall wie folgt markieren:

Beim Schreiben dieses Abschnitts wurde KI verwendet

Ansonsten nutze ich auch KI um meinen geschriebenen Text besser auszuformulieren. Dies wird aber immer von mir Lektoriert. Ansonsten wird er auch mit einem Badge versehen.

War diese Seite hilfreich?