Over beveiliging, verificatie en autorisatie

  • Artikel

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

Azure DevOps maakt gebruik van veel beveiligingsconcepten om ervoor te zorgen dat alleen gebruikers die toegang moeten hebben tot functies, functies en gegevens toegang hebben. Accounts krijgen toegang tot Azure DevOps via verificatie van hun beveiligingsreferenties en autorisatie van hun accountrechten voor toegang tot een functie of functie.

Dit artikel bouwt voort op de informatie in Aan de slag met machtigingen, toegang en beveiligingsgroepen. Beheer istrators profiteren van inzicht in de accounttypen, verificatiemethoden, autorisatiemethoden en beleidsregels die worden gebruikt om Azure DevOps te beveiligen.

Accounttypen

  • Gebruikers
  • Eigenaar van organisatie
  • Serviceaccounts
  • Service-principals of beheerde identiteiten
  • Taakagents

Verificatie

  • Gebruikersreferenties
  • Windows-verificatie
  • Tweeledige verificatie (2FA)
  • SSH-sleutelverificatie
  • Persoonlijke toegangstokens
  • Oauth-configuratie
  • Active Directory-verificatiebibliotheek

Autorisatie

  • Lidmaatschap van beveiligingsgroep
  • Op rollen gebaseerd toegangsbeheer
  • Toegangsniveaus
  • Functievlaggen
  • Beveiligingsnaamruimten en machtigingen

Beleidsregels

  • URL van privacybeleid
  • Toepassingsverbinding en beveiligingsbeleid
  • Gebruikersbeleid
  • Git-opslagplaats en vertakkingsbeleid

Accounttypen

  • Gebruikers
  • Serviceaccounts
  • Service-principals of beheerde identiteiten
  • Taakagents

Verificatie

  • Gebruikersreferenties
  • Windows-verificatie
  • Tweeledige verificatie (2FA)
  • SSH-sleutelverificatie
  • Persoonlijke toegangstokens
  • Oauth-configuratie
  • Active Directory-verificatiebibliotheek

Autorisatie

  • Lidmaatschap van beveiligingsgroep
  • Machtigingen op basis van rollen
  • Toegangsniveaus
  • Functievlaggen
  • Beveiligingsnaamruimten en machtigingen

Beleidsregels

  • Git-opslagplaats en vertakkingsbeleid

Belangrijk

Azure DevOps biedt geen ondersteuning meer voor verificatie met alternatieve referenties sinds begin 2 maart 2020. Als u nog steeds alternatieve referenties gebruikt, raden we u sterk aan over te schakelen naar een veiligere verificatiemethode (bijvoorbeeld persoonlijke toegangstokens). Meer informatie.

Zowel onze cloudservice, Azure DevOps Services als on-premises server, Azure DevOps Server, ondersteunen softwareontwikkelingsprojecten, van planning tot implementatie. Azure DevOps maakt gebruik van het Platform as a Service-infrastructuur van Microsoft Azure en veel van de Services van Azure, waaronder Azure SQL-databases, om een betrouwbare, wereldwijd beschikbare service te leveren voor uw ontwikkelprojecten.

Voor meer informatie over de stappen die Microsoft neemt om uw projecten in Azure DevOps Services veilig, beschikbaar, veilig en privé te houden, raadpleegt u dit witboek, overzicht van Azure DevOps Services Data Protection.

Accounts

Hoewel de belangrijkste typen accounts van belang zijn de menselijke gebruikersaccounts die u aan uw organisatie of project toevoegt, ondersteunt Azure DevOps andere typen accounts om verschillende bewerkingen uit te voeren. Dit zijn de volgende accounttypen.

  • Eigenaar van de organisatie: de maker van een Azure DevOps Services-organisatie of toegewezen eigenaar. Zie De eigenaar van de organisatie opzoeken als u wilt weten wie de eigenaar van de organisatie voor uw organisatie is.
  • Serviceaccounts: Interne Azure DevOps-accounts die worden gebruikt ter ondersteuning van een specifieke service, zoals Agent Pool Service, PipelinesSDK. Zie Beveiligingsgroepen, serviceaccounts en machtigingen voor beschrijvingen van serviceaccounts.
  • Service-principals of beheerde identiteiten: Microsoft Entra-toepassingen of beheerde identiteiten die zijn toegevoegd aan uw organisatie om acties uit te voeren namens een toepassing van derden. Sommige service-principals verwijzen naar interne Azure DevOps-accounts ter ondersteuning van interne bewerkingen.
  • Taakagents: interne accounts die worden gebruikt om specifieke taken volgens een normaal schema uit te voeren.
  • Accounts van derden: accounts die toegang nodig hebben tot de ondersteuning van webhook, serviceverbindingen of andere toepassingen van derden.

