Toepassingsverbinding en beveiligingsbeleid voor uw organisatie wijzigen

Belangrijk

Azure DevOps biedt geen ondersteuning voor verificatie van alternatieve referenties. Als u alternatieve inloggegevens gebruikt, schakelt u over naar een veiligere authenticatiemethode.

Belangrijk

Openbare projecten in Azure DevOps worden buiten gebruik gesteld. Vanaf 2027 worden bestaande openbare projecten omgezet in privéprojecten. Raadpleeg Openbare projecten beëindiging en Migreren van een openbaar project naar GitHub voor meer informatie.

In dit artikel wordt beschreven hoe u het beveiligingsbeleid van uw organisatie beheert waarmee wordt bepaald hoe gebruikers en toepassingen toegang hebben tot services en resources in uw organisatie. U hebt toegang tot de meeste van deze beleidsregels in organisatie-instellingen.

Vereisten

Categorie Vereisten
Toestemmingen

Een beleid beheren

Als u toepassingsverbinding, beveiliging of gebruikersbeleid voor uw organisatie wilt bijwerken, voert u de volgende stappen uit:

  1. Meld u aan bij uw organisatie op https://dev.azure.com/{Your_Organization}.

  2. Selecteer tandwielpictogramOrganisatie-instellingen.

    Schermopname van de knop Organisatie-instellingen, preview-pagina.

  3. Selecteer Beleid en schakel vervolgens het gewenste beleid in of uit.

    Schermopname van de lijst met beleidsregels en de wisselknop aan en uit.

Verificatiemethoden beperken

Om naadloze toegang tot uw organisatie mogelijk te maken zonder herhaaldelijk om gebruikersreferenties te vragen, kunnen toepassingen verificatiemethoden gebruiken, zoals OAuth, SSH en persoonlijk toegangstoken (PAT's). Standaard staan alle bestaande organisaties toegang toe voor alle verificatiemethoden.

U kunt de toegang tot deze verificatiemethoden beperken door het volgende toepassingsverbindingsbeleid uit te schakelen:

  • Toegang tot toepassingen van derden via OAuth: Schakel Azure DevOps OAuth-apps in voor toegang tot resources in uw organisatie via OAuth. Dit beleid is standaard uitgeschakeld voor alle nieuwe organisaties. Als u toegang wilt tot Azure DevOps OAuth-apps, schakelt u dit beleid in om ervoor te zorgen dat deze apps toegang hebben tot resources in uw organisatie. Dit beleid heeft geen invloed op de toegang tot de OAuth-app van Microsoft Entra ID.
  • SSH-verificatie: schakel toepassingen in om via SSH verbinding te maken met de Git-opslagplaatsen van uw organisatie.
  • Tenantbeheerders kunnen het maken van globale persoonlijke toegangstokens beperken, het maken van een volledig persoonlijk toegangstoken beperken en de maximale levensduur van persoonlijke toegangstokens afdwingen via beleid op tenantniveau op de pagina Instellingen van Microsoft Entra . Voeg Microsoft Entra-gebruikers of -groepen toe om deze beleidsregels te uitsluiten.
  • Organisatiebeheerders kunnen het maken van persoonlijke toegangstokens in hun respectieve organisaties beperken. Met subbeleidsregels kunnen beheerders het maken toestaan van PAT's met alleen het verpakkingsbereik of PAT's voor elk bereik voor gebruikers of groepen in Microsoft Entra op de toelatingslijst. Wanneer beheerders het maken van PAT uitschakelen, voorkomt Azure DevOps ook dat Git Credential Manager (GCM) nieuwe PAT's voor Git-bewerkingen genereert, tenzij de gebruiker is toegestaan. GCM is standaard ingesteld op verificatie op basis van PAT, maar gebruikers kunnen zich in plaats daarvan verifiëren met OAuth. Zie de GCM-documentatie voor meer informatie.

Wanneer u de toegang tot een verificatiemethode weigert, heeft geen toepassing via die methode toegang tot uw organisatie. Elke toepassing die eerder toegang had, ondervindt verificatiefouten en verliest de toegang.

Ondersteuning voor beleid voor voorwaardelijke toegang in Azure DevOps

Conditional Access (CA) in Azure DevOps wordt afgedwongen via Microsoft Entra ID en ondersteunt zowel interactieve stromen (web) als niet-interactieve stromen (clientreferenties), het valideren van beleidsregels zoals MFA, IP-beperkingen en apparaatcompatibiliteit tijdens aanmelding en periodiek via tokencontroles.

SSH-sleutelbeleid

SSH-verificatie

Het SSH-verificatiebeleid bepaalt of een organisatie het gebruik van SSH-sleutels toestaat.

Verlopen van SSH-sleutel valideren

Als u geen toegang wilt verliezen vanwege een verlopen SSH-sleutel, maakt en uploadt u een nieuwe sleutel voordat de huidige sleutel verloopt. Het systeem verzendt geautomatiseerde meldingen 7 dagen voor de vervaldatum en opnieuw na de vervaldatum om u te helpen vooruit te blijven. Zie stap 1 voor meer informatie: Uw SSH-sleutels maken.

Het verloopbeleid voor SSH-sleutels valideren is standaard ingeschakeld. Wanneer deze actief is, wordt de vervaldatum afgedwongen. Verlopen sleutels worden onmiddellijk ongeldig.

Als u het beleid uitschakelt, controleert het systeem niet langer de vervaldatums en blijven verlopen sleutels bruikbaar.

Beleid per niveau

Beleid Organisatieniveau Tenantniveau
Toegang tot toepassingen van derden via OAuth ✅
SSH-verificatie ✅
Verlopen van SSH-sleutel valideren ✅
Auditgebeurtenissen loggen ✅
Het maken van persoonlijke toegangstokens beperken ✅
Openbare projecten toestaan ✅
Aanvullende beveiliging bij het gebruik van openbare pakketregisters ✅
Validatie van beleid voor voorwaardelijke toegang voor IP inschakelen voor niet-interactieve stromen ✅
Externe gasttoegang ✅
Team- en projectbeheerders toestaan om nieuwe gebruikers uit te nodigen ✅
Met toegang aanvragen kunnen gebruikers toegang tot de organisatie aanvragen met een opgegeven interne URL ✅
Microsoft toestaan feedback van gebruikers te verzamelen ✅
Het maken van een organisatie beperken ✅
Het maken van een globaal persoonlijk toegangstoken beperken ✅
Het maken van een volledig persoonlijk toegangstoken beperken ✅
Maximale levensduur van persoonlijke toegangstokens afdwingen ✅
  • Laatst bijgewerkt om