Uw Azure Pipelines beveiligen

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

Pijplijnen bieden krachtige mogelijkheden voor het uitvoeren van scripts en het implementeren van code in productieomgevingen, maar het is van cruciaal belang om deze kracht te verdelen met beveiliging. U wilt nooit dat een pijplijn een conduit wordt voor schadelijke code. Het in balans brengen van beveiliging met de flexibiliteit en kracht die ontwikkelteams nodig hebben, is essentieel.

Dit artikel bevat een overzicht van de benodigde beveiligingsconfiguraties om uw pijplijnen te beschermen tegen bedreigingen en beveiligingsproblemen.

Vereiste voorwaarden

Toegang tot project-, opslagplaats- en serviceverbindingen beperken

Als u de beveiliging wilt verbeteren, kunt u overwegen om uw projecten te scheiden, vertakkingsbeleid te gebruiken en meer beveiligingsmaatregelen voor forks toe te voegen. Minimaliseer het bereik van serviceverbindingen en gebruik de veiligste verificatiemethoden.

• Afzonderlijke projecten: beheer elk product en team in afzonderlijke projecten. Hierdoor voorkomt u dat pijplijnen van het ene product per ongeluk toegang krijgen tot open resources van een ander product, waardoor laterale blootstelling wordt geminimaliseerd.
• Identiteiten op projectniveau gebruiken: gebruik een projectgebaseerde build-identiteit voor pijplijnen in plaats van een identiteit op verzamelingsniveau. Identiteiten op projectniveau hebben alleen toegang tot resources binnen hun bijbehorende project, waardoor het risico op onbevoegde toegang door kwaadwillende actoren wordt geminimaliseerd. Zie de scoped build-identiteiten en het bereik voor taakautorisatie voor meer informatie.
• Vertakkingsbeleid gebruiken: om veilige wijzigingen in code en pijplijn te garanderen, past u machtigingen en vertakkingsbeleid toe. Overweeg daarnaast pijplijnmachtigingen toe te voegen en controles uit te voeren op opslagplaatsen.
• Voeg extra beveiliging voor forks toe: wanneer u met openbare opslagplaatsen van GitHub werkt, moet u zorgvuldig rekening houden met uw benadering van fork-builds. Forks die afkomstig zijn van buiten uw organisatie vormen specifieke risico's.
  • Geef geen geheimen op voor fork-builds: pijplijnen zijn standaard geconfigureerd voor het bouwen van forks, maar geheimen en beveiligde resources worden niet automatisch blootgesteld aan de taken in deze pijplijnen. Het is essentieel om deze beveiliging niet uit te schakelen om de beveiliging te behouden.
  • Overweeg het handmatig activeren van fork-builds: schakel automatische fork-builds uit en gebruik opmerkingen bij pull-aanvragen om deze bijdragen handmatig te bouwen. Met deze instelling kunt u de code controleren voordat u een build activeert. Zie Automatische fork-builds uitschakelen voor meer informatie.
  • Geef geen geheimen op voor fork-builds: geheimen die aan uw pijplijn zijn gekoppeld, worden standaard niet beschikbaar gesteld voor pull-aanvraagvalidaties van forks. Schakel de optie om geheimen beschikbaar te maken voor builds van forks niet in. Zie Bijdragen van forks voor instructies over het zoeken en controleren van deze instelling.
  • Overweeg het handmatig activeren van fork-builds: schakel automatische fork-builds uit en gebruik opmerkingen bij pull-aanvragen om deze bijdragen handmatig te bouwen. Met deze instelling kunt u de code controleren voordat u een build activeert. Zie Automatische fork-builds uitschakelen voor instructies over hoe u dit doet.
  • Gebruik door Microsoft gehoste agents voor fork-builds: vermijd het uitvoeren van builds van forks op zelf-hostende agents. Hierdoor kunnen externe organisaties externe code uitvoeren op computers binnen uw bedrijfsnetwerk. Gebruik waar mogelijk door Microsoft gehoste agents.
  • Gebruik de GitHub-app van Azure Pipelines voor beperking van tokenbereik: Wanneer u een pull-aanvraag voor GitHub-forked bouwt, zorgt Azure Pipelines ervoor dat de pijplijn geen inhoud van de GitHub-opslagplaats kan wijzigen. Deze beperking geldt alleen als u de GitHub-app Azure Pipelines gebruikt om te integreren met GitHub.

Beveiligde serviceverbindingen

