Abordagens de arquitetura para integração de locatário e acesso a dados

É comum que os sistemas se integrem, mesmo entre limites organizacionais. Ao criar uma solução multilocatário, você pode ter requisitos para enviar dados de volta aos sistemas de seus locatários ou receber dados desses sistemas. Este artigo descreve as principais considerações e abordagens para arquitetar e desenvolver integrações para uma solução multilocatário.

Considerações e requisitos

Direção do fluxo de dados

É importante entender a direção dos fluxos de dados. A direção do fluxo de dados afeta vários aspectos da arquitetura, como a forma como você gerencia a identidade e a topologia de rede da sua solução. Há dois fluxos de dados comuns:

• Exportar, significa que os dados fluem do sistema multilocatário para os sistemas de seus locatários individuais.

• Importar, significa que os dados são fornecidos dos sistemas de locatários para o sistema multilocatário.

Também é importante considerar a direção do fluxo de dados de rede, que não corresponde necessariamente à direção lógica do fluxo de dados. Por exemplo, você pode iniciar uma conexão de saída com um locatário para que possa importar os dados do sistema do locatário.

Acesso completo ou acesso delegado pelo usuário

Em muitos sistemas, o acesso a dados específicos é restrito a usuários individuais. Os dados acessados por um usuário podem diferir do que outro usuário acessa. É importante considerar se você trabalha com conjuntos de dados completos ou se os dados importados ou exportados dependem das permissões de acesso de cada usuário.

Por exemplo, o Power BI é um serviço multilocatário que fornece relatórios e inteligência empresarial sobre armazenamentos de dados de propriedade do cliente. Ao configurar o Power BI, você configura fontes de dados para extrair dados de bancos de dados, APIs e outros armazenamentos de dados. Você pode configurar armazenamentos de dados de duas maneiras:

• Importe todos os dados do armazenamento de dados subjacente. Essa abordagem requer que o Power BI receba credenciais para uma identidade que tenha permissões para o armazenamento de dados completo. Depois de importar os dados, os administradores do Power BI configuram as permissões de forma independente. O Power BI impõe essas permissões.

• Importar um subconjunto de dados do armazenamento de dados subjacente, com base nas permissões de um usuário. Quando um usuário cria uma fonte de dados, ele usa suas credenciais e permissões associadas. O subconjunto exato de dados importados pelo Power BI depende do nível de acesso do usuário que cria a fonte de dados.

As duas abordagens têm casos de uso válidos, por isso é importante entender claramente os requisitos de seus locatários.

Se você trabalhar com conjuntos de dados completos, o sistema de origem tratará efetivamente o sistema de destino como um subsistema confiável. Para esse tipo de integração, você também deve considerar usar uma identidade de carga de trabalho, em vez de uma identidade de usuário. Uma identidade de carga de trabalho é uma identidade de sistema que não corresponde a um único usuário. A identidade de carga de trabalho recebe um alto nível de permissão para os dados no sistema de origem.

Como alternativa, se você trabalhar com dados no escopo do usuário, talvez seja necessário usar uma abordagem como delegação para acessar o subconjunto correto de dados do conjunto de dados. Em seguida, o sistema de destino efetivamente obtém a mesma permissão que um usuário específico. Para obter mais informações, consulte Acesso de usuário delegado. Se você usar a delegação, considere como lidar com cenários em que um usuário é desprovisionado ou suas permissões são alteradas.

Integrações em tempo real ou integrações em lote

Considere se você planeja usar dados em tempo real ou enviar os dados em lotes.

Para integrações em tempo real, as seguintes abordagens são comuns:

• Solicitação-resposta é onde um cliente inicia uma solicitação para um servidor e recebe uma resposta. Normalmente, as integrações solicitação-resposta são implementadas usando APIs ou webhooks. As solicitações podem ser síncronas, quando aguardam confirmação e resposta. Como alternativa, as solicitações podem ser assíncronas e usar algo como o padrão de Request-Reply assíncrono para aguardar uma resposta.