In deze documenten kunnen gebruikers verwijzen naar alle identiteiten die zijn toegevoegd aan de Users Hub, waaronder menselijke gebruikers en service-principals.

  • Serviceaccounts: Interne Azure DevOps-accounts die worden gebruikt ter ondersteuning van een specifieke service, zoals Agent Pool Service, PipelinesSDK. Zie Beveiligingsgroepen, serviceaccounts en machtigingen voor beschrijvingen van serviceaccounts.
  • Service-principals of beheerde identiteiten: Microsoft Entra-toepassingen of beheerde identiteiten die zijn toegevoegd aan uw organisatie om acties uit te voeren namens een toepassing van derden. Sommige service-principals verwijzen naar interne Azure DevOps-accounts ter ondersteuning van interne bewerkingen.
  • Taakagents: interne accounts die worden gebruikt om specifieke taken volgens een normaal schema uit te voeren.
  • Accounts van derden: accounts die toegang nodig hebben tot de ondersteuning van webhook, serviceverbindingen of andere toepassingen van derden.

De meest effectieve manier om accounts te beheren is door ze toe te voegen aan beveiligingsgroepen.

Notitie

De eigenaar van de organisatie en leden van de groep Projectverzameling Beheer istrators krijgen volledige toegang tot de meeste functies en functies.

Verificatie

Verificatie verifieert een accountidentiteit op basis van de referenties die zijn opgegeven wanneer ze zich aanmelden bij Azure DevOps. Deze systemen integreren met en vertrouwen op de beveiligingsfuncties van deze andere systemen:

  • Microsoft Entra ID
  • Microsoft-account (MSA)
  • Active Directory (AD)

Microsoft Entra ID en MSA ondersteunen cloudverificatie. We raden Microsoft Entra-id aan wanneer u een grote groep gebruikers moet beheren. Als u een klein gebruikersbestand hebt dat toegang heeft tot uw organisatie in Azure DevOps, kunt u Microsoft-accounts gebruiken. Zie Voor meer informatie over toegang tot Azure DevOps met Microsoft Entra ID.

Voor on-premises implementaties wordt AD aanbevolen bij het beheren van een grote groep gebruikers. Zie Groepen instellen voor gebruik in on-premises implementaties voor meer informatie.

Verificatiemethoden, integreren met andere services en apps

Andere toepassingen en services kunnen worden geïntegreerd met services en resources in Azure DevOps. Apps kunnen de volgende verificatiemethoden gebruiken om toegang te krijgen tot uw account zonder meerdere keren om gebruikersreferenties te vragen.

  • Persoonlijke toegangstokens om tokens namens uzelf te genereren voor:

    • Toegang tot specifieke resources of activiteiten, zoals builds of werkitems
    • Clients zoals Xcode en NuGet die gebruikersnamen en wachtwoorden als basisreferenties vereisen en geen ondersteuning bieden voor Microsoft-account- en Microsoft Entra-functies zoals meervoudige verificatie
    • Toegang tot Azure DevOps REST API's

  • Azure DevOps OAuth voor het genereren van tokens in naam van gebruikers voor toegang tot REST API's. De API's voor accounts en profielen ondersteunen alleen OAuth.

  • SSH-verificatie voor het genereren van versleutelingssleutels wanneer u Linux, macOS of Windows gebruikt met Git voor Windows en geen Git-referentiebeheertools of persoonlijke toegangstokens voor HTTPS-verificatie kunt gebruiken.

  • Service-principals of beheerde identiteiten voor het genereren van Microsoft Entra-tokens namens een toepassing of service, die doorgaans een bepaalde werkstroom automatiseert die toegang nodig heeft tot Azure DevOps-resources. De meeste acties die traditioneel door een serviceaccount en een PAT worden uitgevoerd, kunnen worden uitgevoerd met een service-principal of beheerde identiteit.

