Architectuurbenaderingen voor tenantintegratie en gegevenstoegang

Het is gebruikelijk dat systemen samen kunnen worden geïntegreerd, zelfs binnen de grenzen van de organisatie. Wanneer u een multitenant-oplossing bouwt, hebt u mogelijk vereisten om gegevens terug te sturen naar de systemen van uw tenants of om gegevens van die systemen te ontvangen. In dit artikel beschrijven we de belangrijkste overwegingen en benaderingen voor het ontwerpen en ontwikkelen van integraties voor een multitenant-oplossing.

Notitie

Als u meerdere integratiepunten opgeeft, kunt u deze het beste afzonderlijk overwegen. Vaak hebben verschillende integratiepunten verschillende vereisten en zijn ze anders ontworpen, zelfs als ze op verschillende manieren dezelfde systemen met elkaar verbinden.

Belangrijke overwegingen en vereisten

Richting van gegevensstroom

Het is belangrijk om inzicht te hebben in de richting waarin uw gegevens stromen. De richting van de gegevensstroom is van invloed op verschillende aspecten van uw architectuur, zoals hoe u identiteit en de netwerktopologie van uw oplossing beheert. Er zijn twee algemene gegevensstromen:

• Exporteren, wat betekent dat de gegevens stromen van uw multitenant-systeem naar de systemen van uw afzonderlijke tenants.
• Importeren, wat betekent dat gegevens afkomstig zijn van de systemen van uw tenants in uw multitenant-systeem.

Het is ook belangrijk om rekening te houden met de richting van de netwerkgegevensstroom, die niet noodzakelijkerwijs overeenkomt met de richting van de logische gegevensstroom. U kunt bijvoorbeeld een uitgaande verbinding met een tenant initiëren, zodat u de gegevens uit het systeem van de tenant kunt importeren.

Volledige of door de gebruiker gedelegeerde toegang

In veel systemen is de toegang tot bepaalde gegevens beperkt tot specifieke gebruikers. De gegevens waartoe een gebruiker toegang heeft, zijn mogelijk niet hetzelfde als de gegevens waartoe een andere gebruiker toegang heeft. Het is belangrijk om na te gaan of u verwacht te werken met volledige gegevenssets of dat de gegevenssets die u importeert of exporteert, zijn gebaseerd op waartoe een specifieke gebruiker toegangsmachtigingen heeft.

Denk bijvoorbeeld aan Microsoft Power BI, een multitenant-service die rapportage en bedrijfsinformatie biedt boven op gegevensarchieven die eigendom zijn van de klant. Wanneer u Power BI configureert, configureert u gegevensbronnen om gegevens op te halen uit databases, API's en andere gegevensarchieven. U kunt gegevensarchieven op twee verschillende manieren configureren:

• Importeer alle gegevens uit het onderliggende gegevensarchief. Voor deze aanpak is vereist dat Power BI referenties krijgt voor een identiteit die toegang heeft tot het volledige gegevensarchief. Vervolgens kunnen Power BI-beheerders machtigingen voor de geïmporteerde gegevens afzonderlijk configureren nadat ze zijn geïmporteerd in Power BI. Power BI dwingt de machtigingen af.
• Importeer een subset met gegevens uit het onderliggende gegevensarchief op basis van de machtigingen van een gebruiker. Wanneer een gebruiker de gegevensbron maakt, gebruiken ze hun referenties en de bijbehorende machtigingen. De exacte subset van gegevens die door Power BI worden geïmporteerd, is afhankelijk van het toegangsniveau van de gebruiker die de gegevensbron heeft gemaakt.

Beide benaderingen hebben geldige use cases, dus het is belangrijk om de vereisten van uw tenants duidelijk te begrijpen.

Als u met volledige gegevenssets werkt, behandelt het bronsysteem het doelsysteem effectief als een vertrouwd subsysteem. Voor dit type integratie moet u ook overwegen om een workloadidentiteit te gebruiken in plaats van een gebruikersidentiteit. Een workloadidentiteit is een systeemidentiteit die niet overeenkomt met één gebruiker. De workloadidentiteit krijgt een hoog machtigingsniveau voor de gegevens in het bronsysteem.

