Apps Python verifiëren voor Azure services met behulp van de Azure Identity-bibliotheek

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 op Azure, on-premises wordt gehost of lokaal wordt uitgevoerd op een ontwikkelwerkstation. In de volgende secties worden de aanbevolen methoden beschreven voor het verifiëren van een app voor 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 voor Azure, in plaats van verbindingsreeksen of sleutelopties te gebruiken. De Azure Identity Library biedt klassen die ondersteuning bieden voor verificatie op basis van tokens en waarmee apps kunnen worden geverifieerd bij Azure resources, ongeacht of de app lokaal, op 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 connection string verbinding kan maken met een Azure resource.
• Met verificatie op basis van tokens kunt u Azure resourcetoegang verder beperken tot alleen de specifieke machtigingen die nodig zijn voor de app. Dit volgt het principe van minimale bevoegdheden. Een connection string verleent daarentegen volledige rechten aan de Azure resource.
• Wanneer u een beheerde identiteit gebruikt voor verificatie op basis van tokens, Azure beheerfuncties voor u afhandelt, 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 connection string 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 waarbij verificatie op basis van tokens geen optie is, initiële proof-of-concept-apps of prototypes voor ontwikkeling die geen toegang hebben tot productie- of gevoelige gegevens. Gebruik indien mogelijk de verificatieklassen op basis van tokens die beschikbaar zijn in de Azure Identiteitsbibliotheek 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:

• Hosted op Azure: De app zou moeten authenticeren 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 ontwikkelingsaccount, een broker of een service-principal. Elke optie wordt uitvoeriger besproken bij authenticatie tijdens lokale ontwikkeling.
• Hosted on-premises: de app moet worden geverifieerd bij Azure resources met behulp van een service-principal voor toepassingen of een beheerde identiteit in het geval van Azure Arc. On-premises werkstromen worden in meer detail besproken op Verificatie voor apps die on-premises worden gehost.

Verificatie voor Azure gehoste apps

Wanneer uw app wordt gehost op 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 authenticeren bij Azure-resources met uw ontwikkelaarsreferenties of een service-principal. Hiermee kunt u de verificatielogica van uw app testen zonder deze op Azure te implementeren.

Referenties voor ontwikkelaars gebruiken

U kunt uw eigen Azure-gegevens gebruiken om te authenticeren met Azure resources tijdens lokale ontwikkeling. Dit wordt meestal gedaan met behulp van een ontwikkelhulpprogramma, zoals Azure CLI of Visual Studio Code, waarmee uw app de benodigde tokens kan bieden voor toegang tot Azure services. Deze methode is handig, maar mag alleen worden gebruikt voor ontwikkelingsdoeleinden.

Een broker gebruiken

Brokered-authenticatie verzamelt gebruikersreferenties met behulp van de systeemauthenticatiebroker om een app te authenticeren. Een systeemverificatiebroker wordt uitgevoerd op de computer van een gebruiker en beheert de verificatie handshakes en tokenonderhoud voor alle verbonden accounts.

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 voor het gebruik van diens referenties. Met deze methode kan uw on-premises app veilig toegang krijgen tot Azure services.