Standaard staat uw account of verzameling toegang toe voor alle verificatiemethoden. U kunt de toegang beperken, maar u moet dan de toegang voor elke methode specifiek beperken. Wanneer u de toegang tot een verificatiemethode weigert, kan geen enkele app deze methode gebruiken om toegang te krijgen tot uw account. Elke app die eerder toegang had, krijgt een verificatiefout en heeft geen toegang meer tot uw account.

Zie Referentieopslag voor Azure DevOps voor meer informatie over hoe we uw referenties opslaan.

Zie Richtlijnen voor verificatie voor meer informatie over het kiezen van het juiste verificatiemechanisme.

Autorisatie

Autorisatie controleert of de identiteit die verbinding probeert te maken over de benodigde machtigingen beschikt om toegang te krijgen tot een service, functie, functie, object of methode. Autorisatie vindt altijd plaats na geslaagde verificatie. Als een verbinding niet is geverifieerd, mislukt deze voordat autorisatiecontrole wordt uitgevoerd. Als de verificatie van een verbinding slaagt, is een specifieke actie mogelijk nog steeds niet toegestaan omdat de gebruiker of groep geen autorisatie heeft om die actie uit te voeren.

Autorisatie is afhankelijk van de machtigingen die aan het account zijn toegewezen. Machtigingen worden rechtstreeks verleend aan een account of via lidmaatschap van een beveiligingsgroep of beveiligingsrol. Toegangsniveaus en functievlagmen kunnen ook toegang tot een functie verlenen of beperken. Zie Aan de slag met machtigingen, toegang en beveiligingsgroepen voor meer informatie over deze autorisatiemethoden.

Beveiligingsnaamruimten en -machtigingen

Met beveiligingsnaamruimten worden gegevens opgeslagen die bepalen welk toegangsniveau Azure DevOps-accounts nodig hebben om een specifieke actie uit te voeren op een specifieke resource. Elke familie van resources, zoals werkitems of Git-opslagplaatsen, wordt beveiligd via een unieke naamruimte. Elke beveiligingsnaamruimte bevat nul of meer toegangsbeheerlijsten (ACL's). Elke ACL bevat een token, een overnamevlag en een set nul of meer toegangsbeheervermeldingen (ACL's). Elke ACE bevat een identiteitsdescriptor, een toegestane machtiging bitmasker en een geweigerde machtigingsbitmasker.

Zie Beveiligingsnaamruimten en machtigingsreferenties voor meer informatie.

Beveiligingsbeleid

Als u uw organisatie en code wilt beveiligen, kunt u veel beleidsregels instellen. U kunt met name het volgende beleid in- of uitschakelen:

Algemeen

Toepassingsverbinding en beveiligingsbeleid

Gebruik het Tenantbeleid van Microsoft Entra om het maken van nieuwe organisaties te beperken tot alleen gewenste gebruikers. Dit beleid is standaard uitgeschakeld en alleen geldig wanneer de organisatie is verbonden met Microsoft Entra-id. Controleer het maken van de organisatie beperken voor meer informatie.

Het volgende beleid bepaalt de toegang die u gebruikers en toepassingen aan uw organisaties wilt geven:

