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

Artigo
07/22/2024

É comum 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 para receber dados desses sistemas. Neste artigo, descrevemos as principais considerações e abordagens para arquitetar e desenvolver integrações para uma solução multilocatário.

Nota

Se você fornecer vários pontos de integração, é melhor considerar cada um deles de forma independente. Muitas vezes, diferentes pontos de integração têm requisitos diferentes e são projetados de forma diferente, mesmo que estejam conectando os mesmos sistemas de várias maneiras diferentes.

Principais considerações e requisitos

Direção do fluxo de dados

É importante entender a direção em que seus dados fluem. 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 multilocatário 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 delegado pelo usuário

Em muitos sistemas, o acesso a determinados dados é restrito a utilizadores específicos. Os dados que um usuário pode acessar podem não ser os mesmos que os dados que outro usuário pode acessar. É importante considerar se você espera trabalhar com conjuntos de dados completos ou se os conjuntos de dados importados ou exportados são baseados no que um usuário específico tem permissão para acessar.

Por exemplo, considere o Microsoft Power BI, que é um serviço multilocatário que fornece relatórios e business intelligence 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 diferentes:

Importe todos os dados do armazenamento de dados subjacente. Essa abordagem requer que o Power BI receba credenciais para uma identidade que possa acessar o armazenamento de dados completo. Em seguida, os administradores do Power BI podem configurar separadamente as permissões para os dados importados depois que eles forem importados para o Power BI. O Power BI impõe as 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 a fonte de dados, ele usa suas credenciais e as permissões associadas. O subconjunto exato de dados que o Power BI importa depende do nível de acesso do usuário que criou 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 esse tipo de integração, você também deve considerar o uso de uma identidade de carga de trabalho em vez de uma identidade de usuário. Uma identidade de carga de trabalho é uma identidade do sistema que não corresponde a um único usuário. A identidade da 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 de 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 sobre a delegação de usuários, consulte a Abordagem de acesso de usuário delegado abaixo. Se você usar delegação, considere como lidará com cenários em que um usuário é desprovisionado ou suas permissões são alteradas.

Em tempo real ou em lote

Considere se você trabalhará com dados em tempo real ou se os dados serão enviados em lotes.

Para integrações em tempo real, estas 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 de 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, usando algo como o padrão de solicitação-resposta assíncrona para aguardar uma resposta.
A comunicação fracamente acoplada geralmente é habilitada por meio de componentes de mensagens que são projetados para acoplar sistemas de acoplamento flexível. 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 fornecem recursos de evento. 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 determinados momentos do dia. Geralmente, as integrações em lote ocorrem por meio de um local de preparação, 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 tenham uma compreensão clara de como os dados serão formatados e estruturados. 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 que serão incluídos, formatos de data e anulabilidade de campos.

Quando você trabalha com um sistema multilocatário, se possível, é melhor padronizar e usar o mesmo formato de dados para todos os seus locatários. Dessa forma, você evita ter que personalizar e testar novamente seus componentes de integração para os requisitos de cada locatário. No entanto, em algumas situações, talvez seja necessário usar formatos de dados diferentes para se comunicar com locatários diferentes e, portanto, talvez seja necessário implementar várias integrações. Consulte a seção Componentes de integração compostáveis para obter uma abordagem que pode ajudar a simplificar esse tipo de situação.

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:

Conecte-se pela internet. Se você se conectar pela internet, como a conexão será protegida e como os dados serão criptografados? Se os seus inquilinos planeiam restringir 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 NAT Gateway 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 e ajudá-lo a evitar a necessidade de seus locatários permitirem conexõ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 as orientações sobre 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 você gerenciará com segurança as credenciais de seus locatários. O vazamento dos segredos dos seus inquilinos pode resultar em um grande incidente de segurança, potencialmente afetando muitos inquilinos.
Tokens Microsoft Entra, onde você usa um token emitido pelo diretório Microsoft Entra do próprio locatário. 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 evite conceder permissões desnecessárias ao seu 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, que você pode modelar como parte da área de superfície da sua solução.

Em algumas situações, você pode decidir fornecer aos locatários acesso direto aos recursos do Azure. Considere as ramificações cuidadosamente e certifique-se de entender como conceder acesso aos inquilinos de maneira segura. Por exemplo, você pode usar uma das seguintes abordagens:

Use o padrão de chave de manobrista, que envolve o uso de medidas de segurança, como assinaturas de acesso compartilhado, para conceder acesso restrito a determinados recursos 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. Ele também garante que, se um locatário acidentalmente iniciar um grande número de conexões com o recurso e esgotar sua capacidade, o resto do sistema continuará a funcionar.

Conformidade

Quando você começa a interagir diretamente com os dados dos locatários ou a transmitir esses dados, é fundamental que você tenha uma compreensão clara dos requisitos de governança e conformidade dos locatários.

Abordagens e padrões a considerar

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 usadas por terceiros. Considere as perguntas seguintes:

A quem é concedido acesso à API?
Como você autenticará os usuários da API?
Existe um limite para o número de solicitações que um usuário de API pode fazer durante um período de tempo?
Como você fornecerá informações sobre suas APIs e documentação para cada API? Por exemplo, você precisa implementar um portal do desenvolvedor?

Uma boa prática é 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 e simplificam a implementação de seus sistemas de API de back-end. Para saber mais sobre como o Gerenciamento de API dá suporte à arquitetura multilocatário, consulte Usar o Gerenciamento de API do Azure em uma solução multilocatário.

Padrão de Chave Valet

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

Por exemplo, você pode usar essa abordagem ao 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 assinatura de acesso compartilhado com limite de tempo e somente leitura. Essa assinatura pode ser fornecida ao locatário, juntamente com a URL de blob. O locatário pode baixar o arquivo do Armazenamento do Azure até a expiração da assinatura.

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

Webhooks

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 você optar por criar seu próprio sistema de eventos 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 do Azure 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.

Nota

Sempre que fizer ligações de saída aos sistemas dos seus inquilinos, lembre-se de que está a ligar a um sistema externo. Siga as práticas de nuvem recomendadas, incluindo o uso do padrão Retry, o padrão Circuit Breaker e o padrão Bulkhead para garantir que os problemas no sistema do locatário não se propaguem ao seu sistema.

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 o Azure Synapse Analytics, o Armazenamento do Azure, o Azure Cosmos DB e outros. 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 seu aplicativo Web multilocatário e processos em segundo plano precisem acessar o Armazenamento do Azure usando as identidades de usuário de seus locatários da ID do Microsoft Entra. Você pode executar as seguintes etapas:

Crie um registro de aplicativo Microsoft Entra multilocatário que represente sua solução.
Conceda permissão delegada ao aplicativo para acessar o Armazenamento do Azure como o usuário conectado.
Configure seu aplicativo para autenticar usuários usando o Microsoft Entra ID.

Depois que um usuário entra, a ID do Microsoft Entra 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 vida 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 a acessar o Armazenamento do Azure em nome do usuário.

Mensagens

O sistema de mensagens permite uma comunicação assíncrona e fracamente acoplada entre sistemas ou componentes. As mensagens são comumente 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 locatários, considere se deve usar assinaturas de acesso compartilhado para o Barramento de Serviço do Azure ou Hubs de Eventos do Azure. As assinaturas de acesso compartilhado permitem que você conceda acesso limitado aos seus recursos de mensagens a terceiros, 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 (SLAs) ou garantias de qualidade de serviço (QoS) 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, com instâncias de trabalho diferentes para priorizá-las adequadamente.

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 os 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 e invoca cada uma das etapas predefinidas.

Quando você trabalha com cenários complexos de integração multilocatário, pode ser útil definir uma biblioteca de etapas de integração reutilizáveis. Em seguida, você pode criar fluxos de trabalho para cada locatário para compor as partes aplicáveis juntas, com base nos requisitos desse locatário. Como alternativa, você poderá 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 a partir deles.

Da mesma forma, talvez seja necessário importar dados de locatários que usam um formato de dados diferente ou transporte diferente para 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 e, em seguida, acionam seu processo de importação compartilhado principal.

Se você precisar criar lógica ou código específico do locatário, considere seguir o padrão de camada anticorrupção. O padrão ajuda você a encapsular componentes específicos do locatário, mantendo o restante da solução inconsciente da complexidade adicional.

Se você usar um modelo de preços diferenciados, poderá optar por exigir que os locatários em um nível de preço baixo sigam uma abordagem padrão com um conjunto limitado de formatos de dados e transportes. Níveis de preços mais altos podem permitir mais personalização ou flexibilidade nos componentes de integração que você oferece.

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 de dados e eles podem acidentalmente causar problemas de desempenho que afetam sua solução. Evite fornecer credenciais para seus armazenamentos de dados aos seus clientes e não replique diretamente os dados do seu banco de dados principal para as réplicas de leitura dos clientes do mesmo sistema de banco de dados. Em vez disso, crie armazenamentos de dados de integração dedicados e use o padrão Valet Key para expor os dados.
Expor 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 no futuro, não precisará fazer alterações significativas nas URLs das quais um terceiro depende.
Acoplamento apertado desnecessário. O acoplamento flexível, como o uso de abordagens de mensagens , pode fornecer uma série de benefícios para segurança, isolamento de desempenho e resiliência. Quando possível, é uma boa ideia associar livremente suas integrações com terceiros. Se você precisar se acoplar firmemente a terceiros, 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 reutilizá-los em vários locatários com requisitos semelhantes.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

John Downs - Brasil | Engenheiro de Software Principal
Arsen Vladimirskiy - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure

Outros contribuidores:

Will Velida - Brasil | Engenheiro de Clientes 2, FastTrack para Azure

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos

Analise Abordagens arquitetônicas para mensagens em soluções multilocatário.

Partilhar via