Delen via

Toepassings- en toegangsbeheer

  • Artikel

In dit artikel worden overwegingen en aanbevelingen beschreven die eigenaren en ontwikkelaars van toepassingen kunnen gebruiken voor het ontwerpen van identiteits- en toegangsbeheer voor cloudtoepassingen.

Als uw team cloudtoepassingen migreert of maakt, moet u rekening houden met de verificatie- en toegangsvereisten voor de toepassingen. Deze vereisten bepalen hoe gebruikers zich verifiëren bij toepassingen en hoe toepassingsbronnen met elkaar worden geverifieerd, bijvoorbeeld wanneer een webtoepassing toegang heeft tot een SQL-database.

In het ontwerpgebied voor platformautomatisering en DevOps raden we aan dat uw toepassingsteam workloads overgaat naar abonnementsautomaat. Als onderdeel van het abonnementsverkoopproces moet uw toepassingsteam identiteits- en toegangsvereisten bieden aan het platformteam, zodat ze de juiste abonnementen kunnen maken. Toepassingseigenaren zijn verantwoordelijk voor het identiteits- en toegangsbeheer van afzonderlijke toepassingen. Ze moeten hun toepassing beheren met behulp van de gecentraliseerde services die het platformteam biedt.

Ontwerpoverwegingen

