Share via

Aanbevolen procedures voor beveiliging

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Wanneer u informatie en gegevens verwerkt, met name in een cloudoplossing zoals Azure DevOps Services, moet beveiliging de hoogste prioriteit hebben. Hoewel Microsoft de beveiliging van de onderliggende cloudinfrastructuur garandeert, is het configureren van beveiliging binnen Azure DevOps uw verantwoordelijkheid.

Hoewel dit niet verplicht is, kan het opnemen van best practices uw ervaring aanzienlijk verbeteren en de beveiliging verbeteren. De volgende aanbevelingen zijn ontworpen om u te helpen een beveiligde Azure DevOps-omgeving te onderhouden.

Uw Azure DevOps-omgeving beveiligen

Gebruik de volgende aanbevolen procedures voor het verwijderen van gebruikers, het controleren van controlegebeurtenissen en het integreren met Microsoft Entra ID.

Gebruikers verwijderen

  • Inactieve gebruikers verwijderen uit MSA-accounts:
  • Microsoft Entra-gebruikersaccounts uitschakelen of verwijderen:
    • Als uw organisatie is verbonden met Microsoft Entra-id, kunt u het Microsoft Entra-gebruikersaccount uitschakelen of verwijderen terwijl het Azure DevOps-gebruikersaccount actief blijft.
    • Met deze methode kunt u de geschiedenis van werkitems blijven opvragen met behulp van uw Azure DevOps-gebruikers-id.
  • Gebruikers-PAW's intrekken:
    • Controleer en trek alle bestaande gebruikers-PAW's regelmatig in.
    • PAW's zijn essentiële verificatietokens en het veilig beheren ervan is essentieel.
  • Speciale machtigingen intrekken die zijn verleend aan afzonderlijke gebruikers:
    • Controleer en trek eventuele speciale machtigingen in die zijn verleend aan afzonderlijke gebruikersaccounts.
    • Zorg ervoor dat machtigingen zijn afgestemd op het principe van minimale bevoegdheden.
  • Werk opnieuw toewijzen aan verwijderde gebruikers:
    • Voordat u gebruikers verwijdert, moet u alle werkitems die ze verwerken opnieuw toewijzen.
    • Distribueer de workload over de huidige teamleden.

Microsoft Entra-id gebruiken

  • Eén vlak voor identiteit:
    • Door Azure DevOps te verbinden met Microsoft Entra ID, maakt u een geïntegreerd identiteitssysteem.
    • Consistentie tussen services vermindert verwarring en minimaliseert beveiligingsrisico's die voortvloeien uit handmatige configuratiefouten.
  • End-to-end-governance:
    • Door gebruik te maken van Microsoft Entra ID kunt u verfijnde governance implementeren.
    • Wijs verschillende rollen en machtigingen toe aan specifieke Microsoft Entra-groepen in verschillende resourcebereiken.
    • Deze aanpak zorgt voor gecontroleerde toegang en is afgestemd op aanbevolen beveiligingsprocedures.
  • Beveiligingsfuncties:
    • Microsoft Entra ID maakt extra beveiligingsfuncties mogelijk, zoals:
      • Meervoudige verificatie (MFA): Verbeter gebruikersverificatie door meerdere factoren te vereisen (bijvoorbeeld wachtwoord- en telefoonverificatie).
      • Beleid voor voorwaardelijke toegang: definieer toegangsregels op basis van voorwaarden (bijvoorbeeld locatie, apparaat of risiconiveau).

Raadpleeg voor meer informatie de volgende artikelen:

Controle-gebeurtenissen controleren

Zodra uw organisatie wordt ondersteund door Microsoft Entra, voert u de volgende taken uit om de beveiliging te verbeteren en gebruikspatronen te bewaken:

  • Controle inschakelen:
    • Schakel controle in binnen uw beveiligingsbeleid.
    • Controle helpt bij het bijhouden en vastleggen van gebeurtenissen met betrekking tot gebruikersacties, machtigingen en wijzigingen.
  • Controleer regelmatig auditgebeurtenissen:
    • Controleer regelmatig het auditlogboek.
    • Zoek naar onverwachte gebruikspatronen, met name door beheerders en andere gebruikers.

Uw netwerk beveiligen

