Delen via

Communicatie tussen directory's implementeren in Azure

  • Artikel

Deze handleiding biedt een oplossing voor bidirectionele, veilige communicatie tussen services die worden gehost in Azure-abonnementen die door verschillende Microsoft Entra-mappen worden beheerd.

Het beveiligen van communicatie tussen mappen in Azure kan lastig zijn vanwege beperkingen die inherent zijn aan veel services. U kunt voorkomen dat u referenties rechtstreeks hoeft te beheren met behulp van door Azure beheerde identiteiten om tokens van Microsoft Entra-id te verkrijgen. Beheerde Azure-identiteiten werken echter niet over adreslijstgrenzen en het gebruikelijke alternatief is het gebruik van gedeelde geheimen, zoals SHARED Access Signature-URL's. Houd er rekening mee dat als u gedeelde geheimen gebruikt, u de geheimen veilig moet distribueren en roteren over de grenzen van Microsoft Entra-mappen.

Een optie die deze overhead vermijdt, is door een Multitenant Microsoft Entra-toepassing te maken die de identiteit van uw workload vertegenwoordigt. Via een toestemmingsproces kunt u deze workloadidentiteit bekend maken bij een externe directory en uiteindelijk toestaan dat de toepassing services in de externe directory verifieert.

Dit artikel bevat een voorbeeld van een implementatie van dit patroon dat gebruikmaakt van voorbeeldcode.

Dit patroon kan opnieuw worden gebruikt voor elk scenario met verschillende services die moeten communiceren over de grenzen van Microsoft Entra-mappen.

Architectuur

Een diagram van de architectuur voor communicatie tussen directory's.

Download een PowerPoint-bestand van deze architectuur.

Workflow

De volgende werkstroom komt overeen met het voorgaande diagram:

  1. Een beheerder aan de providerzijde maakt een multitenant Entra-toepassingsregistratie en stelt er een clientgeheim voor in.

  2. Een beheerder aan de kant van de klant configureert een serviceprincipe in de Microsoft Entra-directory. Deze service-principal is gebaseerd op de toepassingsregistratie die de provider heeft gemaakt. U kunt deze stap op meerdere manieren uitvoeren. In het voorbeeld hebben we ervoor gekozen om een URL te maken die de klantadreslijstbeheerder moet leveren, maar u kunt in plaats daarvan de Microsoft Graph API gebruiken.

  3. De klant past RBAC-rollen (op rollen gebaseerd toegangsbeheer) toe op deze nieuwe service-principal, zodat deze gemachtigd is voor toegang tot Azure Service Bus.

  4. De functie-app van de provider gebruikt de client-id en het clientgeheim van de toepassingsregistratie om een geverifieerd bericht te verzenden naar de Service Bus-wachtrij van de klant.

  5. De functie-app van de klant gebruikt een beheerde identiteit om het bericht van de provider uit de wachtrij te lezen via een Service Bus-trigger.

  6. Nadat het bericht is ontvangen, werkt de functie-app van de klant doorgaans wat voordat een statusbericht naar de provider wordt verzonden. In dit geval verzendt de functie-app voor demodoeleinden onmiddellijk een statusbericht naar de provider in een afzonderlijke wachtrij in dezelfde Service Bus.

  7. Deze functie-app leest uit de statuswachtrij uit de directory van de klant via een timer die Door Azure Functions wordt geactiveerd.

Scenariodetails

Een provider heeft meerdere klanten. De provider en elke klant hebben hun eigen afzonderlijke Microsoft Entra ID-directory en Azure-resources. De provider en elke klant hebben een veilige, bidirectionele communicatiemethode nodig, zodat ze berichten kunnen uitwisselen via Service Bus-wachtrijen. De oplossing moet een overtuigend identiteitsverhaal hebben dat het introduceren van onnodige referenties of geheimen voorkomt.

