Sdílet prostřednictvím

Přístupy k architektuře pro integraci tenanta a přístup k datům

  • Článek

Systémy se běžně integrují společně, i přes hranice organizace. Při vytváření víceklientských řešení možná budete potřebovat odesílat data zpět do systémů tenantů nebo přijímat data z těchto systémů. V tomto článku popisujeme klíčové aspekty a přístupy pro navrhování a vývoj integrací pro víceklientských řešení.

Poznámka

Pokud zadáte více integračních bodů, je nejlepší zvážit každou z nich nezávisle. Různé integrační body mají často různé požadavky a jsou navrženy odlišně, i když vzájemně propojují stejné systémy různými způsoby.

Klíčové aspekty a požadavky

Směr toku dat

Je důležité porozumět směru toku dat. Směr toku dat má vliv na několik aspektů vaší architektury, jako je například správa identity a síťové topologie vašeho řešení. Existují dva běžné toky dat:

  • Export, což znamená toky dat z víceklientských systémů do systémů jednotlivých tenantů.
  • Import, což znamená, že data pocházejí ze systémů tenantů do vašeho systému s více tenanty.

Je také důležité zvážit směr toku síťových dat, který nemusí nutně odpovídat směru toku logických dat. Můžete například zahájit odchozí připojení k tenantovi, abyste mohli importovat data ze systému tenanta.

Úplný nebo uživatelem delegovaný přístup

V mnoha systémech je přístup k určitým datům omezený na konkrétní uživatele. Data, ke kterým má jeden uživatel přístup, nemusí být stejná jako data, ke kterým má přístup jiný uživatel. Je důležité zvážit, jestli očekáváte, že budete pracovat s kompletními sadami dat, nebo jestli datové sady, které importujete nebo exportujete, vycházejí z toho, k čemu má konkrétní uživatel oprávnění k přístupu.

Představte si například Microsoft Power BI, což je víceklientská služba, která poskytuje vytváření sestav a business intelligence nad úložišti dat vlastněnými zákazníky. Při konfiguraci Power BI nakonfigurujete zdroje dat tak, aby načítá data z databází, rozhraní API a dalších úložišť dat. Úložiště dat můžete nakonfigurovat dvěma různými způsoby:

  • Importujte všechna data z podkladového úložiště dat. Tento přístup vyžaduje, aby služba Power BI poskytovala přihlašovací údaje pro identitu, která má přístup k úplnému úložišti dat. Správci Power BI pak můžou po importu do Power BI samostatně nakonfigurovat oprávnění k importovaným datům. Power BI vynucuje oprávnění.
  • Naimportujte podmnožinu dat z podkladového úložiště dat na základě oprávnění uživatele. Když uživatel vytvoří zdroj dat, použije své přihlašovací údaje a přidružená oprávnění. Přesná podmnožina dat, která Power BI importuje, závisí na úrovni přístupu uživatele, který zdroj dat vytvořil.

Oba přístupy mají platné případy použití, takže je důležité jasně porozumět požadavkům vašich tenantů.

Pokud pracujete s úplnými sadami dat, zdrojový systém efektivně zachází s cílovým systémem jako s důvěryhodným subsystémem. U tohoto typu integrace byste také měli zvážit použití identity úlohy místo identity uživatele. Identita úlohy je systémová identita, která neodpovídá jednomu uživateli. Identitě úlohy je udělena vysoká úroveň oprávnění k datům ve zdrojovém systému.

Pokud pracujete s daty v oboru uživatele, možná budete muset použít přístup, jako je delegování pro přístup ke správné podmnožině dat ze sady dat. Cílový systém pak efektivně získá stejné oprávnění jako konkrétní uživatel. Další informace o delegování uživatele najdete v části Přístup k delegovanému uživateli níže. Pokud používáte delegování, zvažte, jak budete zpracovávat scénáře, kdy se uživatel zruší zřízení nebo se změní jejich oprávnění.

V reálném čase nebo v dávce

Zvažte, jestli budete pracovat s daty v reálném čase nebo jestli se budou data odesílat v dávkách.

