Delen 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 Microsoft-accounts (MSA's): verwijder rechtstreeks inactieve gebruikers uit uw organisatie als u MSA's gebruikt. U kunt geen query's maken voor werkitems die zijn toegewezen aan verwijderde MSA-accounts.
  • Microsoft Entra-gebruikersaccounts uitschakelen of verwijderen: als er verbinding is met Microsoft Entra-id, schakelt u het Microsoft Entra-gebruikersaccount uit of verwijdert u dit terwijl het Azure DevOps-gebruikersaccount actief blijft. Met deze actie kunt u doorgaan met het opvragen van de geschiedenis van werkitems met behulp van uw Azure DevOps-gebruikers-id.
  • Gebruikers-PAW's intrekken: controleer en trek eventuele bestaande gebruikers-PAW's regelmatig in om veilig beheer van deze kritieke verificatietokens te garanderen.
  • Speciale machtigingen intrekken die aan individuele gebruikers zijn verleend: controleer en trek eventuele speciale machtigingen in die aan individuele gebruikers zijn verleend om te zorgen voor afstemming met het principe van minimale bevoegdheden.
  • Werk opnieuw toewijzen aan verwijderde gebruikers: voordat u gebruikers verwijdert, moet u hun werkitems opnieuw toewijzen aan huidige teamleden om de belasting effectief te distribueren.

Microsoft Entra-id gebruiken

  • Stel een geïntegreerd identiteitssysteem in: Verbind Azure DevOps met Microsoft Entra ID om één vlak voor identiteit te maken. Deze consistentie vermindert verwarring en minimaliseert beveiligingsrisico's van handmatige configuratiefouten.
  • Verfijnde governance implementeren: Gebruik Microsoft Entra ID om verschillende rollen en machtigingen toe te wijzen aan specifieke groepen binnen verschillende resourcebereiken. Deze actie zorgt voor gecontroleerde toegang en is afgestemd op aanbevolen beveiligingsprocedures.
  • Beveiligingsfuncties verbeteren: schakel andere beveiligingsfuncties in met Microsoft Entra-id, zoals:
    • Meervoudige verificatie (MFA): Vereisen meerdere factoren, zoals wachtwoord- en telefoonverificatie voor gebruikersverificatie. Beleid voor voorwaardelijke toegang: definieer toegangsregels op basis van voorwaarden zoals locatie, apparaat of risiconiveau.

Raadpleeg voor meer informatie de volgende artikelen:

Controle-gebeurtenissen controleren

Als uw organisatie is verbonden met Microsoft Entra, voert u de volgende taken uit om de beveiliging te verbeteren en gebruikspatronen te bewaken:

  • Controle inschakelen: gebeurtenissen bijhouden en weergeven met betrekking tot gebruikersacties, machtigingen en wijzigingen.
  • Controleer regelmatig controlegebeurtenissen: 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 instellen: beperk de toegang tot specifieke IP-adressen om alleen verkeer van vertrouwde bronnen toe te staan, waardoor de kwetsbaarheid voor aanvallen wordt verminderd.
  • Versleuteling gebruiken: versleutel gegevens altijd tijdens overdracht en at-rest. Beveilig communicatiekanalen met behulp van protocollen zoals HTTPS.
  • Certificaten valideren: zorg ervoor dat certificaten geldig zijn en worden uitgegeven door vertrouwde autoriteiten bij het tot stand brengen van verbindingen.
  • Web Application Firewalls (WAF's) implementeren: filteren, bewaken en blokkeren van schadelijk webverkeer met WAF's voor 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. Zie 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: verminder het risico dat gevoelige informatie wordt gelekt en onveilige code wordt geïmplementeerd door de toegang tot projecten en opslagplaatsen te beperken. Gebruik ingebouwde of aangepaste beveiligingsgroepen om machtigingen te beheren.
  • Schakel 'Openbare projecten toestaan' uit: schakel in de beleidsinstellingen van uw organisatie de optie uit om openbare projecten te maken. De zichtbaarheid van het project wijzigen van openbaar naar privé, indien nodig. Gebruikers die zich niet hebben aangemeld, hebben alleen-lezentoegang tot openbare projecten, terwijl aangemelde gebruikers toegang kunnen krijgen tot privéprojecten en toegestane wijzigingen kunnen aanbrengen.
  • Het maken van projecten beperken: voorkom dat gebruikers nieuwe projecten maken om de controle over uw omgeving te behouden.

Externe gasttoegang

  • Externe gasttoegang blokkeren: schakel het beleid 'Uitnodigingen mogen worden verzonden naar een domein' uit om externe gasttoegang te voorkomen als dit niet nodig is.
  • Afzonderlijke e-mailberichten of UPN's gebruiken: gebruik verschillende e-mailadressen of UPN's (User Principal Names) voor persoonlijke en zakelijke accounts om dubbelzinnigheid tussen persoonlijke en werkgerelateerde accounts te elimineren.
  • Externe gastgebruikers groeperen: plaats alle externe gastgebruikers in één Microsoft Entra-groep en beheer machtigingen voor deze groep op de juiste manier. Verwijder directe toewijzingen om ervoor te zorgen dat groepsregels van toepassing zijn op deze gebruikers.
  • Regels regelmatig opnieuw evalueren: controleer regelmatig regels 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 dynamisch groepslidmaatschap bijwerkt en 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. Zie Geldige gebruikersgroepen voor meer informatie.
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. Stel dat u twee beveiligingsgroepen hebt in uw Azure DevOps-project: ontwikkelaars en testers. De groep Ontwikkelaars heeft de machtiging om werkitems te bewerken die zijn ingesteld op Toestaan. Maar zorg ervoor dat bepaalde gevoelige werkitems niet worden bewerkt door iemand behalve een paar belangrijke personen. Hiervoor maakt u een nieuwe beveiligingsgroep met de naam Editors voor gevoelige items en stelt u de machtiging in om werkitems te bewerken op Weigeren voor deze groep. Als een gebruiker lid is van zowel de groep Ontwikkelaars als de groep Editors voor gevoelige items, heeft de machtiging Weigeren van de groep Editors voor gevoelige items voorrang op de machtiging Toestaan van de groep Ontwikkelaars . Als gevolg hiervan kan deze gebruiker de gevoelige werkitems niet bewerken, ook al hebben ze de machtiging Toestaan in de groep Ontwikkelaars . Dit gedrag zorgt ervoor dat machtigingen voor weigeren strikt worden afgedwongen, waardoor een hoger beveiligingsniveau en controle over gevoelige acties binnen uw Azure DevOps-omgeving worden geboden.
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.

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

  • Serviceaccounts voor één doel maken: elke service moet het 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 en 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.
  • Gebruik afzonderlijke identiteiten voor rapportlezers: als u domeinaccounts gebruikt voor serviceaccounts, gebruikt u een andere identiteit voor rapportlezers om machtigingen te isoleren en onnodige toegang te voorkomen.
  • Lokale accounts gebruiken voor werkgroepinstallaties: wanneer u onderdelen in een werkgroep installeert, gebruikt u lokale accounts voor gebruikersaccounts. Vermijd domeinaccounts in dit scenario.
  • Gebruik serviceverbindingen: gebruik waar mogelijk serviceverbindingen om veilig 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 om de activiteit van het serviceaccount te bewaken.

Zie Common Service Connection Types voor meer informatie.

Bereikserviceverbindingen

  • Bereikserviceverbindingen: beperk de toegang door het bereik van uw Azure Resource Manager-serviceverbindingen met specifieke resources en groepen te beperken. Vermijd het verlenen van brede inzenderrechten voor het hele Azure-abonnement.
  • Gebruik federatie van workloadidentiteit: verifiëren met Azure-resources met behulp van OpenID Connect (OIDC) zonder geheimen. Maak automatisch of handmatig een federatie van workloadidentiteit als u de rol Eigenaar voor uw Azure-abonnement hebt, geen verbinding maakt met Azure Stack- of Azure US Government-omgevingen en eventuele Marketplace-uitbreidingstaken die u hiervoor gebruikt.
  • Bereikresourcegroepen: zorg ervoor dat resourcegroepen alleen de virtuele machines (VM's) of resources bevatten die nodig zijn voor het buildproces.
  • Vermijd klassieke serviceverbindingen: kies voor moderne Azure Resource Manager-serviceverbindingen in plaats van klassieke, die geen bereikopties hebben.
  • Gebruik doelspecifieke teamserviceaccounts: serviceverbindingen verifiëren met 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:

  • Gebruik 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. Configureren voor toegang tot Azure-resources, waaronder Azure DevOps. Handig voor apps die specifieke toegang en beheer nodig hebben.
  • Beheerde identiteiten gebruiken: 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 voor naadloos beheer van aanmeldingsgegevens.

PAT's spaarzaam gebruiken

  • Bereik-PAW's voor specifieke rollen: wijs alleen de benodigde machtigingen voor specifieke taken toe. Vermijd het verlenen van globale toegang tot meerdere organisaties of opslagplaatsen om het risico op onbedoeld misbruik te minimaliseren.
  • Vermijd schrijf- of beheermachtigingen voor builds en releases: PAT'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. Behandel PAW's als essentieel als wachtwoorden, houd ze vertrouwelijk en vermijd openbaar delen of hardcoding in toepassingscode.
  • Vermijd het coderen van PAW's in toepassingscode: gebruik beveiligde configuratiebestanden of omgevingsvariabelen om PAT's dynamisch op te slaan en op te halen in plaats van PAW's rechtstreeks in uw code in te sluiten. Dynamisch.
  • Controleer en trek ongebruikte PAW's regelmatig 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.

Zie PAT's beheren met beleidsregels voor beheerders en PAT's gebruiken voor meer informatie.

Azure-artefacten beveiligen

Azure Boards beveiligen

Azure-pijplijnen beveiligen

Beleid

  • Externe revisoren vereisen: zorg ervoor dat ten minste één revisor buiten de oorspronkelijke aanvrager een grondig beoordelingsproces heeft uitgevoerd. De fiatteur deelt mede-eigendom van de wijzigingen en verantwoordelijkheid voor mogelijke effecten.
  • Vereisen dat CI-build wordt doorgegeven: Stel een basislijn voor codekwaliteit in door de CI-build (Continuous Integration) te vereisen die moet worden doorgegeven voordat een pull-aanvraag wordt samengevoegd. CI-controles omvatten codelining, eenheidstests en beveiligingsscans.
  • Zelfgoedkeuring weigeren: voorkom dat de oorspronkelijke pull-aanvrager zijn/haar eigen wijzigingen goedkeurt om een onbevoorhaald beoordelingsproces te garanderen en belangenconflicten te voorkomen.
  • Het voltooien van pull-aanvragen met 'wachten' of 'afwijzen' wordt geweigerd: voorkom dat pull-aanvragen worden voltooid, zelfs als sommige revisoren stemmen om te wachten of af te wijzen, waardoor alle feedback wordt aangepakt voordat ze worden samengevoegd.
  • Revisorstemmen opnieuw instellen op wijzigingen: revisorstemmen opnieuw instellen wanneer recente wijzigingen naar de pull-aanvraag worden gepusht om ervoor te zorgen dat revisoren de bijgewerkte code opnieuw evalueert.
  • Release-pijplijnen vergrendelen: Beperk releasepijplijnen tot specifieke vertakkingen (meestal productie of hoofd) om onbedoelde implementaties van andere vertakkingen te voorkomen.
  • Settable-variabelen afdwingen tijdens wachtrijtijd: schakel de optie Settable afdwingen tijdens wachtrijtijd in voor pijplijnvariabelen om te voorkomen dat gebruikers variabelewaarden 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 toe dat gebruikers onderdrukkingen behouden om consistentie te behouden en onbedoelde wijzigingen te voorkomen.

Agents

  • Verdeel machtigingen spaarzaam: beperk machtigingen tot de kleinste benodigde set accounts om de kwetsbaarheid voor aanvallen te verminderen.
  • Configureer beperkende firewalls voor agents: stel firewalls zo beperkend mogelijk in, terwijl agents nog steeds kunnen functioneren, beveiliging en bruikbaarheid kunnen verdelen.
  • Agentgroepen regelmatig bijwerken: houd uw agentpark up-to-date door agents regelmatig bij te werken om ervoor te zorgen dat kwetsbare code niet wordt uitgevoerd, waardoor het risico op exploitatie wordt verminderd.
  • Gebruik een afzonderlijke agentgroep voor productieartefacten: Productieartefacten isoleren met behulp van een afzonderlijke agentgroep, waardoor onbedoelde implementaties van niet-productievertakkingen worden 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.

Definities

  • GEBRUIK YAML voor pijplijndefinities: Definieer pijplijnen met behulp van YAML (nog een andere opmaaktaal) voor betere traceerbaarheid en naleving van goedkeuringsrichtlijnen en procedures voor versiebeheer.
  • Beperk de toegang tot pijplijndefinities: beperk de toegang tot het bewerken van pijplijndefinities tot de minimaal benodigde accounts om het risico op onbedoelde of niet-geautoriseerde wijzigingen te beperken.

Invoer

  • Neem controles op variabelen in buildscripts op: Implementeer controles in uw buildscripts om mogelijke aanvallen met opdrachtinjectie te beperken via settabelvariabelen. Valideer invoerwaarden en voorkom onbedoelde of schadelijke opdrachten.
  • Beperk de buildvariabelen 'settable at release time': minimaliseer het aantal buildvariabelen dat tijdens de release kan worden ingesteld om het kwetsbaarheid voor aanvallen te verminderen en het configuratiebeheer te vereenvoudigen.

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 om onbedoelde blootstelling en inbreuk op beveiliging te voorkomen.
  • Gebruik Azure Key Vault voor geheimen: gebruik Azure Key Vault in plaats van geheimen rechtstreeks op te slaan in pijplijnvariabelen om geheimen veilig te beheren en op te halen.
  • Actieve builds beperken op willekeurige vertakkingen of tags: voor beveiligingskritieke pijplijnen kunt u gebruikers beperken om builds uit te voeren op een 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 kunnen mogelijk niet nauwkeurig aan uw behoeften voldoen. Schakel overname uit en stel machtigingen expliciet in om te voldoen aan uw beveiligingsvereisten.
  • Bereik voor taakautorisatie 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 in om ervoor te zorgen dat elke pull-aanvraag beoordelingen ontvangt van ten minste twee goedkeurders, waardoor een grondige codebeoordeling en verantwoordelijkheid wordt bevorderd.
  • Configureer opslagplaatsspecifieke beveiligingsbeleidsregels: pas beveiligingsbeleid aan elke opslagplaats of vertakking aan in plaats van projectbreed beleid om risico's te verminderen, wijzigingsbeheerstandaarden af te dwingen en codekwaliteit te verbeteren.
  • Isoleer productiegeheimen in een afzonderlijke sleutelkluis: sla productiegeheimen afzonderlijk op in een Azure Key Vault en beperk de toegang tot een behoefte-naar-know-basis om de scheiding van niet-productie-builds te behouden.
  • Testomgevingen scheiden van productie: vermijd het combineren van testomgevingen met productie om ervoor te zorgen dat referenties en geheimen niet worden gebruikt in niet-productiecontexten.
  • Forking uitschakelen: het uitschakelen van forken helpt beveiliging te beheren door de verspreiding van forks te voorkomen, waardoor het eenvoudiger is om de beveiliging op alle kopieën bij te houden.
  • Vermijd het verstrekken van geheimen aan fork-builds: u kunt geen geheimen delen met geforkte builds om ze vertrouwelijk te houden en niet zichtbaar te maken voor forks.
  • Overweeg het handmatig activeren van fork-builds: builds handmatig activeren voor forks in plaats van automatische triggers toe te staan om betere controle over beveiligingscontroles te bieden.
  • Gebruik door Microsoft gehoste agents voor fork-builds: gebruik door Microsoft gehoste agents voor geforkte builds wanneer ze worden onderhouden en beveiligd.
  • Scan builddefinities in Git-opslagplaatsen: controleer regelmatig de definities van productiebuilds die zijn opgeslagen in de Git-opslagplaats van uw project voor referenties of gevoelige informatie.
  • Controle van vertakkingen configureren voor productiecontext: Stel vertakkingscontrolecontroles in om het gebruik van gevoelige verbindingen (bijvoorbeeld prod-connection) te beperken tot pijplijnen die worden uitgevoerd in de context van de productievertakking, waardoor de juiste autorisatie wordt gegarandeerd en onbedoeld misbruik wordt voorkomen.

Zie Andere beveiligingsoverwegingen voor meer informatie.

Azure-opslagplaatsen beveiligen

Azure-testplannen beveiligen

Beveiligde GitHub-integraties

  • Gebruik OAuth-stroom in plaats van PAT's: schakel verificatie op basis van PAT uit voor GitHub-serviceverbindingen en kies voor OAuth-stroom voor betere beveiliging en integratie.
  • 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 gitHub-PAT's met een volledig bereik: gebruik geen GitHub PAT voor 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.