Overzicht: Geïntegreerde verificatie voor Python-apps met Azure-services

Microsoft Entra ID, wanneer deze wordt gebruikt met Azure Key Vault, biedt een robuuste en veilige benadering voor het verifiëren van toepassingen voor zowel Azure-services als platforms van derden waarvoor toegangssleutels of referenties zijn vereist. Deze combinatie elimineert de noodzaak om geheimen in toepassingscode te coderen, in plaats daarvan te vertrouwen op beheerde identiteiten, op rollen gebaseerd toegangsbeheer (RBAC) en gecentraliseerd geheimbeheer via Key Vault. Deze aanpak stroomlijnt identiteitsbeheer en verbetert de beveiligingspostuur in cloudomgevingen.

In dit scenario worden deze verificatiemechanismen verkend via een praktisch voorbeeld in de GitHub-opslagplaats: github.com/Azure-Samples/python-integrated-authentication.

In het voorbeeld ziet u hoe een Python-toepassing het volgende kan doen:

• Verifiëren met Azure met behulp van DefaultAzureCredential

• Toegang tot Azure Key Vault-geheimen zonder referenties op te slaan

• Veilig communiceren met andere Azure-services, zoals Azure Storage, Cosmos DB en meer

Dit artikel maakt deel uit van een reeks die een gedetailleerd overzicht biedt van het verifiëren van een Python-app met Microsoft Entra ID, Azure Key Vault en Azure Queue Storage met behulp van de Azure Python SDK-bibliotheek azure-identity .

Deel 1: Achtergrond

Hoewel veel Azure-services uitsluitend afhankelijk zijn van op rollen gebaseerd toegangsbeheer (RBAC), vereisen anderen toegang via geheimen of sleutels. Dergelijke services omvatten Azure Storage, databases, Foundry Tools, Key Vault en Event Hubs.

Bij het bouwen van cloudtoepassingen die met deze services communiceren, kunnen ontwikkelaars de Azure-portal, CLI of PowerShell gebruiken om servicespecifieke toegangssleutels te genereren en te configureren. Deze sleutels zijn gekoppeld aan bepaalde toegangsbeleidsregels om onbevoegde toegang te voorkomen. Voor dit model moet uw toepassing echter expliciet sleutels beheren en afzonderlijk verifiëren bij elke service, een proces dat zowel tijdrovend als foutgevoelig is.

Het rechtstreeks insluiten van geheimen in code of het opslaan ervan op ontwikkelcomputers bestaat de kans dat ze beschikbaar worden gemaakt in:

• Bronbeheer
• Onveilige lokale omgevingen
• Onopzettelijke logboeken of configuratieexporten

Azure biedt twee belangrijke services om de beveiliging te verbeteren en verificatie te vereenvoudigen:

• Azure Key Vault Azure Key Vault biedt een veilig, cloudarchief voor geheimen, waaronder toegangssleutels, verbindingsreeksen en certificaten. Door geheimen alleen tijdens runtime op te halen uit Key Vault, voorkomt u dat in toepassingen gevoelige gegevens worden weergegeven in broncode- of configuratiebestanden.

• Met door Microsoft Entra beheerde identiteiten kan uw toepassing eenmaal worden geverifieerd met Microsoft Entra-id. Van daaruit heeft het toegang tot andere Azure-services, waaronder Key Vault, zonder referenties rechtstreeks te beheren.

Deze aanpak biedt:

• Code zonder referenties (geen geheimen in broncodebeheer)
• Naadloze integratie met Azure-services
• Omgevingsconsistentie: dezelfde code wordt lokaal en in de cloud uitgevoerd met minimale configuratie

In dit overzicht ziet u hoe u met Microsoft Entra beheerde identiteit en Key Vault samen in dezelfde app kunt gebruiken. Door Microsoft Entra ID en Key Vault samen te gebruiken, hoeft uw app zich nooit te verifiëren met afzonderlijke Azure-services en kan uw app eenvoudig en veilig toegang krijgen tot sleutels die nodig zijn voor services van derden.

Belangrijk

In dit artikel wordt de algemene algemene term 'sleutel' gebruikt om te verwijzen naar wat zijn opgeslagen als 'geheimen' in Azure Key Vault, zoals een toegangssleutel voor een REST API. Dit gebruik mag niet worden verward met het beheer van cryptografische sleutels van Key Vault. Dit is een afzonderlijke functie van de geheimen van Key Vault.

Voorbeeldscenario voor cloud-apps

Als u meer inzicht wilt in het verificatieproces van Azure, kunt u het volgende scenario overwegen: Een Flask-webtoepassing wordt geïmplementeerd in Azure App Service. Er wordt een openbaar, niet-geverifieerd API-eindpunt weergegeven dat JSON-gegevens retourneert als reactie op HTTP-aanvragen.

• Om het antwoord te genereren, roept de API een API van derden aan waarvoor een toegangssleutel is vereist. In plaats van deze sleutel op te slaan in code- of configuratiebestanden, haalt de app deze veilig op uit Azure Key Vault met behulp van door Microsoft Entra beheerde identiteit.

• Voordat de reactie aan de client wordt geretourneerd, schrijft de app een bericht naar een Azure Storage-wachtrij voor asynchrone verwerking. Het bericht kan een taak, logboek of signaal vertegenwoordigen, maar de downstreamverwerking is niet de focus van dit scenario.

Opmerking

Hoewel openbare API-eindpunten doorgaans worden beveiligd door hun eigen toegangssleutels of verificatiemechanismen, wordt in dit scenario ervan uitgegaan dat het eindpunt open en niet-geverifieerd is.

Deze vereenvoudiging helpt bij het isoleren van de interne verificatievereisten van de app, zoals het openen van Azure Key Vault en Azure Storage, van verificatieproblemen met betrekking tot externe clients.

Het scenario richt zich alleen op het gedrag van de app en demonstreert of betrekt geen externe beller die verificatie uitvoert met het eindpunt.

Deel 2: verificatievereisten >>>