É possível que os usuários na sua organização acessem dados locais (para os quais eles já têm autorização de acesso), mas antes que eles possam se conectar à fonte de dados local, um gateway de dados local precisa ser instalado e configurado. O gateway facilita a comunicação nos bastidores, de maneira rápida e segura, de um usuário na nuvem para a fonte de dados local, retornando à nuvem em seguida.

A instalação e configuração de um gateway geralmente são feitas por um administrador. Esse processo pode necessitar de conhecimento especial sobre seus servidores locais e, em alguns casos, pode exigir permissões do Administrador do Servidor.

Este artigo não fornece orientações passo a passo sobre como instalar e configurar o gateway. Para fazer isso, não deixe de conferir Gateway de Dados Local. Este artigo destina-se a fornecer uma compreensão detalhada de como o gateway funciona. Também veremos alguns detalhes sobre nomes de usuário e segurança no Azure Active Directory e no Analysis Services, além de como o serviço de nuvem usa o endereço de email que um usuário usa para entrar no gateway e no Active Directory para se conectar com segurança aos dados locais e consultá-los.

Como funciona o gateway

on-prem-data-gateway-how-it-works

Primeiro vamos examinar o que acontece quando um usuário interage com um elemento conectado a uma fonte de dados local.

Observação:

Para o Power BI, você precisará configurar uma fonte de dados para o gateway.

  1. Uma consulta será criada pelo serviço de nuvem, juntamente com as credenciais criptografadas para a fonte de dados local, e enviada à fila para ser processada pelo gateway.

  2. O serviço de nuvem do gateway analisará a consulta e enviará por push a solicitação para o Barramento de Serviço do Azure.

  3. O gateway de dados local pesquisa o Barramento de Serviço do Azure em busca de solicitações pendentes.

  4. O gateway obtém a consulta, descriptografa as credenciais e conecta-se à(s) fonte(s) de dados com essas credenciais.

  5. O gateway envia a consulta à fonte de dados para execução.

  6. Os resultados são enviados da fonte de dados, de volta ao gateway e, em seguida, ao serviço de nuvem. Em seguida, o serviço usa os resultados.

Relação dos tipos de fonte de dados disponíveis

Fonte de dados Live/DirectQuery Atualização manual ou agendada configurada pelo usuário
Tabela do Analysis Services Sim Sim
Multidimensional do Analysis Services Sim Sim
SQL Server Sim Sim
SAP HANA Sim Sim
Oracle Sim Sim
Teradata Sim Sim
Arquivo Não Sim
Pasta Não Sim
Relação do SharePoint (local) Não Sim
Web Não Sim
OData Não Sim
IBM DB2 Não Sim
MySQL Não Sim
Sybase Não Sim
SAP BW Não Sim
Banco de dados do IBM Informix Não Sim
ODBC Não Sim

Conta de entrada

Os usuários entrarão com uma conta corporativa ou de estudante. Essa é a conta de sua organização. Se você se inscreveu para uma oferta do Office 365 e não forneceu seu email de trabalho real, ela poderá ser semelhante a nancy@contoso.onmicrosoft.com. Sua conta, em um serviço de nuvem, é armazenada em um locatário do AAD (Azure Active Directory). Na maioria dos casos, o UPN de sua conta do AAD corresponderá ao endereço de email.

Autenticação em fontes de dados locais

Uma credencial armazenada será usada para se conectar a fontes de dados locais do gateway, exceto o Analysis Services. Independentemente do usuário individual, o gateway usa a credencial armazenada para se conectar.

Autenticação em uma fonte de dados dinâmica do Analysis Services

Cada vez que um usuário interage com o Analysis Services, o nome de usuário efetivo é passado para o gateway e, em seguida, para o servidor local do Analysis Services. O nome UPN, normalmente, o endereço de email que você usa para entrar na nuvem, é o que passaremos para o Analysis Services como o usuário efetivo. O nome UPN é passado na propriedade de conexão EffectiveUserName. Esse endereço de email deve corresponder a um UPN definido no domínio do Active Directory local. O UPN é uma propriedade de uma conta do Active Directory. Essa conta do Windows precisará estar presente em uma função do Analysis Services para que ela tenha acesso ao servidor. O logon não terá êxito se nenhuma correspondência for encontrada no Active Directory.

O Analysis Services também poderá fornecer a filtragem com base nessa conta. A filtragem pode ocorrer com a segurança baseada em função ou com a segurança em nível de linha.

Segurança baseada em função

