Azure DevOps: inrichting en uitgangspunten¶
Veel workload teams bouwen en deployen met Azure DevOps. Het platform kan voor je spoke een repository en een service connection aanmaken (Wat je krijgt), maar de Azure DevOps-organisatie en de projecten daarin zijn van jouw organisatie. Deze pagina bundelt aanbevolen instellingen (guardrails) en een verstandige projectstructuur.
Aanbevelingen, geen platformfuncties
Het MCP-product configureert je Azure DevOps-organisatie niet. Zie de onderstaande lijsten als een basis die je security officer en DevOps-beheerders aanpassen. Waar je organisatie eigen regels heeft, gaan die voor.
Organisatie, project, team¶
| Niveau | Wat het is | Advies |
|---|---|---|
| Organisatie | Container op het hoogste niveau, gekoppeld aan Microsoft Entra ID en facturatie | Weinig. Meestal één per bedrijf. |
| Project | Repositories, pipelines, boards, testplannen, met eigen rechten | Eén project per product of applicatiegebied. |
| Team | Een groep binnen een project met een eigen board en backlog | Eén per DevOps-team. |
Eén project of meerdere?
| Aanpak | Geschikt voor |
|---|---|
| Eén project | Kleine en middelgrote organisaties, eenvoudige rechten, makkelijk navigeren tussen componenten van één product |
| Meerdere projecten | Grote organisaties met onafhankelijke teams. Betere isolatie, en per project andere eisen aan security, build en release |
Welke je ook kiest, houd het consistent. Repositories en pipelines later tussen projecten verplaatsen is werk.
Organisatieniveau¶
| Guardrail | Waarom |
|---|---|
| Een niet-persoonlijk account is eigenaar van de organisatie, en toegang daartoe loopt alleen via escalatie | Mensen vertrekken; een persoonlijke eigenaar is een single point of failure |
| Toegang alleen met Entra ID-identiteiten, via groepen | Joiners en leavers volgen je identiteitsproces |
| Ingebouwde groepen blijven leeg, op hun standaardleden na. Het niet-persoonlijke account zit in Project Collection Administrators. | Geen rechten via vergeten lidmaatschappen |
| Bevoorrechte rollen (bijvoorbeeld Project Collection Administrators) alleen via PIM | Just-in-time toegang met een audit trail. Zie Toegang, groepen en PIM. |
| Schakel alternatieve authenticatiegegevens uit | Kleiner aanvalsoppervlak |
| Schakel toegang voor applicaties van derden via OAuth uit | Controle over integraties |
| Sta SSH-authenticatie toe | Een veilig alternatief voor Git |
| Schakel auditlog-events in | Audit trail en onderzoek van incidenten |
| Schakel publieke projecten uit | Geen onbedoelde blootstelling |
| Schakel extra bescherming in voor publieke package registries | Beschermt tegen gecompromitteerde of kwaadaardige packages |
| Schakel IP conditional access-validatie in voor niet-interactieve flows | Dekt ook service connections |
| Schakel externe gasttoegang uit | Samenwerking blijft intern |
| Laat team- en projectbeheerders geen gebruikers uitnodigen | Centrale onboarding |
Pipelines¶
| Guardrail | Waarom |
|---|---|
| Niemand verwijdert builds, releases, projecten of repositories | Een complete, controleerbare geschiedenis. Gebruik retention policies. |
| Goedkeuring op de productiestage is verplicht. Draai release pipelines alleen vanaf specifieke productiebranches. | Gecontroleerde, controleerbare productie-deployments |
| Definieer pipelines in YAML. Zet classic build- en classic release pipelines uit. | Wijzigingen worden gereviewd en zijn traceerbaar in versiebeheer |
| Schakel Enforce settable at queue time in voor variabelen, beperk de variabelen die bij het queuen kunnen worden gezet en sta niet toe dat in de editor gezette variabelen worden overschreven | Reproduceerbare runs en minder injectiemogelijkheden |
| Laat gebruikers geen security-kritieke pipelines draaien tegen willekeurige branches of tags | Alleen gereviewde code bereikt productie |
| Schakel overerving op de pipeline uit en beperk in alle gevallen de job authorisation scope | Least privilege |
| Vermijd resources die extern worden opgehaald. Heb je er toch een nodig, pin dan de versie en controleer een hash. | Veiligheid van de supply chain |
| Log geen secrets. Bewaar geen secrets in pipeline-variabelen: gebruik Azure Key Vault. Kan dat niet, gebruik dan secret-variabelen, beperk wie ze kan lezen en sla geen gestructureerde data (bijvoorbeeld JSON) op als secret. | Secrets blijven uit logs en pipeline-definities |
| Audit en roteer secrets | Beperkt hoe lang een gelekte secret bruikbaar is |
| Gebruik service connections in plaats van credentials door te geven, beperk ze tot de resources en resource groups die ze nodig hebben en gebruik geen Azure Classic service connections | Least privilege, centraal beheer |
| Gebruik PAT's spaarzaam en roteer ze. Overweeg service principals (of workload identity federation). | PAT's zijn krachtig en persoonlijk |
| Bouw geen pull requests van GitHub-forks. Doe je dat toch, geef ze dan geen secrets en start ze handmatig. | Onbetrouwbare code mag niet draaien met jouw credentials |
| Houd pipeline-afhankelijkheden actueel met een tool zoals Renovate | Minder bekende kwetsbaarheden |
De service connection die het platform voor je spoke aanmaakt, kan federated credentials gebruiken in plaats van een secret, zie Hoe wijzig je iets en Hoe gebruik je het.
Repositories en branches¶
| Guardrail | Waarom |
|---|---|
| Configureer branch policies op de hoofdbranch en sta niet toe dat ze worden omzeild | De regels gelden voor iedereen |
| Eis een minimaal aantal reviewers (twee is gebruikelijk) en minstens één goedkeuring op de laatste iteratie | Onafhankelijke review van wat wordt gemerged |
| Wie als laatste heeft gepusht, kan de eigen wijziging niet goedkeuren | Vierogenprincipe |
| Koppel aan elke pull request een work item | Traceerbaarheid |
| Los alle opmerkingen op voordat je een pull request afrondt | Feedback gaat niet verloren |
| Eis een geslaagde build op de pull request | Fouten vangen voor het mergen |
| Bewaar productiesecrets in een aparte Key Vault, met toegang op need-to-know-basis | Scheiding van productie en niet-productie |
| Meng testomgevingen en productie niet, ook hun credentials niet | Voorkomt ongelukken en datalekken |
| Schakel forken uit | Controle over code en secrets |
Agents¶
| Guardrail | Waarom |
|---|---|
| Geef zo min mogelijk accounts rechten op agent pools | Kleiner aanvalsoppervlak |
| Gebruik de strengste firewall waarbij de agents nog bruikbaar blijven | Beperkt wat een gecompromitteerde build kan bereiken |
| Update de pools regelmatig zodat de buildomgeving geen kwetsbare software draait | Zie Build agents |
| Gebruik een aparte pool voor builds die naar productie leveren of deployen | Scheiding |
| Scheid gevoelige pools van de rest en gebruik credentials alleen in pipelines die aan specifieke pools zijn vergrendeld | Credentials lekken niet naar onbetrouwbare jobs |
Het project van het platform openen voor workload teams (optioneel)¶
Sommige platformteams hebben een eigen Azure DevOps-project, met een wiki, een board en repositories (bijvoorbeeld de definities van firewallregels). Workload teams daar beperkte toegang geven versnelt het werk:
| Wat | Toegang | Waarom |
|---|---|---|
| Wiki met platformdocumentatie | Lezen, voor elk onboarded team | Teams vinden zelf de concepten en how-to's |
| Board | Lezen | Teams kunnen hun eigen aanvragen volgen als tickets met het board worden gesynchroniseerd |
| Repository met firewallregels | Lezen | Teams zien welke regels voor hen gelden en of de firewall hun verkeer blokkeert |
| Pull requests op die repository | Per team, na afspraak | Een pull request is makkelijker te valideren dan een geschreven aanvraag. Het platformteam keurt nog steeds goed en deployt, en een ticket blijft nodig. |
Geef toegang via één lezersgroep in Microsoft Entra ID, waaraan je de groepen van elk onboarded team toevoegt, en niet aan personen afzonderlijk. Houd de overige repositories gesloten. De configuratierepository van het platform openstellen is een beslissing van het platformteam: lees eerst Beheermodellen en Firewallregels.