Wat u moet weten over multitenant Entra-toepassingen

  • Een toepassingsobject is een wereldwijd uniek exemplaar van de toepassing.

  • Wanneer een toepassing is geregistreerd in Microsoft Entra, worden er automatisch een toepassingsobject en een service-principalobject gemaakt in de map.

  • Er wordt een service-principal-object gemaakt in elke map die gebruikmaakt van de toepassing en verwijst naar het toepassingsobject. Een toepassingsobject heeft een een-op-veel-relatie met het bijbehorende service-principal-object.

  • Het toepassingsobject is de globale weergave van uw toepassing en wordt gebruikt in alle mappen. Het service-principal-object is de lokale weergave die wordt gebruikt in een specifieke map.

  • Er moet een service-principal-object worden gemaakt in elke map waarin de toepassing wordt gebruikt, zodat deze een identiteit kan instellen voor toegang tot resources die de directory beveiligt. Een toepassing met één map heeft slechts één service-principal-object in de basismap. Dit service-principal-object wordt gemaakt en toegestaan voor gebruik tijdens de registratie van de toepassing. Een multitenant Entra-toepassing heeft ook een service-principalobject dat in elke map is aangemaakt, en een gebruiker van die map heeft toestemming gegeven voor het gebruik.

  • Voor toegang tot resources die zijn beveiligd door een Microsoft Entra-directory, moet een beveiligingsprincipaal de entiteit vertegenwoordigen die toegang vereist.

  • Wanneer een toepassing toestemming krijgt voor toegang tot resources in een directory na registratie of toestemming, wordt er een service-principal-object gemaakt. Deze architectuur wordt geïmplementeerd met de toestemmingsstroom.

Hoe stuurt de provider de klant een bericht?

In het ideale voorbeeld kan de provider een beheerde identiteit toewijzen aan de Azure-rekenresource die verantwoordelijk is voor het verzenden van berichten naar de wachtrij van een klant. De directory van de klant is geconfigureerd voor het vertrouwen van beheerde identiteiten uit de adreslijst van de provider. Een echte federatie tussen twee Microsoft Entra-tenants, waardoor het delen van identiteiten van de ene map naar de andere mogelijk is, is momenteel niet mogelijk. De provider moet zich dus verifiëren met behulp van een identiteit die de klant herkent. De provider moet zich verifiëren bij de Microsoft Entra-tenant van de klant als een service-principal waarover de klant weet.

Het is raadzaam dat de provider een multitenant Entra-toepassing in een eigen directory registreert en dat elke klant vervolgens een gekoppelde service-principal in hun directory aanmaakt. De provider kan zich vervolgens authentiseren bij de directory van de klant en de door de klant gehoste API's met behulp van deze serviceprincipal. De provider hoeft in deze benadering nooit een clientgeheim te delen. Referentiebeheer is de enige verantwoordelijkheid van de provider.

Hoe stuurt de klant de provider bericht?

Het is raadzaam dat de klant een wachtrij maakt of host van waaruit de provider kan lezen. De klant schrijft een bericht in de wachtrij. De provider peilt herhaaldelijk elke klantwachtrij voor berichten met behulp van een service-principal-object. Het nadeel van deze aanpak is dat er pollinglatentie wordt geïntroduceerd wanneer de provider een bericht ontvangt. Code moet ook vaker worden uitgevoerd in de provider omdat deze moet worden geactiveerd en pollinglogica moet uitvoeren in plaats van te wachten tot een gebeurtenis deze activeert. Referentiebeheer blijft echter de enige verantwoordelijkheid van de provider, die de beveiliging versterkt.

Een andere mogelijke oplossing is om de provider een wachtrij te laten maken of hosten voor elk van de klanten. Elke klant maakt een eigen multitenant Entra-toepassing en vraagt de provider om deze in te richten in de directory, als een service-principal-object. De klant gebruikt dit service-principal-object vervolgens om berichten te verzenden naar een klantspecifieke wachtrij aan de providerzijde. Referentiebeheer blijft de enige verantwoordelijkheid van de klant. Een nadeel van deze aanpak is dat de provider service-principals moet inrichten die zijn gekoppeld aan klanttoepassingen in de directory. Dit proces is handmatig en providers willen waarschijnlijk niet dat handmatige stappen deel uitmaken van de stroom voor het onboarden van een nieuwe klant.

