Hace aproximadamente un año y medio, me mudé a una nueva empresa y comencé a trabajar como su DBA. La empresa no aplicó previamente ningún parche a ninguna base de datos de Oracle. Desde que estoy aquí, he visto que la seguridad del sistema de TI se ha convertido más en un punto de enfoque y se somete a un nivel de escrutinio más alto que el visto anteriormente. En lugar de esperar una directiva para comenzar a implementar parches de seguridad regulares para nuestras bases de datos de Oracle, decidí ser proactivo. Llegará el día en que se nos requiera comenzar a parchear nuestras bases de datos Oracle de manera regular y me gustaría decir que ya lo tenemos implementado.
La CPU de abril de 2012 se lanzó la semana pasada y esta es la primera CPU que aplicaremos a nuestras bases de datos de Oracle. Antes de aplicar la primera CPU, pensé un poco en cómo implementar este cambio en nuestro entorno corporativo. Decidí compartir algunos de esos cambios en caso de que alguien más tenga una situación similar en el futuro.
1. Las 3 D:antes de que comenzara cualquier aplicación de parches, se documentó una política de parches, se difundió al personal y la administración de TI y se discutió. Este documento discutió a un alto nivel la necesidad de parches de seguridad regulares, cuándo saldrían los parches de seguridad y cómo se aplicarían a nuestros sistemas para reducir el riesgo para la base de datos, la aplicación y los usuarios finales.
2. Línea de tiempo de parches:tengo el lujo de tener un clon de nuestra base de datos de producción solo para uso del DBA y de nadie más. Mi línea de tiempo comienza allí. Dentro de una semana del lanzamiento de la CPU, debo aplicar la CPU a mi base de datos DBA y resolver cualquier problema. Con dos semanas del lanzamiento de la CPU, debo aplicar el parche a nuestras bases de datos de desarrollo. Dentro de un mes del lanzamiento de la CPU, debo aplicar el parche a la base de datos Test and Stage. Y finalmente, dentro de las 6 semanas posteriores al lanzamiento de la CPU, debo haber aplicado el parche a la producción. Esta es solo mi línea de tiempo y lo que funciona en nuestro entorno. Su línea de tiempo puede ser diferente. Pero es importante que todos entiendan la línea de tiempo y que la línea de tiempo hace dos cosas aparentemente contradictorias:1) aplica el parche lentamente para que cualquier problema de base de datos o aplicación se resuelva antes de continuar con el siguiente paso en la línea de tiempo. Una vez que el parche llegue a la producción, no debería haber sorpresas y confiar en que el parche no romperá nada. 2) aplica el parche lo suficientemente rápido como para tapar los agujeros de seguridad en un tiempo razonable. En mi entorno, seis semanas hasta la producción es lo suficientemente lento como para detectar problemas, pero tan rápido como nos sentimos cómodos. Su entorno puede tener otras líneas de tiempo.
3. Regístrelo:creo firmemente que los parches deben documentarse en algún tipo de registro de cambios. Con el registro, debería poder volver atrás y ver exactamente cuándo se aplicó cada parche a cada base de datos. Esto puede ayudar mucho a diagnosticar si un parche fue el responsable de un problema. Si recibo un ticket de que un procedimiento recibe errores y el problema se notó por primera vez el 1 de mayo, entonces puedo ver el registro de cambios. Si apliqué el parche el 30 de abril, es posible que el parche haya introducido el problema. Pero si apliqué el parche el 2 de mayo y el problema existía un día antes, entonces el parche no es la causa del problema. Algunas organizaciones ya cuentan con un mecanismo de control de cambios y el registro de parches de Oracle debe encajar dentro de esa estructura.
4. Prueba/Prueba/Prueba:como DBA, tenemos el deber de garantizar que los cambios introducidos en la producción tengan un alto grado de confianza de que la aplicación no se romperá. Es de vital importancia probar sus cambios y los parches no son diferentes. Si no revisa la línea de tiempo de su parche, no tendrá el tiempo adecuado para probar y si hay un problema que el parche ha introducido en su entorno, sería un suicidio profesional si no hiciera una prueba adecuada antes de pasar a la producción.
5. Copias de seguridad:se debe hacer una copia de seguridad de la base de datos y del directorio de inicio de Oracle que se está parcheando antes de aplicar el parche. Nunca se sabe si tendrá que volver a un punto anterior antes del parche en una o ambas áreas. De vez en cuando, se debe probar la metodología de restauración o retirar los parches mucho antes de la producción. Es posible que esta prueba no necesariamente deba realizarse una vez por trimestre, pero debe hacerse al menos una vez al año.
Creo que esos sobre cubren los principales pensamientos que tenía sobre el tema. Si tiene preguntas/comentarios, hágamelo saber.
