REVOKE no SQL: revogar privilegios concedidos com seguranca

REVOKE e a imagem espelhada de GRANT: retira privilegios que voce concedeu antes a um usuario ou a um papel. Na pratica, revogar e mais traicoeiro do que conceder, porque o mesmo acesso pode chegar por varios caminhos ao mesmo tempo.

Sintaxe basica

Para retirar um privilegio especifico em uma tabela, informe o privilegio, o objeto e o beneficiario:

REVOKE INSERT ON orders FROM analyst;

Voce pode revogar varios privilegios de uma vez e mirar colunas especificas:

REVOKE SELECT, UPDATE ON users FROM analyst;
REVOKE UPDATE (salary) ON employees FROM analyst;
REVOKE ALL PRIVILEGES ON orders FROM analyst;

O principio central: REVOKE so remove o que foi concedido diretamente aquele beneficiario. Se o acesso veio de outro caminho, o comando ainda assim executa sem erro, mas o acesso efetivo continua de pe.

CASCADE versus RESTRICT

Se um privilegio foi concedido WITH GRANT OPTION, quem o recebeu pode ter repassado adiante. Ao revogar, o PostgreSQL precisa decidir o destino dessas concessoes derivadas.

• RESTRICT (o comportamento padrao) recusa a revogacao se outras concessoes dependerem desta.
• CASCADE remove o privilegio e todas as concessoes que descendem dele.

GRANT SELECT ON orders TO manager WITH GRANT OPTION;
-- manager passed it on:
GRANT SELECT ON orders TO analyst;

-- This fails because manager re-granted the right:
REVOKE SELECT ON orders FROM manager RESTRICT;

-- This removes manager's grant AND analyst's:
REVOKE SELECT ON orders FROM manager CASCADE;

Voce tambem pode revogar apenas a capacidade de reconceder, deixando o acesso em si intacto:

REVOKE GRANT OPTION FOR SELECT ON orders FROM manager CASCADE;

Gotcha: CASCADE pode apagar o acesso de contas em que voce nem pensou. Antes de revogar com CASCADE, inspecione a cadeia de concessoes em information_schema.role_table_grants, ou voce pode quebrar o painel ou o job de ETL de alguem.

Por que o PUBLIC ainda tem acesso

A surpresa mais comum: voce revoga um privilegio de um usuario e ele continua lendo a tabela mesmo assim. A causa e o pseudo-papel PUBLIC, ao qual todo papel do cluster pertence de forma implicita. Se o privilegio foi concedido a PUBLIC, revoga-lo de um unico usuario nao muda nada.

-- Someone granted broad access earlier:
GRANT SELECT ON users TO PUBLIC;

-- This looks right but analyst still reads users:
REVOKE SELECT ON users FROM analyst;

-- You must revoke from PUBLIC itself:
REVOKE SELECT ON users FROM PUBLIC;

Atencao tambem aos privilegios do dono: o dono da tabela e os superusuarios mantem acesso total apesar do REVOKE. Voce nao consegue tirar o acesso deles com uma revogacao comum.

Papel versus usuario

Distribuir acesso por meio de papeis de grupo e pratico, mas complica a revogacao. Se o usuario analyst e membro do papel analytics_team, revogar um privilegio de analyst pessoalmente nao afeta o que ele herda atraves do papel.

GRANT SELECT ON orders TO analytics_team;
GRANT analytics_team TO analyst;

-- No effect: analyst gets SELECT via the role, not directly:
REVOKE SELECT ON orders FROM analyst;

-- Option A: revoke from the role (affects everyone in it):
REVOKE SELECT ON orders FROM analytics_team;

-- Option B: remove this user from the role:
REVOKE analytics_team FROM analyst;

O MySQL segue um modelo parecido, mas nao suporta REVOKE ... CASCADE/RESTRICT, e os papeis so chegaram na versao 8.0; antes disso, os privilegios eram atribuidos diretamente as contas. O ClickHouse suporta REVOKE e papeis, mas seus privilegios e sua sintaxe diferem bastante do SQL padrao.

Como apertar permissoes com seguranca

• Verifique primeiro o acesso efetivo: leia information_schema.role_table_grants e percorra as participacoes em papeis antes de revogar qualquer coisa.
• Nao esqueca do PUBLIC: para tabelas sensiveis, execute de forma explicita REVOKE ... FROM PUBLIC.
• Prefira RESTRICT (ou simplesmente omita CASCADE) para que o comando falhe de forma evidente quando houver concessoes dependentes e voce veja o problema com antecedencia.
• Revogue no mesmo nivel em que concedeu: revogue um papel de um papel e uma concessao direta de um usuario.
• Envolva a serie de comandos REVOKE em uma transacao e verifique com um SELECT como o usuario afetado antes de confirmar.