Walkthrough: Geïntegreerde verificatie voor Python-apps met Azure-services
Azure Active Directory (Azure AD) bieden samen met Azure Key Vault een uitgebreide en handige manier voor toepassingen voor verificatie met Azure-services en services van derden waarbij toegangssleutels betrokken zijn.
Na enige achtergrondinformatie worden deze verificatiefuncties in de context van het voorbeeld uitgelegd, github.com/Azure-Samples/python-integrated-authentication.
Voor het gemak is het voorbeeld al geïmplementeerd in Azure, zodat u het in werking kunt zien. Als u het voorbeeld wilt implementeren in uw eigen Azure-abonnement, bevat de opslagplaats ook Azure CLI-implementatiescripts.
Deel 1: Achtergrond
Hoewel veel Azure-services uitsluitend afhankelijk zijn van op rollen gebaseerd toegangsbeheer voor autorisatie, beheren bepaalde services de toegang tot hun respectieve resources met behulp van geheimen of sleutels. Dergelijke services omvatten Azure Storage, databases, Cognitive Services, Key Vault en Event Hubs.
Wanneer u een cloud-app maakt die gebruikmaakt van resources binnen deze services, gebruikt u de Azure Portal, de Azure CLI of Azure PowerShell om sleutels te maken en te configureren voor uw app die zijn gekoppeld aan specifiek toegangsbeleid. Deze sleutels verhinderen de toegang tot deze app-specifieke resources door andere niet-geautoriseerde code.
Binnen dit algemene ontwerp moeten cloud-apps deze sleutels doorgaans beheren en bij elke service afzonderlijk verifiëren, een proces dat zowel omslachtig als foutgevoelig kan zijn. Als u sleutels rechtstreeks in app-code beheert, loopt u ook het risico dat deze sleutels in broncodebeheer beschikbaar worden gemaakt. Sleutels kunnen worden opgeslagen op niet-beveiligde werkstations van ontwikkelaars.
Gelukkig biedt Azure twee specifieke services om het proces te vereenvoudigen en betere beveiliging te bieden:
Azure Key Vault biedt beveiligde cloudopslag voor toegangssleutels (samen met cryptografische sleutels en certificaten, die niet in dit artikel worden behandeld). Door gebruik Key Vault, heeft de app alleen tijdens run time toegang tot dergelijke sleutels, zodat ze nooit rechtstreeks in de broncode worden weergegeven.
Met Azure Active Directory (Azure AD) beheerde identiteiten hoeft de app slechts één keer te worden geverifieerd bij Active Directory. De app wordt vervolgens automatisch geverifieerd met andere Azure-services, waaronder Key Vault. Als gevolg hiervan hoeft uw code zich nooit te zorgen over sleutels of andere referenties voor deze Azure-services. Nog beter: u kunt dezelfde code zowel lokaal als in de cloud uitvoeren met minimale configuratievereisten.
Als u Azure AD en Key Vault gebruikt, hoeft uw app zich nooit te verifiëren bij afzonderlijke Azure-services en heeft deze gemakkelijk en veilig toegang 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 in Azure Key Vault is opgeslagen als 'geheimen', zoals een toegangssleutel voor een REST API. Dit gebruik mag niet worden verward met Key Vault het beheer van cryptografische sleutels, een afzonderlijke functie van Key Vault geheimen van de Key Vault.
Voorbeeld van een cloud-app-scenario
Als u meer inzicht wilt krijgen in het verificatieproces van Azure, moet u rekening houden met het volgende scenario:
Een hoofd-app toont een openbaar (niet-geverifieerd) API-eindpunt dat reageert op HTTP-aanvragen met JSON-gegevens. Het voorbeeld-eindpunt, zoals weergegeven in dit artikel, wordt geïmplementeerd als een eenvoudige Flask-app die is geïmplementeerd op Azure App Service.
Voor het genereren van het antwoord roept de API een API van derden aan die een toegangssleutel vereist. De app haalt die toegangssleutel op uit Azure Key Vault run time.
Voordat het antwoord wordt weergegeven, schrijft de API een bericht naar een Azure Storage wachtrij voor latere verwerking. (De specifieke verwerking van deze berichten is niet relevant voor het hoofdscenario.)

Notitie
Hoewel een openbaar API-eindpunt meestal wordt beveiligd met een eigen toegangssleutel, gaan we in dit artikel ervan uit dat het eindpunt open en niet-niet-is. Deze veronderstelling voorkomt verwarring tussen de verificatiebehoeften van de app met die van een externe aanroeper van dit eindpunt. In dit scenario wordt een dergelijke externe aanroeper niet gedemonstreerd.