Delen via

Over beveiliging, verificatie en autorisatie

  • Artikel

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

Azure DevOps maakt gebruik van verschillende beveiligingsconcepten om ervoor te zorgen dat alleen geautoriseerde gebruikers toegang hebben tot functies, functies en gegevens. Gebruikers krijgen toegang tot Azure DevOps via de verificatie van hun beveiligingsreferenties en de autorisatie van hun accountrechten voor toegang tot specifieke functies of functies.

Dit artikel bouwt voort op de informatie in Aan de slag met machtigingen, toegang en beveiligingsgroepen. Beheerders kunnen 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 voor verificatie van alternatieve referenties. Als u nog steeds alternatieve referenties gebruikt, raden we u sterk aan over te schakelen naar een veiligere verificatiemethode.

Zowel Azure DevOps Services (cloud) als Azure DevOps Server (on-premises) ondersteunen softwareontwikkeling van planning tot implementatie. Ze maken gebruik van het Platform as a Service-infrastructuur en -services van Microsoft Azure, waaronder Azure SQL-databases, om een betrouwbare, wereldwijd beschikbare service voor uw projecten te bieden.

Zie het overzicht van azure DevOps Services-gegevensbescherming voor meer informatie over hoe Microsoft ervoor zorgt dat uw Azure DevOps Services-projecten veilig, beschikbaar, veilig en privé zijn.

Accounts

Hoewel menselijke gebruikersaccounts de primaire focus hebben, ondersteunt Azure DevOps ook verschillende andere accounttypen voor verschillende bewerkingen. 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 om de eigenaar van de organisatie te vinden.
  • Serviceaccounts: Interne Azure DevOps-organisatie die wordt 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 aan uw organisatie zijn toegevoegd om acties uit te voeren namens een toepassing van derden. Sommige service-principals verwijzen naar een interne Azure DevOps-organisatie 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 onze beveiligingsgerelateerde artikelen verwijst 'gebruikers' naar alle identiteiten die zijn toegevoegd aan de Users Hub, waaronder menselijke gebruikers en service-principals.

  • Serviceaccounts: Interne Azure DevOps-organisatie die wordt 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 aan uw organisatie zijn toegevoegd om acties uit te voeren namens een toepassing van derden. Sommige service-principals verwijzen naar een interne Azure DevOps-organisatie 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 Beheerders van projectverzamelingen krijgen volledige toegang tot bijna alle functies en functies.

Verificatie

Verificatie verifieert de identiteit van een account op basis van de referenties die zijn opgegeven tijdens het aanmelden bij Azure DevOps. Deze systemen integreren met en vertrouwen op de beveiligingsfuncties van de volgende andere systemen:

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

Microsoft Entra ID en MSA ondersteunen cloudverificatie. U wordt aangeraden Microsoft Entra ID te gebruiken voor het beheren van een grote groep gebruikers. Voor een kleine gebruikersbasis die toegang heeft tot uw Azure DevOps-organisatie, zijn Microsoft-accounts voldoende. Zie Voor meer informatie over toegang tot Azure DevOps met Microsoft Entra ID.

Voor on-premises implementaties wordt AD aanbevolen voor 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 Azure DevOps. Voor toegang tot uw account zonder herhaaldelijk om gebruikersreferenties te vragen, kunnen apps de volgende verificatiemethoden gebruiken:

  • Persoonlijke toegangstokens (PAT's) om namens u tokens 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 namens gebruikers voor toegang tot REST API's. De API's voor accounts en profielen ondersteunen alleen OAuth.

  • SSH-verificatie voor het genereren van versleutelingssleutels voor uzelf wanneer u Linux, macOS of Windows gebruikt waarop Git voor Windows wordt uitgevoerd, en kan geen Git-referentiebeheerders of PAT's gebruiken voor HTTPS-verificatie.

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

Standaard staat uw account of verzameling toegang toe voor alle verificatiemethoden. U kunt de toegang beperken door specifiek elke methode te 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, ontvangt een verificatiefout en heeft geen toegang tot uw account.

Raadpleeg voor meer informatie de volgende artikelen:

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 autorisatiecontroles worden uitgevoerd. Zelfs als de verificatie slaagt, is een specifieke actie mogelijk nog steeds niet toegestaan als de gebruiker of groep geen autorisatie heeft.

Autorisatie is afhankelijk van de machtigingen die zijn toegewezen aan de gebruiker, rechtstreeks of via lidmaatschap van een beveiligingsgroep of beveiligingsrol. Toegangsniveaus en functievlagmen kunnen ook de toegang tot specifieke functies beheren. Zie Aan de slag met machtigingen, toegang en beveiligingsgroepen voor meer informatie over deze autorisatiemethoden.

Beveiligingsnaamruimten en -machtigingen

Beveiligingsnaamruimten bepalen gebruikerstoegangsniveaus voor specifieke acties op resources.

  • Elke resourcefamilie, zoals werkitems of Git-opslagplaatsen, heeft een unieke naamruimte.
  • Elke naamruimte bevat nul of meer toegangsbeheerlijsten (ACL's).
    • Elke ACL bevat een token, een overnamevlag en toegangsbeheervermeldingen (ACL's).
    • Elke ACE heeft een identiteitsdescriptor, een toegestane machtigingen-bitmasker en een geweigerde machtigings-bitmasker.

Zie Beveiligingsnaamruimten en machtigingsreferenties voor meer informatie.

Beveiligingsbeleid

Als u uw organisatie en code wilt beveiligen, kunt u verschillende 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. Zie Het maken van organisaties beperken voor meer informatie.

Het volgende beleid bepaalt de toegang die wordt verleend aan gebruikers en toepassingen binnen uw organisaties:

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 Teambeheerders 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 Verbinding maken met GitHub/veelgestelde vragen voor meer informatie.

Groep Gebruikers met projectbereik

Standaard kunnen gebruikers die aan een organisatie zijn toegevoegd, alle organisatie- en projectgegevens en -instellingen bekijken, waaronder gebruikerslijsten, projectlijsten, factureringsgegevens, gebruiksgegevens en meer.

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 specifieke beveiligingsgroep, wilt beperken, kunt u de functie Zichtbaarheid en samenwerking van gebruikers beperken tot specifieke preview-functies voor projecten voor de organisatie. Zodra dit 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-instellingen openen.
  • Kan alleen verbinding maken en deze projecten weergeven waaraan ze expliciet zijn toegevoegd.
  • Kan alleen gebruikers- en groepsidentiteiten selecteren die expliciet zijn toegevoegd aan het project waaraan ze zijn gekoppeld.

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

U kunt verschillende Git-opslagplaats- en vertakkingsbeleid instellen om uw code te beveiligen. 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 extra 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