Neem de volgende overwegingen op in uw ontwerp om het risico op onbevoegde toegang tot uw toepassingen te verminderen.

  • Er zijn verschillende verificatie- en autorisatiestandaarden, zoals OAuth 2.0, OpenID Verbinding maken, JSON-webtokens (JWT's) en SAML (Security Assertion Markup Language). Bepaal welke verificatie- en autorisatiestandaarden moeten worden gebruikt voor uw toepassing.

  • Wanneer u een landingszone van een toepassing aanvraagt vanuit het platformteam, kunt u ervoor zorgen dat ze de juiste abonnementen maken door hen de volgende vragen te stellen:

    • Hoe verifiëren eindgebruikers zich voor en krijgen ze toegang tot de toepassing?

    • Wie machtigingen voor op rollen gebaseerd toegangsbeheer (RBAC) nodig heeft voor resources en services die door de toepassing worden gebruikt?

    • Hebben bestaande ingebouwde rollen betrekking op de RBAC-toegangsvereisten voor toegang tot zowel het besturingsvlak als de gegevenslaag, of moet u nieuwe aangepaste rollen maken?

    • Heeft het platformteam nalevingsbeleid geïmplementeerd dat problemen met de toepassing kan veroorzaken?

    • Welke toepassingsonderdelen moeten met elkaar communiceren?

    • Zijn er vereisten voor toegang tot de gedeelde resources, zoals Microsoft Entra Domain Services, die zijn geïmplementeerd in de landingszone van het platform?

Azure Key Vault en beheerde identiteiten

  • Beveiligingsschendingen van openbare cloudresources zijn vaak afkomstig van gelekte referenties die zijn ingesloten in code of andere tekst. U kunt beheerde identiteiten en Key Vault gebruiken om programmatische toegang te implementeren en het risico op diefstal van referenties te verminderen.

  • Als voor uw toepassing of workload een service is vereist om referenties veilig op te slaan, kunt u Key Vault gebruiken om geheimen, sleutels en certificaten te beheren.

  • Om te voorkomen dat u referenties in uw code hebt, kunt u beheerde identiteiten met Azure-VM's gebruiken om te verifiëren bij elke service die ondersteuning biedt voor Microsoft Entra ID-verificatie. Zie Beheerde identiteiten gebruiken voor Azure-resources op een VM om een toegangstoken te verkrijgen voor meer informatie.

  • Beheerde identiteiten bieden een automatisch beheerde identiteitsprincipaal die toepassingen en resources gebruiken wanneer ze verbinding maken met resources die ondersteuning bieden voor Microsoft Entra ID-verificatie. Toepassingen kunnen beheerde identiteiten gebruiken om Microsoft Entra ID-tokens te verkrijgen zonder referenties te hoeven beheren.

    • U kunt door het systeem toegewezen of door de gebruiker toegewezen beheerde identiteiten gebruiken.

    • Het is eenvoudig om te verwarren hoe service-principals en beheerde identiteiten toegang hebben tot Azure-resources. Als u het verschil tussen de twee wilt begrijpen, raadpleegt u Demystificerende service-principals: beheerde identiteiten.

    • Gebruik waar mogelijk beheerde identiteiten ter ondersteuning van verificatie in plaats van service-principals en App-registraties van Microsoft Entra ID. U moet de rollen Application Beheer istrator of Application Developer RBAC hebben om service-principals en app-registraties te maken. Deze bevoorrechte rollen worden doorgaans toegewezen aan het platformteam of identiteitsteam. Gebruik beheerde identiteiten om te voorkomen dat het platformteam service-principals en app-registraties voor uw toepassingsteam kan maken.

    • U kunt beheerde identiteiten gebruiken om te verifiëren bij elke service die ondersteuning biedt voor Microsoft Entra-verificatie. Niet alle services bieden echter ondersteuning voor beheerde identiteiten voor toegang tot andere services. Voor sommige services kan het nodig zijn om referenties op te slaan. Sla referenties veilig op, vermijd het delen van referenties met andere services en volg het principe van minimale bevoegdheden. Zie Azure-services die beheerde identiteiten kunnen gebruiken voor toegang tot andere services voor meer informatie.

    • U kunt beheerde identiteiten gebruiken met virtuele Azure-machines (VM's) om te verifiëren bij elke service die ondersteuning biedt voor Microsoft Entra ID-verificatie. Zie Beheerde identiteiten gebruiken voor Azure-resources op een VM om een toegangstoken te verkrijgen voor meer informatie.

    • Er gelden beperkingen voor het verplaatsen van resources met beheerde identiteiten tussen abonnementen en regio's. U kunt bijvoorbeeld resources verplaatsen tussen abonnementen of regio's voor een fusie, overname of repatriëring van resources om redenen van gegevenssoevereine.

      Als een Azure-resource door de gebruiker toegewezen of door het systeem toegewezen identiteiten heeft, kunt u de resource niet overdragen naar een ander Azure-abonnement of -regio. U moet de beheerde identiteiten verwijderen voordat u de resource verplaatst. Na de verplaatsing moet u de beheerde identiteiten opnieuw maken en deze toewijzen aan de resource. Zie Resources verplaatsen naar een nieuwe resourcegroep of een nieuw abonnement voor meer informatie.

    • Als u een abonnement van de ene map naar de andere verplaatst, blijven beheerde identiteiten niet behouden. U moet de resource verplaatsen en vervolgens de beheerde identiteiten handmatig opnieuw maken.

    • Net als bij RBAC-roltoewijzingen van gebruikers volgt u het principe van minimale bevoegdheden wanneer u een beheerde identiteit toegang verleent tot een resource.

Externe gebruikers

U kunt scenario's evalueren die betrekking hebben op het instellen van externe gebruikers, klanten of partners, zodat ze toegang hebben tot resources. Bepaal of deze scenario's betrekking hebben op Configuraties van Microsoft Entra B2B of Azure Active Directory B2C (Azure AD B2C ). Zie Overzicht van Microsoft Entra Externe ID voor meer informatie.

Ontwerpaanaanvelingen

Houd rekening met de volgende aanbevelingen bij het ontwerpen van het identiteits- en toegangsbeheer van uw toepassingen.

OpenID Connect

Als uw toepassingsteam pijplijnen voor continue integratie en continue levering (CI/CD) gebruikt om toepassingen programmatisch te implementeren, configureert u OpenID-Verbinding maken-verificatie voor uw Azure-services. OpenID Verbinding maken gebruikt een tijdelijk, referentievrij token om te verifiëren bij Azure-services. Zie Federatie van workloadidentiteit voor meer informatie.

Als OpenID Verbinding maken niet wordt ondersteund, maakt u een service-principal en wijst u de benodigde machtigingen toe om infrastructuur- of toepassingscode toe te staan te implementeren. Zie de trainingsmodule, Uw Azure-implementatiepijplijn verifiëren met behulp van service-principals voor meer informatie.

Toegangsbeheer op basis van kenmerken

Als u de toegang verder wilt beperken en onbevoegde toegang tot gegevens wilt voorkomen, gebruikt u ABAC (op kenmerken gebaseerd toegangsbeheer) waar dit wordt ondersteund, bijvoorbeeld met Azure Blob Storage.

Toegang tot virtuele machines

Gebruik waar mogelijk Microsoft Entra ID-identiteiten om de toegang tot virtuele Azure-machines te beheren. Gebruik Microsoft Entra-id in plaats van lokale verificatie om toegang te bieden tot virtuele machines, waarbij u profiteert van voorwaardelijke toegang van Microsoft Entra, auditlogboekregistratie en MFA (MultiFactor Authentication). Deze configuratie vermindert het risico dat aanvallers misbruik maken van onveilige lokale verificatieservices. Zie Log into a Linux virtual machine in Azure by using Microsoft Entra ID and OpenSSHand Log into a Windows virtual machine in Azure using Microsoft Entra ID including passwordless voor meer informatie.

Microsoft Identity Platform

  • Wanneer ontwikkelaars een cloudeigen toepassing bouwen, moeten ze de Microsoft identity platform voor ontwikkelaars gebruiken als id-provider voor hun toepassingen. Het Microsoft Identity Platform biedt een OpenID-Verbinding maken standaardverificatieservice die ontwikkelaars kunnen gebruiken om verschillende identiteitstypen te verifiëren, waaronder:

    • Werk- of schoolaccounts, ingericht via Microsoft Entra-id

    • Persoonlijke Microsoft-accounts (Skype, Xbox, Outlook.com)

    • Sociale of lokale accounts, met behulp van Microsoft Entra-id

  • De controlelijst voor best practices en aanbevelingen van het Microsoft Identity Platform biedt richtlijnen voor het effectief integreren van de toepassing met het Microsoft Identity Platform.

Beheerde identiteiten

  • Als u toegang wilt inschakelen tussen Azure-resources die geen referenties hoeven te gebruiken, gebruikt u beheerde identiteiten.

  • U mag geen referenties of beheerde identiteiten delen tussen verschillende omgevingen of toepassingen. Gebruik bijvoorbeeld geen identiteiten voor productiebronnen en ook in dev/test-resources, zelfs voor dezelfde toepassing. Maak afzonderlijke referenties voor elk exemplaar van een toepassing om de kans te verkleinen dat een gecompromitteerd testexemplaren van invloed zijn op productiegegevens. Afzonderlijke referenties maken het ook gemakkelijker om referenties in te trekken wanneer ze niet meer nodig zijn.

  • Wanneer er een vereiste is om beheerde identiteiten op schaal te gebruiken, gebruikt u een door de gebruiker toegewezen beheerde identiteit voor elk resourcetype in elke regio. Deze benadering voorkomt een verloop van identiteiten. Azure Monitor Agent vereist bijvoorbeeld een beheerde identiteit op bewaakte Azure-VM's, waardoor Microsoft Entra-id een aanzienlijk aantal identiteiten kan maken (en verwijderen). U kunt eenmaal door de gebruiker toegewezen beheerde identiteiten maken en deze delen op meerdere VM's. Gebruik Azure Policy om deze aanbeveling te implementeren.

Key Vault

  • U kunt Key Vault gebruiken om de geheimen, sleutels, certificaten te beheren die toepassingen gebruiken.

  • U moet afzonderlijke sleutelkluizen gebruiken voor elke toepassingsomgeving (ontwikkeling, preproductie, productie) in elke regio. Gebruik RBAC voor het beheren van toegang tot geheimen, sleutels en certificaten (gegevensvlakbewerkingen) en toegang tot Key Vault (besturingsvlak). Implementeer sleutelkluizen met toepassingsgeheimen in de landingszones van de toepassing.

Microsoft Entra-toepassingsproxy

  • Gebruik de Microsoft Entra-toepassingsproxy om toegang te krijgen tot toepassingen die gebruikmaken van on-premises verificatie op afstand via Microsoft Entra-id. Microsoft Entra-toepassingsproxy biedt veilige externe toegang tot on-premises webtoepassingen, waaronder toepassingen die gebruikmaken van oudere verificatieprotocollen. Na een eenmalige aanmelding bij Microsoft Entra ID hebben gebruikers toegang tot zowel cloudtoepassingen als on-premises toepassingen via een externe URL of een interne toepassingsportal.

    • U kunt de Microsoft Entra-toepassingsproxy implementeren als één exemplaar in een Microsoft Entra ID-tenant. Voor configuratie zijn de rollen Application Beheer istrator of Global Beheer istrator bevoegde Microsoft Entra ID-rollen vereist. Als uw organisatie gebruikmaakt van democratisering van abonnementen als roltoewijzingsmodel, hebben toepassingseigenaren mogelijk niet de benodigde machtigingen om de Microsoft Entra-toepassingsproxy te configureren. In dit geval moet het platformteam de Microsoft Entra-toepassingsproxy configureren voor de eigenaar van de toepassing.

    • Als u CI/CD-implementatiepijplijnen met voldoende machtigingen gebruikt, kunnen toepassingseigenaren microsoft Entra-toepassingsproxy configureren met behulp van de Microsoft Graph API.

  • Als de toepassing gebruikmaakt van verouderde protocollen, zoals Kerberos, moet u ervoor zorgen dat de landingszone van de toepassing netwerkconnectiviteit heeft met domeincontrollers in het Microsoft Identity Platform-abonnement.

Volgende stappen

Resourceorganisatie