• Comunicação fracamente acoplada geralmente é habilitada por meio de componentes de mensagens projetados para acoplar sistemas fracamente. Por exemplo, o Barramento de Serviço do Azure fornece recursos de enfileiramento de mensagens, e a Grade de Eventos do Azure e os Hubs de Eventos do Azure fornecem recursos de eventos. Esses componentes são frequentemente usados como parte de arquiteturas de integração.

Por outro lado, as integrações em lotes geralmente são gerenciadas por meio de um processo em segundo plano, que pode ser ativado em horários específicos do dia. As integrações em lote geralmente ocorrem por meio de um local de preparo , como um contêiner de armazenamento de blobs, porque os conjuntos de dados trocados podem ser grandes.

Volume de dados

É importante entender o volume de dados que você troca por meio de uma integração, pois essas informações ajudam você a planejar sua capacidade geral do sistema. Ao planejar a capacidade do sistema, lembre-se de que diferentes locatários podem ter volumes diferentes de dados para trocar.

Para integrações em tempo real, você pode medir o volume como o número de transações durante um período de tempo especificado. Para integrações em lote, você pode medir o volume como o número de registros trocados ou a quantidade de dados em bytes.

Formatos de dados

Quando os dados são trocados entre duas partes, é importante que ambos entendam claramente o formato e a estrutura dos dados. Considere as seguintes partes do formato de dados:

• O formato do arquivo, como JSON, Parquet, CSV ou XML

• O esquema, como a lista de campos incluídos, formatos de data e a possibilidade de campos serem nulos

Quando você trabalha com um sistema multilocatário, se possível, padroniza e usa o mesmo formato de dados para todos os seus locatários. Essa abordagem ajuda você a evitar a necessidade de personalizar e retestar seus componentes de integração para os requisitos de cada inquilino. No entanto, alguns cenários exigem formatos de dados diferentes para se comunicar com locatários diferentes, portanto, talvez seja necessário implementar várias integrações. Para obter uma abordagem que possa ajudar a simplificar esse tipo de cenário, confira Componentes de integração combináveis.

Acesso aos sistemas dos locatários

Algumas integrações requerem que você estabeleça uma conexão com os sistemas ou armazenamentos de dados do locatário. Ao se conectar aos sistemas do locatário, você precisará considerar com cautela os componentes de rede e identidade da conexão.

Acesso de rede

Considere a topologia de rede para acessar o sistema do locatário, que pode incluir as seguintes opções:

• As conexões de Internet podem levantar preocupações sobre como proteger a conexão e criptografar os dados. Determine como proteger a conexão e criptografar os dados quando você se conectar pela Internet. Se seus locatários planejam restringir o acesso com base em seus endereços IP, verifique se os serviços do Azure que sua solução usa podem dar suporte a endereços IP estáticos para conexões de saída. Por exemplo, considere usar o Gateway nat do Azure para fornecer endereços IP estáticos, se necessário. Se você precisar de uma VPN, considere como trocar chaves de forma segura com seus locatários.

• Os agentes, que são implantados no ambiente de um locatário, podem fornecer uma abordagem flexível. Os agentes também podem ajudá-lo a evitar a necessidade de que seus inquilinos permitam conexões de entrada.

• Retransmissões, como a Retransmissão do Azure, também fornecem uma abordagem para evitar conexões de entrada.

Para obter mais informações, consulte Abordagens de rede para multilocação.

Autenticação

Considere como você se autentica com cada locatário ao iniciar uma conexão. Considere as seguintes abordagens:

• Segredos, como chaves de API ou certificados. É importante planejar como gerenciar com segurança as credenciais de seus locatários. O vazamento de segredos de seus locatários pode resultar em um grande incidente de segurança, que pode afetar muitos locatários.

• Tokens do Microsoft Entra, onde você usa um token emitido pelo diretório Microsoft Entra do locatário. O token pode ser emitido diretamente para sua carga de trabalho usando um registro do aplicativo Microsoft Entra multilocatário ou uma entidade de serviço específica. Como alternativa, sua carga de trabalho pode solicitar permissão delegada para acessar recursos em nome de um usuário específico no diretório do locatário.

