End-to-end-governance in Azure bij gebruik van CI/CD

Bij het ontwikkelen van een governancemodel voor uw organisatie is het belangrijk om te onthouden dat Azure Resource Manager slechts één manier is om resources te beheren. Automatisering van Azure DevOps en continue integratie en continue levering (CI/CD) kan een onbedoelde beveiligingsachterdeur zijn als deze niet goed is beveiligd. Deze resources moeten worden beveiligd door het RBAC-model (op rollen gebaseerd toegangsbeheer) te spiegelen dat wordt gebruikt voor Resource Manager.

Het concept van end-to-end governance is leverancierneutraal. De implementatie die hier wordt beschreven, maakt gebruik van Azure DevOps, maar alternatieven worden ook kort vermeld.

Potentiële gebruikscases

Deze referentie-implementatie en demo is open source en is bedoeld om te worden gebruikt als een onderwijsprogramma voor organisaties die nieuw zijn bij DevOps en een governancemodel moeten maken voor implementatie in Azure. Lees dit scenario zorgvuldig voor meer informatie over de beslissingen achter het model dat in deze voorbeeldopslagplaats wordt gebruikt.

Elk governancemodel moet zijn gekoppeld aan de bedrijfsregels van de organisatie, die worden weerspiegeld in elke technische implementatie van toegangsbeheer. In dit voorbeeldmodel wordt gebruikgemaakt van een fictief bedrijf met het volgende algemene scenario (met bedrijfsvereisten):

• Microsoft Entra-groepen die zijn afgestemd op bedrijfsdomeinen en machtigingsmodellen
  De organisatie heeft veel verticale bedrijfsdomeinen, zoals 'fruit' en 'groenten', die grotendeels onafhankelijk werken. In elk bedrijfsdomein zijn er twee niveaus of bevoegdheden, die zijn toegewezen aan afzonderlijke *-admins groepen of *-devs Microsoft Entra-groepen. Hierdoor kunnen ontwikkelaars worden gericht bij het configureren van machtigingen in de cloud.

• Implementatieomgevingen
  Elk team heeft twee omgevingen:

  • Productie. Alleen beheerders hebben verhoogde bevoegdheden.
  • Niet-productie. Alle ontwikkelaars hebben verhoogde bevoegdheden (om experimenten en innovatie aan te moedigen).

• Automatiseringsdoelen
  Elke toepassing moet Azure DevOps implementeren, niet alleen voor continue integratie (CI), maar ook voor continue implementatie (CD). Implementaties kunnen bijvoorbeeld automatisch worden geactiveerd door wijzigingen in de Git-opslagplaats.

• Cloudreis tot nu toe
  De organisatie is begonnen met een geïsoleerd projectmodel om de overstap naar de cloud te versnellen. Maar nu verkennen ze opties om silo's te breken en samenwerking aan te moedigen door de projecten 'samenwerking' en 'supermarkt' te creëren.

In dit vereenvoudigde diagram ziet u hoe vertakkingen in een Git-opslagplaats worden toegewezen aan ontwikkel-, faserings- en productieomgevingen:

Download een SVG van dit diagram.

Architectuur

In dit diagram ziet u hoe het koppelen van Resource Manager en CI/CD met Microsoft Entra ID de sleutel is om een end-to-end governancemodel te hebben.

Download een SVG van deze architectuur.

Workflow

De nummering weerspiegelt de volgorde waarin IT-beheerders en ondernemingsarchitecten nadenken over en configureren van hun cloudresources.

1. Microsoft Entra ID

   We integreren Azure DevOps met Microsoft Entra ID om één vlak voor identiteit te hebben. Dit betekent dat een ontwikkelaar hetzelfde Microsoft Entra-account gebruikt voor zowel Azure DevOps als Resource Manager. Gebruikers worden niet afzonderlijk toegevoegd. In plaats daarvan wordt het lidmaatschap toegewezen door Microsoft Entra-groepen, zodat we de toegang van een ontwikkelaar tot resources in één stap kunnen verwijderen door hun Microsoft Entra-groepslidmaatschappen te verwijderen. Voor elk domein maken we:

   • Microsoft Entra-groepen. Twee groepen per domein (verder beschreven in stap 4 en 5 verderop in dit artikel).
   • Service-principals. Eén expliciete service-principal per omgeving.

2. Productieomgeving

   Ter vereenvoudiging van de implementatie maakt deze referentie-implementatie gebruik van een resourcegroep die de productieomgeving vertegenwoordigt. In de praktijk moet u een ander abonnement gebruiken.

   Bevoegde toegang tot deze omgeving is alleen beperkt tot beheerders.

3. Ontwikkelomgeving

   Ter vereenvoudiging van de implementatie maakt deze referentie-implementatie gebruik van een resourcegroep die de ontwikkelomgeving vertegenwoordigt. In de praktijk moet u een ander abonnement gebruiken.

