Criar conta grátis

Implementar e gerenciar uma solução de análise

04. Segurança SQL — RLS, CLS, permissões e DDM

Uma tabela de clientes reúne região, nome e documento. Alguns usuários devem ver somente sua região; outros podem ver todas as regiões, mas não o documento. Essas necessidades não são atendidas por uma única configuração: permissões SQL, segurança de linha, segurança de coluna e mascaramento atuam em partes diferentes da consulta.

5 min de leitura60 questões para praticarRevisado em 30/09/2026

Uma tabela de clientes reúne região, nome e documento. Alguns usuários devem ver somente sua região; outros podem ver todas as regiões, mas não o documento. Essas necessidades não são atendidas por uma única configuração: permissões SQL, segurança de linha, segurança de coluna e mascaramento atuam em partes diferentes da consulta.

Permissão sobre objetos

As permissões SQL definem operações sobre objetos e escopos. SELECT autoriza leitura, enquanto outras permissões podem permitir alterações. O desenho deve conceder apenas o necessário e considerar funções, concessões diretas e permissões herdadas. Ter acesso ao workspace ou conseguir conectar-se não resolve automaticamente todos os direitos SQL exigidos.

Uma view pode oferecer uma interface controlada, mas seu uso exige avaliar permissões e caminhos alternativos para as tabelas. Expor um subconjunto de colunas em uma consulta da aplicação não impede que um usuário autorizado execute outra consulta. A restrição precisa estar no mecanismo de segurança adequado ao objetivo.

Funções de banco permitem administrar conjuntos de permissões e associar usuários sem repetir cada concessão individualmente. Elas facilitam manutenção, mas não eliminam a necessidade de revisar membros e outros direitos. Ao investigar acesso inesperado, uma lista de GRANTs explícitos pode ser insuficiente se a plataforma também fornece direitos por workspace ou item. A auditoria deve reunir as camadas. O objetivo não é encontrar uma instrução isolada que pareça restritiva, e sim explicar por que a identidade consegue executar aquela operação naquele mecanismo.

RLS e CLS

Row-level security, ou RLS, aplica uma condição para determinar quais linhas são visíveis no contexto autorizado. Um predicado pode relacionar o usuário ou seu contexto às regiões permitidas. O teste precisa demonstrar que duas identidades recebem conjuntos diferentes quando isso é previsto. Aplicar um filtro manual no relatório não equivale a instituir RLS na origem SQL.

Column-level security, ou CLS, controla acesso a colunas. É apropriada quando um atributo deve ficar indisponível para determinado público. RLS não esconde automaticamente a coluna Documento: apenas limita quais registros podem ser vistos. Da mesma forma, retirar uma coluna não determina quais regiões permanecem acessíveis. Uma necessidade pode exigir os dois recortes.

Continue lendo de graça

O capítulo inteiro está liberado no plano gratuito

Criar conta leva menos de um minuto e não pede cartão. Você destrava o texto completo, o mapa mental, o PDF para estudar off-line e ainda resolve questões inéditas todo dia.

Leu o resumo? Agora pratique.

São 60 questões inéditas de Segurança SQL — RLS, CLS, permissões e DDM, todas comentadas alternativa por alternativa.

Criar conta grátis e praticar

Você volta para este capítulo depois de criar a conta.

Fontes consultadas

  • https://learn.microsoft.com/en-us/fabric/data-warehouse/row-level-security
  • https://learn.microsoft.com/en-us/fabric/data-warehouse/dynamic-data-masking
  • https://learn.microsoft.com/en-us/fabric/data-warehouse/column-level-security
  • https://learn.microsoft.com/en-us/fabric/data-warehouse/sql-granular-permissions
  • https://learn.microsoft.com/en-us/fabric/data-warehouse/howto-dynamic-data-masking