Melhores práticas de segurança para Delta Sharing

 

O data lakehouse nos permitiu consolidar nossas arquiteturas de gerenciamento de dados, eliminando silos e aproveitando uma plataforma comum para todos os casos de uso. A unificação de data warehousing e casos de uso de IA em uma única plataforma é um grande passo à frente para as organizações, mas depois de dar esse passo, a próxima pergunta a ser considerada é "como compartilhamos esses dados de forma simples e segura, independentemente do cliente, ferramenta ou plataforma que o destinatário esteja usando para acessá-los?" Felizmente, o lakehouse também tem uma resposta para essa pergunta: compartilhamento de dados com Delta Sharing.

Delta Sharing

Delta Sharing é o primeiro protocolo aberto do mundo para compartilhar dados de forma segura interna e externamente entre organizações em tempo real, independentemente da plataforma em que os dados residem. É um componente chave da abertura da arquitetura lakehouse e um facilitador chave para organizar nossas equipes de dados e padrões de acesso de maneiras que não eram possíveis antes, como o data mesh.

Seguro por Design

É importante notar que o Delta Sharing foi construído do zero com a segurança em mente, permitindo que você aproveite os seguintes recursos prontos para uso, quer você use a versão open source ou seu equivalente gerenciado:

• Criptografia TLS de ponta a ponta, do cliente ao servidor e à conta de armazenamento
• Credenciais de curta duração, como URLs pré-assinadas, são usadas para acessar os dados
• Gerencie, rastreie e audite facilmente o acesso aos seus conjuntos de dados compartilhados via Unity Catalog

As melhores práticas que compartilharemos como parte deste blog são adicionais, permitindo que os clientes alinhem os controles de segurança apropriados ao seu perfil de risco e à sensibilidade de seus dados.

Melhores Práticas de Segurança

Nossas recomendações de melhores práticas para usar o Delta Sharing para compartilhar dados sensíveis são as seguintes:

1. Avalie a versão open source versus a versão gerenciada com base em seus requisitos
2. Defina o tempo de vida apropriado do token do destinatário para cada metastore
3. Estabeleça um processo para rotação de credenciais
4. Considere o nível certo de granularidade para Shares, Destinatários e Partições
5. Configure Listas de Acesso por IP
6. Configure o registro de auditoria do Databricks
7. Configure restrições de rede na(s) Conta(s) de Armazenamento
8. Configure o registro na(s) Conta(s) de Armazenamento

1. Avalie a versão open source versus a versão gerenciada com base em seus requisitos

Como estabelecemos acima, o Delta Sharing foi construído do zero com a segurança em primeiro lugar. No entanto, existem vantagens em usar a versão gerenciada:

• O Delta Sharing no Databricks é fornecido pelo Unity Catalog, que permite fornecer acesso granular a quaisquer conjuntos de dados entre diferentes conjuntos de usuários centralmente a partir de um único local. Com a versão open source, você precisaria separar conjuntos de dados que têm vários direitos de acesso entre vários servidores de compartilhamento, e você também precisaria impor restrições de acesso nesses servidores e nas contas de armazenamento subjacentes. Para facilitar a implantação, uma imagem docker é fornecida com a versão open source, mas é importante notar que a escalabilidade das implantações em grandes empresas representará uma sobrecarga não trivial para as equipes responsáveis por gerenciá-las.
• Assim como o restante da Plataforma Lakehouse do Databricks, o Unity Catalog é fornecido como um serviço gerenciado. Você não precisa se preocupar com coisas como disponibilidade, tempo de atividade e manutenção do serviço, porque nós nos preocupamos com isso para você.
• O Unity Catalog permite configurar recursos abrangentes de auditoria prontos para uso.
• Os proprietários de dados poderão gerenciar compartilhamentos usando sintaxe SQL. Além disso, APIs REST estão disponíveis para gerenciar compartilhamentos. O uso da sintaxe SQL familiar simplifica a forma como compartilhamos dados, reduzindo o fardo administrativo.
• Usando a versão open source, você é responsável pela configuração, infraestrutura e gerenciamento do compartilhamento de dados, mas com a versão gerenciada toda essa funcionalidade está disponível prontamente.

Por essas razões, recomendamos avaliar ambas as versões e tomar uma decisão com base em seus requisitos. Se a facilidade de configuração e uso, governança e auditoria prontas para uso, e gerenciamento de serviço terceirizado são importantes para você, a versão gerenciada provavelmente será a escolha certa.

2. Defina o tempo de vida apropriado do token do destinatário para cada metastore

Quando você habilita o Delta Sharing, você configura o tempo de vida do token para as credenciais do destinatário. Se você definir o tempo de vida do token como 0, os tokens do destinatário nunca expirarão.

Definir o tempo de vida apropriado do token é de importância crítica do ponto de vista regulatório, de conformidade e de reputação. Ter um token que nunca expira é um risco enorme; portanto, é recomendado usar tokens de curta duração como melhor prática. É muito mais fácil conceder um novo token a um destinatário cujo token expirou do que investigar o uso de um token cujo tempo de vida foi definido incorretamente.

