Verantwoordelijkheden: wat regel je zelf en wat niet¶
Kort samengevat¶
| Het platformteam regelt… | Jij regelt… |
|---|---|
| De hub: firewall, Virtual WAN, DNS, gateways, App Gateway, Bastion | Alles wat je in je spoke deployt |
| Het opzetten en wijzigen van de baseline van je spoke (netwerk, groepen, PIM, SPN, Key Vault, storage, Log Analytics) | Patching, back-ups, lifecycle en continuïteit van je workload |
| Policies op platformniveau, en het platform up-to-date houden | Het oplossen van policy-overtredingen op jouw resources |
| Centrale monitoring van het platform | Monitoring en alerting van jouw applicatie |
| De deployment-pipelines van het platform | Je eigen applicatiepipelines (met de SPN van je spoke) |
| Het implementeren van firewallregels die je aanvraagt | De regels aanvragen die je nodig hebt en weten waarom je ze nodig hebt |
| Kostenbeheer van de platform-subscriptions | De kosten van je subscription |
In detail¶
| Gebied | Platformteam | Jouw team |
|---|---|---|
| Netwerk: firewall, hub, gateways, DNS, App Gateway | Verantwoordelijk en eindverantwoordelijk | Geïnformeerd |
| Inhoud van firewallregels (welk verkeer is toegestaan) | Implementeert; security officer keurt goed | Vraagt regels aan, met een rationale |
| IP-plan | Wijst toe en implementeert | Geeft aan hoeveel adressen nodig zijn |
| Spoke-VNet, NSG's, route tables | Implementeert via code | Eindverantwoordelijk voor wat het aanvraagt |
| Azure Policy-compliance | Eindverantwoordelijk op platformscope | Eindverantwoordelijk voor de eigen resources |
| Kosten en budgetten | Platform-subscriptions | Eigen subscription |
| Logs en alerts | Platform | Eigen workspace en alerts |
| Aanbevelingen van Defender for Cloud en Advisor | Platform-subscriptions | Eigen subscription |
| RBAC en PIM | Spoke-groepen en PIM-instellingen | Leden van de eigen teamgroep |
| Entra ID-gebruikers, Conditional Access, SOC | Identity-/securityteams van de klant | – |
| Pipelines en runners | Platformpipelines | Eigen applicatiepipelines |
| Tags op de subscription | Past ze toe | Levert de waarden aan en houdt ze actueel |
| Applicatiebeveiliging, dataclassificatie, autorisatie binnen de app | – | Volledig |
| Incidenten | Platformcomponenten, tijdens de afgesproken supporturen | Eigen applicatie, onder eigen SLA |
Verantwoordelijkheden per domein (RACI)¶
Een gedetailleerder overzicht, voor een platform waarin het platformteam de baseline levert en de workload owner (jij) de workload. R = verantwoordelijk uitvoerend (voert het uit), A = eindverantwoordelijk (is eigenaar van het resultaat), C = geraadpleegd (adviseert en stelt standaarden vast).
| Domein | Platformteam | Workload owner |
|---|---|---|
| Virtuele infrastructuur (landing zone, baseline, gedeeld netwerk) | C + A | R: deployt VM's, storage, resources |
| Netwerkbeveiliging (firewallbeleid, NSG-standaarden, routing) | C + A | R: securityregels, subnets, endpoints, toegang |
| OS-beheer (images, hardeningbeleid, agents) | C | A + R: OS-configuratie, antivirus, troubleshooting |
| Monitoring en logging | C: standaarden, platformalerts, retentie | A + R: applicatielogging, alerts, dashboards, opvolging van incidenten |
| Back-up en disaster recovery | C + A: back-upbeleid en DR-aanpak waar geleverd | R: back-ups, herstel, retentie, hersteltests |
| Bedrijfscontinuïteit / hoge beschikbaarheid | C: advies over HA-architectuur | A + R: redundante apps, failover-tests, continuïteitsplannen |
| Resource governance (policies, tags, kosten) | C: dashboards, policies, tagpolicy | A + R: resources taggen, gebruik rapporteren, optimaliseren, reserveringen |
| Identiteit en toegang (RBAC, PIM, groepen) | C: baseline-policies, onboarding | A + R: teamgroepen, MFA, autorisatiegroepen |
| Databescherming en versleuteling | C + A: versleutelingsbeleid, advies over sleutellifecycle | A + R: versleutelingskeuzes, sleutelrotatie, Key Vault-beheer |
| Compliance en auditing | C: advies over beheersmaatregelen, auditondersteuning | A + R: zelfbeoordeling, bewijs, audit trail |
| Dataretentie en verwijdering | C: advies, lifecycle-tooling | A + R: retentie instellen, data verwijderen, verwijdering aantonen |
| Incidentbeheer en melding van datalekken | C: proces, runbooks, forensische ondersteuning | A + R: incidenten detecteren, datalekken melden, communiceren |
| Handhaving van IAM-beleid | C: schrijft baseline-policies, keurt wijzigingen goed | A + R: eigen policies, uitzonderingsaanvragen, toegang verlenen en intrekken |
| Applicatiebeveiliging | C: toezicht op testresultaten | A + R: patching, code-audits, penetratietests, app-configuratie |
| Configuratiebeheer | C + A: baseline-policies, templates | R: resources aanmaken, voldoen aan policy, tags, instellingen |
| Updatebeheer | C + A: patchcadans, tooling voor platformcomponenten | R: applicatie- en OS-updates, patching, rollback (zie Updates en patching als je managed VM's gebruikt) |
| Kwetsbaarhedenbeheer | C: scantools, rapporten, advies | A + R: patchen, risico beoordelen, mitigeren, hertesten |
| Eigenaarschap en verantwoording | C: rollen, change control, eigenaren | A + R: data- en applicatie-eigenaar benoemen, besluiten over assets, escaleren |
Je organisatie bepaalt de details
Deze matrix is een referentie. Wie "het platformteam" is, hangt af van je beheermodel (XMMS onder een managed-servicecontract, of je eigen platformteam). Security- en compliancekaders waarop organisaties dit mappen zijn onder andere ISO 27001, NEN 7510 en NIS2. Vraag je platformteam welke domeinen door je contract of interne afspraak anders worden ingevuld.
De RASCI-matrices lezen
De operationele kant van de verdeling, met meer activiteiten en de betekenis van de letters, staat in Operationele verantwoordelijkheden.
Accountability in het managed model
Bij een managed service kan de accountability bij de klantorganisatie blijven terwijl het platformteam het werk doet. Lees een A in de kolom van het platformteam dan als "accountable voor de eigen scope van het platformteam". Je contract bepaalt welke situatie geldt. Een taak heeft precies één A en minstens één R. Zie Beheermodellen.
Rollen in je team¶
Een workload heeft normaal gesproken deze technische rollen. Benoem de mensen en houd de lijst actueel.
| Rol | Verantwoordelijkheid |
|---|---|
| Owner | Is eigenaar van de workload en accountable voor alles daarin, inclusief actuele tags en contactgegevens |
| Approver | Keurt wijzigingen en verhoogde toegang tot productie goed, bijvoorbeeld PIM-aanvragen |
| Engineer | Bouwt en houdt toezicht op de implementatie |
| Reader | Kijkt mee, voor gasten en ondersteunende engineers of architecten |
Hoe deze rollen aansluiten op de groepen van je spoke staat in Toegang, groepen en PIM en Identiteits- en toegangsmodel. Rollen binnen je applicatie (bijvoorbeeld zakelijke gebruikers en hun beheerders) zijn altijd van jou.
Managed spoke¶
Als je voor een managed spoke hebt gekozen (Servicetypen, Managed spokes), bouwt, deployt, onderhoudt en monitort het platformteam ook de Azure-resources van je workload, binnen de scope van een aparte overeenkomst. Wat niet verandert:
- je blijft accountable voor de workload, de data en de beveiligingsclassificatie,
- jij bepaalt de requirements en accepteert de wijzigingen,
- je houdt je eigen applicatielogica, rollen op applicatieniveau en incidentafhandeling voor je gebruikers.
Vraag in de overeenkomst naar de scope en het servicevenster.
Wat we van je verwachten¶
- Werk binnen de policies en standaarden van het platform.
- Organiseer het beheer en lifecyclemanagement van je workload.
- Benoem een product owner en een technisch aanspreekpunt, en houd die actueel.
- Houd de tags van de subscription correct.
- Meld platformproblemen via het afgesproken supportkanaal, met de naam van de subscription en wat je hebt geprobeerd.
- Volg de guardrails voor workload teams: geen handmatige wijzigingen in productie, vierogenreview, private connectiviteit en secrets in een vault.