Deel 2: Verificatiebehoeften in dit voorbeeldscenario

Vorige deel: Inleiding en achtergrond

In dit voorbeeldscenario heeft de hoofdtoepassing drie verschillende verificatievereisten:

  • Azure Key Vault

    De toepassing moet worden geverifieerd met Azure Key Vault om een veilig opgeslagen API-sleutel op te halen die nodig is om een service van derden aan te roepen.

  • API van derden

    Zodra de toepassing de API-sleutel heeft opgehaald, wordt de sleutel gebruikt om te verifiëren met de externe API van derden.

  • Azure Queue Storage (opslagservice voor wachtrijen)

    Nadat de aanvraag is verwerkt, moet de toepassing worden geverifieerd met Azure Queue Storage om een bericht in de wachtrij te plaatsen voor asynchrone of uitgestelde verwerking.

Voor deze taken moet de app drie sets referenties beheren:

  • Twee sets voor Azure resources (Key Vault en Storage)

  • Eén set voor een externe service (API van derden)

Belangrijke problemen met verificatie

Het bouwen van beveiligde cloudtoepassingen vereist zorgvuldige verwerking van referenties, met name wanneer er meerdere services betrokken zijn. Dit voorbeeldscenario biedt verschillende kritieke uitdagingen:

  • Kringafhankelijkheid van Key Vault

    De toepassing maakt gebruik van Azure Key Vault om geheimen, zoals API-sleutels van derden of Azure Storage-referenties, veilig op te slaan. Als u deze geheimen echter wilt ophalen, moet de app eerst worden geverifieerd met Key Vault. In deze situatie ontstaat een kringprobleem: de app heeft referenties nodig voor toegang tot Key Vault, maar u moet deze referenties veilig opslaan. Zonder een veilige oplossing kan dit probleem leiden tot vastgelegde referenties of onveilige configuraties in ontwikkelomgevingen.

  • Veilige verwerking van API-sleutels van derden

    Nadat de API-sleutel is opgehaald uit Key Vault, moet de toepassing deze gebruiken om een externe service van derden aan te roepen. Verhandel deze sleutel met extreme zorg:

    • Codeer deze nooit in broncode- of configuratiebestanden
    • Meld deze nooit aan bij stdout-, stderr- of toepassingslogboeken
    • Houd het alleen in het geheugen en open het tijdens runtime, net voordat u het gebruikt
    • Verwijder deze onmiddellijk nadat de aanvraag is voltooid

    Als u deze procedures niet volgt, wordt het risico op het lekken van referenties of niet-geautoriseerd gebruik verhoogd.

  • Azure Queue Storage-referenties beveiligen

    Voor het schrijven van berichten naar Azure Queue Storage heeft de app doorgaans een verbindingsreeks of een gedeeld toegangstoken nodig. Deze referenties:

    • Moet worden opgeslagen op een veilige locatie, zoals Key Vault
    • Mag niet worden weergegeven in logboeken, stacktraceringen of ontwikkelhulpprogramma's
    • Mag alleen worden geopend via beveiligde runtimemechanismen
    • Vraag om de juiste RBAC-configuratie indien u een beheerde identiteit gebruikt.

  • Flexibiliteit van de omgeving

    De app moet betrouwbaar worden uitgevoerd in zowel lokale ontwikkel- als cloudproductieomgevingen, met behulp van dezelfde codebasis en minimale voorwaardelijke logica.

    Deze vereiste betekent:

    • Omgevingsspecifieke geheimen niet insluiten in de code
    • Schakel niet handmatig om tussen inloggegevens of logicapaden
    • Verificatie op basis van identiteit consistent gebruiken in omgevingen

Azure-eerste verificatie met Microsoft Entra ID

Naarmate cloudtoepassingen in complexiteit schalen en integreren met meer services, wordt veilige en gestroomlijnde verificatie essentieel. Azure biedt een Azure-eerste identiteitsmodel via Microsoft Entra ID, waardoor geïntegreerd identiteitsbeheer en naadloze integratie met Azure services mogelijk is voor veilige, referentievrije verificatie.