Modelos fornecem segurança baseada em funções de usuário. Funções são definidas para um projeto de modelo específico durante a criação no SSDT-BI (SQL Server Data Tools – Business Intelligence), ou depois que um modelo é implantado usando o SSMS (SQL Server Management Studio). As funções contêm membros organizados por nome de usuário do Windows ou por grupo do Windows. As funções definem as permissões de que um usuário dispõe para consultar ou executar ações no modelo. A maioria dos usuários pertencerão a uma função com permissões de Leitura. Outras funções são destinadas a administradores com permissões para processar itens e gerenciar funções, tanto de banco de dados quanto de outros tipos.

Segurança em nível de linha

A segurança em nível de linha é específica para a segurança em nível de linha do Analysis Services. Os modelos podem fornecem segurança dinâmica no nível de linha. Em vez de ter pelo menos uma função à qual os usuários pertencem, a segurança dinâmica não é requerida para nenhum modelo de tabela. Em um nível elevado, a segurança dinâmica define o acesso de leitura de um usuário aos dados diretamente para uma linha específica em uma tabela específica. De modo similar ao que ocorre nas funções, a segurança dinâmica no nível de linha depende de um nome de usuário do Windows.

A capacidade de um usuário de consultar e ver dados de modelo é determinada, primeiramente, pelas funções das quais sua conta de usuário do Windows é membro e, em segundo lugar, pela segurança dinâmica em nível de linha, se estiver configurada.

A implementação de segurança dinâmica em nível de linha e a segurança baseada em função em modelos está além do escopo deste artigo. Saiba mais em Funções (SSAS de tabela) e Funções de segurança (Analysis Services – dados multidimensionais) no MSDN. Além disso, para obter uma compreensão mais profunda sobre a segurança do modelo de tabela, baixe e leia o white paper Securing the Tabular BI Semantic Model (Protegendo o modelo semântico de BI de tabela).

E quanto ao Active Directory do Azure?

Os serviços em nuvem da Microsoft usam o Azure Active Directory para cuidar da autenticação de usuários. O Azure Active Directory é o locatário que contém nomes de usuário e grupos de segurança. Normalmente, um endereço de email usado para a entrada de um usuário é o mesmo que o UPN da conta.

Qual é a função do meu Active Directory local?

Para que o Analysis Services determine se um usuário que se conecta a ele pertence a uma função com permissões para leitura de dados, o servidor precisa converter o nome de usuário efetivo passado do ADD para o gateway e, em seguida, para o servidor do Analysis Services. O servidor do Analysis Services passa o nome de usuário efetivo para um DC (controlador de domínio) do Active Directory do Windows. Em seguida, o DC Active Directory valida o nome de usuário efetivo como um UPN válido, em uma conta local, e retorna esse nome de usuário do Windows do usuário de volta ao servidor do Analysis Services.

EffectiveUserName não pode ser usado em um servidor do Analysis Services que não foi ingressado em domínio. O servidor do Analysis Services deve ser ingressado em um domínio para evitar erros de logon.

Como saber qual é a minha UPN?

Talvez você não saiba o que é o UPN e talvez você não seja um administrador de domínio. Você pode usar o comando a seguir em sua estação de trabalho para descobrir o UPN para sua conta.

whoami /upn

O resultado será semelhante a um endereço de email, mas esse é o UPN que está em sua conta de domínio local. Se você estiver usando uma fonte de dados do Analysis Services para conexões dinâmicas, ela deverá corresponder ao que foi passado para EffectiveUserName por meio do gateway.

Mapeando nomes de usuário para fontes de dados do Analysis Services

O Power BI possibilita o mapeamento de nomes de usuário para fontes de dados do Analysis Services. É possível configurar regras para mapear um nome de usuário conectado com o Power BI para um nome passado para EffectiveUserName na conexão do Analysis Services. O recurso Mapear nomes de usuário é uma ótima maneira de solucionar problemas quando seu nome de usuário no AAD não corresponde a um UPN no Active Directory local. Por exemplo, se seu endereço de email fosse nancy@contoso.onmicrsoft.com, você poderia mapeá-lo para nancy@contoso.com e esse valor seria passado para o gateway. Saiba mais sobre como mapear nomes de usuário.

Sincronizar um Active Directory local com o Active Directory do Azure

Você desejará que suas contas do Active Directory local correspondam ao Azure Active Directory se você for usar conexões dinâmicas do Analysis Services, já que o UPN deve ser correspondente entre as contas.

