Abordagens arquitetônicas para integração de locatários e acesso a dados

É típico que os sistemas se integrem juntos, mesmo além das fronteiras 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.

Principais considerações e requisitos

Direção do fluxo de dados

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

• Exportar, o que significa que os dados fluem do seu sistema de múltiplos inquilinos para os sistemas dos seus inquilinos individuais

• Importar, o que significa que os dados vêm dos sistemas dos seus inquilinos para o seu 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 poder importar os dados do sistema do locatário.

Acesso total ou acesso delegado pelo usuário

Em muitos sistemas, o acesso a dados específicos é restrito a utilizadores individuais. Os dados que um usuário acessa 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 em cima de armazenamentos de dados pertencentes ao cliente. Quando configura o Power BI, 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 diferentes:

• 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.

• Importe 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 que o Power BI importa depende do nível de acesso do usuário que cria a fonte de dados.

Ambas as abordagens têm casos de uso válidos, por isso é importante entender claramente os requisitos dos seus inquilinos.

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

Como alternativa, se trabalhar com dados com escopo de utilizador, poderá necessitar de usar uma abordagem como delegação para aceder ao 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 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 é quando 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, onde aguardam confirmação e uma resposta. Como alternativa, as solicitações podem ser assíncronas e usar algo como o padrão Request-Reply assíncrono para aguardar uma resposta.

• Comunicação fracamente acoplada é frequentemente habilitada por meio de componentes de mensagens projetados para acoplar sistemas de forma frouxa. Por exemplo, o Azure Service Bus fornece funcionalidades de enfileiramento de mensagens, enquanto o Azure Event Grid e o Azure Event Hubs oferecem funcionalidades de eventos. Esses componentes são frequentemente usados como parte de arquiteturas de integração.

Por outro lado, as integrações em lote geralmente são gerenciadas por meio de um trabalho em segundo plano, que pode ser acionado em momentos 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 blob, 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 a planejar a capacidade geral do sistema. Ao planejar a capacidade do sistema, lembre-se de que locatários diferentes 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 ambas entendam claramente o formato e a estrutura dos dados. Considere as seguintes partes do formato de dados:

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

• O esquema, como a lista de campos incluídos, formatos de data e anulabilidade de campos

Ao trabalhar com um sistema multilocatário, se possível, padronize e use o mesmo formato de dados para todos os seus locatários. Essa abordagem ajuda você a evitar a necessidade de personalizar e testar novamente seus componentes de integração para os requisitos de cada locatário. 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 pode ajudar a simplificar esse tipo de cenário, consulte Componentes de integração compostáveis.

Acesso aos sistemas dos inquilinos

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

Acesso à rede

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

• As ligações à Internet podem levantar preocupações sobre a segurança da ligação e a encriptação dos dados. Determine como proteger a conexão e criptografar os dados quando você se conectar pela Internet. Se os seus inquilinos planeiam restringir o acesso com base nos seus endereços IP, certifique-se de que os serviços do Azure que a sua solução utiliza podem suportar endereços IP estáticos para ligaçõ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 com segurança 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 os seus inquilinos autorizarem as ligações de entrada.

• Os retransmissores, como o Azure Relay, 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 planear como gerir com segurança as credenciais dos seus inquilinos. A fuga dos segredos dos seus inquilinos pode resultar num grande incidente de segurança, que pode potencialmente afetar muitos inquilinos.

• Tokens do Microsoft Entra, onde você usa um token que o diretório do Microsoft Entra do locatário emite. O token pode ser emitido diretamente para sua carga de trabalho usando um registro de 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, certifique-se de que seus locatários sigam o princípio do menor privilégio e não concedam permissões desnecessárias ao sistema. Por exemplo, se o sistema só precisa ler dados do armazenamento de dados de um locatário, a identidade que o sistema usa não deve ter permissões de gravação.

Acesso dos inquilinos 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 sua solução.

Em alguns cenários, você pode decidir fornecer aos locatários acesso direto aos recursos do Azure. Considere as ramificações cuidadosamente e certifique-se de que compreende como conceder acesso aos inquilinos de forma 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 a minimizar o raio de explosão de um incidente de segurança. Também assegura que, se um locatário iniciar acidentalmente um grande número de conexões com o recurso e esgotar sua capacidade, o resto do seu sistema continuará a funcionar.

Conformidade

Quando interage ou transmite os dados dos seus inquilinos diretamente, é crucial que tenha uma compreensão clara dos requisitos de governação e conformidade dos seus inquilinos.

Abordagens e padrões

Expor APIs

As integrações em tempo real geralmente envolvem a exposição de APIs para seus locatários ou outras partes usarem. As APIs requerem considerações especiais, especialmente quando terceiros as utilizam. Considere os seguintes fatores:

• Defina quem pode acessar a API.

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

• Defina um limite para o número de solicitações que cada usuário da API pode fazer durante 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 boa prática é usar um gateway de API, como o Azure API Management, para resolver estas e muitas outras preocupações. 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 back-end. Para obter mais informações, consulte Usar o gerenciamento de API em uma solução multilocatário.

Padrão Chave de Valet

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

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

Da mesma forma, você pode gerar uma SAS com permissões para gravar em um blob específico. Quando você fornece uma SAS a um locatário, ele pode gravar seus dados no blob. Usando a integração com o Event Grid para o Armazenamento do Azure, a sua aplicação pode ser notificada para processar e importar o ficheiro de dados.