• Minimaliseer het bereik van serviceverbindingen: serviceverbindingen mogen alleen toegang hebben tot de benodigde resources. Wanneer u een nieuwe Azure Resource Manager-serviceverbinding maakt, kiest u altijd een specifieke resourcegroep. Zorg ervoor dat de resourcegroep alleen de benodigde VM's of resources bevat die vereist zijn voor de build. Zie Een Azure Resource Manager-serviceverbinding gebruiken voor instructies over het instellen van serviceverbindingen.
• Gebruik federatie van workloadidentiteit voor verificatie: gebruik waar mogelijk workloadidentiteitsfederatie in plaats van een service-principal voor uw Azure-serviceverbinding. Federatie van workloadidentiteit maakt gebruik van Open ID Connect (OIDC), een industriestandaard technologie, om verificatie tussen Azure en Azure DevOps te vergemakkelijken zonder afhankelijk te zijn van geheimen. Zie Een serviceverbinding maken met workloadidentiteitsfederatie (automatisch) voor instructies over hoe dit te doen.
• Minimale toegang tot GitHub-apps: wanneer u de GitHub-app configureert voor Azure DevOps, verleent u alleen toegang tot de opslagplaatsen die u wilt bouwen met behulp van pijplijnen.
• Serviceverbindingen beperken tot specifieke vertakkingen: gebruik een controle voor vertakkingen om te beperken welke vertakkingen uw serviceverbinding kunnen gebruiken. Het hebben van een vertakkingscontrole zorgt ervoor dat serviceverbindingen alleen worden uitgevoerd op geautoriseerde vertakkingen en dat alle gekoppelde pijplijnbronnen zijn gebouwd vanuit toegestane vertakkingen.

YAML-pijplijnen gebruiken in plaats van klassieke pijplijnen

Voor extra beveiliging en om het risico op onbedoelde onjuiste configuraties te verminderen, gebruikt u YAML-pijplijnen in plaats van klassieke pijplijnen. Deze voorzorgsmaatregel voorkomt een beveiligingsprobleem dat voortvloeit uit YAML en klassieke pijplijnen die dezelfde resources delen, zoals serviceverbindingen. Als uw organisatie klassieke pijplijnen gebruikt, migreert u de pijplijnen naar YAML.

• YAML biedt de voordelen van infrastructuur als code: YAML-pijplijnen behandelen zoals elke andere code, omdat stappen en afhankelijkheden in code worden gedefinieerd. Er is ook duidelijk inzicht in pijplijnconfiguraties en een verminderd risico op onbedoelde onjuiste configuraties.
• YAML-pijplijnen kunnen worden gecombineerd met verbeterde beveiligingsmaatregelen: via codebeoordelingen en pull-aanvragen kunt u vertakkingsbeleid gebruiken om een beoordelingsproces in te stellen voor pull-aanvragen om ongeldige samenvoegingen te voorkomen.
• Resourcetoegangsbeheer: Resource-eigenaren bepalen of een YAML-pijplijn toegang heeft tot specifieke resources. Deze beveiligingsfunctie voorkomt aanvallen zoals het stelen van een andere opslagplaats. Gebruik Goedkeuringen en controles om toegangsbeheer te bieden voor elke pijplijnuitvoering.
  • Beveiligde vertakkingscontrole: als u handmatige processen voor codebeoordeling voor specifieke vertakkingen hebt, kunt u deze beveiliging uitbreiden naar pijplijnen. Een beveiligde vertakkingscontrole voor een resource voorkomt dat pijplijnen automatisch worden uitgevoerd op niet-geautoriseerde vertakkingen.
  • Handmatige goedkeuringscontrole: gebruik een handmatige goedkeuringscontrole om te voorkomen dat pijplijnaanvragen een beveiligde resource gebruiken totdat ze handmatig zijn goedgekeurd door opgegeven gebruikers of groepen.
  • Controle kantooruren: gebruik deze controle om ervoor te zorgen dat een pijplijnimplementatie binnen een opgegeven dag en tijdvenster wordt gestart.
• Schakel het maken van klassieke pijplijnen uit: schakel het maken van klassieke build-pijplijnen en klassieke release-pijplijnen onafhankelijk uit. Wanneer beide zijn uitgeschakeld, kunnen er geen klassieke build-pijplijn, klassieke releasepijplijn, taakgroepen of implementatiegroepen worden gemaakt via de gebruikersinterface of de REST API. Zie Het maken van klassieke pijplijnen uitschakelen voor meer informatie.