U integrací v reálném čase jsou tyto přístupy běžné:

  • Požadavek/odpověď je místo, kde klient zahájí požadavek na server a obdrží odpověď. Integrace požadavků a odpovědí se obvykle implementují pomocí rozhraní API nebo webhooků. Požadavky můžou být synchronní, kde čekají na potvrzení a odpověď. Alternativně můžou být požadavky asynchronní, například vzor asynchronní odpovědi požadavku a odpovědi, který čeká na odpověď.
  • Volně propojená komunikace je často povolena prostřednictvím komponent zasílání zpráv, které jsou navrženy pro volně spárované systémy dohromady. Azure Service Bus například poskytuje možnosti řízení front zpráv a Azure Event Grid a Event Hubs poskytují možnosti vytváření událostí. Tyto komponenty se často používají jako součást architektur integrace.

Naproti tomu dávkové integrace se často spravují prostřednictvím úlohy na pozadí, která se může aktivovat v určitých časech dne. Dávkové integrace se obvykle provádí prostřednictvím přípravného umístění, jako je kontejner úložiště objektů blob, protože sady dat, které se vyměňují, můžou být velké.

Objem dat

Je důležité pochopit objem dat, která vyměňujete prostřednictvím integrace, protože tyto informace vám pomůžou naplánovat celkovou kapacitu systému. Při plánování kapacity systému mějte na paměti, že různí tenanti můžou mít různé objemy dat, které se mají vyměňovat.

V případě integrací v reálném čase můžete měřit objem jako počet transakcí v zadaném časovém období. U dávkových integrací můžete měřit objem buď jako počet vyměněných záznamů, nebo množství dat v bajtech.

Formáty dat

Když se data vyměňují mezi dvěma stranami, je důležité, aby oba jasně pochopili, jak budou data formátována a strukturována. Vezměte v úvahu následující části formátu dat:

  • Formát souboru, například JSON, Parquet, CSV nebo XML.
  • Schéma, například seznam polí, která budou zahrnuta, formáty kalendářních dat a možnosti null u polí.

Pokud je to možné, při práci s více tenanty je nejlepší standardizovat a používat stejný datový formát pro všechny tenanty. Díky tomu se nemusíte přizpůsobovat a znovu testovat součásti integrace pro požadavky jednotlivých tenantů. V některých situacích ale možná budete muset pro komunikaci s různými tenanty použít různé formáty dat, takže možná budete muset implementovat více integrací. V části Composable Integration Components (Kompozable Integration Components) najdete přístup, který může pomoct zjednodušit tuto situaci.

Přístup k systémům tenantů

Některé integrace vyžadují připojení k systémům nebo úložištím dat vašeho tenanta. Když se připojíte k systémům vašeho tenanta, musíte pečlivě zvážit síťové i identity komponent připojení.

Síťový přístup

Zvažte síťovou topologii pro přístup k systému vašeho tenanta, která může zahrnovat následující možnosti:

  • Připojení přes internet. Pokud se připojíte přes internet, jak bude připojení zabezpečené a jak budou data šifrovaná? Pokud vaše tenanti plánují omezení na základě vašich IP adres, ujistěte se, že služby Azure, které vaše řešení používá, můžou podporovat statické IP adresy pro odchozí připojení. Pokud je to třeba, zvažte použití služby NAT Gateway k poskytování statických IP adres.
  • Agenti, kteří jsou nasazeni do prostředí tenanta, můžou poskytovat flexibilní přístup a můžou vám pomoct vyhnout se nutnosti, aby vaši tenanti povolili příchozí připojení.
  • Přenosy, jako je Azure Relay, také poskytují přístup, aby se zabránilo příchozím připojením.

Další informace najdete v doprovodných materiálech k přístupům k sítím pro víceklientské architektury.

Authentication

Při zahájení připojení zvažte, jak se ověřuje u každého tenanta. Zvažte následující přístupy:

  • Tajné kódy, jako jsou klíče rozhraní API nebo certifikáty. Je důležité naplánovat, jak bezpečně budete spravovat přihlašovací údaje tenantů. Únik tajných kódů vašich tenantů může vést k závažnému incidentu zabezpečení, což může mít vliv na mnoho tenantů.
  • Tokeny Microsoft Entra, kde používáte token vystavený vlastní instancí Microsoft Entra tenanta. Token může být vydán přímo vaší úloze pomocí registrace víceklientských aplikací Microsoft Entra nebo konkrétního instančního objektu. Případně může vaše úloha požádat o delegovaná oprávnění pro přístup k prostředkům jménem konkrétního uživatele v adresáři tenanta.