Ganchos da Web

Os Webhooks permitem-lhe enviar eventos para os seus inquilinos num URL que eles lhe fornecem. Quando tiver informações para enviar, inicie uma conexão com o webhook do locatário e inclua seus dados na carga útil da solicitação HTTP.

Se optar por criar o seu próprio sistema de eventos de webhook, considere seguir o padrão CloudEvents para simplificar os requisitos de integração dos seus clientes.

Como alternativa, pode usar um serviço como o Event Grid para fornecer a funcionalidade de webhook. O Event Grid funciona nativamente com o CloudEvents e suporta domínios de eventos, que são úteis para soluções multilocatário.

Acesso de usuário delegado

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

Por exemplo, suponha que seu serviço multilocatário execute modelos de aprendizado de máquina sobre os dados de seus locatários. Você precisa acessar as instâncias de serviços de cada locatário, como espaços de trabalho do Microsoft Fabric para análise, Azure Storage e Azure Cosmos DB. Cada locatário tem seu próprio diretório 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 é mais fácil se o armazenamento de dados oferecer suporte à autenticação do Microsoft Entra. Muitos serviços do Azure suportam identidades Microsoft Entra.

Por exemplo, suponha que a sua aplicação Web multilocatário e os processos em segundo plano precisem aceder ao Armazenamento do Azure usando as identidades de utilizador dos seus locatários do Microsoft Entra ID. Você pode executar as seguintes etapas:

1. Crie um registo de aplicação multilocatário do Microsoft Entra que represente a sua solução.

2. Conceda permissão delegada à aplicação para aceder ao Armazenamento do Azure como o utilizador com sessão iniciada.

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

Depois de um utilizador iniciar sessão, a Microsoft Entra ID emite ao seu aplicativo um token de acesso de curta duração que pode ser usado para aceder ao Armazenamento do Azure em nome do utilizador, e emite um token de atualização de longa duração. 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 a acessar o Armazenamento do Azure em nome do usuário.

Messaging

O sistema de mensagens permite uma comunicação assíncrona e fracamente acoplada entre sistemas ou componentes. As mensagens são frequentemente usadas em cenários de integração para separar os sistemas de origem e de destino. Para obter mais informações sobre mensagens e multilocação, consulte Abordagens arquitetônicas para mensagens em soluções multilocatário.

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

Em alguns cenários, você pode fornecer diferentes contratos de nível de serviço ou garantias de qualidade de serviço para diferentes locatários. 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 de fila de prioridade, você pode criar filas separadas para diferentes níveis de prioridade. Em seguida, você pode usar diferentes instâncias de trabalho para priorizá-las de acordo.

Componentes de integração compatíveis

Às vezes, você pode precisar integrar com muitos locatários diferentes, cada um dos quais usa formatos de dados diferentes ou diferentes tipos de conectividade de rede.

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

• Recupere dados de um armazenamento de dados.
• Transforme 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 se trabalha com cenários complexos de integração multi-inquilino, é útil definir uma biblioteca de passos 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 dos outros. Uma boa abordagem para este cenário é criar conectores específicos do inquilino. Conectores são fluxos de trabalho que normalizam e importam os dados em um formato e local padronizados. Em seguida, eles acionam seu processo principal de importação compartilhada.

Se precisar criar lógica ou código específico do inquilino, 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 inconsciente da complexidade adicional.

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

Antipadrões a evitar

• 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 armazenamentos. Eles também podem acidentalmente causar problemas de desempenho que afetam sua solução. Evite fornecer credenciais para seus armazenamentos de dados aos clientes. Não replique diretamente os dados brutos do seu banco de dados principal para as replicas de leitura dos clientes do mesmo sistema de banco de dados. Em vez disso, crie armazenamentos de dados de integração dedicados. Use o padrão Valet Key para expor os dados.

• Expondo APIs sem um gateway de API. As APIs têm preocupações específicas para controle de acesso, faturamento e medição. Mesmo que você não planeje usar políticas de API inicialmente, é uma boa ideia 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 apertado desnecessário. O desacoplamento, como por exemplo através de abordagens de mensagens, pode fornecer uma série de benefícios para a segurança, isolamento de desempenho e resiliência. Quando possível, você deve acoplar livremente suas integrações com sistemas externos. Se você precisar se acoplar firmemente a um sistema externo, certifique-se de seguir boas práticas, como o padrão Retry, o padrão Circuit Breaker e o padrão 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 torna mais difícil modificar sua solução no futuro, porque você precisa entender mais caminhos de código. Em vez disso, tente criar componentes compostáveis que abstraiam os requisitos para qualquer locatário específico e reutilize-os em vários locatários que tenham requisitos semelhantes.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Principais autores:

• John Downs | Engenheiro de Software Principal, Azure Patterns & Practices
• Arsen Vladimirskiy | Engenheiro Principal de Clientes, FastTrack for Azure

Outros contribuidores:

• Will Velida | Engenheiro de Clientes 2, FastTrack para Azure
• Filipe Moreira - Portugal | Arquiteto de Soluções Cloud

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Recurso relacionado

• Abordagens arquitetónicas para comunicação em soluções multicliente