Cómo organizar correctamente usuarios y permisos en una base de datos

Introducción

Organizar usuarios, roles y permisos en una base de datos consiste en relacionar cada identidad con una responsabilidad concreta. No basta con conseguir que una aplicación se conecte: hay que decidir qué puede leer, qué puede cambiar, qué debe quedar fuera de su alcance y cómo retirar ese acceso sin romper otros servicios.

En una pequeña empresa, el desorden suele empezar con una solución aparentemente cómoda. Se reutiliza la cuenta del administrador para una importación, se entrega la misma contraseña a un colaborador y a una aplicación, o se conceden todos los permisos para resolver un error. El sistema funciona, pero ya no permite distinguir qué acceso necesita realmente cada tarea.

Una organización correcta no exige reproducir la estructura de una gran corporación. Puede construirse con pocas identidades bien separadas, roles comprensibles, pruebas de acceso y un registro breve. Lo importante es que los permisos reflejen funciones actuales, no una acumulación de excepciones históricas.

Este artículo desarrolla ese modelo para bases de datos relacionales. Se centra en las decisiones y comprobaciones comunes; cuando aparecen diferencias de producto o un ejemplo SQL, se identifica el motor. Los nombres de cuentas y los casos son ficticios y no describen una instalación concreta.

Índice

• Distinguir conexión, autenticación, autorización y trazabilidad
• No confundir usuarios de la aplicación con usuarios del motor
• Construir un inventario que permita explicar cada identidad
• Separar personas, aplicaciones, despliegues y administración
• Diseñar roles por función, no por persona ni por urgencia
• Construir una matriz de permisos verificable
• Elegir el nivel de acceso: base, esquema, tabla, columna o fila
• Revisar permisos efectivos, propietarios y vías indirectas
• Qué cambia entre PostgreSQL, MySQL y SQL Server
• Ejemplo acotado: conceder consulta sobre una vista
• Evitar que los objetos nuevos rompan o amplíen el modelo de acceso
• Gestionar altas, cambios de función y bajas
• Accesos temporales y cuentas de emergencia
• Proteger credenciales y acceso remoto sin mezclar funciones
• Probar lo permitido y lo que debe permanecer bloqueado
• Caso práctico: sustituir una cuenta compartida sin improvisar
• Mantener el modelo sin crear burocracia
• Preguntas frecuentes
• Conclusión

Distinguir conexión, autenticación, autorización y trazabilidad

Antes de modificar permisos conviene separar cuatro preguntas: ¿puede el cliente llegar al servicio?, ¿puede demostrar su identidad?, ¿qué operaciones tiene autorizadas? y ¿qué evidencia queda de su actividad? Una respuesta positiva a una de ellas no garantiza las demás.

Un firewall puede impedir conexiones de red, pero no define qué tablas puede consultar una cuenta admitida. Una contraseña correcta permite autenticar una identidad, pero no debería otorgarle todas las operaciones. Y registrar un acceso no evita que ese acceso tenga privilegios excesivos.

Esta separación evita resolver un error de conexión concediendo privilegios que no tienen relación con el fallo. Si una aplicación no llega al puerto, aumentar sus permisos sobre tablas no lo corrige. Si llega pero una operación concreta se rechaza, entonces necesitas investigar la autorización correspondiente.

El marco general puede apoyarse en una política de acceso para una empresa pequeña. Dentro de la base, esa política debe traducirse a identidades, objetos, acciones y pruebas concretas.

No confundir usuarios de la aplicación con usuarios del motor

Una aplicación puede tener veinte personas registradas y utilizar una sola identidad técnica para conectarse a la base. También puede emplear varias identidades según módulos o servicios. Por tanto, no debes crear automáticamente una cuenta del motor por cada empleado ni suponer que una cuenta técnica identifica por sí sola a la persona que realizó una operación.

Los permisos del usuario dentro del CRM o del gestor de pedidos pertenecen a la aplicación. Los permisos de su conexión SQL limitan lo que esa aplicación puede hacer sobre la base. Ambas capas necesitan coherencia, pero no son intercambiables.

Cuándo tiene sentido una cuenta nominativa de base de datos

