Un ascenso temporal, un reembolso autoaprobado y un registro que nadie lee: diseña roles claros, alcance, aprobación independiente y evidencia útil.
Autor
Anichur Rahaman
El lunes, la dueña de una tienda encuentra un reembolso de USD 184 solicitado y aprobado por la misma cuenta. El cajero recibió permisos de encargado para cubrir un fin de semana; nadie fijó su vencimiento. Es una escena ilustrativa, no un incidente de un cliente. El reembolso podría ser legítimo. Aun así, falló el control: nadie independiente lo revisó.
Un equipo que crece no puede esperar al dueño para cada venta normal. El acceso debe seguir al trabajo. Elige un proceso sensible, explica sus reglas y comprueba que sobreviven a una llamada directa a la API, una tarea en segundo plano y un cambio de turno.
Un permiso nombra una acción: consultar un pedido, solicitar un reembolso o exportar clientes. Un rol reúne permisos de un trabajo. Una asignación concede ese rol a una persona identificada dentro de un alcance y un periodo. “Encargada de la tienda 2 hasta el viernes” es más preciso que “gerente”. Al trasladarla a la tienda 3, modifica o termina expresamente la asignación anterior.
El control de acceso basado en roles, RBAC, organiza esos grupos. También necesita condiciones sobre empresa, tienda, registro, campo, importe y estado del negocio. Separa consultar, crear, editar, aprobar, exportar y administrar. Ver ventas no permite descargar todas las direcciones. NIST AC-6 explica el mínimo privilegio; no establece una plantilla universal de roles comerciales.
La autenticación establece una identidad de acceso, no la autorización de cada solicitud ni la honestidad del usuario. Usa identidades individuales, autenticación sólida adecuada y cuentas de servicio restringidas. La etiqueta “Propietario” no debe eludir silenciosamente los controles que quieras imponer.
La guía de autorización de OWASP recomienda denegar por defecto y validar cada solicitud. Ocultar un botón ayuda a la interfaz; el servidor debe proteger listas, detalles, búsquedas, exportaciones, descargas, API y tareas. Un identificador difícil de adivinar no concede permiso.
Para un reembolso de la tienda 2, comprueba permiso vigente en esa empresa y tienda, pertenencia del pedido y estado de pago/reembolso. Un ID de tienda enviado por el navegador no demuestra autoridad. Las cachés compartidas, informes y enlaces a archivos tampoco deben revelar datos de otro alcance.
Un módulo opcional desactivado no debe ofrecer operaciones ni datos por sus rutas o integraciones. Activarlo no autoriza a todos los gerentes. Un calendario o panel compartido debe respetar los permisos de consulta y acción de cada fuente. Ver el calendario no permite leer nóminas ni reprogramar productos. Son requisitos que debes comprobar en tu instalación, no capacidades certificadas de un producto.
NIST distingue la separación de funciones estática y dinámica. La primera impide asignaciones incompatibles a una persona. La segunda puede permitir que un gerente solicite y apruebe reembolsos en general, pero nunca apruebe el suyo. Elige el modelo: resulta contradictorio prohibir universalmente ambos permisos y después concedérselos juntos al propietario.
En esta política didáctica, un reembolso permitido de hasta USD 50 inclusive no necesita otro aprobador. Más de USD 50 y hasta USD 300 requiere uno independiente. Más de USD 300 requiere dos personas distintas, ambas diferentes del solicitante. Moneda y límites son decisiones de ejemplo, no umbrales legales. Otro usuario controlado por la misma persona no es independencia.
La tabla distribuye responsabilidades, no configura permisos de un programa. En un equipo pequeño podría ayudar un contador externo autorizado. Si falta el aprobador, retén la operación o deriva a un sustituto aprobado. Una excepción de emergencia necesita autoridad limitada, vencimiento, alerta y revisión independiente posterior; no un atajo permanente.
| Proceso | Solicitud/preparación | Decisión independiente | Alcance y condición |
|---|---|---|---|
| Reembolso ≤USD 50 | Cajero asignado | Ninguna adicional en el ejemplo | Su tienda; controles de pago vigentes |
| Reembolso >USD 50 hasta USD 300 | Solicitante asignado | Una persona autorizada | Mismo alcance; nunca el propio solicitante |
| Reembolso >USD 300 | Solicitante asignado | Dos personas autorizadas distintas | Ninguna solicita; operación exacta |
| Pago a proveedor | Mantenimiento del proveedor / preparación | Liberación independiente autorizada | No crear proveedor y pagarlo a solas |
| Diferencia de stock | Responsable de registro | Aprobación independiente del ajuste | Inspección y evidencia por ubicación |
| Exportar clientes | Solicitante expresamente permitido | Aprobación exigida por política | Campos necesarios, alcance y entrega segura |
| Cambiar roles | Administrador restringido | Responsable autorizado del rol | Sin autoescalada silenciosa; registro |
Otra persona autorizada en la tienda 2 recibe la solicitud de USD 184. Examina pedido, pago capturado, devoluciones anteriores, motivo, moneda y destino. Cambiar a USD 196 o a otro destino exige nueva aprobación. Fraccionar solicitudes no debe evitar límites acumulados ni exceder el saldo reembolsable.
La guía de autorización de transacciones de OWASP respalda vincular la aprobación a datos significativos y comprobar el estado autorizado antes de ejecutar. Revalida permisos y vencimiento al confirmar la operación: una pestaña antigua no conserva autoridad. Controla la concurrencia para que dos clics o aprobaciones no gasten dos veces el mismo saldo.
Solicitado, aprobado, enviado al proveedor y reembolso confirmado son estados diferentes. Un timeout deja un resultado desconocido, no un fallo demostrado. Conserva la referencia, consulta al proveedor y sigue su contrato documentado de idempotencia/recuperación con reintentos limitados y espera progresiva. Escala lo pendiente; no envíes otro reembolso a ciegas. Reembolsar tampoco devuelve automáticamente una chaqueta dañada al stock vendible.
Guarda referencias estables del evento y operación, hora con zona, actor y servicio delegado, acción, objeto y alcance, motivo seguro, importe/moneda necesarios, versión de política, solicitante, aprobadores y resultado real. Vincula solicitud, aprobación, ejecución y conciliación como eventos separados. Corrige con otro evento en lugar de reescribir la historia.
Una entrada de las 09:41 no puede afirmar “completado” si la aprobación ocurrió a las 09:42 y aún no confirmó el proveedor. Distingue intento, denegación, pendiente, fallo, desconocido y confirmado. El mensaje “éxito” de la aplicación no prueba independientemente liquidación bancaria ni recepción física de inventario.
La guía de registros de OWASP trata eventos de seguridad y protección de datos. Registra denegaciones relevantes, cambios de rol, exportaciones y excepciones sin copiar contraseñas, tokens, tarjetas completas ni datos personales innecesarios. Sanea texto no fiable, limita lectores y protege archivos exportados. Prevé fallos del colector y falta de espacio; define si una operación de alto riesgo debe bloquearse sin evidencia o utilizar una alternativa duradera aprobada.
Los permisos de solo añadir reducen ediciones corrientes, pero no impiden por sí solos que un superusuario de base de datos o administrador comprometido altere el almacenamiento. Una cadena de hashes detecta inconsistencias al contrastarla con evidencia fiable. Quien puede reescribir cadena y referencia puede recalcularlas o quitar el final.
Usa una frontera de recogida/retención bajo control separado y puntos de control o firmas protegidos cuando corresponda. Define quién añade, lee y cambia la retención. El colector puede añadir sin permiso para reescribir eventos conservados. Prueba borrados, huecos, problemas de reloj y fallos de verificación, no solo muestras intactas.
Decide conservación, revisiones y acceso según riesgo, privacidad y contratos. La biblioteca actual de PCI SSC ofrece PCI DSS v 4.0.1 para entornos de pago aplicables. No significa que todos los registros comerciales deban guardarse para siempre ni revisarse igual. Confirma norma y alcance de evaluación. Este proceso no es un certificado de cumplimiento.
En un alta, aprueba rol y alcance por función, verifica identidad, configura la autenticación exigida y prueba acciones permitidas y denegadas. No copies todas las excepciones de un veterano. Una suplencia necesita hora de fin y prueba de que el vencimiento afecta a la siguiente solicitud protegida, incluidas decisiones en caché.
En un traslado, coordina retirar acceso sustituido y activar el nuevo. Si el relevo exige solapamiento, aprueba duración corta y revisión de conflictos. En una baja o identidad comprometida, revoca en el momento efectivo exigido por política, contiene el riesgo pronto, termina sesiones, revoca tokens y delegaciones y reasigna pendientes. Esperar a la revisión trimestral no es una baja efectiva.
Cada credencial de servicio necesita responsable identificado y acceso mínimo para su propósito. Cambiar una contraseña humana puede dejar API e integraciones activas. Rota los secretos compartidos utilizables por esa persona cuando corresponda y prueba dependencias; no cambies indiscriminadamente claves de cifrado ajenas ni destruyas registros. Conserva identidad de auditoría necesaria y respeta el ciclo legal de datos personales.
Empieza por reembolsos: lista asignaciones y excepciones, nombra responsable, prueba consultar otra tienda y autoaprobar por API, y verifica evidencia protegida de la denegación. Prueba además rol vencido, módulo desactivado, credencial API revocada y timeout del proveedor. Una pantalla agradable no demuestra controles.
Revisa pronto las alertas graves y fija una revisión periódica viable. Trimestral puede convenir a un equipo, sin sustituir exigencias más estrictas ni revocaciones por cambios. Confirma rol, alcance, vencimientos y responsables de servicios con el gerente. Investiga cuentas inactivas antes de deshabilitarlas según política: una identidad de servicio puede no tener accesos interactivos.
Si revisas 60 asignaciones y retiras 9 concesiones innecesarias,9÷60=15% de las asignaciones revisadas. No es 15% de empleados, tasa de fraude ni prueba de que el resto sea seguro. Mide conflictos pendientes, vencimientos efectivos, tiempo de revocación y huecos de recogida. Investiga reembolsos inusuales considerando carga de trabajo y devoluciones legítimas antes de acusar.
En el mostrador, el objetivo es sencillo: el cajero ayuda al cliente, otra persona autorizada evalúa los USD 184 y el propietario sigue el resultado real. Roles claros facilitan delegar; comprobaciones precisas y evidencia honesta permiten responder por esa delegación.
Revisado el 5 de noviembre de 2026. Anichur Rahaman es el creador de StoreConsole. Escenas, límites y cifras son ejemplos; comprueba controles y obligaciones de tu instalación.
Sobre el autor
Anichur Rahaman
Seguir Leyendo
