Betrieb
Cloud vs. On‑Premises vs. Hybrid
Vergleich der drei Betriebsmodelle entlang der Dimensionen Implementierung, Administration, Kosten, Sicherheit, Monitoring/Auditierbarkeit, Datenschutz/Datenhoheit und Nutzererlebnis. Der Fokus liegt auf technischen Implikationen und Betriebsmechanik.
Vergleichstabelle
| Dimension | Cloud | On-Premises | Hybrid |
|---|---|---|---|
| Implementierung | Guardrails zuerst: Landing Zones, Entra‑Baseline, Policies/IaC. Schnelle Provisionierung, aber Risiko von Wildwuchs ohne Governance. | Langsamerer Rollout (Hardware, Netzwerk, Kapazität), dafür volle Kontrolle über Plattform‑Bausteine. Komplexität steigt bei Legacy‑Abhängigkeiten. | Zusätzliches Enablement (Entra Connect, Arc, Netzwerk‑Kopplung). Standardisierung zwingend, sonst driftet Cloud und DC‑Welt auseinander. |
| Administration | Schwerpunkt auf RBAC, Tenant‑Betrieb, Policy‑Management, Plattform‑Updates. Automatisierung über IaC/CI‑Pipelines möglich. | Betriebssystem‑ und Applikations‑Patch, GPO‑Pflege, Backup/Restore, Hardware‑Lifecycle. Hoher Aufwand für Standardisierung über viele Zonen. | Doppelter Betrieb: Cloud‑Controls plus On‑Prem‑Domänenbetrieb. Klare Verantwortlichkeiten und Runbooks sind essenziell. |
| Kosten | OPEX‑getrieben: Verbrauch, Storage‑Retention, SIEM‑Ingestion. Kostensteuerung über Tags, Budgets, Retention‑Tiering, Reserved Capacity. | CAPEX‑getrieben: Hardware, Lizenzen, Rechenzentrums‑Kosten. Planbar, aber Risiko durch Überprovisionierung. | Kombination aus CAPEX + OPEX. Zusätzliche Lizenz‑ und Integrationskosten (z. B. Arc, SIEM, Netzwerk). |
| Sicherheit | Starke Plattform‑Controls (CA, PIM, Policy, CSPM) – wenn konsequent aktiviert. Shared Responsibility muss operationalisiert werden. | Volle Verantwortung beim Betrieb: Hardening, Patch, Netzwerk‑Segmente, DC‑Schutz. AD ist häufig „Crown Jewel“ – Tiering/PAW erforderlich. | Größere Angriffsfläche durch Brücken (Sync, Federation, Netz). Detection muss Cloud + On‑Prem korrelieren (XDR/SIEM). |
| Monitoring / Audit | Zentrale Telemetrie (Log Analytics/Sentinel), Audit‑APIs, Security Score. Retention & Export (Storage/Archive) planen. | Event Forwarding, EDR‑Telemetrie, klassische Monitoring‑Stacks. Audit‑Nachweise sind möglich, aber häufig verteilt. | Zentrale Korrelation nötig: Identity, Endpoint, Server, Cloud. Datenquellen‑Hygiene entscheidet über Detection‑Qualität. |
| Datenschutz / Datenhoheit | Datenresidenz über Regionen/Policies; Compliance‑Artefakte verfügbar. Kritisch: Tenant‑Konfiguration, Gast‑/Sharing‑Policies, DLP/Labels. | Maximale Datenhoheit im eigenen RZ, aber hoher Aufwand für Security‑Nachweise und Prozesse. | Datenklassifizierung entscheidet, was wohin darf. Labels/DLP und klare Datenflüsse sind Pflicht. |
| Nutzererlebnis | Hohe Agilität, Self‑Service, moderne Auth‑Flows. Risiko: Security‑Reibung ohne abgestimmte CA‑Policies. | Stabil für interne Workloads, aber häufig weniger flexibel bei Remote/Modern Workplace. | Best‑of‑Both möglich, aber nur mit sauberer Identity‑Journey und konsistenter Policy‑Logik. |
Empfohlene Betriebsbausteine
Identity‑Betriebsmodell
- ✓Break‑Glass, CA‑Baseline, PIM‑Prozess, Reviews
- ✓Service‑Principals: Ownership, Secrets/Cert‑Rotation
- ✓Hybrid: Sync‑Monitoring, privilegierte Pfade minimieren
Baseline‑ & Drift‑Kontrolle
- ✓Cloud: Policy‑Enforcement, Secure Score, CSPM‑Backlog
- ✓On‑Prem: Baselines/GPO, Config Audits, Patch Compliance
- ✓Exceptions: dokumentiert, befristet, überwacht
Betriebsmodell: Von „Run“ zu „Run + Prove“
RACI (Beispiel) – Plattform, Security, SOC, Fachbereiche
Für Audit & Betrieb entscheidend: klare Verantwortlichkeiten, definierte Eskalationspfade, und ein Evidence‑Repository (Runbooks, Reports, Decision Records).
Für Audit & Betrieb entscheidend: klare Verantwortlichkeiten, definierte Eskalationspfade, und ein Evidence‑Repository (Runbooks, Reports, Decision Records).
| Capability | R (Responsible) | A (Accountable) | C (Consulted) | I (Informed) |
|---|---|---|---|---|
| Identity Policies (CA, MFA, PIM) | IAM/Platform | CISO | SOC, Compliance | IT Ops |
| Endpoint Baselines (Intune/MDE) | Workplace | IT Ops Lead | Security | Fachbereiche |
| Logging & SIEM (Sentinel) | SOC | CISO | Platform | IT Ops |
| Patch & Vulnerability | IT Ops | IT Ops Lead | Security | Fachbereiche |
| Incident Response (IR) | SOC | CISO | IT Ops, Legal | Management |
SERVICE TIERS
- ✓8x5 – Standard‑IT, geplante Changes, IR nach Bedarf
- ✓12x5 – erweiterte Reaktionsfenster, SOC‑Kopplung
- ✓24x7 – KRITIS/NIS2‑nahe Anforderungen, feste On‑Call‑Rotation
Entscheiderfrage:
Welche Business‑Impact‑Klassen haben Systeme?
Daraus folgt Service Tier + Kosten.
Welche Business‑Impact‑Klassen haben Systeme?
Daraus folgt Service Tier + Kosten.
SLOs
- ✓MTTD kritische Incidents: < 15 min (24x7)
- ✓MTTR containment: < 4 h (kritisch)
- ✓Patch Compliance: 95% innerhalb 14 Tagen (kritisch)
- ✓Backup Restore Test: monatlich (Tier‑0), quartalsweise (sonst)
- ✓CA Policy Drift: 0 ungeprüfte Änderungen (Change Gate)
In audit‑relevanten Umgebungen reicht „läuft“ nicht aus. Betriebsfähigkeit bedeutet: planbare Changes, definierte Reaktionszeiten, und eine belastbare Nachweiskette.
Service- & SLO-Definition
- ✓Servicekatalog (Identity, Endpoint, Plattform, SOC, Data)
- ✓SLOs/SLAs (z. B. Incident‑Reaktion, Patch‑Fenster, Restore‑Zeit)
- ✓KPIs: Coverage, Drift, MTTD/MTTR, Exception‑Aging
Change & Release
- ✓Policy‑Änderungen wie Releases behandeln (Staging/Pilot/Wellen)
- ✓Standard Changes (vordefiniert) vs. Emergency Changes
- ✓Rollback‑Kriterien und technische Guardrails
Runbooks & Übungen
- ✓IR‑Runbooks (Defender/Sentinel) + Tabletop‑Exercises
- ✓Backup/Restore‑Tests + DR‑Tests mit Protokoll
- ✓Privileged Access Übungen (Break‑Glass, PIM Approvals)
Was möchten Sie jetzt tun?
Die Spezialisten der XELANED stehen Ihnen für die nächsten Schritte jederzeit zur Verfügung. Gemeinsam priorisieren wir Themen, klären Abhängigkeiten und wählen ein Vorgehen, das fachlich und organisatorisch zu Ihrer Umgebung passt.
Projektplanung
Wir besprechen Scope, Abhängigkeiten und erstellen eine belastbare Vorgehensplanung.