Als u met gegevens binnen het gebruikersbereik werkt, moet u mogelijk een benadering zoals delegering gebruiken om toegang te krijgen tot de juiste subset van gegevens uit de gegevensset. Vervolgens krijgt het doelsysteem in feite dezelfde machtiging als een specifieke gebruiker. Zie de benadering gedelegeerde gebruikerstoegang hieronder voor meer informatie over gebruikersdelegering . Als u delegatie gebruikt, kunt u overwegen hoe u scenario's afhandelt waarin een gebruiker de inrichting ongedaan maakt of de bijbehorende machtigingen worden gewijzigd.

Realtime of batch

Overweeg of u met realtime gegevens werkt of dat de gegevens in batches worden verzonden.

Voor realtime-integraties zijn deze benaderingen gebruikelijk:

• Aanvraag/antwoord is de plaats waar een client een aanvraag naar een server initieert en een antwoord ontvangt. Aanvraag-/antwoordintegraties worden doorgaans geïmplementeerd met behulp van API's of webhooks. Aanvragen kunnen synchroon zijn, waarbij ze wachten op bevestiging en een antwoord. Aanvragen kunnen ook asynchroon zijn, met behulp van bijvoorbeeld het Asynchrone aanvraagantwoordpatroon om te wachten op een antwoord.
• Losjes gekoppelde communicatie wordt vaak ingeschakeld via berichtenonderdelen die zijn ontworpen voor losjes koppelen van systemen. Azure Service Bus biedt bijvoorbeeld mogelijkheden voor berichtenwachtrijen en Azure Event Grid en Event Hubs bieden mogelijkheden voor gebeurtenisverwerking. Deze onderdelen worden vaak gebruikt als onderdeel van integratiearchitecturen.

Batchintegraties worden daarentegen vaak beheerd via een achtergrondtaak, die op bepaalde tijdstippen van de dag kan worden geactiveerd. Batchintegraties vinden meestal plaats via een faseringslocatie, zoals een blobopslagcontainer, omdat de uitgewisselde gegevenssets groot kunnen zijn.

Gegevensvolume

Het is belangrijk om inzicht te hebben in het volume aan gegevens dat u via een integratie uitwisselt, omdat deze informatie u helpt bij het plannen van uw totale systeemcapaciteit. Wanneer u de capaciteit van uw systeem plant, moet u er rekening mee houden dat verschillende tenants mogelijk verschillende gegevensvolumes hebben die moeten worden uitgewisseld.

Voor realtime-integraties kunt u het volume meten als het aantal transacties gedurende een opgegeven periode. Voor batchintegraties kunt u het volume meten als het aantal uitgewisselde records of de hoeveelheid gegevens in bytes.

Bestandsindelingen

Wanneer gegevens tussen twee partijen worden uitgewisseld, is het belangrijk dat ze beide een duidelijk beeld hebben van hoe de gegevens worden opgemaakt en gestructureerd. Houd rekening met de volgende onderdelen van de gegevensindeling:

• De bestandsindeling, zoals JSON, Parquet, CSV of XML.
• Het schema, zoals de lijst met velden die worden opgenomen, datumnotaties en null-baarheid van velden.

Wanneer u werkt met een multitenant-systeem, indien mogelijk, kunt u het beste dezelfde gegevensindeling voor al uw tenants standaardiseren en gebruiken. Op die manier hoeft u uw integratieonderdelen niet aan te passen en opnieuw te testen voor de vereisten van elke tenant. In sommige situaties moet u echter mogelijk verschillende gegevensindelingen gebruiken om te communiceren met verschillende tenants, en moet u mogelijk meerdere integraties implementeren. Zie de sectie Composable Integration Components voor een aanpak die kan helpen om dit soort situaties te vereenvoudigen.

Toegang tot de systemen van tenants