Beveiligde agents

Als u containers wilt beveiligen, markeert u volumes als alleen-lezen, stelt u resourcelimieten in, gebruikt u vertrouwde images, scant u naar kwetsbaarheden en dwingt u beveiligingsbeleid af.

• Gebruik door Microsoft gehoste agents in plaats van zelf-hostende agents: door Microsoft gehoste agents bieden isolatie en een schone virtuele machine voor elke uitvoering van een pijplijn. Gebruik door Microsoft gehoste agents in plaats van zelf-hostende agents. Raadpleeg door Microsoft gehoste agents voor meer informatie.
• Afzonderlijke agents voor elk project: om zijdelingse verplaatsing te beperken en kruisbesmetting tussen projecten te voorkomen, onderhoudt u afzonderlijke agentpools, die elk zijn toegewezen aan een specifiek project.
• Gebruik accounts met beperkte bevoegdheden om agents uit te voeren: als u de systeembeveiliging wilt verbeteren, gebruikt u het account met laagste bevoegdheden voor het uitvoeren van zelf-hostende agents. U kunt bijvoorbeeld uw computeraccount of een beheerde service-identiteit gebruiken. Voer geen agent uit onder een identiteit met directe toegang tot Azure DevOps-resources.
• Productieartefacten en gevoelige agentgroepen isoleren: gebruik verschillende agentgroepen om beveiligingsproblemen te voorkomen.
  • Gebruik een aparte agent pool voor productieartefacten: Isoleer productieartefacten met een aparte agent pool om onbedoelde implementaties van niet-productiebranches te voorkomen.
  • Segmentgevoelige pools: maak afzonderlijke pools voor gevoelige en niet-gevoelige workloads. Sta alleen referenties toe in builddefinities die zijn gekoppeld aan de juiste pool.
• Configureer beperkende firewalls voor zelf-hostende agents: stel firewalls zo beperkend mogelijk in, terwijl agents nog steeds kunnen functioneren, beveiliging en bruikbaarheid kunnen verdelen.
• Werk regelmatig zelf-hostende agentgroepen bij: houd uw zelf-hostende agents up-to-date met regelmatige updates om ervoor te zorgen dat kwetsbare code niet wordt uitgevoerd, waardoor het risico op exploitatie wordt verminderd.

Veilig variabelen en parameters gebruiken

Gebruik veilig variabelen en parameters in uw pijplijnen door de aanbevolen procedures voor het instellen van geheimen te volgen. Best practices omvatten het beperken van geheimgebruik, het gebruik van variabelen in wachtrijtijd en het inschakelen van validatie van shell-taakargumenten om uw pijplijn te beschermen tegen bedreigingen en beveiligingsproblemen.

• Toegang tot geheimen beperken: verwijder geheimen of sleutels uit pijplijnen. Schakel over naar authenticatiemethoden zonder geheimen, zoals workload identity federation, of stel geheimen in de gebruikersinterface, een variabelegroep, of een variabelegroep afkomstig van Azure Key Vault.
• Validatie van shell-parameters inschakelen: wanneer parametervalidatie voor shelltaken inschakelen is ingeschakeld, wordt er een extra controle uitgevoerd op tekens zoals puntkomma's, aanhalingstekens en haakjes. Schakel parametervalidatie van argumenten voor shell-taken in op organisatie- of projectniveau onder Instellingen>Pijplijnen>Instellingen.
• Limietvariabelen die kunnen worden ingesteld op het tijdstip van de wachtrij: voorkom dat gebruikers nieuwe variabelen definiëren op het moment van de wachtrij door de instellingslimietvariabelen in te schakelen die kunnen worden ingesteld op het tijdstip van de wachtrij bij Instellingenvoor pijplijnen van>organisatieinstellingen>.
• Gebruik parameters in plaats van variabelen: In tegenstelling tot variabelen kan een actieve pijplijn geen pijplijnparameters wijzigen. Parameters hebben gegevenstypen zoals number en string, en ze kunnen worden beperkt tot specifieke waardesubsets. Deze beperking is waardevol wanneer een door de gebruiker configureerbaar aspect van de pijplijn alleen waarden uit een vooraf gedefinieerde lijst mag accepteren, zodat de pijplijn geen willekeurige gegevens accepteert.
• Naslaginformatie over sjablonen: gebruik sjablonen in plaats van inlinescripts met geheime parameters rechtstreeks in uw pijplijn YAML op te slaan om gevoelige informatie te abstraheren van de hoofdpijplijn. Als u deze aanpak wilt implementeren, maakt u een afzonderlijk YAML-bestand voor uw script en slaat u dat script vervolgens op in een afzonderlijke, beveiligde opslagplaats. U kunt vervolgens verwijzen naar de sjabloon en een geheime variabele doorgeven in uw YAML als parameter. De beveiligde variabele moet afkomstig zijn van Azure Key Vault, een variabelegroep of de gebruikersinterface van de pijplijn. Gebruik sjablonen voor meer informatie.
• Beperk geheimen met vertakkingsbeleid en machtigingen voor variabelengroepen: u kunt een combinatie van machtigingen voor variabelengroepen, voorwaardelijke taakinvoeging en vertakkingsbeleid gebruiken om ervoor te zorgen dat geheimen zijn gekoppeld aan de main vertakking. Zie Geheimen beveiligen voor meer informatie.
• Gebruik setvariable om het instellen van variabelen te beperken: Gebruik het settableVariables kenmerk om te configureren welke variabelen pijplijnauteurs mogen instellen in een pijplijn. Zonder deze instelling kunnen auteurs van pijplijnen onbeperkte nieuwe variabelen declareren met de setvariable opdracht voor logboekregistratie. Wanneer u een lege lijst with settableVariablesopgeeft, is alle instelling voor variabelen niet toegestaan. Zie het kenmerk in het settableVariables YAML-schema voor meer informatie.

