SQL Academy · Aula

Políticas de segurança em nível de linha

Filtre linhas automaticamente por usuário.

Políticas de segurança em nível de linha é uma aula grátis de SQL Academy no CoddyKit. Esta é a aula 2 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de SQL Academy, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de SQL Academy inclui 4 aulas no total.

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

A segurança em nível de linha (RLS) é um recurso do PostgreSQL que permite controlar quais linhas de uma tabela determinado usuário ou papel do banco de dados pode ver ou modificar. Em vez de filtrar linhas em cada consulta, você define uma política uma vez e PostgreSQL a impõe automaticamente em cada SELECT, INSERT, UPDATE e DELETE.

Imagine isso como uma cláusula WHERE invisível anexada à própria tabela, e não a uma consulta específica.

Ativando RLS em uma tabela

RLS está desativada por padrão. Você precisa ativá-la explicitamente em cada tabela usando ALTER TABLE ... ENABLE ROW LEVEL SECURITY. Uma vez ativada, qualquer papel que não seja o proprietário da tabela não verá nenhuma linha até que pelo menos uma política seja criada.

-- Create a sample table
CREATE TABLE orders (
  id        SERIAL PRIMARY KEY,
  owner     TEXT NOT NULL,
  amount    NUMERIC(10,2)
);

-- Enable RLS
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

Criando sua primeira política

Uma política é criada com CREATE POLICY. Dê-lhe um nome, especifique a tabela e forneça uma expressão USING. A cláusula USING é uma expressão booleana avaliada para cada linha — somente as linhas para as quais a expressão retorna TRUE ficam visíveis ao usuário.

-- Allow each user to see only their own orders
CREATE POLICY orders_owner_policy
  ON orders
  FOR SELECT
  USING (owner = current_user);

As cláusulas USING e WITH CHECK

As políticas têm duas cláusulas de filtro que servem a propósitos diferentes:

USING — filtra linhas em operações de leitura (SELECT, UPDATE, DELETE). Uma linha fica visível somente se USING retornar TRUE.
WITH CHECK — valida linhas em operações de escrita (INSERT, UPDATE). Uma operação de escrita é permitida somente se WITH CHECK retornar TRUE. Se for omitida, USING será reutilizada para as verificações de escrita.

-- Allow users to select and insert only their own rows
CREATE POLICY orders_isolation
  ON orders
  FOR ALL
  USING       (owner = current_user)
  WITH CHECK  (owner = current_user);

Escopo da política: FOR SELECT, INSERT, UPDATE, DELETE

Uma única política pode abranger todos os comandos (FOR ALL) ou um comando específico. Separar as políticas por comando oferece um controle granular — por exemplo, permitindo que todos os usuários leiam todas as linhas, mas modifiquem somente as próprias.

-- Everyone can read all orders
CREATE POLICY read_all_orders
  ON orders
  FOR SELECT
  USING (true);

-- But each user can only update their own orders
CREATE POLICY update_own_orders
  ON orders
  FOR UPDATE
  USING       (owner = current_user)
  WITH CHECK  (owner = current_user);

Usando o usuário da sessão e current_user

O PostgreSQL fornece funções integradas para identificar o usuário ativo dentro de uma expressão de política:

current_user — o papel cujos privilégios estão ativos no momento (pode mudar após SET ROLE).
usuário da sessão — o papel que abriu a conexão (nunca muda durante a sessão).

A maioria das políticas de RLS depende de current_user porque ele reflete o papel efetivo após a troca de papel.

-- Inspect the current identity inside a query
SELECT current_user, session_user;

Aplicando RLS a papéis específicos

Por padrão, uma política se aplica a PUBLIC (todos os papéis). Você pode restringi-la a um papel específico usando a cláusula TO. Isso é útil quando você deseja uma política para usuários comuns e outra diferente para um papel de administrador.

-- Policy only for the 'app_user' role
CREATE POLICY app_user_policy
  ON orders
  FOR SELECT
  TO app_user
  USING (owner = current_user);

-- Separate permissive policy for 'admin' role
CREATE POLICY admin_full_access
  ON orders
  FOR ALL
  TO admin
  USING (true)
  WITH CHECK (true);

Políticas PERMISSIVE versus RESTRICTIVE

Várias políticas na mesma tabela podem interagir de duas maneiras:

PERMISSIVE (padrão) — todas as políticas permissivas são combinadas com OR. Uma linha fica acessível se qualquer política permissiva permitir o acesso.
RESTRICTIVE — as políticas restritivas são combinadas com AND ao resultado permissivo. Uma linha fica acessível somente se passar pela política restritiva e por pelo menos uma política permissiva.

-- Restrictive policy: block access to archived orders for everyone
CREATE POLICY no_archived_rows
  ON orders
  AS RESTRICTIVE
  FOR SELECT
  USING (amount > 0);

