Delen via

Beveiligingsoverwegingen voor DevOps-platforms

Beveiliging moet altijd een prioriteit zijn in cloudontwikkelingsplatforms, zoals Azure DevOps en GitHub. Microsoft werkt de beveiliging van de onderliggende cloudinfrastructuur bij en onderhoudt deze, maar het is aan u om aanbevolen beveiligingsprocedures te controleren en te configureren voor uw eigen Azure DevOps-organisaties en GitHub-exemplaren.

Houd rekening met de volgende kritieke beveiligingsgebieden, ongeacht of u omgevingen implementeert via infrastructuur als code in CI/CD-pijplijnen (continue integratie en continue implementatie) of code implementeert in uw toepassingen die worden gehost in Azure.

Toegang tot DevOps-hulpprogramma's beperken

Volg het principe van minimale bevoegdheden met behulp van op rollen gebaseerd toegangsbeheer (RBAC) via Microsoft Entra-id. Geef gebruikers en services de minimale hoeveelheid toegang tot uw DevOps-platforms die ze nodig hebben om hun bedrijfsfuncties uit te voeren. Raadpleeg voor meer informatie de volgende artikelen:

Nadat u Microsoft Entra ID als identiteitsbeheervlak hebt ingesteld, volgt u de aanbevolen procedures voor het beheren van Azure DevOps-roltoewijzingen met Microsoft Entra-groepslidmaatschappen. U kunt Azure DevOps-rollen toewijzen aan Microsoft Entra-groepen en het Microsoft Entra-lidmaatschap van een gebruiker aanpassen om hun Azure DevOps-toegang te wijzigen of te verwijderen.

  • Gebruik Microsoft Entra ID-rechtenbeheer om toegangspakketten te maken waarmee Microsoft Entra-gebruikers tijdgebonden toegang kunnen krijgen tot de vereiste resources om hun taken te voltooien.

  • U kunt Microsoft Entra Privileged Identity Management ook gebruiken voor Just-In-Time-toegang om personen gedurende een bepaalde periode te promoveren naar Azure DevOps Administrator-rollen.

Beheer de beveiliging in Azure DevOps met behulp van beveiligingsgroepen, beleidsregels en instellingen in de Azure DevOps-organisatie, het project of het objectniveau. Overweeg zo mogelijk de overname van machtigingen in Azure DevOps uit te schakelen.

Toegang tot opslagplaats en vertakking beperken

Beperk de toegang tot de opslagplaats, machtigingen en het maken van vertakkingen om uw code en omgevingen te beveiligen tegen ongewenste of schadelijke wijzigingen. Beperk de toegang tot opslagplaatsen met behulp van beveiligingsgroepen in Azure DevOps. Beperk wie code in uw vertakkingen kan lezen en bijwerken door vertakkingsmachtigingen in te stellen.

Toegang en machtigingen voor pijplijnen beperken

Schadelijke code kan zakelijke gegevens en geheimen stelen en beschadigde productieomgevingen. Implementeer kaders om schadelijke code-implementatie in de pijplijn te voorkomen. Door de toegang te beperken en kaders te implementeren, kunt u ook voorkomen dat andere projecten, pijplijnen en opslagplaatsen lateraal worden blootgesteld aan eventuele gecompromitteerde pijplijnen.

Overweeg om een incrementele benadering te volgen voor het beveiligen van uw YAML-pijplijnen. Zie Plannen hoe u uw YAML-pijplijnen beveiligt voor meer informatie.

Selecteer de DevOps-agent op basis van beveiligingsbehoeften

U kunt door Microsoft gehoste of zelf-hostende agents gebruiken om Azure DevOps- en GitHub-pijplijnen mogelijk te maken. Er zijn compromissen voor elk type agent.

Met door Microsoft gehoste agents hoeft u zich geen zorgen te maken over upgrades of onderhoud. Met zelf-hostende agents hebt u meer flexibiliteit om beveiligingsbeveiligingsrails te implementeren. U bepaalt de agenthardware, het besturingssysteem en de geïnstalleerde hulpprogramma's. Zelfgehoste agents kunnen ook privé netwerktoegang bieden tot resources achter firewalls of virtuele netwerken.

Zie Azure Pipelines-agents om de verschillen tussen de typen agents te bekijken en mogelijke beveiligingsoverwegingen te identificeren.

Gebruik veilige en begrensde service-identiteiten