Gebruikersbeleid

  • Externe gasttoegang (alleen geldig wanneer de organisatie is verbonden met Microsoft Entra-id.): wanneer deze optie is ingeschakeld, kunnen uitnodigingen worden verzonden naar e-mailaccounts van gebruikers die geen lid zijn van de Microsoft Entra-id van de tenant via de pagina Gebruikers . Zie Externe gebruikers toevoegen aan uw organisatie voor meer informatie.
  • Sta team- en projectbeheerders toe om nieuwe gebruikers uit te nodigen: alleen geldig wanneer de organisatie is verbonden met Microsoft Entra-id. Wanneer deze functie is ingeschakeld, kunnen team- en projectbeheerders gebruikers toevoegen via de pagina Gebruikers . Zie Nieuwe gebruikersuitnodigingen van Project- en Team-Beheer istrators beperken voor meer informatie.
  • Toegang aanvragen: alleen geldig wanneer de organisatie is verbonden met Microsoft Entra-id. Wanneer deze optie is ingeschakeld, kunnen gebruikers toegang tot een resource aanvragen. Een aanvraag resulteert in een e-mailmelding aan de beheerders die vragen om beoordeling en toegang, indien nodig. Zie Externe gebruikers toevoegen aan uw organisatie voor meer informatie.
  • GitHub-gebruikers uitnodigen: alleen geldig wanneer de organisatie niet is verbonden met Microsoft Entra-id. Wanneer deze optie is ingeschakeld, kunnen beheerders gebruikers toevoegen op basis van hun GitHub-gebruikersaccounts op de pagina Gebruikers . Zie Veelgestelde vragen over verifiëren en uitnodigen voor GitHub-gebruikers voor meer informatie.

Groep Gebruikers met projectbereik

Standaard kunnen gebruikers die zijn toegevoegd aan een organisatie, alle organisatie- en projectgegevens en -instellingen bekijken. Dit omvat het weergeven van een lijst met gebruikers, een lijst met projecten, factureringsgegevens, gebruiksgegevens en meer die toegankelijk zijn via organisatie-Instellingen.

Belangrijk

  • De beperkte zichtbaarheidsfuncties die in deze sectie worden beschreven, zijn alleen van toepassing op interacties via de webportal. Met de REST API's of azure devops CLI-opdrachten hebben projectleden toegang tot de beperkte gegevens.
  • Gastgebruikers die lid zijn van de beperkte groep met standaardtoegang in Microsoft Entra ID, kunnen niet zoeken naar gebruikers met de personenkiezer. Wanneer de preview-functie is uitgeschakeld voor de organisatie of wanneer gastgebruikers geen lid zijn van de beperkte groep, kunnen gastgebruikers naar verwachting alle Microsoft Entra-gebruikers doorzoeken.

Als u bepaalde gebruikers, zoals Belanghebbenden, Microsoft Entra-gastgebruikers of leden van een bepaalde beveiligingsgroep, wilt beperken, kunt u de functie Zichtbaarheid en samenwerking van gebruikers beperken tot specifieke preview-functies voor projecten voor de organisatie. Zodra deze optie is ingeschakeld, worden gebruikers of groepen die zijn toegevoegd aan de groep Gebruikers met projectbereik, op de volgende manieren beperkt:

  • Kan alleen de pagina's Overzicht en Projecten van organisatie openen Instellingen.
  • Kan alleen verbinding maken en deze projecten weergeven waaraan ze expliciet zijn toegevoegd (zie Gebruikers toevoegen aan een project of team.
  • Kan alleen gebruikers- en groepsidentiteiten selecteren die expliciet zijn toegevoegd aan het project waarmee ze zijn verbonden.

Zie Uw organisatie beheren, de zichtbaarheid van gebruikers beperken voor projecten en meer en preview-functies beheren voor meer informatie.

Waarschuwing

Wanneer de preview-functie van gebruikers beperken tot specifieke projecten is ingeschakeld voor de organisatie, kunnen gebruikers met projectbereik niet zoeken naar gebruikers die via microsoft Entra-groepslidmaatschap aan de organisatie zijn toegevoegd, in plaats van via een expliciete gebruikersuitnodiging. Dit is een onverwacht gedrag en er wordt aan een oplossing gewerkt. Als u dit probleem zelf wilt oplossen, schakelt u de functie Zichtbaarheid en samenwerking van gebruikers beperken tot specifieke preview-functies voor projecten voor de organisatie uit.

Git-opslagplaats en vertakkingsbeleid

Als u uw code wilt beveiligen, kunt u veel Git-opslagplaats- en vertakkingsbeleid instellen. Zie de volgende artikelen voor meer informatie.

Beveiliging van Azure-opslagplaatsen en Azure Pipelines

Omdat opslagplaatsen en build- en release-pijplijnen unieke beveiligingsuitdagingen vormen, worden andere functies buiten de functies die in dit artikel worden besproken, gebruikt. Zie de volgende artikelen voor meer informatie.

Volgende stappen

Naslaginformatie over machtigingen en groepen