Cuando una persona necesita acceder directamente con una herramienta de administración, análisis o desarrollo, una identidad propia permite atribuir ese acceso y retirarlo de forma independiente. Su autorización debe responder a una tarea, no simplemente a que «trabaja en informática».

Para el personal que solo utiliza pantallas de una aplicación, suele ser más adecuado gestionar el acceso en esa aplicación. Entregar credenciales SQL puede abrir una vía que elude validaciones, restricciones funcionales y controles previstos en las pantallas.

Cómo conservar atribución cuando existe una cuenta técnica

La aplicación debe mantener su propia trazabilidad de acciones cuando resulte necesaria. Un registro del motor que solo muestra svc_pedidos_prod no revela automáticamente qué usuario final solicitó la operación. Relacionar ambos niveles requiere identificadores y registros de aplicación diseñados para ello, sin guardar secretos ni información innecesaria.

La coordinación con el resto de herramientas se desarrolla en cómo organizar las cuentas de usuario de las aplicaciones. Aquí la unidad de trabajo es la identidad que realmente llega al motor.

Construir un inventario que permita explicar cada identidad

La primera revisión debe responder por qué existe cada cuenta. Un nombre y una fecha de creación no bastan. Necesitas saber si corresponde a una persona, una aplicación, una tarea programada, un despliegue o una función administrativa.

Una ficha útil registra identidad, tipo, entorno, propietario funcional o técnico, servicio que la utiliza, método de autenticación, origen autorizado, roles asignados y fecha de revisión. En lugar de copiar una contraseña, incluye únicamente la referencia a su ubicación protegida.

Identidad: svc_pedidos_prod
Tipo: servicio de aplicación
Entorno: producción
Responsable: mantenimiento de la aplicación de pedidos
Consumidor: proceso web y trabajadores del mismo servicio
Origen previsto: servidor de aplicación autorizado
Rol funcional: r_pedidos_operacion
Secreto: referencia en el gestor de credenciales
No debe: administrar usuarios ni modificar el esquema
Revisión: junto con cambios de aplicación y de permisos

La ficha es un ejemplo de organización, no una configuración ejecutable. En el sistema real debe corresponderse con lo que muestran el motor, la aplicación y el mecanismo de secretos.

Una cuenta poco utilizada no está necesariamente abandonada

Puede pertenecer a un proceso mensual, una restauración o una tarea de contingencia. Antes de retirarla, identifica dependencias y observa un periodo representativo. Del mismo modo, una cuenta con actividad no es necesariamente legítima: puede seguir usándola una integración que ya debería haberse eliminado.

Las cuentas que nadie puede explicar deben tratarse como una incertidumbre pendiente. Investiga su origen y consumidores; no las mantengas indefinidamente por miedo, pero tampoco las elimines sin comprobar si sostienen una tarea importante.

Separar personas, aplicaciones, despliegues y administración

La separación más útil no consiste en multiplicar nombres, sino en conseguir que una operación pueda limitarse, rotarse o revocarse sin afectar a funciones ajenas. Una contraseña compartida entre una aplicación y una persona impide retirar el acceso de esa persona sin modificar también la aplicación.

Identidades de ejecución y de cambio

La cuenta que atiende peticiones ordinarias necesita los permisos funcionales de la aplicación. La que despliega una migración puede necesitar modificar estructuras. Mantener permanentemente ambas capacidades en la misma conexión amplía el alcance de un error durante la operación cotidiana.

La separación debe respetar las necesidades reales del producto. Algunas aplicaciones realizan migraciones al arrancar o al actualizarse. Antes de restringirlas, identifica ese comportamiento y diseña cómo se ejecutará el cambio con autorización controlada; no retires permisos necesarios sin una alternativa probada.

Copias, monitorización e integraciones

Cada función necesita analizarse por separado. Una cuenta de copia puede requerir acceso amplio a datos, aunque no deba administrar usuarios. Una cuenta de monitorización puede leer estadísticas sin necesitar todas las tablas de negocio. Una integración debería acceder únicamente a las fuentes y destinos de su flujo.