Voor sommige integraties moet u verbinding maken met de systemen of gegevensarchieven van uw tenant. Wanneer u verbinding maakt met de systemen van uw tenant, moet u zorgvuldig rekening houden met de netwerk- en identiteitsonderdelen van de verbinding.

Netwerktoegang

Overweeg de netwerktopologie voor toegang tot het systeem van uw tenant, waaronder de volgende opties:

• Maak verbinding via internet. Als u via internet verbinding maakt, hoe wordt de verbinding beveiligd en hoe worden de gegevens versleuteld? Als uw tenants van plan zijn om te beperken op basis van uw IP-adressen, moet u ervoor zorgen dat de Azure-services die door uw oplossing worden gebruikt, statische IP-adressen voor uitgaande verbindingen kunnen ondersteunen. U kunt bijvoorbeeld nat-gateway gebruiken om zo nodig statische IP-adressen op te geven. Als u een VPN nodig hebt, kunt u overwegen om sleutels veilig uit te wisselen met uw tenants.
• Agents, die zijn geïmplementeerd in de omgeving van een tenant, kunnen een flexibele benadering bieden en kunnen u helpen voorkomen dat uw tenants binnenkomende verbindingen toestaan.
• Relays, zoals Azure Relay, bieden ook een benadering om binnenkomende verbindingen te voorkomen.

Zie de richtlijnen voor netwerkmethoden voor multitenancy voor meer informatie.

Verificatie

Overweeg hoe u zich bij elke tenant verifieert wanneer u een verbinding initieert. Houd rekening met de volgende benaderingen:

• Geheimen, zoals API-sleutels of certificaten. Het is belangrijk om te plannen hoe u de referenties van uw tenants veilig beheert. Het lekken van de geheimen van uw tenants kan leiden tot een groot beveiligingsincident, mogelijk van invloed op veel tenants.
• Microsoft Entra-tokens, waarbij u een token gebruikt dat is uitgegeven door de eigen Microsoft Entra-directory van de tenant. Het token kan rechtstreeks aan uw workload worden uitgegeven met behulp van een registratie van een Microsoft Entra-toepassing met meerdere tenants of een specifieke service-principal. U kunt ook gedelegeerde machtigingen aanvragen voor toegang tot resources namens een specifieke gebruiker in de directory van de tenant.

Ongeacht welke benadering u selecteert, moet u ervoor zorgen dat uw tenants het principe van minimale bevoegdheden volgen en voorkomen dat u uw systeem onnodige machtigingen verleent. Als uw systeem bijvoorbeeld alleen gegevens hoeft te lezen uit het gegevensarchief van een tenant, mag de identiteit die uw systeem gebruikt geen schrijfmachtigingen hebben.

Toegang van tenants tot uw systemen

Als tenants verbinding moeten maken met uw systeem, kunt u overwegen om toegewezen API's of andere integratiepunten op te geven, die u vervolgens kunt modelleren als onderdeel van het oppervlak van uw oplossing.

In sommige situaties kunt u besluiten om uw tenants directe toegang te geven tot uw Azure-resources. Houd rekening met de gevolgen zorgvuldig en zorg ervoor dat u begrijpt hoe u op een veilige manier toegang verleent aan tenants. U kunt bijvoorbeeld een van de volgende methoden gebruiken:

• Gebruik het valetsleutelpatroon, waarbij beveiligingsmaatregelen, zoals handtekeningen voor gedeelde toegang, worden gebruikt om beperkte toegang te verlenen tot bepaalde Azure-resources.
• Gebruik toegewezen resources voor integratiepunten, zoals een toegewezen opslagaccount. Het is een goede gewoonte om integratieresources gescheiden te houden van uw kernsysteemresources. Deze aanpak helpt u om de straalstraal van een beveiligingsincident te minimaliseren. Het zorgt er ook voor dat, als een tenant per ongeluk grote aantallen verbindingen met de resource initieert en de capaciteit ervan uitput, de rest van uw systeem blijft worden uitgevoerd.

Naleving

Wanneer u rechtstreeks met de gegevens van uw tenants begint te communiceren of die gegevens verzendt, is het essentieel dat u een duidelijk inzicht hebt in de governance- en nalevingsvereisten van uw tenants.