De volgende functies zijn effectieve manieren om de beveiliging van uw netwerk te verbeteren wanneer u met Azure DevOps werkt.

  • IP-acceptatielijst:
    • Stel een acceptatielijst in om de toegang tot specifieke IP-adressen te beperken.
    • Sta alleen verkeer van vertrouwde bronnen toe, waardoor de kwetsbaarheid voor aanvallen wordt verminderd.
  • Versleuteling:
    • Gebruik altijd versleuteling voor gegevens die worden overgedragen en at-rest.
    • Beveilig communicatiekanalen met behulp van protocollen zoals HTTPS.
  • Certificaatvalidatie:
    • Valideer certificaten bij het tot stand brengen van verbindingen.
    • Zorg ervoor dat certificaten geldig en uitgegeven zijn door vertrouwde autoriteiten.
  • Web Application Firewalls (WAF's):
    • Implementeer WAF's om schadelijk webverkeer te filteren, bewaken en blokkeren.
    • WAF's bieden een extra beveiligingslaag tegen veelvoorkomende aanvallen.

Zie Best practices voor toepassingsbeheer voor meer informatie.

Bereikmachtigingen

Het systeem verwerkt machtigingen op verschillende niveaus( afzonderlijke, verzameling, project en object) en wijst deze standaard toe aan een of meer ingebouwde groepen. Ga als volgt te werk om de beveiliging te verbeteren:

  • Minimale toegangsrechten bieden: geef gebruikers en services de minimale toegang die nodig is om hun bedrijfsfuncties uit te voeren.
  • Overname uitschakelen:
    • Schakel waar mogelijk overname uit.
    • Overname kan per ongeluk toegang of machtigingen verlenen aan onverwachte gebruikers vanwege de standaard toegestane aard.
    • Raadpleeg de sectie over overname van machtigingen voor meer informatie

Zie de volgende artikelen voor meer informatie over machtigingen:

Machtigingen op projectniveau

  • Beperk de toegang tot projecten en opslagplaatsen:
    • Beperk de toegang tot projecten en opslagplaatsen om het risico op het lekken van gevoelige informatie en het implementeren van onveilige code voor productie te verminderen.
    • Gebruik de ingebouwde beveiligingsgroepen of aangepaste beveiligingsgroepen om machtigingen te beheren. Zie Machtigingen verlenen of beperken voor specifieke taken voor meer informatie.
  • Schakel 'Openbare projecten toestaan' uit:
    • Schakel in de beleidsinstellingen van uw organisatie de optie uit om openbare projecten te maken.
    • Met Azure DevOps Services kunt u de zichtbaarheid van het project wijzigen van openbaar naar privé (en omgekeerd).
    • Gebruikers die zich niet hebben aangemeld bij uw organisatie hebben alleen-lezentoegang tot openbare projecten.
    • Aangemelde gebruikers kunnen toegang krijgen tot privéprojecten en toegestane wijzigingen aanbrengen.
  • Het maken van een project beperken:
    • Voorkom dat gebruikers nieuwe projecten maken om de controle over uw omgeving te behouden.

Externe gasttoegang

  • Externe gasttoegang blokkeren:
    • Schakel het beleid Toestaan dat uitnodigingen worden verzonden naar een domein uit om externe gasttoegang te voorkomen.
    • Houd rekening met deze stap als er geen zakelijke behoefte is aan externe gasten.
  • Gebruik een andere e-mail of UPN voor uw persoonlijke en zakelijke accounts:
    • Hoewel dit is toegestaan, gebruikt u afzonderlijke e-mailadressen of UPN's (User Principal Names) voor persoonlijke en zakelijke accounts.
    • Deze procedure elimineert dubbelzinnigheid bij het ondubbelzinnig maken van uw persoonlijke en werkgerelateerde accounts.
  • Externe gastgebruikers groeperen:
    • Plaats alle externe gastgebruikers in één Microsoft Entra-groep.
    • Machtigingen voor deze groep op de juiste manier beheren.
    • Verwijder directe toewijzingen om ervoor te zorgen dat groepsregels van toepassing zijn op deze gebruikers. Zie Een groepsregel toevoegen om toegangsniveaus toe te wijzen voor meer informatie.
    • Evalueer regelmatig regels opnieuw op het tabblad Groepsregels van de pagina Gebruikers. Houd rekening met eventuele wijzigingen in het groepslidmaatschap in Microsoft Entra-id die van invloed kunnen zijn op uw organisatie. Het kan tot 24 uur duren voordat microsoft Entra ID het dynamische groepslidmaatschap bijwerkt. Regels worden elke 24 uur automatisch opnieuw geëvalueerd en wanneer een groepsregel wordt gewijzigd.

Zie B2B-gasten in de Microsoft Entra-id voor meer informatie.

Beveiligingsgroepen beheren

Beveiligings- en gebruikersgroepen

De volgende tabel bevat aanbevelingen voor het toewijzen van machtigingen aan beveiligingsgroepen en gebruikersgroepen.

Doen Niet doen
Gebruik Microsoft Entra ID-, Active Directory- of Windows-beveiligingsgroepen wanneer u veel gebruikers beheert. Wijzig de standaardmachtigingen voor de groep Geldige gebruikers van Project niet. Deze groep kan projectgegevens openen en weergeven.
Wanneer u teams toevoegt, kunt u overwegen welke machtigingen u wilt toewijzen aan teamleden die gebiedspaden, iteratiepaden en query's moeten maken en wijzigen. Voeg geen gebruikers toe aan meerdere beveiligingsgroepen die verschillende machtigingsniveaus bevatten. In bepaalde gevallen kan een machtigingsniveau Weigeren een machtigingsniveau Toestaan overschrijven.
Wanneer u veel teams toevoegt, kunt u een aangepaste groep Teambeheerders maken waarin u een subset van de machtigingen toewijst die beschikbaar zijn voor Projectbeheerders. Wijzig de standaardtoewijzingen die zijn gemaakt in de groepen Geldige gebruikers van Project niet. Als u gegevens op exemplaarniveau weergeven verwijdert of instelt op Weigeren voor een van de groepen Geldige gebruikers van Project, hebben geen gebruikers in de groep toegang tot elk project, verzameling of implementatie waarvoor u de machtiging hebt ingesteld.
U kunt de werkitemquerymappen bijdragen verlenen aan gebruikers of groepen die de mogelijkheid nodig hebben om werkitemquery's voor het project te maken en te delen. Wijs geen machtigingen toe die worden vermeld als Alleen toewijzen aan serviceaccounts aan gebruikersaccounts.
Houd groepen zo klein mogelijk. Toegang moet worden beperkt en de groepen moeten regelmatig worden gecontroleerd.
Profiteer van ingebouwde rollen en standaard inzender voor ontwikkelaars. Beheerders worden toegewezen aan de beveiligingsgroep Projectbeheerder voor verhoogde machtigingen, zodat ze beveiligingsmachtigingen kunnen configureren.

Zie Geldige gebruikersgroepen voor meer informatie.

Just-In-Time-toegang voor beheerdersgroepen

Als u toegang hebt tot projectverzamelingsbeheerder en projectbeheerder , kunt u de configuratie van uw organisatie of project wijzigen. Als u de beveiliging voor deze ingebouwde beheerdersgroepen wilt verbeteren, kunt u Just-In-Time-toegang implementeren met behulp van een Pim-groep (Microsoft Entra Privileged Identity Management). Met deze methode kunt u alleen verhoogde machtigingen verlenen wanneer dat nodig is, waardoor het risico voor permanente toegang wordt verminderd.

Toegang configureren

  1. Maak een door rollen toewijsbare groep in Microsoft Entra-id.
  2. Voeg uw Microsoft Entra-groep toe aan de Azure DevOps-groep.

Notitie

Wanneer u Just-In-Time-toegang configureert met behulp van een Pim-groep (Microsoft Entra Privileged Identity Management), moet u ervoor zorgen dat elke gebruiker met verhoogde toegang ook standaardtoegang tot de organisatie behoudt. Op deze manier kunnen ze de benodigde pagina's bekijken en zo nodig hun machtigingen vernieuwen.

Toegang gebruiken

  1. Activeer uw toegang.
  2. Vernieuw uw machtigingen in Azure DevOps.
  3. Voer de actie uit waarvoor beheerderstoegang is vereist.

Notitie

Gebruikers hebben maximaal 1 uur nadat hun PIM-groepstoegang is gedeactiveerd in Azure DevOps.

Serviceaccounts bereik

  • Inzicht in serviceaccounts
  • Serviceaccounts voor één doel maken:
    • Elke service moet zijn toegewezen account hebben om het risico te minimaliseren.
    • Vermijd het gebruik van gewone gebruikersaccounts als serviceaccounts.
  • Volg de naamgevings- en documentatieconventies:
    • Gebruik duidelijke, beschrijvende namen voor serviceaccounts.
    • Documenteer het doel en de bijbehorende services.
  • Ongebruikte serviceaccounts identificeren en uitschakelen:
    • Controleer en identificeer regelmatig accounts die niet meer worden gebruikt.
    • Schakel ongebruikte accounts uit voordat u het verwijderen overweegt.
  • Bevoegdheden beperken:
    • Beperk de bevoegdheden van het serviceaccount tot het minimum dat nodig is.
    • Vermijd interactieve aanmeldingsrechten voor serviceaccounts.
  • Afzonderlijke identiteiten gebruiken voor rapportlezers:
    • Als u domeinaccounts gebruikt voor serviceaccounts, gebruikt u een andere identiteit voor rapportlezers.
    • Machtigingen isoleren om onnodige toegang te voorkomen. Zie Serviceaccounts en afhankelijkheden voor meer informatie.
  • Lokale accounts gebruiken voor werkgroepinstallaties:
    • Wanneer u onderdelen in een werkgroep installeert, gebruikt u lokale accounts voor gebruikersaccounts.
    • Vermijd domeinaccounts in dit scenario. Zie Vereisten voor serviceaccounts voor meer informatie.
  • Maak gebruik van serviceverbindingen:
    • Gebruik waar mogelijk serviceverbindingen.
    • Ze bieden een veilige manier om verbinding te maken met services zonder geheime variabelen rechtstreeks door te geven aan builds.
    • Beperk verbindingen met specifieke gebruiksvoorbeelden.
  • Activiteit van serviceaccount bewaken:
    • Controle implementeren en controlestromen maken.

Zie Common Service Connection Types voor meer informatie.

Bereikserviceverbindingen

  • Bereik van Azure Resource Manager-serviceverbindingen :
    • Als u de toegang wilt beperken, moet u de serviceverbindingen beperken tot specifieke resources en groepen. Vermijd het verlenen van brede inzenderrechten voor het hele Azure-abonnement.
    • Gebruik federatie van workloadidentiteit voor verificatie. Hierdoor kunnen serviceverbindingen zonder geheimen in Azure Pipelines worden toegestaan.
  • Workloadidentiteitsfederatie gebruiken:
    • Federatie van workloadidentiteit maakt gebruik van OpenID Connect (OIDC) voor verificatie met Azure-resources zonder geheimen.
    • U kunt workloadidentiteitsfederatie automatisch of handmatig maken. Houd rekening met deze aanpak als:
      • U hebt de rol Eigenaar voor het Azure-abonnement.
      • U maakt geen verbinding met Azure Stack- of Azure US Government-omgevingen.
      • Alle Marketplace-extensies die u gebruikt, ondersteunen workloadidentiteitsfederatie1.
  • Bereik van resourcegroep:
    • Zorg ervoor dat de resourcegroep alleen de virtuele machines (VM's) of resources bevat die nodig zijn voor het buildproces.
  • Vermijd klassieke Azure-serviceverbindingen:
    • Klassieke serviceverbindingen hebben geen bereikopties. Kies in plaats daarvan voor moderne Azure Resource Manager-serviceverbindingen.
  • Doelspecifieke teamserviceaccounts gebruiken:
    • Verifieer serviceverbindingen met behulp van doelspecifieke teamserviceaccounts om beveiliging en controle te behouden.

Zie Common Service Connection Types voor meer informatie.

De juiste verificatiemethode kiezen

Selecteer uw verificatiemethoden uit de volgende bronnen:

Service-principals overwegen

Bekijk alternatieven zoals service-principals en beheerde identiteiten:

  • Service-principals:
    • Vertegenwoordig beveiligingsobjecten in een Microsoft Entra-toepassing.
    • Definieer wat een toepassing in een bepaalde tenant kan doen.
    • Instellen tijdens de registratie van toepassingen in Azure Portal.
    • Geconfigureerd voor toegang tot Azure-resources, waaronder Azure DevOps.
    • Handig voor apps die specifieke toegang en beheer nodig hebben.
  • Beheerde identiteiten:
    • Vergelijkbaar met de service-principal van een toepassing.
    • Identiteiten opgeven voor Azure-resources.
    • Services die Microsoft Entra-verificatie ondersteunen, toestaan referenties te delen.
    • Azure verwerkt referentiebeheer en rotatie automatisch.
    • Ideaal als u naadloos beheer van aanmeldingsgegevens wilt.

PAT's spaarzaam gebruiken

  • Bereik-PAW's voor specifieke rollen:
    • Wijs alleen de benodigde machtigingen toe die nodig zijn voor specifieke taken. Vermijd het verlenen van globale toegang tot meerdere organisaties of opslagplaatsen.
    • Het bereik van PAW's zorgt ervoor dat ze de minimale bevoegdheden hebben die nodig zijn, waardoor het risico op onbedoeld misbruik wordt verminderd.
  • Schrijf- of beheermachtigingen voor builds en releases voorkomen:
    • PAW's mogen geen schrijf- of beheermachtigingen hebben voor builds, releases of andere kritieke resources.
    • Als u deze machtigingen beperkt, voorkomt u onbedoelde acties die van invloed kunnen zijn op uw pijplijnen of implementaties.
  • Vervaldatums instellen en PAT's geheim houden:
    • Stel altijd een vervaldatum in voor PAW's. Controleer ze regelmatig en vernieuw ze indien nodig.
    • PAT's behandelen als kritiek als wachtwoorden. Bewaar ze vertrouwelijk en voorkom dat ze openbaar worden gedeeld of in uw toepassingscode worden vastgelegd.
  • Vermijd hardcoderings-PAW's in toepassingscode:
    • Hoewel het misschien handig lijkt, vermijdt u het rechtstreeks insluiten van PAW's in uw code.
    • Gebruik in plaats daarvan beveiligde configuratiebestanden of omgevingsvariabelen om PAT's dynamisch op te slaan en op te halen.
  • Controleer regelmatig ongebruikte PAW's en trek deze in:
    • Beheerders moeten regelmatig alle PAW's controleren met behulp van de REST API's.
    • Trek alle PAW's in die niet meer nodig zijn of die niet voldoen aan de aanbevolen criteria.

Raadpleeg de volgende artikelen voor meer informatie:

Azure-artefacten beveiligen

Azure Boards beveiligen

Azure-pijplijnen beveiligen

Beleid

  • Revisoren buiten de oorspronkelijke aanvrager vereisen:
    • Ten minste één revisor buiten de oorspronkelijke aanvrager zorgt voor een grondiger beoordelingsproces.
    • De fiatteur deelt mede-eigendom van de wijzigingen en moet evengoed verantwoordelijk worden gehouden voor mogelijke gevolgen.
  • Vereisen dat CI-build wordt doorgegeven:
    • Vereisen dat de CI-build (Continuous Integration) wordt doorgegeven voordat een pull-aanvraag wordt samengevoegd, wordt een basislijn voor codekwaliteit vastgesteld.
    • CI-controles omvatten codelining, eenheidstests en beveiligingsscans (bijvoorbeeld virus- en referentiecontroles).
  • Zelfgoedkeuring door de oorspronkelijke aanvrager weigeren:
    • Voorkom dat de oorspronkelijke pull-aanvrager zijn/haar eigen wijzigingen goedkeurt.
    • Deze actie zorgt voor een onbevoorhaamd beoordelingsproces en voorkomt potentiële belangenconflicten.
  • De voltooiing van pull-aanvragen is zelfs niet toe te laten met 'wachten' of 'afwijzen'-stemmen:
    • Zelfs als sommige revisoren stemmen om te wachten of af te wijzen, voorkomt u voltooiing van pull-aanvragen.
    • Deze actie moedigt u aan alle feedback aan te pakken voordat u samenvoegt.
  • Revisorstemmen van code opnieuw instellen voor gepushte wijzigingen:
    • Wanneer recente wijzigingen naar de pull-aanvraag worden gepusht, stelt u revisorstemmen opnieuw in.
    • Deze actie zorgt ervoor dat revisoren de bijgewerkte code opnieuw evalueren.
  • Releasepijplijnen vergrendelen voor specifieke productiebranches:
    • Beperk release-pijplijnen tot specifieke vertakkingen (meestal productie of hoofd).
    • Vermijd onbedoelde implementaties van andere vertakkingen.
  • Settable-variabelen afdwingen op het moment van de wachtrij:
    • Schakel de optie Settable afdwingen bij wachtrijtijd in voor pijplijnvariabelen.
    • Met deze actie voorkomt u dat gebruikers variabele waarden overschrijven tijdens de uitvoering van de pijplijn.
  • Overschrijvingen van variabelen in de editor niet toestaan:
    • Voor variabelen die zijn ingesteld in de pijplijneditor, staat u onderdrukkingen van gebruikers niet toe.
    • Deze actie behoudt consistentie en voorkomt onbedoelde wijzigingen.

Agents

  • Machtigingen spaarzaam verlenen:
    • Beperk machtigingen tot de kleinste benodigde set accounts.
    • Vermijd overmissieve toegang, waardoor de kwetsbaarheid voor aanvallen wordt verminderd.
  • Beperkende firewalls voor bruikbare agents:
    • Configureer firewalls zo beperkend mogelijk, terwijl agents nog steeds kunnen functioneren.
    • Een balans vinden tussen beveiliging en bruikbaarheid.
  • Agentpools regelmatig bijwerken:
    • Houd uw agentpark up-to-date door agents regelmatig bij te werken.
    • Deze actie zorgt ervoor dat kwetsbare code niet wordt uitgevoerd, waardoor het risico op exploitatie wordt verminderd.
  • Afzonderlijke agentgroep voor productieartefacten:
    • Gebruik een afzonderlijke agentgroep voor buildartefacten die zijn bestemd voor productie.
    • Het isoleren van productieartefacten helpt onbedoelde implementaties van niet-productievertakkingen te voorkomen.
  • Gevoelige pools segmenteren:
    • Maak afzonderlijke pools voor gevoelige en niet-gevoelige workloads.
    • Sta alleen referenties toe in builddefinities die zijn gekoppeld aan de juiste pool.

Definities

  • YAML gebruiken voor pijplijndefinities:
    • YAML (Yet Another Markup Language) is de aanbevolen methode voor het definiëren van pijplijnen.
    • Het biedt traceerbaarheid voor wijzigingen, waardoor het eenvoudiger is om wijzigingen in de loop van de tijd bij te houden.
    • Daarnaast kunnen YAML-pijplijnen voldoen aan goedkeuringsrichtlijnen en procedures voor versiebeheer.
  • Beperk de toegang tot pijplijndefinities:
    • Beperk de toegang tot het bewerken van pijplijndefinities tot de minimaal benodigde accounts.
    • Door dit te doen, vermindert u het risico op onbedoelde of niet-geautoriseerde wijzigingen.

Invoer

  • Neem sanitycontroles op voor variabelen in buildscripts:
    • Implementeer sanitycontroles in uw buildscripts om mogelijke aanvallen met opdrachtinjectie te beperken via settabelvariabelen.
    • Deze controles kunnen invoerwaarden valideren en onbedoelde of schadelijke opdrachten voorkomen.
  • Beperk het aantal buildvariabelen voor 'settable at release time':
    • Stel zo weinig mogelijk buildvariabelen in als 'settable at release time'.
    • Het minimaliseren van het aantal van dergelijke variabelen vermindert het kwetsbaarheid voor aanvallen en vereenvoudigt het configuratiebeheer.

Opdrachten

  • Vermijd extern opgehaalde resources:
    • Vermijd waar mogelijk het ophalen van resources uit externe URL's tijdens het buildproces.
    • Als externe resources nodig zijn, gebruikt u versiebeheer en hashcontrole om de integriteit te waarborgen.
  • Vermijd logboekregistratiegeheimen:
    • Registreer nooit gevoelige informatie, zoals geheimen of referenties, in uw buildlogboeken.
    • Logboekregistratiegeheimen kunnen ze onbedoeld blootstellen en de beveiliging in gevaar brengen.
  • Azure Key Vault gebruiken voor geheimen:
    • Gebruik Azure Key Vault in plaats van geheimen rechtstreeks op te slaan in pijplijnvariabelen.
    • Key Vault biedt een veilige manier om geheimen centraal te beheren en op te halen.
  • Actieve builds beperken tot willekeurige vertakkingen of tags:
    • Beperk voor beveiligingskritieke pijplijnen het uitvoeren van builds op elke vertakking of tag.
    • Definieer specifieke geautoriseerde vertakkingen of tags om onbedoelde of niet-geautoriseerde uitvoeringen te voorkomen.
  • Overname uitschakelen voor pijplijnmachtigingen:
    • Overgenomen machtigingen kunnen te breed zijn en zijn mogelijk niet nauwkeurig in overeenstemming met uw behoeften.
    • Schakel overname uit en stel machtigingen expliciet in om te voldoen aan uw beveiligingsvereisten.
  • Werkautorisatiebereiken beperken:
    • Beperk taakautorisatiebereiken altijd tot het minimum dat nodig is.
    • Machtigingen verfijnen op basis van de specifieke taken die door elke taak worden uitgevoerd.

Opslagplaatsen en vertakkingen

  • Minimaal aantal revisoren vereisen:
    • Schakel het beleid 'Een minimum aantal revisoren vereisen' in om ervoor te zorgen dat elke pull-aanvraag beoordelingen ontvangt van ten minste twee goedkeurders.
    • Dit bevordert grondige codebeoordeling en verantwoordelijkheid.
  • Beveiligingsbeleid voor opslagplaatsen configureren:
    • In plaats van projectbreed beleid kunt u beveiligingsbeleid aanpassen aan elke opslagplaats of vertakking.
    • Aangepast beleid vermindert risico's, dwingt wijzigingsbeheerstandaarden af en verbetert de codekwaliteit.
  • Productiegeheimen isoleren in een afzonderlijke sleutelkluis:
    • Sla productiegeheimen afzonderlijk op in een Azure Key Vault.
    • Beperk de toegang tot een basis die nodig is om de scheiding van niet-productieversies te behouden.
  • Testomgevingen scheiden van productie:
    • Vermijd het mengen van testomgevingen met productie.
    • Zorg ervoor dat referenties en geheimen niet worden gebruikt in niet-productiecontexten.
  • Forking uitschakelen:
    • Door forking uit te schakelen, kunt u de beveiliging beheren.
    • Forks kunnen zich verspreiden, waardoor het lastig is om de beveiliging voor alle kopieën bij te houden.
  • Vermijd het verstrekken van geheimen aan fork-builds:
    • U kunt geen geheimen delen met gesplitste builds.
    • Geheimen moeten vertrouwelijk blijven en niet worden blootgesteld aan forks.
  • Overweeg het handmatig activeren van fork-builds:
    • Activeer builds handmatig voor forks in plaats van automatische triggers toe te staan.
    • Dit biedt betere controle over beveiligingscontroles.
  • Gebruik door Microsoft gehoste agents voor fork-builds:
    • Maak gebruik van door Microsoft gehoste agents voor geforkte builds.
    • Deze agents worden onderhouden en beveiligd.
  • Builddefinities voor productie scannen in Git-opslagplaatsen:
    • Controleer regelmatig de definities van productiebuilds die zijn opgeslagen in de Git-opslagplaats van uw project.
    • Scannen op referenties of gevoelige informatie.
  • Controle van vertakkingen configureren voor productiecontext:
    • Stel controle van vertakkingen in om het gebruik van gevoelige verbindingen (bijvoorbeeld prod-connection) te beperken tot pijplijnen die worden uitgevoerd in de context van de productievertakking.
    • Dit zorgt voor de juiste autorisatie en voorkomt onbedoeld misbruik.

Zie Andere beveiligingsoverwegingen voor meer informatie.

Azure-opslagplaatsen beveiligen

Azure-testplannen beveiligen

Beveiligde GitHub-integraties

  • OAuth-stroom gebruiken in plaats van PAT's:
    • Schakel verificatie op basis van PAT uit voor GitHub-serviceverbindingen.
    • Kies voor OAuth-stroom, die betere beveiliging en integratie biedt.
  • Vermijd identiteiten van beheerders of eigenaren:
    • Verifieer nooit GitHub-serviceverbindingen met behulp van een identiteit die een beheerder of eigenaar van opslagplaatsen is.
    • Beperk machtigingen tot het benodigde niveau.
  • Vermijd volledige GitHub-PAT's:
    • Vermijd het gebruik van een gitHub PAT in volledig bereik om serviceverbindingen te verifiëren.
    • Gebruik tokens met de minimaal vereiste machtigingen.
  • Vermijd persoonlijke GitHub-accounts als serviceverbindingen:
    • Gebruik geen persoonlijke GitHub-accounts als serviceverbindingen in Azure DevOps.
    • Maak in plaats daarvan toegewezen serviceaccounts of gebruik accounts op organisatieniveau.