No existe un conjunto mínimo universal para cualquier herramienta de backup: depende del motor, del método y del alcance de recuperación. Debe verificarse con su documentación y con una prueba representativa.

Incluso cuando administra una sola persona

Usar una identidad ordinaria y otra administrativa sigue reduciendo errores. La separación no crea una aprobación independiente si ambas las controla la misma persona, pero sí obliga a cambiar deliberadamente de contexto antes de realizar operaciones de mayor impacto.

La orientación de OWASP sobre seguridad de bases de datos recomienda identidades de aplicación con privilegios mínimos, sin reutilizar las cuentas administrativas incorporadas al motor.

Diseñar roles por función, no por persona ni por urgencia

Un rol reúne permisos que corresponden a una función estable. La persona o el servicio recibe el rol mientras necesita esa función. Así, cuando cambia un acceso no es necesario reconstruir manualmente decenas de concesiones dispersas.

Conviene utilizar nombres que expresen recurso y capacidad: r_pedidos_consulta, r_pedidos_operacion o r_informes_resumen. Evita nombres como «avanzado» o «especial» si no permiten deducir qué acceso representan.

Un núcleo pequeño y excepciones visibles

No crees un rol distinto para cada consulta si eso produce una estructura imposible de mantener. Empieza por funciones coherentes y separa aquellas que presentan diferencias reales de acceso. Una excepción debe tener motivo, alcance y revisión, en lugar de convertirse en un rol genérico que acumula permisos de todo tipo.

También es importante distinguir la facultad de usar un rol de la facultad de concederlo a otros. No toda persona autorizada a consultar información debe poder delegar esa autorización.

Herencia y activación no significan lo mismo

En PostgreSQL, una pertenencia puede permitir heredar privilegios o asumir otro rol mediante SET ROLE, según sus opciones. Esto debe revisarse en toda la cadena, no solo en la relación directa. La documentación de pertenencia a roles explica esa distinción.

En términos operativos, el resultado deseado es poder responder: «Esta identidad tiene este permiso porque pertenece a esta función aprobada». Cuando hacen falta varias pantallas y muchas excepciones para reconstruir la respuesta, conviene simplificar la estructura.

Construir una matriz de permisos verificable

La matriz debe describir tareas permitidas y límites, no limitarse a etiquetas como «lectura» y «administración». Debe indicar sobre qué objetos se aplica cada capacidad y qué operaciones quedan fuera del diseño.

La columna «fuera de su alcance» expresa una expectativa de diseño. No significa que el motor haya recibido una instrucción universal de denegación. Hay que comprobar todas las vías de acceso y aplicar las reglas del producto concreto.

Para convertir la matriz en permisos reales, identifica tablas, vistas, rutinas, secuencias y esquemas implicados. Una operación de inserción puede necesitar recursos auxiliares; una actualización puede requerir leer columnas para localizar o comprobar registros. Resuelve esas necesidades concretas en lugar de conceder control total para evitar investigar.

La prueba funcional completa es más valiosa que comprobar únicamente una consulta sencilla. Una aplicación puede leer correctamente y fallar al guardar, registrar un historial o ejecutar una tarea diferida.

Elegir el nivel de acceso: base, esquema, tabla, columna o fila

Los permisos deben situarse en el nivel que resuelva la necesidad con un mantenimiento razonable. Dar acceso a una base completa es sencillo, pero puede exponer dominios ajenos. Restringir cada columna puede reducir exposición, aunque exige revisar cuidadosamente los cambios del modelo.

Conectar no equivale a consultar

En PostgreSQL, CONNECT, USAGE de un esquema y SELECT sobre un objeto representan capacidades distintas. Ser propietario añade derechos que no se reducen a una concesión ordinaria. Estas diferencias se describen en la referencia de privilegios del motor.

La consecuencia práctica es que no puedes evaluar una cuenta únicamente por el nombre del rol o por un permiso aislado. Hay que considerar el conjunto de recursos que permiten completar la operación.

Vistas y columnas para reducir exposición