Seja qual for a abordagem selecionada, verifique se os locatários seguem o princípio do privilégio mínimo e não concedam permissões desnecessárias ao sistema. Por exemplo, se o sistema precisar ler apenas dados do armazenamento de dados de um locatário, a identidade usada pelo sistema não deverá ter permissões de gravação.

Acesso dos locatários aos seus sistemas

Se os locatários precisarem se conectar ao seu sistema, considere fornecer APIs dedicadas ou outros pontos de integração. Em seguida, você pode modelar esses pontos de integração como parte da área de superfície da solução.

Em alguns cenários, você pode decidir fornecer aos seus locatários acesso direto aos recursos do Azure. Considere as ramificações com cuidado e verifique se você entende como conceder acesso aos locatários de maneira segura. Por exemplo, você pode usar uma das seguintes abordagens:

• Use o padrão Valet Key, que usa medidas de segurança como tokens SAS (assinaturas de acesso compartilhado) para conceder acesso restrito a recursos específicos do Azure.

• Use recursos dedicados para pontos de integração, como uma conta de armazenamento dedicada. É uma boa prática manter os recursos de integração separados dos recursos principais do sistema. Essa abordagem ajuda você a minimizar o raio de explosão de um incidente de segurança. Ele também garante que, se um inquilino acidentalmente iniciar um grande número de conexões com o recurso e esgotar sua capacidade, o restante do sistema continuará funcionando.

Conformidade

Quando você interage ou transmite os dados de seus locatários diretamente, é crucial que você tenha uma compreensão clara dos requisitos de governança e conformidade de seus locatários.

Abordagens e padrões

Expor APIs

As integrações em tempo real geralmente envolvem expor APIs para seus locatários ou outras partes usarem. As APIs exigem considerações especiais, especialmente quando as partes externas as usam. Considere os seguintes fatores:

• Defina quem pode acessar a API.

• Autenticar usuários da API usando um método seguro e confiável.

• Defina um limite no número de solicitações que cada usuário de API pode fazer em um período de tempo específico.

• Forneça informações e documentação claras para cada API. Se apropriado, implemente um portal do desenvolvedor para dar suporte à descoberta e integração.

Uma prática recomendada é usar um gateway de API, como o Gerenciamento de API do Azure, para lidar com essas preocupações e muitas outras. Os gateways de API oferecem um único local para implementar políticas que suas APIs seguem. Eles também simplificam a implementação de seus sistemas de API de back-end. Para obter mais informações, consulte Usar o Gerenciamento de API em uma solução multilocatário.

Padrão Valet Key

Ocasionalmente, um locatário pode precisar de acesso direto a uma fonte de dados, como o Armazenamento do Azure. Considere seguir o padrão Valet Key para compartilhar dados com segurança e restringir o acesso ao repositório de dados.

Por exemplo, você pode usar essa abordagem para exportar em lote um arquivo de dados grande. Após gerar o arquivo de exportação, você pode salvá-lo em um contêiner de blob no Armazenamento do Azure e, depois, gerar uma SAS de limite de tempo e somente leitura. Essa assinatura poderá ser fornecida ao locatário, juntamente com a URL do blob. Em seguida, o locatário pode baixar o arquivo do Armazenamento do Azure até a data de validade da assinatura.

Da mesma forma, você pode gerar uma SAS com permissões para gravar em um blob específico. Quando você fornece um SAS a um inquilino, ele pode gravar seus dados no blob. Ao usar a integração da Grade de Eventos para o Armazenamento do Azure, seu aplicativo poderá ser notificado para processar e importar o arquivo de dados.

Ganchos da Web

Os webhooks permitem que você envie eventos para seus locatários em uma URL que eles fornecem a você. Quando você tiver informações para enviar, inicie uma conexão com o webhook do locatário e inclua seus dados no conteúdo da solicitação HTTP.