4. Roltoewijzingen in Resource Manager

   Hoewel onze Microsoft Entra-groepsnamen een rol impliceren, worden toegangsbeheer pas toegepast nadat een roltoewijzing is geconfigureerd. Hiermee wordt een rol toegewezen aan een Microsoft Entra-principal voor een specifiek bereik. Ontwikkelaars hebben bijvoorbeeld de rol Inzender in de productieomgeving.

   Microsoft Entra-principal	Ontwikkelomgeving (Resource Manager)	Productieomgeving (Resource Manager)
   veggies-devs-group	Eigenaar	Lezer
   veggies-admins-group	Eigenaar	Eigenaar
   veggies-ci-dev-sp	Aangepaste rol *	–
   veggies-ci-prod-sp	–	Aangepaste rol *

   * Ter vereenvoudiging van de implementatie wijst deze referentie-implementatie de Owner rol toe aan de service-principals. In productie moet u echter een aangepaste rol maken die voorkomt dat een service-principal alle beheervergrendelingen verwijdert die u op uw resources hebt geplaatst. Dit helpt resources te beschermen tegen onbedoelde schade, zoals het verwijderen van de database.

   Zie de sectie overwegingen verderop in dit artikel voor meer informatie over de redenering achter de afzonderlijke roltoewijzingen.

5. Toewijzingen van beveiligingsgroepen in Azure DevOps

   Beveiligingsgroepen werken als rollen in Resource Manager. Profiteer van ingebouwde rollen en standaard inzender voor ontwikkelaars. Beheerders worden toegewezen aan de beveiligingsgroep Projectbeheerder voor verhoogde machtigingen, zodat ze beveiligingsmachtigingen kunnen configureren.

   Houd er rekening mee dat Azure DevOps en Resource Manager verschillende machtigingsmodellen hebben:

   • Azure Resource Manager maakt gebruik van een additief machtigingsmodel .
   • Azure DevOps maakt gebruik van een minimaal machtigingsmodel .

   Daarom moeten lidmaatschap van de -admins en -devs groepen elkaar uitsluiten. Anders hebben de betrokken personen minder toegang dan verwacht in Azure DevOps.

   Groepsnaam	Resource Manager-rol	Azure DevOps-rol
   fruits-all	–	–
   fruits-devs	Inzender	Inzender
   fruits-admins	Eigenaar	Projectbeheerders
   veggies-all	–	–
   veggies-devs	Inzender	Inzender
   veggies-admins	Eigenaar	Projectbeheerders
   infra-all	–	–
   infra-devs	Inzender	Inzender
   infra-admins	Eigenaar	Projectbeheerders

   In een scenario van beperkte samenwerking, zoals het fruitteam dat het veggies-team uitnodigt om samen te werken aan één opslagplaats, zouden ze de veggies-all groep gebruiken.

   Raadpleeg de sectie overwegingen verderop in dit artikel voor meer informatie over de redenering achter de afzonderlijke roltoewijzingen.

6. Serviceverbindingen

   In Azure DevOps is een serviceverbinding een algemene wrapper rond een referentie. We maken een serviceverbinding die de client-id en het clientgeheim van de service-principal bevat. Projectbeheerders kunnen de toegang tot deze beveiligde resource zo nodig configureren, bijvoorbeeld wanneer menselijke goedkeuring is vereist voordat ze worden geïmplementeerd. Deze referentiearchitectuur heeft twee minimale beveiligingen voor de serviceverbinding:

   • Beheerders moeten pijplijnmachtigingen configureren om te bepalen welke pijplijnen toegang hebben tot de referenties.
   • Beheerders moeten ook een controle voor vertakkingsbeheer configureren, zodat alleen pijplijnen die in de context van de production vertakking worden uitgevoerd, de prod-connection.

7. Git-opslagplaatsen

   Omdat onze serviceverbindingen zijn gekoppeld aan vertakkingen via vertakkingsbesturingselementen, is het essentieel om machtigingen voor de Git-opslagplaatsen te configureren en vertakkingsbeleid toe te passen. Naast dat CI-builds moeten worden doorgegeven, moeten pull-aanvragen ook ten minste twee goedkeurders hebben.

Onderdelen

• Azure DevOps
• Microsoft Entra ID
• Azure Resource Manager
• Azure-opslagplaatsen
• Azure Pipelines

Alternatieven

Het concept van end-to-end governance is leverancierneutraal. Hoewel dit artikel gericht is op Azure DevOps, kan Azure DevOps Server worden gebruikt als een on-premises vervanging. U kunt ook een set technologieën gebruiken voor een opensource-CI/CD-ontwikkelingspijplijn met behulp van opties zoals Jenkins en GitLab.

