Veelgestelde vragen over beheerde identiteiten voor Azure-resources

  • Artikel

Beheerde identiteiten voor Azure-resources is een functie van Microsoft Entra ID. Voor alle Azure-services die beheerde identiteiten voor Azure-resources ondersteunen, geldt een eigen tijdlijn. Controleer de beschikbaarheidsstatus van beheerde identiteiten voor uw resource en eventuele bekende problemen voordat u begint.

Notitie

Beheerde identiteiten voor Azure-resources is de nieuwe naam voor de service die eerder de naam Managed Service Identity (MSI) had.

Beheer

Resources met een beheerde identiteit zoeken

U vindt de lijst met resources met een door het systeem toegewezen beheerde identiteit met behulp van de volgende Azure CLI-opdracht:

az resource list --query "[?identity.type=='SystemAssigned'].{Name:name,  principalId:identity.principalId}" --output table

Welke Azure RBAC-machtigingen zijn vereist voor het gebruik van een beheerde identiteit voor een resource?

  • Door het systeem toegewezen beheerde identiteit: u moet schrijfmachtigingen hebben voor de resource. Bijvoorbeeld voor virtuele machines die u nodig hebt Microsoft.Compute/virtualMachines/write. Deze actie is opgenomen in resource-specifieke, ingebouwde rollen, zoals Inzender virtuele machines.
  • Door de gebruiker toegewezen beheerde identiteiten toewijzen aan resources: u dient over schrijfmachtigingen voor de resource te beschikken. Bijvoorbeeld voor virtuele machines die u nodig hebt Microsoft.Compute/virtualMachines/write. U hebt ook de actie Microsoft.ManagedIdentity/userAssignedIdentities/*/assign/action nodig voor de door de gebruiker toegewezen identiteit. Deze actie is opgenomen in de ingebouwde rol Operator beheerde identiteit.
  • Door de gebruiker toegewezen identiteiten beheren: als u door de gebruiker toegewezen identiteiten wilt maken of verwijderen, hebt u de roltoewijzing Inzender beheerde identiteit nodig.
  • Roltoewijzingen voor beheerde identiteiten beheren: u hebt de roltoewijzing Eigenaar of Beheerder gebruikerstoegang nodig voor de resource waartoe u toegang verleent. U hebt de roltoewijzing Lezer nodig voor de resource met een door het systeem toegewezen identiteit of voor de door de gebruiker toegewezen identiteit die de roltoewijzing heeft gekregen. Als u geen leestoegang hebt, kunt u zoeken op Gebruiker, Groep of Service-principal om de service-principal te vinden die de identiteit ondersteunt. Tijdens het toevoegen van de roltoewijzing hoeft u dan niet op beheerde identiteit te zoeken. Meer informatie over het toewijzen van Azure-rollen.

Hoe kan ik voorkomen dat door de gebruiker toegewezen beheerde identiteiten worden gemaakt?

U kunt voorkomen dat uw gebruikers door de gebruiker toegewezen beheerde identiteiten maken met behulp van Azure Policy

  1. Meld u aan bij Azure Portal en ga naar Beleid.

  2. KiesDefinities

  3. Selecteer + Beleidsdefinitie en voer de benodigde gegevens in.

  4. Plak het volgende in de sectie met beleidsregels:

    {
  "mode": "All",
  "policyRule": {
    "if": {
      "field": "type",
      "equals": "Microsoft.ManagedIdentity/userAssignedIdentities"
    },
    "then": {
      "effect": "deny"
    }
  },
  "parameters": {}
}

Nadat u het beleid hebt gemaakt, wijst u het toe aan de resourcegroep die u wilt gebruiken.

  1. Ga naar resourcegroepen.
  2. Zoek de resourcegroep die u voor het testen gebruikt.
  3. Kies in het linkermenu Beleid.
  4. Selecteer Beleid toewijzen
  5. Geef in de sectie Basisinformatie het volgende op:
    1. Bereik: de resourcegroep die wij voor het testen gebruiken
    2. Beleidsdefinitie: het beleid dat we eerder hebben gemaakt.
  6. Laat alle andere instellingen op de standaardwaarden staan en kies Beoordelen en maken

Op dit moment mislukt elke poging om een door de gebruiker toegewezen beheerde identiteit in de resourcegroep te maken.

Schermopname van een schending van het beleid.

Concepten

Hebben beheerde identiteiten een ondersteunend app-object?

Nee, beheerde identiteiten en Registraties van Microsoft Entra-apps zijn niet hetzelfde in de map.

App-registraties hebben twee onderdelen: een toepassingsobject + een service-principalobject. Beheerde identiteiten voor Azure-resources hebben slechts een van deze onderdelen: een service-principalobject.

Beheerde identiteiten hebben geen toepassingsobject in de map. Dit is wat vaak wordt gebruikt om app-machtigingen voor MS Graph te verlenen. In plaats daarvan moeten machtigingen voor MS Graph voor beheerde identiteiten rechtstreeks aan de service-principal worden verleend.

Wat is de referentie die is gekoppeld aan een beheerde identiteit? Hoe lang is deze geldig en hoe vaak wordt deze gedraaid?

Notitie

Het verifiëren van beheerde identiteiten is een intern implementatiedetail, dat zonder kennisgeving kan worden gewijzigd.

Beheerde identiteiten maken gebruik van verificatie op basis van certificaten. Een referentie van een beheerde identiteit verloopt na 90 dagen en wordt na 45 dagen geroteerd.

Welke identiteit zal IMDS standaard opgeven als ik de identiteit niet opgeeft in de aanvraag?

  • Als de door het systeem toegewezen beheerde identiteit is ingeschakeld en er geen identiteit in de aanvraag is opgegeven, valt IMDS (Azure Instance Metadata Service) standaard terug op de door het systeem toegewezen beheerde identiteit.
  • Als de door het systeem toegewezen beheerde identiteit niet is ingeschakeld en er slechts één door de gebruiker toegewezen beheerde identiteit bestaat, valt IMDS standaard terug op die ene door de gebruiker toegewezen beheerde identiteit.
  • Als de door het systeem toegewezen beheerde identiteit niet is ingeschakeld en er meerdere door de gebruiker toegewezen beheerde identiteiten bestaan, bent u verplicht een beheerde identiteit in de aanvraag op te geven.

Beperkingen

Kan dezelfde beheerde identiteit in meerdere regio's worden gebruikt?

Kortweg, ja. U kunt door de gebruiker toegewezen beheerde identiteiten gebruiken in meer dan één Azure-regio. Het langere antwoord is dat, terwijl door de gebruiker toegewezen beheerde identiteiten worden gemaakt als regionale resources, de bijbehorende service-principal (SP) die is gemaakt in Microsoft Entra ID wereldwijd beschikbaar is. De service-principal kan worden gebruikt vanuit elke Azure-regio en de beschikbaarheid ervan is afhankelijk van de beschikbaarheid van Microsoft Entra-id. Als u bijvoorbeeld een door de gebruiker toegewezen beheerde identiteit hebt gemaakt in de regio South-Central en die regio niet meer beschikbaar is, is dit probleem alleen van invloed op activiteiten van het besturingsvlak op de beheerde identiteit zelf. De activiteiten die al zijn uitgevoerd door resources die al zijn geconfigureerd voor het gebruik van de beheerde identiteiten, worden niet beïnvloed.

Werken beheerde identiteiten voor Azure-resources met Azure Cloud Services (klassiek)?

Beheerde identiteiten voor Azure-resources bieden momenteel geen ondersteuning voor Azure Cloud Services (klassiek). "

Wat is de beveiligingsgrens van beheerde identiteiten voor Azure-resources?

De beveiligingsgrens van de identiteit is de resource waaraan deze is gekoppeld. De beveiligingsgrens voor een virtuele machine met beheerde identiteiten voor Azure-resources is bijvoorbeeld de virtuele machine. Elke code die op die VM wordt uitgevoerd, kan het eindpunt van de beheerde identiteiten aanroepen en tokens aanvragen. Dit is vergelijkbaar met het werken met andere resources die beheerde identiteiten ondersteunen.

Worden beheerde identiteiten automatisch opnieuw gemaakt als ik een abonnement naar een andere map verplaats?

Nee, als u een abonnement naar een andere directory verplaatst, moet u deze handmatig opnieuw maken en Azure-roltoewijzingen opnieuw verlenen.

  • Voor door het systeem toegewezen beheerde identiteiten: uitschakelen en opnieuw inschakelen.
  • Voor door de gebruiker toegewezen beheerde identiteiten: verwijder deze, maak deze opnieuw en koppel ze opnieuw aan de benodigde resources (bijvoorbeeld virtuele machines)

Kan ik een beheerde identiteit gebruiken om toegang te krijgen tot een resource in een andere map/tenant?

Nee, beheerde identiteiten bieden momenteel geen ondersteuning voor scenario's tussen mappen.

Zijn er frequentielimieten die van toepassing zijn op beheerde identiteiten?

Limieten voor beheerde identiteiten hebben afhankelijkheden van Azure-servicelimieten, IMDS-limieten (Azure Instance Metadata Service) en Limieten voor Microsoft Entra-services.

  • Azure-servicelimieten definiëren het aantal maakbewerkingen dat kan worden uitgevoerd op tenant- en abonnementsniveau. Door de gebruiker toegewezen beheerde identiteiten kennen ook beperkingen voor de naamgeving ervan.
  • IMDS Over het algemeen zijn aanvragen bij IMDS beperkt tot vijf aanvragen per seconde. Aanvragen die deze drempelwaarde overschrijden, worden geweigerd met 429 antwoorden. Aanvragen bij de categorie Beheerde identiteit zijn beperkt tot twintig aanvragen per seconde en vijf gelijktijdige aanvragen. Meer informatie vindt u in het artikel Azure Instance Metadata Service (Windows).
  • Microsoft Entra-service Elke beheerde identiteit telt mee voor de objectquotumlimiet in een Microsoft Entra-tenant, zoals beschreven in De limieten en beperkingen van de Microsoft Entra-service.

Is het mogelijk om een door de gebruiker toegewezen beheerde identiteit te verplaatsen naar een andere resourcegroep of een ander abonnement?

Het verplaatsen van een door de gebruiker toegewezen beheerde identiteit naar een andere resourcegroep wordt niet ondersteund.

Worden tokens voor beheerde identiteiten in de cache opgeslagen?

Tokens voor beheerde identiteiten worden in de cache opgeslagen door de onderliggende Azure-infrastructuur voor prestatie- en tolerantiedoeleinden: de back-endservices voor beheerde identiteiten onderhouden ongeveer 24 uur een cache per resource-URI. Zo kan het enkele uren duren voordat wijzigingen in de machtigingen van een beheerde identiteit van kracht worden. Het is momenteel niet mogelijk om af te dwingen dat het token van een beheerde identiteit vóór de vervaldatum wordt vernieuwd. Zie Beperking van het gebruik van beheerde identiteiten voor autorisatie voor meer informatie.

Worden beheerde identiteiten voorlopig verwijderd?

Ja, beheerde identiteiten worden 30 dagen voorlopig verwijderd. U kunt de service-principal voor voorlopig verwijderde beheerde identiteiten bekijken, maar u kunt deze niet herstellen of permanent verwijderen.

Wat gebeurt er met tokens nadat een beheerde identiteit is verwijderd?

Wanneer een beheerde identiteit wordt verwijderd, kan een Azure-resource die eerder aan die identiteit is gekoppeld, voor die identiteit geen nieuwe tokens meer aanvragen. Tokens die zijn uitgegeven voordat de identiteit werd verwijderd, zijn nog steeds geldig tot aan de oorspronkelijke vervaldatum. Sommige autorisatiesystemen van doeleindpunten kunnen andere controles uitvoeren in de map voor de identiteit. In dat geval mislukt de aanvraag omdat het object niet kan worden gevonden. Sommige systemen, zoals Azure RBAC, blijven echter aanvragen van dat token accepteren totdat het verloopt.

Volgende stappen