Verantwortlichkeiten: Was du selbst übernimmst und was nicht¶
Kurzfassung¶
| Das Plattform-Team kümmert sich um … | Du kümmerst dich um … |
|---|---|
| Den hub: firewall, Virtual WAN, DNS, Gateways, App Gateway, Bastion | Alles, was du in deinem Spoke bereitstellst |
| Einrichtung und Änderung der Baseline deines Spokes (Netzwerk, Gruppen, PIM, SPN, Key Vault, Storage, Log Analytics) | Patching, Backups, Lifecycle und Kontinuität deines Workloads |
| Policies auf Plattformebene und die Aktualität der Plattform | Das Beheben von Policy-Verstößen bei deinen Ressourcen |
| Zentrales Monitoring der Plattform | Monitoring und Alerting deiner Anwendung |
| Die Deployment-pipelines der Plattform | Deine eigenen Anwendungs-pipelines (mit deinem Spoke-SPN) |
| Die Umsetzung der von dir angefragten Firewallregeln | Das Anfragen der Regeln, die du brauchst, und zu wissen, warum du sie brauchst |
| Kostenmanagement der Plattform-subscriptions | Die Kosten deiner subscription |
Im Detail¶
| Bereich | Plattform-Team | Dein Team |
|---|---|---|
| Netzwerk: firewall, hub, Gateways, DNS, App Gateway | Durchführend und gesamtverantwortlich | Informiert |
| Inhalt der Firewallregeln (welcher Verkehr erlaubt ist) | Setzt um; Security Officer genehmigt | Beantragt Regeln, mit Begründung |
| IP-Plan | Weist zu und setzt um | Nennt, wie viele Adressen es braucht |
| Spoke-VNet, NSGs, Route Tables | Setzt per Code um | Verantwortlich für das, was es anfragt |
| Azure-Policy-Compliance | Verantwortlich im Plattform-Scope | Verantwortlich für die eigenen Ressourcen |
| Kosten und Budgets | Plattform-subscriptions | Die eigene subscription |
| Logs und Alerts | Plattform | Der eigene Workspace und die eigenen Alerts |
| Empfehlungen von Defender for Cloud und Advisor | Plattform-subscriptions | Die eigene subscription |
| RBAC und PIM | Spoke-Gruppen und PIM-Einstellungen | Mitglieder der eigenen Team-Gruppe |
| Entra-ID-Benutzer, Conditional Access, SOC | Identitäts-/Security-Teams des Kunden | – |
| pipelines und runner | Plattform-pipelines | Die eigenen Anwendungs-pipelines |
| Tags auf der subscription | Wendet sie an | Liefert die Werte und hält sie aktuell |
| Anwendungssicherheit, Datenklassifizierung, Autorisierung innerhalb der App | – | Vollständig |
| Incidents | Plattformkomponenten, während der vereinbarten Support-Zeiten | Die eigene Anwendung, unter dem eigenen SLA |
Verantwortlichkeiten nach Domäne (RACI)¶
Eine detailliertere Sicht für eine Plattform, in der das Plattform-Team die Baseline bereitstellt und der Workload-Eigentümer (du) den Workload. R = durchführend (führt es aus), A = gesamtverantwortlich (verantwortet das Ergebnis), C = konsultiert (berät und setzt Standards).
| Domäne | Plattform-Team | Workload-Eigentümer |
|---|---|---|
| Virtuelle Infrastruktur (landing zone, Baseline, gemeinsames Netzwerk) | C + A | R: stellt VMs, Storage, Ressourcen bereit |
| Netzwerksicherheit (firewall-Policy, NSG-Standards, Routing) | C + A | R: Sicherheitsregeln, Subnets, Endpunkte, Zugriff |
| OS-Management (Images, Hardening-Policy, Agents) | C | A + R: OS-Konfiguration, Virenschutz, Fehlerbehebung |
| Monitoring und Logging | C: Standards, Plattform-Alerts, Aufbewahrung | A + R: Anwendungs-Logging, Alerts, Dashboards, Incident-Nachverfolgung |
| Backup und Disaster Recovery | C + A: Backup-Policy und DR-Ansatz, wo bereitgestellt | R: Backups, Wiederherstellungen, Aufbewahrung, Restore-Tests |
| Business Continuity / Hochverfügbarkeit | C: Beratung zur HA-Architektur | A + R: redundante Apps, Failover-Tests, Kontinuitätspläne |
| Ressourcen-Governance (Policies, Tags, Kosten) | C: Dashboards, Policies, Tag-Policy | A + R: Ressourcen taggen, Nutzung berichten, optimieren, Reservierungen |
| Identität und Zugriff (RBAC, PIM, Gruppen) | C: Baseline-Policies, onboarding | A + R: Team-Gruppen, MFA, Autorisierungsgruppen |
| Datenschutz und Verschlüsselung | C + A: Verschlüsselungs-Policy, Beratung zum Schlüssel-Lifecycle | A + R: Verschlüsselungsentscheidungen, Schlüsselrotation, Key-Vault-Verwaltung |
| Compliance und Auditing | C: Beratung zu Kontrollen, Audit-Unterstützung | A + R: Selbstbewertung, Nachweise, Audit-Trail |
| Datenaufbewahrung und -löschung | C: Beratung, Lifecycle-Tooling | A + R: Aufbewahrung festlegen, Daten löschen, Löschung nachweisen |
| Incident-Management und Meldung von Datenschutzverletzungen | C: Prozess, Runbooks, forensische Unterstützung | A + R: Incidents erkennen, Datenschutzverletzungen melden, kommunizieren |
| Durchsetzung der IAM-Policy | C: schreibt Baseline-Policies, genehmigt Änderungen | A + R: eigene Policies, Ausnahmeanfragen, Zugriff gewähren und entziehen |
| Anwendungssicherheit | C: Aufsicht über Testergebnisse | A + R: Patching, Code-Audits, Penetrationstests, App-Konfiguration |
| Konfigurationsmanagement | C + A: Baseline-Policies, Vorlagen | R: Ressourcen erstellen, Policy einhalten, Tags, Einstellungen |
| Update-Management | C + A: Patch-Rhythmus, Tooling für Plattformkomponenten | R: Anwendungs- und OS-Updates, Patching, Rollback (siehe Updates und Patching, wenn du Managed VMs nutzt) |
| Schwachstellenmanagement | C: Scan-Tools, Berichte, Beratung | A + R: patchen, Risiko bewerten, mindern, erneut testen |
| Eigentümerschaft und Verantwortlichkeit | C: Rollen, Änderungskontrolle, Eigentümer | A + R: Daten- und Anwendungseigentümer benennen, über Assets entscheiden, eskalieren |
Deine Organisation entscheidet über die Details
Diese Matrix ist eine Referenz. Wer „das Plattform-Team“ ist, hängt von deinem Betriebsmodell ab (XMMS im Rahmen eines Managed-Service-Vertrags oder dein eigenes Plattform-Team). Zu den Security- und Compliance-Frameworks, auf die Organisationen sie abbilden, gehören ISO 27001, NEN 7510 und NIS2. Frag dein Plattform-Team, welche Domänen dein Vertrag oder deine interne Vereinbarung abändert.
Die RASCI-Matrizen lesen
Die betriebliche Seite der Aufteilung, mit mehr Aktivitäten und der Bedeutung der Buchstaben, steht in Betriebsverantwortlichkeiten.
Accountability im Managed-Modell
Bei einem Managed Service kann die Accountability bei der Kundenorganisation bleiben, während das Plattform-Team die Arbeit erledigt. Lies dann ein A in der Spalte des Plattform-Teams als „accountable für den eigenen Verantwortungsbereich des Plattform-Teams“. Dein Vertrag legt fest, was gilt. Eine Aufgabe hat genau ein A und mindestens ein R. Siehe Betriebsmodelle.
Rollen in deinem Team¶
Ein Workload hat normalerweise diese technischen Rollen. Benenne die Personen und halte die Liste aktuell.
| Rolle | Verantwortung |
|---|---|
| Owner | Besitzt den Workload und ist für alles darin verantwortlich, einschließlich aktueller Tags und Kontakte |
| Approver | Genehmigt Änderungen und erhöhten Zugriff auf die Produktion, zum Beispiel PIM-Anfragen |
| Engineer | Baut die Umsetzung und überwacht sie |
| Reader | Schaut zu, für Gäste und unterstützende Engineers oder Architekten |
Wie diese Rollen auf die Gruppen deines Spokes abgebildet werden, steht in Zugriff, Gruppen und PIM und im Identitäts- und Zugriffsmodell. Rollen innerhalb deiner Anwendung (zum Beispiel Fachanwender und ihre Administratoren) liegen immer bei dir.
Managed Spoke¶
Wenn du einen Managed Spoke gewählt hast (Service-Typen, Managed Spokes), baut, deployt, wartet und überwacht das Plattform-Team auch die Azure-Ressourcen deines Workloads, im Rahmen einer separaten Vereinbarung. Was sich nicht ändert:
- Du bleibst accountable für den Workload, seine Daten und seine Sicherheitsklassifizierung.
- Du entscheidest über die Anforderungen und nimmst die Änderungen ab.
- Du behältst deine eigene Anwendungslogik, die Rollen auf Anwendungsebene und die Incident-Behandlung für deine Benutzer.
Frag in der Vereinbarung nach dem Umfang und dem Servicefenster.
Was wir von dir erwarten¶
- Arbeite innerhalb der Policies und Standards der Plattform.
- Organisiere Betrieb und Lifecycle-Management deines Workloads.
- Benenne einen Product Owner und einen technischen Ansprechpartner und halte sie aktuell.
- Halte die subscription-Tags korrekt.
- Melde Plattformprobleme über den vereinbarten Support-Kanal, mit dem subscription-Namen und dem, was du versucht hast.
- Befolge die Guardrails für Workload-Teams: keine manuellen Änderungen an der Produktion, Vier-Augen-Review, private Konnektivität und Secrets in einem Vault.