Consulte a documentação (AWS, Azure) para configurar tokens para expirar após o número apropriado de segundos, minutos, horas ou dias.

3. Estabeleça um processo para rotação de credenciais

Existem várias razões pelas quais você pode querer rotacionar credenciais, desde a expiração de um token existente, preocupações de que uma credencial possa ter sido comprometida, ou mesmo porque você modificou o tempo de vida do token e deseja emitir novas credenciais que respeitem esse tempo de expiração.

Para garantir que tais solicitações sejam atendidas de forma previsível e oportuna, é importante estabelecer um processo, preferencialmente com um SLA estabelecido. Isso pode ser bem integrado ao seu processo de gerenciamento de serviços de TI, com a ação apropriada concluída pelo proprietário de dados designado, administrador de dados ou DBA para esse metastore.

Consulte a documentação (AWS, Azure) para saber como rotacionar credenciais. Em particular:

• Se você precisar rotacionar uma credencial imediatamente, defina --existing-token-expire-in-seconds como 0, e o token existente expirará imediatamente.
• O Databricks recomenda as seguintes ações quando há preocupações de que as credenciais possam ter sido comprometidas:
  1. Revogue o acesso do destinatário ao compartilhamento.
  2. Rotacione o destinatário e defina --existing-token-expire-in-seconds como 0 para que o token existente expire imediatamente.
  3. Compartilhe o novo link de ativação com o destinatário pretendido por um canal seguro.
  4. Após o acesso ao URL de ativação, conceda novamente ao destinatário o acesso ao compartilhamento.

4. Considere o nível certo de granularidade para Compartilhamentos, Destinatários e Partições

Na versão gerenciada, cada compartilhamento pode conter uma ou mais tabelas e pode ser associado a um ou mais destinatários, usando controles granulares para gerenciar quem ou como os múltiplos conjuntos de dados são acessados. Isso nos permite fornecer acesso granular a múltiplos conjuntos de dados de uma forma que seria muito mais difícil de alcançar usando apenas o código aberto. E podemos ir um passo além, adicionando apenas parte de uma tabela para compartilhar, fornecendo uma especificação de partição (veja a documentação sobre AWS, Azure).

Vale a pena aproveitar esses recursos implementando seus compartilhamentos e destinatários para seguir o princípio do menor privilégio, de modo que, se as credenciais de um destinatário forem comprometidas, elas estarão associadas ao menor número de conjuntos de dados ou ao menor subconjunto dos dados possível.

5. Configure Listas de Acesso por IP

Por padrão, tudo o que é necessário para acessar seus compartilhamentos é um Arquivo de Credenciais de Compartilhamento Delta válido, portanto, é fundamental minimizar a possibilidade de as credenciais serem comprometidas implementando limites no nível da rede de onde elas podem ser usadas.

Configure listas de acesso de Compartilhamento Delta (veja os docs para AWS, Azure) para restringir o acesso do destinatário a endereços IP confiáveis, por exemplo, o IP público da sua VPN corporativa.

Combinar as listas de acesso por IP com o token de acesso reduz consideravelmente os riscos de acesso não autorizado. Para que alguém acesse os dados de forma não autorizada, é necessário que essa pessoa tenha adquirido uma cópia do seu token e esteja na mesma rede autorizada, o que é muito mais difícil do que apenas adquirir o token em si.

6. Configure o Registro de Auditoria do Databricks

Os logs de auditoria são seu registro oficial do que está acontecendo na sua Databricks Lakehouse Platform, incluindo todas as atividades relacionadas ao Delta Sharing. Como tal, recomendamos altamente que você configure os logs de auditoria do Databricks para cada nuvem (veja os docs para AWS, Azure) e configure pipelines automatizados para processar esses logs e monitorar/alertar sobre eventos importantes.

Confira nosso blog complementar, Monitorando sua Databricks Lakehouse Platform com Logs de Auditoria para um mergulho mais profundo neste assunto, incluindo todo o código que você precisa para configurar pipelines do Delta Live Tables, configurar alertas do Databricks SQL e executar consultas SQL para responder a perguntas importantes como:

• Quais dos meus Compartilhamentos Delta são os mais populares?
• De quais países meus Compartilhamentos Delta estão sendo acessados?
• Destinatários do Compartilhamento Delta estão sendo criados sem a aplicação de restrições de lista de acesso por IP?
• Destinatários do Compartilhamento Delta estão sendo criados com restrições de lista de acesso por IP que estão fora do meu intervalo de IP confiável?
• Tentativas de acessar meus Compartilhamentos Delta estão falhando nas restrições de lista de acesso por IP?
• Tentativas de acessar meus Compartilhamentos Delta estão falhando repetidamente na autenticação?

7. Configure restrições de rede na(s) conta(s) de armazenamento

