Cambiar las contraseñas periódicamente es una práctica común, pero si se trata de usuarios de la base de datos que sirven para dar soporte a las aplicaciones, puede ser todo un dolor de cabeza.
Empecemos por comprender qué pasa tras bambalinas y luego de ello podremos ver cómo superar los problemas que se presentan.
Imaginemos el siguiente escenario:
Tenemos un grupo de aplicaciones que se conectan a la base de datos db1, y lo hacen con el usuario webapp identificado con contraseña dyingPass. Este usuario tiene asociado el profile webuser.
Procedimiento convencional
Contraseña modificada
Se cambia la contraseña del usuario de base de datos empleado por las aplicaciones, al valor brandNewPass.
SQL> alter user webapp identified by brandNewPass;1
2
Aplicaciones afectadas
Empiezan los problemas: todo intento de conexión a la base de datos con la contraseña anterior se ve impedido, interrumpiendo así la disponibilidad de las aplicaciones.
java.sql.SQLException: ORA-01017: invalid username/password; logon deniedActualizar contraseñas
Se inicia una carrera contra el tiempo para actualizar las contraseñas en todos los archivos de configuración de las aplicaciones, a fin de minimizar el tiempo de indisponibilidad de las aplicaciones.
<Resource
name="jdbc/myoracle"
auth="Container"
type="javax.sql.DataSource"
username="webapp"
password="brandNewPass"
driverClassName="oracle.jdbc.OracleDriver"
url="jdbc:oracle:thin:@server1:1521:db1"
/>3
Cambio gradual de contraseñas
En este punto ya nos queda claro que al cambiar la contraseña de un usuario de base de datos asociado a una aplicación, ésta se ve afectada y deja de brindar servicio mientras no se actualice su configuración para reflejar la nueva contraseña.
Afortunadamente desde Oracle Server 19.12 es posible superar este problema y lograr que el servicio se siga brindando de forma ininterrumpida.
Esto se logra permitiendo que la antigua contraseña siga vigente durante un intervalo definido, es decir: ¡para un mismo usuario de base de datos existen 2 contraseñas válidas simultáneamente!
Sin más preludio, veamos cómo lograrlo.
Cambios en profile
Para poder permitir que las aplicaciones usen la contraseña antigua y la nueva, se requiere de modificar el profile webuser, asociado al usuario webapp, asignando un valor mayor a cero al parámetro password_rollover_time.
alter profile webuser password_rollover_time 3/24;
Los valores permitidos para este parámetro van desde 0 (valor por defecto) hasta 60, expresado en días.
El mínimo aceptado es una hora, que viene a ser 1/24, pero para nuestro ejemplo hemos considerado un límite de 3 horas.
1
2
Contraseña modificada
Procedemos a cambiar la contraseña del usuario de base de datos empleado por las aplicaciones, al valor brandNewPass.
SQL> alter user webapp identified by brandNewPass;Actualizar contraseñas
Las aplicaciones siguen brindando servicio ininterrumpido.
Podemos ir actualizando gradualmente la contraseña del usuario de base de datos en todos los archivos de configuración de las aplicaciones.
<Resource
name="jdbc/myoracle"
auth="Container"
type="javax.sql.DataSource"
username="webapp"
password="brandNewPass"
driverClassName="oracle.jdbc.OracleDriver"
url="jdbc:oracle:thin:@server1:1521:db1"
/>3
4
Continúa la actualización
Siempre que no se supere el período establecido, podemos seguir actualizando las contraseñas en las aplicaciones, y estas siguen brindando servicio ininterrumpido.
<Resource
name="jdbc/myoracle"
auth="Container"
type="javax.sql.DataSource"
username="webapp"
password="brandNewPass"
driverClassName="oracle.jdbc.OracleDriver"
url="jdbc:oracle:thin:@server1:1521:db1"
/>Consideraciones adicionales
1. Período superado
Si transcurridas las 3 horas que pusimos de límite en nuestro ejemplo, quedaron aplicaciones sin actualizar, a partir de ese momento sus intentos de conexión con la contraseña anterior se verán impedidos, con el error ORA-01017.
java.sql.SQLException: ORA-01017: invalid username/password; logon denied2. Oracle Data Guard
En una configuración con Oracle Data Guard, en la que la base de datos standby permite conexiones de solo lectura, si el primer intento de conexión se da luego de las 3 horas que establecimos de límite en nuestro ejemplo, este será denegado con el error ORA-16000.
ORA-16000: database or pluggable database open for read-only accessPara evitar que esto ocurra se debe modificar el parámetro de instancia adg_account_info_tracking al valor global (requiere reinicio).
SQL> alter system set adg_account_info_tracking=global scope=spfile;3. Adelantar la exigencia de la nueva contraseña
Si deseamos que de forma inmediata solo se acepten conexiones con la nueva contraseña, tendremos que ejecutar el siguiente comando.
SQL> alter user webapp expire password rollover period;Conclusiones
Siguiendo un procedimiento bastante simple, ahora es posible que las aplicaciones sigan utilizando la contraseña anterior, mientras que la nueva contraseña va siendo actualizada en los archivos de configuración.
Lo que tradicionalmente implicaba un alto impacto a la disponibilidad de las aplicaciones, ¡ya no lo es más!