Bez ohledu na to, jaký přístup vyberete, zajistěte, aby vaši tenanti dodržovali zásadu nejnižších oprávnění a vyhnuli se udělení nepotřebných oprávnění systému. Pokud například váš systém potřebuje jen číst data z úložiště dat tenanta, pak identita, kterou váš systém používá, by neměla mít oprávnění k zápisu.

Přístup tenantů k vašim systémům

Pokud se tenanti potřebují připojit k vašemu systému, zvažte poskytnutí vyhrazených rozhraní API nebo jiných integračních bodů, které pak můžete modelovat jako součást oblasti vašeho řešení.

V některých situacích se můžete rozhodnout poskytnout svým tenantům přímý přístup k prostředkům Azure. Pečlivě zvažte důsledky a ujistěte se, že rozumíte tomu, jak udělit přístup klientům bezpečným způsobem. Můžete například použít jeden z následujících přístupů:

  • Použijte vzor Valet Key, který zahrnuje použití bezpečnostních opatření, jako jsou sdílené přístupové podpisy k udělení omezeného přístupu k určitým prostředkům Azure.
  • Pro integrační body, jako je vyhrazený účet úložiště, použijte vyhrazené prostředky. Osvědčeným postupem je udržovat integrační prostředky oddělené od základních systémových prostředků. Tento přístup vám pomůže minimalizovat poloměr výbuchu incidentu zabezpečení. Také zajišťuje, že pokud tenant omylem zahájí velký počet připojení k prostředku a vyčerpá jeho kapacitu, zbytek systému se bude dál spouštět.

Dodržování předpisů

Když začnete pracovat přímo s daty tenantů nebo je přenášet, je důležité, abyste jasně porozuměli požadavkům na zásady správného řízení a dodržování předpisů tenantů.

Přístupy a vzory, které je potřeba zvážit

Zveřejnění rozhraní API

Integrace v reálném čase běžně zahrnují zveřejnění rozhraní API pro vaše tenanty nebo jiné strany, které se mají použít. Rozhraní API vyžadují zvláštní aspekty, zejména pokud je používají externí strany. Zvažte následující otázky:

  • Kdo je udělen přístup k rozhraní API?
  • Jak ověříte uživatele rozhraní API?
  • Je omezený počet požadavků, které může uživatel rozhraní API provést v určitém časovém období?
  • Jak poskytnete informace o rozhraních API a dokumentaci pro každé rozhraní API? Potřebujete například implementovat vývojářský portál?

Dobrým postupem je použít bránu rozhraní API, jako je Azure API Management, ke zpracování těchto problémů a mnoha dalších. Brány rozhraní API poskytují jedno místo pro implementaci zásad, které vaše rozhraní API následují, a zjednodušují implementaci systémů back-endového rozhraní API.

Model osobního klíče

V některých případech může tenant potřebovat přímý přístup ke zdroji dat, jako je Azure Storage. Zvažte použití vzoru Valet Key k bezpečnému sdílení dat a omezení přístupu k úložišti dat.

Tento přístup můžete použít například při dávkovém exportu velkého datového souboru. Po vygenerování souboru exportu ho můžete uložit do kontejneru objektů blob ve službě Azure Storage a pak vygenerovat sdílený přístupový podpis jen pro čtení s časovým limitem. Tento podpis je možné poskytnout tenantovi spolu s adresou URL objektu blob. Tenant si pak může soubor stáhnout ze služby Azure Storage, dokud nevypršela platnost podpisu.

Podobně můžete vygenerovat sdílený přístupový podpis s oprávněními k zápisu do konkrétního objektu blob. Když klientovi poskytnete sdílený přístupový podpis, může do objektu blob zapisovat data. Pomocí integrace služby Event Grid pro Azure Storage pak může být vaše aplikace upozorněna na zpracování a import datového souboru.

Webhooky

