Respuesta breve

Una regla de acceso que solo existe en la interfaz es una sugerencia. Si alguien llama a la API directamente, abre otra pantalla o un error deja pasar una consulta, la regla desaparece. Las reglas que importan deben cumplirse en la base de datos. Lo mismo vale para las validaciones y la auditoría: que una persona no pueda estar asignada al 120 %, que un fichaje antiguo no se edite o que cada cambio deje rastro son garantías que conviene aplicar donde viven los datos.

Puntos clave

  • Una regla de acceso que solo existe en la interfaz es una sugerencia: basta una llamada directa a la API, otra pantalla o un error para saltarla.
  • Con políticas de fila, la base de datos filtra cada consulta según quién pregunta, y lo que no corresponde a un usuario no está oculto: no está.
  • Las reglas de negocio deben validarse en los datos, porque una importación, un script o una pantalla nueva saltarán las que solo aplica el formulario.
  • Una práctica útil es que la aplicación escriba solo a través de funciones con permisos acotados, que registran el cambio y la auditoría en la misma transacción.
  • Cerrar, archivar o desactivar en lugar de borrar conserva el historial, mantiene los informes coherentes y permite explicar las decisiones.

Cada área ve solo lo suyo

En una herramienta compartida por varias áreas, o por varias empresas en una misma plataforma, el aislamiento se resuelve con políticas de fila: la base de datos filtra cada consulta según quién pregunta. Mantenimiento ve sus asuntos, gerencia los ve todos, y nadie tiene que acordarse de añadir un filtro en cada pantalla.

El efecto práctico se nota al cambiar de usuario: lo que no corresponde deja de existir para esa sesión. No está oculto; no está. Esa diferencia es la que protege cuando la interfaz tiene un error.

Escribir solo a través de funciones

Una práctica útil es que la aplicación no escriba directamente en las tablas, sino a través de funciones con permisos acotados. Cada función hace una cosa, comprueba lo que debe comprobar y registra en la misma transacción el cambio, la auditoría y, si procede, un comentario automático.

Con un número de versión en cada registro, dos personas no se pisan: si alguien guarda sobre una versión antigua, la operación falla y se le muestra el cambio del otro. Es más sencillo que bloquear registros y evita pérdidas silenciosas.

Validar en los datos, no en el formulario

Que una persona no supere el 100 % de dedicación en periodos que se solapan, que un PIN se bloquee tras cinco intentos o que un fichaje antiguo no se pueda modificar son reglas de negocio. Si solo las aplica el formulario, una importación, un script o una pantalla nueva las saltarán sin querer.

Lo mismo con lo que no debe salir: el precio de coste de un catálogo debe eliminarse en la API pública, no solo ocultarse en la pantalla, y una puntuación interna de un cuestionario no debería enviarse nunca al navegador del cliente.

Nunca borrar: cerrar o desactivar

Borrar destruye el historial y, con él, la posibilidad de explicar una decisión. Cerrar, archivar o desactivar conserva lo ocurrido y mantiene los informes coherentes. Para cerrar un asunto puede exigirse escribir lo aprendido: cuesta poco y deja memoria.

Estas decisiones no requieren una plataforma grande. Una base de datos relacional bien configurada, funciones con permisos acotados y una copia de seguridad obligatoria antes de cada migración bastan para que una herramienta pequeña sea fiable durante años.

Preguntas frecuentes

¿Es suficiente ocultar datos en la interfaz para que cada área vea solo lo suyo?

No. Una regla de acceso que solo existe en la pantalla desaparece si alguien llama a la API directamente, abre otra pantalla o un error deja pasar una consulta. El aislamiento se resuelve con políticas de fila en la base de datos, que filtran cada consulta según quién pregunta. Así, lo que no corresponde a un usuario no está oculto: no existe para su sesión.

¿Cómo evito que dos personas se sobrescriban los cambios en una herramienta interna?

Con un número de versión en cada registro. Si alguien guarda sobre una versión antigua, la operación falla y se le muestra el cambio de la otra persona. Es más sencillo que bloquear registros y evita pérdidas silenciosas.

¿Las validaciones de negocio deben aplicarse en el formulario o en la base de datos?

En la base de datos. Reglas como que una persona no supere el 100 % de dedicación en periodos solapados, que un PIN se bloquee tras cinco intentos o que un fichaje antiguo no se pueda modificar se saltan sin querer si solo las aplica el formulario: basta una importación, un script o una pantalla nueva. Lo mismo vale para los datos que no deben salir, como el precio de coste de un catálogo en una API pública.

¿Hace falta una plataforma grande para que una herramienta interna sea fiable?

No. Validar en los datos, aplicar permisos por fila o cerrar registros en lugar de borrarlos no requiere una plataforma grande. Una base de datos relacional bien configurada, funciones con permisos acotados y una copia de seguridad obligatoria antes de cada migración bastan para que una herramienta pequeña sea fiable durante años.