Il y a environ un an et demi, j'ai déménagé dans une nouvelle entreprise et j'ai commencé à travailler en tant que DBA. La société n'appliquait auparavant aucun correctif à aucune base de données Oracle. Depuis que je suis ici, j'ai vu la sécurité des systèmes informatiques devenir davantage un point central et faire l'objet d'un examen plus minutieux qu'auparavant. Plutôt que d'attendre une directive pour commencer à mettre en place des correctifs de sécurité réguliers pour nos bases de données Oracle, j'ai décidé d'être proactif. Le jour viendra où nous devrons commencer à corriger régulièrement nos bases de données Oracle et je voudrais dire que nous l'avons déjà implémenté.
Le processeur Apr2012 vient de sortir la semaine dernière et c'est le premier processeur que nous appliquerons à nos bases de données Oracle. Avant d'appliquer le premier processeur, j'ai réfléchi un peu à la manière d'implémenter ce changement dans notre environnement d'entreprise. J'ai décidé de partager quelques-uns de ces changements au cas où quelqu'un d'autre se retrouverait dans une situation similaire à l'avenir.
1. Les 3 D :avant le début de tout correctif, une politique de correctif a été documentée, diffusée au personnel informatique et à la direction, et discutée. Ce document a discuté à un niveau élevé de la nécessité de correctifs de sécurité réguliers, du moment où les correctifs de sécurité seraient publiés et de la manière dont ils seraient appliqués à nos systèmes afin de réduire les risques pour la base de données, l'application et les utilisateurs finaux.
2. Patch Timeline - J'ai le luxe d'avoir un clone de notre base de données de production uniquement pour l'utilisation du DBA et de personne d'autre. Ma chronologie commence là. Dans la semaine suivant la sortie du processeur, je dois appliquer le processeur à ma base de données DBA et résoudre tous les problèmes. À deux semaines de la sortie du processeur, je dois appliquer le correctif à nos bases de données de développement. Dans un délai d'un mois après la sortie du processeur, je dois appliquer le correctif à la base de données Test et Stage. Et enfin, dans les 6 semaines suivant la sortie du CPU, je dois avoir appliqué le correctif à la production. Ce n'est que ma chronologie et ce qui fonctionne dans notre environnement. Votre calendrier peut être différent. Mais il est important que tout le monde comprenne la chronologie et que la chronologie fasse deux choses apparemment contradictoires - 1) applique le correctif lentement afin que tout problème de base de données ou d'application soit résolu avant de passer à l'étape suivante de la chronologie. Une fois que le patch est en production, il ne devrait y avoir aucune surprise et la certitude que le patch ne cassera rien. 2) applique le correctif suffisamment rapidement pour que les failles de sécurité soient colmatées dans un délai raisonnable. Dans mon environnement, six semaines de production sont suffisamment lentes pour détecter les problèmes, mais à peu près aussi rapides que nous nous sentons à l'aise. Votre environnement peut avoir d'autres délais.
3. Log It - Je suis convaincu que les correctifs devraient être documentés dans une sorte de journal des modifications. Avec le journal, vous devriez pouvoir revenir en arrière et voir exactement quand chaque correctif a été appliqué à chaque base de données. Cela peut grandement aider à diagnostiquer si un correctif est responsable d'un problème. Si je reçois un ticket indiquant qu'une procédure reçoit des erreurs et que le problème a été noté pour la première fois le 1er mai, je peux consulter le journal des modifications. Si j'ai appliqué le correctif le 30 avril, le correctif a peut-être introduit le problème. Mais si j'ai appliqué le patch le 2 mai et que le problème existait un jour plus tôt, alors le patch n'est pas la cause du problème. Certaines organisations ont déjà mis en place un mécanisme de contrôle des modifications et le journal des correctifs Oracle doit s'intégrer dans cette structure.
4. Test/Test/Test – En tant que DBA, nous avons le devoir de nous assurer que les changements introduits dans la production ont un haut degré de confiance que l'application ne se cassera pas. Il est extrêmement important de tester vos modifications et les correctifs ne sont pas différents. Si vous ne parcourez pas la chronologie de votre patch, vous n'aurez pas suffisamment de temps pour tester et s'il y a un problème que le patch a introduit dans votre environnement, ce serait un suicide de carrière si vous n'aviez pas suffisamment testé avant de passer en production.
5. Sauvegardes - Il faut sauvegarder la base de données et le répertoire d'accueil Oracle corrigé avant d'appliquer le correctif. Vous ne savez jamais si vous devrez revenir à un point précédent avant le patch dans l'un ou les deux de ces domaines. Il convient de temps en temps de tester la méthodologie de restauration ou de sauvegarder les correctifs bien avant la production. Ce test ne doit pas nécessairement être effectué une fois par trimestre, mais devrait être effectué au moins une fois par an.
Je pense que ceux-ci couvrent les principales réflexions que j'avais sur le sujet. Si vous avez des questions/commentaires, faites le moi savoir.
