Configurando permissões com GRANT e REVOKE

Imagina que seus dados são tipo uma fortaleza, e cada morador da fortaleza tem seus próprios direitos: tem quem só pode andar pelo pátio, tem quem guarda as chaves do tesouro, e tem quem senta no trono e manda em tudo. No nosso banco de dados, quem faz esse papel são os comandos GRANT e REVOKE. Eles que decidem: quem pode ir aonde e pra quê.

O comando GRANT, como todo grant que se preze, serve pra liberar acesso a recursos (tipo bancos de dados, tabelas, schemas) pra certas roles. É tipo um "convite pra festa", onde você decide quem pode ler, escrever ou até quebrar os móveis.

O comando REVOKE, ao contrário, tira permissões que já tinham sido dadas. É tipo falar: "Ô, a festa acabou pra você, deixa a chave na porta quando sair".

Dando permissões com GRANT

Vamos começar pelo topo — o banco de dados. Pra um usuário conseguir se conectar ao banco, ele precisa da permissão de conexão. Pra isso, usa esse comando:

GRANT CONNECT ON DATABASE database_name TO role_name;

Por exemplo, se a gente tem o banco university e a role student, dá pra liberar o acesso dos estudantes assim:

GRANT CONNECT ON DATABASE university TO student;

Mas só conectar não quer dizer que pode fazer o que quiser. Pra criar objetos no banco, o usuário precisa também da permissão de criação:

GRANT CREATE ON DATABASE university TO student;

Você pode conferir as permissões do banco com esse comando:

\l+ university

Removendo permissões com REVOKE

Se o estudante começar a fazer coisa estranha (tipo criar mais tabelas do que devia), dá pra tirar o direito de criar coisas assim:

REVOKE CREATE ON DATABASE university FROM student;

Depois disso, o estudante só vai conseguir conectar, mas nada de "liberdade criativa".

Configurando permissões no nível de schemas

Schema é tipo um "quarto" dentro do banco, onde ficam as tabelas, views e outros objetos. Pra um usuário mexer nos objetos do schema, dá pra configurar permissões de leitura, escrita ou criação de objetos.

Dando permissões no schema

Vamos supor que temos o schema public (ele já vem por padrão em todo banco). Dá pra liberar pro usuário ver o conteúdo do schema assim:

GRANT USAGE ON SCHEMA public TO student;

Mas só o USAGE não basta pra mexer nas tabelas. Pra criar novos objetos, adiciona isso:

GRANT CREATE ON SCHEMA public TO student;

Assim, o estudante pode não só ler, mas também criar tabelas no schema public.

Removendo permissões do schema

Se o estudante começar a encher o schema com tabelas estranhas tipo bad_idea_01, dá pra limitar os direitos dele:

REVOKE CREATE ON SCHEMA public FROM student;

Agora o estudante não pode mais criar tabelas novas. Ordem restaurada!

Configurando permissões no nível de tabelas

Tabela é provavelmente o objeto mais famoso do banco. Bora ver como liberar acesso só pras tabelas. Aqui tem três categorias principais: leitura, escrita e alteração.

Permissão de leitura

Pra liberar leitura de uma tabela, usa esse comando:

GRANT SELECT ON TABLE table_name TO role_name;

Por exemplo, pra estudantes lerem a tabela courses:

GRANT SELECT ON TABLE courses TO student;

Agora o usuário student pode rodar SELECT na tabela courses.

Permissão de escrita

Se quiser que o usuário possa inserir linhas novas na tabela, faz assim:

GRANT INSERT ON TABLE table_name TO role_name;

Exemplo:

GRANT INSERT ON TABLE courses TO student;

Agora os estudantes podem adicionar cursos novos na tabela. Mas pera aí... Será que isso é uma boa ideia?

Permissão de alteração e remoção

Se o usuário precisa atualizar linhas existentes ou apagar elas, tem que liberar UPDATE e DELETE:

GRANT UPDATE ON TABLE courses TO student;
GRANT DELETE ON TABLE courses TO student;

Dica: não exagera nessas permissões. Se der permissão de apagar pra estudante, eles podem ferrar tudo sem querer (ou de propósito).

Exemplo: criando uma role com permissões limitadas

Imagina que a gente vai criar uma role pra professores, que só podem ler dados de estudantes e cursos, mas não podem apagar nada. Olha só como faz:

1. Cria a role:

CREATE ROLE teacher;

2. Dá permissão de leitura nas tabelas students e courses:

GRANT SELECT ON TABLE students, courses TO teacher;

3. Restringe o acesso pra apagar:

REVOKE DELETE ON TABLE students, courses FROM teacher;

Agora nossos professores só têm os direitos que precisam, sem exagero.

Como combinar GRANT e REVOKE pra configurar tudo certinho

Vamos supor que temos a role intern, que a gente quer limitar. Ela só pode acessar dados dos cursos, mas nunca dos estudantes. Fica assim:

1. Liberamos acesso só pra tabela courses:

GRANT SELECT, INSERT ON TABLE courses TO intern;

2. Garantimos que a role intern não tem permissão na tabela students:

REVOKE ALL ON TABLE students FROM intern;

Essa combinação deixa as permissões bem ajustadas.

Exemplos de uso em projetos reais

Esse esquema de controle de acesso é usado direto em projetos de verdade. Por exemplo:

1. Em lojas online, as permissões nas tabelas de usuários e pedidos são divididas entre as roles "administrador", "operador" e "visitante".
2. Em sistemas universitários, administradores podem adicionar e editar cursos, enquanto estudantes só podem ver.
3. Em bancos, o acesso às contas dos clientes é separado entre funcionários de diferentes setores.