Controle de acesso em projetos: por que Row Level Security importa

O problema das ferramentas "abertas por padrão"

A maioria das plataformas de gestão de projetos como Trello, Asana e Notion adota um modelo de acesso aberto: quando você entra em um workspace, consegue ver todos os projetos, todas as tarefas e todos os comentários. Para equipes pequenas, isso pode funcionar. Para organizações com dados sensíveis, é um risco.

Imagine um escritório de advocacia usando Trello. Um estagiário do setor administrativo consegue ver os boards de due diligence de uma fusão bilionária. Ou uma gestora de investimentos onde analistas juniores acessam informações de alocação de portfólio que deveriam ser restritas ao comitê de investimentos.

O problema não é a ferramenta em si — é a arquitetura de acesso.

O que é Row Level Security (RLS)?

Row Level Security é uma funcionalidade nativa do PostgreSQL que aplica regras de acesso diretamente no banco de dados. Diferente de validações feitas no código da aplicação (que podem ser contornadas por bugs ou falhas), RLS garante que uma query nunca retorna dados que o usuário não deveria ver.

Na prática, funciona assim:

• O banco de dados sabe qual usuário está fazendo a consulta
• Antes de retornar qualquer linha, verifica se aquele usuário tem permissão
• Se não tem, a linha simplesmente não existe para ele

Isso significa que mesmo que um bug na aplicação esqueça de filtrar dados, o banco de dados impede o vazamento.

Como o Sketi implementa RLS

No Sketi, cada projeto é hermeticamente fechado. As políticas de RLS garantem que:

1. Tarefas só são visíveis para membros explicitamente adicionados ao projeto
2. Comentários herdam a permissão do projeto pai
3. Anexos e campos customizados seguem a mesma política
4. Audit logs registram quem acessou o quê e quando

Não existe um modo "ver tudo" nem para administradores da organização por padrão. O acesso é sempre explícito.

Controle granular de permissões

Além do RLS, o Sketi permite definir roles customizadas por projeto com permissões granulares:

• Visualizar — pode ver tarefas e comentários
• Criar tarefas — pode adicionar novas tarefas
• Editar tarefas — pode modificar tarefas existentes
• Mover tarefas — pode arrastar entre colunas
• Gerenciar membros — pode adicionar/remover pessoas
• Gerenciar colunas — pode criar e reorganizar o board
• Excluir projeto — ação destrutiva, restrita a owners

Cada membro do projeto pode ter uma role diferente, permitindo que um cliente externo veja o progresso sem conseguir editar nada.

Quando isso importa na prática

• Financeiro e investimentos: dados de alocação e compliance separados por fundo
• Jurídico: cada caso isolado, com acesso apenas para a equipe designada
• Consultorias: projetos de clientes diferentes nunca se cruzam
• Saúde: dados de pacientes com acesso restrito por regulação

Conclusão

Se sua equipe lida com dados sensíveis, o modelo "aberto por padrão" das ferramentas tradicionais é um risco desnecessário. RLS no nível do banco de dados não é um extra — é o mínimo esperado para organizações que levam segurança a sério.

O Sketi foi construído com essa premissa desde o primeiro dia. Cada linha de dados é protegida por políticas que não dependem do código da aplicação funcionar corretamente.