Andere beveiligingsoverwegingen voor Azure Pipelines

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

Als het gaat om het beveiligen van Azure Pipelines, zijn er verschillende andere overwegingen waarmee u rekening moet houden, zoals het beveiligen van gedeelde infrastructuur, opslagplaatsen, projecten en meer.

Gedeelde infrastructuur beveiligen

Beveiligde resources in Azure Pipelines zijn een abstractie van echte infrastructuur. Volg deze aanbevelingen om de onderliggende infrastructuur te beveiligen.

Door Microsoft gehoste pools gebruiken

Door Microsoft gehoste pools bieden isolatie en een schone virtuele machine voor elke uitvoering van een pijplijn. Gebruik indien mogelijk door Microsoft gehoste pools in plaats van zelf-hostende pools.

Afzonderlijke agents voor elk project

Een agent kan slechts aan één pool worden gekoppeld. U kunt agents in verschillende projecten delen door de pool te koppelen aan meerdere projecten. In de praktijk kunnen meerdere projecten dezelfde agent opeenvolgend gebruiken. Hoewel kosteneffectief, kan deze aanpak laterale verplaatsingsrisico's veroorzaken.

Als u zijdelingse verplaatsing wilt beperken en kruisbesmetting tussen projecten wilt voorkomen, onderhoudt u afzonderlijke agentpools, die elk zijn toegewezen aan een specifiek project.

Accounts met beperkte bevoegdheden gebruiken om agents uit te voeren

Hoewel u misschien verleidelijk bent, kan het uitvoeren van de agent onder een identiteit met directe toegang tot Azure DevOps-resources riskant zijn. Deze installatie is gangbaar in organisaties die Microsoft Entra-id gebruiken, maar vormt wel risico's. Als u de agent uitvoert onder een identiteit die wordt ondersteund door Microsoft Entra ID, heeft deze rechtstreeks toegang tot Azure DevOps-API's zonder dat deze afhankelijk is van het toegangstoken van de taak. Voor betere beveiliging kunt u overwegen om de agent uit te voeren met een niet-gemachtigd lokaal account, zoals Netwerkservice.

Belangrijk

In Azure DevOps is er een groep met de naam Project Collection Service Accounts, die misleidend kan zijn. Door overname worden leden van Serviceaccounts van Project Collection ook beschouwd als leden van beheerders van projectverzamelingen. Sommige klanten voeren hun buildagents uit met behulp van een identiteit die wordt ondersteund door Microsoft Entra-id. Deze identiteiten maken mogelijk deel uit van Project Collection Service Accounts. Maar als kwaadwillende personen een pijplijn uitvoeren op een van deze buildagents, kunnen ze mogelijk controle krijgen over de hele Azure DevOps-organisatie.

Er zijn exemplaren waarbij zelf-hostende agents worden uitgevoerd onder accounts met hoge bevoegdheden. Deze agents maken vaak gebruik van deze bevoegde accounts voor toegang tot geheimen of productieomgevingen. Maar als kwaadwillende personen een gecompromitteerde pijplijn uitvoeren op een van deze buildagents, krijgen ze toegang tot die geheimen. Vervolgens kunnen de kwaadwillende personen zich lateraal verplaatsen via andere systemen die toegankelijk zijn via deze accounts.

Om de systeembeveiliging te verbeteren, raden we u aan het laagste bevoegde account te gebruiken voor het uitvoeren van zelf-hostende agents. U kunt bijvoorbeeld overwegen uw computeraccount of een beheerde service-identiteit te gebruiken. Vertrouw ook Azure Pipelines toe met het beheren van toegang tot geheimen en omgevingen.

Het bereik van serviceverbindingen minimaliseren

Zorg ervoor dat serviceverbindingen alleen toegang hebben tot de benodigde resources. Overweeg waar mogelijk om workloadidentiteitsfederatie te gebruiken 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.

Zorg ervoor dat uw Azure-serviceverbinding alleen toegang heeft tot de benodigde resources. Vermijd het verlenen van brede inzenderrechten voor het hele Azure-abonnement aan gebruikers.

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 nodig zijn voor de build. Wanneer u de GitHub-app configureert, verleent u ook alleen toegang tot de opslagplaatsen die u wilt bouwen met behulp van Azure Pipelines.

Projecten beveiligen

Naast afzonderlijke resources is het van cruciaal belang om resourcegroepen in Azure DevOps te overwegen. Resources worden georganiseerd op basis van teamprojecten en begrijpen waartoe uw pijplijn toegang heeft op basis van projectinstellingen en insluiting is essentieel.

Elke taak in uw pijplijn ontvangt een toegangstoken met machtigingen voor het lezen van open resources. In sommige gevallen kunnen pijplijnen deze resources ook bijwerken. Dit betekent dat uw gebruikersaccount mogelijk geen directe toegang heeft tot een specifieke resource, scripts en taken die in uw pijplijn worden uitgevoerd, nog steeds toegang heeft tot deze resource. Daarnaast biedt het beveiligingsmodel van Azure DevOps toegang tot deze resources vanuit andere projecten binnen de organisatie. Als u besluit om de toegang van pijplijnen tot bepaalde resources te beperken, is deze beslissing van toepassing op alle pijplijnen binnen een project. Specifieke pijplijnen kunnen niet selectief toegang krijgen tot open resources.

Afzonderlijke projecten

Gezien de aard van open resources, kunt u overwegen om elk product en team in afzonderlijke projecten te beheren. Door dit te doen, voorkomt u dat pijplijnen van het ene product per ongeluk toegang krijgen tot open resources van een ander product, waardoor laterale blootstelling wordt geminimaliseerd. Maar wanneer meerdere teams of producten een project delen, wordt gedetailleerde isolatie van hun resources lastig.