De beste methode om een geheim te beveiligen, is om geen geheim te hebben. Vermijd het gebruik van geheimen indien mogelijk, sla ze nooit op in YAML-bestanden en zorg ervoor dat ze niet worden geregistreerd of afgedrukt om de beveiliging te behouden.

• Vermijd het gebruik van geheimen indien mogelijk: controleer of uw pijplijn een andere methode kan gebruiken dan het gebruik van een geheim om een taak uit te voeren, zoals een serviceverbinding met federatie van workloadidentiteit of een beheerde identiteit. Met beheerde identiteiten kunnen uw toepassingen en services zich bij Azure authenticeren zonder expliciete referenties. Zie Service-principals gebruiken & beheerde identiteitenvoor meer informatie. Plaats geen geheimen in YAML: sla nooit gevoelige waarden op als tekst zonder opmaak in een Azure Pipelines-bestand .yml bestand.
• Geen logboeken maken of geheimen afdrukken: vermijd het echoën van geheimen naar de console, het gebruik ervan in opdrachtregelparameters of het vastleggen ervan in bestanden. Azure Pipelines probeert waar mogelijk geheimen te verwijderen uit logboeken, maar kan niet elke manier vangen waarop geheimen kunnen worden gelekt.
• Gebruik geen gestructureerde gegevens, zoals JSON als geheimen: maak afzonderlijke geheimen voor elke gevoelige waarde. Deze aanpak zorgt voor een betere nauwkeurigheid van de redaction en minimaliseert het risico dat gevoelige gegevens per ongeluk zichtbaar worden gemaakt.

Geheime gegevens controleren en vervangen

Om uw pijplijnen te beveiligen, controleert u regelmatig de verwerking van geheimen in taken en logboeken, controleert en verwijdert u overbodige geheimen en roteert u geheimen om beveiligingsrisico's te minimaliseren.

• Verwerking van geheimen controleren in taken en logboeken: controleert taken om ervoor te zorgen dat geheimen niet naar hosts worden verzonden of naar logboeken worden afgedrukt. Controleer of er geen geheimen zijn in logboekbestanden, inclusief de foutenlogboeken.
• Geregistreerde geheimen beoordelen: Bevestig of geheimen in uw pijplijn nog steeds nodig zijn en verwijder eventuele geheimen die niet meer nodig zijn om overbodige items en potentiële beveiligingsrisico's te verminderen.
• Geheimen rouleren: Rouleer geheimen regelmatig om het tijdvenster te minimaliseren waarin een gecompromitteerd geheim kan worden benut.

Uitvoering van schadelijke code voorkomen

Als u ervoor wilt zorgen dat alleen geteste en opgeschoonde code via uw pijplijn wordt uitgevoerd, controleert u regelmatig uw pijplijnen op veelvoorkomende problemen.

