Aanbevolen procedures voor beveiliging

  • Artikel

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

Wanneer u met informatie en gegevens werkt, met name in een cloudoplossing zoals Azure DevOps Services, moet het prioriteren van beveiliging altijd uw belangrijkste probleem zijn. Hoewel Microsoft de beveiliging van de onderliggende cloudinfrastructuur onderhoudt, is het uw verantwoordelijkheid om beveiliging in Azure DevOps te configureren.

Hoewel dit niet verplicht is, kan het opnemen van best practices tijdens het gebruik van Azure DevOps uw ervaring verbeteren en deze veiliger maken. We hebben de volgende aanbevolen procedures gecompileerd die erop gericht zijn om uw Azure DevOps-omgeving veilig te houden:

Azure DevOps-omgeving beveiligen

Gebruikers verwijderen

  • Als uw organisatie MSA-accounts gebruikt, verwijdert u inactieve gebruikers rechtstreeks uit de organisatie, omdat u geen andere manier hebt om toegang te voorkomen. Wanneer u dit doet, kunt u geen query maken voor werkitems die zijn toegewezen aan het verwijderde gebruikersaccount. Zie Gebruikers verwijderen uit Azure DevOps voor meer informatie.
  • Als uw organisatie is verbonden met Microsoft Entra-id, kunt u het Microsoft Entra-gebruikersaccount uitschakelen of verwijderen en uw Azure DevOps-gebruikersaccount actief laten. Op deze manier kunt u de geschiedenis van werkitems blijven opvragen met behulp van uw Azure DevOps-gebruikers-id.
  • Gebruikers-PAT's intrekken.
  • Eventuele speciale machtigingen intrekken die zijn verleend aan afzonderlijke gebruikersaccounts.
  • Wijs werk opnieuw toe aan gebruikers die u verwijdert aan huidige teamleden.

Microsoft Entra-id gebruiken

Integreer Azure DevOps met Microsoft Entra ID om één vlak voor identiteit te hebben. Consistentie en één gezaghebbende bron vergroot de duidelijkheid en vermindert beveiligingsrisico's van menselijke fouten en configuratiecomplexiteit. De sleutel tot eindbeheer is om meerdere roltoewijzingen te hebben (met verschillende roldefinities en verschillende resourcebereiken voor dezelfde Microsoft Entra-groepen). Zonder Microsoft Entra-id bent u alleen verantwoordelijk voor het beheren van de toegang van de organisatie.

Als u Microsoft Entra ID gebruikt, hebt u ook toegang tot andere beveiligingsfuncties, zoals meervoudige verificatie of ander beleid voor voorwaardelijke toegang.

Raadpleeg voor meer informatie de volgende artikelen:

Controle-gebeurtenissen controleren

Zodra u een door Microsoft Entra ondersteunde organisatie hebt, kunt u Controle inschakelen in uw beveiligingsbeleid. Controleer regelmatig controlegebeurtenissen om onverwachte gebruikspatronen door beheerders en andere gebruikers te controleren en erop te reageren.

Uw netwerk beveiligen

Een aantal manieren om dit te doen, zijn onder andere:

  • Stel een acceptatielijst in om specifieke IP-adressen te beperken.
  • Gebruik altijd versleuteling.
  • Certificaten valideren.
  • Implementeer WAF's (Web Application Firewalls), zodat ze schadelijk webverkeer naar en van Azure DevOps kunnen filteren, bewaken en blokkeren.
  • Zie deze richtlijnen voor aanbevolen procedures voor toepassingsbeheer voor meer informatie

Bereikmachtigingen

Het systeem beheert machtigingen op verschillende niveaus , afzonderlijke, verzameling, project en object - en wijst deze standaard toe aan een of meer ingebouwde groepen.

Machtigingen op projectniveau

  • Beperk de toegang tot projecten en opslagplaatsen om het risico te verminderen dat gevoelige informatie wordt gelekt en onveilige code wordt geïmplementeerd in productie.
  • Gebruik de ingebouwde beveiligingsgroepen of aangepaste beveiligingsgroepen om machtigingen te beheren. Zie Machtigingen verlenen of beperken voor het selecteren van taken voor meer informatie.
  • Schakel 'Openbare projecten toestaan' uit in de beleidsinstellingen van uw organisatie om te voorkomen dat elke organisatiegebruiker een openbaar project maakt. Met Azure DevOps Services kunt u de zichtbaarheid van uw projecten wijzigen van openbaar naar privé en omgekeerd. Als gebruikers zich niet hebben aangemeld bij uw organisatie, hebben ze alleen-lezentoegang tot uw openbare projecten. Als gebruikers zich hebben aangemeld, kunnen ze toegang krijgen tot privéprojecten en eventuele toegestane wijzigingen aanbrengen.
  • Sta gebruikers niet toe om nieuwe projecten te maken.