Ignorando RLS: BYPASSRLS e proprietários de tabelas

O proprietário da tabela e os superusuários ignoram RLS por padrão e sempre veem todas as linhas. Você pode conceder o atributo BYPASSRLS a um papel que precise de acesso irrestrito sem ser um superusuário. Por outro lado, pode obrigar o proprietário a obedecer ao RLS usando FORCE ROW LEVEL SECURITY.

-- Force the table owner to also obey RLS policies
ALTER TABLE orders FORCE ROW LEVEL SECURITY;

-- Grant BYPASSRLS to a trusted service account
ALTER ROLE service_account BYPASSRLS;

Modificando e removendo políticas

Você pode atualizar uma política existente com ALTER POLICY ou removê-la completamente com DROP POLICY. Remover todas as políticas enquanto o RLS continua habilitado significa que nenhum papel que não seja o proprietário poderá acessar linhas. Para remover o RLS completamente, desabilite-o com ALTER TABLE.

-- Rename a policy
ALTER POLICY orders_owner_policy ON orders
  RENAME TO user_isolation_policy;

-- Update the USING expression
ALTER POLICY user_isolation_policy ON orders
  USING (owner = current_user AND amount >= 0);

-- Remove a policy
DROP POLICY admin_full_access ON orders;

-- Disable RLS entirely on the table
ALTER TABLE orders DISABLE ROW LEVEL SECURITY;

Padrão do mundo real: isolamento de dados multi-inquilino

Um padrão comum de RLS em aplicativos de software como serviço multi-inquilino armazena uma coluna de identificador do locatário em cada tabela e usa uma variável no nível da sessão (set_config) para transmitir o identificador do locatário no momento da conexão. Em seguida, a política compara o identificador do locatário de cada linha com essa configuração.

-- Table with tenant isolation column
CREATE TABLE documents (
  id         SERIAL PRIMARY KEY,
  tenant_id  TEXT NOT NULL,
  title      TEXT
);

ALTER TABLE documents ENABLE ROW LEVEL SECURITY;

-- Policy reads the tenant from a session variable
CREATE POLICY tenant_isolation
  ON documents
  FOR ALL
  USING       (tenant_id = current_setting('app.tenant_id'))
  WITH CHECK  (tenant_id = current_setting('app.tenant_id'));

-- Application sets the variable before running queries
SELECT set_config('app.tenant_id', 'tenant_42', true);

-- Now only tenant_42 documents are visible
SELECT * FROM documents;

Verificação de conhecimentos

Teste sua compreensão das políticas de Segurança no nível de linha no PostgreSQL.

Recapitulação da lição

Nesta lição, você aprendeu como a Segurança no nível de linha permite filtrar linhas automaticamente, com base em políticas, diretamente no nível do banco de dados:

Habilite o RLS em uma tabela com ALTER TABLE ... ENABLE ROW LEVEL SECURITY.
Use CREATE POLICY com uma cláusula USING para filtrar linhas legíveis e uma cláusula WITH CHECK para validar linhas gravadas.
Defina o escopo das políticas para comandos específicos (SELECT, INSERT, UPDATE, DELETE, ALL) e papéis específicos usando a cláusula TO.
Combine políticas PERMISSIVE (lógica OR) e RESTRICTIVE (lógica AND) para criar um controle de acesso em camadas.
Os proprietários de tabelas e os superusuários ignoram o RLS por padrão; use FORCE ROW LEVEL SECURITY para substituir esse comportamento.
O padrão multi-inquilino que usa current_setting() é uma aplicação poderosa do RLS no mundo real.

O RLS é a forma padrão de impor o isolamento de dados de maneira limpa e consistente, sem espalhar cláusulas WHERE por todas as consultas do aplicativo.

Perguntas Frequentes

A aula “Políticas de segurança em nível de linha” é grátis?

Sim — o texto completo de “Políticas de segurança em nível de linha” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de SQL Academy, atualize para CoddyKit PRO. O curso de SQL Academy inclui 4 aulas no total.

O que vou aprender em “Políticas de segurança em nível de linha”?

Filtre linhas automaticamente por usuário. Você pratica SQL Academy com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.

Preciso ter experiência prévia para começar SQL Academy?

Nenhuma experiência prévia é necessária. SQL Academy no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 2 de 4.

Quanto tempo leva a aula “Políticas de segurança em nível de linha”?

A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.

Posso escrever e executar código nesta aula de SQL Academy?

Sim. Cada aula de SQL Academy inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.

Todas as aulas deste curso

Funções e privilégios
Políticas de segurança em nível de linha
Permissões em nível de coluna
Auditando o acesso

← Voltar para SQL Academy