Beveiliging van opslagplaatsen

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

De broncode, het YAML-bestand van de pijplijn en de benodigde scripts en hulpprogramma's worden allemaal opgeslagen in een opslagplaats voor versiebeheer. Machtigingen en vertakkingsbeleid moeten worden gebruikt om ervoor te zorgen dat wijzigingen in de code en pijplijn veilig zijn. U kunt ook pijplijnmachtigingen en controles toevoegen aan opslagplaatsen.

U moet ook het standaardtoegangsbeheer voor opslagplaatsen controleren.

Vanwege het ontwerp van Git zal beveiliging op vertakkingsniveau u alleen tot nu toe dragen. Gebruikers met pushtoegang tot een opslagplaats kunnen meestal nieuwe vertakkingen maken. Als u opensource-projecten van GitHub gebruikt, kan iedereen met een GitHub-account uw opslagplaats splitsen en bijdragen terug voorstellen. Omdat pijplijnen zijn gekoppeld aan een opslagplaats en niet met specifieke vertakkingen, moet u ervan uitgaan dat de code en YAML-bestanden niet worden vertrouwd.

Voorvorken

Als u openbare opslagplaatsen bouwt vanuit GitHub, moet u rekening houden met uw houding bij fork-builds. Forks zijn vooral gevaarlijk omdat ze afkomstig zijn van buiten uw organisatie. Houd rekening met de volgende aanbevelingen om uw producten te beschermen tegen bijgedragen code.

Notitie

De volgende aanbevelingen zijn voornamelijk van toepassing op het bouwen van openbare opslagplaatsen vanuit GitHub.

Geen geheimen voor fork-builds opgeven

Uw pijplijnen zijn standaard geconfigureerd voor het bouwen van forks, maar geheimen en beveiligde resources worden standaard niet beschikbaar gemaakt voor de taken in deze pijplijnen. Schakel deze laatste beveiliging niet uit.

Notitie

Wanneer u fork-builds inschakelt voor toegang tot geheimen, beperkt Azure Pipelines standaard het toegangstoken dat wordt gebruikt voor fork-builds. Het heeft beperktere toegang tot open resources dan een normaal toegangstoken. Als u fork-builds dezelfde machtigingen wilt geven als gewone builds, schakelt u de fork-builds in met dezelfde machtigingen als de normale builds-instelling .

Overweeg om fork-builds handmatig te activeren

U kunt automatische fork-builds uitschakelen en in plaats daarvan pull-aanvraagopmerkingen gebruiken als een manier om deze bijdragen handmatig te bouwen. Met deze instelling kunt u de code controleren voordat u een build activeert.

Door Microsoft gehoste agents gebruiken voor fork-builds

Voer geen builds uit vanuit forks op zelf-hostende agents. Door dit te doen, biedt u effectief een pad naar externe organisaties om externe code uit te voeren op computers in uw bedrijfsnetwerk. Gebruik waar mogelijk door Microsoft gehoste agents. Gebruik voor uw zelf-hostende agent een vorm van netwerkisolatie en zorg ervoor dat agents hun status niet tussen taken behouden.

Codewijzigingen controleren

Voordat u uw pijplijn uitvoert op een geforkte pull-aanvraag, controleert u de voorgestelde wijzigingen zorgvuldig en controleert u of u de pijplijn goed kunt uitvoeren.

De versie van de YAML-pijplijn die u gaat uitvoeren, is de versie van de pull-aanvraag. Let dus vooral op wijzigingen in de YAML-code en op de code die wordt uitgevoerd wanneer de pijplijn wordt uitgevoerd, zoals opdrachtregelscripts of eenheidstests.

Beperking van bereik van GitHub-token

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. Als u andere vormen van GitHub-integratie gebruikt, bijvoorbeeld de OAuth-app, wordt de beperking niet afgedwongen.

Gebruikersbranches

Gebruikers in uw organisatie met de juiste machtigingen kunnen nieuwe vertakkingen met nieuwe of bijgewerkte code maken. Deze code kan worden uitgevoerd via dezelfde pijplijn als uw beveiligde vertakkingen. Als het YAML-bestand in de nieuwe vertakking verder wordt gewijzigd, wordt de bijgewerkte YAML gebruikt om de pijplijn uit te voeren. Hoewel dit ontwerp grote flexibiliteit en selfservice mogelijk maakt, zijn niet alle wijzigingen veilig (al dan niet kwaadwillend).

Als uw pijplijn broncode verbruikt of is gedefinieerd in Azure-opslagplaatsen, moet u het machtigingsmodel voor Azure-opslagplaatsen volledig begrijpen. In het bijzonder kan een gebruiker met de machtiging Branch maken op het niveau van de opslagplaats code aan de opslagplaats toevoegen, zelfs als die gebruiker geen bijdragemachtiging heeft.

Volgende stappen

Lees vervolgens meer over de meer beveiliging die wordt geboden door controles op beveiligde resources.