Externe gasttoegang

  • Blokkeer externe gasttoegang volledig door het beleid 'Uitnodigingen toestaan om naar een domein te worden verzonden' uit te schakelen. Het is een goed idee om dit te doen als er geen zakelijke behoefte aan is.
  • Gebruik een andere e-mail of user principal name (UPN) voor uw persoonlijke en zakelijke accounts, ook al is dit toegestaan. Deze actie elimineert de uitdaging om onderscheid te maken tussen uw zakelijke en persoonlijke accounts wanneer de e-mail/UPN hetzelfde is.
  • Plaats alle externe gastgebruikers in één Microsoft Entra-groep en beheer de machtigingen van die groep op de juiste manier. U kunt op deze manier eenvoudig beheren en controleren.
    • Verwijder directe toewijzingen zodat de groepsregels van toepassing zijn op die gebruikers. Zie Een groepsregel toevoegen om toegangsniveaus toe te wijzen voor meer informatie.
    • Evalueer regels regelmatig opnieuw op het tabblad Groepsregels van de pagina Gebruikers. Geef aan of wijzigingen in het groepslidmaatschap in Microsoft Entra ID van invloed kunnen zijn op uw organisatie. Het kan tot 24 uur duren voordat microsoft Entra ID het dynamische groepslidmaatschap bijwerkt. Elke 24 uur en wanneer een groepsregel verandert, worden regels automatisch opnieuw geëvalueerd in het systeem.
  • Zie B2B-gasten in de Microsoft Entra-id voor meer informatie.

Beveiligingsgroepen beheren

Beveiligings- en gebruikersgroepen

Zie de volgende 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 team-Beheer istrators maken waarin u een subset van de machtigingen toewijst die beschikbaar zijn voor Project Beheer istrators. 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. Beheer worden toegewezen aan de beveiligingsgroep van Project Beheer istrator voor verhoogde machtigingen, zodat ze beveiligingsmachtigingen kunnen configureren.

Zie Geldige gebruikersgroepen voor meer informatie.

Just-In-Time-toegang voor beheerdersgroepen

U kunt de configuratie van uw organisatie of project wijzigen als u Beheer istrator- en Project Beheer istrator-toegang hebt. Als u de toegang tot deze ingebouwde beheerdersgroepen wilt beveiligen, hebt u Just-In-Time-toegang nodig met behulp van een Microsoft Entra Privileged Identity Management-groep (PIM).

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

Zorg ervoor dat elke gebruiker met verhoogde toegang met een PIM-groep ook standaardtoegang heeft tot de organisatie, zodat deze de pagina kan bekijken om de machtigingen te 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

  • Zorg ervoor dat serviceaccounts geen interactieve aanmeldingsrechten hebben.
  • Beperk de bevoegdheden van het serviceaccount tot het minimum dat minimaal nodig is.
  • Gebruik een andere identiteit voor het rapportlezeraccount als u domeinaccounts gebruikt voor uw serviceaccounts. Zie Serviceaccounts en afhankelijkheden voor meer informatie.
  • Gebruik lokale accounts voor gebruikersaccounts als u een onderdeel in een werkgroep installeert. Zie Vereisten voor serviceaccounts voor meer informatie.
  • Gebruik waar mogelijk serviceverbindingen . Serviceverbindingen bieden een beveiligd mechanisme om verbinding te maken met verschillende services zonder dat geheime variabelen rechtstreeks aan de build moeten worden doorgegeven. - Beperk deze verbindingen naar de specifieke plaats waar ze moeten worden gebruikt en niets meer.
  • Controleer de activiteit van het serviceaccount en maak controlestreaming. Met controle kunt u verdachte aanmeldingen en activiteiten detecteren en erop reageren.
  • Zie Common Service Connection Types voor meer informatie.