• Code scannen: Escape speciale tekens in argumenten om shell-opdrachtinjectie te voorkomen. U kunt GitHub Advanced Security voor Azure DevOps gebruiken om het scannen van code te automatiseren.
• Invoer valideren en parameters gebruiken: invoerparameters en argumenten valideren om onbedoeld gedrag te voorkomen. Gebruik geparameteriseerde query's in scripts om SQL-injectie te voorkomen. Runtimeparameters helpen beveiligingsproblemen met betrekking tot variabelen, zoals argumentinjectie, te voorkomen.
• Gebruik PATH niet in scripts: Het is gevaarlijk om te vertrouwen op de instelling van de agent, omdat deze kan worden gewijzigd door een eerder script of hulpprogramma. Gebruik altijd een volledig gespecifieerd pad.
• Beschikbare taken beheren: schakel de mogelijkheid uit om taken te installeren en uit te voeren vanuit Marketplace, zodat u meer controle hebt over de code die in een pijplijn wordt uitgevoerd.

Beveiligde containers

Meer informatie over het beveiligen van containers via configuratiewijzigingen, scannen en beleid.

• Volumes markeren als alleen-lezen: containers bevatten door het systeem geleverde volumekoppelingen voor taken, hulpprogramma's en externe onderdelen die nodig zijn om met de hostagent te werken. Stel externals, tasksen tools als alleen-lezen in voor extra beveiliging.
• Containerspecifieke resourcelimieten instellen: stel limieten in voor CPU en geheugen om te voorkomen dat containers overmatige resources verbruiken, wat kan leiden tot denial of service- of beveiligingsproblemen.
• Gebruik vertrouwde installatiekopieën: gebruik officiële en geverifieerde installatiekopieën van betrouwbare bronnen, zoals Azure Container Registry of Docker Hub. Geef altijd een specifieke versie of tag op om consistentie en betrouwbaarheid te behouden, in plaats van te vertrouwen op de latest tag. Werk basisinstallatiekopieën regelmatig bij om de meest recente beveiligingspatches en bugfixes op te nemen.
• containers scannen op beveiligingsproblemen en runtime-bedreigingsbeveiliging afdwingen: gebruik hulpprogramma's zoals Microsoft Defender voor Cloud om beveiligingsrisico's te bewaken en te detecteren. Daarnaast biedt Azure Container Registry geïntegreerde scannen op beveiligingsproblemen om ervoor te zorgen dat containerinstallatiekopieën vóór de implementatie veilig zijn. U kunt ook scanhulpprogramma's van derden integreren via Azure DevOps-extensies voor extra beveiligingscontroles.
• Implementeer beveiligingsbeleid om escalatie van bevoegdheden te voorkomen en ervoor te zorgen dat containers worden uitgevoerd met de minst mogelijke nodige bevoegdheden: Voorbeeld: Azure Kubernetes Service (AKS), rolgebaseerde toegangscontrole en Pod Security Admissionsmechanisme stellen u in staat om beleidsregels af te dwingen die containerbevoegdheden beperken, niet-root uitvoering garanderen en toegang tot kritieke resources beperken.
• Netwerkbeleid gebruiken: netwerkbeleid kan worden gebruikt om de communicatie tussen containers te beperken, zodat alleen geautoriseerde containers toegang hebben tot gevoelige resources binnen uw netwerk. Daarnaast kan Azure Policy voor AKS worden toegepast om best practices voor containerbeveiliging af te dwingen, om ervoor te zorgen dat alleen vertrouwde containerafbeeldingen worden geïmplementeerd.

Sjablonen gebruiken om aanbevolen procedures af te dwingen

Begin met een minimale sjabloon en dwing geleidelijk extensies af. Deze aanpak zorgt ervoor dat u bij het implementeren van beveiligingsprocedures een gecentraliseerd uitgangspunt hebt dat alle pijplijnen omvat.

• Uitbreidingssjablonen gebruiken: Breidt sjablonen definiëren de buitenste structuur en bieden specifieke punten voor gerichte aanpassingen. Het uitbreiden van sjablonen kan voorkomen dat schadelijke code een pijplijn infiltreert.
• Beperk de toegang met stappen: beperk de netwerktoegang door stappen uit te voeren, zoals het downloaden van pakketten die worden uitgevoerd op een container in plaats van op de host. Wanneer de stappen in een container worden uitgevoerd, voorkomt u dat een ongeldige actor de configuratie van de agent wijzigt of schadelijke code laat staan voor latere uitvoering.

Verwante artikelen

• Microsoft Security Development Lifecycle
• Vertrouwenscentrum van Azure