Webhooky umožňují odesílat události do vašich tenantů na adrese URL, kterou vám poskytují. Když budete mít informace k odeslání, zahájíte připojení k webhooku tenanta a zahrnete data do datové části požadavku HTTP.

Pokud se rozhodnete vytvořit vlastní systém událostí webhooku, zvažte použití standardu CloudEvents , aby se zjednodušily požadavky na integraci vašich tenantů.

Alternativně můžete k poskytování funkcí webhooku použít službu, jako je Azure Event Grid . Event Grid pracuje nativně s CloudEvents a podporuje domény událostí, které jsou užitečné pro víceklientský řešení.

Poznámka

Vždy, když provádíte odchozí připojení k systémům tenantů, nezapomeňte, že se připojujete k externímu systému. Postupujte podle doporučených cloudových postupů, včetně použití modelu Opakování, modelu Jistič a modelu Bulkhead, abyste zajistili, že se problémy v systému tenanta nerozšířují do vašeho systému.

Delegovaný přístup uživatele

Při přístupu k datům z úložišť dat tenanta zvažte, jestli pro přístup k datům potřebujete použít identitu konkrétního uživatele. Když to uděláte, integrace podléhá stejným oprávněním, jaká má uživatel. Tento přístup se často označuje jako delegovaný přístup.

Předpokládejme například, že vaše víceklientová služba spouští modely strojového učení nad daty tenantů. Potřebujete přístup k instancím služeb jednotlivých tenantů, jako jsou Azure Synapse Analytics, Azure Storage, Azure Cosmos DB a další. Každý tenant má vlastní instanci Microsoft Entra. Řešení může mít delegovaný přístup k úložišti dat, abyste mohli načíst data, ke kterým má konkrétní uživatel přístup.

Delegovaný přístup je jednodušší, pokud úložiště dat podporuje ověřování Microsoft Entra. Mnoho služeb Azure podporuje identity Microsoft Entra.

Předpokládejme například, že vaše procesy víceklientských webových aplikací a procesů na pozadí potřebují přístup ke službě Azure Storage pomocí uživatelských identit tenantů z Microsoft Entra ID. Můžete provést následující kroky:

  1. Vytvořte registraci víceklientských aplikací Microsoft Entra, která představuje vaše řešení.
  2. Udělte aplikaci delegovaná oprávnění pro přístup ke službě Azure Storage jako přihlášený uživatel.
  3. Nakonfigurujte aplikaci tak, aby ověřovali uživatele pomocí ID Microsoft Entra.

Po přihlášení uživatele Microsoft Entra ID vydá vaši aplikaci krátkodobý přístupový token, který se dá použít pro přístup ke službě Azure Storage jménem uživatele a vydá delší obnovovací token. Váš systém potřebuje bezpečně uložit obnovovací token, aby vaše procesy na pozadí mohly získat nové přístupové tokeny a mohli dál přistupovat ke službě Azure Storage jménem uživatele.

Zasílání zpráv

Zasílání zpráv umožňuje asynchronní, volně svázanou komunikaci mezi systémy nebo komponentami. Zasílání zpráv se běžně používá ve scénářích integrace k oddělení zdrojových a cílových systémů. Další informace o zasílání zpráv a víceklientské architektuře najdete v tématu Přístupy architektury pro zasílání zpráv ve víceklientských řešeních.

Pokud používáte zasílání zpráv jako součást integrace se systémy tenantů, zvažte, jestli byste měli používat sdílené přístupové podpisy pro Službu Azure Service Bus nebo Azure Event Hubs. Sdílené přístupové podpisy umožňují udělit třetím stranám omezený přístup k prostředkům zasílání zpráv, aniž byste jim umožnili přístup ke zbytku subsystému zasílání zpráv.

V některých scénářích můžete různým tenantům poskytnout různé smlouvy o úrovni služeb (SLA) nebo záruky kvality služeb (QoS). Například podmnožina vašich tenantů může očekávat, že žádosti o export dat budou zpracovávat rychleji než ostatní. Pomocí vzoru Prioritní fronta můžete vytvořit samostatné fronty pro různé úrovně priority, s různými instancemi pracovních procesů, které je odpovídajícím způsobem upřednostní.

