Belajar System Engineer - Patch & Vulnerability Management

#Pendahuluan

Setelah episode 16 mengoptimalkan performa, sekarang kita membahas aspek yang sering bertabrakan dengan stabilitas: patch management. Server yang tidak pernah di-update adalah bom waktu — kerentanan yang diketahui publik bisa dieksploitasi begitu saja. Tapi server yang di-patch tanpa perencanaan juga berbahaya: update yang gagal atau merusak aplikasi bisa menumbangkan layanan.

Mengapa episode ini penting? Karena patch management adalah disiplin keseimbangan: keamanan vs ketersediaan. System Engineer yang baik bukan yang paling sering meng-update, melainkan yang paling terencana — tahu apa yang dipatch, mengapa, kapan, dan bagaimana memverifikasi. Episode ini membangun siklus hidup patch yang lengkap, dari pelacakan CVE sampai maintenance window.

#Siklus Hidup Patch

#Tahapan

#1. Temukan CVE

CVE (Common Vulnerabilities and Exposures) adalah identifikasi publik untuk kerentanan. Skor keparahannya dinilai lewat CVSS (0-10). Sumber informasi yang wajib diikuti:

• NVD (National Vulnerability Database) — database CVE resmi.
• Vendor advisories — email/situs Ubuntu Security, Red Hat CVE, Microsoft.
• OSV — feed kerentanan untuk open source.
• Scanner otomatis — Trivy, Grype, OpenVAS (akan dibahas nanti).

Cek kerentanan paket yang terinstall di sistem:

# Debian/Ubuntu
ubuntu-security-status
# RHEL/Rocky
dnf updateinfo list
# Opsi CLI umum (jika diinstall)
trivy image ghcr.io/corp/app-web:1.4.2
trivy fs /srv/app

#2. Prioritaskan

Tidak semua CVE sama. Matriks prioritas sederhana:

Kuncinya konteks: CVE kritis di komponen yang tidak terinstall = tidak relevan. CVE rendah di komponen yang terpapar publik tanpa mitigasi = tetap harus segera ditangani.

#3. Test di Staging

Jangan pernah langsung patch produksi. Siklus yang benar:

1. Terapkan di staging (mirror produksi).
2. Jalankan test smoke: service up, aplikasi merespons, log bersih.
3. Baru terapkan di produksi dalam maintenance window.

#4. Terapkan di Maintenance Window

Maintenance window adalah jendela waktu yang disepakati untuk perubahan sistem. Kapan yang baik?

• Jam trafik terendah untuk layanan tersebut.
• Tidak bersamaan dengan event bisnis penting.
• Didokumentasikan dan dikomunikasikan ke pemilik layanan.

Eksekusi patch di Debian/Ubuntu dan RHEL/Rocky:

# Debian/Ubuntu
sudo apt update
sudo apt upgrade -y
sudo reboot   # jika ada kernel update
 
# RHEL/Rocky
sudo dnf update -y
sudo reboot

#5. Verifikasi & Monitor

Patch selesai bukan akhir. Verifikasi:

# 1. Sistem berjalan normal
uptime && systemctl is-system-running
 
# 2. Kernel terbaru benar-benar aktif
uname -r
 
# 3. Service inti tetap hidup
systemctl list-units --type=service --state=failed
 
# 4. Uji aplikasi
curl -s -o /dev/null -w "%{http_code}\n" http://localhost/healthz

Perhatikan: setelah apt upgrade, kernel baru hanya aktif setelah reboot. Jangan berasumsi kernel sudah berubah hanya karena paket ter-update.

#Otomasi Patch

#unattended-upgrades (Debian/Ubuntu)

Untuk patch keamanan otomatis, Debian/Ubuntu menyediakan unattended-upgrades:

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}${distro_codename}-updates";
};
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

Prinsipnya: otomatiskan patch keamanan, tetapi kelola update besar (minor/major) melalui maintenance window manual yang terencana.

#Patch di Kubernetes

Untuk K8s, patch dikelola per lapisan:

• Node: kubectl drain (episode 15), upgrade sistem, uncordon.
• Workload image: bump versi image + rollout (episode 15).
• Cluster: upgrade versi K8s sesuai EOL timeline vendor.

#Pelaporan dan Dokumentasi

Jejak audit patch diperlukan untuk compliance (episode 20). Simpan:

• Tanggal dan daftar paket yang di-update per server.
• CVE yang ditangani dan yang ditunda beserta alasannya.
• Hasil verifikasi (output check di atas).
• Approval dari pemilik layanan untuk maintenance window.

# Daftar paket yang bisa di-update (untuk laporan bulanan)
apt list --upgradable

#Kesalahan Umum

1. Patch tanpa snapshot/backup — tidak ada jalan kembali saat patch merusak sistem.
2. Langsung patch produksi tanpa test staging — kejutan di jam kerja.
3. Reboot tidak direncanakan — kernel tidak aktif sampai reboot; jadwalkan dengan jelas.
4. Patch keamanan tidak otomatis — server terpapar CVE kritis selama berhari-hari.
5. Tidak mencatat penundaan patch — auditor bertanya "kenapa CVE kritis belum di-patch?" dan tidak ada jawaban.

#Penutup

Inti yang harus dibawa pulang:

• Siklus: temukan CVE → prioritaskan (CVSS + konteks) → test staging → terapkan → verifikasi → dokumentasikan.
• Snapshot/backup sebelum patch, maintenance window yang jelas, dan verifikasi (uname -r, failed units).
• Otomasi patch keamanan dengan unattended-upgrades; update besar manual dan terencana.
• K8s dipatch per lapisan: node (drain), image (rollout), cluster (upgrade).

Di episode 18 selanjutnya kita mengeraskan sistem yang sudah aman: system hardening — CIS benchmarks, SELinux/AppArmor, dan minimal install. Sampai jumpa di episode 18!