Sekitar satu setengah tahun yang lalu, saya pindah ke perusahaan baru dan mulai bekerja sebagai DBA mereka. Perusahaan sebelumnya tidak menerapkan tambalan apa pun ke database Oracle mana pun. Sejak saya di sini, saya telah melihat keamanan sistem TI menjadi lebih fokus dan menjalani tingkat pengawasan yang lebih tinggi dari sebelumnya. Daripada menunggu arahan untuk mulai menerapkan patch keamanan reguler untuk database Oracle kami, saya memutuskan untuk proaktif. Harinya akan tiba ketika kita diminta untuk mulai menambal database Oracle kita secara teratur dan saya ingin mengatakan bahwa kita sudah menerapkannya.
CPU Apr2012 baru saja dirilis minggu lalu dan ini adalah CPU pertama yang akan kami terapkan ke database Oracle kami. Sebelum saya menerapkan CPU pertama, sedikit pemikiran tentang bagaimana menerapkan perubahan ini di lingkungan perusahaan kami. Saya memutuskan untuk membagikan beberapa perubahan itu jika ada orang lain yang mengalami situasi serupa di masa mendatang.
1. The 3 D's:Sebelum patching dimulai, kebijakan patch Didokumentasikan, Disosialisasikan kepada staf dan manajemen TI, dan Dibahas. Dokumen ini membahas pada tingkat tinggi, perlunya patch keamanan reguler, kapan patch keamanan akan keluar, dan bagaimana patch tersebut akan diterapkan pada sistem kami untuk mengurangi risiko pada database, aplikasi, dan pengguna akhir.
2. Patch Timeline – Saya memiliki kemewahan memiliki tiruan dari basis data produksi kami hanya untuk penggunaan DBA dan tidak untuk orang lain. Garis waktu saya dimulai dari sana. Dalam satu minggu setelah rilis CPU, saya akan menerapkan CPU ke database DBA saya dan menyelesaikan masalah apa pun. Dengan dua minggu rilis CPU, saya akan menerapkan patch ke database pengembangan kami. Dalam satu bulan setelah rilis CPU, saya akan menerapkan patch ke database Test and Stage. Dan akhirnya, dalam waktu 6 minggu setelah rilis CPU, saya telah menerapkan patch ke produksi. Ini hanya timeline saya dan apa yang berhasil di lingkungan kita. Garis waktu Anda mungkin berbeda. Tetapi penting bagi setiap orang untuk memahami garis waktu dan bahwa garis waktu melakukan dua hal yang tampaknya bertentangan – 1) menerapkan tambalan secara perlahan sehingga masalah basis data atau aplikasi apa pun diselesaikan sebelum melanjutkan ke langkah berikutnya di garis waktu. Setelah tambalan mencapai produksi, seharusnya tidak ada kejutan dan keyakinan bahwa tambalan tidak akan merusak apa pun. 2) menerapkan tambalan cukup cepat sehingga lubang keamanan terpasang dalam waktu yang wajar. Di lingkungan saya, enam minggu untuk produksi cukup lambat untuk menangkap masalah tetapi secepat kami merasa nyaman untuk melakukannya. Lingkungan Anda mungkin memiliki jadwal lain.
3. Log It – Saya sangat yakin bahwa patch harus didokumentasikan dalam semacam log perubahan. Dengan log, Anda seharusnya dapat kembali dan melihat dengan tepat kapan setiap patch diterapkan ke setiap database. Ini bisa sangat membantu dalam mendiagnosis jika tambalan bertanggung jawab atas suatu masalah. Jika saya mendapatkan tiket bahwa prosedur menerima kesalahan dan masalahnya pertama kali dicatat pada tanggal 1 Mei, maka saya dapat melihat log perubahan. Jika saya menerapkan tambalan pada 30 April, tambalan itu mungkin telah menimbulkan masalah. Tetapi jika saya menerapkan tambalan pada tanggal 2 Mei dan masalah muncul sehari sebelumnya, maka tambalan bukanlah penyebab masalah. Beberapa organisasi telah memiliki mekanisme Kontrol Perubahan dan log patch Oracle harus sesuai dengan struktur tersebut.
4. Test/Test/Test – Sebagai DBA, kami memiliki kewajiban untuk memastikan bahwa perubahan yang diperkenalkan ke dalam produksi memiliki tingkat kepercayaan yang tinggi bahwa aplikasi tidak akan rusak. Sangat penting untuk menguji perubahan Anda dan patch tidak berbeda. Jika Anda tidak melalui timeline patch Anda, Anda tidak akan memiliki waktu yang cukup untuk menguji dan jika ada masalah yang patch telah diperkenalkan ke lingkungan Anda, itu akan menjadi bunuh diri karir jika Anda tidak cukup menguji sebelum mencapai produksi.
5. Cadangan – Seseorang harus mencadangkan database dan direktori home Oracle yang ditambal sebelum menerapkan tambalan. Anda tidak pernah tahu apakah Anda harus kembali ke titik sebelumnya sebelum patch di salah satu atau kedua area tersebut. Seseorang harus sesekali menguji metodologi pemulihan atau memundurkan patch jauh sebelum produksi. Pengujian ini mungkin tidak perlu dilakukan sekali dalam seperempat, tetapi harus setidaknya setahun sekali.
Saya pikir itu tentang menutupi pemikiran utama yang saya miliki tentang masalah ini. Jika Anda memiliki pertanyaan/komentar, beri tahu saya.
