O que é uma ACL (Lista de Controle de Acesso)?

Uma lista de controle de acesso é uma lista anexada a um recurso que nomeia quais usuários ou papéis podem acessá-lo e o que cada um pode fazer. O vínculo é a ideia toda: onde sistemas de papéis penduram permissões em pessoas, a ACL as pendura no objeto — cada registro com sua própria lista de convidados, cada entrada (uma entrada de controle de acesso, ACE) um sujeito pareado com seus direitos. É uma das construções de segurança mais antigas da computação, e em backends de aplicação é como “só a Ada e os editores podem tocar neste documento” vira um campo em vez de uma feature.

Principais pontos

A lista de convidados de um objeto

Documento "Roadmap Q3" — ACL
┌────────────────────┬─────────┬─────────┐
│ sujeito            │ leitura │ escrita │
├────────────────────┼─────────┼─────────┤
│ user usr-8fk2 (Ada)│   sim   │   sim   │   ← dona
│ user usr-2mq7 (Bob)│   sim   │    —    │   ← grant individual
│ role editors       │   sim   │   sim   │   ← um papel como uma entrada
│ público (todos)    │    —    │    —    │   ← padrão: fechado
└────────────────────┴─────────┴─────────┘

Como dado, no próprio registro:
{ "title": "Q3 roadmap",
  "ACL": { "usr-8fk2": { "read": true, "write": true },
           "usr-2mq7": { "read": true },
           "role:editors": { "read": true, "write": true } } }

Escrevendo essa lista de convidados em código de aplicação:

// JavaScript / Node.js — Back4app JS SDK
// A per-object ACL: this document's own guest list
const doc = new Parse.Object('Document');
doc.set('title', 'Q3 roadmap');

const acl = new Parse.ACL(currentUser);   // owner: read + write
acl.setReadAccess(reviewerId, true);      // one user: read only
acl.setRoleWriteAccess('editors', true);  // a role as an entry
acl.setPublicReadAccess(false);           // everyone else: nothing
doc.setACL(acl);

await doc.save(); // enforced server-side on every future request

// Flutter / Dart — Back4app Flutter SDK
// A per-object ACL: this document's own guest list
final doc = ParseObject('Document')..set('title', 'Q3 roadmap');

final acl = ParseACL(owner: currentUser);              // owner: read + write
acl.setReadAccess(userId: reviewerId, allowed: true);  // one user: read only
acl.setRoleWriteAccess('editors', true);               // a role as an entry
acl.setPublicReadAccess(allowed: false);               // everyone else: nothing
doc.setACL(acl);

await doc.save(); // enforced server-side on every future request

// iOS / Swift — Back4app Swift SDK
// A per-object ACL: this document's own guest list
var doc = Document()
doc.title = "Q3 roadmap"

var acl = ParseACL()
acl.setReadAccess(user: currentUser, value: true)    // owner: read…
acl.setWriteAccess(user: currentUser, value: true)   // …and write
acl.setReadAccess(objectId: reviewerId, value: true) // one user: read only
acl.setWriteAccess(roleName: "editors", value: true) // a role as an entry
acl.publicRead = false                               // everyone else: nothing
doc.ACL = acl

try await doc.save() // enforced server-side on every future request

// Android / Kotlin — Back4app Android SDK
// A per-object ACL: this document's own guest list
val doc = ParseObject("Document")
doc.put("title", "Q3 roadmap")

val acl = ParseACL(ParseUser.getCurrentUser()) // owner: read + write
acl.setReadAccess(reviewerId, true)            // one user: read only
acl.setRoleWriteAccess("editors", true)        // a role as an entry
acl.publicReadAccess = false                   // everyone else: nothing
doc.acl = acl

doc.save() // enforced server-side on every future request

Os três significados de “ACL”

A maioria das explicações escolhe um deles em silêncio; o termo nomeia, de fato, três mecanismos:

Elas compartilham a forma — uma lista de entradas sujeito-permissão guardando um recurso — e diferem em todo o resto. A casa deste artigo é o terceiro significado: as listas de permissão por registro dos backends de aplicação, o menos coberto e, para quem desenvolve produto, o mais usado.

Como uma requisição é avaliada: o modelo de dois gates

As camadas são como sistemas maduros conciliam controle grosso e fino: as permissões em nível de classe declaram a política da categoria inteira (“só usuários autenticados; só moderadores excluem”), e a ACL por objeto decide o registro individual. A requisição precisa passar pelos dois gates — o que significa que uma ACL esquecida não abre o que a regra da classe fechou, e uma regra de classe generosa ainda não expõe um objeto trancado. A mesma lógica de camadas aparece um nível abaixo como segurança em nível de linha, quando o próprio banco aplica o predicado por linha.