Zowel Azure-opslagplaatsen als GitHub zijn platforms die zijn gebouwd voor het gebruik van het opensource-versiebeheersysteem van Git. Hoewel hun functiesets enigszins verschillen, kunnen beide worden geïntegreerd in globale governancemodellen voor CI/CD. GitLab is een ander Git-platform dat robuuste CI/CD-mogelijkheden biedt.

In dit scenario wordt Terraform gebruikt als hulpprogramma voor infrastructuur als code (IaC). Alternatieven zijn Jenkins, Ansible en Chef.

Overwegingen

Om end-to-end-governance in Azure te bereiken, is het belangrijk om inzicht te krijgen in het beveiligings- en machtigingenprofiel van het pad van de computer van de ontwikkelaar naar productie. In het volgende diagram ziet u een CI/CD-werkstroom volgens de basislijn met Azure DevOps. Het rode vergrendelingspictogram geeft beveiligingsmachtigingen aan die door de gebruiker moeten worden geconfigureerd. Als u geen machtigingen configureert of onjuist configureert, blijven uw workloads kwetsbaar.

Download een SVG van deze werkstroom.

Als u uw workloads wilt beveiligen, moet u een combinatie van configuraties voor beveiligingsmachtigingen en menselijke controles in uw werkstroom gebruiken. Het is belangrijk dat elk RBAC-model ook moet worden uitgebreid naar zowel pijplijnen als code. Deze worden vaak uitgevoerd met bevoorrechte identiteiten en vernietigen uw werkbelastingen als dit wordt geïnstrueerd. Om te voorkomen dat dit gebeurt, moet u vertakkingsbeleid configureren in uw opslagplaats om menselijke goedkeuring te vereisen voordat u wijzigingen accepteert die automatiseringspijplijnen activeren.

De volgende concepten en vragen zijn belangrijk om rekening mee te houden bij het ontwerpen van een governancemodel. Houd rekening met de mogelijke gebruiksvoorbeelden van deze voorbeeldorganisatie.

1. Uw omgevingen beveiligen met vertakkingsbeleid

Omdat uw broncode implementaties definieert en activeert, is uw eerste verdedigingslinie het beveiligen van uw opslagplaats voor broncodebeheer (SCM). In de praktijk wordt dit bereikt met behulp van de werkstroom pull-aanvraag in combinatie met vertakkingsbeleid, waarmee controles en vereisten worden gedefinieerd voordat code kan worden geaccepteerd.

Wanneer u uw end-to-end-governancemodel plant, zijn bevoegde gebruikers (veggies-admins) verantwoordelijk voor het configureren van vertakkingsbeveiliging. Algemene controles voor vertakkingsbeveiliging die worden gebruikt om uw implementaties te beveiligen, zijn onder andere:

• Ci-build moet worden doorgegeven. Handig voor het vaststellen van de kwaliteit van basislijncode, zoals codeplining, eenheidstests en zelfs beveiligingscontroles zoals virus- en referentiescans.

• Peer review vereisen Een andere menselijke controle hebben dat code werkt zoals bedoeld. Wees extra voorzichtig wanneer er wijzigingen worden aangebracht in pijplijncode. Combineer met CI-builds om peerbeoordelingen minder tijdrovend te maken.

Wat gebeurt er als een ontwikkelaar rechtstreeks naar productie probeert te pushen?

Houd er rekening mee dat Git een gedistribueerd SCM-systeem is. Een ontwikkelaar kan zich rechtstreeks doorvoeren naar de lokale production vertakking. Maar wanneer Git correct is geconfigureerd, wordt een dergelijke push automatisch geweigerd door de Git-server. Voorbeeld:

remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "continuous-integration" is expected.
To https://github.com/Azure/devops-governance
 ! [remote rejected] main -> main (protected branch hook declined)
error: failed to push some refs to 'https://github.com/Azure/devops-governance'

Houd er rekening mee dat de werkstroom in het voorbeeld leverancierneutraal is. De functies voor pull-aanvraag- en vertakkingsbeveiliging zijn beschikbaar bij meerdere SCM-providers, waaronder Azure-opslagplaatsen, GitHub en GitLab.

Zodra de code is geaccepteerd in een beveiligde vertakking, wordt de volgende laag toegangsbeheer toegepast door de buildserver (zoals Azure Pipelines).

2. Welke toegang hebben beveiligingsprinciplen nodig?