Os serviços de nuvem conhecem apenas as contas no Azure Active Directory. Não importa se você adicionou uma conta no Active Directory local, se ela não existir no AAD, não poderá ser usada. Há diferentes maneiras pelas quais você poderá corresponder suas contas do Active Directory local ao Azure Active Directory.

  1. É possível adicionar contas manualmente ao Azure Active Directory.

    É possível criar uma conta no portal do Azure ou no Portal de Administração do Office 365, e o nome da conta corresponderá ao UPN da conta do Active Directory local.

  2. Você pode usar a ferramenta Azure AD Connect para sincronizar contas locais ao seu locatário do Azure Active Directory.

    A ferramenta Azure AD Connect fornece opções para a sincronização de diretório e senha. Se você não for um administrador de locatários nem um administrador de domínio local, precisará entrar em contato com seu administrador de TI para obter essa configuração.

  3. Você pode configurar o ADFS (Serviços de Federação do Active Directory).

    É possível associar seu servidor do ADFS ao locatário do AAD com a ferramenta Azure AD Connect. O ADFS faz uso da sincronização de diretórios abordada acima, mas permite uma experiência de SSO (Logon Único). Por exemplo, se você estiver em sua rede corporativa, quando acessar um serviço de nuvem e entrar nele, talvez não seja solicitado que você insira um nome de usuário ou uma senha. Você precisará conversar com seu Administrador de TI caso essa opção esteja disponível para sua organização.

O uso do Azure AD Connect garante que o UPN corresponderá entre o AAD e o Active Directory local.

Observação:

A sincronização de contas com a ferramenta Azure AD Connect criará novas contas em seu locatário do AAD.

Agora, é aqui que entra o gateway

O gateway atua como uma ponte entre a nuvem e o servidor local. A transferência de dados entre a nuvem e o gateway é protegida pelo Barramento de Serviço do Azure. O Barramento de Serviço cria um canal seguro entre a nuvem e o servidor local por meio de uma conexão de saída no gateway. Não é necessário abrir nenhuma conexão de entrada no firewall local.

Se você tiver uma fonte de dados do Analysis Services, você precisará instalar o gateway em um computador associado ao mesmo domínio/floresta que o servidor do Analysis Services.

Quanto mais próximo o gateway está do servidor, mais rápida será a conexão. Se você pode obter o gateway no mesmo servidor que a fonte de dados, isso é melhor para evitar a latência da rede entre o gateway e o servidor.

O que fazer em seguida?

Depois que o gateway for instalado, você desejará criar fontes de dados para ele. Você pode adicionar fontes de dados na tela Gerenciar gateways. Para obter mais informações, consulte os artigos sobre gerenciar fontes de dados.

Gerenciar sua fonte de dados – Analysis Services
Gerenciar sua fonte de dados – SAP HANA
Gerenciar sua fonte de dados – SQL Server
Gerenciar sua fonte de dados – Oracle
Gerenciar sua fonte de dados – Importar/Atualização agendada

O que pode dar errado

Às vezes, a instalação do gateway falha. Ou talvez o gateway pareça ser instalado sem problemas, mas o serviço ainda não poderá trabalhar com ele. Em muitos casos, é algo simples, como a senha para as credenciais que o gateway usa para entrar na fonte de dados.

Em outros casos, pode haver problemas com o tipo de endereço de email com que os usuários se autenticam, ou com ou incapacidade do Analysis Services de resolver um nome de usuário efetivo. Caso você tenha vários domínios com relações de confiança entre eles, e o gateway estiver em um domínio e o Analysis Services em outro, às vezes, isso poderá causar alguns problemas.

Em vez de explorar a solução de problemas do gateway aqui, apresentamos uma série de etapas de solução de problemas em outro artigo: Troubleshooting the On-Premises Data Gateway (Solução de problemas do Gateway de Dados Local). Esperamos que você não tenha nenhum problema. Mas se acontecer, um entendimento de como tudo isso funciona e o artigo de solução de problemas devem ajudar.

Conta de entrada

Os usuários entrarão com uma conta corporativa ou de estudante. Essa é a conta de sua organização. Se você se inscreveu para uma oferta do Office 365 e não forneceu seu email de trabalho real, ela poderá ser semelhante a nancy@contoso.onmicrosoft.com. Sua conta, em um serviço de nuvem, é armazenada em um locatário do AAD (Azure Active Directory). Na maioria dos casos, o UPN de sua conta do AAD corresponderá ao endereço de email.

Conta do Serviço Windows

O gateway de dados local está configurado para usar NT SERVICE\PBIEgwService como a credencial de logon do serviço Windows. Por padrão, ele tem o direito de Fazer logon como serviço. Isso está no contexto do computador no qual você está instalando o gateway.

Observação:

Se você selecionou o modo pessoal, configure a conta de serviço Windows separadamente.