ACL vs. RBAC vs. ABAC

A resposta honesta é composição, não competição: papéis cuidam do acesso que segue a função de trabalho; ACLs cuidam das decisões por objeto que papéis não conseguem expressar (“este rascunho, estes dois revisores”); regras de atributo entram quando o contexto importa (hora, tenant, estado). A dobradiça prática entre os dois primeiros é a ACE de papel — uma linha da ACL cujo sujeito é um role — que mantém o controle em nível de objeto enquanto delega a rotatividade de membros ao sistema de papéis.

O problema de escala — e a escada de mitigação

ACLs por objeto ingênuas crescem como N objetos × M sujeitos: um milhão de documentos listando usuários individuais significa que cada contratação, desligamento e reorganização edita listas espalhadas pelo dataset — o “difícil de gerenciar” que todo livro-texto menciona, tornado concreto. A escada de mitigação, na ordem de subida: entradas de papel (uma ACE cobre uma população que muda; a associação atualiza em um lugar só); ACLs padrão (cada objeto novo já nasce com leitura/escrita do dono e as entradas de papel certas — o análogo, na aplicação, das ACLs default do POSIX em diretórios); regras em nível de classe para o caso comum, reservando listas por objeto para as exceções; e, em escala pesada de relacionamentos, autorização baseada em grafo (ReBAC), que deriva o acesso de relacionamentos em vez de armazenar listas. Sistemas que pulam a escada não abandonam as ACLs — afogam-se nelas.

Enforcement: no servidor ou nada

Uma ACL aplicada no cliente é uma sugestão. Esconder botões, filtrar listas em JavaScript ou confiar que o app só envie IDs permitidos falham do mesmo jeito: o atacante edita a requisição, não a interface — incrementa /documents/41 para /documents/42 e lê o registro de outra pessoa. Essa classe de falha — broken object-level authorization, a primeira da lista de segurança de APIs da OWASP — é exatamente o que as ACLs por objeto existem para fechar, e a orientação da OWASP é direta: verificações de autorização rodam no servidor, por requisição, por objeto; ter acesso a um tipo de objeto nunca implica acesso a todo objeto daquele tipo. A avaliação pertence à camada de dados, onde nenhum caminho do cliente consegue contorná-la.

Casos de uso comuns

• Conteúdo gerado por usuários — cada post, arquivo ou nota pertence a quem criou, compartilhado registro a registro.
• Colaboração em documentos — listas de leitores/editores por documento; a caixa de compartilhar é um editor de ACL vestindo UX.
• Registros multiusuário com exceções — o caso de RH: o titular do registro lê, o gestor escreve, o papel de auditores lê tudo.
• Escopo por tenant e por time — entradas de papel por time em classes compartilhadas, com grants por objeto para exceções entre times.
• Apps privados por padrão — mensagens, saúde, finanças: todo objeto fechado na criação, aberto apenas por entradas explícitas.

Você deveria usar ACLs ou papéis? Matriz de decisão

Limitações e trade-offs

• A proliferação é a trajetória padrão. Sem entradas de papel e defaults, listas por objeto viram confete inauditável; a escada de mitigação não é opcional em escala.
• “O que este usuário pode acessar?” é a consulta cara. ACLs otimizam a auditoria por objeto; o inventário por sujeito exige varreduras ou índices secundários.
• Defaults errados são vazamentos silenciosos. Um objeto criado com leitura pública fica público até alguém notar; ACLs padrão merecem a mesma revisão que código.
• A performance carrega a verificação. Toda leitura filtra por ACL; a avaliação precisa ser indexada e aplicada na camada de dados, não remendada endpoint a endpoint.
• ACLs autorizam; não autenticam. A lista vale o que vale a identidade apresentada a ela — sessions e tokens são a dependência a montante.

ACLs no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Aqui a ACL é um campo de primeira classe: todo objeto carrega uma, as abas de código acima são a API completa — padrões de dono, grants por usuário, entradas de papel, flags públicas — e o enforcement acontece no Back4app em toda requisição REST, GraphQL e Live Query, então assinaturas em tempo real respeitam as mesmas listas de convidados que as consultas. O modelo de dois gates chega intacto: as permissões em nível de classe definem a política da categoria no dashboard, as ACLs por objeto a refinam registro a registro, e uma configuração de ACL padrão faz objetos novos nascerem privados do dono. A escada de escala já vem montada — roles são objetos que você gerencia como qualquer outro dado — deixando as decisões de design, e não a maquinaria de enforcement, como a sua parte do trabalho.