Voorbeeldcode instellen

De volgende stappen begeleiden u bij het instellen van crossdirectory-communicatie tussen een provider en klant.

Provider instellen

De installatie van de provider omvat de stappen voor het genereren en configureren van een service-principal voor de multitenant Entra-toepassing en de stappen voor het configureren van de klantenmap.

  1. Maak een door HTTP geactiveerde functie-app om een bericht te verzenden dat moet worden geschreven naar de Service Bus-opdrachtwachtrij van de klant in de directory van de klant.

  2. Maak een door tijd geactiveerde functie-app om periodiek een statuswachtrij te controleren binnen de Service Bus van de klant in de klantdirectory.

Een multitenant Entra-toepassing maken in de directory van de provider

Maak eerst een multitenant Entra-toepassing in de directory van de provider en richt die identiteit in de directory van de klant in. In dit scenario is de identiteit een service-principal. De -architectuur, eerder in dit artikel, toont hoe u een service-principal kunt configureren en toewijzen van de directory van de provider naar de directory van de klant. In de architectuur wordt ook beschreven hoe u kunt inrichten met meerdere Microsoft Entra-tenants.

  1. Kies de optie voor meerdere tenants.

  2. Voeg de volgende website toe als de omleidings-URI: https://entra.microsoft.com. U kunt deze URI aanpassen aan de behoeften van uw bedrijf.

  3. Registreer en noteer de waarde van de toepassings-id (client).

Een nieuw clientgeheim maken

  1. Nadat u de multitenant Entra-toepassing hebt gemaakt, maakt u een clientsecret voor deze service principal.

  2. Sla het gegenereerde geheim op een veilige locatie op. Het geheim en de client-id zijn uw clientreferenties die nodig zijn voor het uitwisselen van de code, in de autorisatiecodestroom en voor een id-token in de volgende stap.

Azure Functions - HTTP-geactiveerd

Gebruik de HTTP-functie om de implementatie vanuit de adreslijst van de provider te starten door een bericht te verzenden naar de Service Bus-implementatiewachtrij van de klant. We hebben de door HTTP geactiveerde functie gekozen als leveringsmethode om dit proof-of-concept te starten. De service-principal die u eerder hebt gegenereerd, fungeert als de referentie voor toegang tot de adreslijst van de klant en schrijft naar een specifieke wachtrij in Service Bus. U moet ook de installatie van de klant voltooien om deze stap goed te laten werken.

Azure Functions - Timer geactiveerd

Gebruik de door timer geactiveerde functie om de wachtrij voor de implementatiestatus te peilen vanuit de directory van de klant. We peilen elke 10 seconden de implementatiestatuswachtrij voor demodoeleinden in dit proof-of-concept. Met deze aanpak hoeft de klant geen service-principal te hebben voor toegang tot de adreslijst van de provider.

Installatie van de klant

  1. Richt de service-principal in door de opgegeven URL te wijzigen en te gebruiken.

  2. Beperk de providerservice-principal om de juiste RBAC-besturingselementen te gebruiken.

  3. Maak een door Service Bus geactiveerde functie om een bericht uit een Service Bus-berichtenwachtrij te lezen en een bericht in een andere wachtrij te plaatsen. Voor demodoeleinden is deze stroom optimaal om de functionaliteit te testen.

  4. Maak een door het systeem toegewezen beheerde identiteit voor de door Service Bus geactiveerde functie.

  5. Wijs het service bus-bereik van de door het systeem toegewezen beheerde identiteit toe.

