O que é segurança em nível de linha?

A segurança em nível de linha (RLS) é um controle de acesso a banco de dados que limita quais linhas de uma tabela um usuário pode ler ou alterar com base em sua identidade, função ou contexto de sessão.

Em vez de restringir o acesso a tabelas inteiras ou colunas específicas, o RLS filtra os dados linha por linha. O mecanismo do banco de dados aplica o filtro automaticamente no momento da consulta, de modo que a mesma regra se aplica independentemente de qual ferramenta o usuário utilize para acessar os dados.

O RLS faz parte do controle de acesso refinado, juntamente com:

• Segurança em nível de coluna
• Mascaramento de dados
• Permissões em nível de tabela

Por exemplo, um vendedor pode consultar a tabela de pedidos da empresa, mas ver apenas os pedidos da sua região atribuída, mesmo que a tabela contenha os dados de todas as regiões. O usuário escreve uma instrução SELECT normal, e o mecanismo retorna apenas as linhas que ele tem permissão para ver.

O RLS é agora um componente fundamental para SaaS multi-tenant, segregação de dados regionais e casos de uso de conformidade. Este artigo aborda como o RLS funciona, onde ele ajuda, onde deixa a desejar e como funciona na plataforma Databricks.

Como funciona a segurança em nível de linha?

A segurança em nível de linha funciona aplicando uma regra de filtro, frequentemente chamada de política ou predicado, a uma tabela. Quando um usuário executa uma consulta, o mecanismo do banco de dados aplica automaticamente esse filtro e retorna apenas as linhas que o usuário tem permissão para ver.

Na prática, o RLS geralmente funciona em três etapas:

1. O usuário executa uma consulta: O usuário escreve uma consulta padrão sem adicionar filtros de segurança por conta própria.
2. O banco de dados verifica a identidade do usuário: O mecanismo avalia o usuário por meio de uma função integrada como CURRENT_USER, uma variável de sessão definida pelo aplicativo ou uma tabela de mapeamento que conecta usuários e grupos aos dados permitidos.
3. O mecanismo filtra o resultado: O predicado RLS retorna TRUE para as linhas que o usuário pode ver e FALSE para todo o resto. Apenas as linhas que passam pelo predicado são retornadas.

Como a aplicação ocorre na camada de banco de dados, a mesma regra se aplica de forma consistente em todos os caminhos de acesso, incluindo painéis de BI, notebooks, SQL ad-hoc, APIs e ferramentas de terceiros. Essa consistência é o que torna o RLS poderoso: uma única regra, aplicada em todos os lugares, imposta pelo mecanismo.

A maioria dos mecanismos também distingue entre a aplicação do lado de leitura e do lado de gravação. Um predicado de leitura controla o que uma consulta SELECT retorna. Um predicado de gravação, frequentemente definido separadamente com uma cláusula WITH CHECK, controla quais linhas um usuário pode inserir, atualizar ou excluir.

Os dois predicados podem ser iguais, mas não precisam ser. Por exemplo, um usuário pode ter permissão para ler linhas de todas as regiões, mas apenas inserir linhas para sua própria região. Definir ambos os lados é importante quando uma tabela aceita gravações, pois ignorar a verificação de gravação é uma das maneiras mais comuns pelas quais as equipes configuram incorretamente o RLS em produção.

Segurança em nível de linha vs. segurança em nível de coluna e outros controles de acesso

O RLS é um dos vários controles de acesso refinados e, em produção, quase sempre é combinado com outros. A tabela abaixo mostra como cada controle se encaixa.

Esses controles são projetados para funcionar em camadas. Uma configuração típica usa permissões em nível de tabela para controlar quem pode acessar uma tabela, RLS para definir o escopo de quais linhas ficam visíveis e segurança em nível de coluna ou mascaramento de dados para proteger campos confidenciais nessas linhas. Tratá-los como uma pilha, em vez de um menu de alternativas, torna a governança auditável e resiliente. Uma configuração incorreta em uma camada não compromete as outras.

Casos de uso comuns para segurança em nível de linha

O RLS é a forma padrão de impor quem pode ver o que dentro de uma tabela compartilhada, filtrando as linhas com base nos atributos de um usuário em relação a uma coluna de chaveamento, como região, tenant ou classificação. A maioria das equipes recorre a ele quando um único conjunto de dados precisa atender a vários públicos com regras de visibilidade diferentes.