Kompozovatelné integrační komponenty

Někdy můžete potřebovat integraci s mnoha různými tenanty, z nichž každá používá různé formáty dat nebo různé typy síťového připojení.

Běžným přístupem v integraci je sestavení a testování jednotlivých kroků, které provádějí následující typy akcí:

  • Načtěte data z úložiště dat.
  • Transformujte data do určitého formátu nebo schématu.
  • Přenášet data pomocí konkrétního síťového přenosu nebo do známého cílového typu.

Tyto jednotlivé prvky obvykle sestavíte pomocí služeb, jako jsou Azure Functions a Azure Logic Apps. Celý proces integrace pak definujete pomocí nástroje, jako je Logic Apps nebo Azure Data Factory, a vyvolá každý z předdefinovaných kroků.

Při práci se složitými scénáři integrace s více tenanty může být užitečné definovat knihovnu opakovaně použitelných kroků integrace. Pak můžete vytvářet pracovní postupy pro každého tenanta, které společně vytvoří příslušné části na základě požadavků daného tenanta. Případně můžete být schopni zveřejnit některé datové sady nebo součásti integrace přímo vašim tenantům, aby z nich mohly vytvářet vlastní pracovní postupy integrace.

Podobně může být potřeba importovat data z tenantů, kteří používají jiný formát dat nebo jiný přenos do jiných. Dobrým přístupem pro tento scénář je sestavení konektorů specifických pro tenanta. Připojení ors jsou pracovní postupy, které normalizují a importují data do standardizovaného formátu a umístění a pak aktivují váš hlavní proces sdíleného importu.

Pokud potřebujete vytvořit logiku nebo kód specifický pro tenanta, zvažte použití vzoru vrstva proti poškození. Tento model vám pomůže zapouzdřovat komponenty specifické pro tenanty a přitom zachovat zbytek vašeho řešení bez vědomí přidané složitosti.

Pokud používáte cenový model s úrovněmi, můžete se rozhodnout, že tenanti s nízkou cenovou úrovní budou postupovat podle standardního přístupu s omezenou sadou datových formátů a přenosů. Vyšší cenové úrovně můžou umožňovat větší přizpůsobení nebo flexibilitu komponent integrace, které nabízíte.

Antipatterny, aby se zabránilo

  • Zveřejnění primárních úložišť dat přímo tenantům Vyhněte se například zadávání přihlašovacích údajů k úložištím dat vašim zákazníkům a nereplikujte data z primární databáze do replik pro čtení stejného databázového systému zákazníků. Místo toho vytvořte vyhrazená úložiště dat integrace a pomocí vzoru Valet Key zpřístupňte data.
  • Vystavení rozhraní API bez brány rozhraní API Rozhraní API mají specifické obavy týkající se řízení přístupu, fakturace a měření. I když zpočátku nechcete používat zásady rozhraní API, je vhodné bránu rozhraní API zahrnout včas. Pokud tedy v budoucnu potřebujete přizpůsobit zásady rozhraní API, nemusíte provádět zásadní změny adres URL, na které závisí třetí strana.
  • Zbytečné těsné párování. Volné párování, jako je použití přístupů k zasílání zpráv , může poskytnout řadu výhod zabezpečení, izolace výkonu a odolnosti. Pokud je to možné, je vhodné volně spojit integrace se třetími stranami. Pokud potřebujete úzce párovat s třetí stranou, ujistěte se, že dodržujete osvědčené postupy, jako je model Opakování, model Jistič a vzor Bulkhead.
  • Vlastní integrace pro konkrétní tenanty Funkce nebo kód specifické pro tenanta můžou znesnadnit testování vašeho řešení. V budoucnu také znesnadňuje úpravu řešení, protože potřebujete porozumět dalším cestám kódu. Místo toho se pokuste sestavit kompozovatelné komponenty , které abstrahují požadavky pro libovolného konkrétního tenanta, a znovu je použijte ve více tenantech s podobnými požadavky.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autoři:

Další přispěvatel:

  • Will Velida | Customer Engineer 2, FastTrack for Azure

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

Projděte si přístupy k architektuře pro zasílání zpráv ve víceklientských řešeních.