Gebruik voor GitHub, Azure DevOps of CI/CD-platforms van derden beveiligde en gescope identiteiten om code en infrastructuur te implementeren in Azure-omgevingen.

  • Door de gebruiker toegewezen beheerde identiteiten of toepassingsregistraties (service-principals) in Entra-id kunnen worden gebruikt. Gebruik nooit een gebruikersaccount.
  • Implementeer OpenID Connect-verificatie (workloadidentiteitsfederatie) met federatieve referenties voor de identiteit. Gebruik nooit clientgeheimen of -certificaten.
  • Maak een afzonderlijke identiteit voor elke toepassing en omgeving waarmee u implementeert, zodat gedetailleerde machtigingen kunnen worden toegepast.
  • Maak een afzonderlijke identiteit per toepassing en omgeving voor alleen-lezen bewerkingen, zoals Terraform plan of Bicep what-if.
  • Bereik de identiteitsmachtigingen alleen voor het Azure-abonnement of de resourcegroepen die zijn vereist voor implementatie. Gebruik het principe van minimale bevoegdheid om alleen de benodigde rollen toe te wijzen aan de identiteit.
  • Implementeer uw identiteiten en federatieve referenties via infrastructuur als code (IaC) in een veilig verkoopproces voor abonnementen. Zie De implementatie en configuratie van abonnementen automatiseren voor meer informatie.

Door de gebruiker toegewezen beheerde identiteiten worden beheerd door Azure Resource Manager. Toepassingsregistraties (service-principals) worden beheerd door Entra-id. Door de gebruiker toegewezen beheerde identiteiten kunnen eenvoudiger worden geïntegreerd met uw abonnementsverkoopproces, zodat ze buiten gebruik worden gesteld, samen met uw andere resources wanneer ze niet meer nodig zijn.

Met zelf-hostende agents die gebruikmaken van Azure Compute, is het mogelijk om systeem- of door de gebruiker toegewezen beheerde identiteiten rechtstreeks op de agent te gebruiken. Hoewel deze methode veilig kan zijn, is het raadzaam OpenID Connect (workloadidentiteitsfederatie) te gebruiken met door de gebruiker toegewezen beheerde identiteiten of toepassingsregistraties (service-principals) voor meer flexibiliteit en controle. Wanneer u een door de berekening gekoppelde beheerde identiteit gebruikt en u meerdere door de gebruiker toegewezen beheerde identiteiten aan de agent koppelt, heeft alles wat op de agent wordt uitgevoerd, toegang tot al deze identiteiten. Het is meestal kostbaar om afzonderlijke agents per toepassing en omgeving te hebben om toegang tot minimale bevoegdheden te garanderen.

Azure DevOps-identiteiten

Gebruik altijd een serviceverbinding met OpenID Connect (workloadidentiteitsfederatie) om infrastructuur- of toepassingscode in een Azure-omgeving te implementeren. Een serviceverbinding is een wrapper voor de identiteit in Azure.

  • Maak een afzonderlijke serviceverbinding en -identiteit voor elke toepassing en omgeving waarmee u implementeert, zodat gedetailleerde machtigingen kunnen worden toegepast.
  • Maak goedkeuringen voor de serviceverbinding. Maak ze niet in omgevingen, omdat deze in code kunnen worden overgeslagen.
  • Maak vereiste sjablonen (ook wel beheerde pijplijnen genoemd) in de serviceverbinding om ervoor te zorgen dat schadelijke code niet kan worden geïnjecteerd zonder goedkeuring.
  • Zorg ervoor dat de federatieve inloggegevens van uw identiteit zich alleen richten op de serviceverbinding.
  • Implementeer uw serviceverbindingen via infrastructuur als code (IaC) in een veilig verkoopproces voor abonnementen. Zie De implementatie en configuratie van abonnementen automatiseren voor meer informatie.

Voorbeeldcode en pijplijnen vindt u in het voorbeeld van de Azure DevOps Workload Identity Federation-code .

GitHub Actions-identiteiten

