Concluindo a visão do Lakehouse: armazenamento aberto, acesso aberto e governança unificada

Até agora, as organizações não tinham como unificar as políticas de controle de acesso baseado em atributos (ABAC) nos diferentes mecanismos de query e ferramentas que usam no lakehouse. Hoje, temos o prazer de anunciar a Prévia dos controles de acesso granulares para mecanismos externos. Com este lançamento, o Unity Catalog se torna o primeiro e único catálogo a oferecer suporte a ABAC entre mecanismos, permitindo que as equipes definam filtros de linha baseados em tags e máscaras de coluna uma única vez e os apliquem em todos os lugares onde os dados são acessados.

A governança unificada com o Unity Catalog elimina um dos maiores desafios remanescentes no lakehouse: a governança fragmentada em diferentes mecanismos. Desenvolvido com base nas APIs de catálogo REST do Apache Iceberg, o Unity Catalog garante que os dados permaneçam abertos para mecanismos externos e, ao mesmo tempo, sejam totalmente governados com políticas refinadas.

Concluindo a visão do Lakehouse

À medida que as organizações adotaram a arquitetura lakehouse, os dados saíram de sistemas de data warehouse proprietários e foram para formatos de armazenamento e tabelas abertos, onde podiam ser acessados por vários engines, como Spark, Trino e DuckDB, sem duplicação ou lock-in.

Mas esse novo nível de abertura introduziu um problema difícil: a governança precisava funcionar em todos os lugares onde os dados pudessem ser acessados. Em warehouses tradicionais, os controles em nível de linha e coluna eram aplicados em um único engine. No lakehouse aberto, os dados agora podiam ser acessados por muitos mecanismos, e garantir a aplicação consistente de políticas em todos eles se tornou um novo desafio.

As equipes de segurança eram forçadas a escolher entre abordagens complicadas ou arriscadas, como:

• Duplicar manualmente as políticas de controle de acesso em vários sistemas, aumentando a carga operacional e o risco de drift de políticas
• Manter views filtradas separadas ou cópias de tabelas para diferentes mecanismos ou regiões, o que introduz duplicação e inconsistência
• Ou ignorar completamente a governança refinada, concedendo acesso amplo no nível da tabela a ferramentas downstream

Os clientes sempre nos disseram que, embora os formatos abertos tenham cumprido a promessa de compute flexível com base em dados compartilhados, essa visão só poderia ser totalmente realizada se a governança também fosse unificada.

Desafios com a governança granular em vários mecanismos

O Unity Catalog já oferece controle de acesso universal em nível de tabela em vários mecanismos por meio da distribuição de credenciais — o passo na unificação da governança no lakehouse. No entanto, apenas o acesso em nível de tabela não resolve cenários em que os usuários devem ver apenas um subconjunto de linhas ou colunas. Dados sensíveis geralmente precisam de controles mais granulares, como restrições regionais ou mascaramento de PII.

A aplicação refinada normalmente acontece dentro do motor de compute. No Databricks Runtime, resolvemos isso usando a filtragem do lado do servidor, em que as queries que exigem aplicação granular são roteadas de forma transparente por uma frota de filtragem segura para que somente os dados permitidos sejam processados. Mas engines externos como DuckDB, Trino ou Spark executados fora do Databricks não têm essa lógica integrada e não aplicam políticas de governança com semântica consistente.

Isso trouxe à tona um desafio central: as organizações querem a flexibilidade de usar qualquer mecanismo no lakehouse, sem perder a governança detalhada.

Princípios-chave

Nossos clientes nos disseram que qualquer solução precisava:

• Funciona com qualquer engine e ferramenta, incluindo aqueles sem recursos de governança nativos (por exemplo, DuckDB, Python, pandas)
• Preserve toda a expressividade das políticas do Unity Catalog, incluindo o controle de acesso baseado em atributos (ABAC) e a lógica personalizada de mascaramento de linhas e colunas
• Opere de forma eficiente em escala, sem introduzir alta latência ou sobrecarga operacional complexa

Nossa abordagem

Há duas abordagens para estender a governança de granularidade fina entre os mecanismos:

1. Troca de políticas - os fornecedores concordam com uma linguagem de política compartilhada e um modelo de aplicação que cada mecanismo implementa.
2. Aplicação centralizada - O catálogo governante avalia as políticas e as aplica antes que os dados cheguem ao mecanismo externo.

A longo prazo, esperamos que o ecossistema convirja para a primeira abordagem — um padrão de política compartilhado que mecanismos confiáveis possam aplicar nativamente.

No entanto, fazer isso corretamente requer resolver três desafios fundamentais:

• Desenvolvimento de uma linguagem e semântica de política comum entre os sistemas - Os modelos de identidade, a semântica de política e os ambientes de execução variam muito entre os sistemas. Qualquer padrão inicial de vários fornecedores correria o risco de convergir para uma linguagem de denominador comum mais baixo que não pudesse oferecer suporte a políticas avançadas, como controle de acesso baseado em atributos, subconsultas complexas etc.
• Transmissão segura do contexto da política - Os catálogos devem poder compartilhar o contexto da política com engines externos sem vazar informações confidenciais de identidade ou de atributos
• Estabelecendo confiança e aplicação verificável entre mecanismos - Os catálogos precisam ter confiança de que os mecanismos aplicarão as políticas de forma segura e consistente

Para resolver esses desafios, será necessário um amplo alinhamento em todo o ecossistema. Já iniciamos as primeiras discussões na comunidade do Apache Iceberg para explorar os fundamentos de um modelo de política compartilhada que possa suportar os sofisticados requisitos de governança dos quais as empresas dependem.

O modelo ABAC do Unity Catalog foi criado para segurança de nível empresarial, com suporte a controles expressivos, como filtros de linha com subconsultas complexas, lógica condicional orientada por tags governadas e atributos de usuário e funções de mascaramento avançadas usando UDFs em SQL, Python e Scala. Temos o compromisso de colaborar com a comunidade de código aberto para estabelecer um padrão que ofereça suporte a esses primitivos de segurança avançados e escale em todo o ecossistema.

Em paralelo, a aplicação centralizada é a única abordagem que oferece governança detalhada em engines externos hoje. Ela permite que os clientes mantenham toda a expressividade dos recursos de governança do Unity Catalog, garante a aplicação consistente em qualquer engine externo (incluindo aqueles sem um runtime de política nativo) e evita a dependência da confiança implícita em sistemas externos.

Baseado em padrões abertos

Para permitir a aplicação entre mecanismos, o Unity Catalog se baseia em padrões abertos. O protocolo de catálogo Iceberg REST permite que os mecanismos solicitem que o servidor determine quais dados devem ser lidos e como eles devem ser acessados. Isso é chamado de "planejamento de varredura" e permite que o catálogo otimize os padrões de acesso aos dados e melhore o desempenho da query.

O Unity Catalog estende esse modelo gerando planos de varredura filtrados que aplicam políticas refinadas, como filtros de linha, máscaras de coluna e regras baseadas em atributos, com base nas permissões do usuário.

Veja como funciona: Quando um mecanismo externo solicita acesso a uma tabela governada:

• O mecanismo emite uma solicitação de varredura usando a API de catálogo REST do Iceberg
• O Unity Catalog avalia as políticas granulares aplicáveis
• O UC aplica os filtros de linha e as máscaras de coluna necessários e retorna um plano de verificação filtrado 

Somente o subconjunto de dados autorizado é exposto ao mecanismo para processamento. Como a aplicação ocorre como parte do planejamento no lado do servidor, nenhuma lógica de política personalizada é necessária no mecanismo.

A Databricks usa serverless compute altamente otimizado para realizar essa filtragem, aproveitando a mesma infraestrutura usada para garantir a segurança no Databricks Runtime. Dentro desse sistema, os dados filtrados são processados de forma incremental e eficiente usando a tecnología que também sustenta os pipelines declarativos da Databricks. Isso garante que os resultados sejam retornados a um custo baixo e com latência mínima.

Com base nas APIs de catálogo REST do Iceberg, o Unity Catalog estabelece a base para uma governança aberta e entre mecanismos, em que as políticas são aplicadas de forma eficiente e consistente em todos os mecanismos em uma única cópia dos dados.

Defina políticas uma vez, aplique em todos os lugares

A aplicação refinada em mecanismos externos permite que os clientes adotem um modelo de segurança único e dimensionável para todas as tabelas gerenciadas do Unity Catalog - Delta Lake e Iceberg.

Com o ABAC, os administradores definem filtros de linha e a lógica de mascaramento de coluna uma única vez, e as políticas são aplicadas dinamicamente com base em tags governadas e atributos de usuário. Agora, essa mesma camada de política unificada se estende para além do Databricks, começando com o Apache Spark e se expandindo ainda mais à medida que o ecossistema aberto adota as Iceberg REST catalog Scan APIs.

O que isso significa para o ecossistema de lakehouse aberto

A governança refinada em mecanismos externos é um marco importante para o open lakehouse. Os formatos de tabela abertos proporcionaram aos clientes a flexibilidade para a execução de vários mecanismos em dados compartilhados. O Unity Catalog agora fornece a camada de governança correspondente, permitindo que as políticas ABAC sejam aplicadas independentemente de onde os dados são acessados.

Isso estabelece uma nova base para a interoperabilidade no lakehouse: formatos abertos para dados, APIs abertas para acesso e um único sistema de governança aplicado de forma consistente em todo o ecossistema.

O que vem a seguir

Estamos integrando clientes selecionados para experimentar controles de acesso refinados para mecanismos externos, com suporte mais amplo a ser seguido à medida que outros mecanismos adotarem as APIs de verificação do catálogo REST do Iceberg. Preencha este formulário ou entre em contato com a equipe da sua account Databricks para ser incluído na visualização.

(This blog post has been translated using AI-powered tools) Original Post