Ir para o conteúdo principal
Produto

Assuma o Controle: Chaves Gerenciadas pelo Cliente para Lakebase Postgres

Criptografia em armazenamento e computação com controle de revogação

por Ben Hagan

  • O CMK do Lakebase permite o controle do cliente sobre as chaves de criptografia, permitindo que você gerencie chaves em seu próprio KMS na nuvem em vez de depender dos padrões gerenciados pelo Databricks.
  • Proteja todo o ciclo de vida dos dados criptografando tanto o armazenamento de longo prazo quanto os caches de computação efêmeros.
  • Use seu KMS como um "interruptor de segurança" técnico para tornar os dados criptograficamente inacessíveis e encerrar instâncias de computação ativas, fornecendo uma proteção para cargas de trabalho Postgres de alta conformidade.

A criptografia em repouso é um padrão de nuvem, mas para empresas que operam em ambientes altamente regulamentados, as organizações devem controlar a raiz de confiança. As Chaves Gerenciadas pelo Cliente (CMK) do Lakebase oferecem esse controle, permitindo que você use suas próprias chaves de criptografia do seu Serviço de Gerenciamento de Chaves (KMS) - como AWS KMS, Azure Key Vault ou Google Cloud KMS - para proteger e gerenciar dados em todo o ciclo de vida do Lakebase.

As Chaves Gerenciadas pelo Cliente (CMK) do Lakebase oferecem gerenciamento e controle abrangentes em toda a arquitetura, ao contrário dos bancos de dados gerenciados convencionais. Enquanto os bancos de dados tradicionais geralmente criptografam apenas o armazenamento, o CMK do Lakebase gerencia tanto o armazenamento persistente quanto a computação efêmera.

A Arquitetura de Criptografia do Lakebase

A arquitetura do Lakebase separa o armazenamento e a computação em camadas independentes - um design que permite escalabilidade elástica e operações sem servidor. A camada de armazenamento (Pageserver e Safekeeper) mantém dados persistentes de longa duração em armazenamento de objetos e caches locais, enquanto a camada de computação executa instâncias Postgres independentes que escalam para cima, para baixo ou para zero com base na demanda.

diagrama de arquitetura descreve o mecanismo de criptografia entre serviços de chave gerenciados pela nuvem, Databricks e aplicação de chaves pelo Lakebase

Essa separação cria um desafio único para a criptografia: ambas as camadas (bem como todos os seus caches em toda a arquitetura) devem ser criptografadas e permanecer sob controle do cliente. O CMK do Lakebase aborda isso por meio de um modelo hierárquico de Criptografia de Envelope.

A Hierarquia de Chaves

A Criptografia de Envelope é um modelo de segurança onde os dados são criptografados com chaves de dados exclusivas (DEKs), e essas chaves são elas mesmas criptografadas por chaves de nível superior. Essa hierarquia garante que seu CMK nunca saia do seu KMS na nuvem - o Databricks recebe apenas versões encapsuladas (criptografadas) das chaves necessárias para descriptografar os dados. O modelo também permite criptografia de alto desempenho em escala, já que o KMS é contatado apenas para desencapsular chaves, não para criptografar cada bloco de dados. Essa arquitetura é o que permite a rotação contínua de chaves e a revogação oportuna, se necessário.

A hierarquia consiste em três níveis:

  1. Chave Gerenciada pelo Cliente (CMK): A Raiz de Confiança residente no seu KMS na nuvem (AWS KMS, Azure Key Vault ou Google Cloud KMS). O Databricks nunca vê o texto simples desta chave.
  2. Chave de Criptografia de Chaves (KEK): Uma chave transitória usada pelo Serviço de Gerenciamento de Chaves do Databricks para encapsular chaves de dados.
  3. Chaves de Criptografia de Dados (DEKs): Chaves exclusivas geradas para cada segmento de dados. Estas são armazenadas junto com os dados em um estado criptografado (encapsulado).
hierarquia de criptografia de envelope

