Verificatie-, autorisatie- en beveiligingsbeleid

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

Azure DevOps maakt gebruik van een combinatie van beveiligingsconcepten om ervoor te zorgen dat alleen geautoriseerde gebruikers toegang hebben tot de functies, functies en gegevens. Toegang wordt bepaald door twee belangrijke processen: verificatie, waarmee de referenties van een gebruiker worden geverifieerd en autorisatie, die machtigingen verleent op basis van accountrechten. Samen bepalen deze processen wat elke gebruiker kan doen in Azure DevOps.

Dit artikel gaat verder met machtigingen, toegang en beveiligingsgroepen en helpt beheerders inzicht te krijgen in de verschillende accounttypen, verificatie- en autorisatiemethoden en beveiligingsbeleid dat beschikbaar is om Azure DevOps-omgevingen te beveiligen.

---

Accounttypen

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

Verificatie

• Gebruikersreferenties
• Windows-verificatie
• Tweeledige verificatie (2FA)
• SSH-sleutelverificatie
• Microfost Entra-token
• Persoonlijk toegangstoken
• 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

---

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.

Beide Azure DevOps ondersteunt softwareontwikkeling van planning tot implementatie. Elk platform maakt gebruik van het Platform as a Service-infrastructuur en -services van Microsoft Azure, inclusief Azure SQL-databases, om een betrouwbare, wereldwijd beschikbare service voor uw projecten te bieden.

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

Rekeningen

Hoewel menselijke gebruikersaccounts de primaire focus vormen, ondersteunt Azure DevOps ook verschillende andere accounttypen voor verschillende bewerkingen:

• 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 zijn toegevoegd aan uw organisatie om acties uit te voeren namens een niet-Microsoft-toepassing. 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 om webhook, serviceverbindingen of andere niet-Microsoft-toepassingen te ondersteunen.

In onze beveiligingsgerelateerde artikelen verwijst 'gebruikers' naar alle identiteiten die zijn toegevoegd aan de Users Hub, waaronder menselijke gebruikers en service-principals.

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

Authenticatie verifieert de identiteit van een gebruiker op basis van de inloggegevens die zijn aangeboden tijdens het inloggen bij Azure DevOps. Azure DevOps kan worden geïntegreerd met verschillende identiteitssystemen voor het beheren van verificatie:

• Microsoft Entra-id: aanbevolen voor organisaties die een grote groep gebruikers beheren. Biedt robuuste, cloudgebaseerde verificatie en gebruikersbeheer.
• Microsoft-account (MSA): geschikt voor kleinere gebruikersbasissen die toegang hebben tot Azure DevOps-organisaties. Ondersteunt cloudverificatie.
• Active Directory (AD):wordt aanbevolen voor on-premises implementaties met veel gebruikers, met behulp van uw bestaande AD-infrastructuur.

Microsoft Entra ID en Microsoft-accounts ondersteunen beide cloudverificatie. Zie Voor meer informatie over toegang tot Azure DevOps met Microsoft Entra ID.

Gebruik Active Directory voor on-premises omgevingen om gebruikerstoegang efficiënt te beheren. Meer informatie over het instellen van groepen voor gebruik in on-premises implementaties.

Programmatisch verifiëren

Open uw Azure DevOps-organisatie programmatisch zonder herhaaldelijk uw gebruikersnaam en wachtwoord in te voeren door een van de beschikbare verificatiemethoden te kiezen. Gebruik de volgende methoden om werkstromen te automatiseren, te integreren met REST API's of aangepaste toepassingen te bouwen:

• Gebruik OAuth om toepassingen te bouwen die acties uitvoeren namens gebruikers. Gebruikers moeten toestemming geven voor de app. Gebruik Microsoft Entra OAuth voor nieuwe apps.
• Gebruik service-principals of beheerde identiteiten om werkstromen te automatiseren of hulpprogramma's te bouwen die regelmatig toegang hebben tot organisatiebronnen. Geef Microsoft Entra-tokens uit namens de toepassing zelf.
• Gebruik Microsoft Entra ID voor veilige, cloudgebaseerde verificatie en gebruikersbeheer.
• Gebruik persoonlijke toegangstokens (PAT's) voor ad-hocaanvragen of vroege prototypen. Vermijd PAT's voor langetermijnontwikkeling van apps, omdat ze gevoeliger zijn voor lekken en misbruik.

Aanbeveling

Sla referenties altijd veilig op en volg de aanbevolen procedures voor het beheren van verificatiemethoden.

Standaard staat uw organisatie toegang toe voor alle verificatiemethoden. Organisatiebeheerders kunnen de toegang tot deze verificatiemethoden beperken door beveiligingsbeleid uit te schakelen. Tenantbeheerders kunnen pat-risico's verder verminderen door de manieren te beperken waarop ze kunnen worden gemaakt.

Autorisatie

Autorisatie bepaalt of een geverifieerde identiteit de vereiste machtigingen heeft voor toegang tot een specifieke service, functie, functie, object of methode in Azure DevOps. Autorisatiecontroles vinden altijd plaats na geslaagde verificatie. Als verificatie mislukt, wordt autorisatie nooit geëvalueerd. Zelfs na verificatie kunnen gebruikers of groepen de toegang tot bepaalde acties weigeren als ze niet over de benodigde machtigingen beschikken.

Azure DevOps beheert autorisatie via machtigingen die rechtstreeks zijn toegewezen aan gebruikers of overgenomen via beveiligingsgroepen of rollen. Toegangsniveaus en functievlagmen kunnen de toegang tot specifieke functies verder beheren. Zie Aan de slag met machtigingen, toegang en beveiligingsgroepen voor meer informatie over deze autorisatiemethoden.

Beveiligingsnaamruimten en -machtigingen

Beveiligingsnaamruimten definiëren gebruikerstoegangsniveaus voor specifieke acties in Azure DevOps-resources.

• Elke resourcefamilie, bijvoorbeeld werkitems of Git-opslagplaatsen, heeft een eigen unieke naamruimte.
• Binnen elke naamruimte kunnen er meerdere toegangsbeheerlijsten (ACL's) zijn.
  • Elke ACL bevat een token, een erfenisvlag en een of meer toegangsbeheervermeldingen (ACE's).
  • Elke ACE specificeert een identiteitsdescriptor, een bitmasker voor toegestane machtigingen en een bitmasker voor geweigerde machtigingen.

Zie Beveiligingsnaamruimten en machtigingsreferenties voor meer informatie.

Beveiligingsbeleid

Om uw organisatie en code te beveiligen, kunnen beheerders op organisatieniveau (Projectverzamelingsbeheerder) of tenantniveau (Azure DevOps Administrator) verschillende beveiligingsbeleidsregels in- of uitschakelen, afhankelijk van het beleidsbereik. Belangrijke beleidsregels die u moet overwegen, zijn onder andere:

• Geef een URL voor het privacybeleid op om te beschrijven hoe u de privacy van interne en externe gastgegevens verwerkt.
• Bepaal of gebruikers in uw organisatie openbare projecten mogen maken.

Als uw organisatie is verbonden met Microsoft Entra ID, hebt u toegang tot de volgende andere beveiligingsfuncties:

• Het maken van organisaties beperken tot specifieke gebruikers.
• Nodig externe gasten uit voor de organisatie.
• Hiermee kunnen team- en projectbeheerders nieuwe gebruikers uitnodigen.
• Validatie van beleid voor voorwaardelijke toegang (CAP) inschakelen.
• Auditgebeurtenissen en streams in uw organisatie bijhouden.

Controleer en configureer dit beleid om het beveiligingspostuur van uw organisatie te versterken en ervoor te zorgen dat uw gegevensprivacy en toegangsvereisten worden nageleefd.

Gebruikersgroep 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.

Als u de toegang wilt beperken voor specifieke gebruikers, zoals belanghebbenden, Gastgebruikers van Microsoft Entra of leden van een bepaalde beveiligingsgroep, schakelt u de functie Zichtbaarheid en samenwerking van gebruikers beperken tot specifieke preview-functies voor projecten voor uw organisatie. Wanneer deze functie is ingeschakeld, wordt elke gebruiker of groep die is toegevoegd aan de groepProject-Scoped Gebruikers op de volgende manieren beperkt:

• Toegang is beperkt tot de pagina's Overzicht en Projecten binnen organisatie-instellingen.
• Gebruikers kunnen alleen toegang krijgen tot projecten waaraan ze expliciet zijn toegevoegd.
• Gebruikers kunnen alleen gebruikers- en groepsidentiteiten selecteren die expliciet aan hetzelfde project worden toegevoegd.

Zie Uw organisatie beheren voor meer informatie: Beperk de zichtbaarheid van gebruikers voor projecten en meer enbeheer preview-functies.

Waarschuwing

Houd rekening met de volgende beperkingen bij het gebruik van deze preview-functie:

• 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.
• Gebruikers in de beperkte groep kunnen alleen gebruikers selecteren die expliciet zijn toegevoegd aan Azure DevOps en niet gebruikers die toegang hebben via microsoft Entra-groepslidmaatschap.
• Gastgebruikers die lid zijn van de beperkte groep met standaardtoegang in Microsoft Entra ID, kunnen niet zoeken naar gebruikers met de personenkiezer.

Git-opslagplaats en vertakkingsbeleid

• Instellingen en beleidsregels voor opslagplaatsen configureren
• Vertakkingsbeleid configureren
• Vertakkingsbeleid configureren voor een externe service
• Azure Functions gebruiken om aangepast vertakkingsbeleid te maken

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.

• Azure Pipelines beveiligen
• Plannen hoe u uw YAML-pijplijnen beveiligt
• Beveiliging van opslagplaatsen
• Pijplijnbronnen
• Aanbevelingen voor het veilig structuren van projecten in uw pijplijn
• Beveiliging via sjablonen
• Variabelen en parameters veilig gebruiken in uw pijplijn
• Aanbevelingen voor het beveiligen van een gedeelde infrastructuur in Azure Pipelines
• Andere beveiligingsoverwegingen

Volgende stappen

Naslaginformatie over machtigingen en groepen

Verwante inhoud

• Standaardmachtigingen en toegangstoewijzingen
• Gebruikers toevoegen of verwijderen met behulp van Microsoft Entra ID
• Groepen instellen voor gebruik in on-premises implementaties
• HTTPS instellen met Secure Sockets Layer (SSL)
• Standaardmachtigingen en toegangstoewijzingen