Essa não é a conta usada para se conectar a fontes de dados locais. Também não é sua conta corporativa ou de estudante que você usa para entrar nos serviços de nuvem.

Caso tenha problemas com o servidor proxy devido à autenticação, uma sugestão é alterar a conta do serviço Windows para um usuário de domínio ou conta de serviço gerenciado. É possível aprender alterar a conta na configuração de proxy.

Portas

O gateway cria uma conexão de saída para o Barramento de Serviço do Azure. Ele se comunica com as portas de saída TCP 443 (padrão), 5671, 5672, 9350 a 9354. O gateway não requer portas de entrada. Saiba mais

É recomendável colocar os endereços IP no seu firewall, para sua região de dados, na lista branca. Você pode baixar a lista de IP do Data Center do Microsoft Azure. Essa lista é atualizada semanalmente. O gateway se comunicará com o Barramento de Serviço do Azure usando o endereço IP junto com o nome de domínio totalmente qualificado (FQDN). Se você estiver forçando o gateway a se comunicar usando HTTPS, ele usará apenas o FQDN de forma exclusiva e nenhuma comunicação acontecerá usando endereços IP.

Observação:

Os Endereços IP listados na lista de IP do Data Center do Azure estão na notação CIDR. Por exemplo, 10.0.0.0/24 não significa 10.0.0.0 até 10.0.0.24. Saiba mais sobre a notação CIDR.

Esta é uma lista dos nomes de domínio totalmente qualificados usados pelo gateway.

Nomes de domínio Portas de saída Descrição
*.download.microsoft.com 80 HTTP usado para baixar o instalador.
*.powerbi.com 443 HTTPS
*.analysis.windows.net 443 HTTPS
*.login.windows.net 443 HTTPS
*.servicebus.windows.net 5671-5672 Advanced Message Queuing Protocol (AMQP)
*.servicebus.windows.net 443, 9350-9354 Ouvintes na Retransmissão do Barramento de Serviço por TCP (requer 443 para aquisição de token de Controle de Acesso)
*.frontend.clouddatahub.net 443 HTTPS
*.core.windows.net 443 HTTPS
login.microsoftonline.com 443 HTTPS
*.msftncsi.com 443 Usado para testar a conectividade com a Internet se o gateway não estiver acessível pelo serviço do Power BI.
*.microsoftonline-p.com 443 Usado para autenticação, dependendo da configuração.
Observação:

O tráfego direcionado para visualstudio.com ou visualstudioonline.com é para o App Insights e não é necessário para que o gateway funcione.

Forçar a comunicação HTTPS com o Barramento de Serviço do Azure

Você pode forçar o Gateway a se comunicar com o Barramento de Serviço do Azure usando HTTPS em vez de TCP direto. Isso pode ter um impacto no desempenho. Para fazer isso, modifique o arquivo Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config, alterando o valor de AutoDetect para Https, conforme mostrado no trecho de código logo após este parágrafo. Este arquivo está localizado (por padrão) em C:\Arquivos de Programas\Gateway de dados local.

<setting name="ServiceBusSystemConnectivityModeString" serializeAs="String">
    <value>Https</value>
</setting>

Como alternativa, você pode forçar o gateway a adotar este comportamento usando a interface do usuário do gateway, começando com a versão de março de 2017. Na interface do usuário do Gateway, selecione Rede e, em seguida, alterne o modo de conectividade do Barramento de Serviço do Azure para Ativado.

Depois de alterado, ao selecionar Aplicar (um botão que aparece somente quando você faz uma alteração), o gateway do serviço Windows será reiniciado automaticamente para que as alterações tenham efeito.

Para referência futura, você pode reiniciar o gateway do serviço Windows na caixa de diálogo de interface do usuário, selecionando Configurações de serviço e, em seguida, Reiniciar agora.

Alta Disponibilidade

Opções de alta disponibilidade estão previstas para o gateway. Fique ligado para saber sobre mais atualizações.

Como reiniciar o gateway

O gateway é executado como um serviço Windows. É possível iniciar e pará-lo como qualquer serviço Windows. Há várias maneiras de fazer isso. Veja abaixo como é possível fazer isso no prompt de comando.

  1. No computador em que o gateway está em execução, inicie um prompt de comando do administrador.

  2. Use o seguinte comando para interromper o serviço.

    net stop PBIEgwService

  3. Use o seguinte comando para iniciar o serviço.

    net start PBIEgwService

Consulte também

Solução de problemas do Gateway de dados local
Barramento de serviço do Azure
Azure AD Connect
Mais perguntas? Experimente a Comunidade do Power BI