Compartilhar via

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

  • Artigo

É comum que os sistemas se integrem, mesmo entre limites organizacionais. Ao criar uma solução multilocatário, talvez você tenha o requisito de retornar dados aos sistemas dos locatários ou de 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.

Observação

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

Considerações e requisitos

Direção do fluxo de dados

É importante entender a direção de fluxo dos seus 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, o que significa que os dados fluem do sistema multilocatário para os sistemas de seus locatários individuais.
  • Importar, o que significa que os dados são fornecidos dos sistemas de seus locatários para 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 que possa 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 usuários específicos. Os dados que um usuário pode acessar podem não ser os mesmos dados que outro usuário pode acessar. É importante considerar se você espera trabalhar com conjuntos de dados completos ou se os conjuntos de dados que você importa ou exporta 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:

  • Importar 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 permissões para os dados importados depois que eles são importados para o Power BI. O Power BI impõe as 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 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.

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 obtém efetivamente a mesma permissão que um usuário específico. Para obter mais informações sobre delegação de usuário, consulte a abordagem 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. Geralmente, as integrações de 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, usando algo como o Padrão de solicitação/resposta assíncrona 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 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 lote geralmente são gerenciadas por meio de um trabalho em segundo plano, que pode ser acionado em determinados momentos do dia. Normalmente, as integrações em lote 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 a planejar a 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 ambas tenham uma clara compreensão 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, os formatos de data e a nulidade dos campos.

Quando você trabalhar com um sistema multilocatário, se possível, será melhor padronizar e usar o mesmo formato de dados para todos os seus locatários. Dessa forma, você evitará 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 combináveis, para obter uma abordagem que poderá ajudar a simplificar esse tipo de situação.

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:

  • Conectar-se pela internet. Se você se conectar pela internet, como a conexão será protegida e como os dados serão criptografados? Se seus locatários planejarem restringir com base em seus endereços IP, verifique se os serviços do Azure que sua solução usa poderão dar suporte a endereços IP estáticos para conexões de saída. Por exemplo, considere usar o Gateway da NAT 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.
  • Agentes, que são implantados no ambiente de um locatário, podem fornecer uma abordagem flexível e podem ajudar você a evitar que seus locatários tenham necessidade de permitir 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 as diretrizes 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 de seus locatários poderá resultar em um grande incidente de segurança, podendo afetar muitos locatários.
  • Tokens do Microsoft Entra, em que você usa um token emitido pelo próprio diretório do 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, certifique-se de que seus locatários sigam o princípio de privilégio mínimo e evitem conceder permissões desnecessárias ao sistema. Por exemplo, se o seu sistema precisar apenas ler dados do armazenamento de dados de um locatário, a identidade que o sistema usar 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, que você poderá modelar como parte da área de superfície da sua solução.

Em algumas situações, você poderá decidir fornecer aos seus locatários acesso direto aos seus recursos do Azure. Considere com cautela as ramificações e certifique-se de entender 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 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 prática recomendada é manter os recursos de integração separados dos recursos principais do sistema. Essa abordagem ajuda a minimizar o raio de alcance de um incidente de segurança. Ela também garantirá que, se um locatário iniciar acidentalmente um grande número de conexões com o recurso e esgotar sua capacidade, o restante do sistema continuará em execução.

Conformidade

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

Abordagens e padrões a serem considerados

Expor APIs

As integrações em tempo real geralmente envolvem expor APIs para que sejam usadas por seus locatários ou outras partes. As APIs requerem considerações especiais, principalmente quando usadas por partes externas. Considere as seguintes perguntas:

  • A quem o acesso à API é concedido?
  • Como você autenticará os usuários da API?
  • Existe um limite para o número de solicitações que um usuário da 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 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 você implementar as 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 API Management dá suporte à arquitetura multilocatário, consulte Usar o Azure API Management 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 armazenamento de dados.

Por exemplo, você poderá usar essa abordagem ao exportar em lote um arquivo de dados grande. Depois de gerar o arquivo de exportação, você poderá salvá-lo em um contêiner de blob no Armazenamento do Azure e gerar uma assinatura de acesso compartilhado com limite de tempo e somente leitura. Essa assinatura poderá ser fornecida ao locatário, juntamente com a URL do blob. O locatário poderá baixar o arquivo do Armazenamento do Azure até o vencimento 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. 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.

Webhooks

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 do Azure para fornecer a funcionalidade de webhook. A Grade de Eventos funciona nativamente com o CloudEvents e oferece suporte a domínios de eventos, que são úteis para soluções multilocatário.

Observação

Sempre que você estabelecer conexões de saída com os sistemas de seus locatários, lembre-se de que está se conectando a um sistema externo. Siga as práticas de nuvem recomendadas, incluindo o uso do padrão de Repetição, do padrão de Disjuntor e do padrão de Bulkhead para garantir que os problemas no sistema do locatário não se propaguem para o seu sistema.

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 geralmente é 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 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 oferecem suporte a identidades do Microsoft Entra.

Por exemplo, suponha que seu aplicativo Web multilocatário e os processos em segundo plano precisem acessar o Armazenamento do Azure usando as identidades de usuário de seus locatários do 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 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 a acessar o Armazenamento do Azure em nome do usuário.

Mensagens

O sistema de mensagens permite a comunicação assíncrona e fracamente acoplada entre sistemas ou componentes. O sistema de mensagens é comumente usado em cenários de integração para separar os sistemas de origem e de destino. Para obter mais informações sobre o sistema de mensagens e multilocação, consulte Abordagens de arquitetura 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 você 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 seu 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 distintos. 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, com instâncias de trabalho distintas 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.
  • Transmitir 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 geral de integração 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 para seus locatários, de forma que eles possam criar seus próprios fluxos de trabalho de integração a partir deles.

Da mesma forma, talvez você precise 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. Conectores são fluxos de trabalho que normalizam e importam os dados para um formato e local padronizados e, em seguida, acionam seu processo de importação compartilhado principal.

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

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

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 armazenamentos de dados e eles podem acidentalmente causar problemas de desempenho que afetam sua solução. Evite fornecer a seus clientes credenciais para seus armazenamentos de dados e não replique diretamente os dados do banco de dados primário 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 de Chave Limitada para expor os dados.
  • Expor APIs sem um gateway de API. 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 no futuro, não precisará fazer alterações significativas nas URLs das quais um terceiro 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. Quando possível, uma prática recomendada é acoplar fracamente suas integrações com terceiros. Se você realmente precisar se acoplar rigidamente a um terceiro, certifique-se de seguir boas práticas, como o padrão de Repetição, o padrão de Disjuntor e o 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 tornará mais difícil modificar sua solução no futuro, porque você precisará entender mais caminhos de código. Em vez disso, tente criar componentes combináveis que abstraiam os requisitos de qualquer locatário específico e reutilize-os em vários locatários com requisitos semelhantes.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

Outro colaborador:

  • Will Velida | Engenheiro do Cliente 2, FastTrack for Azure

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

Próximas etapas

Consulte Abordagens de arquitetura para mensagens em soluções multilocatário.