Quando os dados precisam ser acessados, os componentes do Lakebase desencapsulam a DEK necessária usando chaves obtidas do seu KMS. Em caso de revogação, o desencapsulamento falhará, tornando os dados criptograficamente inacessíveis. Como parte desse processo, todas as instâncias de computação efêmeras são terminadas para remover o acesso aos dados em cache.

CMK na Prática: Armazenamento e Computação

A implementação prática difere entre armazenamento e computação:

1. Camada de Persistência (Armazenamento)

Todos os segmentos de dados gerenciados pelo Lakebase, incluindo segmentos WAL (logs de transação armazenados pelo Safekeeper) e arquivos de dados, são criptografados com chaves protegidas pelo seu CMK. Isso fornece defesa em profundidade: os dados em repouso são protegidos por chaves de criptografia sob seu controle, não do Databricks.

2. Camada Efêmera (Computação)

A VM de computação Postgres armazena dados efêmeros usados pelo sistema operacional e pelo PostgresSQL - por exemplo, caches de desempenho, artefatos WAL, arquivos temporários etc. Portanto, é crucial que todos esses dados também sejam gerenciados sob um CMK. O CMK protege esses dados de computação efêmeros com:

  • Chaves por Inicialização: Toda vez que uma instância de computação do Lakebase é iniciada, ela gera uma chave efêmera exclusiva.
  • Destruição Automática: Na revogação do CMK, o Gerenciador do Lakebase encerra a instância, destruindo as chaves efêmeras na memória e tornando os dados do disco local inacessíveis.

Implementando CMK no Fluxo de Trabalho do Lakebase

A implementação segue o modelo padrão de delegação da Conta para Workspace do Databricks. Essa separação de funções garante que os Administradores de Segurança possam gerenciar chaves sem precisar de acesso aos dados em si. Uma vez que uma chave é configurada no nível do workspace, todos os projetos do Lakebase usam o CMK como parte do fluxo de trabalho de criptografia.

Etapa 1: Configuração da Chave

Um Administrador de Conta cria uma Configuração de Chave no Console da Conta Databricks. Esse objeto contém o identificador da chave (ARN para AWS KMS, URL do Key Vault para Azure ou ID da Chave para Google Cloud KMS) e a função IAM ou entidade de serviço que o Lakebase assumirá para executar operações de Encapsulamento e Desencapsulamento.

Etapa 2: Vinculação ao Workspace

A configuração é então mapeada para um Workspace específico. Para o Lakebase, isso significa:

  • Novos Projetos: Todos os novos projetos do Lakebase herdam automaticamente o CMK do workspace.
  • Isolamento: Diferentes workspaces podem usar CMKs diferentes para atender a requisitos de segurança multi-inquilino ou multi-departamental.

Etapa 3: Gerenciamento de Ciclo de Vida e Rotação

O Lakebase suporta Rotação Contínua de Chaves. Ao girar seu CMK no console do seu provedor de nuvem:

  • A hierarquia de criptografia de envelope permite a rotação contínua - seu CMK pode ser girado no seu KMS na nuvem sem re-criptografar dados ou alterar DEKs.
  • Não há tempo de inatividade ou re-criptografia manual necessária.

Auditabilidade de Segurança

Como o CMK reside em sua conta na nuvem, as operações criptográficas contra sua chave são registradas no serviço de auditoria do seu provedor (AWS CloudTrail, Azure Monitor ou Google Cloud Audit Logs).

Comece com Soberania de Dados Aprimorada

Se sua organização exige o mais alto nível de controle criptográfico sobre suas cargas de trabalho Postgres, o CMK do Lakebase agora está disponível para clientes do nível Enterprise.

Pronto para proteger seus dados? Entre em contato com sua equipe de contas Databricks para habilitar Chaves Gerenciadas pelo Cliente para seu workspace, ou visite nossa documentação técnica para revisar as políticas IAM e configurações de KMS pré-requisitos.

Ainda não é um cliente Databricks? Comece com um teste gratuito.

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

Receba os posts mais recentes na sua caixa de entrada

Assine nosso blog e receba os posts mais recentes diretamente na sua caixa de entrada.