• SaaS multi-tenant: Isole os dados de cada cliente dentro de tabelas compartilhadas usando uma coluna tenant_id e o contexto da sessão. Isso evita o custo operacional de ter um esquema ou um banco de dados por tenant, mantendo os dados de cada cliente totalmente separados no momento da consulta.
• Segregação regional: Restrinja dados de vendas, HR ou pedidos para que os usuários vejam apenas registros de seu país ou região, sem dividir a tabela subjacente por geografia.
• Acesso departamental: Dê às equipes de finanças, marketing e operações acesso à mesma tabela, mas a linhas diferentes, mapeadas por uma coluna de departamento ou centro de custo.
• Conformidade regulatória: Imponha regras de residência de dados, por exemplo, mantendo os registros da EU visíveis apenas para funcionários baseados na EU sob a GDPR, ou restringindo categorias protegidas sob HIPAA, CCPA ou regulamentações específicas do setor.
• Dados clínicos e de saúde: Permita que os médicos compartilhem uma tabela de pacientes enquanto visualizam apenas seus próprios pacientes, apoiando o acesso mínimo necessário da HIPAA sem duplicar registros em silos.
• Portais de parceiros e fornecedores: Compartilhe um único conjunto de dados entre parceiros externos enquanto filtra cada um para seus próprios registros, de modo que uma única tabela de fonte da verdade possa alimentar dezenas de views voltadas para parceiros.

Como implementar a segurança em nível de linha: 4 etapas

O padrão geral é consistente entre as plataformas, com a sintaxe específica do fornecedor preenchida onde necessário.

1. Identifique a lógica do filtro: Decida o que determina o acesso: ID do usuário, associação a grupos, região, ID do tenant ou uma tabela de mapeamento. A lógica do filtro deve ser derivável do contexto da sessão ou de uma busca estável, não de valores que o usuário controla no momento da consulta.
2. Adicione ou confirme a coluna de chaveamento: Certifique-se de que a tabela tenha uma coluna que o filtro possa usar, como tenant_id, region ou owner_id. Se essa coluna ainda não existir, planeje um preenchimento retroativo antes que a política entre em vigor e considere indexar a coluna para manter o predicado de baixo custo.
3. Defina a política ou o filtro de linha: Escreva o predicado que retorna TRUE para as linhas que o usuário tem permissão para ver e uma verificação separada para gravações, se a tabela as aceitar. Mantenha a lógica em SQL sempre que possível. A maioria dos mecanismos otimiza predicados SQL melhor do que chamadas de função em outras linguagens.
4. Teste com várias identidades de usuário: Execute consultas com diferentes funções e confirme se as linhas corretas aparecem e se nada vaza entre os tenants. Inclua um teste negativo: um usuário sem linhas correspondentes deve ver um resultado vazio, não um erro, e um usuário privilegiado deve ser testado separadamente para confirmar o comportamento de desvio do proprietário (owner-bypass).

Benefícios da segurança em nível de linha

Mover a lógica de acesso para a camada de dados traz vantagens de várias maneiras práticas. Em resumo, o banco de dados se torna a fonte da verdade para o acesso, em vez de cada aplicativo que toca os dados.

• Lógica centralizada: As regras de acesso residem junto com os dados, e não espalhadas pelo código do aplicativo ou pelas ferramentas de BI.
• Aplicação consistente: A mesma regra se aplica se o usuário fizer uma consulta a partir de um notebook, de um painel ou de uma API.
• Defesa em profundidade: O RLS adiciona uma segunda camada de proteção caso as verificações na camada do aplicativo sejam contornadas ou apresentem falhas.
• Código de aplicativo mais simples: Os desenvolvedores não precisam anexar cláusulas WHERE manuais em cada consulta.
• Auditorias mais fáceis: As equipes de conformidade podem revisar uma única política em vez de rastrear a lógica de acesso em vários sistemas.

Limitações e riscos da segurança em nível de linha

A RLS é poderosa, mas apresenta armadilhas conhecidas para as quais as equipes devem se planejar. A maioria delas surge apenas em produção ou durante uma auditoria, o que faz com que valha a pena conhecê-las com antecedência.

Bypass de administradores e proprietários

Em muitos bancos de dados, os proprietários das tabelas e administradores com altos privilégios fazem o bypass da RLS por padrão. O PostgreSQL, por exemplo, exige a configuração FORCE ROW LEVEL SECURITY para aplicar políticas ao proprietário da tabela, e configurações semelhantes existem em outros mecanismos. Esta é uma descoberta comum de auditoria: assuma que os usuários privilegiados veem todas as linhas, a menos que sua configuração force explicitamente a aplicação da política a eles. Teste a política a partir de uma sessão privilegiada, e não apenas de uma sessão comum, antes de aprová-la.

Sem ocultação de colunas ou resumos

A RLS filtra linhas, mas não oculta colunas nem bloqueia resultados agregados. Um analista impedido de ver registros individuais da EU ainda pode executar SELECT COUNT(*) na tabela não filtrada se a RLS não estiver associada a restrições de coluna ou de agregação. Combine a RLS com segurança em nível de coluna ou mascaramento de dados para fechar essa lacuna, e considere se as próprias consultas agregadas precisam ser governadas para as tabelas mais confidenciais.