In Azure kan een beveiligingsprincipaal een gebruikers-principal of een hoofdloze principal zijn, zoals een service-principal of beheerde identiteit. In alle omgevingen moeten beveiligingsprinciplen het principe van minimale bevoegdheden volgen. Hoewel beveiligingsprinciplen mogelijk uitgebreide toegang hebben in preproductieomgevingen, moeten productieomgevingen in Azure-omgevingen de permanente machtigingen minimaliseren, waardoor JIT-toegang (Just-In-Time) en voorwaardelijke toegang van Microsoft Entra worden geminimaliseerd. Stel uw Azure RBAC-roltoewijzingen voor gebruikersprinciplen op om te voldoen aan deze principals met minimale bevoegdheden.

Het is ook belangrijk om Azure RBAC afzonderlijk van Azure DevOps RBAC te modelleren. Het doel van de pijplijn is om directe toegang tot Azure te minimaliseren. Met uitzondering van speciale gevallen zoals innovatie, leren en oplossen van problemen, moeten de meeste interacties met Azure worden uitgevoerd via speciaal gebouwde en gated pijplijnen.

Voor Azure Pipeline-service-principals kunt u overwegen een aangepaste rol te gebruiken waarmee wordt voorkomen dat resourcevergrendelingen worden verwijderd en andere destructieve acties buiten het bereik worden uitgevoerd voor het doel ervan.

3. Maak een aangepaste rol voor de service-principal die wordt gebruikt voor toegang tot productie

Het is een veelvoorkomende fout om CI/CD-buildagents eigenaarsrollen en -machtigingen te geven. Inzendermachtigingen zijn niet voldoende als uw pijplijn ook identiteitsroltoewijzingen of andere bevoegde bewerkingen moet uitvoeren, zoals Key Vault-beleidsbeheer.

Maar een CI/CD Build Agent verwijdert uw volledige productieomgeving als dit wordt verteld. Om onherstelbare destructieve wijzigingen te voorkomen, maken we een aangepaste rol die:

• Key Vault-toegangsbeleid verwijderen
• Hiermee verwijdert u beheervergrendelingen die standaard moeten voorkomen dat resources worden verwijderd (een gemeenschappelijke vereiste in gereglementeerde branches)

Hiervoor maken we een aangepaste rol en verwijderen we de Microsoft.Authorization/*/Delete acties.

{
  "Name": "Headless Owner",
  "Description": "Can manage infrastructure.",
  "actions": [
    "*"
  ],
  "notActions": [
    "Microsoft.Authorization/*/Delete"
  ],
  "AssignableScopes": [
    "/subscriptions/{subscriptionId1}",
    "/subscriptions/{subscriptionId2}",
    "/providers/Microsoft.Management/managementGroups/{groupId1}"
  ]
}

Als hiermee te veel machtigingen voor uw doeleinden worden verwijderd, raadpleegt u de volledige lijst in de officiële documentatie voor bewerkingen van de Azure-resourceprovider en past u uw roldefinitie indien nodig aan.

Dit scenario implementeren

Dit scenario gaat verder dan Resource Manager. Daarom gebruiken we Terraform, waarmee we ook principals kunnen maken in Microsoft Entra ID en bootstrap Azure DevOps met één infrastructuur als codehulpprogramma.

Ga naar de GitHub-opslagplaatsgovernance in Azure Demo voor broncode en gedetailleerde instructies: van DevOps naar ARM.

Prijzen

Azure DevOps-kosten zijn afhankelijk van het aantal gebruikers in uw organisatie dat toegang nodig heeft, samen met andere factoren, zoals het aantal gelijktijdige build-/releases dat vereist is en het aantal gebruikers. Azure-opslagplaatsen en Azure Pipelines zijn functies van de Azure DevOps-service. Zie prijzen voor Azure DevOps voor meer informatie.

In Microsoft Entra ID wordt het type groepstoegangsbeheer dat nodig is voor dit scenario opgegeven in de Premium P1- en Premium P2-edities. Prijzen voor deze lagen worden per gebruiker berekend. Zie Prijzen van Microsoft Entra voor meer informatie.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

• Julie Ng | Senior Service Engineer

Volgende stappen

• Ga naar de codeopslagplaats voor dit scenario in Governance in Azure Demo: van DevOps naar ARM.
• Bekijk de cloudgovernancehandleidingen van het Cloud Adoption Framework.
• Wat is Azure RBAC (toegangsbeheer op basis van rollen)?
• Cloud Adoption Framework: Toegangsbeheer voor resources in Azure
• Azure Resource Manager-rollen
  • Eigenaar (ingebouwd)
  • Inzender (ingebouwd)
  • Lezer (ingebouwd)
  • Aangepaste rol
• Azure DevOps-beveiligingsgroepen
  • Projectbeheerders
  • Inzender
  • Lezer

Verwante resources

• Een CI/CD-pijplijn ontwerpen met behulp van Azure DevOps
• Computer forensische bewakingsketen in Azure
• Hybride azure Arc-beheer en -implementatie voor Kubernetes-clusters
• Bladeren in Azure Architecturen - CI/CD