Als uw Azure DevOps-organisatie vóór augustus 2019 is gemaakt, hebben uitvoeringen mogelijk nog steeds toegang tot open resources in alle projecten van uw organisatie. De beheerder van uw organisatie moet een kritieke beveiligingsinstelling controleren in Azure Pipelines waarmee projectisolatie voor pijplijnen mogelijk is.

U vindt deze instelling in De instellingen voor organisatie-pijplijnen>> of rechtstreeks: . https://dev.azure.com/Organization_Name/_settings/pipelinessettings

Opslagplaatsen beveiligen

In opslagplaatsen voor versiebeheer kunt u de broncode, het YAML-bestand van de pijplijn en de benodigde scripts en hulpprogramma's opslaan. Om veilige wijzigingen in de code en pijplijn te garanderen, is het van cruciaal belang om machtigingen en vertakkingsbeleid toe te passen. Overweeg daarnaast pijplijnmachtigingen toe te voegen en controles uit te voeren op opslagplaatsen.

Bekijk bovendien de standaardinstellingen voor toegangsbeheer voor uw opslagplaatsen.

Houd er rekening mee dat het ontwerp van Git betekent dat beveiliging op vertakkingsniveau beperkingen heeft. Gebruikers met pushtoegang tot een opslagplaats kunnen doorgaans nieuwe vertakkingen maken. Als u met opensource-projecten van GitHub werkt, kan iedereen met een GitHub-account uw opslagplaats splitsen en bijdragen voorstellen. Omdat pijplijnen zijn gekoppeld aan een opslagplaats (geen specifieke vertakkingen), is het essentieel om code- en YAML-bestanden te behandelen als mogelijk niet-vertrouwd.

Voorvorken

Wanneer u werkt met openbare opslagplaatsen vanuit GitHub, is het essentieel om zorgvuldig na te denken over uw benadering van fork-builds. Forks, afkomstig van buiten uw organisatie, vormen bepaalde risico's. Als u uw producten wilt beschermen tegen mogelijk niet-vertrouwde bijgedragen code, moet u rekening houden met de volgende aanbevelingen

Notitie

Deze 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 niet automatisch blootgesteld aan de taken in deze pijplijnen. Het is essentieel om deze beveiliging niet uit te schakelen om de beveiliging te behouden.

Notitie

Wanneer u fork-builds inschakelt voor toegang tot geheimen, beperkt Azure Pipelines het toegangstoken dat standaard wordt gebruikt. Dit token heeft beperkte toegang tot open resources in vergelijking met een normaal toegangstoken. Als u fork-builds dezelfde machtigingen wilt verlenen 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

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. Implementeer voor zelf-hostende agents netwerkisolatie en zorg ervoor dat agents de status tussen taken niet 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 uitvoert, 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 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.

Andere beveiligingsoverwegingen

Er zijn de volgende andere dingen die u moet overwegen bij het beveiligen van pijplijnen.

Afhankelijk van PATH

Afhankelijk van de instelling van PATH de agent is gevaarlijk. Het kan niet wijzen waar u denkt dat het doet, omdat het mogelijk is gewijzigd door een eerder script of hulpprogramma. Gebruik voor beveiligingskritieke scripts en binaire bestanden altijd een volledig gekwalificeerd pad naar het programma.

Logboekgeheimen

Azure Pipelines probeert waar mogelijk geheimen te verwijderen uit logboeken. Deze filtering is op basis van best effort en kan niet elke manier vangen waarop geheimen kunnen worden gelekt. Vermijd het echoën van geheimen naar de console, het gebruik ervan in opdrachtregelparameters of het vastleggen van geheimen in bestanden.

Containers vergrendelen

Containers hebben een aantal door het systeem geleverde volumekoppelingen in de taken, de werkruimte en externe onderdelen die nodig zijn om te communiceren met de hostagent. U kunt een of al deze volumes markeren als alleen-lezen.

resources:
  containers:
  - container: example
    image: ubuntu:22.04
    mountReadOnly:
      externals: true
      tasks: true
      tools: true
      work: false  # the default; shown here for completeness

Normaal gesproken moeten de meeste personen de eerste drie mappen instellen als alleen-lezen en laten staan work als lezen/schrijven. Als u niet naar de work map schrijft in een specifieke taak of stap, kunt u ook het kenmerk Alleen-lezen maken work . Maar als uw pijplijntaken zelf moeten worden gewijzigd, moet u mogelijk behouden tasks als lezen/schrijven.

Beschikbare taken beheren

U kunt de mogelijkheid uitschakelen om taken te installeren en uit te voeren vanuit Marketplace, zodat u meer controle hebt over de code die in een pijplijn wordt uitgevoerd. U kunt ook alle in-the-box-taken uitschakelen (behalve Uitchecken, een speciale actie op de agent). Het is raadzaam om taken in het vak in de meeste gevallen niet uit te schakelen.

Taken die rechtstreeks zijn geïnstalleerd met tfx zijn altijd beschikbaar. Als beide functies zijn ingeschakeld, zijn alleen deze taken beschikbaar.

De controleservice gebruiken

Veel pijplijn-gebeurtenissen worden vastgelegd in de controleservice. Controleer het auditlogboek regelmatig om ervoor te zorgen dat er geen schadelijke wijzigingen voorbij zijn gelopen. Bezoek https://dev.azure.com/ORG-NAME/_settings/audit om aan de slag te gaan.

Volgende stappen

Bekijk het beveiligingsoverzicht