Se você optar por criar seu próprio sistema de eventos do webhook, considere seguir o padrão CloudEvents para simplificar os requisitos de integração de seus locatários.

Como alternativa, você pode usar um serviço, como a Grade de Eventos para fornecer a funcionalidade de webhook. A Grade de Eventos funciona nativamente com CloudEvents e dá suporte a domínios de eventos, que são úteis para soluções multilocatários.

Acesso de usuário delegado

Ao acessar os dados de armazenamentos de dados de um locatário, considere se você precisa usar a identidade de um usuário específico para acessar os dados. Quando você fizer isso, sua integração estará sujeita às mesmas permissões que o usuário tem. Essa abordagem é frequentemente chamada de acesso delegado.

Por exemplo, suponha que seu serviço multilocatário execute modelos de machine learning nos dados de seus locatários. Você precisa acessar as instâncias de serviços de cada locatário, como Microsoft Fabric workspaces para análises, o Armazenamento do Azure e o Azure Cosmos DB. Cada locatário tem seu próprio diretório do Microsoft Entra. Sua solução pode receber acesso delegado ao armazenamento de dados para que você possa recuperar os dados que um usuário específico pode acessar.

O acesso delegado será mais fácil se o armazenamento de dados oferecer suporte à autenticação do Microsoft Entra. Muitos serviços do Azure dão suporte a identidades do Microsoft Entra.

Por exemplo, suponha que seu aplicativo Web multilocatário e os processos em segundo plano precisem acessar o Azure Storage usando as identidades de usuário dos seus locatários no Microsoft Entra ID. Siga as seguintes etapas:

1. Crie um registro de aplicativo multilocatário do Microsoft Entra que represente sua solução.

2. Conceda ao aplicativo uma permissão delegada para acessar o Armazenamento do Azure como o usuário conectado.

3. Configure o aplicativo para autenticar usuários usando o Microsoft Entra ID.

Depois que um usuário está conectado, o Microsoft Entra ID emite ao seu aplicativo um token de acesso de curta duração que pode ser usado para acessar o Armazenamento do Azure em nome do usuário e emite um token de atualização de duração mais longa. Seu sistema precisa armazenar o token de atualização com segurança para que seus processos em segundo plano possam obter novos tokens de acesso e possam continuar acessando o Armazenamento do Azure em nome do usuário.

Messaging

O sistema de mensagens permite a comunicação assíncrona e fracamente acoplada entre sistemas ou componentes. O sistema de mensagens geralmente é usado em cenários de integração para desacoplar os sistemas de origem e de destino. Para obter mais informações sobre mensagens e multilocação, consulte Abordagens arquiteturais para mensagens em soluções multilocatadas.

Ao usar mensagens como parte de uma integração com os sistemas de locatários, considere se deve usar Tokens SAS para Barramento de Serviço ou Hubs de Eventos. Os tokens SAS concedem acesso limitado aos recursos de mensagens para usuários ou sistemas externos sem permitir que eles acessem o restante do subsistema de mensagens.

Em alguns cenários, você pode fornecer contratos de nível de serviço diferentes ou garantias de qualidade de serviço para locatários diferentes. Por exemplo, um subconjunto de seus locatários pode esperar que suas solicitações de exportação de dados sejam processadas mais rapidamente do que outros. Usando o padrão fila de prioridade, você pode criar filas separadas para diferentes níveis de prioridade. Em seguida, você pode usar instâncias de trabalho diferentes para priorizá-las adequadamente.

Componentes de integração combináveis

Talvez algumas vezes você precise se integrar a muitos locatários diferentes, cada um dos quais usa formatos de dados diferentes ou tipos diferentes de conectividade de rede.

Uma abordagem comum na integração é criar e testar etapas individuais que executam os seguintes tipos de ações:

• Recuperar dados de um armazenamento de dados.
• Transformar dados em um formato ou esquema específico.
• Transmita dados usando um transporte de rede específico ou para um tipo de destino conhecido.

