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.
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.
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