Ontwerpprincipes en guardrails¶
Platformfilosofie legt uit hoe het product is gebouwd. Deze pagina gaat over de regels voor het gebruik van het platform: de guardrails die workload teams en het platformteam volgen. Ze vormen een aanbevolen set. Je organisatie bepaalt welke gelden en wie ze handhaaft.
Policy, standaard, best practice¶
Geef bij elke regel aan hoe bindend die is.
| Niveau | Betekenis | Voorbeeld |
|---|---|---|
| Policy | Moet worden gevolgd. Bij voorkeur afgedwongen door technologie. | Storage accounts zijn niet bereikbaar vanaf het publieke internet |
| Standaard | Moet worden gevolgd, tenzij een afwijking is gemotiveerd | Een standaardtaal of -tool, tenzij een vereiste library niet beschikbaar is |
| Best practice | Aanbevolen, niet verplicht | Tests draaien tegen gedeelde datamodellen |
Guardrails voor workload teams¶
| # | Guardrail | Waarom |
|---|---|---|
| 1 | Geen handmatige wijzigingen in productie. Gebruik een deployment pipeline. | Handmatige wijzigingen hebben geen historie (wat is er gewijzigd, door wie, waarom) en zijn foutgevoelig |
| 2 | Automatiseer zoveel mogelijk: infrastructure as code, pipelines, scripts | Handmatige taken zijn niet reproduceerbaar en veroorzaken fouten |
| 3 | Vierogenprincipe voor elke wijziging in productie, bijvoorbeeld een gereviewde pull request | Een onafhankelijke controle vangt fouten op |
| 4 | Hergebruiken vóór kopen vóór bouwen | Hergebruiken en kopen zijn op de lange termijn meestal goedkoper |
| 5 | Geef de voorkeur aan cloud-native boven third-party, en aan SaaS boven PaaS boven IaaS | Makkelijker te integreren in de rest van het landschap |
| 6 | You build it, you run it, you own it | Ontwerp voor beheer, want je gaat het zelf beheren |
| 7 | Observability mag geen toegang tot de data vereisen | Operators kunnen de gezondheid verifiëren zonder gevoelige inhoud te zien |
| 8 | Isoleer ontwikkeling: het werk van het ene team mag dat van een ander team niet breken | Deploy vaak naar productie in plaats van big-bang-releases |
| 9 | Test de cruciale onderdelen | Geen 100% dekking, maar tests die refactoring en continuous deployment beschermen |
| 10 | Log in met Entra ID met MFA. Geef toegang aan groepen, nooit aan individuen. | Eén identiteit, één controlepunt |
Best practices die erbij horen: lint en test op security in de pipeline, geef de voorkeur aan kleine best-of-breed-tools boven één tool die alles doet, houd het aantal verbindingen tussen resources laag, standaardiseer API's en volg de best practices van de services die je gebruikt.
Guardrails voor infrastructuur¶
| # | Guardrail | Waarom |
|---|---|---|
| 1 | Publieke toegang tot een workload loopt via de centrale ingangen: HTTP(S) via de Application Gateway, andere protocollen via de Azure Firewall | Eén plek om inkomend verkeer te inspecteren en te beheersen |
| 2 | Geen publieke IP-adressen op workloadresources | Volgt uit de vorige guardrail |
| 3 | Gebruik private connectiviteit. Publieke toegang tot resources is standaard geblokkeerd; private endpoints hebben de voorkeur. Als dat niet kan, sta dan alleen specifieke subnets of IP-adressen toe. | Houdt dataverkeer van het internet af |
| 4 | Gebruik de nieuwste TLS-versie die een service biedt | Security |
| 5 | Omgevingen zijn volledig geïsoleerd: elke omgeving heeft eigen resources, configuratie en afhankelijkheden | Voorkomt dat problemen in de ene fase doorwerken in een andere, en ondersteunt parallelle ontwikkeling en tests |
In het platform worden deze geïmplementeerd door de centrale firewall, de private DNS en policies die publieke endpoints weigeren. Een manier om een externe partij inkomende toegang tot één resource te geven is Inkomende SFTP naar een storage account. Zie Beperkingen en Policy en uitzonderingen.
Guardrails voor pipelines en repositories¶
Het platform draait op pipelines, dus het pipelineplatform is onderdeel van het securitymodel. Een baseline in het kort:
- Organisatie. Een niet-persoonlijk account is eigenaar van de organisatie. Toegang is alleen met Entra ID-identiteiten, via groepen. Bevoorrechte rollen alleen via PIM. Alternatieve authenticatiegegevens en OAuth-toegang van derden staan uit.
- Historie is bewijs. Niemand verwijdert builds, releases, repositories of teamprojecten.
- Productiedeployments vereisen een goedkeuring op de productiestage en draaien alleen vanaf specifieke productiebranches.
- Pipelines zijn YAML, klassieke pipelines staan uit, en variabelen die bij het in de wachtrij zetten kunnen worden ingesteld zijn beperkt.
- Secrets staan in een vault, niet in pipelinevariabelen. Ze worden nooit gelogd, en worden geaudit en geroteerd. Geef de voorkeur aan service connections die beperkt zijn tot wat ze nodig hebben, en aan service principals boven personal access tokens.
- Branches hebben policies zonder bypass: minimaal twee reviewers, degene die als laatste pushte kan niet goedkeuren, opmerkingen zijn opgelost, een build slaagt en een work item is gekoppeld. Forken staat uit.
- Productiesecrets staan in een aparte vault, met toegang op need-to-know-basis. Test- en productiegegevens worden niet gemengd.
- Agents. Weinig accounts hebben rechten, de firewall is zo restrictief als de agents toelaten, pools worden regelmatig bijgewerkt, en productie-artifacts gebruiken een aparte pool (Toegang voor build agents).
De volledige lijst voor Azure DevOps, met de instellingen, staat in Azure DevOps: inrichting en uitgangspunten.
Hoe dit zich verhoudt tot de MCP-pipelines
De MCP-configuratierepository heeft eigen beveiligingen: goedkeuringsmodi voor prod-runs en branch protection op de configuratierepository. Zie Pipelines en workflows. De guardrails op deze pagina zijn voor de pipelines die je workload teams bouwen.
Vrijheid binnen een kader¶
Guardrails betekenen geen centrale controle over alles. Een goed platform geeft teams autonomie waar dat veilig is: het team is eigenaar van zijn pipelines, zijn resources binnen zijn spoke en, in sommige ontwerpen, zijn eigen DNS-zones (DNS-subdomeindelegatie). Het platform stelt het kader vast met policy, naamgeving en het netwerk, en controleert dat automatisch.