Delen via

Referenties voor toepassingsidentiteit opgeven wanneer er geen gebruiker is

  • Artikel

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' (een gebruikersaccount maken en gebruiken voor een service) is geen goede oplossing. Microsoft Entra ID heeft geen serviceaccountconcept. Wanneer beheerders gebruikersaccounts voor een service 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 clientreferenties

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

Geheime sleutel of certificaat?

Geheime sleutels zijn acceptabel wanneer u een geavanceerde infrastructuur voor geheimenbeheer (zoals Azure Key Vault) in uw onderneming hebt. Geheime sleutels in scenario's waarin de IT-professional echter een geheime sleutel genereert en vervolgens een e-mail stuurt naar een ontwikkelaar die deze vervolgens op een onveilige locatie kan opslaan, zoals een spreadsheet, zorgt ervoor dat geheime sleutels niet goed worden beveiligd.

Clientreferenties op basis van certificaten zijn veiliger dan geheime sleutels. Certificaten worden beter beheerd 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, ontsleutelt en ontsleutelt, is het geheim nog steeds veilig omdat de onderscheppende partij niet over de persoonlijke sleutel beschikt.

Best practice: Beheerde identiteiten gebruiken voor Azure-resources

Wanneer u services (niet-gebruikerstoepassingen) in Azure ontwikkelt, 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 niet te reageren op de mogelijkheid om ze kwijt te raken of te mishanden. Geheimen kunnen niet worden onderschept omdat ze niet via het netwerk worden verplaatst. Beheerde identiteiten voor Azure-resources is de aanbevolen procedure als u services bouwt in Azure.

Volgende stappen