In plaats van geheimen handmatig te beheren of referenties in te sluiten in toepassingscode, een praktijk die gevoelig is voor beveiligingsrisico's, Microsoft Entra ID apps in staat stelt veilig te verifiëren met behulp van beheerde identiteiten.

De belangrijkste voordelen van door Microsoft Entra beheerde identiteiten zijn:

  • Geen geheimen in code

    Toepassingen vereisen geen in code vastgelegde verbindingsreeksen, clientgeheimen of sleutels meer.

  • Ingebouwde identiteit voor apps

    Azure kan automatisch een beheerde identiteit toewijzen aan uw app, zodat deze veilig toegang heeft tot services zoals Key Vault, Storage en SQL zonder extra referenties.

  • Consistentie van omgeving

    Hetzelfde code- en identiteitsmodel werken zowel in lokale ontwikkeling als Azure gehoste omgevingen met behulp van de Azure SDKDefaultAzureCredential.

Omgevingsspecifieke identiteitsstroom

Toepassingen die gebruikmaken van Microsoft Entra ID voor verificatie, profiteren van een flexibel identiteitsmodel dat naadloos werkt in zowel door Azure gehoste als lokale ontwikkelomgevingen. De Azure SDK DefaultAzureCredential biedt deze consistentie door automatisch de juiste identiteitsmethode te selecteren op basis van de omgeving.

Azure-omgeving

Wanneer u de toepassing implementeert in Azure:

  • De toepassing krijgt automatisch een beheerde identiteit.
  • Azure beheert de levenscyclus van tokenuitgifte en referenties intern, zodat u geen geheimen hoeft af te handelen.
  • De toepassing krijgt toegang tot services met behulp van op rollen gebaseerde toegangscontrole (RBAC) of toegangsbeleid voor Key Vault.

Lokale ontwikkelomgeving

Tijdens lokale ontwikkeling:

  • Een service-principal fungeert als de identiteit van de app.
  • Ontwikkelaars verifiëren met behulp van de Azure CLI (az login), omgevingsvariabelen of Visual Studio/VS Code-integraties.
  • Dezelfde toepassingscode wordt uitgevoerd zonder enige wijziging: alleen de identiteitsbron verandert.

In beide omgevingen gebruikt Azure-SDK's de DefaultAzureCredential, die de identiteitsbron abstraheert en automatisch de juiste methode selecteert.

Beste praktijken voor veilige ontwikkeling

Hoewel u geheimen kunt instellen als omgevingsvariabelen (bijvoorbeeld via Azure-app Instellingen), heeft deze aanpak een nadeel:

  • U moet geheimen handmatig repliceren in lokale omgevingen.
  • Het risico bestaat dat gevoelige gegevens naar versiebeheer lekken.
  • Mogelijk hebt u extra logica nodig om onderscheid te maken tussen omgevingen.

Gebruik in plaats daarvan de volgende methode:

  • Gebruik Key Vault om API-sleutels en andere geheimen van derden op te slaan.
  • Wijs een beheerde identiteit toe aan uw geïmplementeerde app.
  • Gebruik een service-principal voor lokale ontwikkeling en wijs deze dezelfde toegangsrechten toe.
  • Gebruik DefaultAzureCredential in uw code om verificatielogica te abstraheren.
  • Vermijd het opslaan of vastleggen van referenties.

Authenticatiestroom in de praktijk

Zo werkt verificatie tijdens runtime:

  • Uw code maakt een DefaultAzureCredential exemplaar.
  • U gebruikt deze referentie om een client te instantiëren (bijvoorbeeld SecretClient, QueueServiceClient).
  • Wanneer de app een methode aanroept (bijvoorbeeld get_secret()), gebruikt de client de referentie om de aanvraag te verifiëren.
  • Azure controleert de identiteit en controleert of deze de juiste rol of het juiste beleid heeft om de bewerking uit te voeren.

Deze stroom zorgt ervoor dat uw app veilig toegang heeft tot Azure-services zonder geheimen in code of configuratiebestanden in te sluiten. Hiermee kunt u ook naadloos schakelen tussen lokale ontwikkeling en cloudimplementatie zonder uw verificatielogica te wijzigen.

deel 3: API-implementatie van derden >>>

  • Laatst bijgewerkt om