Gebruik altijd de ingebouwde acties of omgevingsvariabelen met OpenID Connect (workloadidentiteitsfederatie) om infrastructuur- of toepassingscode in een Azure-omgeving te implementeren.

  • Maak een identiteit voor elke toepassing en omgeving waarnaar u implementeert, zodat gedetailleerde machtigingen kunnen worden toegepast.
  • Maak goedkeuringen in een GitHub Actions-omgeving.
  • Werk uw onderwerpclaims bij om de environment claim op te nemen om ervoor te zorgen dat uw identiteit alleen kan worden gebruikt binnen het bereik van de opgegeven omgeving. Dit zorgt ervoor dat uw goedkeuringen niet kunnen worden overgeslagen. Voeg deze claim toe aan uw federatieve identiteitsreferentie.
  • Werk uw onderwerpclaims bij om de job_workflow_ref-claim (ook wel beheerde pijplijnen genoemd) op te nemen, zodat uw identiteit alleen kan worden gebruikt binnen de reikwijdte van de opgegeven werkstroom. Voeg deze claim toe aan uw federatieve identiteitsreferentie.
  • Werk uw onderwerpclaims bij om te verwijderen repository en te gebruiken repository_owner_id en repository_id in plaats daarvan om ervoor te zorgen dat uw identiteit alleen kan worden gebruikt in het bereik van de opgegeven opslagplaats, zelfs als de naam ervan is gewijzigd. Voeg deze claim toe aan uw federatief identiteitsbewijs.
  • Werk uw onderwerpclaims bij via infrastructuur als code (IaC) in een veilig verkoopproces voor abonnementen. Zie De implementatie en configuratie van abonnementen automatiseren voor meer informatie.

Voorbeeldcode en werkstromen vindt u in het voorbeeld van de GitHub Actions Workload Identity Federation-code .

Een geheim archief gebruiken

Vermijd altijd het gebruik van geheimen, geef waar mogelijk de voorkeur aan OpenID Connect (federatie van workloadidentiteiten) of beheerde identiteiten.

In het geval dat u het gebruik van een geheim niet kunt vermijden, hard-codeer ze nooit in de code of in de bijbehorende documentatie binnen uw repositories. Kwaadwillende bestanden scannen opslagplaatsen, zoeken naar blootgestelde vertrouwelijke gegevens om te misbruiken. Stel een geheimarchief in, zoals Azure Key Vault, en verwijs naar het archief in Azure Pipelines om veilig sleutels, geheimen of certificaten op te halen. Zie De pijplijn en CI/CD-werkstroom beveiligen voor meer informatie. U kunt ook Key Vault-geheimen gebruiken in GitHub Actions-werkstromen.

Harde DevOps-werkstations gebruiken om code te bouwen en te implementeren

Platform- en ontwikkelteams hebben vaak verhoogde bevoegdheden op het Azure-platform of op andere services, zoals Azure DevOps en GitHub. Deze toegang verhoogt de potentiële kwetsbaarheid voor aanvallen aanzienlijk. Implementeer kaders om eindpunten en werkstations te beveiligen die u gebruikt om code te ontwikkelen en te implementeren.

Gebruik beveiligde beheerwerkstations (SAW's) om wijzigingen in risico- en productieomgevingen te implementeren. Zie Eindpunten beveiligen met Zero Trust voor meer informatie.

Beveiligingsscans en -tests uitvoeren

Of u nu toepassingscode of infrastructuur als code implementeert, best practices en besturingselementen voor DevSecOps implementeren in uw pijplijnen. Integreer beveiliging vroeg in uw CI/CD-traject om kostbare beveiligingsschendingen later te voorkomen. Maak een strategie om statische codeanalyse, eenheidstests, geheimscans en pakket-/afhankelijkheidsscans in uw pijplijnen te implementeren.

Bedrijfsbeveiligingshulpprogramma's zoals Microsoft Defender voor Cloud kunnen worden geïntegreerd met DevOps-hulpprogramma's. Defender voor Cloud kan bijvoorbeeld kwetsbare containerinstallatiekopieën in uw CI/CD-werkstromen identificeren. Voor GitHub Actions en opslagplaatsen gebruikt u GitHub Advanced Security voor code- en geheimscans en afhankelijkheidsbeoordeling.

Controleer regelmatig controlegebeurtenissen om onverwachte gebruikspatronen door beheerders en andere gebruikers te controleren en erop te reageren. U kunt auditlogboeken voor uw Azure DevOps-organisatie openen, filteren en exporteren. Voor langetermijnopslag en gedetailleerde logboekquery's maakt u een controlestroom naar een Azure Monitor Log Analytics-werkruimte of naar een SIEM-systeem (Security Information and Event Management), zoals Microsoft Sentinel.

  • Last updated on