White paper de segurança do Azure Synapse Analytics: Proteção de dados

Nota

Este artigo faz parte da série de artigos do white paper de segurança do Azure Synapse Analytics. Para obter uma visão geral da série, consulte o white paper de segurança do Azure Synapse Analytics.

Deteção e classificação de dados

As organizações precisam proteger seus dados para cumprir as diretrizes federais, locais e da empresa para mitigar os riscos de violação de dados. Um desafio que as organizações enfrentam é: como proteger os dados se você não sabe onde eles estão? Outra é: que nível de proteção é necessário?—porque alguns conjuntos de dados exigem mais proteção do que outros.

Imagine uma organização com centenas ou milhares de arquivos armazenados em seu data lake e centenas ou milhares de tabelas em seus bancos de dados. Ele se beneficiaria de um processo que verifica automaticamente todas as linhas e colunas do sistema de arquivos ou tabela e classifica as colunas como dados potencialmente confidenciais. Esse processo é conhecido como descoberta de dados.

Quando o processo de descoberta de dados estiver concluído, ele fornecerá recomendações de classificação com base em um conjunto predefinido de padrões, palavras-chave e regras. Alguém pode então rever as recomendações e aplicar rótulos de classificação de sensibilidade às colunas apropriadas. Este processo é conhecido como classificação.

O Azure Synapse fornece duas opções para descoberta e classificação de dados:

• Descoberta de Dados & Classificação, que é incorporada ao Azure Synapse e ao pool SQL dedicado (anteriormente SQL DW).
• Microsoft Purview, que é uma solução unificada de governança de dados que ajuda a gerenciar e controlar dados locais, multicloud e de software como serviço (SaaS). Ele pode automatizar a descoberta de dados, a identificação de linhagens e a classificação de dados. Ao produzir um mapa unificado de ativos de dados e suas relações, ele torna os dados facilmente detetáveis.

Nota

A descoberta e a classificação de dados do Microsoft Purview estão em visualização pública para o Azure Synapse, pool SQL dedicado (anteriormente SQL DW) e pool SQL sem servidor. No entanto, atualmente não há suporte para linhagem de dados para o Azure Synapse, pool SQL dedicado (anteriormente SQL DW) e pool SQL sem servidor. O pool do Apache Spark suporta apenas o rastreamento de linhagem.

Encriptação de dados

Os dados são encriptados em repouso e em trânsito.

Dados inativos

Por padrão, o Armazenamento do Azure criptografa automaticamente todos os dados usando a criptografia AES 256 (AES 256) de 256 bits. É uma das cifras de bloco mais fortes disponíveis e é compatível com FIPS 140-2. A plataforma gerencia a chave de criptografia e forma a primeira camada de criptografia de dados. Essa criptografia se aplica aos bancos de dados do usuário e do sistema, incluindo o banco de dados mestre .

Habilitar a Criptografia de Dados Transparente (TDE) pode adicionar uma segunda camada de criptografia de dados para pools SQL dedicados. Ele executa criptografia de E/S em tempo real e descriptografia de arquivos de banco de dados, arquivos de logs de transações e backups em repouso sem exigir alterações no aplicativo. Por padrão, ele usa AES 256.

Por padrão, a TDE protege a chave de criptografia do banco de dados (DEK) com um certificado de servidor interno (gerenciado pelo serviço). Há uma opção para trazer sua própria chave (BYOK) que pode ser armazenada com segurança no Cofre de Chaves do Azure.

O pool sem servidor SQL do Azure Synapse e o pool do Apache Spark são mecanismos analíticos que funcionam diretamente no Azure Data Lake Gen2 (ALDS Gen2) ou no Armazenamento de Blobs do Azure. Esses tempos de execução analíticos não têm armazenamento permanente e dependem das tecnologias de criptografia do Armazenamento do Azure para proteção de dados. Por padrão, o Armazenamento do Azure criptografa todos os dados usando a criptografia do lado do servidor (SSE). Ele está habilitado para todos os tipos de armazenamento (incluindo ADLS Gen2) e não pode ser desativado. O SSE criptografa e descriptografa dados de forma transparente usando AES 256.

Há duas opções de criptografia SSE:

• Chaves gerenciadas pela Microsoft: a Microsoft gerencia todos os aspetos da chave de criptografia, incluindo armazenamento, propriedade e rotações de chaves. É totalmente transparente para os clientes.
• Chaves gerenciadas pelo cliente: nesse caso, a chave simétrica usada para criptografar dados no Armazenamento do Azure é criptografada usando uma chave fornecida pelo cliente. Suporta chaves RSA e RSA-HSM (Hardware Security Modules) dos tamanhos 2048, 3072 e 4096. As chaves podem ser armazenadas com segurança no Azure Key Vault ou no Azure Key Vault Managed HSM. Ele fornece controle de acesso refinado da chave e seu gerenciamento, incluindo armazenamento, backup e rotações. Para obter mais informações, consulte Chaves gerenciadas pelo cliente para criptografia de Armazenamento do Azure.

Embora o SSE forme a primeira camada de criptografia, os clientes cautelosos podem dobrar a criptografia habilitando uma segunda camada de criptografia AES de 256 bits na camada de infraestrutura de Armazenamento do Azure. Conhecida como criptografia de infraestrutura, ela usa uma chave gerenciada pela plataforma juntamente com uma chave separada da SSE. Assim, os dados na conta de armazenamento são criptografados duas vezes; uma vez no nível de serviço e uma vez no nível de infraestrutura com dois algoritmos de criptografia diferentes e chaves diferentes.

Dados em trânsito

O Azure Synapse, o pool SQL dedicado (anteriormente SQL DW) e o pool SQL sem servidor usam o protocolo TDS (Tabular Data Stream) para se comunicar entre o ponto de extremidade do pool SQL e uma máquina cliente. O TDS depende do Transport Layer Security (TLS) para criptografia de canal, garantindo que todos os pacotes de dados estejam protegidos e criptografados entre o ponto de extremidade e a máquina cliente. Ele usa um certificado de servidor assinado da Autoridade de Certificação (CA) usado para criptografia TLS, gerenciado pela Microsoft. O Azure Synapse dá suporte à criptografia de dados em trânsito com TLS v1.2, usando criptografia AES 256.

O Azure Synapse aproveita o TLS para garantir que os dados sejam criptografados em movimento. Pools SQL dedicados suportam versões TLS 1.0, TLS 1.1 e TLS 1.2 para criptografia, em que os drivers fornecidos pela Microsoft usam TLS 1.2 por padrão. O pool SQL sem servidor e o pool Apache Spark usam TLS 1.2 para todas as conexões de saída.

Importante

O Azure começará a desativar as versões mais antigas do TLS (TLS 1.0 e 1.1) a partir de novembro de 2024. Use TLS 1.2 ou superior. Após 31 de março de 2025, você não poderá mais definir a versão mínima do TLS para conexões de cliente do Azure Synapse Analytics abaixo do TLS 1.2. Após essa data, as tentativas de entrada de conexões usando uma versão TLS inferior a 1.2 falharão. Para obter mais informações, consulte Anúncio: O suporte do Azure para TLS 1.0 e TLS 1.1 será encerrado.

Próximos passos

No próximo artigo desta série de white papers, saiba mais sobre o controle de acesso.