Cuando una persona solo necesita totales, ofrece un acceso que contenga esos totales, no todas las tablas de origen. Una vista puede servir de interfaz, pero hay que revisar sus privilegios, su definición y las vías alternativas. El filtro deja de ser una barrera si la misma identidad puede consultar directamente los datos que pretendía ocultar.

La lectura también puede ser sensible. Poder exportar información comercial o personal tiene consecuencias aunque no exista permiso de modificación. «Solo lectura» describe integridad, pero no garantiza confidencialidad.

Restricciones por fila cuando existe una necesidad real

Las políticas por fila permiten limitar registros dentro de una misma tabla en los motores que las soportan. No conviene presentarlas como una protección absoluta: PostgreSQL documenta excepciones para superusuarios, roles con BYPASSRLS y, normalmente, propietarios. Deben probarse con las identidades reales, como explica su documentación de seguridad por filas.

Antes de introducir este nivel, define qué identidad determina la fila autorizada y cómo llega ese contexto desde la aplicación. Una política sofisticada apoyada en un contexto mal gestionado puede ofrecer una falsa sensación de aislamiento.

Revisar permisos efectivos, propietarios y vías indirectas

Retirar una concesión directa no demuestra que haya desaparecido el acceso. La identidad puede recibir la misma capacidad por otro rol, por permisos generales, por propiedad o a través de una rutina autorizada. Lo que importa es el resultado efectivo de todas las vías aplicables.

Permisos generales y nombres engañosos

En PostgreSQL, PUBLIC representa a todos los roles y no es lo mismo que el esquema llamado public. Revisar solo los roles creados por la empresa puede dejar fuera concesiones generales. Además, retirar un permiso de una vía no constituye una denegación que anule cualquier otra concesión.

No revoques indiscriminadamente todos los permisos generales: puede haber dependencias legítimas. Identifica primero cuáles permiten llegar a objetos sensibles y prueba el efecto de cualquier cambio en un entorno controlado.

Propiedad no es una etiqueta administrativa inocua

Una cuenta propietaria puede conservar capacidades estructurales que no encajan con «solo lectura». Por eso conviene separar la propiedad técnica de objetos de las identidades de uso ordinario. Si la propiedad pertenece a una persona, su salida puede complicar el mantenimiento y la retirada de la cuenta.

Rutinas y contexto de ejecución

Una función que se ejecuta con privilegios de su propietario puede permitir operaciones que el llamante no tiene directamente. En PostgreSQL esto exige especial cuidado con SECURITY DEFINER, el acceso a la función y su entorno de resolución de nombres; la documentación de creación segura de funciones detalla estas precauciones.

La revisión debe incluir tanto el acceso normal como las capacidades de delegación o cambio de contexto. No basta con afirmar que una identidad «no puede modificar una tabla» si puede ejecutar una operación autorizada que la modifica sin límites adecuados.

Qué cambia entre PostgreSQL, MySQL y SQL Server

El modelo organizativo es transferible, pero no debes trasladar comandos ni suponer que «usuario», «rol», «esquema» y «base» tienen idéntico significado en todos los motores.

En PostgreSQL, los roles se definen para el clúster o conjunto de bases administrado por una instancia, no de forma independiente dentro de cada base. Que una identidad exista en ese ámbito no significa que deba poder utilizar todas sus bases. La referencia de creación de roles describe ese alcance.

En MySQL, una cuenta combina nombre de usuario y origen, mediante la forma 'usuario'@'host'. Dos cuentas con el mismo nombre de usuario y distinto origen pueden tener tratamientos diferentes. Esa identidad completa debe aparecer en el inventario; puede comprobarse en la documentación de nombres de cuenta de MySQL.

SQL Server distingue entidades de seguridad de ámbito servidor y de ámbito base de datos, incluidos inicios de sesión, usuarios y roles. No conviene confundir el acceso a la instancia con los permisos dentro de una base. Microsoft explica esa jerarquía en su documentación de entidades de seguridad.

Estas diferencias cambian cómo consultas el estado y cómo aplicas la matriz. La política debe expresar la intención; el procedimiento específico del motor debe demostrar que esa intención se ha implementado. La configuración de otro producto puede servir de inspiración, pero no de prueba.