Normalmente, você cria esses elementos individuais usando serviços, como o Azure Functions e os Aplicativos Lógicos do Azure. Em seguida, você define o processo de integração geral usando uma ferramenta como Aplicativos Lógicos ou Azure Data Factory, que invoca cada etapa predefinida.

Quando você trabalha com cenários complexos de integração multilocatário, é útil definir uma biblioteca de etapas de integração reutilizáveis. Você pode criar fluxos de trabalho para cada locatário compondo as partes aplicáveis com base nos requisitos desse locatário. Como alternativa, você pode expor alguns dos conjuntos de dados ou componentes de integração diretamente aos seus locatários para que eles possam criar seus próprios fluxos de trabalho de integração.

Da mesma forma, talvez seja necessário importar dados de locatários que usam um formato de dados diferente ou transporte diferente de outros. Uma boa abordagem para esse cenário é criar conectores específicos do locatário. Os conectores são fluxos de trabalho que normalizam e importam os dados em um formato e local padronizados. Em seguida, eles disparam seu principal processo de importação compartilhada.

Se precisar criar uma lógica ou um código específico do locatário, considere seguir o Padrão da Camada Anticorrupção. Esse padrão ajuda a encapsular componentes específicos do locatário e mantém o restante da solução sem reconhecimento da complexidade adicional.

Se você usar um modelo de preços em camadas, poderá exigir que os locatários em tipos de preços baixos sigam uma abordagem padrão com um conjunto limitado de formatos de dados e transportes. Locatários em tipos de preços mais altos podem ter acesso a mais personalização ou flexibilidade nos componentes de integração que você fornece.

Antipadrões a serem evitados

• Expor seus armazenamentos de dados primários diretamente aos locatários. Quando os locatários acessam seus armazenamentos de dados primários, pode se tornar mais difícil proteger esses repositórios. Eles também podem causar problemas de desempenho acidentalmente que afetam sua solução. Evite fornecer credenciais para seus armazenamentos de dados aos clientes. Não faça a replicação direta de dados brutos do banco de dados primário para as réplicas de leitura dos clientes no mesmo sistema de banco de dados. Em vez disso, crie armazenamentos de dados de integração dedicados. Use o Padrão de chave limitada para expor os dados.

• Expondo APIs sem um gateway de APIs. As APIs têm preocupações específicas para controle de acesso, cobrança e medição. Mesmo que você não planeje usar políticas de API inicialmente, é recomendável incluir um gateway de API antecipadamente. Dessa forma, se você precisar personalizar suas políticas de API mais tarde, não precisará fazer alterações significativas nas URLs das quais um cliente externo depende.

• Acoplamento estrito desnecessário. O acoplamento fraco, como o uso de abordagens de mensagens, pode fornecer uma série de benefícios para segurança, isolamento de desempenho e resiliência. Sempre que possível, você deve desacoplar integrações com sistemas externos. Se precisar se associar firmemente a um sistema externo, siga práticas recomendadas como Padrão de Repetição, Padrão de Disjuntor e Padrão de Bulkhead.

• Integrações personalizadas para locatários específicos. Recursos ou códigos específicos do locatário podem tornar sua solução mais difícil de testar. Isso também dificulta a modificação da solução no futuro, pois você precisa entender mais caminhos de código. Em vez disso, tente criar componentes componíveis que abstraiam os requisitos de qualquer locatário específico e reutilize-os em vários locatários que tenham requisitos semelhantes.

Colaboradores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Principais autores:

• John Downs | Principal Engenheiro de Software, Padrões do Azure & Práticas
• Arsen Vladimirskiy | Engenheiro Principal de Clientes, FastTrack for Azure

Outros colaboradores:

• Will Velida | Engenheiro do Cliente 2, FastTrack for Azure
• Filipe Moreira | Arquiteto de Soluções na Nuvem

Para ver perfis não públicos no LinkedIn, entre no LinkedIn.

Recurso relacionado

• Abordagens arquiteturais para mensageria em soluções multi-inquilino