Servicetypes: Core, Direct en Additional¶
Het platform biedt zijn services aan in drie typen. Het type zegt wie een service kan aanvragen, hoe die is ingericht en of er extra kosten of een aparte overeenkomst bij horen. Welke services op jouw platform bestaan, hangt af van wat is afgenomen en ingeschakeld; vraag het aan je platformteam.
| Type | Wat het is | Wie vraagt het aan | Extra overeenkomst of vergoeding |
|---|---|---|---|
| Core | De basis waar elke andere service van afhangt. Centraal beheerd en onderhouden. | Niemand: het is er altijd | Nee |
| Direct | Services die een workload team rechtstreeks kan aanvragen. Ingericht voor het team en afgeschermd tot zijn workload. | Workload team, via een standaardwijziging | Nee, onderdeel van het platform |
| Additional | Services bovenop de baseline, met een eigen scope | Workload team, na een intake | Meestal ja: een aparte vergoeding, een apart service level en, waar nodig, een implementatie-SOW |
In het managed-model (Beheermodellen) zijn de additional services het deel van het contract dat verder gaat dan de platformbaseline. In het zelfbeheermodel zijn het services die je eigen platformteam kan besluiten aan te bieden.
Core services¶
Core services zijn de nutsvoorzieningen van het platform. Door ze centraal te beheren blijven ze betrouwbaar, veilig en kostenefficiënt.
| Core service | Wat het omvat | Meer |
|---|---|---|
| Connectivity | Virtual WAN en virtual hub per regio, VPN- en ExpressRoute-gateways naar datacenters en filialen, de private DNS resolver, het centrale IP-plan en IP groups | Architectuur, DNS-ontwerp |
| Firewalling | Het centrale Azure Firewall policy, Application Gateway met Web Application Firewall (WAF), baseline NSG's, host-based firewalls binnen VM's | Indeling van firewallregels |
| Governance | Management groups, Azure Policy en initiatives, tags, RBAC-model, kostenbeheer | Governance |
| Monitoring | Action groups, Azure Monitor Baseline Alerts, Service Health-alerts, centrale Log Analytics | Operationele verantwoordelijkheden |
| Security platforms | Microsoft Defender for Cloud en, indien ingeschakeld, Microsoft Sentinel | Identiteits- en toegangsmodel |
Firewalling in meer detail¶
Firewalling is gelaagd. Elke laag heeft een andere taak.
| Component | Beschermt |
|---|---|
| Azure Firewall (hub) | Verkeer tussen spokes, naar on-premises netwerken, naar andere landing zones en naar internet |
| Application Gateway met WAF | Inkomend webverkeer van internet naar workloads. De WAF blokkeert veelvoorkomende exploits (bijvoorbeeld SQL injection en cross-site scripting). |
| Network security groups (NSG) | Verkeer in en uit een subnet. Elk subnet krijgt een NSG, zodat connectiviteit zo beperkt mogelijk blijft. |
| Host-based firewall | Verkeer op de machine zelf. Eigendom van het workload team. |
| Een bestaande on-premises firewall | Verkeer van de andere kant van een VPN- of ExpressRoute-verbinding, als je die hebt. Regels moeten meestal aan beide kanten worden aangepast. |
Een set principes voor firewallregels, gebruikt door meerdere managed platformen:
| Principe | Reden |
|---|---|
| Gebruik versleutelde protocollen, tenzij de workload dat niet kan | Versleuteling houdt gevoelige data geheim |
| Regels zijn eigendom van een workload | Het moet altijd duidelijk zijn wie de eigenaar van een regel is |
| Houd productie- en niet-productieregels gescheiden en sta geen verkeer tussen beide toe | Productiedata mag niet in niet-productieomgevingen worden verwerkt |
| Houd interne en internetgerichte regels gescheiden | Extern verkeer is een grotere dreiging |
| Inkomend verkeer naar een spoke wordt geweigerd, tenzij de workload het nodig heeft | Onnodige communicatie is een direct risico |
| Definieer regels bij de bestemming, alleen als inkomend verkeer | De firewall is gedeeld. Als workload B een regel kon toevoegen die workload A opent, zou workload A open staan zonder eigen goedkeuring. |
Hoe je de regelbestanden indeelt, staat in Indeling van firewallregels.
Application Gateway en WAF: typische instellingen¶
Het Application Gateway-entrypoint wordt als code geconfigureerd. Typische, aanpasbare instellingen:
| Instelling | Typische waarde | Waarom |
|---|---|---|
| Tier | WAF v2 | Schakelt de WAF in voor elk request |
| Capaciteit | Autoscale met minimaal twee instances en een vast maximum | Redundantie, met een plafond op de kosten |
| HTTP/2 | Ingeschakeld | |
| TLS policy | Een voorgedefinieerd policy met minimaal TLS 1.2 | |
| WAF-modus | Prevention, met de door Microsoft beheerde rule set en inspectie van de request body | Blokkeert overeenkomende requests actief |
| Log scrubbing | Ingeschakeld | Maskeert gevoelige waarden in WAF-logs |
| Certificaten | Opgeslagen in een eigen Key Vault; de gateway leest ze met een managed identity | |
| Toegang | Alleen het platformteam, via PIM | Resources staan in een eigen resource group |
Typische afhandeling van false positives: het workload team vraagt een uitzondering aan, het platformteam vraagt security om goedkeuring en de uitzondering wordt daarna toegevoegd als exclusion voor de specifieke regel en het specifieke request-argument. Een regel die Microsoft zelf adviseert uit te schakelen vanwege false positives, kan platformbreed worden uitgeschakeld. Houd een lijst bij van exclusions en uitgeschakelde regels met hun motivatie.
De waarden hierboven zijn voorbeelden. De werkelijke instellingen staan in je platformconfiguratie (Application Gateway).
Direct services¶
Direct services worden aangevraagd door het workload team en ingericht voor dat team.
| Service | Wat het is |
|---|---|
| Workload en spoke | Een subscription met netwerk, groepen, PIM, service principal, Key Vault, storage en Log Analytics, verbonden met de hub. Zie Wat je krijgt en Spoke-varianten. |
| Bastion-toegang | Een centrale Azure Bastion-host, zodat teams er geen eigen uitrollen. Zie Verbinden met VM's en Ontwerpnotities voor Bastion. |
| Build agents | Self-hosted pipeline agents binnen het netwerk, om private resources te bereiken. Zie Toegang voor build agents en de container agent pool. |
| Developer-toegang via VPN | Point-to-site VPN zodat engineers private resources in hun spokes kunnen bereiken. Zie Developer-toegang met point-to-site VPN. |
Ontwerpnotities voor Bastion¶
Als het platform een centrale Bastion-host aanbiedt, zijn dit de instellingen die ertoe doen in een Virtual WAN-ontwerp:
| Instelling | Waarde | Waarom |
|---|---|---|
| Tier | Standard | Nodig voor verbindingen op IP-adres, wat een Virtual WAN-ontwerp vereist |
| IP-based connection | Ingeschakeld | Laat Bastion verbinden met een privé-IP-adres in een andere spoke |
| Native client support | Ingeschakeld | Maakt de Azure CLI of native RDP- en SSH-clients mogelijk, bijvoorbeeld vanaf macOS |
| Copy and paste | Ingeschakeld | Makkelijker om scripts en commando's te plakken |
| Aantal instances | Twee of meer | Redundantie |
Bastion staat in een eigen virtual network met een subnet met de naam AzureBastionSubnet. De firewall staat alleen SSH (22) en RDP
(3389) toe vanaf dat subnet naar de adresranges van de workload. Toegang wordt geregeld met een Entra ID-groep met Reader
op de Bastion-resource group, gevuld met teamgroepen (niet met individuele gebruikers). Gebruikers hebben het IP-adres van de
doelmachine en de credentials ervoor nodig.
Additional services¶
Additional services vragen om een intake, omdat hun scope afhangt van de workload. Een typische overeenkomst bevat:
- een service level addendum met de scope, het servicevenster en de beschikbaarheid van dagelijkse support,
- een implementatie-SOW als de workload eerst compliant met de service moet worden gemaakt,
- een vergoeding,
- rapportage aan het workload team.
Voorbeelden:
| Service | Wat verandert ten opzichte van een normale spoke |
|---|---|
| Managed spoke (servicebeschrijving) | Het platformteam bouwt, deployt, onderhoudt en monitort ook de Azure-resources van de workload, als infrastructure as code bovenop de standaard spoke |
| Managed virtual machines | Het platformteam doet de initiële configuratie en de patching van het besturingssysteem. Zie Managed virtual machines. |
| Base Fabric Data Platform | Een beheerde Microsoft Fabric-omgeving (capacity, workspaces, private connectiviteit, connections) bovenop een spoke. Zie Base Fabric Data Platform. |
| Integration Platform | Beheerde integratiebouwstenen (Service Bus, Logic Apps, Function Apps, Container Apps, Data Factory) met gedeelde API Management en Event Hubs. Zie Integration Platform. |
| AI Platform | Een gedeeld Azure AI Foundry-account met een project per workload en datastores voor agents. Zie AI Platform. |
| AKS Platform | Een beheerde Kubernetes-variant (AKS in Azure of op Azure Local) met baseline, identity en securitypolicy. Zie AKS Platform. |
| Agentic Developer Portal | Een optioneel, op Backstage gebaseerd portaal met een catalogus van workloads, kosten-, netwerk-, security- en compliance-overzichten, AI-agents en een MCP-server. Zie Agentic Developer Portal. |
| Andere managed platformen (bijvoorbeeld virtual desktops) | Een managed variant van de service, aangeboden wanneer het platformteam die heeft gebouwd |
Spoke-varianten¶
| Variant | Gebruik het wanneer | Wat verschilt |
|---|---|---|
| Standaard spoke | Normaal geval | De default: één spoke per omgeving, één voor productiedata en de andere voor niet-productiedata |
| Sandbox | Experimenten met Azure | Een subscription in de management group sandbox zonder verbinding met de hub, andere workloads of interne netwerken. Zie Nieuwe sandbox-subscription. |
| Managed spoke | Het team leert Azure nog, wil niet investeren in de technische vaardigheden, of heeft te weinig mensen om de workload technisch te ondersteunen | Dezelfde baseline als de standaard spoke. Het platformteam onderhoudt ook de workloadresources, binnen een aparte overeenkomst. |
Voor een managed spoke is het gebruikelijke proces: een intake met het platformteam, een beoordeling van de huidige of nieuwe oplossing, een service level addendum, het bouwen en deployen van de infrastructure as code, support binnen het afgesproken venster en rapportage aan het workload team. Het workload team blijft verantwoordelijk voor de workload: zie Verantwoordelijkheden.
Aanvragen voor nieuwe services¶
Een aanvraag voor nieuwe gedeelde functionaliteit wordt eerst beoordeeld door architectuur, operations en security. Het is óf een uitbreiding van een bestaande service (bijvoorbeeld een nieuwe optie in een feature flag) óf een nieuwe service. Een feature waarvoor nieuwe Terraform nodig is, is een ontwikkelwijziging in de coderepository, geen standaardwijziging: zie Platformfilosofie.