Ejemplo acotado: conceder consulta sobre una vista

El siguiente ejemplo didáctico corresponde a PostgreSQL 17 y debe probarse en un laboratorio. Supone que ya existen el esquema informes, una vista revisada llamada v_pedidos_resumen y la cuenta lector_laboratorio, con autenticación y conexión configuradas y sin privilegios ajenos al ejercicio. La cuenta utiliza herencia de roles.

El objetivo no es dar lectura sobre toda la base, sino agrupar el acceso a una interfaz concreta. Debe ejecutarlo una identidad autorizada para crear el rol y conceder los permisos correspondientes:

CREATE ROLE r_informes NOLOGIN;
GRANT USAGE ON SCHEMA informes TO r_informes;
GRANT SELECT ON informes.v_pedidos_resumen TO r_informes;
GRANT r_informes TO lector_laboratorio;

El rol funcional no permite iniciar una sesión por sí mismo. La cuenta personal recibe su pertenencia y puede utilizar los privilegios según la configuración de herencia. La sintaxis y las opciones de pertenencia deben contrastarse con la referencia de roles de PostgreSQL.

Este fragmento añade permisos; no elimina concesiones anteriores ni acredita que la vista sea segura. No configura red, TLS, autenticación, caducidad, permisos generales ni acceso a otros objetos. Para considerar terminado el ejercicio debes revisar esas condiciones y conectarte realmente como lector_laboratorio.

La prueba positiva consiste en consultar la vista. La prueba negativa consiste en intentar consultar un objeto restringido del laboratorio y verificar el rechazo, además de comprobar que no puede conceder privilegios ni alterar estructuras. Utiliza datos sintéticos y no ejecutes pruebas destructivas contra producción.

Evitar que los objetos nuevos rompan o amplíen el modelo de acceso

Una organización puede estar correcta hoy y dejar de estarlo al crear una tabla, una vista o una rutina. Los permisos de los objetos existentes y los que recibirán objetos futuros deben revisarse como problemas diferentes.

En PostgreSQL, ALTER DEFAULT PRIVILEGES afecta a objetos creados posteriormente, no corrige los existentes, y se aplica según el rol que crea el objeto. Configurar los valores de un rol diferente del creador real puede no producir el efecto esperado. La referencia es la documentación de privilegios predeterminados.

Elegir entre autorización explícita y herencia deliberada

Dar acceso automáticamente a toda nueva tabla puede simplificar un dominio homogéneo. También puede exponer una tabla sensible incorporada más tarde al mismo ámbito. La decisión debe apoyarse en qué tipo de objetos se permite crear allí y quién revisa sus efectos.

Para interfaces de informes, puede ser preferible autorizar explícitamente vistas revisadas. Para un conjunto de tablas estrictamente internas de una aplicación, una política uniforme puede resultar mantenible si su alcance está claro. No hay que aplicar el mismo criterio por comodidad a ambos casos.

Incluir permisos en la aceptación del cambio

Después de una migración, prueba que el consumidor esperado puede usar el objeto nuevo y que un consumidor no autorizado no puede hacerlo. Comprueba también si añadir campos amplía la información accesible por concesiones existentes. El cambio de estructura y el cambio de exposición deben revisarse juntos.

Gestionar altas, cambios de función y bajas

Un permiso necesita un principio, una justificación y una condición de retirada. Sin ese ciclo, incluso un buen diseño de roles acaba acumulando accesos que ya no responden a ninguna tarea.

Alta: pedir una función y demostrarla

La solicitud debería identificar el trabajo, el entorno, los datos y la duración prevista. Asigna una identidad, concede el rol correspondiente y entrega el acceso por un mecanismo protegido. Termina con pruebas positivas y negativas, no solo con una confirmación de que la contraseña funciona.

Cambio: sustituir, no solo sumar

Cuando una persona cambia de función, revisa qué permisos anteriores dejan de ser necesarios. Añadir el nuevo rol y conservar todos los antiguos produce una acumulación silenciosa. La revisión debe considerar también tareas que la persona gestionaba y cuyo responsable debe cambiar.

Baja: cerrar las vías de acceso sin destruir dependencias

