Considerações de segurança para o movimento de dados no Azure Data Factory
APLICA-SE A: 
Azure Data Factory Azure Synapse Analytics
Gorjeta
Experimente o Data Factory no Microsoft Fabric, uma solução de análise tudo-em-um para empresas. O Microsoft Fabric abrange tudo, desde a movimentação de dados até ciência de dados, análises em tempo real, business intelligence e relatórios. Saiba como iniciar uma nova avaliação gratuitamente!
Este artigo descreve a infraestrutura de segurança básica que os serviços de movimentação de dados no Azure Data Factory usam para ajudar a proteger seus dados. Os recursos de gerenciamento do Data Factory são criados na infraestrutura de segurança do Azure e usam todas as medidas de segurança possíveis oferecidas pelo Azure.
Numa solução do Data Factory, pode criar um ou mais pipelines de dados. Um pipeline é um agrupamento lógico de atividades que, em conjunto, executam uma tarefa. Estes pipelines residem na região onde a fábrica de dados foi criada.
Embora o Data Factory esteja disponível apenas em algumas regiões, o serviço de movimentação de dados está disponível globalmente para garantir a conformidade dos dados, a eficiência e a redução dos custos de saída da rede.
O Azure Data Factory, incluindo o Tempo de Execução de Integração do Azure e o Tempo de Execução de Integração Auto-hospedado, não armazena dados temporários, dados de cache ou logs, exceto credenciais de serviço vinculado para armazenamentos de dados em nuvem, que são criptografados usando certificados. Com o Data Factory, você cria fluxos de trabalho orientados por dados para orquestrar a movimentação de dados entre armazenamentos de dados suportados e o processamento de dados usando serviços de computação em outras regiões ou em um ambiente local. Também pode monitorizar e gerir fluxos de trabalho com os SDKs e o Azure Monitor.
O Data Factory foi certificado para:
Se você estiver interessado na conformidade do Azure e em como o Azure protege sua própria infraestrutura, visite a Central de Confiabilidade da Microsoft. Para obter a lista mais recente de todas as ofertas de Conformidade do Azure, verifique - https://aka.ms/AzureCompliance.
Neste artigo, analisamos as considerações de segurança nos dois cenários de movimentação de dados a seguir:
- Cenário de nuvem: neste cenário, tanto a sua origem como o seu destino são acessíveis publicamente através da Internet. Isso inclui serviços de armazenamento em nuvem gerenciados, como o Armazenamento do Azure, o Azure Synapse Analytics, o Banco de Dados SQL do Azure, o Azure Data Lake Store, o Amazon S3, o Amazon Redshift, serviços SaaS, como o Salesforce, e protocolos da Web, como FTP e OData. Encontre uma lista completa de fontes de dados suportadas em Armazenamentos e formatos de dados suportados.
- Cenário híbrido: nesse cenário, sua origem ou seu destino está atrás de um firewall ou dentro de uma rede corporativa local. Ou, o armazenamento de dados está em uma rede privada ou rede virtual (na maioria das vezes a fonte) e não é acessível publicamente. Os servidores de banco de dados hospedados em máquinas virtuais também se enquadram nesse cenário.
Nota
Recomendamos que utilize o módulo Azure Az do PowerShell para interagir com o Azure. Para começar, consulte Instalar o Azure PowerShell. Para saber como migrar para o módulo do Az PowerShell, veja Migrar o Azure PowerShell do AzureRM para o Az.
Cenários de nuvem
Protegendo as credenciais de armazenamento de dados
- Armazene credenciais criptografadas em um repositório gerenciado do Azure Data Factory. O Data Factory ajuda a proteger suas credenciais de armazenamento de dados criptografando-as com certificados gerenciados pela Microsoft. Esses certificados são alternados a cada dois anos (o que inclui a renovação do certificado e a migração de credenciais). Para obter mais informações sobre a segurança do Armazenamento do Azure, consulte Visão geral da segurança do Armazenamento do Azure.
- Armazene credenciais no Cofre da Chave do Azure. Você também pode armazenar a credencial do armazenamento de dados no Cofre de Chaves do Azure. O Data Factory recupera a credencial durante a execução de uma atividade. Para obter mais informações, veja Armazenar credenciais no Azure Key Vault.
Ao centralizar o armazenamento dos segredos das aplicações no Azure Key Vault, pode controlar a distribuição dos mesmos. O Key Vault reduz grandemente as possibilidades de haver fugas de segredos acidentais. Em vez de armazenar a cadeia de conexão no código do aplicativo, você pode armazená-la com segurança no Cofre da Chave. Seus aplicativos podem acessar com segurança as informações de que precisam usando URIs. Esses URIs permitem que os aplicativos recuperem versões específicas de um segredo. Não há necessidade de escrever código personalizado para proteger qualquer informação secreta armazenada no Cofre de Chaves.
Encriptação de dados em trânsito
Se o armazenamento de dados na nuvem suportar HTTPS ou TLS, todas as transferências de dados entre os serviços de movimentação de dados no Data Factory e um armazenamento de dados na nuvem são feitas através do canal seguro HTTPS ou TLS.
Nota
Todas as conexões com o Banco de Dados SQL do Azure e o Azure Synapse Analytics exigem criptografia (SSL/TLS) enquanto os dados estão em trânsito de e para o banco de dados. Quando você estiver criando um pipeline usando JSON, adicione a propriedade encryption e defina-a como true na cadeia de conexão. Para o Armazenamento do Azure, você pode usar HTTPS na cadeia de conexão.
Nota
Para habilitar a criptografia em trânsito ao mover dados do Oracle, siga uma das opções abaixo:
- No servidor Oracle, vá para Oracle Advanced Security (OAS) e defina as configurações de criptografia, que suporta criptografia Triple-DES (3DES) e Advanced Encryption Standard (AES), consulte aqui para obter detalhes. O ADF negocia automaticamente o método de criptografia para usar aquele que você configura no OEA ao estabelecer conexão com o Oracle.
- No ADF, você pode adicionar EncryptionMethod=1 na cadeia de conexão (no Serviço Vinculado). Isso usará SSL/TLS como o método de criptografia. Para usar isso, você precisa desabilitar as configurações de criptografia não SSL no OAS no lado do servidor Oracle para evitar conflitos de criptografia.
Nota
A versão TLS usada é 1.2.
Encriptação de dados inativa
Alguns armazenamentos de dados suportam criptografia de dados em repouso. Recomendamos que você habilite o mecanismo de criptografia de dados para esses armazenamentos de dados.
Azure Synapse Analytics
A Criptografia de Dados Transparente (TDE) no Azure Synapse Analytics ajuda a proteger contra a ameaça de atividades maliciosas executando criptografia em tempo real e descriptografia de seus dados em repouso. Esse comportamento é transparente para o cliente. Para obter mais informações, consulte Proteger um banco de dados no Azure Synapse Analytics.
Base de Dados SQL do Azure
O Banco de Dados SQL do Azure também dá suporte à criptografia de dados transparente (TDE), que ajuda a proteger contra a ameaça de atividades maliciosas executando criptografia e descriptografia em tempo real dos dados, sem exigir alterações no aplicativo. Esse comportamento é transparente para o cliente. Para obter mais informações, consulte Criptografia de dados transparente para Banco de dados SQL e Data Warehouse.
Azure Data Lake Store
O Azure Data Lake Store também fornece criptografia para dados armazenados na conta. Quando ativado, o Repositório Data Lake criptografa automaticamente os dados antes de persistir e descriptografa antes da recuperação, tornando-os transparentes para o cliente que acessa os dados. Para obter mais informações, consulte Segurança no Azure Data Lake Store.
Armazenamento de Blob do Azure e armazenamento de Tabela do Azure
O armazenamento de Blob do Azure e o armazenamento de Tabela do Azure suportam a Criptografia do Serviço de Armazenamento (SSE), que criptografa automaticamente seus dados antes de persistir no armazenamento e descriptografa antes da recuperação. Para obter mais informações, veja Azure Storage Service Encryption for Data at Rest (Encriptação do Serviço de Armazenamento do Azure para Dados Inativos).
Amazon S3
O Amazon S3 oferece suporte à criptografia de dados em repouso tanto do cliente quanto do servidor. Para obter mais informações, consulte Protegendo dados usando criptografia.
Amazon Redshift
O Amazon Redshift oferece suporte à criptografia de cluster para dados em repouso. Para obter mais informações, consulte Criptografia de banco de dados do Amazon Redshift.
Salesforce
O Salesforce oferece suporte à criptografia da plataforma Shield, que permite a criptografia de todos os arquivos, anexos e campos personalizados. Para obter mais informações, consulte Noções básicas sobre o fluxo de autenticação OAuth do servidor Web.
Cenários híbridos
Os cenários híbridos exigem que o tempo de execução de integração auto-hospedado seja instalado em uma rede local, dentro de uma rede virtual (Azure) ou dentro de uma nuvem privada virtual (Amazon). O tempo de execução de integração auto-hospedado deve ser capaz de acessar os armazenamentos de dados locais. Para obter mais informações sobre o tempo de execução da integração auto-hospedada, consulte Como criar e configurar o tempo de execução da integração auto-hospedada.
O canal de comando permite a comunicação entre os serviços de movimentação de dados no Data Factory e o tempo de execução de integração auto-hospedado. A comunicação contém informações relacionadas com a atividade. O canal de dados é usado para transferir dados entre armazenamentos de dados locais e armazenamentos de dados em nuvem.
Credenciais de armazenamento de dados local
As credenciais podem ser armazenadas no data factory ou referenciadas pelo data factory durante o tempo de execução do Azure Key Vault. Se estiver armazenando credenciais no data factory, elas serão sempre armazenadas criptografadas no tempo de execução de integração auto-hospedado.
Armazene credenciais localmente. Se você usar diretamente o cmdlet Set-AzDataFactoryV2LinkedService com as cadeias de conexão e credenciais embutidas no JSON, o serviço vinculado será criptografado e armazenado no tempo de execução de integração auto-hospedado. Nesse caso, as credenciais fluem através do serviço de back-end do Azure, que é extremamente seguro, para a máquina de integração auto-hospedada, onde é finalmente criptografada e armazenada. O tempo de execução de integração auto-hospedado usa o DPAPI do Windows para criptografar os dados confidenciais e as informações de credenciais.
Armazene credenciais no Cofre da Chave do Azure. Você também pode armazenar a credencial do armazenamento de dados no Cofre de Chaves do Azure. O Data Factory recupera a credencial durante a execução de uma atividade. Para obter mais informações, veja Armazenar credenciais no Azure Key Vault.
Armazene credenciais localmente sem fluir as credenciais através do back-end do Azure para o tempo de execução de integração auto-hospedado. Se você quiser criptografar e armazenar credenciais localmente no tempo de execução de integração auto-hospedado sem precisar fluir as credenciais pelo back-end do data factory, siga as etapas em Criptografar credenciais para armazenamentos de dados locais no Azure Data Factory. Todos os conectores suportam esta opção. O tempo de execução de integração auto-hospedado usa o DPAPI do Windows para criptografar os dados confidenciais e as informações de credenciais.
Use o cmdlet New-AzDataFactoryV2LinkedServiceEncryptedCredential para criptografar credenciais de serviço vinculado e detalhes confidenciais no serviço vinculado. Em seguida, você pode usar o JSON retornado (com o elemento EncryptedCredential na cadeia de conexão) para criar um serviço vinculado usando o cmdlet Set-AzDataFactoryV2LinkedService .
Portas usadas ao criptografar o serviço vinculado no tempo de execução de integração auto-hospedado
Por padrão, quando o acesso remoto da intranet está habilitado, o PowerShell usa a porta 8060 na máquina com tempo de execução de integração auto-hospedado para comunicação segura. Se necessário, essa porta pode ser alterada a partir do Integration Runtime Configuration Manager na guia Configurações:
Encriptação em trânsito
Todas as transferências de dados são feitas através de HTTPS de canal seguro e TLS sobre TCP para evitar ataques man-in-the-middle durante a comunicação com os serviços do Azure.
Você também pode usar VPN IPsec ou Azure ExpressRoute para proteger ainda mais o canal de comunicação entre sua rede local e o Azure.
A Rede Virtual do Azure é uma representação lógica da sua rede na nuvem. Você pode conectar uma rede local à sua rede virtual configurando VPN IPsec (site a site) ou ExpressRoute (emparelhamento privado).
A tabela a seguir resume as recomendações de configuração do tempo de execução de integração de rede e auto-hospedado com base em diferentes combinações de locais de origem e destino para movimentação de dados híbridos.
| Origem | Destino | Configuração de rede | Configuração do runtime de integração |
|---|---|---|---|
| No local | Máquinas virtuais e serviços de nuvem implantados em redes virtuais | VPN IPsec (ponto a site ou site a site) | O tempo de execução de integração auto-hospedado deve ser instalado em uma máquina virtual do Azure na rede virtual. |
| No local | Máquinas virtuais e serviços de nuvem implantados em redes virtuais | ExpressRoute (emparelhamento privado) | O tempo de execução de integração auto-hospedado deve ser instalado em uma máquina virtual do Azure na rede virtual. |
| No local | Serviços baseados no Azure que têm um ponto de extremidade público | ExpressRoute (emparelhamento da Microsoft) | O tempo de execução de integração auto-hospedado pode ser instalado no local ou em uma máquina virtual do Azure. |
As imagens a seguir mostram o uso do tempo de execução de integração auto-hospedado para mover dados entre um banco de dados local e os serviços do Azure usando a Rota Expressa e a VPN IPsec (com a Rede Virtual do Azure):
ExpressRoute
IPsec VPN
Configurações de firewall e configuração de lista de permissões para endereços IP
Nota
Talvez seja necessário gerenciar portas ou configurar a lista de permissões para domínios no nível de firewall corporativo, conforme exigido pelas respetivas fontes de dados. Esta tabela usa apenas o Banco de Dados SQL do Azure, o Azure Synapse Analytics e o Azure Data Lake Store como exemplos.
Nota
Para obter detalhes sobre estratégias de acesso a dados por meio do Azure Data Factory, consulte este artigo.
Requisitos de firewall para rede no local/privada
Em uma empresa, um firewall corporativo é executado no roteador central da organização. O Firewall do Windows é executado como um daemon na máquina local na qual o tempo de execução de integração auto-hospedado está instalado.
A tabela a seguir fornece requisitos de porta de saída e domínio para firewalls corporativos:
| Nomes de domínio | Portas de saída | Description |
|---|---|---|
*.servicebus.windows.net |
443 | Exigido pelo tempo de execução de integração auto-hospedado para criação interativa. |
{datafactory}.{region}.datafactory.azure.netou *.frontend.clouddatahub.net |
443 | Exigido pelo tempo de execução de integração auto-hospedado para se conectar ao serviço Data Factory. Para o novo Data Factory criado, encontre o FQDN da sua chave Self-hosted Integration Runtime que está no formato {datafactory}. {região}.datafactory.azure.net. Para o Data factory antigo, se você não vir o FQDN em sua chave de integração auto-hospedada, use *.frontend.clouddatahub.net em vez disso. |
download.microsoft.com |
443 | Exigido pelo tempo de execução de integração auto-hospedado para baixar as atualizações. Se tiver desativado a atualização automática, pode ignorar a configuração deste domínio. |
*.core.windows.net |
443 | Usado pelo tempo de execução de integração auto-hospedado para se conectar à conta de armazenamento do Azure quando você usa o recurso de cópia em estágios. |
*.database.windows.net |
1433 | Necessário somente quando você copia de ou para o Banco de Dados SQL do Azure ou o Azure Synapse Analytics e opcional caso contrário. Use o recurso de cópia em estágios para copiar dados para o Banco de Dados SQL ou o Azure Synapse Analytics sem abrir a porta 1433. |
*.azuredatalakestore.netlogin.microsoftonline.com/<tenant>/oauth2/token |
443 | Necessário somente quando você copia de ou para o Repositório Azure Data Lake e opcional caso contrário. |
Nota
Talvez seja necessário gerenciar portas ou configurar a lista de permissões para domínios no nível de firewall corporativo, conforme exigido pelas respetivas fontes de dados. Esta tabela usa apenas o Banco de Dados SQL do Azure, o Azure Synapse Analytics e o Azure Data Lake Store como exemplos.
A tabela a seguir fornece os requisitos de porta de entrada para o Firewall do Windows:
| Portas de entrada | Description |
|---|---|
| 8060 (TCP) | Exigido pelo cmdlet de criptografia do PowerShell, conforme descrito em Criptografar credenciais para armazenamentos de dados locais no Azure Data Factory, e pelo aplicativo gerenciador de credenciais para definir com segurança credenciais para armazenamentos de dados locais no tempo de execução de integração auto-hospedado. |
Configurações de IP e configuração de lista de permissões em armazenamentos de dados
Alguns armazenamentos de dados na nuvem também exigem que você permita que o endereço IP da máquina acesse a loja. Verifique se o endereço IP da máquina de tempo de execução de integração auto-hospedada é permitido ou configurado no firewall adequadamente.
Os armazenamentos de dados na nuvem a seguir exigem que você permita o endereço IP da máquina de tempo de execução de integração auto-hospedada. Alguns desses armazenamentos de dados, por padrão, podem não exigir lista de permissões.
- Base de Dados SQL do Azure
- Azure Synapse Analytics
- Azure Data Lake Store
- BD do Cosmos para o Azure
- Amazon Redshift
Perguntas mais frequentes
O tempo de execução de integração auto-hospedado pode ser compartilhado entre diferentes fábricas de dados?
Sim. Mais detalhes aqui.
Quais são os requisitos de porta para que o tempo de execução de integração auto-hospedado funcione?
O tempo de execução de integração auto-hospedado faz conexões baseadas em HTTP para acessar a Internet. As portas de saída 443 devem ser abertas para que o tempo de execução de integração auto-hospedado faça essa conexão. Abra a porta de entrada 8060 somente no nível da máquina (não no nível do firewall corporativo) para o aplicativo gerenciador de credenciais. Se o Banco de Dados SQL do Azure ou o Azure Synapse Analytics for usado como a origem ou o destino, você também precisará abrir a porta 1433. Para obter mais informações, consulte a seção Configurações de firewall e configuração de lista de permissões para endereços IP.
Conteúdos relacionados
Para obter informações sobre o desempenho da Atividade de Cópia do Azure Data Factory, consulte Guia de ajuste e desempenho da Atividade de Cópia.