gebeurtenis
17 mrt, 21 - 21 mrt, 10
Neem deel aan de meetup-serie om schaalbare AI-oplossingen te bouwen op basis van praktijkgebruiksvoorbeelden met collega-ontwikkelaars en experts.
Nu registrerenOver beveiliging, verificatie en autorisatie
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. De combinatie van beide bepaalt de toegang van de gebruiker tot specifieke 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. Elk platform maakt 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.
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 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 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.
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:
OAuth- om namens gebruikers tokens te genereren voor toegang tot REST API's.
- Er zijn twee OAuth-app-modellen beschikbaar: Azure DevOps OAuth is gepland voor afschaffing in 2026. Gebruik Microsoft Entra OAuth- om namens gebruikers-apps te bouwen.
- U kunt ook Microsoft Entra-tokens genereren voor ad-hocbewerkingen namens uzelf, voor toegang tot resources zoals builds en werkitems, of voor toegang tot Azure DevOps REST API's.
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.
Persoonlijke toegangstokens (PATs) om token voor u te genereren. PAW's zijn mogelijk handig voor clients zoals Xcode en NuGet die geen ondersteuning bieden voor Microsoft-accounts of -functies, zoals meervoudige verificatie (MFA).
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.
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 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 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.
Als u uw organisatie en code wilt beveiligen, kunt u verschillende beleidsregels instellen. U kunt met name het volgende beleid in- of uitschakelen:
- URL van privacybeleid: Hiermee geeft u een URL op die is gekoppeld aan uw aangepaste document waarin wordt beschreven hoe u zowel interne als externe gastgegevensprivacy verwerkt. Zie Een URL voor het privacybeleid toevoegen voor uw organisatie voor meer informatie.
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:
- Niet-Microsoft-toepassingstoegang via OAuth.
- Toegang tot SSH-verificatie.
- Openbare projecten toestaan: wanneer dit is ingeschakeld, kunnen gebruikers openbare projecten maken die niet-leden van een project en gebruikers die niet zijn aangemeld met het kenmerk Alleen-lezen, beperkte toegang tot de artefacten en services van het project. Zie Uw project openbaar maken voor meer informatie.
- Auditgebeurtenissen vastleggen: schakel de mogelijkheid in om controlegebeurtenissen en streams voor uw organisatie bij te houden.
- Schakel validatie van Het Beleid voor voorwaardelijke toegang (CAP) van Microsoft Entra in.
- 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.
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 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. Wanneer deze optie is ingeschakeld, worden gebruikers of groepen die zijn toegevoegd aan de groep Project-Scoped Gebruikers, 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 die ze toegevoegd aan expliciet.
- 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
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 devopsCLI-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.
U kunt verschillende Git-opslagplaats- en vertakkingsbeleid instellen om uw code te beveiligen. Zie de volgende artikelen voor meer informatie.
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
Aanvullende resources
Training
Module
Beveiligde toegang tot pijplijnbronnen configureren - Training
Veilige toegang tot pijplijnbronnen configureren.
Certificering
Microsoft Gecertificeerd: Identiteits- en Toegangsbeheerbeheerder Associate - Certifications
Demonstreer de functies van Microsoft Entra ID om identiteitsoplossingen te moderniseren, hybride oplossingen te implementeren en identiteitsbeheer te implementeren.