IT-Glossar für Managed Services

Debian ist eine seit 1993 entwickelte, rein community-getragene Linux-Distribution — ohne Commercial-Background. Die aktuelle Stable-Version Debian 12 „bookworm" erhält Security-Updates für fünf Jahre. In unseren Managed-Server-Setups ist Debian die häufigste Wahl für Webserver, Datenbank-Systeme und Container-Hosts, weil es konservativ, vorhersehbar und nahezu wartungsfrei ist.

Debian zeichnet sich durch ein besonders rigoroses Paket-Review-Verfahren aus. Pakete laufen durch „unstable" → „testing" → „stable" — das bedeutet für den Produktivbetrieb: selten Überraschungen.

Ubuntu ist eine Debian-basierte Distribution mit Fokus auf Benutzerfreundlichkeit und einem kommerziellen Support-Angebot durch Canonical. Die LTS-Versionen (Long Term Support) erscheinen alle zwei Jahre und werden fünf Jahre lang gepflegt — optional sogar zehn mit „Ubuntu Pro".

In Serverumgebungen bevorzugen wir Ubuntu 24.04 LTS („Noble Numbat"), weil es neuere Kernels und aktuellere Software als Debian Stable bringt, während Stabilität erhalten bleibt. Typische Einsatzfälle: Docker-Hosts, Kubernetes-Worker, GPU-Server für KI-Workloads.

Red Hat Enterprise Linux (RHEL) ist die kommerzielle Enterprise-Linux-Distribution mit bis zu zehn Jahren Support und Zertifizierungen für SAP, Oracle, VMware und viele Enterprise-Anwendungen. Subscription-Modell — pro Host jährlich zu lizenzieren.

Rocky Linux ist der kostenfreie, binär-kompatible Klon von RHEL, entstanden nach dem Strategie-Wechsel von CentOS durch IBM/Red Hat 2020. Für Organisationen, die die Stabilität und Kompatibilität von RHEL brauchen, aber keine Subscription zahlen wollen.

Wir setzen RHEL/Rocky ein für SAP-Landschaften, Oracle-Datenbanken und Kunden mit strengen Compliance-Vorgaben (BSI-Grundschutz, ISO 27001-Audits).

AlmaLinux ist — wie Rocky Linux — ein kostenfreier RHEL-Klon, entwickelt von der AlmaLinux OS Foundation. Unterschied zu Rocky: AlmaLinux hat früher auf das CIQ-Changes-Modell gewechselt und patcht Sicherheitslücken schneller unabhängig von Red Hat. In der Praxis ist die Wahl zwischen Rocky und AlmaLinux Geschmackssache — beide sind RHEL-binär-kompatibel und werden von uns gleichwertig betreut.

Microsoft Windows Server ist die kommerzielle Server-Version von Windows. Aktuelle LTS-Version ist Windows Server 2025 (veröffentlicht November 2024), die Vorgänger 2022 und 2019 werden noch im Extended Support gepflegt. Zentrale Rolle in den meisten Mittelstands-IT-Landschaften für Active Directory, Datei-Freigaben (SMB), Exchange, Microsoft SQL Server und Remote Desktop Services.

Wir betreuen Windows Server inkl. Active Directory, Gruppenrichtlinien, Failover-Cluster, IIS und Hyper-V. Migration von alten 2012/2016-Instanzen auf 2025 ist eines unserer häufigsten Projektfelder.

Active Directory ist Microsofts Verzeichnisdienst für Windows-Netzwerke. Er speichert Benutzer, Computer, Gruppen und Richtlinien zentral und ist damit das Herzstück jedes Windows-basierten Mittelstands-Setups. Gruppenrichtlinien (GPO) sorgen für einheitliche Konfigurationen über hunderte Geräte hinweg.

Aus Security-Sicht ist AD oft das Hauptangriffsziel — Kompromittierung eines Domain-Controllers bedeutet faktisch Kompromittierung des gesamten Netzwerks. Wir empfehlen dringend Tiered-Admin-Modelle, Kerberos-Härtung (RC4 deaktivieren), LAPS für lokale Admin-Passwörter und regelmäßige Pentests speziell gegen AD.

Linux bezeichnet den 1991 von Linus Torvalds begonnenen Betriebssystem-Kern, der heute über 80 % aller Internet-Server antreibt. Er ist keine Distribution, sondern der Kern, den Distributionen wie Debian, Ubuntu, RHEL oder Rocky Linux ergänzen. Alle Android-Smartphones und die meisten Cloud-Workloads laufen auf Linux-Kernels.

Für einen professionellen Managed-Server-Provider wie uns ist Linux-Kompetenz unverzichtbar: Fast jede Spezial-Anwendung (Datenbanken, Container, Monitoring-Stacks, Security-Tools) hat ihre primäre Heimat auf Linux.

Proxmox Virtual Environment (VE) ist eine österreichische Open-Source-Virtualisierungsplattform, die KVM (für VMs) und LXC (für Container) in einem gemeinsamen Management-Interface bündelt. Seit der Broadcom-Übernahme von VMware und den massiven Lizenzänderungen 2024/25 hat Proxmox erheblichen Aufwind: viele unserer Kunden migrieren aktuell von vSphere zu Proxmox VE.

Proxmox unterstützt Cluster aus bis zu 32 Nodes, Ceph-basierte Hyperconverged-Storage, ZFS, Live-Migration und granulare Berechtigungen. Kostenlos nutzbar, Subscription nur für Enterprise-Repository und Support.

VMware vSphere ist seit über 20 Jahren der dominierende Enterprise-Hypervisor. Besteht aus ESXi (dem bare-metal Hypervisor, der direkt auf der Hardware läuft) und vCenter (dem zentralen Management-Server). Nach der Broadcom-Übernahme 2023/24 sind die Lizenzkosten teilweise verfünffacht worden — was viele Mittelständler zum Wechsel auf Alternativen bewegt.

Wir betreiben weiterhin vSphere für Kunden mit großen bestehenden Investments oder spezifischen Abhängigkeiten (z.B. Horizon VDI). Bei Neu-Setups empfehlen wir aber meist Proxmox VE oder Hyper-V.

Hyper-V ist der Microsoft-eigene Hypervisor, der in jeder Windows-Server-Lizenz bereits enthalten ist. Kostenmäßig damit besonders attraktiv für Unternehmen, die ohnehin Windows-Lizenzen betreiben. Integration mit System Center, Active Directory und Azure Arc.

Wir setzen Hyper-V typischerweise in Windows-dominierten Umgebungen ein (z.B. File-Server-Cluster, SQL-Server-Konsolidierung). Für Linux-VMs leisten sich die meisten Kunden allerdings eher Proxmox, weil Hyper-V bei Linux-Workloads nicht immer die beste Performance liefert.

KVM (Kernel-based Virtual Machine) ist der im Linux-Kernel eingebaute Hypervisor seit 2007. Technische Basis für Proxmox VE, Red Hat Virtualization, OpenStack und die meisten Cloud-Provider (u.a. AWS Nitro, Google Cloud Compute).

LXC (Linux Containers) sind System-Container — leichter als VMs, schwerer als Docker-Container. Sie teilen sich den Kernel des Host, sind aber ansonsten isoliert. Ideal für klassische Anwendungen, die nicht als Docker-Container verfügbar sind, aber Ressourcen-Effizienz bringen sollen.

Kubernetes — ursprünglich von Google entwickelt und 2014 als Open-Source-Projekt gespendet — ist heute der De-facto-Standard für Container-Orchestrierung. Es verwaltet Deployments, Skalierung, Load-Balancing, Secrets und Netzwerk über verteilte Container-Cluster. Die deklarative API („wie soll der Zustand sein") trennt „Was will ich?" von „Wie erreiche ich das?".

In der Mittelstands-Realität ist Kubernetes oft Over-Engineering — für weniger als 20 Services lohnt sich der Komplexitäts-Aufschlag meist nicht. Wir empfehlen K8s dann, wenn mehrere Entwicklungs-Teams autonom deployen müssen, oder wenn Stateless-Services elastisch skalieren sollen. On-Premise setzen wir K3s oder RKE2 ein, für minimalere Footprints.

Docker ist seit 2013 die Standard-Container-Runtime auf Linux. Seine Image-Spezifikation (OCI) wurde zum offenen Standard, auf dem auch Kubernetes basiert. Für einfache Container-Setups ohne K8s-Overhead eignet sich Docker Compose — die Datei docker-compose.yml beschreibt mehrere Container + ihre Netzwerke und Volumes.

Docker Swarm war der eingebaute Orchestrator, wurde aber von Kubernetes verdrängt. Wir nutzen Docker vor allem bei Einzel-Host-Setups: Selfhosted-Apps wie Nextcloud, Matomo, Mailcow, oder Reverse-Proxies mit Traefik.

Ein Container ist eine in sich abgeschlossene Laufzeitumgebung für Anwendungen, die sich den Kernel des Hosts teilt, aber ansonsten isoliert ist (eigenes Dateisystem, eigene Netzwerk-Namespace, eigene Prozess-IDs). Container sind schneller zu starten und ressourcen-effizienter als VMs — dafür sind sie nicht ganz so stark isoliert (Shared-Kernel-Risiko).

Container sind das Fundament moderner Cloud-Native-Architekturen, werden aber zunehmend auch im klassischen Betrieb eingesetzt, um Deployment-Komplexität zu reduzieren. Wichtig: Container-Images müssen regelmäßig aktualisiert werden — „ich habe einen Container vor 2 Jahren gebaut" ist der Anfang eines Security-Incidents.

XCP-ng ist eine Community-Fortsetzung von Citrix XenServer, nachdem Citrix 2018 das Open-Source-Model aufgegeben hat. Nutzt den Xen-Hypervisor. In der Praxis weniger verbreitet als Proxmox, aber für spezifische Anwendungsfälle (z.B. XenCenter-vertraute Admins, spezifische Enterprise-Features) relevant.

Verschiebt eine laufende VM ohne Ausfallzeit von einem Cluster-Knoten auf einen anderen: Der RAM-Zustand wird iterativ übertragen, beim finalen Umschalten steht die VM für Millisekunden still — Anwendungen und Nutzer merken davon nichts. Unter VMware heißt das vMotion, unter Proxmox schlicht Live Migration; technisch leistet KVM/QEMU dasselbe.

Entscheidend ist der Storage: Liegt die VM-Disk auf Shared Storage (SAN, Ceph), wandert nur der RAM — die Migration dauert Sekunden. Ohne gemeinsamen Speicher muss die Disk mitkopiert werden (Storage-Migration), was je nach Größe Stunden dauern kann. Voraussetzung im Proxmox-Cluster: Quorum und möglichst homogene CPU-Typen (oder ein gemeinsamer CPU-Baseline-Typ).

Damit ein Cluster bei Netzwerkproblemen nicht in zwei Hälften zerfällt, die beide weiterschreiben (Split-Brain), darf nur die Seite mit der Mehrheit der Stimmen aktiv bleiben. Deshalb baut man Cluster mit ungerader Knotenzahl — bei zwei Knoten gibt es im Fehlerfall keine Mehrheit, und der gesamte Cluster friert ein.

In der Praxis: mindestens drei Knoten, oder bei zwei Knoten ein QDevice — ein kleiner Stimmgeber auf einem dritten Gerät (reicht: eine VM oder ein Raspberry-Klasse-Host außerhalb des Clusters). Verliert ein Knoten das Quorum, stoppt Proxmox dort alle HA-Dienste, bis die Mehrheit wiederhergestellt ist. Das ist kein Fehler, sondern der Schutzmechanismus.

Bevor ein HA-Cluster die VMs eines ausgefallenen Knotens auf anderen Hosts neu startet, muss sichergestellt sein, dass der alte Knoten wirklich nicht mehr schreibt — sonst greifen zwei Instanzen auf dieselbe Disk zu und zerstören das Dateisystem. Dieses erzwungene Isolieren heißt Fencing.

Proxmox nutzt dafür standardmäßig einen Hardware-Watchdog: Verliert ein Knoten das Quorum, resettet er sich nach 60 Sekunden selbst (Self-Fencing). Erst danach übernimmt der HA-Manager die VMs. Praxis-Hinweis: Die Failover-Zeit von ~2 Minuten ist gewollt konservativ — wer schnelleres Failover verspricht, opfert Sicherheit gegen Doppel-Mounts.

Proxmox' Antwort auf die vCenter-Frage: Der Datacenter Manager verwaltet mehrere Cluster und Einzelhosts zentral — aggregierte Dashboards, zentrales Update-Management, RBAC mit LDAP/AD/OIDC und als Kernstück die Live-Migration von VMs zwischen verschiedenen Clustern, die ein einzelner Cluster nicht kann. Version 1.0 erschien im Dezember 2025, 1.1 (Mai 2026) ergänzte zentrales Ceph-Monitoring, erste zentrale Snapshot-Verwaltung und Enterprise-Support per Subscription.

Einordnung: Für den einzelnen Cluster bleibt die eingebaute Proxmox-Weboberfläche zuständig — PDM lohnt ab zwei Standorten oder getrennten Clustern (z.B. Produktion/DR). Zentrale Firewall-Verwaltung steht noch auf der Roadmap.

Zero Trust ist ein Sicherheits-Paradigma, das den traditionellen „Burg-mit-Wassergraben"-Ansatz ersetzt. Statt dem internen Netzwerk zu vertrauen und nur außen zu schützen, wird jeder Zugriff — auch intern — authentifiziert, autorisiert und verschlüsselt. Grundlage: „never trust, always verify".

Konkrete Bausteine: MFA überall, kontinuierliche Session-Verifikation, Micro-Segmentierung des Netzes, Identity-zentrische Zugriffskontrolle (nicht mehr IP-basiert), ZTNA statt klassischem VPN. Ein vollständiges Zero-Trust-Modell ist ein Projekt von 2–3 Jahren, aber schon kleine Schritte (MFA, Least-Privilege) liefern große Sicherheits-Gewinne.

Ein SIEM sammelt Logs aus allen Systemen einer Organisation — Server, Firewalls, Active Directory, Anwendungen — und korreliert Events, um Angriffe zu erkennen. Klassische SIEMs waren lange schwer zu betreiben und hatten hohe Lizenzkosten. Open-Source-Alternativen wie Wazuh haben das Feld demokratisiert.

Ohne SIEM haben Sie keine Chance, einen Angriff zu bemerken, der länger als einen Tag dauert — Forensik wird zur Archäologie. Wir betreiben SIEMs sowohl als Dedicated-Installation beim Kunden als auch als geteilte Plattform für kleinere Organisationen.

Ein Security Operations Center ist die Kombination aus Menschen, Tools und Prozessen, die rund um die Uhr die Sicherheit einer Organisation überwacht. Ein SIEM ist das Tool, aber ein SOC ist das Team, das die Alerts tatsächlich analysiert und auf sie reagiert. Eigenes SOC aufzubauen kostet Millionen — Managed SOCs sind der Standard für Mittelstand.

Wazuh ist eine Open-Source-Security-Plattform, die SIEM-, HIDS- (Host-based Intrusion Detection) und XDR-Funktionen kombiniert. Agents auf den Servern sammeln Logs, Dateiintegrität, Vulnerabilities und verhaltensbasierte Events, zentrale Dashboards liefern Korrelationen und Alerts. Kostenfrei verfügbar, kommerzieller Support durch Wazuh Inc. oder Partner wie uns.

Wir haben Wazuh in über 20 Kundenprojekten implementiert und sehen es als beste Option für mittelständische Organisationen, die nicht die Budget-Dimension eines Splunk oder QRadar haben, aber trotzdem echte Security-Visibility brauchen.

Die CIS Benchmarks sind detaillierte Konfigurationsrichtlinien, die das Center for Internet Security (eine US-Non-Profit) für hunderte von Technologien herausgibt — von Windows 10 über Debian 12 bis Kubernetes. Sie konkretisieren „Sicherheit" in umsetzbare, auditierbare Schritte: „SSH Protocol 2 only", „Passwordless sudo disabled", „Fail2Ban aktiv".

Wir nutzen CIS Benchmarks als Checkliste beim Server-Onboarding. Compliance-Auditoren (ISO 27001, BSI) akzeptieren sie als Stand der Technik. Die Benchmarks sind kostenlos in der PDF-Version, das Tooling zur automatisierten Prüfung ist teilweise kostenpflichtig.

Fail2Ban ist ein einfaches, aber wirkungsvolles Python-Tool, das Log-Dateien beobachtet und bei verdächtigen Mustern (z.B. 5 fehlgeschlagene SSH-Logins innerhalb von 2 Minuten) automatisch IP-Adressen per iptables/nftables blockiert. Gehört bei uns zum Standard-Build jedes Linux-Servers — verhindert zuverlässig automatisierte Brute-Force-Angriffe.

Ransomware ist Schadsoftware, die Daten und Systeme verschlüsselt, um Lösegeld zu erpressen. Aktuelle Varianten kombinieren Verschlüsselung mit Datendiebstahl („Double Extortion"): Zahlung wird nicht nur für die Entschlüsselung erpresst, sondern auch dafür, dass kopierte Daten nicht veröffentlicht werden.

Einfallswege sind meist ähnlich: Phishing-E-Mails mit Office-Makros, kompromittierte RDP-Zugänge, ungepatchte Exchange- oder VPN-Systeme. Die Verteidigung ist nicht ein einzelnes Tool, sondern eine Kette: MFA, Patching, Segmentierung, EDR, immutable Backups, Awareness-Trainings und ein getesteter Notfallplan.

Ein Penetration Test (Pentest) ist ein kontrollierter Angriff auf Ihre eigene IT durch ein beauftragtes Security-Team. Ziel: konkrete Schwachstellen finden, die reale Angreifer ausnutzen würden. Unterschied zum Vulnerability Scan: ein Pentest kombiniert automatisierte Tools mit manuellen, kreativen Angriffs-Techniken.

Wir empfehlen einen jährlichen Pentest für alle Kunden mit Internet-exponierten Systemen — mindestens für Kronjuwelen (Kundendaten, Patientendaten, Finanzsysteme). NIS2 und die ISO 27001 machen regelmäßige Tests zunehmend zur Pflicht.

EDR (Endpoint Detection & Response) löst klassische Antivirus-Lösungen ab. Statt nur signaturbasiert nach bekannten Schadcodes zu suchen, beobachten EDR-Agenten das tatsächliche Verhalten auf jedem Endpoint — verdächtige Prozessketten, ungewöhnliche PowerShell-Aufrufe, Privilege-Escalation-Muster. Reagiert wird automatisiert: Prozesse killen, Hosts isolieren, Forensik-Snapshots erstellen.

XDR (Extended Detection & Response) erweitert das Konzept um Netzwerk-, E-Mail-, Cloud- und Identity-Telemetrie und korreliert Events kanalübergreifend. Aus einem auffälligen Login + verdächtigem Endpoint-Prozess + ungewöhnlichem Mail-Versand wird ein einziger, zusammenhängender Alarm — statt drei Einzelmeldungen, die niemand verbindet.

Eine SBOM ist eine maschinenlesbare Liste aller Komponenten und Bibliotheken, aus denen eine Software besteht — inklusive Versionen, Lizenzen und Lieferanten. Standards: SPDX und CycloneDX. Im Klartext: das „Zutatenverzeichnis" Ihrer Software-Lieferkette.

Praktischer Nutzen wird sichtbar bei Vorfällen wie Log4Shell (Dezember 2021): wer eine SBOM für sein Portfolio hatte, wusste in Minuten, welche Systeme betroffen waren — alle anderen brauchten Wochen. Mit dem Cyber Resilience Act (CRA) wird die SBOM ab 2027 für viele Produkte zur Pflicht.

VEX ist das Gegenstück zur SBOM: Während die SBOM sagt, welche Komponenten in einem Produkt stecken, dokumentiert ein VEX-Statement maschinenlesbar, ob eine konkrete CVE in genau diesem Produkt ausnutzbar ist — mit Status wie „not affected", „affected", „fixed" oder „under investigation". Gängige Formate: CycloneDX VEX, CSAF und OpenVEX.

In der Praxis ist VEX der Hebel gegen die Alarmflut: Ein SBOM-Scan liefert schnell 200+ CVE-Treffer pro Produkt, von denen die meisten im konkreten Einsatz nicht erreichbar sind. Ohne VEX prüfen Ihre Kunden (oder Sie selbst) jeden Treffer manuell — mit VEX einmal zentral beim Hersteller.

Phishing ist der Versuch, Mitarbeitende per gefälschter E-Mail, SMS oder Website zur Preisgabe von Zugangsdaten oder zum Ausführen von Schadcode zu verleiten. Es ist nach wie vor der häufigste Einstiegsvektor für Ransomware-Angriffe — nicht die technische Lücke, sondern der Klick. Varianten: Spear-Phishing (gezielt auf eine Person), CEO-Fraud (gefälschte Geschäftsführer-Anweisung) und Quishing (QR-Code statt Link, um Filter zu umgehen).

Technische Filter — DMARC, DKIM, Attachment-Sandboxing — fangen einen Großteil ab, aber nie alles. Ehrlich: Der wirksamste Hebel ist die Kombination aus technischer Absicherung, MFA als Schadensbegrenzung bei geklauten Passwörtern und regelmäßigen, simulierten Phishing-Kampagnen mit Auswertung. Einmalige Schulungen verpuffen — die Klickrate sinkt nur bei wiederkehrendem Training.

Secure Boot ist eine UEFI-Funktion, die beim Start nur kryptografisch signierte Bootloader und Kernel zulässt. Damit werden Bootkits und Rootkits ausgebremst, die sich sonst noch vor dem Betriebssystem einnisten. Die Vertrauenskette läuft vom Platform Key über die Key Exchange Keys (KEK) zur Signaturdatenbank (DB) — nicht vertrauenswürdige Hashes landen in der Sperrliste DBX.

2026 ist das praktisch relevant: Die UEFI-CA-Zertifikate von Microsoft aus dem Jahr 2011 laufen aus. Ohne Update auf die neue „UEFI CA 2023" können Geräte ab Mitte 2026 keine aktuell signierten Bootkomponenten oder Secure-Boot-Updates mehr verarbeiten. Wir empfehlen, jetzt den Gerätebestand zu inventarisieren und die Firmware- bzw. Zertifikats-Updates geplant auszurollen — überstürzte Aktionen am Bootpfad führen schnell zu nicht mehr startenden Systemen.

ISO/IEC 27001 ist die international anerkannte Norm für Informationssicherheits-Management-Systeme (ISMS). Sie schreibt keine konkreten Technologien vor, sondern einen risikobasierten Prozess: Assets identifizieren, Risiken bewerten, Maßnahmen ableiten, kontinuierlich verbessern. Die Zertifizierung nach ISO 27001 ist oft Voraussetzung für Großkunden, Versicherungen oder Ausschreibungen.

Die letzte große Revision 2022 („Annex A rework") brachte neue Controls für Cloud-Sicherheit, Threat Intelligence und ICT Readiness. Wir arbeiten nach ISO 27001-Prozessen — ohne eigene Zertifizierung zu sein, können wir Kunden in ihrem Zertifizierungs-Prozess unterstützen.

Der BSI IT-Grundschutz ist die vom Bundesamt für Sicherheit in der Informationstechnik (BSI) herausgegebene Methodik zur Absicherung von IT-Systemen. Konkreter als ISO 27001 — mit detaillierten Bausteinen für typische Szenarien (Webserver, VPN-Gateway, AD-Server, mobile Geräte). Pflicht für Bundesbehörden, Empfehlung für KRITIS-Betreiber.

Grundschutz und ISO 27001 sind gegenseitig kompatibel — eine BSI-Grundschutz-Zertifizierung ist gleichzeitig eine ISO 27001-Zertifizierung. Für mittelständische Organisationen ist der „Basis-Schutz" eine gute Einstiegsvariante ohne das volle Prozess-Overhead.

Die Nachfolgerin der NIS-Richtlinie von 2016. NIS2 trat offiziell am 17. Oktober 2024 in Kraft und erweitert den Scope erheblich: Nicht mehr nur „Betreiber wesentlicher Dienste" sind betroffen, sondern alle mittleren und großen Unternehmen in 18 Sektoren — darunter Energie, Gesundheit, Transport, Lebensmittel, Banken, aber auch IT-Dienstleister, Rechenzentren und Hersteller.

Neue Pflichten: Risikomanagement, Incident-Meldepflicht innerhalb von 24h, Lieferkettensicherheit, Geschäftsführer-Haftung. Die deutsche Umsetzung erfolgte mit einiger Verzögerung — dennoch sind Unternehmen seit 2024 formal in der Pflicht. Bei Verstößen drohen Bußgelder bis 10 Mio. € oder 2 % des Jahresumsatzes.

KRITIS-Betreiber sind Organisationen, deren Ausfall erhebliche gesamtwirtschaftliche oder gesellschaftliche Auswirkungen hätte — Krankenhäuser, Energieversorger, Wasserwerke, Finanzdienstleister. Sie unterliegen besonderen Schutzpflichten nach dem BSI-Gesetz (§8a): angemessene Sicherheitsmaßnahmen, Nachweis alle zwei Jahre, Meldepflicht bei Störungen.

KRITIS und NIS2 überschneiden sich, sind aber nicht deckungsgleich — KRITIS ist ein deutsches Konzept, NIS2 ein europäisches. Viele KRITIS-Betreiber sind gleichzeitig von NIS2 erfasst.

Die Datenschutz-Grundverordnung regelt seit 2018 EU-weit den Umgang mit personenbezogenen Daten. Für Managed-Services relevant: Art. 28 regelt die Auftragsverarbeitung — wann immer wir als Dienstleister auf Server zugreifen, auf denen personenbezogene Daten liegen, wird ein Auftragsverarbeitungsvertrag (AVV) fällig.

Ein professioneller Managed-Server-Vertrag enthält den AVV als Anlage, mit klaren Regeln zu Weisungsgebundenheit, technischen-organisatorischen Maßnahmen (TOM) und Subunternehmer-Nutzung. Wir nutzen ausschließlich deutsche Rechenzentren — das schließt Datentransfer in Nicht-EU-Länder aus.

Der US CLOUD Act (2018) verpflichtet US-Unternehmen, US-Behörden auf Anordnung Zugriff auf Daten zu gewähren — unabhängig davon, wo die Daten gespeichert sind. Ein EU-Rechenzentrum eines US-Hyperscalers schützt also nicht vor dieser Zugriffsmöglichkeit; entscheidend ist die Jurisdiktion des Betreibers, nicht der Serverstandort. Genau deshalb greifen auch „Sovereign Cloud"-Angebote von US-Anbietern hier nur begrenzt.

In der Praxis ist das kein Grund zur Panik, aber ein Grund für eine bewusste Architekturentscheidung: Welche Datenklassen dürfen bei US-Anbietern liegen, welche gehören zu einem europäischen Betreiber oder On-Premise? Die AVV- und Sub-Prozessor-Ketten Ihrer Dienstleister zeigen, wo Sie tatsächlich stehen.

TISAX (Trusted Information Security Assessment Exchange) ist der Branchen-Standard für Informationssicherheit in der Automobil-Industrie. Entwickelt vom Verband ENX auf Basis von ISO 27001, mit Automotive-spezifischen Ergänzungen (z.B. Prototypenschutz). Pflicht für Zulieferer, die mit VW-, BMW-, Mercedes-, Audi-Daten arbeiten.

Wann immer ein IT-Dienstleister auf Systeme zugreift, auf denen personenbezogene Daten liegen, muss ein AVV vorhanden sein. Er regelt, dass der Dienstleister nur auf Weisung des Kunden handelt, welche TOMs (technisch-organisatorische Maßnahmen) gelten und welche Subunternehmer einbezogen werden dürfen.

DORA ist die seit 17. Januar 2025 verbindliche EU-Verordnung für digitale operationelle Resilienz von Finanzunternehmen — Banken, Versicherungen, Zahlungsdienstleister, Krypto-Anbieter und deren kritische IT-Dienstleister. Sie fordert dokumentierte Risikomanagement-Frameworks, Incident-Reporting, regelmäßige Resilienz-Tests (TLPT — Threat-Led Penetration Tests) und ein striktes Lieferketten-Management.

Kern für IT-Dienstleister: Verträge mit Finanzkunden müssen DORA-Klauseln enthalten (Audit-Rechte, Exit-Strategien, Sub-Outsourcing-Transparenz). Aufsichtsbehörden können bei Verstößen Bußgelder bis 1 % des Tagesumsatzes pro Tag verhängen.

Der EU AI Act ist die weltweit erste umfassende Regulierung für Künstliche Intelligenz. Er klassifiziert KI-Systeme nach Risiko: verbotene Praktiken (Social Scoring, biometrische Massenüberwachung — seit Februar 2025 untersagt), Hochrisiko-KI (HR, Kreditvergabe, Medizin, kritische Infrastruktur — strenge Auflagen), begrenztes Risiko (Transparenzpflichten bei Chatbots, Deepfakes) und minimales Risiko (kein Eingriff).

Verpflichtungen für GPAI-Modelle (General-Purpose AI) gelten seit August 2025, die meisten Hochrisiko-Pflichten ab August 2026. Bußgelder bis 35 Mio EUR oder 7 % des weltweiten Jahresumsatzes. Für jedes Unternehmen, das KI im Kundenkontakt oder in Personalentscheidungen einsetzt: jetzt eine Inventur durchführen.

Der Cyber Resilience Act ist Ende 2024 in Kraft getreten und gilt vollständig ab Dezember 2027 — die 24-Stunden-Meldepflicht für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle greift jedoch bereits ab dem 11. September 2026 (Meldung über die ENISA-Plattform ans BSI, auch für Bestandsprodukte). Er verpflichtet Hersteller von Hard- und Software, Sicherheit über den gesamten Produktlebenszyklus zu garantieren: Security-by-Design, automatische Sicherheitsupdates, eine maschinenlesbare SBOM — und mindestens fünf Jahre Update-Versorgung nach Markteinführung.

Betroffen ist faktisch alles mit Netzwerkanschluss — von der Industriesteuerung bis zur SaaS-Anwendung. Für Open-Source-Maintainer gibt es Erleichterungen, aber das CE-Kennzeichen wird ohne CRA-Konformität nicht mehr vergeben.

Eine Cyber-Versicherung deckt finanzielle Schäden aus IT-Vorfällen ab — Lösegeld bei Ransomware, Betriebsunterbrechung, Datenwiederherstellung, Forensik, Rechtskosten und Ansprüche Dritter. Für den Mittelstand ist sie zunehmend Teil des Risikomanagements, weil ein einzelner Vorfall existenzbedrohend werden kann.

Entscheidend: Versicherer zahlen nicht bedingungslos. Vor Vertragsabschluss verlangen sie technische Mindeststandards — flächendeckende MFA, getrennt bzw. offline gehaltene Backups, EDR, ein funktionierendes Patch-Management und Netzsegmentierung. Wer im Schadensfall nicht belegen kann, dass diese Maßnahmen liefen, riskiert Leistungskürzung oder Ablehnung. In der Praxis: Behandeln Sie den Fragebogen des Versicherers als Sicherheits-Checkliste — er bildet recht genau ab, was ohnehin Stand der Technik ist.

Ein SLA definiert präzise, was „Service" bedeutet: Welche Verfügbarkeit (z.B. 99,9 %)? Welche Reaktionszeit bei Incidents (z.B. < 30 Min bei P1)? Welche Öffnungszeiten? Wie werden Messungen durchgeführt? Welche Konsequenzen bei Nicht-Erreichen?

99,9 % Verfügbarkeit klingt gut — heißt aber „bis zu 43 Minuten Ausfall pro Monat". 99,99 % („Four Nines") erlaubt nur 4,3 Minuten. Wir empfehlen, nicht blind 99,9 % zu akzeptieren, sondern zu fragen: „Wie wird Verfügbarkeit gemessen? Was zählt als Ausfall?" — hier versteckt sich oft der Teufel im Detail.

MTTR (Mean Time to Recovery) ist die durchschnittliche Zeit von Störungs-Beginn bis Wiederherstellung. Hauptgröße für die tatsächliche Service-Qualität — eine perfekte Infrastruktur mit schlechter MTTR ist in der Praxis schlechter als eine durchschnittliche mit schneller Recovery.

MTBF (Mean Time Between Failures) misst die mittlere Zeit zwischen Ausfällen — sagt also etwas über Zuverlässigkeit aus. In unserem Fleet-Durchschnitt liegt MTTR bei unter 15 Minuten, MTBF bei über 18 Monaten pro Server.

Uptime kann zwei Dinge bedeuten: (1) die Zeit seit dem letzten Reboot eines einzelnen Servers, (2) die prozentuale Verfügbarkeit eines Service über einen Zeitraum. Linux-Admins lieben hohe Uptimes („487 Tage ohne Reboot!"), aus Security-Sicht ist das aber problematisch — ein Kernel, der 487 Tage nicht neugestartet wurde, hat vermutlich ungepatchte Security-Lücken.

Wir setzen auf regelmäßige, geplante Reboots in Wartungsfenstern statt auf Rekord-Uptimes. Mit Live-Kernel-Patching (kpatch, kernelcare) lassen sich Security-Fixes auch ohne Reboot einspielen.

Patch-Management ist der strukturierte Prozess, Security- und Funktions-Updates zu testen, zu deployen und zu dokumentieren. Ohne Prozess wird das zum Hit-or-miss: entweder wird nie gepatcht (Security-Risiko) oder blind gepatcht (Ausfall-Risiko).

Wir arbeiten mit abgestuftem Rollout: kritische Security-Patches innerhalb von 48h, Standard-Updates monatlich in geplanten Fenstern. Vor jedem Patch: Backup-Verifikation, Pre-Prod-Test (wo möglich), Rollback-Plan.

Incident Response ist der geplante Ablauf bei Störungen: Erkennung → Klassifizierung → Eskalation → Mitigation → Recovery → Post-Mortem. Jede Stufe mit klaren Verantwortlichkeiten, Zeit-Targets und Dokumentations-Pflichten. Ohne Playbook wird jeder Incident zur Improvisation — und damit zur verlängerten Auswirkung.

Ein Post-Mortem ist die strukturierte Nachbesprechung eines Incidents: Was ist wann passiert? Was war die Ursache? Was hat gut funktioniert? Was muss verbessert werden? Entscheidend ist die Blameless-Kultur — nicht „wer ist schuld?", sondern „welches System hat versagt und wie verhindern wir das?". Ohne Post-Mortem-Kultur wiederholt sich jeder Incident.

Ein Runbook ist die dokumentierte Schritt-für-Schritt-Anleitung für wiederkehrende oder kritische Aufgaben — „Was tun, wenn Disk voll?", „Wie Datenbank-Failover durchführen?". Gut geschriebene Runbooks erlauben es, dass auch ein Bereitschafts-Engineer um 3 Uhr morgens den richtigen nächsten Schritt macht. Wir pflegen über 200 Runbooks für unsere Kunden-Systeme.

Ein Backup ist eine Kopie von Daten, aus der im Fehlerfall wiederhergestellt werden kann. Klingt trivial — ist aber in 80 % der Fälle unvollständig. Häufige Fehler: nur File-Backup (keine Applikations-Konsistenz), kein Offsite-Kopie (gleicher Brand zerstört Primary + Backup), keine Restore-Tests, kein Schutz gegen Ransomware-Zerstörung der Backup-Dateien selbst.

Die 3-2-1-Regel ist der Industry-Standard für robuste Backup-Strategien: 3 Kopien der Daten (Original + 2 Backups), 2 verschiedene Speicher-Medien (z.B. Disk + Tape oder Disk + Object Storage), 1 Kopie offsite (physisch entfernt vom Original).

Moderne Erweiterung: 3-2-1-1-0 — zusätzlich 1 Kopie offline/immutable (gegen Ransomware) und 0 Fehler beim letzten Restore-Test. Wir orientieren uns an dieser erweiterten Regel.

Disaster Recovery ist der geplante Ablauf zur Wiederherstellung einer IT-Umgebung nach einem Totalausfall (Brand, Überschwemmung, Ransomware-Totalbefall). Ein DR-Plan beschreibt nicht nur „wie restore ich Daten?", sondern „in welcher Reihenfolge stelle ich Services wieder her?", „welche Abhängigkeiten existieren?", „wer trifft welche Entscheidungen?".

DR-Pläne sind nur so gut wie die letzte DR-Übung — wir empfehlen jährliche Simulationen, bei denen ein ganzes System kontrolliert abgeschaltet und aus dem Backup wiederhergestellt wird.

RPO (Recovery Point Objective) ist der maximal akzeptable Datenverlust, gemessen in Zeit. RPO = 1 Stunde heißt: Im Ernstfall verliere ich höchstens die letzte Stunde an Daten — also muss ich mindestens stündlich sichern.

RTO (Recovery Time Objective) ist die maximal akzeptable Wiederherstellungs-Dauer. RTO = 4 Stunden heißt: Nach 4 Stunden muss der Service wieder laufen — das determiniert Backup-Technologie, Infrastruktur und Personal-Kapazität.

RPO und RTO sollten fachlich festgelegt werden, nicht technisch: „Wie lange kann die Produktion stehen, bevor es existenzbedrohend wird?" ist eine Business-Frage, keine IT-Frage.

Veeam ist ein führender Anbieter von Enterprise-Backup-Software mit Fokus auf virtualisierte Umgebungen (VMware, Hyper-V, Nutanix). Bietet Application-Aware-Backups (Datenbank-konsistente Snapshots), Instant-Recovery (VM direkt aus Backup booten), Replikation und Cloud-Tiering. Lizenz pro Host/VM.

Der Proxmox Backup Server ist eine dedizierte Backup-Lösung der Proxmox-Macher. Client-side Deduplication (Chunk-Level) macht inkrementelle Backups sehr effizient — auch bei vielen VMs. Verify-Jobs prüfen regelmäßig die Integrität der Chunks. Für Kunden, die bereits Proxmox VE nutzen, ist PBS die natürliche Ergänzung.

Prometheus ist der De-facto-Standard für Metric-basiertes Monitoring in Kubernetes- und Cloud-Native-Umgebungen. Pullt Metriken von Exportern (statt Push) und speichert sie als Time-Series. Seine Query-Language PromQL ist mächtig, aber gewöhnungsbedürftig.

Wir nutzen Prometheus für Infrastructure- und Application-Monitoring. Typische Exporter: Node-Exporter (OS-Metriken), Blackbox-Exporter (Endpoint-Probing), PostgreSQL-Exporter, Nginx-Exporter.

Grafana ist der Standard für Dashboard-Visualisierungen von Monitoring-Daten. Unterstützt Prometheus, Loki, Elasticsearch, InfluxDB, PostgreSQL und viele andere Datasources. Das Ökosystem bietet tausende von Community-Dashboards, die sich für Standard-Anwendungsfälle (Linux-Nodes, PostgreSQL, Kubernetes) direkt importieren lassen.

Loki von Grafana Labs ist eine Log-Aggregation, die ähnlich wie Prometheus denkt: statt alle Log-Inhalte zu indizieren, werden nur Labels indiziert — die eigentlichen Logs liegen komprimiert in Object Storage. Ergebnis: sehr viel günstiger als klassische ELK-Stacks, aber mit etwas anderer Query-Logik.

Der Alertmanager nimmt Alerts von Prometheus entgegen, dedupliziert, gruppiert und routet sie zu den richtigen Empfängern — E-Mail, Slack, Teams, PagerDuty, SMS. Silencing für bekannte Wartungsfenster, Escalation für ungewollte Non-Response. Ein gut konfigurierter Alertmanager ist die Differenz zwischen „95 Alerts pro Tag, alle ignoriert" und „3 Alerts pro Tag, alle beachtet".

Bei Managed Server übernimmt ein Dienstleister den kompletten operativen Betrieb eines dedizierten oder virtualisierten Servers — Installation, Monitoring, Patching, Security-Hardening, Incident-Response. Der Kunde nutzt die Anwendungen, kümmert sich aber nicht um die Infrastruktur.

Managed Hosting ist die Full-Stack-Variante: der Dienstleister stellt Hardware, Rechenzentrum, Netz, Betriebssystem und Anwendungsbetrieb — alles aus einer Hand. Die Grenze zu Managed Server ist fließend; Managed Hosting betont die physische Infrastruktur stärker.

Bei Colocation bringt der Kunde seine eigene Hardware mit und mietet vom Provider nur Platz (Rack-Einheiten), Strom, Kühlung und Internet-Anschluss. Betrieb und Wartung liegen beim Kunden. Für Organisationen, die ihre Hardware schon haben oder Datenhoheit auf physischer Ebene wünschen, aber kein eigenes Rechenzentrum betreiben wollen.

On-Premise heißt: Die Systeme laufen physisch beim Kunden (eigener Serverraum, eigenes Rechenzentrum). Gegensatz zu Cloud/Off-Premise. Für Datenhoheit, Compliance-Anforderungen oder spezielle Latenz-Anforderungen (Produktion, Medizin) oft die einzige Option. Wir bieten Managed-Services auch on-premise — mit Fernzugriff über VPN/Bastion-Host.

Hybrid Cloud kombiniert On-Premise-Ressourcen mit Public Cloud — typischerweise bleiben sensible Daten on-premise, während variable Lasten in die Cloud ausgelagert werden. Technische Voraussetzung: Site-to-Site-VPN oder Direct-Connect, gemeinsame Identity, konsistente Netzsegmentierung.

Desktop as a Service stellt vollständige Windows-Arbeitsplätze aus dem Rechenzentrum bereit — der Mitarbeiter greift per Thin Client, Notebook oder Tablet auf seinen Desktop zu, die eigentliche Verarbeitung läuft zentral. Abgerechnet wird pro User und Monat. Typische Einsatzfälle: verteilte Teams, BYOD-Szenarien, Saisonkräfte und Setups, in denen Unternehmensdaten das Rechenzentrum nicht verlassen sollen.

Trade-off ehrlich: DaaS steht und fällt mit einer stabilen, latenzarmen Anbindung — ohne ordentliche Leitung wird das Arbeiten zäh. Für GPU-lastige Workloads wie CAD oder Videoschnitt braucht es teurere, GPU-gestützte Instanzen. Für standardisierte Büroarbeitsplätze ist DaaS dagegen ein sauberer Weg, Wildwuchs bei Endgeräten und Patchständen loszuwerden.

DRaaS verlagert die Wiederanlauf-Umgebung für den Katastrophenfall zu einem Dienstleister: Eine replizierte Standby-Umgebung steht bereit und kann bei Ausfall des Primärsystems aktiviert werden — mit vertraglich zugesicherten Werten für RTO und RPO. Der Unterschied zum reinen Backup: Ein Backup sichert Daten, DRaaS hält eine lauffähige Umgebung vor, in der diese Daten sofort wieder arbeiten.

Kostenmodell: Sie zahlen für reservierte Standby-Kapazität, nicht für einen zweiten Vollbetrieb. Das lohnt sich für Unternehmen, bei denen Tage an Stillstand existenzbedrohend wären. In der Praxis ist die Vertragsfrage entscheidend — getestete Wiederanlauf-Prozesse und realistische RTO-Zusagen sind mehr wert als die bloße Existenz einer Replik.

HAProxy ist seit 2000 ein extrem performanter TCP- und HTTP-Load-Balancer, der in praktisch jeder High-Traffic-Site der Welt eingesetzt wird. Gegenüber Nginx stärker in reinem Load-Balancing, etwas schwächer bei statischem Content. Unsere typische Wahl für Production-Front-Ends.

Nginx ist heute der meistverwendete Webserver im Internet — vor Apache HTTP Server. Stärken: extrem geringer Ressourcenverbrauch, asynchroner Event-Loop, eingebauter Reverse-Proxy und Load-Balancer. Wir nutzen Nginx als Front-End vor Application-Servern und als TLS-Terminator.

Der Apache HTTP Server war zwei Jahrzehnte lang der meistgenutzte Webserver des Internets und liegt heute hinter Nginx. Er arbeitet mit Prozess- bzw. Thread-Modellen (MPM prefork/worker/event). Stärken: die per-Verzeichnis-Konfiguration über .htaccess, ein riesiges Modul-Ökosystem und die enge Integration von mod_php.

Schwäche gegenüber Nginx: höherer Speicherbedarf pro Verbindung, da kein reiner Event-Loop. In der Praxis setzen wir Nginx als Reverse-Proxy und TLS-Frontend ein und betreiben Apache dahinter dort, wo Anwendungen auf .htaccess oder spezifische Apache-Module angewiesen sind — etwa ältere PHP-Anwendungen und bestimmte CMS.

pfSense und OPNsense sind zwei Open-Source-Firewall-Distributionen auf FreeBSD-Basis — OPNsense entstand 2015 als Fork von pfSense. Beide bieten dieselbe Grundausstattung: Stateful-Firewall, VPN (IPsec, OpenVPN, WireGuard), Traffic-Shaping und IDS/IPS über Suricata. Für KMU sind sie eine ernstzunehmende Alternative zu teuren Appliance-Lizenzen.

Unterschiede: OPNsense hat einen schnelleren Release-Zyklus, eine aufgeräumtere Oberfläche und wöchentliche Security-Updates; pfSense hat die größere installierte Basis und mit pfSense Plus eine kommerzielle Variante. Unsere Empfehlung: Für Neuinstallationen OPNsense — bei bestehenden, gepflegten pfSense-Setups gibt es keinen zwingenden Grund zu wechseln.

VPN schafft einen verschlüsselten Tunnel über ein unsicheres Netzwerk — klassisch für Remote-Access von Heimarbeitsplätzen zu Firmensystemen oder für Site-to-Site-Verbindungen zwischen Standorten. Technologien: IPsec (legacy, aber überall), OpenVPN (TLS-basiert), WireGuard (modern, performant).

Klassische VPNs geraten zunehmend in die Kritik, weil sie Netzwerk-Zugang gewähren statt Anwendungs-Zugang. Der Trend geht zu ZTNA.

ZTNA ist ein Zugriffsmodell, bei dem nicht das Netzwerk freigegeben wird, sondern einzelne Anwendungen — nach erfolgreicher Authentifizierung und Autorisierung pro Zugriff. Der Client sieht die Anwendung erst, nachdem er authentifiziert wurde. Deutlich sicherer als klassisches VPN, weil lateral movement erschwert wird.

TLS ist das Protokoll, das Verbindungen im Internet verschlüsselt und authentifiziert — die Basis hinter HTTPS, IMAPS, SMTPS und vielen anderen „-S"-Protokollen. Aktuelle Versionen sind TLS 1.2 und TLS 1.3. TLS 1.0 und 1.1 sind seit Jahren deprecated und sollten überall deaktiviert sein.

In unseren Managed-Server-Setups sorgen wir für aktuelle Cipher-Suites, HSTS, automatische Zertifikat-Erneuerung (meist via Let's Encrypt), korrekte Chain-Konfiguration und regelmäßige SSL-Labs-Tests (Ziel: Rating A+).

SSH ist der Standard für den verschlüsselten Remote-Zugriff auf Linux-Systeme. Port 22 (standardmäßig, aber von uns geändert), Public-Key-Authentifizierung (Passwort-Login deaktiviert), Fail2Ban gegen Brute-Force, Bastion-Host als Sprungbrett. Typische Härtung: nur Protocol 2, keine Root-Logins, strikte Cipher-Liste.

WireGuard ist ein modernes VPN-Protokoll, das seit 2020 fester Bestandteil des Linux-Kernels ist. Mit unter 4.000 Zeilen Code (im Vergleich zu Hunderttausenden bei OpenVPN/IPsec) ist die Angriffsfläche extrem klein und eine vollständige Code-Review realistisch. Performance: 5–10× schneller als OpenVPN, oft latenz-bestimmend nicht der Tunnel, sondern die Strecke.

Wir setzen WireGuard für Site-to-Site-Verbindungen, Remote-Admin-Zugänge und als Backbone in Mesh-Netzen (Tailscale, Netbird, Headscale). Konfiguration ist deklarativ, Schlüssel-basiert und automatisierbar — perfekt für GitOps-Workflows.

IPv6 löst das Adress-Knappheits-Problem von IPv4 (4,3 Mrd Adressen vs. 340 Sextillionen) und bringt Verbesserungen wie SLAAC für Auto-Konfiguration, Pflicht-IPsec-Unterstützung und kein NAT. In Deutschland liegt der IPv6-Anteil bei rund 70 % der Endkunden-Anschlüsse — Server-Setups ohne IPv6 sind heute schwer zu rechtfertigen.

In der Praxis fahren wir Dual-Stack (IPv4 + IPv6 parallel). Klassische Stolperfallen: Firewall-Regeln nur für IPv4 gesetzt, asymmetrisches Routing, fehlende AAAA-Records im DNS, Logging-Tools die IPv6-Adressen nicht parsen. Für reine v6-Backbones (z. B. zwischen Containern) reduziert sich der Konfigurations-Overhead deutlich.

PostgreSQL ist die verlässlichste Open-Source-Relational-DB der Welt — mit ACID-Transaktionen, MVCC, JSONB für semi-strukturierte Daten, Streaming Replication, logischer Replikation, Partitionierung und einer extrem stabilen Roadmap. Wird von uns für fast alle Kundenprojekte als Default gewählt, wo eine relationale DB gebraucht wird.

MySQL ist die am weitesten verbreitete Open-Source-DB, Teil des klassischen LAMP-Stacks. Seit der Oracle-Übernahme 2010 hat sich MariaDB als Community-Fork etabliert — binär kompatibel, aber mit eigener Feature-Entwicklung. Praktisch: MariaDB als Drop-in-Replacement für MySQL, die meisten Anwendungen funktionieren ohne Anpassung.

MariaDB ist ein 2009 entstandener Fork von MySQL, gestartet von den ursprünglichen MySQL-Entwicklern als Reaktion auf die Oracle-Übernahme. Für die meisten Workloads ist MariaDB ein Drop-in-Replacement — gleiche Protokolle, gleiche Clients, dieselbe SQL-Syntax. Eigene Akzente: zusätzliche Storage-Engines (Aria, ColumnStore für Analytics), keine Lizenz-Unsicherheit und ein vollständig offener Entwicklungsprozess.

Seit etwa 2020 driften die Codebasen merklich auseinander — JSON-Funktionen, system-versionierte Tabellen und einige Replikationsdetails sind nicht mehr identisch. In der Praxis: Für neue Web- und LAMP-Workloads ist MariaDB die unkomplizierte Default-Wahl. Bei Anwendungen, die explizit gegen eine bestimmte MySQL-Version zertifiziert sind — etwa manche ERP-Systeme —, bleiben Sie besser bei MySQL.

MongoDB ist die bekannteste NoSQL-Document-DB. Statt Tabellen speichert sie BSON-Dokumente (binäres JSON). Gut geeignet für Anwendungen mit flexiblem Schema oder tiefer JSON-Struktur. In der Realität ist PostgreSQL mit JSONB-Typ oft die bessere Wahl — wir empfehlen MongoDB nur dort, wo die spezifischen Stärken (Auto-Sharding, Aggregation-Pipeline) wirklich genutzt werden.

Replication ist der Prozess, bei dem Änderungen von einer primären Datenbank kontinuierlich auf eine oder mehrere Replicas übertragen werden. Zwecke: High Availability (automatisches Failover), Lastverteilung (Lesezugriffe auf Replicas), Offsite-Backup. Synchrone Replication garantiert Null Datenverlust — kostet aber Performance. Asynchrone Replication ist schneller, aber mit möglichem Replication-Lag.

Ceph ist ein verteiltes Open-Source-Storage-System, das gleichzeitig Block-Storage (RBD), Object-Storage (S3-kompatibel) und Filesystem (CephFS) bereitstellt — alles aus demselben Cluster. Daten werden auf mehrere Knoten repliziert oder per Erasure Coding gesichert; fällt ein Disk oder ein ganzer Host aus, heilt sich der Cluster automatisch. Skaliert linear von drei Knoten in den Petabyte-Bereich.

Wir setzen Ceph für Proxmox-Cluster mit hyperkonvergenter Architektur ein — Rechenleistung und Storage liegen auf denselben Hosts, kein separates SAN nötig. Wichtig: Ceph braucht ein dediziertes 25/100-GbE-Backend-Netz, sonst wird das Replication-Traffic zur Bremse.

ZFS ist ein Copy-on-Write-Filesystem mit integriertem Volume-Manager. Die Killer-Features: konsistente Snapshots in Sekunden (egal wie groß das Dataset), inkrementelle Replikation per zfs send | zfs receive, end-to-end-Checksums gegen Bit-Rot, integrierte Kompression (LZ4 spart oft 30–50 % ohne CPU-Last), und ARC-Caching im RAM für extreme Read-Performance.

Klassische Einsatzfelder bei uns: Proxmox-Storage auf Single-Hosts, Backup-Repositories für Veeam und Proxmox Backup Server, Datenbank-Storage mit häufigen Snapshots vor Migrationen. Faustregel: 1 GB RAM pro 1 TB Storage als Minimum, mehr für Deduplikation.

Das S3-API von Amazon hat sich zum De-facto-Standard für Object-Storage entwickelt — fast jede Backup-, Logging- und KI-Software kann nach S3 schreiben. Die wichtigsten On-Premise-Implementierungen: MinIO (klein, schnell, einfach), Ceph RadosGW (skaliert mit dem Cluster), Garage (lightweight, geo-replizierend), kommerziell Cloudian.

Wir nutzen S3-Storage primär als Backup-Ziel (Object-Lock für Ransomware-resistente Immutable Backups), als Log-Archiv (Loki, OpenSearch) und als Vector- bzw. Embedding-Speicher in KI-Workloads. Vorteil gegenüber NFS: praktisch unbegrenzt skalierbar, Geo-Replikation eingebaut, jede Datei adressierbar via URL.

Ein SAN stellt zentralen Speicher als Block-Geräte (LUNs) über ein eigenes Netzwerk bereit — anders als ein NAS, das auf Dateiebene (NFS/SMB) arbeitet. Mehrere Server greifen gleichzeitig auf dieselben LUNs zu; genau das ist die Voraussetzung für gemeinsamen Cluster-Speicher mit Live Migration und Hochverfügbarkeit. Als Transport dienen Fibre Channel, iSCSI oder zunehmend FC-NVMe/NVMe-oF.

In Migrationsprojekten weg von VMware ist das SAN fast immer die größte Sorge — zu Unrecht: Proxmox VE bindet bestehende FC- und iSCSI-Arrays von Dell, HPE, NetApp, IBM, Hitachi oder Pure per Multipath ein und legt ein gemeinsames LVM darüber. Die Investition ins Array und das Fabric bleibt erhalten.

Fibre Channel ist das klassische, dedizierte Transportprotokoll für SANs: Block-Storage über eigene HBAs und FC-Switches, getrennt vom LAN, verlustfrei und mit sehr niedriger Latenz. Adressiert wird über WWNs (World Wide Names), die Zugriffssteuerung erfolgt per Zoning im Fabric und LUN-Maskierung am Array. Für Redundanz baut man zwei getrennte Fabrics (A/B).

Unter Proxmox VE wird ein FC-LUN per Multipath als /dev/mapper/mpathX eingebunden; darauf liegt ein thick-provisioniertes Shared LVM. Damit bleibt ein bestehendes FC-SAN beim VMware-Ausstieg voll nutzbar — inklusive Live Migration und HA. Alternativen zum Transport sind iSCSI (über Ethernet) und FC-NVMe.

Hat ein Server zwei HBA-Ports an zwei FC-Fabrics, sieht Linux dasselbe LUN doppelt. Device-Mapper-Multipath (multipathd) bündelt diese redundanten Pfade zu einem einzigen Gerät unter /dev/mapper/mpathX — mit automatischem Failover bei Pfad- oder Switch-Ausfall und je nach Policy Lastverteilung über beide Pfade.

Multipath muss vor LVM eingerichtet sein, sonst drohen Doppelzugriffe und Datenkorruption. Praxis-Hinweis: multipath-tools-boot installieren und nach jeder Änderung an den WWIDs die initramfs neu erzeugen. Erst wenn multipath -ll ein sauberes Pfadbild zeigt, folgt pvcreate.

NVMe over Fabrics transportiert das NVMe-Protokoll über ein Netzwerk statt über den lokalen PCIe-Bus — als NVMe/TCP über Standard-Ethernet, als NVMe/FC über bestehende Fibre-Channel-Fabrics oder über RDMA (RoCE). Gegenüber iSCSI und klassischem FC-SCSI entfällt die SCSI-Übersetzungsschicht: deutlich niedrigere Latenz und mehr parallele Queues, ideal für All-Flash-Arrays.

Praxis unter Proxmox VE (Stand 2026): Der Linux-Kernel beherrscht NVMe/TCP und NVMe/FC inklusive ANA-Multipathing, ein GUI-Storage-Typ fehlt aber — die Einrichtung läuft manuell per nvme-cli, darüber liegt wie beim FC-SAN ein Shared LVM. Hersteller wie NetApp dokumentieren Proxmox offiziell als NVMe-oF-Host; Plugins von TrueNAS, StarWind und LINSTOR nutzen NVMe-oF als Transport.

LVM abstrahiert physischen Speicher in drei Schichten: Physical Volumes (PV, z. B. ein Multipath-LUN), eine Volume Group (VG) als Pool und daraus geschnittene Logical Volumes (LV) als nutzbare Block-Geräte. Das erlaubt flexibles Vergrößern, Verschieben und Verwalten von Volumes ohne Downtime.

Bei Proxmox auf gemeinsamem SAN ist LVM das Herzstück: Die VG liegt auf dem geteilten LUN, jede VM-Disk ist ein eigenes LV, und mit shared 1 behandelt der Cluster den Speicher als gemeinsam. Wichtig: auf geteilten LUNs ausschließlich thick provisioniertes LVM — LVM-thin ist nicht cluster-sicher und nur für lokalen Speicher gedacht.

VMFS (Virtual Machine File System) ist VMwares clusterfähiges Dateisystem, das direkt auf einem SAN-LUN liegt und mehreren ESXi-Hosts gleichzeitig den Schreibzugriff erlaubt. Die VMs liegen als .vmdk-Dateien darin, die Sperren regelt VMFS auf Dateisystemebene. Elegant, aber proprietär.

Proxmox hat kein direktes VMFS-Äquivalent — und braucht keines: Statt eines Cluster-Dateisystems nutzt es ein gemeinsames LVM über dem LUN, wobei jede VM-Disk ein Logical Volume ist und die Cluster-Datenbank die Aktivierung koordiniert. Funktional gleichwertig (Shared Block-Storage, Live Migration, HA), nur anders aufgebaut. Beim Umstieg werden die Daten per ESXi-Import-Wizard übernommen.

iSCSI verpackt SCSI-Befehle in TCP/IP und macht damit aus jedem Ethernet-Netz ein SAN: Der Server (Initiator) sieht ein LUN des Storage-Systems (Target) als lokale Blockplatte. Gegenüber Fibre Channel entfallen HBAs, FC-Switches und das eigene Fabric — dafür teilt man sich das Netz und sollte iSCSI-Traffic konsequent in eigene VLANs mit Jumbo Frames legen.

Unter Proxmox ist der Aufbau identisch zum FC-SAN: LUN einbinden (bei zwei Pfaden mit Multipath), darüber ein thick Shared LVM. Für die meisten KMU-Setups mit 10/25-GbE-Netz ist iSCSI der pragmatische Einstieg in Shared Storage; der modernere Nachfolger auf gleicher Leitung ist NVMe/TCP.

Thin provisionierter Speicher wird erst physisch belegt, wenn tatsächlich Daten geschrieben werden — eine 500-GB-Disk mit 80 GB Daten kostet nur 80 GB. Das erlaubt Überbuchung (Overprovisioning), verlangt aber Monitoring: Läuft der Pool wirklich voll, stehen alle VMs gleichzeitig still. Thick Provisioning reserviert dagegen sofort die volle Größe — verschwenderischer, aber ohne Überraschungen.

Wichtigste Cluster-Regel: Auf einem gemeinsam genutzten FC- oder iSCSI-LUN ist LVM-thin tabu — es ist nicht cluster-sicher und führt zu Datenkorruption, wenn mehrere Knoten die Thin-Pool-Metadaten beschreiben. Auf Shared Storage übernimmt das Array selbst das Thin Provisioning (fast jedes Enterprise-SAN kann es LUN-seitig), Proxmox fährt darüber thick.

QCOW2 (QEMU Copy-on-Write, Version 2) ist das native Disk-Format von QEMU/KVM. Anders als ein rohes Image bringt es eingebaute Snapshots, Kompression und Backing-Files mit: Ein QCOW2-Image kann auf einem Basis-Image aufsetzen und nur die Änderungen speichern — die Grundlage für Linked Clones und Snapshot-Ketten. Der Preis ist eine zusätzliche Metadaten-Schicht, die je nach Workload spürbar Performance kostet.

Aktuell relevant: Proxmox VE 9 nutzt QCOW2-Ketten, um Snapshots auf thick LVM — also auf FC- und iSCSI-SANs — nachzurüsten (Stand 9.2 noch Technologie-Vorschau, mit gemessenen 30–90 % I/O-Overhead). Faustregel: raw für maximale Performance auf Block-Storage, QCOW2 wo Snapshot-Flexibilität auf Datei- oder LVM-Ebene gebraucht wird.

Ein Snapshot friert den Zustand einer VM oder eines Volumes zum Zeitpunkt X ein — als Rücksprungmarke vor Updates oder riskanten Änderungen. Technisch wird meist Copy-on-Write genutzt: Der Snapshot kostet anfangs nichts, wächst aber mit jeder Änderung. Je nach Ebene heißt das VM-Snapshot (Hypervisor), Volume-/LUN-Snapshot (Storage-Array) oder Dateisystem-Snapshot (ZFS, Ceph).

Die zwei wichtigsten Praxis-Regeln: Ein Snapshot ist kein Backup — er liegt auf demselben Speicher wie das Original und schützt weder vor Hardware-Ausfall noch vor Ransomware. Und: Snapshots nicht wochenlang stehen lassen — lange Ketten kosten Performance und Speicherplatz, egal ob unter VMware, Proxmox oder auf dem Array.

Terraform beschreibt Infrastruktur deklarativ in HCL: VMs, Netzwerke, DNS-Records, Firewall-Regeln, Storage-Buckets — alles als versionierter Code in Git. Beim terraform apply berechnet das Tool die Differenz zwischen IST und SOLL und führt nur die nötigen Änderungen aus. Provider gibt es für AWS, Azure, GCP, Hetzner, Proxmox, VMware und hunderte weitere Plattformen.

Seit dem HashiCorp-Lizenzwechsel 2023 nutzen viele Teams den Open-Source-Fork OpenTofu (unter Linux Foundation). Beide sind 100 % drop-in-kompatibel. Bei Multi-Cloud- und Hybrid-Setups bleibt Terraform/OpenTofu unsere Default-Wahl.

Ansible konfiguriert Server agentless über SSH — kein Daemon auf Zielsystemen, nur Python. Playbooks beschreiben in YAML, welcher Zielzustand auf welchen Hosts gelten soll: Pakete installieren, Konfigurationen ausrollen, Dienste starten, User anlegen. Idempotent: ein Playbook kann beliebig oft laufen, das Ergebnis bleibt gleich.

Wir nutzen Ansible für Server-Hardening (CIS-Benchmarks), Patch-Wellen, Onboarding neuer Hosts und tägliche Compliance-Checks. Ergänzt sich perfekt mit Terraform: Terraform legt die VM an, Ansible konfiguriert sie.

GitOps macht Git zur einzigen Quelle der Wahrheit für Infrastruktur und Deployments. Änderungen passieren über Pull Requests, ein Operator (z. B. ArgoCD oder Flux) im Cluster zieht regelmäßig den Repo-Stand und synchronisiert das laufende System mit dem deklarierten Soll-Zustand. Vorteile: vollständige Audit-Historie, einfache Rollbacks (git revert), keine Push-Credentials nötig — der Cluster pullt selbst.

Praxis-Vorteil bei Audits: jede Konfigurationsänderung ist mit Autor, Zeitstempel und Review-Trail dokumentiert — ohne zusätzliches Compliance-Tooling.

GitLab ist eine integrierte DevOps-Plattform — Git-Repository-Hosting, CI/CD-Pipelines, Container-Registry und Issue-Tracking aus einer Hand. Im Self-hosted-Betrieb (Community Edition kostenlos, Enterprise lizenziert) bleibt der Quellcode im eigenen Haus — relevant für IP-Schutz und Compliance gegenüber Cloud-Diensten wie GitHub.com.

GitLab ist zugleich die natürliche Plattform für einen GitOps-Workflow. Trade-off: Self-Hosting heißt, Sie betreiben es selbst — Updates, Backups, CI-Runner. In der Praxis: Für regulierte Branchen und sensible Codebasen lohnt sich der Self-hosted-Betrieb; die Community Edition reicht für die allermeisten Mittelständler aus.

Single Sign-On lässt Mitarbeitende sich einmal authentifizieren und danach ohne weitere Passworteingabe alle freigegebenen Anwendungen nutzen — typischerweise via SAML, OIDC oder OAuth. Der eigentliche Wert liegt nicht in der Bequemlichkeit, sondern in der zentralen Kontrolle: Onboarding und Offboarding eines Users passiert an einer Stelle, MFA-Erzwingung gilt für alle angeschlossenen Systeme, Audit-Logs sind zentralisiert.

In der Praxis nutzen wir Keycloak als Open-Source-IdP für eigenes Hosting oder Microsoft Entra ID (vormals Azure AD) für M365-zentrische Umgebungen. Schwierig wird es nicht beim Setup, sondern bei der Migration bestehender Anwendungen — viele ältere Systeme können kein modernes SSO und brauchen Reverse-Proxy-Wrapper oder LDAP-Brücken.

Multi-Faktor-Authentifizierung verlangt zusätzlich zum Passwort einen zweiten Beweis: TOTP-Code aus einer App, Push-Benachrichtigung am Smartphone, Hardware-Token (YubiKey) oder Biometrie. SMS-MFA ist seit Jahren als unsicher bekannt (SIM-Swap-Angriffe) und sollte nicht mehr neu eingeführt werden — wo es noch läuft, ist die Migration zu TOTP oder Passkeys überfällig.

MFA ist heute der mit Abstand wirksamste Einzelschutz gegen Account-Übernahmen. Gleichzeitig ist sie das, was Cyberversicherer am stärksten als Mindestanforderung prüfen. Wir rollen MFA bevorzugt für alle Admin-Zugänge, VPN-Logins und externen Anwendungen durch — und in einer zweiten Phase für die Standard-User-Anmeldung.

Passkeys sind die Konsumenten-Variante des FIDO2/WebAuthn-Standards: Statt Passwort hinterlegt man auf jedem Service ein kryptographisches Schlüsselpaar — der private Key bleibt im Gerät (Secure Enclave, TPM, Hardware-Token), der öffentliche Key liegt beim Dienst. Phishing-Angriffe scheitern strukturell, weil der Browser die Domain mitprüft und die Signatur nur für die echte Domain erzeugt.

Für den Mittelstand sind Passkeys vor allem dort relevant, wo Microsoft 365, Google Workspace oder eigene SaaS-Produkte sie unterstützen — Apple, Google und Microsoft haben Passkeys 2023/2024 alltagstauglich gemacht. Reine On-Premise-Anwendungen brauchen meist noch FIDO2 mit Hardware-Token (YubiKey) statt Cloud-synchronisierter Passkeys.

OAuth 2.0 ist ein Protokoll zur delegierten Autorisierung — eine Anwendung darf in begrenztem Umfang im Namen eines Users auf eine andere Ressource zugreifen, ohne dessen Passwort zu kennen. Das klassische Beispiel: „Diese App möchte auf Ihren Kalender zugreifen". OAuth ist explizit kein Authentifizierungs-Standard — wer es als Login-Mechanismus zweckentfremdet, baut Sicherheitslücken ein. Genau dafür existiert OIDC, das auf OAuth aufsetzt.

OpenID Connect ergänzt OAuth 2.0 um echte Authentifizierung: Neben dem Access-Token wird ein ID-Token als signiertes JWT zurückgegeben, das den User identifiziert und Standard-Claims wie E-Mail oder Display-Name enthält. OIDC ist heute der De-facto-Standard für moderne SSO-Anbindungen — schlanker als SAML, web- und mobile-tauglich, von allen großen IdPs (Entra ID, Keycloak, Auth0, Google) unterstützt.

Für neue Integrationen wählen wir OIDC vor SAML, sofern beide möglich sind. SAML bleibt aber Pflicht für viele klassische Enterprise-Anwendungen, die nichts anderes können.

SAML ist der ältere, XML-basierte SSO-Standard, der seit den frühen 2000er-Jahren in Enterprise-Umgebungen dominant ist. Ein Identity Provider (IdP) signiert Assertions, ein Service Provider (SP) prüft die Signatur und akzeptiert den User. SAML-Integrationen sind oft fragiler als OIDC: Zertifikatswechsel, Clock-Skew, Metadata-Mismatches verursachen wiederkehrende Stör­ungen. Trotzdem unverzichtbar, weil viele Branchenlösungen — von Personalsoftware bis Krankenhaus-Systemen — nichts anderes können.

Keycloak ist die ausgereifteste Open-Source-Lösung für einen eigenen Identity Provider — mit OIDC-, OAuth- und SAML-Support, LDAP/AD-Federation, MFA-Integration, sozialem Login und feingranularen Authorization-Policies. Im Hintergrund von Red Hat entwickelt, lizenzkostenfrei. Wir setzen Keycloak vor allem dort ein, wo Datenschutz oder Hoster-Wahl die Cloud-IdPs ausschließen — also typischerweise in regulierten Branchen oder bei Kunden mit strikter „Daten in Deutschland"-Vorgabe.

Der Betrieb ist nicht trivial: Datenbank, Cluster, Realm-Konfiguration, Updates und Themes brauchen IT-Expertise. Wer Keycloak ohne Plan einführt, hat in 2 Jahren ein vergessenes System mit kritischer Abhängigkeit. Managed Keycloak ist deshalb meist die ehrlichere Wahl als Self-Service.

Privileged Access Management adressiert die Tatsache, dass Admin-Konten der Kronjuwelen-Angriffsvektor sind. Ein PAM-System (z. B. Teleport, Bravura, CyberArk) zwingt Admin-Zugriffe durch einen kontrollierten Pfad: Zugang nur nach Approval-Workflow, vollständiges Session-Recording, automatische Passwort-Rotation, Just-in-Time-Eskalation statt permanenter Admin-Rechte. PIM ist der ältere Microsoft-Begriff dafür, primär in Entra ID-Kontext.

Für mittelständische Organisationen ist die richtige Reihenfolge: erst MFA + Logging + getrennte Admin-Konten, dann ein leichtes PAM-Tool (Teleport ist hier oft pragmatisch), erst zuletzt eine Enterprise-Lösung. Die Versuchung, mit dem schwersten Tool zu beginnen, endet meist in einem Schatten-Bypass, weil das Tool im Alltag bremst.

Statt Admin-Rechte permanent zu vergeben, erhält ein User sie nur für ein definiertes Zeitfenster und nach expliziter Anforderung — typischerweise gekoppelt an einen Ticket-Bezug oder Approval. Nach Ablauf werden die Rechte automatisch entzogen. Reduziert die „Standing Privileges", die im Schadensfall den Hebel eines kompromittierten Accounts ausmachen. Bestens geeignet für seltene, aber tiefgreifende Aktionen wie Domain-Admin-Tätigkeiten oder Produktions-Zugriffe.

Conditional Access (Microsoft-Begriff; bei Google heißt es „Context-Aware Access") ist die Idee, Login-Anforderungen vom Kontext abhängig zu machen: Anmeldung aus Firmen-Netzwerk → Passwort reicht; Anmeldung aus dem Ausland mit unbekanntem Gerät → MFA + Compliance-geprüftes Endgerät; Anmeldung von einer Tor-Exit-Node → Block. Praktisch wird das über Risk-Scores implementiert (Microsoft Entra ID Identity Protection, Okta, Auth0).

Im Mittelstand ist Conditional Access oft die ehrlichste Form von „Zero Trust": ohne Big-Bang-Migration, sondern als kontinuierliche Härtung der bestehenden M365- oder Workspace-Umgebung.

Der Identity Provider ist die Komponente, die Identitäten verwaltet und Authentifizierungs-Tokens für angeschlossene Anwendungen ausstellt. Beispiele: Microsoft Entra ID, Google Workspace Identity, Okta, Auth0, Keycloak, Active Directory Federation Services (ADFS). In den meisten Mittelstands-Setups ist der IdP entweder Entra ID (M365-zentriert) oder Keycloak (Open-Source-zentriert) — alles andere ist meist historisch gewachsen oder branchenbedingt.

Vaultwarden ist eine schlanke, in Rust geschriebene Server-Implementierung der Bitwarden-API. Sie ist mit allen offiziellen Bitwarden-Clients kompatibel — Browser-Erweiterung, Mobile-App, Desktop. Self-hosted bedeutet: Die Passwort-Tresore liegen auf der eigenen Infrastruktur, es fallen keine Cloud-Gebühren pro Nutzer an, und der Server läuft ressourcenschonend in einem einzigen Container.

Der Tresor selbst wird clientseitig Ende-zu-Ende verschlüsselt — der Server sieht nie Klartext-Passwörter. Trade-off ehrlich: Vaultwarden ist ein Community-Projekt, Sie betreiben und sichern es selbst. Organisationen, die einen Hersteller-SLA oder erzwungenes SSO brauchen, sind mit dem kommerziellen Bitwarden besser bedient. Für den Mittelstand, der einen eigenen Team-Passwortmanager will, ist Vaultwarden eine ausgezeichnete Wahl.

Microsoft Entra ID ist Microsofts Cloud-Plattform für Identitäten und Zugriff — 2023 aus Azure Active Directory umbenannt. Es ist der Identity Provider hinter Microsoft 365 und liefert SSO, MFA, Conditional Access und Geräteverwaltung. Für M365-zentrierte Unternehmen ist Entra ID damit faktisch die zentrale Auth-Instanz.

Wichtig zu verstehen: Entra ID ist kein Cloud-Klon des klassischen Active Directory. Es ist ein anderes Modell — ein flaches Verzeichnis ohne OUs und Gruppenrichtlinien, Zugriff über REST/Microsoft Graph statt LDAP. Klassische domänengebundene Server brauchen weiterhin ein lokales AD; die Brücke schlägt Entra Connect per Synchronisierung. In der Praxis fahren die meisten Mittelständler ein Hybrid-Setup aus beidem.

Ein Large Language Model ist ein neuronales Netz, das auf riesigen Textkorpora trainiert wurde, um Sprach-Muster zu modellieren — typischerweise mit Milliarden bis Hunderten Milliarden Parametern. GPT-4, Claude, Llama und DeepSeek sind aktuelle Vertreter. Was sie für Unternehmen relevant macht: Sie können Texte zusammenfassen, klassifizieren, generieren oder in strukturierte Form bringen — ohne projektspezifisches Training, allein durch Prompts.

Für Geschäftszwecke ist meist nicht das größte Modell das richtige. Ein 7B- oder 13B-Modell mit guter RAG-Anbindung schlägt im Spezial-Use-Case oft ein generisches GPT-4 — und läuft On-Premise auf einer einzelnen GPU. Die Wahl ist deshalb keine Frage der Technik, sondern der Use-Case-Schärfe.

RAG ergänzt ein LLM um eine eigene Wissensquelle: Bevor das Modell antwortet, werden semantisch passende Dokumente aus einer Vektor-Datenbank in den Prompt eingefügt — das Modell antwortet dann auf Basis dieses Kontexts statt seines trainierten Allgemeinwissens. Vorteil: Eigene, aktuelle, vertrauliche Daten bleiben unter Kontrolle, das Modell muss nicht neu trainiert werden, und Halluzinationen sind besser einzudämmen.

RAG ist das mit Abstand häufigste Pattern für Unternehmens-KI — von „Frag deine Wissensdatenbank" über Support-Bots bis zur Vertragsanalyse. Die Architektur ist konzeptuell einfach, der praktische Knackpunkt liegt in der Datenaufbereitung: Chunking-Strategie, Metadaten, Re-Ranking und Evaluations-Setup entscheiden über Qualität, nicht das Modell selbst.

Ein Embedding ist eine Vektor-Repräsentation von Text (oder Bild, Audio) — typischerweise zwischen 384 und 3072 Dimensionen lang. Texte mit ähnlicher Bedeutung erzeugen Vektoren, die im Raum nah beieinander liegen. Das ist die mathematische Grundlage von RAG und semantischer Suche: Statt nach Schlüsselwörtern wird nach Bedeutung gesucht.

Für deutschsprachige Inhalte ist die Wahl des Embedding-Modells nicht trivial — viele Standard-Modelle aus dem englischen Raum verlieren bei deutschen Fachbegriffen Genauigkeit. Wir testen Embedding-Modelle vor dem Produktiv-Einsatz immer auf einem realen Datensatz und vergleichen Top-K-Recall, nicht abstrakte Benchmarks.

Vektor-Datenbanken sind auf die schnelle Nachbarschafts-Suche in hochdimensionalen Räumen spezialisiert — typischerweise via Approximate-Nearest-Neighbor-Indizes (HNSW, IVF). Bekannte Vertreter: Qdrant, Weaviate, Milvus, pgvector als PostgreSQL-Erweiterung. Für mittelständische Setups ist pgvector oft die ehrlichste Wahl: keine zusätzliche Datenbank-Engine im Stack, ausreichend für Millionen-Größenordnung, gewohnte Backup- und Replication-Tools.

Spezialisierte Vector-DBs lohnen sich erst bei zweistelligen Millionen-Vektoren oder wenn echte Multi-Tenancy-Trennung im Index gefordert ist. Bei kleineren Datenmengen kostet die Komplexität mehr als sie bringt.

vLLM ist eine Open-Source-Inference-Engine für LLMs, ursprünglich aus Berkeley. Der Schlüssel-Trick ist PagedAttention — eine Speicherverwaltung, die GPU-RAM ähnlich wie virtuellen Speicher behandelt und damit höhere Concurrency und besseren Durchsatz erreicht als naïve Inference-Loops. Praktisch heißt das: Mit vLLM bedient eine A100 oder H100 dutzende parallele User mit akzeptabler Latenz.

Wir setzen vLLM in unseren On-Premise-KI-Stacks als Default-Server ein. Alternativen wie TGI (Hugging Face) oder TensorRT-LLM (NVIDIA) sind je nach Modell und Hardware gleichwertig — entscheidend ist eher die Pipeline rundherum: Prompt-Caching, Streaming, Telemetrie.

LoRA trainiert nicht das gesamte Modell neu, sondern nur kleine Adapter-Matrizen, die in bestimmte Layer eingehängt werden. Das Resultat ist ein wenige Megabyte großer Adapter, der das Verhalten eines Basis-Modells in eine bestimmte Richtung kippt — Stil, Domain, Format. LoRA-Training ist um Größenordnungen günstiger als Full-Fine-Tuning und auf einer einzelnen Consumer-GPU machbar.

Praktisch wichtig: Fine-Tuning ist selten der erste Schritt. Vor dem Training lohnt es sich fast immer, die Aufgabe per Prompting + RAG durchzuspielen — wenn das nicht reicht, ist die Datengrundlage meistens auch zu klein für ein sinnvolles Fine-Tuning.

Prompt Injection ist die LLM-Variante von SQL-Injection: Ein Angreifer schleust Anweisungen in Daten ein, die das Modell verarbeitet — etwa über eine E-Mail, ein Dokument oder eine Webseite — und bringt das Modell dazu, seine eigentliche Anweisung zu ignorieren. Direkte Injection erfolgt durch den User selbst, indirekte über Drittquellen (RAG-Dokumente, gescrapter Webinhalt).

Der Schutz ist anders als bei klassischen Web-Vulnerabilities: Es gibt keine vollständige Lösung. Best Practice ist Defense-in-Depth — strikte Trennung von System- und User-Prompt, Privilegien-Minimierung des Modells (nur lesende Tools, kein blinder Datei-Zugriff), Output-Filter, Logging und ein menschlicher Approval-Schritt für sensitive Aktionen.

Quantization reduziert die Bit-Tiefe der Modell-Gewichte — von 16-Bit-Float (FP16/BF16) auf 8-Bit (FP8/INT8) oder sogar 4-Bit (INT4/MXFP4). Das Modell wird kleiner und passt damit auf günstigere GPUs, ohne dass die Qualität in den meisten Anwendungsfällen messbar leidet. Ein 70B-Modell, das in FP16 etwa 140 GB VRAM braucht, läuft in INT4 schon auf 40 GB — also auf einer einzelnen A100 oder zwei Consumer-GPUs.

Praxis-Formate 2026: FP8 nutzt die nativen Hopper-Tensor-Cores der H100 voll aus (typisch für MiniMax M2.5). AWQ-Int4 (Activation-aware Weight Quantization) halbiert den VRAM-Bedarf bei Dense-Modellen wie Qwen3 27B mit minimalem Qualitätsverlust. MXFP4 (Microscaling 4-Bit Float) ist das von GPT OSS nativ ausgelieferte Format — damit passt selbst ein 120B-MoE-Modell auf eine einzelne H100. Bei Code oder mathematischer Logik wird's enger — dort lohnt sich oft die nächst-bessere Stufe.

MLOps überträgt DevOps-Prinzipien auf Machine-Learning-Workflows: Modelle und Daten werden versioniert, Trainingsläufe sind reproduzierbar, Deployments laufen automatisiert, und produktive Modelle werden auf Drift, Latenz und Output-Qualität überwacht. Tools wie MLflow, DVC oder Kubeflow decken Teile davon ab — eine vollständige MLOps-Pipeline ist aber primär Prozess, nicht Tooling.

Für reine LLM-Anwendungen, die fertige Modelle konsumieren statt selbst zu trainieren, ist klassisches MLOps oft Overkill. Wichtiger sind dort Prompt-Versionierung, Eval-Datasets und Output-Monitoring — was unter dem Begriff LLMOps zusammengefasst wird.

Eine A100 oder H100 ist teuer und in vielen Workloads nicht ausgelastet. GPU-Pooling teilt eine physische GPU auf mehrere Workloads auf — entweder via NVIDIA Multi-Instance GPU (MIG, harte Trennung in bis zu 7 Slices), klassischer vGPU (Citrix-/VMware-Welt) oder Software-Time-Slicing über Kubernetes-Plugins. Sinnvoll vor allem in Multi-Tenant-Setups oder wenn Inference-Last und Training-Spikes sich abwechseln.

In der Praxis: MIG für klare Service-Isolation (z. B. Mandantentrennung), Time-Slicing für Entwickler-Workstations, dedizierte GPUs für produktive Inference mit konstanter Last.

Das Model Context Protocol ist ein offener Standard, mit dem LLM-Anwendungen einheitlich auf externe Datenquellen und Tools zugreifen können — Datenbanken, Filesysteme, APIs, interne Wissensdatenbanken. Statt für jedes Modell und jede Datenquelle eine eigene Integration zu bauen, definiert MCP eine standardisierte Server-Schnittstelle. Anthropic hat das Protokoll Ende 2024 veröffentlicht, OpenAI, Microsoft und Google haben es 2025 adoptiert.

Praktischer Nutzen: Ein einmal gebauter MCP-Server (z. B. „Zugriff auf das ERP-System") funktioniert mit Claude, ChatGPT, Cursor und beliebigen anderen MCP-fähigen Clients. Für Mittelständler, die KI ins Tagesgeschäft integrieren wollen, reduziert das Lock-in und Implementierungsaufwand erheblich.

Agentic AI bezeichnet KI-Systeme, die nicht nur Antworten erzeugen, sondern eigenständig Aufgaben planen und ausführen — Tools aufrufen, Zwischenergebnisse bewerten, korrigieren, weitermachen. Klassisches Beispiel: „Bereite den Quartalsbericht vor" — der Agent zieht Zahlen aus dem ERP, formatiert sie, prüft Plausibilität, generiert Visualisierungen, sendet das Ergebnis. Loop aus Planen → Handeln → Beobachten → Anpassen.

Risiken steigen mit dem Autonomie-Grad: ein Agent mit Schreibrechten in der Datenbank kann mehr Schaden anrichten als ein Chatbot. Wir empfehlen klare Berechtigungs-Scopes pro Tool, Audit-Logging jeder Agenten-Aktion, Mensch-im-Loop bei irreversiblen Schritten — und konkrete Kostenlimits, da Agenten viele Tokens konsumieren.

Durable Execution ist ein Ausführungsmodell, bei dem der Fortschritt eines langlaufenden Prozesses persistent außerhalb des ausführenden Prozesses gehalten wird. Fällt der Node aus, wird der Lauf auf dem letzten Checkpoint fortgesetzt statt neu gestartet. Für KI-Agenten ist das die Voraussetzung für alles, was länger als ein paar Sekunden dauert.

Der entscheidende Punkt sind Seiteneffekte: Eine Erstattung, eine Buchung oder eine Mail darf nach einem Absturz nicht ein zweites Mal ausgelöst werden. Deshalb bekommt jeder schreibende Schritt einen Idempotenz-Key aus Lauf-ID und Schrittnummer — das Zielsystem erkennt den Wiederholungsversuch und führt die Aktion nur einmal aus.

A2A ist ein offenes Protokoll für die Kommunikation zwischen eigenständigen KI-Agenten — auch über Organisationsgrenzen hinweg. Während MCP den vertikalen Bus bildet (ein Agent, viele Werkzeuge), ist A2A der horizontale: Ein Agent delegiert eine Aufgabe an einen anderen, verfolgt den Fortschritt und empfängt das Ergebnis, ohne dessen interne Umsetzung zu kennen. Das Protokoll steht unter neutraler Governance der Linux Foundation; ACP ist darin aufgegangen.

Jeder Agent veröffentlicht eine Agent Card unter /.well-known/agent-card.json mit Fähigkeiten, Endpunkten, Authentifizierung und Betreiber. Die Signaturprüfung dieser Karte ist Pflicht: Ohne sie lässt sich ein Registry-Eintrag fälschen und eine Aufgabe samt Kontext an einen fremden Endpunkt umlenken. Unsere Praxis: Delegation als Vorschlag mit Rückgabe, nicht als Vollmacht.

Agent Identity bedeutet, dass ein KI-Agent eine eigene Kennung, einen eigenen Rechteumfang und eine eigene Spur im Audit-Log hat — getrennt von dem Menschen, der den Lauf ausgelöst hat. Der häufigste Konstruktionsfehler in Agenten-Projekten ist das Gegenteil: Der Agent handelt unter einem Administratorkonto und hat damit dauerhaft dessen Rechte.

Technisch umgesetzt wird das über OAuth 2.1 mit Resource Indicators (RFC 8707): kurzlebige Tokens, die nur für ein bestimmtes Zielsystem gelten, je Lauf ausgestellt statt je Deployment. Bei Sub-Agenten gilt strikte Teilmengenbildung — ein Sub-Agent kann nur Rechte bekommen, die der Eltern-Lauf besitzt. So bleibt der Blast Radius eines kompromittierten Agenten begrenzt.

Ein Agent Gateway (auch Tool-Gateway) sitzt zwischen Agent und Werkzeug und ist die einzige Stelle, an der ein Aufruf technisch verhindert werden kann. Fünf Stufen laufen dort ab: Authentifizierung des aufrufenden Agenten, Schema-Validierung auf Ein- und Ausgabe, Rate-Limiting und Quoten, Policy-Entscheid (erlaubt, erlaubt mit Limit, Freigabe nötig, abgelehnt) und schließlich das Audit-Log mit sanitisierten Parametern.

Der oft übersehene Punkt ist die Prüfung der Rückgabe: Was ein Werkzeug zurückliefert, fließt direkt in den Modellkontext und kann Verhalten beeinflussen — Prompt Injection über die Hintertür. Deshalb werden Ausgaben gegen das Schema validiert, in der Größe begrenzt und als Daten markiert, nie als Anweisung.

OpenTelemetry ist der herstellerneutrale Standard, mit dem Anwendungen ihre Telemetrie beschreiben: Ein Vorgang wird als Trace aufgezeichnet, jeder Teilschritt als Span mit Dauer, Attributen und Fehlerstatus. Weil das Format offen ist, lassen sich die Daten in nahezu jedes Monitoring exportieren — ohne Bindung an einen Anbieter.

Bei KI-Agenten ist das der Unterschied zwischen Raten und Wissen: Ein Lauf besteht aus einem Eltern-Span (agent.run) und je einem Span pro Modellaufruf und Tool-Call — inklusive Agenten-Identität, Prompt-Version, Token-Verbrauch und Kosten. Ein fehlgeschlagener Call und sein Retry sind zwei getrennte Spans; im Nachhinein ist damit nachvollziehbar, warum ein Lauf 2,4 Sekunden statt 800 Millisekunden gebraucht hat.

Human-in-the-Loop bezeichnet den bewusst eingeplanten Halt eines automatisierten Ablaufs, an dem ein Mensch entscheidet. Technisch sauber gelöst ist das kein Abbruch mit späterem Neustart, sondern ein Wartezustand: Der Lauf wird persistiert, wartet Stunden oder Tage auf die Freigabe und setzt danach an genau derselben Stelle fort.

In der Praxis wird die Grenze über Schwellen gezogen — Betrag, Außenwirkung, Unumkehrbarkeit, Datenkategorie. Wer alles freigeben lässt, erzeugt Alarmmüdigkeit und damit Pro-forma-Klicks; wer nichts freigeben lässt, verlagert das Risiko in die Policy. Jede Entscheidung gehört mit Zeitstempel und Person ins Audit-Log.

Eine Agent Card ist die maschinenlesbare Visitenkarte eines Agenten im A2A-Ökosystem: Sie liegt unter /.well-known/agent-card.json und beschreibt Fähigkeiten, Endpunkte, unterstützte Ein- und Ausgabeformate sowie die Authentifizierung. Ein aufrufender Agent liest sie zur Laufzeit und weiß damit, was das Gegenüber kann.

Sicherheitsrelevant ist die Signatur. Eine unsignierte Agent Card ist eine Behauptung — sie lässt sich manipulieren, um Fähigkeiten vorzutäuschen oder Aufrufe umzuleiten. Signierte Cards und gepinnte Aussteller sind deshalb Baseline-Schutz, sobald Aufgaben an fremde Agenten übergeben werden.

Ein Eval-Harness ist die Testsuite für KI-gestützte Abläufe: ein festes Set aus echten Eingaben mit erwartetem Ergebnis (Goldset), das bei jeder Änderung an Prompt, Modell, Werkzeug oder Policy automatisch durchläuft. Bewertet wird maschinell, wo es geht — Schema gültig, Summe korrekt, Datensatz vorhanden, Tests grün — und stichprobenhaft durch Menschen, wo Ermessen im Spiel ist.

Ohne Evals ist jede Prompt-Änderung ein Blindflug: Eine Formulierung, die einen Fall verbessert, verschlechtert oft drei andere. Der Aufwand liegt weniger im Werkzeug als im Goldset — 50 bis 200 gut ausgewählte Fälle sind für einen ersten Use Case realistisch.

Eine Operation heißt idempotent, wenn ihre mehrfache Ausführung dasselbe Ergebnis hat wie die einmalige. Lesende Aufrufe sind das von Natur aus; schreibende nicht — eine zweimal ausgeführte Erstattung ist zweimal Geld. Ein Idempotenz-Key ist die Kennung, unter der ein Zielsystem einen bereits ausgeführten Aufruf wiedererkennt und nicht erneut ausführt.

Für KI-Agenten ist das die Voraussetzung dafür, dass Retries und Wiederaufnahme nach einem Ausfall gefahrlos sind. Ohne Idempotenz-Keys ist jeder Neustart eines Laufs ein Risiko für doppelte Seiteneffekte — und genau daran scheitern Agenten-Prototypen beim Schritt in den Produktivbetrieb.

ISO/IEC 42001 ist die erste zertifizierbare Norm für ein KI-Managementsystem (AIMS) — das Pendant zur ISO 27001, nur für Künstliche Intelligenz statt Informationssicherheit. Sie fordert unter anderem ein KI-Inventar, Risikobewertungen je System, definierte Rollen und Verantwortlichkeiten, Änderungsmanagement für Modelle und dokumentierte Incident-Prozesse.

Praktische Bedeutung: Die Norm ist der natürliche Nachweis-Rahmen für EU-AI-Act-Pflichten — wer ein AIMS betreibt, hat die geforderte Governance-Struktur weitgehend stehen. Viele Nachweise (Logging, Modellversionen, Zugriffskontrolle) entstehen in einem sauber geführten KI-Betrieb ohnehin; ein Managed-Betrieb kann sie als „Readiness-Paket" kontinuierlich mitliefern, zertifizieren muss eine akkreditierte Stelle.

LLMOps ist das DevOps für Sprachmodelle: die Betriebsdisziplin, die ein LLM-System produktiv hält. Dazu gehören Modell-Lifecycle (Auswahl, Updates, Rollback), Latenz- und Qualitäts-Monitoring, Kosten-Tracking pro Anwendung, Prompt- und Versions-Management sowie die Pflege von RAG-Indizes und Embeddings.

Der Unterschied zum klassischen Server-Betrieb: Bei KI-Systemen altern nicht nur Betriebssystem und Pakete, sondern auch Modelle, Indizes und Prompts — ein Modell-Update kann Antwortverhalten spürbar ändern. Sauberes LLMOps testet deshalb vor dem Rollout gegen definierte Referenzfragen und hält Rollback-Pfade bereit.

Mixture-of-Experts-Modelle teilen ihre Parameter in spezialisierte „Experten"-Subnetze auf, von denen pro Token nur einige wenige aktiviert werden. Ein Modell mit 230 Milliarden Gesamtparametern wie MiniMax M2.5 aktiviert pro Token nur etwa 10 Milliarden — Inference wird damit deutlich günstiger als bei einem äquivalent großen Dense-Modell, ohne dass die Endqualität leidet.

MoE ist 2025/26 zur Standardarchitektur der Open-Weights-Spitzenmodelle geworden — MiniMax M2, GPT OSS, DeepSeek V3 und Mixtral nutzen das Konzept. Praktischer Vorteil für On-Premise-Betrieb: Modelle in der 100B+-Klasse laufen mit nur wenigen Milliarden aktiven Parametern auf einer einzelnen H100, was vor zwei Jahren nicht möglich war.

GPT OSS ist die Open-Weights-Modellfamilie von OpenAI, 2025 unter Apache-2.0-Lizenz veröffentlicht — die erste freie Veröffentlichung seit GPT-2. Verfügbar als GPT OSS 120B (117 Mrd. Gesamt-, ca. 5 Mrd. aktive Parameter pro Token) und GPT OSS 20B (kleinere Variante). Beide nutzen MoE-Architektur mit nativer MXFP4-Quantisierung — GPT OSS 120B passt damit in eine einzelne H100 80GB, GPT OSS 20B läuft sogar auf einer L40S 48GB.

Zentrale Eignung als On-Premise-Chatbot: Tonalität, Formatierung und Refusal-Verhalten entsprechen dem von ChatGPT — die Akzeptanz-Hürde bei Mitarbeitenden ist daher niedriger als bei vergleichbaren Open-Modellen. Volle Kompatibilität mit OpenAI-Tooling: Function Calling, Structured Outputs und Chat-Completion-Format funktionieren ohne Anpassung. Reasoning-Stärke nahe o3-mini / o4-mini durch eingebauten Chain-of-Thought-Modus mit Stufen low/medium/high.

Qwen3 ist die dritte Generation der Open-Weights-Modellreihe aus dem Hause Alibaba, 2025 erschienen. Verfügbar in Dense- und MoE-Varianten zwischen 0,6 und 235 Milliarden Parametern, alle unter Apache-2.0-Lizenz. Charakteristisch ist der Hybrid-Thinking-Modus, der per Prompt-Switch (/think bzw. /no_think) zwischen schnellen Antworten und explizitem Reasoning-Loop umschaltet — pro Anfrage wählbar, ohne Modellwechsel.

Stärke bei deutscher Sprache und mehrsprachigem Reasoning: Qwen3 ist eines der wenigen Open-Modelle in dieser Größenklasse, das auf Deutsch idiomatisch antwortet — entscheidend für Helpdesk-Agenten, Dokumentenverarbeitung und Kommunikation in deutschsprachigen Unternehmen. Qwen3 27B ist in unseren On-Premise-Stacks die typische Default-Wahl für Reasoning- und Allzweck-Chat-Workloads, mit AWQ-Int4-Quantisierung lauffähig auf einer einzelnen H100.

Stand 2026: Mit Qwen3.6 (April 2026, Apache 2.0) ist die Reihe multimodal geworden — sowohl das dichte 27B-Modell als auch das MoE-Modell 35B-A3B bringen den Vision-Encoder im selben Checkpoint mit, bei 262.144 Token nativem Kontext. Mit Qwen3.8-Max (2,4 Billionen Parameter) wurde im Sommer 2026 erstmals ein Modell der Max-Klasse als Open Weight angekündigt; für eigene Infrastruktur relevant ist die parallel angekündigte 27B-Variante.

MiniMax ist eine chinesische LLM-Familie, die explizit auf agentische Workflows und Coding optimiert ist. Die aktuelle Generation MiniMax M2.5 ist ein MoE-Modell mit rund 230 Milliarden Gesamt- und ca. 10 Milliarden aktiven Parametern pro Token, mit Kontextfenstern bis 256k Tokens.

Eines der besten Open-Weights-Modelle für Function Calling und mehrstufige Tool-Chains — Spitzenwerte auf BFCL und Tau-Bench. Typischer Einsatz: Helpdesk-Agenten mit komplexen Tool-Aufrufen, Coding-Assistants als Cloud-Copilot-Ersatz, RAG-Systeme mit langen Kontexten. VRAM-Bedarf höher als Dense-Modelle vergleichbarer Leistung — typischerweise 4× H100 in FP8-Quantisierung.

Ein Open-Weight-Modell stellt seine trainierten Gewichte zum Download bereit. Sie dürfen es lokal ausführen, quantisieren, feintunen und in eigene Anwendungen einbetten — ohne dass eine einzige Anfrage an einen Anbieter geht. Die verbreiteten Lizenzen sind Apache 2.0 oder MIT; einzelne Hersteller nutzen eigene Community-Lizenzen mit Nutzungsgrenzen, die man vor dem Produktiveinsatz lesen sollte.

Nicht zu verwechseln mit Open Source: Offengelegt sind die Gewichte, in aller Regel nicht die Trainingsdaten und nicht der Trainingscode. Für den Betrieb ist genau das Erste entscheidend — für die Nachvollziehbarkeit der Modellherkunft bleibt eine Lücke. Betriebsvorteil gegenüber Cloud-APIs: keine Modell-Deprecation durch Dritte, planbare Kosten, keine Datenübermittlung, kein Rate-Limit.

Ein Vision-Language-Modell verarbeitet Bilder und Text im selben Modell und antwortet in Text — technisch „Image-Text-to-Text". Der bildverarbeitende Teil heißt Vision-Encoder und steckt bei modernen offenen Modellen wie Qwen3.6 direkt im Checkpoint, statt als separater Dienst danebenzustehen.

Der betriebliche Vorteil ist größer, als die Produktbeschreibung vermuten lässt: ein Endpunkt statt zwei, eine GPU-Zuteilung statt zwei, ein Quantisierungsstand, eine Monitoring-Kette. Typische Anwendungen im Mittelstand: Belegverarbeitung, Screenshot-Analyse im Helpdesk, Auswertung technischer Dokumentation, Wareneingangs- und Qualitätsprüfung. Wird der Knoten nur für Text genutzt, spart --language-model-only in vLLM den Speicher des Encoders.

llama.cpp ist eine schlanke Inference-Engine in C/C++, die Sprachmodelle auf Hardware ausführt, die kein Rechenzentrum ist: einzelne Consumer-GPUs, Apple Silicon, reine CPU-Systeme mit Teilauslagerung. Modelle werden im GGUF-Format geladen; llama-server stellt eine OpenAI-kompatible API bereit, sodass bestehende Clients unverändert weiterlaufen.

Abgrenzung zu vLLM: llama.cpp ist die richtige Wahl für Einzelplätze, Außenstandorte, Testumgebungen und Edge-Betrieb. Sobald mehrere Nutzer oder Automationen gleichzeitig zugreifen, ist vLLM um Größenordnungen im Vorteil — der Unterschied im Durchsatz ist nicht graduell. Beides parallel zu betreiben ist üblich: zentral vLLM, an den Rändern llama.cpp mit demselben Modell.

GGUF ist das Modellformat von llama.cpp: ein Modell, eine Datei, inklusive Metadaten und Tokenizer. Die Namensbestandteile bezeichnen die Quantisierungsstufe — Q4_K_M steht für 4 Bit mit gemischter Genauigkeit, IQ4_XS für eine platzsparendere 4-Bit-Variante, UD-* für Varianten mit dynamisch verteilter Bitbreite.

Praxisregel: 4 Bit ist die untere Grenze für produktive Arbeit. 3 Bit kostet spürbar Qualität, 2 Bit ist ein Machbarkeitsnachweis, kein Betriebsmodus. Beispiel Qwen3.6-27B: rund 17,6 GB in UD-Q4_K_XL gegenüber 53,8 GB unquantisiert — plus Kontext und KV-Cache im laufenden Betrieb.

SGLang ist neben vLLM die zweite ernstzunehmende Open-Source-Engine für den Mehrbenutzerbetrieb von Sprach- und Vision-Modellen. Stärken liegen bei strukturierten Ausgaben, komplexen Prompt-Programmen und aggressivem Prefix-Caching (RadixAttention).

In der Praxis entscheidet meist die Unterstützungslage: Welche Engine unterstützt das gewünschte Modell in einer stabilen Version? Für Qwen3.6 nennen die Modellkarten SGLang ab Version 0.5.10. Wir behandeln beide Engines als austauschbare Bausteine hinter derselben OpenAI-kompatiblen Schnittstelle — das hält den Wechsel offen.

Der KV-Cache hält die bereits berechneten Schlüssel- und Wert-Vektoren der verarbeiteten Token, damit das Modell bei jedem neuen Token nicht den gesamten Kontext neu berechnen muss. Er wächst linear mit der Kontextlänge und mit der Zahl gleichzeitiger Anfragen.

Die wichtigste Sizing-Konsequenz: Nicht die Modellgröße begrenzt im Betrieb die Nutzerzahl, sondern der Speicher, der nach dem Laden der Gewichte für den KV-Cache übrig bleibt. Wer den Kontext auf das Maximum stellt, „verbraucht" damit parallele Nutzer. vLLM verwaltet diesen Speicher mit PagedAttention seitenweise und erreicht dadurch deutlich höhere Auslastung als eine naive Implementierung.

Eine CVE-Nummer (z. B. CVE-2025-31324) ist die weltweit eindeutige Kennung für eine konkrete Sicherheitslücke. Der zugehörige CVSS-Score (0–10) bewertet die Kritikalität. Das BSI meldet im Schnitt rund 119 neue Schwachstellen pro Tag — die schiere Menge macht eine Priorisierung nach CVSS und tatsächlicher Ausnutzbarkeit unverzichtbar.

In der Praxis entscheidend ist das Zeitfenster zwischen Veröffentlichung und erster Ausnutzung: Bei kritischen CVEs sinkt es laut Branchenauswertungen auf wenige Tage. Genau deshalb gehört ein automatisiertes Patch-Management zur Pflichtausstattung — und ist über NIS2 §30 für viele Unternehmen rechtlich vorgeschrieben.

Das Exploit Prediction Scoring System (betrieben von FIRST) schätzt für jede CVE die Wahrscheinlichkeit, dass sie in den nächsten 30 Tagen tatsächlich ausgenutzt wird — als Wert zwischen 0 und 1, täglich aktualisiert. Damit beantwortet EPSS die Frage, die der CVSS-Score offen lässt: nicht „wie schlimm wäre es?", sondern „wie wahrscheinlich passiert es?".

In der Praxis ist EPSS der zweite Filter im risikobasierten Patch-Management: Ein CVSS-9-Fund mit EPSS von 0,01 kann warten, ein CVSS-7-Fund mit EPSS über 0,1 auf einem exponierten System nicht. Die Kombination aus CVSS, EPSS und KEV-Katalog reduziert die tägliche Patch-Triage auf ein handhabbares Maß.

Der Known-Exploited-Vulnerabilities-Katalog der US-Behörde CISA listet ausschließlich Schwachstellen, deren aktive Ausnutzung in freier Wildbahn belegt ist — Mitte 2026 rund 1.300 Einträge, gegenüber zehntausenden neuen CVEs pro Jahr. Ein KEV-Eintrag ist damit das stärkste Priorisierungssignal, das es gibt: kein Modell, keine Schätzung, sondern beobachtete Angriffe.

In der Praxis: KEV-gelistete Lücken auf erreichbaren Systemen gehören in ein 24–72-Stunden-Patchfenster, notfalls per Notfall-Change. Wer nur nach CVSS priorisiert, patcht an der realen Bedrohungslage vorbei.

Post-Quanten-Kryptografie bezeichnet Verschlüsselungs- und Signaturverfahren, die auch einem künftigen Quantencomputer standhalten — im Gegensatz zu RSA und ECC, die per Shor-Algorithmus brechbar wären. Die NIST-Standards sind seit August 2024 final: ML-KEM (FIPS 203, Schlüsselaustausch), ML-DSA (FIPS 204) und SLH-DSA (FIPS 205, Signaturen). Browser und OpenSSH nutzen hybride PQC-Verfahren wie X25519MLKEM768 bereits per Default.

Der Migrationstreiber ist „Harvest now, decrypt later": heute mitgeschnittener TLS- oder VPN-Verkehr kann später entschlüsselt werden. Die EU-Roadmap verlangt den Migrationsstart bis Ende 2026, Hochrisiko-Systeme bis Ende 2030; das BSI empfiehlt reines RSA/ECC nur noch bis Ende 2031 — hybride Verfahren zuerst.

Ein ISMS ist kein Produkt, sondern ein dokumentierter Steuerungsrahmen: Richtlinien, Rollen, Risikoanalysen und Maßnahmen, mit denen ein Unternehmen Informationssicherheit systematisch plant, umsetzt und kontrolliert (Plan-Do-Check-Act). Es ist der Kern jeder ISO-27001-Zertifizierung und zugleich der praktische Umsetzungsweg für das Risikomanagement nach NIS2.

Ehrlich: Ein ISMS lebt von gelebten Prozessen, nicht von Aktenordnern. Wir betreiben HostSpezial selbst nach einem ISO/IEC 27001:2022-zertifizierten ISMS (Zertifikat-Nr. 202787) und kennen daher den Aufwand aus erster Hand — von der Asset-Inventur bis zum internen Audit.

SOAR ergänzt ein SIEM um automatisierte Reaktionen: Statt dass ein Analyst jeden Alarm manuell abarbeitet, lösen vordefinierte Playbooks Aktionen aus — etwa einen kompromittierten Host isolieren, ein Konto sperren oder ein Ticket eröffnen. Das senkt die Reaktionszeit (MTTR) und entlastet knappe SOC-Kapazitäten.

In der Praxis: Vollwertige SOAR-Suiten sind für KMU oft überdimensioniert. Wazuh bringt mit „Active Response" eine schlanke Automatisierungsbasis mit, die für die häufigsten Reaktionen ausreicht — ohne separate Lizenzkosten.

Ein TPM ist ein manipulationssicherer Krypto-Chip (heute meist TPM 2.0), der Schlüssel, Zertifikate und Integritätsmessungen hardwaregeschützt speichert. Es ist die Vertrauensbasis für Secure Boot, BitLocker-Festplattenverschlüsselung und Geräte-Attestierung — und harte Pflichtvoraussetzung für Windows 11.

Genau dieser TPM-2.0-Zwang ist einer der Hauptgründe, warum viele ältere Geräte den Sprung auf Windows 11 nicht schaffen und stattdessen über Windows-10-ESU, Hardware-Tausch oder Linux-Alternativen entschieden werden muss. Auch virtuelle Maschinen können über ein vTPM ein TPM emulieren — relevant für Win11-VMs unter Proxmox.

Managed Services bedeuten, dass ein Dienstleister definierte IT-Aufgaben dauerhaft übernimmt — Monitoring, Patch-Management, Backup, Security-Betrieb — geregelt über ein SLA mit zugesicherten Reaktionszeiten. Abgerechnet wird als planbare monatliche Pauschale statt im Stundenmodell, was Kosten kalkulierbar macht und proaktiven statt reaktiven Betrieb fördert.

Die meisten KMU lagern nicht alles aus, sondern gezielt einzelne Bereiche (Co-Managed IT). Ehrlich: Der Hebel liegt weniger im Preis als in Verfügbarkeit und Reaktionsgeschwindigkeit — eine interne Ein-Personen-IT kann keinen 24/7-Betrieb abbilden, ein Managed-Services-Team schon.

LXC sind System-Container: Sie teilen sich den Kernel des Hosts, verhalten sich aber wie eine eigenständige Linux-Maschine mit eigenem Dateisystem, Netzwerk und Prozessraum. Gegenüber einer vollwertigen Proxmox-VM sind sie deutlich ressourcenschonender und starten in Sekunden — ideal für viele kleine Linux-Dienste auf begrenzter Hardware.

In der Praxis: Wir nutzen LXC für leichtgewichtige Workloads (Reverse-Proxy, kleine Web-Dienste, interne Tools), VMs dagegen für Windows, Kernel-abhängige Software und harte Isolationsanforderungen. Proxmox VE 9.1 erlaubt zusätzlich, Standard-OCI-Images direkt als LXC zu starten.

GPAI bezeichnet im EU AI Act KI-Modelle mit allgemeinem Verwendungszweck — typischerweise große Sprachmodelle wie GPT, Llama oder Qwen, die nicht für eine einzelne Aufgabe trainiert sind. Für GPAI-Anbieter gelten eigene Transparenz- und Dokumentationspflichten; die Durchsetzung greift ab dem 2. August 2026, bei Verstößen drohen Bußgelder bis 15 Mio. € oder 3 % des weltweiten Jahresumsatzes.

Für Unternehmen, die solche Modelle nur einsetzen (nicht selbst anbieten), sind primär die Pflichten als Betreiber relevant — etwa KI-Kompetenz der Mitarbeiter (Art. 4) und Transparenz. Ein LLM on-premise zu betreiben verschiebt die Datenhoheit zurück ins eigene Haus und vereinfacht den DSGVO-Nachweis erheblich.