Como parei de fazer deploy pra mudar permissão de usuário

Fala galera. Essa semana eu tava batendo cabeça com a modelagem do banco de um SaaS novo que tô estruturando em Go e Postgres.

Até então, meu controle de acesso sempre foi aquele feijão com arroz: a gente joga uma coluna role na tabela de usuários, bota um "admin" ou "user" lá e resolve tudo no código com um if user.role == "admin". Funciona que é uma beleza pra MVP.

Mas o escopo do projeto começou a crescer. Apareceu a necessidade de ter uma galera que só edita, mas não apaga. Depois, uma galera que pode ler os resultados, mas não pode mexer nas configurações.

Ficou claro que se eu continuasse criando roles no código, logo ia ter que lidar com bizarrices tipo editor_que_nao_deleta. Fui dar uma pesquisada em como a galera escala isso e caí nessa sopa de letrinhas. Pra quem também se confunde com isso, aqui vai meu resumo:

1. RBAC simples (Role-Based Access Control)

É o que a gente já faz por instinto. O acesso é liberado pelo cargo.

• Exemplo: Você é Admin? Entra. Você é Viewer? Só lê.
• O problema: Fica engessado muito rápido. Qualquer exceção vira uma gambiarra no código ou uma role nova com nome esquisito.

2. RBAC com permissões granulares

Foi aqui que a ficha caiu pra mim. Não é um paradigma completamente diferente — é o jeito certo de implementar RBAC.

Em vez de checar o cargo diretamente, você passa a checar a ação que o usuário quer executar.

• Exemplo: Ao invés de perguntar "Ele é editor?", o sistema pergunta "Ele tem a permissão item:delete?".
• A mágica é que no banco de dados, você atrela essas permissões granulares aos cargos. A role vira só um "pacote de permissões". Quer dar acesso novo a um cargo? Insere uma linha no banco, sem alterar código.

⚠️ Você pode ver isso sendo chamado de "PBAC" (Permission-Based) em alguns posts. Cuidado: esse termo não é padronizado e pode confundir, pois PBAC na literatura de segurança normalmente se refere a Policy-Based Access Control — algo diferente, mais próximo do ABAC.

3. ReBAC (Relationship-Based Access Control)

Esse aqui aparece bastante em SaaS multi-tenant e eu acho que é o mais subestimado.

O acesso depende da relação entre o usuário e o recurso.

• Exemplo: "O usuário pode editar esse documento SE ele for o dono OU se pertencer ao mesmo workspace.".
• É o modelo usado pelo Google (Zanzibar), e por libs open source como SpiceDB e Ory Keto.
• Resolve de forma elegante o caso clássico de "cada usuário só pode editar os próprios itens", que fica torto tanto no RBAC quanto no ABAC.

4. ABAC (Attribute-Based Access Control)

Esse é o nível hard. Não é só ter a permissão — depende do contexto completo (atributos do usuário, do recurso e do ambiente).

• Exemplo: "O usuário pode aprovar a solicitação SE for gerente E o valor for menor que R$10k E o acesso estiver ocorrendo em horário comercial.".
• É o modelo por trás do AWS IAM, do OPA (Open Policy Agent) e do Google IAM.
• Overkill pra maioria dos projetos, mas essencial pra sistemas com regras de compliance complexas.

Como ficou na prática

Acabei optando pelo RBAC com permissões granulares. Criei três tabelas básicas usando UUIDs: roles (os nomes dos cargos), permissions (as ações tipo survey:edit, billing:view) e uma tabela de junção role_permissions.

A mudança no backend (em Go, no meu caso) foi sutil, mas mudou tudo.

Saí disso:

// O jeito antigo e engessado
if user.Role != "admin" {
    http.Error(w, "Forbidden", http.StatusForbidden)
    return
}

Para isso:

// Desacoplado e escalável
if !user.HasPermission("survey:edit") {
    http.Error(w, "Forbidden", http.StatusForbidden)
    return
}

A moral da história é que desacoplar a role da permissão salva muito tempo de manutenção. Se amanhã o time de negócios pedir que um "Estagiário" também possa editar, eu não preciso alterar nenhuma linha de código nem fazer deploy — só insiro uma linha no banco ligando aquele cargo àquela permissão.

Resumo rápido

Como vocês costumam lidar com controle de acesso nos projetos de vocês? Fazem na mão ou usam alguma lib pronta pra isso?