De service-principal vanuit de directory van de provider inrichten in de directory van de klant

  1. Ga naar de volgende URL nadat u de client_id querytekenreeksparameter hebt vervangen door uw eigen client-id: https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?response_type=code&response_mode=query&scope=openid&client_id=<your_client_ID>.

    U kunt de service-principal ook inrichten in een andere Microsoft Entra-tenant met een microsoft Graph API-aanroep van een beheerder, een Azure PowerShell-opdracht of een Azure CLI-opdracht.

  2. Meld u aan met een account vanuit de adreslijst van de klant.

  3. Selecteer in het toestemmingsscherm Accepteren om de toepassing van de provider in te richten in de adreslijst van de klant. De URL wordt uiteindelijk omgeleid naar microsoft.com, wat nog steeds het gewenste effect heeft van het inrichten van de identiteit in de directory van de klant.

  4. Controleer de identiteit binnen de Microsoft Entra-tenant van de klant door naar Bedrijfstoepassingen te gaan om de zojuist ingerichte service-principal te zien.

RBAC instellen voor de ingerichte service-principal

Beperk de providerservice-principal van de instelling van de service-principal van de provider om de rollen 'Service Bus-gegevenseigenaar' in de Service Bus te hebben. Deze service-principal wordt gebruikt bij het schrijven naar een wachtrij met een door HTTP geactiveerde functie en het lezen van een wachtrij vanuit een door een timer geactiveerde functie. Zorg ervoor dat u de rol Azure Service Bus-gegevenseigenaar toevoegt aan de service-principal.

Azure Functions - Service Bus-trigger

Volg de stappen in de zelfstudie op basis van identiteiten om de functietrigger uit de Service Bus-wachtrij te definiëren en om te leren hoe u een beheerde identiteit instelt. Deze richtlijnen helpen u bij het activeren van de functie-app uit de Service Bus-wachtrij wanneer een bericht wordt toegevoegd aan de wachtrij. U gebruikt ook de beheerde identiteit wanneer u een bericht in een andere wachtrij plaatst. Voor demodoeleinden gebruiken we dezelfde functie om het bericht door te pushen.

Selecteer toegangsbeheer (IAM) in uw zojuist gemaakte Service Bus-naamruimte. U kunt bekijken en configureren wie toegang heeft tot de resource in het besturingsvlak.

De functie-app toegang verlenen tot de Service Bus-naamruimte met behulp van beheerde identiteiten

  1. Zorg ervoor dat u de rol Azure Service Bus-gegevensontvanger toevoegt aan de beheerde identiteit.

  2. Kies in de beheerde identiteitskiezer de functie-app in de categorie Door het systeem toegewezen beheerde identiteit . De labelfunctie-app heeft mogelijk een getal tussen haakjes ernaast. Dit getal geeft aan hoeveel apps met door het systeem toegewezen identiteiten zich in het abonnement bevinden.

Verbinding maken met Service Bus in uw functie-app

  1. Zoek in de portal naar uw functie-app of ga naar de app op de pagina Functie-app .

  2. Selecteer + Nieuw in de toepassingsinstellingen om een nieuwe toepassingsinstelling in de tabel te maken. Service BusConnection__fullyQualifiedNamespace <SERVICE_BUS_NAMESPACE>.Service Bus.windows.net.

Levenscyclusbeheer voor clientgeheim van service-principal

Als u geheimen in uw cross-directory-architectuur introduceert, moet u de levenscyclus van de gegenereerde clientgeheimen beheren. Zie aanbevolen procedures voor geheimenbeheer voor meer informatie over het veilig opslaan, roteren en bewaken van clientgeheimen.

Lokale instellingen

Elke submap bevat een stubbed versie van de local.settings.json bestanden, die kan worden gewijzigd om de Azure-functies lokaal uit te voeren. Werk de toepassingsinstellingen bij om instellingen in Azure te configureren.

Met DefaultAzureCredential de opdracht worden meerdere instellingen opgesomd voordat de Azure CLI-referentie wordt bereikt. Om verwarring te voorkomen, raden we u aan om de az login -t <tenant ID> opdracht uit te voeren om de juiste referenties te selecteren wanneer u lokale functies ontwikkelt.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

Volgende stappen