Conceitos de segurança do Clusters de Big Data do SQL Server
Aplica-se a:
SQL Server 2019 (15.x)
Importante
O complemento Clusters de Big Data do Microsoft SQL Server 2019 será desativado. O suporte para Clusters de Big Data do SQL Server 2019 será encerrado em 28 de fevereiro de 2025. Todos os usuários existentes do SQL Server 2019 com Software Assurance terão suporte total na plataforma e o software continuará a ser mantido por meio de atualizações cumulativas do SQL Server até esse momento. Para obter mais informações, confira a postagem no blog de anúncio e as opções de Big Data na plataforma do Microsoft SQL Server.
Este artigo abordará os principais conceitos relacionados à segurança.
Os Clusters de Big Data do SQL Server fornecem autenticação e autorização coerentes e consistentes. Um cluster de Big Data pode ser integrado ao AD (Active Directory) por meio de uma implantação totalmente automatizada que configura a integração do AD em um domínio existente. Depois que um cluster de Big Data for configurado com a integração do AD, aproveite as identidades e os grupos de usuários existentes para acesso unificado em todos os pontos de extremidade. Além disso, depois de criar tabelas externas no SQL Server, você pode controlar o acesso às fontes de dados permitindo acesso a tabelas externas aos usuários e grupos do AD, centralizando as políticas de acesso a dados em uma só localização.
Neste vídeo de 14 minutos, você obterá uma visão geral da segurança do cluster de Big Data:
Autenticação
Os pontos de extremidade do cluster externo dão suporte à autenticação do AD. Use sua identidade do AD para autenticação no cluster de Big Data.
Pontos de extremidade do cluster
Há cinco pontos de entrada para o cluster de Big Data
Instância mestra – Ponto de extremidade TDS para acessar a instância mestra do SQL Server no cluster, usando ferramentas de banco de dados e aplicativos como o SSMS ou o Azure Data Studio. Ao usar comandos do HDFS ou do SQL Server na CLI de Dados do Azure (
azdata), a ferramenta se conectará aos outros pontos de extremidade, dependendo da operação.Gateway para acessar arquivos HDFS, Spark (Knox) – ponto de extremidade HTTPS para acessar serviços como o webHDFS e o Spark.
Ponto de extremidade do Serviço de Gerenciamento do Cluster (Controlador) – serviço de gerenciamento de cluster de Big Data que expõe APIs REST para gerenciar o cluster. A ferramenta azdata exige conexão com esse ponto de extremidade.
Proxy de Gerenciamento – para acessar o painel Pesquisa de logs e o painel Métricas.
Proxy de aplicativo – ponto de extremidade para gerenciar aplicativos implantados dentro do cluster de Big Data.
Atualmente, não há nenhuma opção de abrir portas adicionais para acessar o cluster de fora.
Autorização
Em todo o cluster, a segurança integrada entre diferentes componentes permite que a identidade do usuário original seja passada, durante a emissão de consultas do Spark e do SQL Server, até o HDFS. Conforme mencionado acima, os vários pontos de extremidade de cluster externo dão suporte à autenticação do AD.
Há dois níveis de verificações de autorização no cluster para gerenciar o acesso a dados. A autorização no contexto de Big Data é feita no SQL Server, usando as permissões tradicionais do SQL Server em objetos e no HDFS com ACLs (listas de controle), que associam as identidades de usuário a permissões específicas.
Um cluster de Big Data seguro implica no suporte uniforme e coerente a cenários de autenticação e autorização, tanto no SQL Server quanto no HDFS/Spark. Autenticação é o processo de verificar a identidade de um usuário ou serviço e de garantir que eles sejam quem alegam ser. Autorização refere-se à concessão ou negação de acesso a recursos específicos com base na identidade do usuário solicitante. Esta etapa é executada após um usuário ser identificado por meio da autenticação.
A autorização no contexto de Big Data é executada por meio de ACLs (listas de controle de acesso), que associam identidades de usuário a permissões específicas. O HDFS dá suporte à autorização limitando o acesso a APIs de serviço, arquivos HDFS e execução de trabalhos.
Criptografia em trânsito e outros mecanismos de segurança
A criptografia da comunicação entre clientes com os pontos de extremidade externos, bem como entre componentes dentro do cluster, é protegida com o TLS/SSL, usando certificados.
Toda a comunicação do SQL Server com o SQL Server, como a instância mestra do SQL que se comunica com um pool de dados, é protegida usando logons do SQL.
Importante
Os Clusters de Big Data usam etcd para armazenar as credenciais. Como prática recomendada, é necessário garantir que o cluster do Kubernetes esteja configurado para usar a criptografia etcd em repouso. Por padrão, os segredos armazenados em etcd serão descriptografados. A documentação do Kubernetes fornece detalhes sobre esta tarefa administrativa: https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/ e https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/.
Criptografia de dados em repouso
A capacidade de criptografia em repouso de Clusters de Big Data do SQL Server dá suporte ao cenário principal de criptografia de nível de aplicativo para os componentes do SQL Server e do HDFS. Siga o artigo Guia de configuração e conceitos de criptografia em repouso para obter um guia abrangente de uso dos recursos.
Importante
A criptografia de volume é recomendada para todas as implantações de Cluster de Big Data do SQL Server. Os volumes de armazenamento fornecidos pelo cliente configurados em clusters do Kubernetes também devem ser criptografados, como uma abordagem abrangente da criptografia de dados em repouso. A capacidade de criptografia em repouso do Cluster de Big Data do SQL Server é uma camada de segurança adicional, fornecendo criptografia em nível de aplicativo aos arquivos de log e dados do SQL Server e suporte à zona de criptografia do HDFS.
Logon de administrador básico
Você pode optar por implantar o cluster no modo do AD ou usando somente o logon de administrador básico. Somente usar o logon de administrador básico não é um modo de segurança com suporte em produção e destina-se à avaliação do produto.
Mesmo que você escolha o modo do Active Directory, os logons básicos serão criados para o administrador do cluster. Esse recurso fornece acesso alternativo, caso a conectividade do AD esteja inoperante.
Após a implantação, esse logon básico receberá permissões de administrador no cluster. O usuário do logon será o administrador do sistema na instância mestra do SQL Server e um administrador no controlador de cluster. Os componentes do Hadoop não dão suporte à autenticação de modo misto, o que significa que um logon de administrador básico não pode ser usado para autenticação no gateway (Knox).
As credenciais de logon que você precisa definir na implantação incluem:
Nome de usuário administrador do cluster:
AZDATA_USERNAME=<username>
Senha de administrador do cluster:
AZDATA_PASSWORD=<password>
Observação
Observe que, no modo não AD, o nome de usuário deve ser usado em combinação com a senha acima, para autenticação no gateway (KNOX) para acesso ao HDFS/Spark. Antes do SQL Server 2019 CU5, o nome de usuário era root.
A partir do SQL Server 2019 (15.x) CU 5, quando você implanta um novo cluster com a autenticação básica, todos os pontos de extremidade, incluindo o gateway, usam AZDATA_USERNAME e AZDATA_PASSWORD. Os pontos de extremidade em clusters que são atualizados para CU 5 continuam usando root como o nome de usuário para se conectar ao ponto de extremidade do gateway. Essa alteração não se aplica às implantações que usam a autenticação do Active Directory. Confira Credenciais para acessar serviços por meio do ponto de extremidade do gateway nas notas sobre a versão.
Gerenciar versões de chave
Clusters de Big Data do SQL Server 2019 permite o gerenciamento de versão de chave para SQL Server e HDFS usando zonas de criptografia. Para obter mais informações, confira Versões de chave no cluster de Big Data.
Próximas etapas
O que são Clusters de Big Data do SQL Server 2019
Workshop: Arquitetura dos Clusters de Big Data do SQL Server da Microsoft
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de