Una cuenta de administrador compartida y una promoción de fin de semana olvidada pueden costarle miles de dólares a un comercio. Aprende a diseñar roles, bloquear pares de funciones riesgosos, poner compuertas por monto a los reembolsos y conservar un registro de auditoría que nadie edite en silencio.
Author
Anichur Rahaman
Imagina a la dueña de una cadena de tres tiendas un lunes por la mañana. Abre el reporte de reembolsos y ve que la tienda 2 emitió 41 el domingo, por un total de 2,870 dólares. Treinta y ocho están entre 50 y 300 dólares, el rango que debía aprobar una segunda persona. Todos salieron del mismo usuario de cajero, y todos los aprobó ese mismo usuario.
Nadie hackeó nada. Hace dos años, en un día de mucha carga, a ese cajero le dieron el rol de encargado de turno "solo por el fin de semana", y nunca se lo quitaron. El sistema hizo exactamente lo que se le pidió. Es un escenario ilustrativo, pero el patrón es común: los accesos se dan con prisa, no se revisan nunca y se registran de una forma que nadie lee.
Este artículo trata de tres ideas que lo evitan: roles a la medida de lo que pide cada puesto, dos personas para todo lo que mueva dinero o inventario y un registro de auditoría que nadie pueda editar en silencio. Incluye una plantilla de roles para un comercio de tres tiendas y los campos del registro de un reembolso.
Con tres personas todos se conocen, y una sola cuenta de administrador compartida parece inofensiva. Con quince personas en tres tiendas, los mismos hábitos se vuelven un riesgo. Las causas son comunes:
La mayoría de las pérdidas no vienen de ataques espectaculares, sino de acciones pequeñas, repetidas y sin vigilancia, hechas por alguien que tenía permiso para hacerlas. De todas las formas de perder dinero, la interna es la que un comerciante puede controlar mejor.
El control de acceso basado en roles suena abstracto hasta que lo divides en partes. Un permiso es un verbo sobre una cosa: refund.issue, refund.approve, stock.adjust, customer.export. Un rol es un paquete con nombre de permisos que corresponde a un puesto: cajero, encargado de turno, contador. Y el alcance indica dónde aplica el rol: una tienda, una bodega o todas partes.
La unidad que importa es la asignación, no el rol. "Sana es encargada de turno en la tienda 2" es un renglón: usuario, rol, alcance, fecha de inicio y, si se quiere, fecha de fin. Si Sana pasa a la tienda 3, el renglón cambia; no se queda en silencio con los accesos de la tienda 2.
Mínimo privilegio (least privilege) significa que cada persona tiene el conjunto más pequeño de permisos que le permite hacer su trabajo hoy. NIST SP 800-53 lo plantea en el control AC-6: el sistema aplica el conjunto más restrictivo de derechos necesario para las tareas especificadas. En un sistema de comercio se traduce en tres hábitos.
El mínimo privilegio limita lo que una persona puede hacer. La separación de funciones (segregation of duties) limita lo que puede hacer sola. NIST AC-5 la describe como repartir las funciones entre personas distintas para que abusar de un privilegio exija colusión. El método es sencillo: haz la lista de pares de funciones que, en manos de una sola persona, podrían provocar o esconder una pérdida, y haz que el sistema rechace esa combinación.
Los cuatro pares bloqueados cubren casi todo el dinero de un negocio de comercio. Quien puede crear un proveedor y pagarle puede inventar un proveedor. Quien emite y aprueba un reembolso, como el cajero de nuestro lunes, se autoriza a sí mismo. Editar la nómina y ejecutarla tiene la misma forma. Y ajustar el inventario y aprobar el conteo que lo justifica es la manera en que una merma se vuelve invisible.
La regla debe aplicarla el software, en el momento de la acción, y no solo un documento de políticas. Una validación que diga "quien aprueba debe ser un usuario distinto de quien solicita" cuesta una línea de lógica y elimina toda una clase de problemas.
El inicio de sesión demuestra quién eres. No demuestra que esta acción en particular sea razonable. Para una lista corta de acciones, como reembolsos, cambios de precio, descuentos por encima de un límite, ajustes de inventario, exportaciones de datos de clientes y corridas de nómina, agrega una compuerta que mire el monto.
El flujo de abajo usa umbrales ilustrativos. Elige los tuyos según lo que cuesta un solo error en tu negocio.
Tres detalles de ese flujo importan más de lo que parecen.
Para el nivel más alto, aquí por encima de 300 dólares, exige dos aprobadores, por ejemplo el gerente de la tienda y alguien de finanzas. Mantén pocos niveles. Tres se explican en la caja; siete se esquivan.
Esta tabla es un punto de partida, no un estándar. "Su tienda" significa que el permiso aplica solo a la tienda asignada al usuario. "Solicita" significa que la persona puede iniciar la acción, pero otra debe aprobarla.
| Permiso | Cajero | Encargado de turno | Gerente de tienda | Almacenista | Contador | Dueño |
|---|---|---|---|---|---|---|
| Vender en caja | Su tienda | Su tienda | Su tienda | No | No | Todas |
| Emitir reembolso hasta 50 dólares | Su tienda | Su tienda | Su tienda | No | No | Todas |
| Aprobar reembolso de 50 a 300 dólares | No | Su tienda | Su tienda | No | No | Todas |
| Aprobar reembolso de más de 300 dólares | No | No | Su tienda (primero de dos) | No | Segundo aprobador | Todas |
| Cambiar un precio | No | Solicita | Su tienda, dentro de un porcentaje fijo | No | No | Todas |
| Ajustar inventario | No | No | No | Su tienda | No | Todas |
| Aprobar conteo de inventario | No | No | Su tienda | No | Sí | Todas |
| Crear proveedor | No | No | No | No | No | Todas |
| Pagar a un proveedor | No | No | No | No | Sí | No |
| Exportar la lista de clientes | No | No | No | No | No | Todas |
| Administrar usuarios y roles | No | No | No | No | No | Todas, con aprobación de un segundo dueño |
Fíjate en los huecos, que son a propósito. El contador puede pagar a los proveedores, pero no crearlos. El dueño puede crear proveedores, pero no pagarles, lo cual es un poco molesto y lo es por diseño. La columna del dueño muestra lo que el rol puede hacer, pero la revisión de conflictos se ejecuta en cada transacción, así que el dueño tampoco puede aprobar un reembolso que él mismo emitió. Los roles de nómina quedan fuera de esta tabla porque suelen vivir en una plantilla aparte de recursos humanos, con la misma regla: quien edita los sueldos no ejecuta la nómina.
Un registro de auditoría responde después una sola pregunta: quién hizo qué, sobre qué registro, cuándo, por qué y con el permiso de quién. Una línea que diga "reembolso procesado" no lo hace. Este es el registro del reembolso de 184 dólares del flujo anterior.
| Campo | Valor de ejemplo | Para qué sirve |
|---|---|---|
| Id de registro y hora | R-20931, 09:41:07 UTC | Orden y búsqueda. Guarda en UTC, muestra en hora local. |
| Actor | cashier-07 (un usuario con nombre, nunca "till") | Responsabilidad |
| Acción y objetivo | refund.issue sobre el pedido 48211 | Qué registro cambió |
| Dónde | Tienda 2, caja 3, dispositivo e IP | Alcance y detección de ubicaciones inusuales |
| Monto y motivo | $184.00, código de motivo "damaged" | Análisis de patrones por motivo |
| Antes y después | Pago capturado y luego reembolsado; inventario +1 en la bandeja de devoluciones | Prueba del efecto |
| Regla aplicada | "Reembolso de 50 a 300 dólares: un aprobador" | Muestra la política vigente en ese momento |
| Aprobador y hora | lead-02, 09:42:31 UTC | Demuestra que hubo una segunda persona |
| Resultado | Completado | Éxito, denegación o rechazo |
| Hash anterior y propio | 7f3a…c91e | Evidencia de alteración |
Un registro que un administrador puede editar prueba poco. Dos medidas baratas ayudan. Primero, haz que la tabla sea solo de adición (append-only) para la aplicación: sin permiso de actualizar ni borrar, y con las correcciones escritas como renglones nuevos. Segundo, encadena los registros. Cada renglón guarda un hash SHA-256 de su propio contenido más el hash del renglón anterior, de modo que cambiar un renglón viejo rompe todos los hashes que siguen. Copia el registro cada noche a un almacenamiento donde la aplicación no pueda escribir.
La retención depende de las reglas que te apliquen. Como referencia, el requisito 10.5.1 de PCI DSS v4.0.1 pide conservar el historial de registros de auditoría al menos 12 meses, con los tres más recientes disponibles de inmediato para análisis. Revisa qué exigen además tus normas fiscales, de nómina y de privacidad, y deja por escrito el plazo.
La última pregunta es quién lo lee. Un registro que nadie revisa es un diario. Asigna a una persona concreta fuera de las tiendas, un responsable de finanzas o el dueño, y dale tres vistas guardadas: reembolsos por usuario, ajustes manuales de inventario y exportaciones. Diez minutos a la semana bastan para detectar al cajero del lunes antes del lunes.
La mayoría de los problemas de acceso empiezan en un cambio de puesto, no en un ataque. Trata los tres momentos como una rutina con un orden fijo.
Alta: el gerente solicita un rol de la plantilla, el responsable del rol lo aprueba y la persona activa un segundo factor de inicio de sesión antes del primer uso. Cambio: quita primero el rol anterior y luego agrega el nuevo. Ese orden evita la acumulación de permisos. Baja: desactiva la cuenta (no la borres, el historial debe quedar), cierra las sesiones, rota los códigos compartidos y las claves de API, y reasigna las aprobaciones pendientes.
El acceso temporal merece su propia regla. "Cubrir a Priya hasta el viernes" se convierte en una asignación de rol con fecha de fin, de modo que vence sola sin que nadie tenga que acordarse. Esa sola función habría frenado la promoción de fin de semana en la escena del lunes.
Cada asignación de rol debería ser confirmada por una persona al menos cada cierto tiempo. PCI DSS 7.2.4 fija seis meses como mínimo para los sistemas en alcance; para un comercio con rotación de personal, cada trimestre es un mejor ritmo. La revisión toma una hora si la preparas bien.
Unos cuantos números muestran si los controles funcionan, y ninguno requiere un proyecto de tableros.
Vuelve a correr la escena inicial con estos controles. El rol del cajero cubre ventas y reembolsos hasta 50 dólares. El reembolso de 184 dólares pasa a un encargado de turno, que es otra persona, y el sistema no acepta el mismo usuario dos veces. La promoción de fin de semana tiene fecha de fin y vence el lunes.
Los 41 reembolsos no ocurren como ocurrieron. Si algunos siguen siendo sospechosos, la dueña los encuentra en una revisión semanal de diez minutos, porque cada uno trae usuario, regla, aprobador y hash. Lee un reporte en lugar de descubrir una pérdida.
Anichur Rahaman es arquitecto de software y creador de StoreConsole. Diseña sistemas de comercio y ERP para negocios en crecimiento, con enfoque en arquitectura orientada a eventos, integridad de datos y operación en servidores propios.
About the Author
Anichur Rahaman
Continue Reading