Benaderingen en patronen om rekening mee te houden

API's beschikbaar maken

Realtime-integraties omvatten vaak het beschikbaar maken van API's aan uw tenants of andere partijen die u wilt gebruiken. API's vereisen speciale overwegingen, met name bij gebruik door externe partijen. Denk na over de volgende vragen:

• Wie krijgt toegang tot de API?
• Hoe verifieert u de gebruikers van de API?
• Is er een limiet voor het aantal aanvragen dat een API-gebruiker gedurende een bepaalde periode kan doen?
• Hoe geeft u informatie over uw API's en documentatie voor elke API? Moet u bijvoorbeeld een ontwikkelaarsportal implementeren?

Een goede gewoonte is om een API-gateway, zoals Azure API Management, te gebruiken voor het afhandelen van deze problemen en vele andere. API-gateways bieden u één plaats om beleidsregels te implementeren die door uw API's worden gevolgd en ze vereenvoudigen de implementatie van uw back-end-API-systemen. Zie Azure API Management gebruiken in een multitenant-oplossing voor meer informatie over hoe API Management ondersteuning biedt voor multitenant-architectuur.

Valetsleutelpatroon

Af en toe heeft een tenant mogelijk directe toegang nodig tot een gegevensbron, zoals Azure Storage. Overweeg het patroon Valet Key te volgen om gegevens veilig te delen en de toegang tot het gegevensarchief te beperken.

U kunt deze methode bijvoorbeeld gebruiken bij het batchgewijs exporteren van een groot gegevensbestand. Nadat u het exportbestand hebt gegenereerd, kunt u het opslaan in een blobcontainer in Azure Storage en vervolgens een tijdgebonden, alleen-lezen handtekening voor gedeelde toegang genereren. Deze handtekening kan worden verstrekt aan de tenant, samen met de blob-URL. De tenant kan het bestand vervolgens downloaden van Azure Storage totdat de handtekening is verlopen.

Op dezelfde manier kunt u een handtekening voor gedeelde toegang genereren met machtigingen om naar een specifieke blob te schrijven. Wanneer u een handtekening voor gedeelde toegang aan een tenant opgeeft, kunnen ze hun gegevens naar de blob schrijven. Door Event Grid-integratie voor Azure Storage te gebruiken, kan uw toepassing vervolgens een melding ontvangen om het gegevensbestand te verwerken en te importeren.

Webhooks

Met Webhooks kunt u gebeurtenissen naar uw tenants verzenden op een URL die ze aan u verstrekken. Wanneer u informatie hebt om te verzenden, start u een verbinding met de webhook van de tenant en neemt u uw gegevens op in de nettolading van de HTTP-aanvraag.

Als u ervoor kiest om uw eigen webhook-gebeurtenissysteem te bouwen, kunt u overwegen de CloudEvents-standaard te volgen om de integratievereisten van uw tenants te vereenvoudigen.

U kunt ook een service zoals Azure Event Grid gebruiken om webhookfunctionaliteit te bieden. Event Grid werkt systeemeigen met CloudEvents en ondersteunt gebeurtenisdomeinen, die handig zijn voor multitenant-oplossingen.

Notitie

Wanneer u uitgaande verbindingen maakt met de systemen van uw tenants, moet u er rekening mee houden dat u verbinding maakt met een extern systeem. Volg aanbevolen cloudprocedures, waaronder het patroon Opnieuw proberen, het circuitonderbrekerpatroon en het schotkoppatroon om ervoor te zorgen dat problemen in het systeem van de tenant niet worden doorgegeven aan uw systeem.

Gedelegeerde gebruikerstoegang

Wanneer u toegang krijgt tot gegevens uit de gegevensarchieven van een tenant, moet u overwegen of u de identiteit van een specifieke gebruiker moet gebruiken om toegang te krijgen tot de gegevens. Wanneer u dit doet, is uw integratie onderworpen aan dezelfde machtigingen die de gebruiker heeft. Deze benadering wordt vaak gedelegeerde toegang genoemd.

