Verleen applicatie-identiteitsreferenties wanneer er geen gebruiker is

Wanneer u als ontwikkelaar niet-gebruikerstoepassingen bouwt, hebt u geen gebruiker die u kunt vragen om een gebruikersnaam en wachtwoord of Meervoudige verificatie (MFA). U moet de identiteit van de toepassing zelf opgeven. In dit artikel wordt uitgelegd waarom de beste zero Trust-clientreferenties voor services (niet-gebruikerstoepassingen) in Azure beheerde identiteiten zijn voor Azure-resources.

Problemen met serviceaccounts

Het gebruik van een serviceaccount (het gebruik van een gebruikersaccount voor een service) is geen goede oplossing. Microsoft Entra ID heeft geen serviceaccountconcept. Wanneer beheerders gebruikersaccounts voor services maken en wachtwoorden vervolgens delen met ontwikkelaars, is dit onveilig. Het kan geen wachtwoordloos zijn of een MFA hebben. In plaats van een gebruikersaccount als een serviceaccount te gebruiken, kunt u het beste een van de volgende clientreferentieopties gebruiken.

Opties voor klantreferentiegegevens

Er zijn vier typen clientreferenties waarmee een toepassing kan worden geïdentificeerd.

• Geheime sleutel
• Certificaat
• Beheerde identiteiten voor Azure-resources
• Federatieve referenties

Geheime sleutel of certificaat?

Geheime sleutels zijn acceptabel in geavanceerde infrastructuren voor geheimenbeheer (zoals Azure Key Vault). U kunt geheime sleutels echter niet goed beveiligen in scenario's waarin de IT-professional een geheime sleutel genereert en deze vervolgens naar een ontwikkelaar stuurt.

Clientreferenties op basis van certificaten zijn veiliger dan geheime sleutels. U kunt certificaten beter beheren omdat ze niet het geheim zelf zijn. Het geheim maakt geen deel uit van een overdracht. Wanneer u een geheime sleutel gebruikt, verzendt uw client de werkelijke waarde van de geheime sleutel naar Microsoft Entra-id. Wanneer u een certificaat gebruikt, verlaat de persoonlijke sleutel van het certificaat het apparaat nooit. Zelfs als iemand de overdracht onderschept, decodeert en ontsleutelt, is het geheim nog steeds veilig omdat de onderscheppende partij niet over de privésleutel beschikt.

Best practice: Beheerde identiteiten gebruiken voor Azure-resources

Wanneer u services (niet-gebruikerstoepassingen) ontwikkelt in Azure, bieden beheerde identiteiten voor Azure-resources een automatisch beheerde identiteit in Microsoft Entra-id. De app kan worden geverifieerd bij elke service die Ondersteuning biedt voor Microsoft Entra-verificatie zonder referenties te beheren. U hoeft geen geheimen te beheren. U hoeft geen aandacht te geven aan de mogelijkheid om ze te verliezen of verkeerd te behandelen. Slechte actoren kunnen geen geheimen onderscheppen die niet over het netwerk lopen. Beheerde identiteiten voor Azure-resources is de beste werkwijze voor het ontwikkelen van services in Azure.

Volgende stappen 

• In ondersteunde identiteits- en accounttypen voor apps met één en meerdere tenants wordt uitgelegd hoe u kunt kiezen of uw app alleen gebruikers van uw Microsoft Entra-tenant, elke Microsoft Entra-tenant of gebruikers met persoonlijke Microsoft-accounts toestaat.
• Door een strategie voor toepassingsmachtigingen te ontwikkelen, kunt u beslissen over de benadering van uw toepassingsmachtigingen voor referentiebeheer.
• Legt uit waarom u referenties voor toepassingsidentiteiten moet opgeven wanneer er geen gebruiker is, waarom Beheerde identiteiten voor Azure-resources de beste methode zijn voor clientreferenties voor services (niet-gebruikerstoepassingen) in Azure.
• Met best practices voor autorisatie kunt u de beste autorisatie-, machtigings- en toestemmingsmodellen voor uw toepassingen implementeren.
• Gebruik best practices voor identiteits- en toegangsbeheer van Zero Trust in de ontwikkelingslevenscyclus van uw toepassing om veilige toepassingen te maken.
• Het bouwen van apps met een Zero Trust-benadering voor identiteit biedt een overzicht van machtigingen en aanbevolen procedures voor toegang.