Retira la capacidad de iniciar nuevas sesiones y revoca los accesos correspondientes al caso. Evalúa sesiones ya abiertas, credenciales compartidas, acceso remoto y secretos que la persona conocía. No presupongas que cambiar una contraseña termina automáticamente todas las conexiones existentes.

Antes de eliminar definitivamente la identidad, revisa si posee objetos o ejecuta trabajos. Transfiere esas responsabilidades mediante un procedimiento del motor. No utilices borrados masivos de objetos como atajo para resolver una dependencia de propiedad.

La baja tampoco retira las copias de datos que una persona ya hubiera exportado. Esa limitación refuerza la importancia de minimizar desde el principio el acceso y la circulación de información.

Accesos temporales y cuentas de emergencia

Una asistencia puntual no justifica una cuenta privilegiada indefinida. Registra el motivo, el ámbito, la persona responsable y la condición de cierre. Cuando sea posible, habilita el acceso para la intervención y verifica su retirada al terminar.

No confundas una fecha escrita en una ficha con una restricción aplicada. Tampoco todos los mecanismos llamados «caducidad» bloquean la identidad completa. Por ejemplo, en PostgreSQL, VALID UNTIL establece caducidad de contraseña y no se aplica igual a autenticaciones que no utilizan contraseña, tal como aclara la documentación del comando.

Preparar una vía de recuperación administrativa

La empresa debe poder recuperar el control si falla su acceso habitual. Esa vía puede depender del proveedor, de la infraestructura o de una identidad de emergencia según el entorno. Debe estar documentada, protegida y comprobada sin convertirla en la cuenta cotidiana.

El material de recuperación no debería depender exclusivamente de la misma base que permite administrar. De otro modo, una caída puede dejar inaccesible la información necesaria para resolverla.

Una vez utilizada una vía extraordinaria, registra el motivo y revisa qué cambios se realizaron. Si se expuso un secreto o se habilitó un permiso adicional, cierra la excepción de forma explícita.

Proteger credenciales y acceso remoto sin mezclar funciones

La matriz de permisos pierde valor si las credenciales terminan en repositorios, capturas, mensajes o archivos accesibles a cualquiera. Conserva los secretos en un mecanismo con control de acceso y referencia su ubicación desde la documentación, sin copiar su contenido.

La rotación debe identificar primero los consumidores. Una misma identidad puede estar configurada en un proceso web, un trabajador y una tarea programada. Cambiar el secreto solo en uno de ellos puede dejar fallos intermitentes difíciles de explicar.

Para organizar este ciclo, la guía de gestión de secretos de OWASP trata el almacenamiento, el control de acceso y la rotación como partes de una gestión continuada, no como una única elección de contraseña.

Movilidad profesional con un camino administrativo controlado

Necesitar administrar desde fuera no obliga a publicar el puerto de la base para cualquier origen. Define un acceso administrativo protegido y limita quién puede utilizarlo. El segundo factor puede situarse en la identidad corporativa, la VPN o la puerta de acceso cuando la arquitectura lo permita; no presupongas que todos los motores lo ofrecen nativamente.

En conexiones de red, protege el transporte y verifica la identidad del servidor. OWASP recomienda restringir orígenes, proteger herramientas de administración y utilizar conexiones cifradas con validación del certificado en su guía de seguridad de bases de datos.

Para separar de forma más amplia credenciales y datos entre fases de trabajo, consulta cómo organizar desarrollo, pruebas y producción. Un secreto de producción no debería circular por comodidad dentro de un laboratorio.

Probar lo permitido y lo que debe permanecer bloqueado

La validación necesita dos direcciones. La prueba positiva demuestra que la función autorizada funciona. La negativa demuestra que no puede salirse de su ámbito por las vías previstas en el ensayo. Una sin la otra deja la política incompleta.

Realiza estas pruebas con la identidad real, no con una cuenta administrativa que omite restricciones. Incluye el origen de conexión, el método de autenticación y el contexto de rol utilizados en la operación habitual.

