Bewerken

Delen via

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

Microsoft Entra ID
Azure DevOps
Azure Pipelines
Azure Resource Manager

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:

Simplified diagram of Git repository branches mapped to various web environments
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.

End-to-end governance overview with Microsoft Entra ID at the center
Download een SVG van deze architectuur.

Notitie

Om het concept beter te begrijpen, illustreert het diagram alleen het domein 'veggies' . Het domein 'fruit' ziet er ongeveer als volgt uit en gebruikt dezelfde naamconventies.

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. Beheer worden toegewezen aan de Project Beheer istrator-beveiligingsgroep voor verhoogde machtigingen, zodat ze beveiligingsmachtigingen kunnen configureren.

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

    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 Project Beheer istrators
    veggies-all – –
    veggies-devs Inzender Inzender
    veggies-admins Eigenaar Project Beheer istrators
    infra-all – –
    infra-devs Inzender Inzender
    infra-admins Eigenaar Project Beheer istrators

    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 service-Verbinding maken ion een algemene wrapper rond een referentie. We maken een serviceverbinding die de client-id en het clientgeheim van de service-principal bevat. Project Beheer istrators kunnen de toegang tot deze beveiligde resource zo nodig configureren, zoals wanneer menselijke goedkeuring is vereist voordat ze worden geïmplementeerd. Deze referentiearchitectuur heeft twee minimale beveiligingen voor de serviceverbinding:

    • Beheer s moeten pijplijnmachtigingen configureren om te bepalen welke pijplijnen toegang hebben tot de referenties.
    • Beheer s moeten ook een controle van een vertakkingsbeheer zodanig configureren dat alleen pijplijnen die worden uitgevoerd in de context van de production vertakking 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

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.

Diagram illustrating a baseline CI/CD workflow with Azure DevOps
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.

Implementatiefasen Verantwoordelijkheid Omschrijving
Pull-aanvragen User Technici moeten hun werk beoordelen, inclusief de pijplijncode zelf.
Vertakkingsbeveiliging Gedeelde Configureer Azure DevOps om wijzigingen te weigeren die niet voldoen aan bepaalde standaarden, zoals CI-controles en peerbeoordelingen (via pull-aanvragen).
Pijplijn als code User Een buildserver verwijdert uw volledige productieomgeving als de pijplijncode dit instrueert. U kunt dit voorkomen door gebruik te maken van een combinatie van pull-aanvragen en vertakkingsbeveiligingsregels, zoals menselijke goedkeuring.
Serviceverbindingen Gedeelde Configureer Azure DevOps om de toegang tot deze referenties te beperken.
Azure-resources Gedeelde Configureer RBAC in Resource Manager.

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. Bijvoorbeeld:

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:

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 voor Microsoft Entra voor meer informatie.

Inzenders

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

Hoofdauteur:

Volgende stappen