Una integración entre una tienda online, un CRM, un ERP o una herramienta de soporte suele recibir una autorización descrita de forma demasiado amplia: “acceso a pedidos” o “acceso al CRM”. Esa simplificación dificulta saber qué necesita realmente el conector y puede mantener disponibles funciones o datos que no forman parte de su trabajo.
La matriz de permisos para APIs convierte ese acceso genérico en decisiones concretas y revisables. Su utilidad no se limita al equipo técnico: operaciones puede validar el proceso, negocio puede aprobar las acciones sensibles y los proveedores pueden conocer los límites de su intervención. El objetivo es que cada actor, humano o automático, acceda únicamente a las operaciones, registros y campos necesarios.
El problema de autorizar una herramienta completa
Estar autenticado identifica a una persona, proceso o cuenta técnica, pero no determina por sí mismo qué puede hacer. La autorización debe responder, como mínimo, si ese actor puede ejecutar una acción concreta y sobre qué recurso. Por ejemplo, un conector que crea contactos desde un formulario no necesita necesariamente exportar todos los contactos, cambiar propietarios, borrar registros ni consultar información interna. [2]
También es necesario distinguir el permiso sobre una función del permiso sobre un objeto concreto. Que un portal permita consultar pedidos no implica que cualquier cliente pueda consultar cualquier pedido: el sistema debe comprobar que el registro solicitado pertenece a su empresa o a su cuenta. OWASP identifica la falta de esta comprobación a nivel de objeto como un riesgo que puede conducir a exposición, modificación o eliminación no autorizada de datos. [1]
Qué debe incluir una matriz de permisos por operación
Una matriz es un inventario estructurado de decisiones de acceso. Cada fila representa una necesidad operativa, no un rol genérico como “administrador” o “acceso completo”. Puede empezar con una integración crítica, como web–CRM, e-commerce–ERP o portal de clientes–soporte, y ampliarse después al resto del ecosistema. El valor está en hacer visibles las excepciones antes de convertirlas en credenciales o reglas técnicas.
Como plantilla mínima, incluya el sistema o integración; el actor; el recurso; la operación; el alcance; los campos permitidos y excluidos; el método de autenticación y la credencial asociada; las condiciones adicionales; la persona responsable; la fecha de revisión, y el evento que debe registrarse. Entre las operaciones conviene diferenciar leer, crear, actualizar, cancelar, aprobar, exportar y borrar, porque su impacto no es equivalente.
- Actor: empleado, cliente, proveedor, proceso automático o cuenta de servicio.
- Alcance: datos propios, una empresa determinada, una unidad de negocio o datos internos.
- Condición: por ejemplo, solo pedidos asignados, solo documentos en un estado concreto o aprobación previa para exportar.
Ejemplo hipotético de una integración web–CRM
Ejemplo hipotético: una empresa conecta el formulario de solicitud comercial de su web con el CRM. La cuenta técnica del formulario puede crear un contacto y un posible cliente, pero solo con nombre, correo, empresa, teléfono y mensaje. No puede leer contactos existentes, descargar listados, modificar el propietario comercial, consultar notas internas ni borrar registros. El responsable de negocio valida que esos campos son suficientes para atender la solicitud.
La misma matriz debe describir el alcance de los datos. Si el CRM organiza clientes por filiales, el proceso automático debería crear registros únicamente en la unidad asignada, no en todas. Si necesita detectar duplicados, puede requerir una comprobación limitada y registrada, en lugar de acceso de lectura global. Esta precisión evita que una necesidad legítima se traduzca en una credencial con capacidades innecesarias.
Cinco reglas para convertir la matriz en controles reales
Primero, aplique denegación por defecto: toda operación no autorizada expresamente debe rechazarse. Segundo, compruebe en el servidor y en cada solicitud tanto la acción como el objeto solicitado; no basta con ocultar un botón en la interfaz ni con validar el permiso solo cuando se emite un token. Tercero, separe las cuentas de personas de las cuentas técnicas para poder limitar, revisar y retirar sus capacidades de manera independiente. [2]
Cuarto, limite cada cuenta de integración a los recursos, operaciones y campos que requiere el proceso. Quinto, establezca revisiones periódicas y revisiones desencadenadas por cambios relevantes, como una baja de proveedor, un cambio de funciones, un nuevo endpoint o una automatización sustituida. Mantener el ciclo de vida de las cuentas incluye registrar altas, cambios, habilitaciones y bajas, así como desactivar cuentas que ya no correspondan a una persona o necesidad vigente. [4]
- Evite claves compartidas entre proveedores o automatizaciones distintas.
- Asigne un responsable de negocio para permisos sensibles, aunque tecnología implemente el control.
- Registre cambios de permisos y acciones relevantes de cuentas técnicas para facilitar su revisión.
Cómo validar y mantener la matriz
Antes de publicar cambios, convierta la matriz en casos de prueba. Con autorización expresa, alcance definido y preferiblemente cuentas o datos de prueba, confirme que cada acción permitida funciona y que cada acción no concedida se rechaza. Compruebe tanto operaciones de consulta como de modificación, y pruebe roles o cuentas con el menor privilegio. La revisión debe ser defensiva, planificada y limitada al entorno y sistemas autorizados. [3]
Una revisión útil no busca demostrar que el sistema “es seguro” en términos absolutos. Busca detectar diferencias entre el proceso aprobado, la matriz documentada y el comportamiento real de la API, el panel administrativo y la web. Si una regla es distinta entre canales, si una cuenta técnica tiene permisos de administrador por precaución o si un conector puede exportar datos que no utiliza, conviene corregir el diseño y volver a validar el cambio. [1] [3]
Preguntas frecuentes
¿Qué diferencia hay entre autenticación y autorización en una API?
La autenticación verifica la identidad de quien realiza una solicitud, como un usuario o una cuenta de integración. La autorización decide qué operación puede ejecutar esa identidad, sobre qué recurso, en qué alcance y bajo qué condiciones. Ambas son necesarias.
¿Cada integración necesita una cuenta propia?
En general, separar las cuentas técnicas por integración facilita limitar permisos, registrar actividades y retirar accesos cuando un proceso cambia o deja de utilizarse. Una cuenta compartida puede dificultar atribuir acciones y aplicar límites específicos.
¿Con qué integración conviene empezar la matriz?
Empiece por una integración crítica o que trate datos relevantes, como la conexión entre web y CRM, tienda y ERP, o portal de clientes y soporte. Documente las operaciones reales, valide los límites con negocio y tecnología, y use el resultado como modelo para las demás integraciones.