Arquitetura de rede e melhores práticas do Microsoft Purview
As soluções de governação do Microsoft Purview são soluções paaS (plataforma como serviço) para a governação de dados. As contas do Microsoft Purview têm pontos finais públicos que são acessíveis através da Internet para ligar ao serviço. No entanto, todos os pontos finais são protegidos através de inícios de sessão Microsoft Entra e controlo de acesso baseado em funções (RBAC).
Observação
Estas melhores práticas abrangem a arquitetura de rede para soluções de governação unificada do Microsoft Purview. Para obter mais informações sobre as soluções de risco e conformidade do Microsoft Purview, aceda aqui. Para obter mais informações sobre o Microsoft Purview em geral, aceda aqui.
Para uma camada adicional de segurança, pode criar pontos finais privados para a sua conta do Microsoft Purview. Receberá um endereço IP privado da sua rede virtual no Azure para a conta do Microsoft Purview e os respetivos recursos geridos. Este endereço irá restringir todo o tráfego entre a sua rede virtual e a conta do Microsoft Purview para uma ligação privada para interação do utilizador com as APIs e o portal de governação do Microsoft Purview ou para análise e ingestão.
Atualmente, a firewall do Microsoft Purview fornece controlo de acesso para o ponto final público da sua conta purview. Pode utilizar a firewall para permitir todo o acesso ou bloquear todo o acesso através do ponto final público ao utilizar pontos finais privados. Para obter mais informações, veja Opções de firewall do Microsoft Purview
Com base nos seus requisitos de rede, conectividade e segurança, pode configurar e manter contas do Microsoft Purview para aceder a serviços ou ingestão subjacentes. Utilize este guia de melhores práticas para definir e preparar o seu ambiente de rede para que possa aceder ao Microsoft Purview e analisar origens de dados a partir da sua rede ou cloud.
Este guia abrange as seguintes opções de rede:
- Utilizar pontos finais públicos do Azure.
- Utilizar pontos finais privados.
- Utilize pontos finais privados e permita o acesso público na mesma conta do Microsoft Purview.
- Utilize pontos finais públicos do Azure para aceder ao portal de governação do Microsoft Purview e aos pontos finais privados para ingestão.
Este guia descreve alguns dos cenários de arquitetura de rede mais comuns para o Microsoft Purview. Apesar de não estar limitado a esses cenários, tenha em atenção as limitações do serviço quando estiver a planear redes para as suas contas do Microsoft Purview.
Pré-requisitos
Para compreender qual é a melhor opção de rede para o seu ambiente, sugerimos que execute primeiro as seguintes ações:
Reveja a topologia de rede e os requisitos de segurança antes de registar e analisar quaisquer origens de dados no Microsoft Purview. Para obter mais informações, veja: Definir uma topologia de rede do Azure.
Defina o modelo de conectividade de rede para os serviços PaaS.
Opção 1: Utilizar pontos finais públicos
Por predefinição, pode utilizar contas do Microsoft Purview através dos pontos finais públicos acessíveis através da Internet. Permita redes públicas na sua conta do Microsoft Purview se tiver os seguintes requisitos:
- Não é necessária conectividade privada ao analisar ou ligar a pontos finais do Microsoft Purview.
- Todas as origens de dados são apenas aplicações de software como serviço (SaaS).
- Todas as origens de dados têm um ponto final público acessível através da Internet.
- Os utilizadores empresariais necessitam de acesso a uma conta do Microsoft Purview e ao portal de governação do Microsoft Purview através da Internet.
Opções de runtime de integração
Para analisar origens de dados enquanto a firewall da conta do Microsoft Purview está definida para permitir o acesso público, pode utilizar todos os tipos de runtime de integração – o runtime de integração do Azure, o runtime de integração da VNet Gerida e um runtime de integração autoalojado. Saiba mais em Escolher a configuração do runtime de integração certa para o seu cenário.
Seguem-se algumas das melhores práticas:
Sempre que aplicável, recomendamos que utilize o runtime de integração do Azure ou o runtime de integração da VNet Gerida para analisar origens de dados, para reduzir os custos e os custos administrativos.
Os passos seguintes mostram o fluxo de comunicação a um nível elevado quando está a utilizar o runtime de integração do Azure para analisar uma origem de dados:
Observação
Este gráfico aplica-se apenas às contas do Microsoft Purview criadas após 15 de dezembro de 2023 (ou implementadas com a versão de API 2023-05-01-preview).
É iniciada uma análise manual ou automática a partir do Mapa de Dados do Microsoft Purview através do runtime de integração do Azure.
O runtime de integração do Azure liga-se à origem de dados para extrair metadados.
Os metadados são colocados em fila na conta de armazenamento de ingestão do Microsoft Purview e armazenados em Armazenamento de Blobs do Azure temporariamente.
Os metadados são enviados para o Mapa de Dados do Microsoft Purview.
A análise de origens de dados no local e baseadas em VMs requer sempre a utilização de um runtime de integração autoalojado. O runtime de integração do Azure não é suportado para estas origens de dados. Os passos seguintes mostram o fluxo de comunicação a um nível elevado quando está a utilizar um runtime de integração autoalojado para analisar uma origem de dados. O primeiro diagrama mostra um cenário em que os recursos estão no Azure ou numa VM no Azure. O segundo diagrama mostra um cenário com recursos no local. Os passos entre os dois são os mesmos na perspetiva do Microsoft Purview:
É acionada uma análise manual ou automática. O Microsoft Purview liga-se ao Azure Key Vault para obter a credencial para aceder a uma origem de dados.
A análise é iniciada a partir do Mapa de Dados do Microsoft Purview através de um runtime de integração autoalojado.
O serviço de runtime de integração autoalojado da VM ou do computador no local liga-se à origem de dados para extrair metadados.
Os metadados são processados na memória do computador para o runtime de integração autoalojado. Os metadados são colocados em fila no armazenamento de ingestão do Microsoft Purview e, em seguida, armazenados no Armazenamento de Blobs do Azure temporariamente. Os dados reais nunca saem do limite da sua rede.
Os metadados são enviados para o Mapa de Dados do Microsoft Purview.
Opções de autenticação
Quando estiver a analisar uma origem de dados no Microsoft Purview, tem de fornecer uma credencial. Em seguida, o Microsoft Purview pode ler os metadados dos recursos da origem de dados com o runtime de integração. Veja cada artigo de origem de dados para obter detalhes sobre os tipos de autenticação suportados e as permissões necessárias. As opções e os requisitos de autenticação variam com base nos seguintes fatores:
Tipo de origem de dados. Por exemplo, se a origem de dados for SQL do Azure Base de Dados, terá de utilizar um início de sessão com db_datareader acesso a cada base de dados. Pode ser uma identidade gerida atribuída pelo utilizador ou uma identidade gerida do Microsoft Purview. Em alternativa, pode ser um principal de serviço no Microsoft Entra ID adicionado ao Banco de Dados SQL como db_datareader.
Se a origem de dados for Armazenamento de Blobs do Azure, pode utilizar uma identidade gerida do Microsoft Purview ou um principal de serviço no Microsoft Entra ID adicionado como uma função de Leitor de Dados de Armazenamento de Blobs na conta de armazenamento do Azure. Em alternativa, utilize a chave da conta de armazenamento.
Tipo de autenticação. Recomendamos que utilize uma identidade gerida do Microsoft Purview para analisar origens de dados do Azure sempre que possível, para reduzir a sobrecarga administrativa. Para quaisquer outros tipos de autenticação, tem de configurar credenciais para a autenticação de origem no Microsoft Purview:
- Gerar um segredo dentro de um cofre de chaves do Azure.
- Registe o cofre de chaves no Microsoft Purview.
- No Microsoft Purview, crie uma nova credencial com o segredo guardado no cofre de chaves.
Tipo de runtime utilizado na análise. Atualmente, não pode utilizar uma identidade gerida do Microsoft Purview com um runtime de integração autoalojado.
Outras considerações
- Se optar por analisar origens de dados com pontos finais públicos, as VMs de runtime de integração autoalojadas têm de ter acesso de saída a origens de dados e pontos finais do Azure.
- As VMs do runtime de integração autoalojado têm de ter conectividade de saída aos pontos finais do Azure.
Opção 2: Utilizar pontos finais privados
À semelhança de outras soluções PaaS, o Microsoft Purview não suporta a implementação direta numa rede virtual. Por isso, não pode utilizar determinadas funcionalidades de rede com os recursos da oferta, tais como grupos de segurança de rede, tabelas de rotas ou outras aplicações dependentes da rede, como Firewall do Azure. Em vez disso, pode utilizar pontos finais privados que podem ser ativados na sua rede virtual. Em seguida, pode desativar o acesso público à Internet para ligar de forma segura ao Microsoft Purview.
Tem de utilizar pontos finais privados para a sua conta do Microsoft Purview se tiver algum dos seguintes requisitos:
Precisa de ter isolamento de rede ponto a ponto para contas e origens de dados do Microsoft Purview.
Tem de bloquear o acesso público às suas contas do Microsoft Purview.
As origens de dados paaS (plataforma como serviço) são implementadas com pontos finais privados e bloqueou todo o acesso através do ponto final público.
As origens de dados iaaS (infraestrutura como serviço) no local ou na infraestrutura (IaaS) não conseguem aceder aos pontos finais públicos.
Considerações de design
- Para ligar à sua conta do Microsoft Purview de forma privada e segura, tem de implementar uma conta e um ponto final privado do portal. Por exemplo, esta implementação é necessária se pretender ligar ao Microsoft Purview através da API ou utilizar o portal de governação do Microsoft Purview.
- Se precisar de se ligar ao portal de governação do Microsoft Purview através de pontos finais privados, tem de implementar pontos finais privados de conta e portal.
- Para analisar origens de dados através da conectividade privada, tem de configurar, pelo menos, uma conta e um ponto final privado de ingestão para o Microsoft Purview.
- Reveja os requisitos de DNS. Se estiver a utilizar um servidor DNS personalizado na sua rede, os clientes têm de conseguir resolve o nome de domínio completamente qualificado (FQDN) dos pontos finais da conta do Microsoft Purview para o endereço IP do ponto final privado.
Opções de runtime de integração
Para analisar origens de dados através da conectividade privada, pode utilizar o runtime de integração da VNet Gerida ou o runtime de integração autoalojado. Saiba mais em Escolher a configuração do runtime de integração certa para o seu cenário.
Sempre que aplicável, recomendamos que utilize o runtime de integração da VNet Gerida para analisar origens de dados, para reduzir os custos e os custos administrativos.
Se utilizar o runtime de integração autoalojado, terá de configurar e utilizar um runtime de integração autoalojado numa máquina virtual do Windows implementada dentro da mesma rede virtual ou numa rede virtual em modo de peering onde os pontos finais privados de ingestão do Microsoft Purview estão implementados.
Para analisar origens de dados no local, também pode instalar um runtime de integração autoalojado num computador Windows no local ou numa VM dentro de uma rede virtual do Azure.
Quando estiver a utilizar pontos finais privados com o Microsoft Purview, tem de permitir a conectividade de rede de origens de dados para a VM de integração autoalojada na rede virtual do Azure onde os pontos finais privados do Microsoft Purview estão implementados.
Recomendamos que permita a atualização automática do runtime de integração autoalojado. Certifique-se de que abre as regras de saída necessárias na rede virtual do Azure ou na firewall empresarial para permitir a atualização automática. Para obter mais informações, veja Requisitos de rede do runtime de integração autoalojado.
Opções de autenticação
Certifique-se de que as suas credenciais estão armazenadas num cofre de chaves do Azure e registadas no Microsoft Purview.
Tem de criar uma credencial no Microsoft Purview com base em cada segredo que criar no cofre de chaves do Azure. Tem de atribuir, no mínimo, acesso de obtenção e lista de segredos para o Microsoft Purview no recurso Key Vault no Azure. Caso contrário, as credenciais não funcionarão na conta do Microsoft Purview.
Limitações atuais
Analisar várias origens do Azure através de toda a subscrição ou grupo de recursos através de pontos finais privados de ingestão e de um runtime de integração autoalojado ou do runtime de integração da VNet Gerida não é suportado quando utiliza pontos finais privados para ingestão. Em vez disso, pode registar e analisar origens de dados individualmente.
Para obter limitações relacionadas com pontos finais privados do Microsoft Purview, veja Limitações conhecidas.
Para obter limitações relacionadas com o serviço Link Privado, veja limites de Link Privado do Azure.
Cenários de pontos finais privados
Rede virtual única, região única
Neste cenário, todas as origens de dados do Azure, as VMs de runtime de integração autoalojadas e os pontos finais privados do Microsoft Purview são implementados na mesma rede virtual numa subscrição do Azure.
Se existirem origens de dados no local, a conectividade é fornecida através de uma VPN site a site ou conectividade do Azure ExpressRoute a uma rede virtual do Azure onde os pontos finais privados do Microsoft Purview estão implementados.
Esta arquitetura é adequada principalmente para pequenas organizações ou para cenários de desenvolvimento, teste e prova de conceito.
Região única, várias redes virtuais
Para ligar duas ou mais redes virtuais no Azure em conjunto, pode utilizar o peering de rede virtual. O tráfego de rede entre redes virtuais em modo de peering é privado e é mantido na rede principal do Azure.
Muitos clientes criam a infraestrutura de rede no Azure com a arquitetura de rede hub-and-spoke, onde:
- Os serviços partilhados de rede (como aplicações virtuais de rede, gateways expressRoute/VPN ou servidores DNS) são implementados na rede virtual do hub.
- As redes virtuais spoke consomem esses serviços partilhados através do peering de rede virtual.
Nas arquiteturas de rede hub-and-spoke, a equipa de governação de dados da sua organização pode ser fornecida com uma subscrição do Azure que inclui uma rede virtual (hub). Todos os serviços de dados podem estar localizados em algumas outras subscrições ligadas à rede virtual do hub através de um peering de rede virtual ou de uma ligação VPN site a site.
Numa arquitetura hub-and-spoke, pode implementar o Microsoft Purview e uma ou mais VMs de runtime de integração autoalojadas na subscrição do hub e na rede virtual. Pode registar e analisar origens de dados de outras redes virtuais a partir de várias subscrições na mesma região.
As VMs do runtime de integração autoalojado podem ser implementadas dentro da mesma rede virtual do Azure ou numa rede virtual em modo de peering onde os pontos finais privados da conta e da ingestão são implementados.
Opcionalmente, pode implementar outro runtime de integração autoalojado nas redes virtuais spoke.
Várias regiões, várias redes virtuais
Se as origens de dados estiverem distribuídas por várias regiões do Azure numa ou mais subscrições do Azure, pode utilizar este cenário.
Para otimização do desempenho e dos custos, recomendamos vivamente a implementação de uma ou mais VMs de runtime de integração autoalojadas em cada região onde estão localizadas as origens de dados.
Analisar com o Runtime da VNet Gerida
Pode utilizar o Runtime da VNet Gerida para analisar origens de dados numa rede privada. Saiba mais em Utilizar uma VNet Gerida com a sua conta do Microsoft Purview.
A utilização do Runtime da VNet Gerida ajuda a minimizar a sobrecarga administrativa da gestão do runtime e a reduzir a duração geral da análise.
Para analisar quaisquer origens de dados do Azure através da rede privada com o Runtime de VNet Gerida, tem de ser implementado um ponto final privado gerido no Microsoft Purview Managed Rede Virtual, mesmo que a origem de dados já tenha uma rede privada na sua subscrição do Azure.
Se precisar de analisar origens de dados no local ou origens de dados adicionais no Azure que não são suportadas pelo Runtime de VNet Gerida, pode implementar o Runtime de VNet Gerida e o Runtime de integração autoalojado.
Se o Microsoft Purview não estiver disponível na sua região primária
O Microsoft Purview é uma solução de plataforma como serviço do Azure. Pode implementar uma conta do Microsoft Purview na sua subscrição do Azure em todas as regiões do Azure suportadas.
Se o Microsoft Purview não estiver disponível na sua região principal do Azure, considere os seguintes fatores ao escolher uma região secundária para implementar a sua conta do Microsoft Purview:
- Reveja a latência entre a região primária do Azure onde as origens de dados são implementadas e a região secundária do Azure, onde a conta do Microsoft Purview será implementada. Para obter mais informações, veja Estatísticas de latência de ida e volta da rede do Azure.
- Reveja os requisitos de residência dos dados. Quando analisa origens de dados no Mapa de Dados do Microsoft Purview, as informações relacionadas com os metadados são ingeridas e armazenadas no mapa de dados na região do Azure onde a sua conta do Microsoft Purview é implementada. Para obter mais informações, veja Onde estão armazenados os metadados.
- Reveja os requisitos de rede e segurança se for necessária conectividade de rede privada para acesso de utilizadores ou ingestão de metadados. Para obter mais informações, veja Se o Microsoft Purview não estiver disponível na sua região primária.
Opção 1: implemente a sua conta do Microsoft Purview numa região secundária e implemente todos os pontos finais privados na região primária, onde estão localizadas as origens de dados do Azure. Para este cenário:
- Esta é a opção recomendada, se Austrália Sudeste for a região primária de todas as origens de dados e tiver todos os recursos de rede implementados na região primária.
- Implemente uma conta do Microsoft Purview na sua região secundária (por exemplo, Leste da Austrália).
- Implemente todos os pontos finais privados do Microsoft Purview, incluindo a conta, o portal e a ingestão na região primária (por exemplo, Austrália Sudeste).
- Implementar todo o [runtime de integração autoalojado do Microsoft Purview](.. / manage-integration-runtimes.md) VMs na região primária (por exemplo, Austrália Sudeste). Isto ajuda a reduzir o tráfego entre regiões, uma vez que as análises do Mapa de Dados ocorrerão na região local onde estão localizadas origens de dados e apenas os metadados são ingeridos na região secundária onde a sua conta do Microsoft Purview está implementada.
- Se utilizar VNets Geridas do Microsoft Purview para ingestão de metadados, o Runtime da VNet Gerida e todos os pontos finais privados geridos serão implementados automaticamente na região onde o Microsoft Purview está implementado (por exemplo, Leste da Austrália).
Opção 2: implemente a sua conta do Microsoft Purview numa região secundária e implemente pontos finais privados nas regiões primária e secundária. Para este cenário:
- Esta opção é recomendada se tiver origens de dados em regiões primárias e secundárias e os utilizadores estiverem ligados através da região primária.
- Implemente uma conta do Microsoft Purview na sua região secundária (por exemplo, Leste da Austrália).
- Implemente o ponto final privado do portal de governação do Microsoft Purview na região primária (por exemplo, Austrália Sudeste) para o acesso dos utilizadores ao portal de governação do Microsoft Purview.
- Implemente pontos finais privados de ingestão e conta do Microsoft Purview na região primária (por exemplo, Austrália sudeste) para analisar as origens de dados localmente na região primária.
- Implemente pontos finais privados de ingestão e conta do Microsoft Purview na região secundária (por exemplo, Leste da Austrália) para analisar origens de dados localmente na região secundária.
- Implementar [Runtime de integração autoalojado do Microsoft Purview](.. / manage-integration-runtimes.md) VMs em regiões primárias e secundárias. Isto ajudará a manter o tráfego de análise de mapa de dados na região local e enviará apenas metadados para Mapa de Dados do Microsoft Purview onde está configurado na sua região secundária (por exemplo, Leste da Austrália).
- Se utilizar VNets Geridas do Microsoft Purview para ingestão de metadados, o Runtime da VNet Gerida e todos os pontos finais privados geridos serão implementados automaticamente na região onde o Microsoft Purview está implementado (por exemplo, Leste da Austrália).
Configuração de DNS com pontos finais privados
Resolução de nomes para várias contas do Microsoft Purview
Recomenda-se que siga estas recomendações se a sua organização precisar de implementar e manter múltiplas contas do Microsoft Purview através de pontos finais privados:
- Implemente pelo menos um ponto final privado de conta para cada conta do Microsoft Purview.
- Implemente pelo menos um conjunto de pontos finais privados de ingestão para cada conta do Microsoft Purview.
- Implemente um ponto final privado do portal para uma das contas do Microsoft Purview nos seus ambientes do Azure. Crie um registo DNS A para o ponto final privado do portal resolve
web.purview.azure.com. O ponto final privado do portal pode ser utilizado por todas as contas do Purview na mesma rede virtual do Azure ou redes virtuais ligadas através do VNet Peering.
Este cenário também se aplica se forem implementadas várias contas do Microsoft Purview em várias subscrições e várias VNets ligadas através do VNet Peering. O ponto final privado do portal compõe principalmente recursos estáticos relacionados com o portal de governação do Microsoft Purview, pelo que é independente da conta do Microsoft Purview, pelo que só é necessário um ponto final privado do portal para visitar todas as contas do Microsoft Purview no ambiente do Azure se as VNets estiverem ligadas.
Observação
Poderá ter de implementar pontos finais privados do portal separados para cada conta do Microsoft Purview nos cenários em que as contas do Microsoft Purview são implementadas em segmentações de rede isoladas.
O portal do Microsoft Purview é um conteúdo estático para todos os clientes sem qualquer informação do cliente. Opcionalmente, pode utilizar a rede pública (sem o ponto final privado do portal) para iniciar web.purview.azure.com se os utilizadores finais tiverem permissão para iniciar a Internet.
Opção 3: Utilizar pontos finais públicos e privados
Pode escolher uma opção na qual um subconjunto das origens de dados utiliza pontos finais privados e, ao mesmo tempo, tem de analisar uma das seguintes opções:
- Outras origens de dados configuradas com um ponto final de serviço
- Origens de dados que têm um ponto final público acessível através da Internet
Se precisar de analisar algumas origens de dados com um ponto final privado de ingestão e algumas origens de dados com pontos finais públicos ou um ponto final de serviço, pode:
- Utilize pontos finais privados para a sua conta do Microsoft Purview.
- Defina Acesso à rede públicacomo Ativado a partir de todas as redes na sua conta do Microsoft Purview.
Opções de runtime de integração
Para analisar uma origem de dados do Azure configurada com um ponto final privado, tem de configurar e utilizar um runtime de integração autoalojado numa máquina virtual do Windows implementada dentro da mesma rede virtual ou em modo de peering onde os pontos finais privados de ingestão e conta do Microsoft Purview são implementados.
Quando estiver a utilizar um ponto final privado com o Microsoft Purview, tem de permitir a conectividade de rede de origens de dados para uma VM de integração autoalojada na rede virtual do Azure onde os pontos finais privados do Microsoft Purview estão implementados.
Para analisar uma origem de dados do Azure configurada para permitir um ponto final público, pode utilizar o runtime de integração do Azure.
Para analisar origens de dados no local, também pode instalar um runtime de integração autoalojado num computador Windows no local ou numa VM dentro de uma rede virtual do Azure.
Recomendamos que permita a atualização automática para um runtime de integração autoalojado. Certifique-se de que abre as regras de saída necessárias na rede virtual do Azure ou na firewall empresarial para permitir a atualização automática. Para obter mais informações, veja Requisitos de rede do runtime de integração autoalojado.
Opções de autenticação
Para analisar uma origem de dados do Azure configurada para permitir um ponto final público, pode utilizar qualquer opção de autenticação, com base no tipo de origem de dados.
Se utilizar um ponto final privado de ingestão para analisar uma origem de dados do Azure configurada com um ponto final privado:
Não pode utilizar uma identidade gerida do Microsoft Purview. Em vez disso, utilize um principal de serviço, uma chave de conta ou autenticação SQL, com base no tipo de origem de dados.
Certifique-se de que as suas credenciais estão armazenadas num cofre de chaves do Azure e registadas no Microsoft Purview.
Tem de criar uma credencial no Microsoft Purview com base em cada segredo que criar no Azure Key Vault. No mínimo, atribua acesso de obtenção e lista de segredos para o Microsoft Purview no recurso Key Vault no Azure. Caso contrário, as credenciais não funcionarão na conta do Microsoft Purview.
Opção 4: Utilizar pontos finais privados apenas para ingestão
Pode escolher esta opção se precisar de:
- Analise todas as origens de dados com o ponto final privado de ingestão.
- Os recursos geridos têm de ser configurados para desativar a rede pública.
- Ativar o acesso ao portal de governação do Microsoft Purview através da rede pública.
Para ativar esta opção:
- Configure o ponto final privado de ingestão para a sua conta do Microsoft Purview.
- Defina Acesso à rede pública como Desativado apenas para ingestão (Pré-visualização) na sua conta do Microsoft Purview.
Opções de runtime de integração
Siga a recomendação para a opção 2.
Opções de autenticação
Siga a recomendação para a opção 2.
Recomendações de proxy e rede de runtime de integração autoalojado
Para analisar origens de dados nas suas redes no local e no Azure, poderá ter de implementar e utilizar uma ou várias máquinas virtuais de runtime de integração autoalojadas dentro de uma VNet do Azure ou de uma rede no local, para qualquer um dos cenários mencionados anteriormente neste documento.
Para simplificar a gestão, sempre que possível, utilize o IR do Azure e o IR da VNet Gerida do Microsoft Purview para analisar origens de dados.
O serviço runtime de integração autoalojado pode comunicar com o Microsoft Purview através da rede pública ou privada através da porta 443. Para obter mais informações, veja Requisitos de rede do runtime de integração autoalojado.
Uma VM de runtime de integração autoalojada pode ser utilizada para analisar uma ou várias origens de dados no Microsoft Purview. No entanto, o runtime de integração autoalojado só tem de ser registado para o Microsoft Purview e não pode ser utilizado para Azure Data Factory ou Azure Synapse ao mesmo tempo.
Pode registar e utilizar um ou vários runtimes de integração autoalojados numa conta do Microsoft Purview. Recomenda-se que coloque, pelo menos, uma VM de runtime de integração autoalojada em cada região ou rede no local onde residem as origens de dados.
Recomenda-se definir uma linha de base para a capacidade necessária para cada VM do runtime de integração autoalojado e dimensionar a capacidade da VM com base na procura.
É recomendado configurar a ligação de rede entre VMs de runtime de integração autoalojadas e o Microsoft Purview e os respetivos recursos geridos através da rede privada, sempre que possível.
Permita a conectividade de saída para download.microsoft.com, se a atualização automática estiver ativada.
O serviço de runtime de integração autoalojado não requer conectividade internet de saída, se as VMs do runtime de integração autoalojadas forem implementadas numa VNet do Azure ou na rede no local que está ligada ao Azure através de uma ligação expressRoute ou VPN site a site. Neste caso, o processo de ingestão de metadados e análise pode ser feito através da rede privada.
O runtime de integração autoalojado pode comunicar o Microsoft Purview e os respetivos recursos geridos diretamente ou através de um servidor proxy. Evite utilizar as definições de proxy se a VM do runtime de integração autoalojado estiver dentro de uma VNet do Azure ou se estiver ligada através do ExpressRoute ou da ligação VPN Site a Site.
Reveja os cenários suportados, se precisar de utilizar o runtime de integração autoalojado com a definição de proxy.