Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Apps kunnen de Azure Identity-bibliotheek gebruiken om te verifiëren bij Microsoft Entra ID, zodat de apps toegang hebben tot Azure-services en -resources. Deze verificatievereiste is van toepassing of de app wordt geïmplementeerd in Azure, on-premises wordt gehost of lokaal wordt uitgevoerd op een ontwikkelaarswerkstation. In de volgende secties worden de aanbevolen benaderingen beschreven voor het verifiëren van een app bij Microsoft Entra-id in verschillende omgevingen bij het gebruik van de Azure SDK-clientbibliotheken.
Aanbevolen benadering voor app-verificatie
Verificatie op basis van tokens via Microsoft Entra ID is de aanbevolen methode voor het verifiëren van apps naar Azure, in plaats van verbindingsreeksen of sleutelopties te gebruiken. De Azure Identity-clientmodule voor Go biedt verificatie op basis van tokens en staat apps toe om te verifiëren bij Azure-resources, ongeacht of de app lokaal, in Azure of op een on-premises server wordt uitgevoerd.
Voordelen van verificatie op basis van tokens
Verificatie op basis van tokens biedt de volgende voordelen ten opzichte van verbindingsreeksen:
- Verificatie op basis van tokens zorgt ervoor dat alleen de specifieke apps die zijn bedoeld voor toegang tot de Azure-resource, dit kunnen doen, terwijl iedereen of elke app met een verbindingsreeks verbinding kan maken met een Azure-resource.
- Met verificatie op basis van tokens kunt u de toegang tot Azure-resources verder beperken tot alleen de specifieke machtigingen die nodig zijn voor de app. Dit volgt het principe van minimale bevoegdheden. Een verbindingsreeks verleent daarentegen volledige rechten aan de Azure-resource.
- Wanneer u een beheerde identiteit gebruikt voor verificatie op basis van tokens, verwerkt Azure beheerfuncties voor u, zodat u zich geen zorgen hoeft te maken over taken zoals het beveiligen of roteren van geheimen. Hierdoor is de app veiliger omdat er geen verbindingsreeks of toepassingsgeheim is dat kan worden aangetast.
- De Azure Identity-bibliotheek verkrijgt en beheert Microsoft Entra-tokens voor u.
Het gebruik van verbindingsreeksen moet worden beperkt tot scenario's waarin authenticatie op basis van tokens geen optie is, proof-of-concept-apps, of ontwikkelingsprototypes die geen toegang hebben tot productie- of gevoelige gegevens. Gebruik indien mogelijk de referentietypen in de Azure Identity-bibliotheek om te verifiëren bij Azure-resources.
Verificatie in verschillende omgevingen
Het specifieke type verificatie op basis van tokens dat een app moet gebruiken om te verifiëren bij Azure-resources, is afhankelijk van waar de app wordt uitgevoerd. Het volgende diagram bevat richtlijnen voor verschillende scenario's en omgevingen:
Wanneer een app:
- Gehost in Azure: de app moet worden geverifieerd bij Azure-resources met behulp van een beheerde identiteit. Deze optie wordt uitvoeriger besproken bij verificatie in serveromgevingen.
- Lokaal uitvoeren tijdens de ontwikkeling: De app kan worden geverifieerd bij Azure met behulp van een toepassingsservice-principal voor lokale ontwikkeling of met behulp van de Azure-referenties van de ontwikkelaar. Elke optie wordt uitvoeriger besproken bij authenticatie tijdens lokale ontwikkeling.
- Gehost on-premises: de app moet worden geverifieerd bij Azure-resources met behulp van een toepassingsservice-principal of een beheerde identiteit in het geval van Azure Arc. On-premises werkstromen worden uitvoeriger besproken bij verificatie in serveromgevingen.
Verificatie voor door Azure gehoste apps
Wanneer uw app wordt gehost in Azure, kan deze beheerde identiteiten gebruiken om te verifiëren bij Azure-resources zonder referenties te hoeven beheren. Er zijn twee typen beheerde identiteiten: door de gebruiker toegewezen en door het systeem toegewezen.
Een door de gebruiker toegewezen beheerde identiteit gebruiken
Een door de gebruiker toegewezen beheerde identiteit wordt gemaakt als een zelfstandige Azure-resource. Deze kan worden toegewezen aan een of meer Azure-resources, zodat deze resources dezelfde identiteit en machtigingen kunnen delen. Als u wilt verifiëren met behulp van een door de gebruiker toegewezen beheerde identiteit, maakt u de identiteit, wijst u deze toe aan uw Azure-resource en configureert u vervolgens uw app om deze identiteit te gebruiken voor verificatie door de client-id, resource-id of object-id op te geven.
Een door het systeem toegewezen beheerde identiteit gebruiken
Een door het systeem toegewezen beheerde identiteit wordt rechtstreeks ingeschakeld op een Azure-resource. De identiteit is gekoppeld aan de levenscyclus van die resource en wordt automatisch verwijderd wanneer de resource wordt verwijderd. Als u wilt verifiëren met behulp van een door het systeem toegewezen beheerde identiteit, schakelt u de identiteit in uw Azure-resource in en configureert u vervolgens uw app voor het gebruik van deze identiteit voor verificatie.
Verificatie tijdens lokale ontwikkeling
Tijdens lokale ontwikkeling kunt u zich verifiëren bij Azure-resources met behulp van uw referenties voor ontwikkelaars of een service-principal. Hiermee kunt u de verificatielogica van uw app testen zonder deze in Azure te implementeren.
Referenties voor ontwikkelaars gebruiken
U kunt uw eigen Azure-referenties gebruiken om tijdens lokale ontwikkeling te authenticeren met Azure-resources. Dit wordt meestal gedaan met behulp van een ontwikkelhulpprogramma, zoals Azure CLI, dat uw app de benodigde tokens kan bieden voor toegang tot Azure-services. Deze methode is handig, maar mag alleen worden gebruikt voor ontwikkelingsdoeleinden.
Een service-principal gebruiken
Er wordt een service-principal gemaakt in een Microsoft Entra-tenant die een app vertegenwoordigt en wordt gebruikt voor verificatie bij Azure-resources. U kunt uw app tijdens lokale ontwikkeling configureren om service-principalgegevens te gebruiken. Deze methode is veiliger dan het gebruik van referenties voor ontwikkelaars en is dichter bij de manier waarop uw app in productie wordt geverifieerd. Het is echter nog steeds minder ideaal dan het gebruik van een beheerde identiteit vanwege de noodzaak van geheimen.
Verificatie voor apps die on-premises worden gehost
Voor apps die on-premises worden gehost, kunt u een service-principal gebruiken om te verifiëren bij Azure-resources. Dit omvat het maken van een service-principal in Microsoft Entra ID, het toewijzen van de benodigde machtigingen en het configureren van uw app om gebruik te maken van de referenties. Met deze methode kan uw on-premises app veilig toegang krijgen tot Azure-services.