Bereikserviceverbindingen

  • Bereik van Azure Resource Manager en andere serviceverbindingen, alleen voor de resources en groepen waartoe ze toegang nodig hebben. Serviceverbindingen mogen geen brede inzenderrechten hebben voor het hele Azure-abonnement.
  • Gebruik workloadidentiteitsfederatie voor uw ARM-serviceverbindingen (Azure Resource Manager). Met federatie van workloadidentiteit kunt u serviceverbindingen zonder geheim maken in Azure Pipelines naar Azure.
  • Geef gebruikers geen algemene of brede inzenderrechten voor het Azure-abonnement.
  • Gebruik geen klassieke Azure-serviceverbindingen, omdat er geen manier is om de machtigingen te bepalen.
  • Zorg ervoor dat de resourcegroep alleen virtuele machines (VM's) of resources bevat waartoe de build toegang nodig heeft.
  • Gebruik een specifiek teamserviceaccount om een serviceverbinding te verifiëren.
  • Zie Common Service Connection Types voor meer informatie.

De juiste verificatiemethode kiezen

Selecteer uw verificatiemethoden uit de volgende bronnen:

Service-principals overwegen

Verken alternatieven zoals service-principals en beheerde identiteiten waarmee u Microsoft Entra-tokens kunt gebruiken voor toegang tot Azure DevOps-resources. Dergelijke tokens dragen minder risico wanneer ze worden gelekt in vergelijking met PAW's en bevatten voordelen zoals eenvoudig referentiebeheer.

PAT's spaarzaam gebruiken

Indien mogelijk is het raadzaam om identiteitsservices altijd te gebruiken voor verificatie in plaats van cryptografische sleutels, omdat het veilig beheren van sleutels met toepassingscode lastig is en kan leiden tot fouten, zoals het per ongeluk publiceren van gevoelige toegangssleutels naar openbare codeopslagplaatsen zoals GitHub. Als u echter persoonlijke toegangstokens (PAW's) moet gebruiken, moet u rekening houden met de volgende richtlijnen:

  • PAW's moeten altijd worden afgestemd op specifieke rollen.

  • PAW's mogen geen globale toegang bieden tot meerdere organisaties.

  • PAW's mogen geen schrijf- of beheermachtigingen verlenen voor builds of releases.

  • PAW's moeten een vervaldatum hebben en geheim blijven omdat ze net zo kritiek zijn als wachtwoorden.

  • PAW's mogen nooit in de toepassingscode worden vastgelegd, zelfs als dit verleidelijk is om de code te vereenvoudigen.

  • Beheer istrators moeten regelmatig alle PAW's controleren met behulp van de REST API's en intrekken die niet voldoen aan de bovenstaande criteria.

  • Houd uw PAT's geheim. Uw tokens zijn net zo kritiek als wachtwoorden.

  • Sla uw tokens op een veilige plaats op.

  • Gebruik geen codetokens in toepassingen. Het kan verleidelijk zijn om code te vereenvoudigen om een token gedurende een lange periode te verkrijgen en op te slaan in uw toepassing, maar doe dat niet.

  • Geef tokens een vervaldatum.

  • Raadpleeg de volgende artikelen voor meer informatie:

Azure-artefacten beveiligen

Azure Boards beveiligen

Azure-pijplijnen beveiligen

Beleidsregels

  • Minimaal één revisor buiten de oorspronkelijke aanvrager vereisen. De goedkeurder deelt mede-eigenaarschap van de wijzigingen en moet evengoed verantwoordelijk worden gehouden voor mogelijke gevolgen.
  • Ci-build moet worden doorgegeven. Deze vereiste is handig voor het vaststellen van de kwaliteit van basislijncode, door middel van codeplining, eenheidstests en beveiligingscontroles, zoals virus- en referentiescans.
  • Zorg ervoor dat de oorspronkelijke pull-aanvrager de wijziging niet kan goedkeuren.
  • Laat de voltooiing van een pull-aanvraag (pull-aanvraag) niet toe, zelfs als sommige revisoren stemmen om te wachten of af te wijzen.
  • Stel de stemmen van de revisor van de code opnieuw in wanneer recente wijzigingen worden gepusht.
  • Vergrendeling release-pijplijnen door ze alleen uit te voeren op specifieke productiebranches.
  • Schakel 'Settable afdwingen bij wachtrijtijd voor variabelen' in in de pijplijninstellingen van uw organisatie.
  • Laat gebruikers deze waarde niet negeren bij het uitvoeren van deze pijplijn, voor variabelen die zijn ingesteld in de editor.

Agents

  • Verdeel machtigingen aan het kleinste mogelijke aantal accounts.
  • Zorg ervoor dat de meest beperkende firewall uw agents bruikbaar laat.
  • Werk pools regelmatig bij om ervoor te zorgen dat de build-vloot geen kwetsbare code uitvoert die een kwaadwillende actor kan misbruiken.
  • Gebruik een afzonderlijke agentgroep voor buildartefacten die naar productie worden verzonden of geïmplementeerd.
  • Segmenteer een 'gevoelige' pool van niet-gevoelige pools en sta alleen het gebruik van referenties toe in builddefinities die zijn vergrendeld voor die pool.

Definities

  • Pijplijndefinities beheren met YAML (nog een andere opmaaktaal). YAML is de voorkeursmethode voor het beheren van pijplijndefinities, omdat het traceerbaarheid biedt voor wijzigingen en kan voldoen aan de goedkeuringsrichtlijnen.
  • Beveilig de pijplijndefinitie Toegang tot het minimale aantal accounts bewerken .

Invoer

  • Neem sanitycontroles op voor variabelen in buildscripts. Een sanity-controle kan een aanval op opdrachtinjectie beperken via de ingestelde variabelen.
  • Stel zo weinig mogelijk buildvariabelen in op 'Settable at release time'.

Opdrachten

  • Vermijd extern opgehaalde resources, maar gebruik indien nodig versiebeheer en hashcontrole.
  • Leg geen geheimen vast.
  • Sla geen geheimen op in pijplijnvariabelen, gebruik Azure Key Vault. Scan regelmatig uw build-pijplijnen om ervoor te zorgen dat geheimen niet worden opgeslagen in build-pijplijnvariabelen.
  • Laat gebruikers geen builds uitvoeren op willekeurige vertakkingen of tags op beveiligingskritieke pijplijnen.
  • Schakel overname van de pijplijn uit, omdat overgenomen machtigingen breed zijn en niet nauwkeurig overeenkomen met uw behoeften voor machtigingen.
  • Beperk taakautorisatiebereiken in alle gevallen.

Opslagplaatsen en vertakkingen

  • Stel het beleid 'Een minimum aantal revisoren vereisen' in op ingeschakeld, zodat elke pull-aanvraag wordt beoordeeld door ten minste twee goedkeurders.
  • Configureer beveiligingsbeleid dat specifiek is voor elke opslagplaats of vertakking, in plaats van projectbreed. Beveiligingsbeleid vermindert risico's, dwingt wijzigingsbeheerstandaarden af en verbetert de kwaliteit van de code van uw team.
  • Sla productiegeheimen op in een afzonderlijke Key Vault en zorg ervoor dat alleen toegang wordt verleend op basis van noodzaak om niet-productieversies gescheiden te houden.
  • Meng testomgevingen niet met productie, inclusief het gebruik van referenties.
  • Schakel forking uit. Hoe meer vorken er zijn, hoe moeilijker het is om de beveiliging van elke fork bij te houden. Een gebruiker kan ook eenvoudig een kopie van een opslagplaats splitsen naar een eigen privéaccount.
  • Geef geen geheimen op voor fork-builds.
  • Overweeg om fork-builds handmatig te activeren.
  • Gebruik door Microsoft gehoste agents voor fork-builds.
  • Voor Git controleert u de builddefinities van uw productie in de Git-opslagplaats van het project, zodat ze kunnen worden gescand op referenties.
  • Configureer een controle van een vertakkingsbeheer zodat alleen pijplijnen die in de context van de production vertakking worden uitgevoerd, gebruikmaken van de prod-connection.
  • Zie Andere beveiligingsoverwegingen voor meer informatie.

Azure-opslagplaatsen beveiligen

Azure-testplannen beveiligen

Beveiligde GitHub-integraties

  • Schakel verificatie op basis van persoonlijk toegangstoken (PAT) uit, zodat de OAuth-stroom wordt gebruikt met de GitHub-serviceverbinding.
  • Verifieer gitHub-serviceverbindingen nooit als een identiteit die een beheerder of eigenaar van opslagplaatsen is.
  • Gebruik nooit een gitHub PAT (persoonlijk toegangstoken) voor het volledige bereik om GitHub-serviceverbindingen te verifiëren.
  • Gebruik geen persoonlijk GitHub-account als een serviceverbinding met Azure DevOps.