Stel dat uw multitenant-service machine learning-modellen uitvoert op de gegevens van uw tenants. U moet toegang krijgen tot de exemplaren van services van elke tenant, zoals Azure Synapse Analytics, Azure Storage, Azure Cosmos DB en andere. Elke tenant heeft een eigen Microsoft Entra-map. Uw oplossing kan gedelegeerde toegang krijgen tot het gegevensarchief, zodat u de gegevens kunt ophalen waartoe een specifieke gebruiker toegang heeft.

Gedelegeerde toegang is eenvoudiger als het gegevensarchief ondersteuning biedt voor Microsoft Entra-verificatie. Veel Azure-services ondersteunen Microsoft Entra-identiteiten.

Stel dat uw multitenant-webtoepassing en achtergrondprocessen toegang moeten hebben tot Azure Storage met behulp van de gebruikersidentiteiten van uw tenants van Microsoft Entra ID. U kunt de volgende stappen uitvoeren:

1. Maak een multitenant Microsoft Entra-toepassingsregistratie die uw oplossing vertegenwoordigt.
2. Verdeel de gedelegeerde machtiging voor de toepassing om toegang te krijgen tot Azure Storage als de aangemelde gebruiker.
3. Configureer uw toepassing om gebruikers te verifiëren met behulp van Microsoft Entra-id.

Nadat een gebruiker zich heeft aangemeld, geeft Microsoft Entra ID uw toepassing een kortstondige toegangstoken uit dat kan worden gebruikt voor toegang tot Azure Storage namens de gebruiker en geeft het een vernieuwingstoken met een langere levensduur uit. Uw systeem moet het vernieuwingstoken veilig opslaan, zodat uw achtergrondprocessen nieuwe toegangstokens kunnen verkrijgen en namens de gebruiker toegang kunnen blijven krijgen tot Azure Storage.

Berichten

Berichten maken asynchrone, losjes gekoppelde communicatie tussen systemen of onderdelen mogelijk. Berichten worden vaak gebruikt in integratiescenario's om de bron- en doelsystemen los te koppelen. Zie Architectuurmethoden voor berichten in multitenant-oplossingen voor meer informatie over berichten en multitenancy.

Wanneer u berichten gebruikt als onderdeel van een integratie met de systemen van uw tenants, moet u overwegen of u handtekeningen voor gedeelde toegang moet gebruiken voor Azure Service Bus of Azure Event Hubs. Met handtekeningen voor gedeelde toegang kunt u beperkte toegang verlenen tot uw berichtenresources aan derden, zonder dat ze toegang hebben tot de rest van uw berichtensubsysteem.

In sommige scenario's kunt u verschillende serviceovereenkomsten (SLA's) of QoS-garanties (Quality of Service) bieden voor verschillende tenants. Een subset van uw tenants kan bijvoorbeeld verwachten dat hun aanvragen voor gegevensexport sneller worden verwerkt dan andere. Met behulp van het patroon Priority Queue kunt u afzonderlijke wachtrijen maken voor verschillende prioriteitsniveaus, met verschillende werkrolexemplaren om ze dienovereenkomstig te prioriteren.

Composeerbare integratieonderdelen

Soms moet u mogelijk integreren met veel verschillende tenants, die elk verschillende gegevensindelingen of verschillende typen netwerkconnectiviteit gebruiken.

Een algemene integratiebenadering is het bouwen en testen van afzonderlijke stappen die de volgende typen acties uitvoeren:

• Gegevens ophalen uit een gegevensarchief.
• Gegevens transformeren naar een specifieke indeling of een specifiek schema.
• Verzend de gegevens met behulp van een bepaald netwerktransport of naar een bekend doeltype.

Normaal gesproken bouwt u deze afzonderlijke elementen met behulp van services zoals Azure Functions en Azure Logic Apps. Vervolgens definieert u het algehele integratieproces met behulp van een hulpprogramma zoals Logic Apps of Azure Data Factory en roept elk van de vooraf gedefinieerde stappen aan.