Sobrecarga de desempenho

Toda consulta tem o predicado RLS aplicado, o que pode prejudicar o desempenho se a lógica do filtro for complexa ou se a coluna de chaveamento não estiver indexada. Indexe as colunas que a política referencia e mantenha o predicado o mais simples possível. Prefira expressões CASE diretas em vez de subconsultas ou buscas em tabelas de mapeamento dentro do filtro. Se o mecanismo for compatível, materialize o mapeamento de usuários para linhas em uma tabela pequena e bem indexada, em vez de computá-lo dinamicamente.

Complexidade de depuração

Conjuntos de resultados vazios causados pela RLS parecem idênticos a "nenhum dado correspondente". Os desenvolvedores que buscam uma linha ausente geralmente passam horas antes de perceberem que a política a filtrou. Registre a identidade do usuário efetivo e a versão da política durante o desenvolvimento, ofereça aos engenheiros uma maneira de confirmar se a RLS está ativa quando os resultados parecerem incorretos e documente a política no mesmo local que o esquema da tabela para que ela possa ser encontrada facilmente.

Regras de gravação mal configuradas

As políticas de RLS geralmente têm dois lados: uma cláusula USING que filtra o que os usuários podem ler e uma cláusula WITH CHECK que controla o que eles podem inserir ou atualizar. Definir uma sem a outra é um erro clássico: a filtragem de leitura sem verificação de gravação permite que os usuários insiram ou atualizem linhas que não deveriam possuir. Sempre defina ambos os lados quando a tabela aceitar gravações e execute um teste do lado da gravação como parte da revisão da política.

Segurança em nível de linha na plataforma Databricks

Na plataforma Databricks, a segurança em nível de linha é gerenciada por meio de filtros de linha no Unity Catalog, a camada de governança unificada da Databricks para dados e IA. O padrão é simples: defina uma função SQL definida pelo usuário que retorne verdadeiro para as linhas que um determinado usuário tem permissão para ver e, em seguida, anexe-a à tabela de destino. O filtro é executado automaticamente no momento da consulta, usando a identidade do usuário atual ou o contexto da sessão para determinar quais linhas retornar.

Os filtros de linha são aplicados de forma consistente no Databricks SQL, notebooks, jobs e ferramentas de BI conectadas, sem a necessidade de lógica personalizada por superfície. Eles funcionam em conjunto com máscaras de coluna para um controle de acesso refinado completo, e cada consulta que toca em uma tabela filtrada é capturada nos logs de linhagem e auditoria do Unity Catalog, para que as equipes de governança e segurança possam ver exatamente quais políticas se aplicam a quais tabelas e quais usuários consultaram o quê.

Perguntas frequentes

O que é segurança dinâmica em nível de linha? A RLS dinâmica avalia a regra de acesso no momento da consulta usando a identidade do usuário atual ou o contexto da sessão, de modo que a mesma política retorna resultados diferentes para usuários diferentes. Todas as implementações modernas de RLS funcionam dessa maneira, incluindo as políticas ABAC da Databricks, filtros de linha e exibições dinâmicas.

Qual é a diferença entre segurança em nível de linha e segurança em nível de coluna? A RLS restringe quais linhas um usuário pode ver; a segurança em nível de coluna restringe quais colunas, normalmente para ocultar campos confidenciais, como salário ou números de identificação pessoal. A maioria das implantações em produção usa ambas em conjunto.

A segurança em nível de linha é suficiente por si só para proteger dados confidenciais? Não. A RLS gerencia a visibilidade das linhas, mas não mascara os valores das colunas, não bloqueia consultas agregadas nem substitui o gerenciamento de identidade e acesso. Combine-a com segurança em nível de coluna, concessões em nível de tabela e registro de auditoria como parte de uma estratégia de defesa em profundidade.

Como a Databricks implementa a segurança em nível de linha? Por meio do Unity Catalog, com três opções: políticas ABAC, filtros de linha em nível de tabela e exibições dinâmicas. O ABAC é recomendado para governança em escala; os filtros de linha e as exibições dinâmicas estão disponíveis para necessidades mais personalizadas.

A segurança em nível de linha afeta o desempenho da consulta? Sim, mas o impacto geralmente é gerenciável. Mantenha a lógica da política simples, indexe as colunas que a política referencia e prefira UDFs SQL em vez de UDFs Python. Analise o perfil das consultas antes e depois das alterações de política para detectar regressões com antecedência.

Comece a usar o controle de acesso refinado na Databricks

A segurança em nível de linha é mais eficaz como parte de um modelo de governança mais amplo que também abrange colunas, mascaramento, linhagem e auditoria. Veja como o Unity Catalog une a segurança em nível de linha, o mascaramento de colunas e a governança unificada na plataforma Databricks.

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