No conviertas «probar una denegación» en ejecutar comandos peligrosos sobre datos reales. Utiliza objetos de laboratorio o mecanismos de inspección de privilegios. Tampoco presupongas que una transacción permite deshacer cualquier operación administrativa: el comportamiento depende del motor y del comando.

En producción, aplica cambios acotados y comprueba flujos representativos. Debes poder distinguir un permiso insuficiente de un error de aplicación y tener una reversión limitada al cambio realizado, no recurrir a conceder acceso total a toda la base.

Caso práctico: sustituir una cuenta compartida sin improvisar

Una empresa ficticia utiliza la misma cuenta privilegiada en su aplicación, en el programa de copias y en el equipo de un colaborador. El colaborador termina su trabajo. Cambiar inmediatamente la contraseña compartida podría detener los dos servicios, pero dejarla activa conservaría un acceso innecesario.

Primero: identificar todos los consumidores

Revisa configuraciones, tareas y conexiones conocidas. Anota qué función realiza cada consumidor y qué pruebas permiten verificarla. No deduzcas los permisos mínimos únicamente de unos minutos de actividad: podrían faltar operaciones periódicas importantes.

Después: separar sin cambiar todo a la vez

Crea identidades de servicio y roles adecuados al motor. Prueba la aplicación y las copias con sus nuevas credenciales en un entorno controlado. Actualiza los consumidores por fases, incluyendo trabajadores, procesos programados y configuraciones que puedan recrearse durante un despliegue.

La copia necesita validación de alcance y restauración, no solo un mensaje de tarea terminada. La aplicación necesita comprobar lectura, escritura y funciones menos frecuentes. Una migración de permisos debe preservar las operaciones legítimas al mismo tiempo que reduce privilegios.

Finalmente: retirar la cuenta antigua y revisar la exposición

Cuando los consumidores legítimos ya no dependan de la cuenta compartida, bloquea su uso, trata las sesiones restantes y revisa los secretos conocidos por el colaborador. Documenta el resultado y las dependencias transferidas.

Este orden corresponde a una regularización controlada. Ante indicios de compromiso activo, la prioridad puede ser contener el acceso inmediatamente, incluso asumiendo una interrupción. No debe retrasarse una contención necesaria solo para mantener una transición cómoda.

Mantener el modelo sin crear burocracia

Una revisión sostenible se centra en preguntas que producen decisiones: ¿qué identidades ya no tienen una función?, ¿qué excepciones siguen abiertas?, ¿qué objetos cambiaron?, ¿qué permisos se ampliaron y por qué? El resultado debe indicar qué se mantiene, qué se retira y qué necesita investigación.

Revisa especialmente después de altas y bajas, cambios de proveedor, nuevas integraciones, migraciones y restauraciones. Una restauración puede traer un estado anterior de accesos o requerir reconstruir identidades según el método empleado. Por eso los permisos forman parte de la validación del servicio recuperado.

Conserva evidencia de cambios importantes: solicitante, responsable, motivo, ámbito, fecha y resultado de pruebas. No necesitas registrar indiscriminadamente el contenido de todas las consultas. El registro debe aportar atribución y control sin convertirse en otra copia desprotegida de los datos.

La política de revisión puede integrarse con el mantenimiento preventivo de la base, mientras el inventario técnico de conexiones y procedimientos puede referenciarse desde la documentación del servidor. Cada documento debe conservar su función para evitar copias contradictorias.

Preguntas frecuentes

Conclusión

Organizar usuarios y permisos en una base de datos significa transformar accesos improvisados en funciones explícitas. Cada identidad debe tener un propósito, cada rol un alcance comprensible y cada excepción una condición de cierre.

La base del modelo es separar uso ordinario, cambios estructurales y administración; definir una matriz sobre objetos concretos; revisar herencias, propiedad y permisos generales; y validar tanto lo permitido como lo que debe quedar bloqueado. Las altas, los cambios de función y las bajas mantienen ese diseño alineado con la realidad.

Una pequeña empresa no necesita muchos roles, sino roles que pueda explicar. El resultado deseable es que la aplicación funcione, los datos se expongan únicamente donde corresponde y un acceso pueda cambiarse sin poner en riesgo al resto del sistema.