Wanneer u met complexe multitenant-integratiescenario's werkt, kan het handig zijn om een bibliotheek met herbruikbare integratiestappen te definiëren. Vervolgens kunt u werkstromen bouwen voor elke tenant om de toepasselijke onderdelen samen te stellen op basis van de vereisten van die tenant. U kunt ook mogelijk enkele gegevenssets of integratieonderdelen rechtstreeks beschikbaar maken voor uw tenants, zodat ze hun eigen integratiewerkstromen van hen kunnen bouwen.

Op dezelfde manier moet u mogelijk gegevens importeren uit tenants die een andere gegevensindeling of een ander transport naar anderen gebruiken. Een goede benadering voor dit scenario is het bouwen van tenantspecifieke connectors. Connectors zijn werkstromen die de gegevens normaliseren en importeren in een gestandaardiseerde indeling en locatie, en vervolgens activeren ze uw belangrijkste gedeelde importproces.

Als u tenantspecifieke logica of code moet bouwen, kunt u overwegen het patroon Anti-corruptielaag te volgen. Het patroon helpt u bij het inkapselen van tenantspecifieke onderdelen, terwijl de rest van uw oplossing niet weet wat de toegevoegde complexiteit is.

Als u een gelaagd prijsmodel gebruikt, kunt u ervoor kiezen om te vereisen dat tenants met een lage prijscategorie een standaardbenadering volgen met een beperkte set gegevensindelingen en transporten. Hogere prijscategorieën kunnen meer aanpassingen of flexibiliteit mogelijk maken in de integratieonderdelen die u aanbiedt.

Antipatroon om te voorkomen

• Uw primaire gegevensarchieven rechtstreeks beschikbaar maken voor tenants. Wanneer tenants toegang hebben tot uw primaire gegevensarchieven, kan het moeilijker worden om deze gegevensarchieven te beveiligen en kunnen ze per ongeluk prestatieproblemen veroorzaken die van invloed zijn op uw oplossing. Vermijd het opgeven van referenties voor uw gegevensarchieven aan uw klanten en repliceer geen gegevens rechtstreeks van uw primaire database naar leesreplica's van hetzelfde databasesysteem van klanten. Maak in plaats daarvan toegewezen integratiegegevensarchieven en gebruik het patroon ValetSleutel om de gegevens beschikbaar te maken.
• API's beschikbaar maken zonder een API-gateway. API's hebben specifieke problemen voor toegangsbeheer, facturering en meting. Zelfs als u in eerste instantie geen API-beleid wilt gebruiken, is het een goed idee om een API-gateway vroeg op te nemen. Op die manier hoeft u uw API-beleid in de toekomst niet aan te passen, hoeft u geen wijzigingen aan te brengen die fouten veroorzaken in de URL's waarop een derde partij afhankelijk is.
• Onnodig strakke koppeling. Losse koppeling, zoals door middel van berichtmethoden , kan een scala aan voordelen bieden voor beveiliging, prestatieisolatie en tolerantie. Indien mogelijk is het een goed idee om uw integraties losjes te koppelen aan derden. Als u nauw moet koppelen aan een derde partij, moet u ervoor zorgen dat u goede procedures volgt, zoals het patroon Opnieuw proberen, het patroon Circuitonderbreker en het patroon Bulkhead.
• Aangepaste integraties voor specifieke tenants. Tenantspecifieke functies of code kunnen uw oplossing moeilijker testen. Het maakt het ook moeilijker om uw oplossing in de toekomst te wijzigen, omdat u meer codepaden moet begrijpen. Probeer in plaats daarvan samenstelbare onderdelen te bouwen die de vereisten voor een specifieke tenant abstraheren en opnieuw gebruiken voor meerdere tenants met vergelijkbare vereisten.

Medewerkers

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

Belangrijkste auteurs:

• John Downs | Principal Software Engineer
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack voor Azure

Andere inzender:

• Will Velida | Customer Engineer 2, FastTrack voor Azure

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

Bekijk de architectuurbenaderingen voor berichten in oplossingen met meerdere tenants.