Uma vez que uma solicitação de compartilhamento delta é autenticada com sucesso pelo servidor de compartilhamento, uma matriz de credenciais de curta duração é gerada e retornada ao cliente. O cliente então usa esses URLs para solicitar os arquivos relevantes diretamente do provedor de nuvem. Esse design significa que a transferência pode ocorrer em paralelo com largura de banda massiva, sem transmitir os resultados pelo servidor. Também significa que, do ponto de vista de segurança, você provavelmente desejará implementar restrições de rede semelhantes na conta de armazenamento às do próprio destinatário do compartilhamento delta - não adianta proteger o compartilhamento no nível do destinatário, se os próprios dados estiverem hospedados em uma conta de armazenamento que pode ser acessada por qualquer pessoa e de qualquer lugar.

Azure

No Azure, a Databricks recomenda o uso de Identidades Gerenciadas (atualmente em Visualização Pública) para acessar a Conta de Armazenamento subjacente em nome do Unity Catalog. Os clientes podem então configurar firewalls de armazenamento para restringir todo o outro acesso aos endpoints privados confiáveis, redes virtuais ou intervalos de IP públicos que os clientes de compartilhamento delta podem usar para acessar os dados. Entre em contato com seu representante Databricks para mais informações.

Nota Importante: Novamente, é importante considerar todos os casos de uso potenciais ao determinar quais restrições de nível de rede aplicar. Por exemplo, além de acessar dados via compartilhamento delta, é provável que um ou mais workspaces Databricks também precisem de acesso aos dados e, portanto, você deve permitir o acesso dos endpoints privados confiáveis, redes virtuais ou intervalos de IP públicos relevantes usados por esses workspaces.

AWS

Na AWS, a Databricks recomenda o uso de políticas de bucket S3 para restringir o acesso aos seus buckets S3. Por exemplo, a seguinte instrução Deny pode ser usada para restringir o acesso a endereços IP e VPCs confiáveis.

Nota Importante: É importante considerar todos os casos de uso potenciais ao determinar quais restrições de nível de rede aplicar. Por exemplo:

• Ao usar a versão gerenciada, os URLs pré-assinados são gerados pelo Unity Catalog e, portanto, você precisará permitir o acesso do IP NAT do Plano de Controle Databricks para sua região.
• É provável que um ou mais workspaces Databricks também precisem de acesso aos dados e, portanto, você deve permitir o acesso dos IDs de VPC relevantes se o bucket S3 subjacente estiver na mesma região e você estiver usando Endpoints de VPC para se conectar ao S3 ou ao endereço IP público para o qual o tráfego do plano de dados é resolvido (por exemplo, via NAT Gateway).
• Para evitar a perda de conectividade de dentro da sua rede corporativa, a Databricks recomenda sempre permitir o acesso de pelo menos um endereço IP conhecido e confiável, como o IP público da sua VPN corporativa. Isso ocorre porque as condições Deny se aplicam mesmo dentro do console da AWS.

Além das restrições em nível de rede, também é recomendado restringir o acesso aos buckets S3 subjacentes à função IAM usada pelo Unity Catalog. O motivo é que, como vimos, o Unity Catalog fornece acesso granular aos seus dados de uma forma que não é possível com as permissões de granularidade grosseira fornecidas pelo AWS IAM/S3. Portanto, se alguém conseguisse acessar o bucket S3 diretamente, poderia contornar essas permissões granulares e acessar mais dados do que o pretendido.

Observação Importante: Assim como acima, as condições de negação se aplicam mesmo dentro do console da AWS, portanto, é recomendado permitir também o acesso a uma função de administrador que um pequeno número de usuários privilegiados possa usar para acessar a interface/APIs da AWS.

8. Configurar o registro em log nas contas de armazenamento

Além de impor restrições em nível de rede nas contas de armazenamento subjacentes, você provavelmente desejará monitorar se alguém está tentando contorná-las. Como tal, a Databricks recomenda:

• Configurar o registro de acesso do servidor S3 na AWS, bem como o monitoramento e alertas apropriados em torno dele
• Configurar o registro de diagnóstico no Azure, bem como o monitoramento e alertas apropriados em torno dele

Conclusão

O lakehouse resolveu a maioria dos problemas de gerenciamento de dados que levaram a arquiteturas de dados e padrões de acesso fragmentados, e limitou severamente o tempo de valor que uma organização poderia esperar de seus dados. Agora que as equipes de dados foram liberadas desses problemas, o compartilhamento de dados aberto, mas seguro se tornou a próxima fronteira.

Delta Sharing é o primeiro protocolo aberto do mundo para compartilhar dados de forma segura interna e externamente em tempo real, independentemente da plataforma em que os dados residem. E ao usar o Delta Sharing em combinação com as melhores práticas descritas acima, as organizações podem trocar dados de forma fácil, mas segura, com seus usuários, parceiros e clientes em escala empresarial.

Os marketplaces de dados existentes falharam em maximizar o valor de negócios para provedores e consumidores de dados, mas com o Databricks Marketplace você pode alavancar a Databricks Lakehouse Platform para alcançar mais clientes, reduzir custos e entregar mais valor em todos os seus produtos de dados.

Se você estiver interessado em se tornar um Parceiro Provedor de Dados, adoraríamos ouvir você!

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original