Autenticación con identidad en la base

En RDS para MariaDB, MySQL y PostgreSQL se puede autenticar con IAM: en lugar de una clave guardada en la base, la aplicación pide un token de autenticación, que vale 15 minutos. El token solo se usa para entrar; no afecta a la sesión una vez establecida. La gestión del acceso pasa a IAM, donde un permiso se concede o se revoca en un lugar central, y no hay una clave que se guarde en el código.

Hay un matiz que importa a quien audita: según la documentación de RDS, ni CloudTrail ni CloudWatch registran la autenticación con IAM. Quitar la clave local no sustituye a la auditoría dentro de la base, que verás en otra sala.

Una cuenta compartida es una cuenta sin dueño: cuando algo ocurre, el registro dice el nombre del usuario y no la persona. Y cuando una de esas personas se va del equipo, nadie cambia la clave. Abre el laboratorio y mira usuarios_bd: la columna personas_que_lo_usan indica cuántas personas entran con cada usuario.

La política de Nemocon exige cambiar las claves locales cada 90 días como máximo. Entre los usuarios de clave local, busca el que lleva más tiempo sin cambiarla y calcula cuántos días han pasado desde ese cambio hasta la fecha de la revisión (en la tabla revision). Los usuarios con IAM no tienen clave que cambiar.

En Azure SQL existe la autenticación solo con Microsoft Entra: cuando se activa, se deshabilita la autenticación SQL del servidor, incluido el inicio de sesión del administrador de SQL. Los inicios de sesión SQL que ya existían no se borran; simplemente dejan de poder conectar. Para activarla hace falta que el servidor tenga antes un administrador de Entra.

Mira servidores_azure. Interesa el servidor que acumula las dos fallas: acepta autenticación SQL y ni siquiera tiene un administrador de Entra definido.

Aun con la identidad de la nube en uso, suele quedar una cuenta administradora local de la que nadie se atreve a desprenderse. Dejarla en el uso diario conserva todos sus defectos. Lo razonable es sacarla de la operación normal.