¿Qué es una ACL (Lista de Control de Acceso)?

Una lista de control de acceso es una lista adjunta a un recurso que nombra qué usuarios o roles pueden acceder a él y qué puede hacer cada uno. La adjunción es la idea: donde los sistemas de roles cuelgan los permisos de las personas, una ACL los cuelga del objeto — cada registro con su propia lista de invitados, cada entrada (una entrada de control de acceso, ACE) un sujeto emparejado con sus derechos. Es una de las construcciones de seguridad más antiguas de la computación, y en los backends de aplicación es cómo “solo Ada y los editores pueden tocar este documento” se convierte en un campo en lugar de una feature.

Puntos clave

La lista de invitados de un objeto

Documento "Roadmap Q3" — ACL
┌────────────────────┬─────────┬───────────┐
│ sujeto             │ lectura │ escritura │
├────────────────────┼─────────┼───────────┤
│ user usr-8fk2 (Ada)│   sí    │    sí     │   ← propietaria
│ user usr-2mq7 (Bob)│   sí    │     —     │   ← grant individual
│ role editors       │   sí    │    sí     │   ← un rol como una entrada
│ público (todos)    │    —    │     —     │   ← por defecto: cerrado
└────────────────────┴─────────┴───────────┘

Como dato, en el propio registro:
{ "title": "Q3 roadmap",
  "ACL": { "usr-8fk2": { "read": true, "write": true },
           "usr-2mq7": { "read": true },
           "role:editors": { "read": true, "write": true } } }

Escribir esa lista de invitados en código de aplicación:

// 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

Los tres significados de “ACL”

La mayoría de las explicaciones elige uno en silencio; el término nombra, de hecho, tres mecanismos:

Comparten la forma — una lista de entradas sujeto-permiso custodiando un recurso — y difieren en todo lo demás. La casa de este artículo es el tercer significado: las listas de permisos por registro de los backends de aplicación, el menos cubierto y, para quien desarrolla producto, el más usado.

Cómo se evalúa una solicitud: el modelo de dos gates

Las capas son la manera en que los sistemas maduros concilian el control grueso y el fino: los permisos a nivel de clase declaran la política de la categoría entera (“solo usuarios autenticados; solo los moderadores eliminan”), y la ACL por objeto decide el registro individual. Una solicitud debe pasar ambos gates — lo que significa que una ACL olvidada no puede abrir lo que la regla de la clase cerró, y una regla de clase generosa tampoco puede exponer un objeto bloqueado. La misma lógica de capas aparece un nivel más abajo como seguridad a nivel de fila, cuando la propia base de datos aplica el predicado por fila.

ACL vs. RBAC vs. ABAC

La respuesta honesta es composición, no competencia: los roles manejan el acceso que sigue la función de trabajo; las ACLs manejan las decisiones por objeto que los roles no pueden expresar (“este borrador, estos dos revisores”); las reglas de atributos entran cuando el contexto importa (hora, tenant, estado). La bisagra práctica entre los dos primeros es la ACE de rol — una línea de la ACL cuyo sujeto es un rol — que conserva el control a nivel de objeto mientras delega la rotación de miembros al sistema de roles.

El problema de escala — y la escalera de mitigación

Las ACLs por objeto ingenuas crecen como N objetos × M sujetos: un millón de documentos, cada uno listando usuarios individuales, significa que cada contratación, salida y reorganización edita listas dispersas por todo el dataset — el “difícil de gestionar” que menciona todo libro de texto, hecho concreto. La escalera de mitigación, en el orden en que se sube: entradas de rol (una ACE cubre una población que cambia; la membresía se actualiza en un solo lugar); ACLs por defecto (cada objeto nuevo nace con lectura/escritura del propietario y las entradas de rol correctas — el análogo en la aplicación de las ACLs default de POSIX en directorios); reglas a nivel de clase para el caso común, reservando las listas por objeto para las excepciones; y, a escala pesada de relaciones, autorización basada en grafos (ReBAC), que deriva el acceso de las relaciones en lugar de almacenar listas. Los sistemas que se saltan la escalera no abandonan las ACLs — se ahogan en ellas.

Enforcement: del lado del servidor o nada

Una ACL aplicada en el cliente es una sugerencia. Ocultar botones, filtrar listas en JavaScript o confiar en que la app solo envíe IDs permitidos fallan de la misma manera: el atacante edita la solicitud, no la interfaz — incrementa /documents/41 a /documents/42 y lee el registro de otra persona. Esa clase de falla — broken object-level authorization, el primer puesto de la lista de seguridad de APIs de OWASP — es exactamente lo que las ACLs por objeto existen para cerrar, y la guía de OWASP es directa: las verificaciones de autorización corren del lado del servidor, por solicitud, por objeto; tener acceso a un tipo de objeto nunca implica acceso a todo objeto de ese tipo. La evaluación pertenece a la capa de datos, donde ningún camino del cliente puede rodearla.

Casos de uso comunes

• Contenido generado por usuarios — cada post, archivo o nota pertenece a quien lo creó, compartido registro a registro.
• Colaboración en documentos — listas de lectores/editores por documento; el diálogo de compartir es un editor de ACL vestido de UX.
• Registros multiusuario con excepciones — el caso de RR. HH.: el titular del registro lo lee, su gerente lo escribe, el rol de auditores lo lee todo.
• Alcance por tenant y por equipo — entradas de rol por equipo en clases compartidas, con grants por objeto para las excepciones entre equipos.
• Apps privadas por defecto — mensajería, salud, finanzas: cada objeto cerrado al crearse, abierto solo por entradas explícitas.

¿Deberías usar ACLs o roles? Matriz de decisión

Limitaciones y trade-offs

• La proliferación es la trayectoria por defecto. Sin entradas de rol y valores por defecto, las listas por objeto se vuelven confeti inauditable; la escalera de mitigación no es opcional a escala.
• “¿A qué puede acceder este usuario?” es la consulta cara. Las ACLs optimizan la auditoría por objeto; el inventario por sujeto exige recorridos o índices secundarios.
• Los defaults equivocados son brechas silenciosas. Un objeto creado con lectura pública sigue público hasta que alguien lo nota; las ACLs por defecto merecen la misma revisión que el código.
• El rendimiento carga con la verificación. Cada lectura filtra por ACL; la evaluación debe estar indexada y aplicarse en la capa de datos, no parcharse endpoint por endpoint.
• Las ACLs autorizan; no autentican. La lista vale lo que vale la identidad que se le presenta — las sesiones y los tokens son la dependencia aguas arriba.

ACLs en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Aquí la ACL es un campo de primera clase: cada objeto lleva una, las pestañas de código de arriba son la API completa — valores por defecto del propietario, grants por usuario, entradas de rol, flags públicas — y el enforcement ocurre en Back4app en cada solicitud REST, GraphQL y Live Query, así que las suscripciones en tiempo real respetan las mismas listas de invitados que las consultas. El modelo de dos gates llega intacto: los permisos a nivel de clase fijan la política de la categoría en el dashboard, las ACLs por objeto la refinan registro a registro, y una configuración de ACL por defecto hace que los objetos nuevos nazcan privados de su propietario. La escalera de escala viene montada — los roles son objetos que gestionas como cualquier otro dato — dejando las decisiones de diseño, y no la maquinaria de enforcement, como tu parte del trabajo.