Çalışırken Çekirdek Yamalama: Yeniden Başlatmadan Güvenlik Güncellemesi
Kritik bir çekirdek açığı duyuruldu ve yama yayımlandı. Ama yamayı uygulamak için sunucuyu yeniden başlatmanız gerekiyor ve bu, saatlerce planlanmış bir kesinti demek. Bu ikilem her güvenlik duyurusunda tekrarlanır.
Bu yazı, yeniden başlatmasız çekirdek yamalamayı ele alıyor.
Neden Yeniden Başlatma Gerekir
- Çekirdek bellekte çalışır.
- Yeni sürüm diske yazılır.
- Bellekteki eski sürüm çalışmaya devam eder.
Üçüncü adım çok yaygın bir yanılgıyı düzeltir: paket güncellemesi yapmak çekirdeği güncellemez, yalnızca yeni sürümü diske yazar — sistem yeniden başlatılana kadar eski ve açık barındıran çekirdek çalışmaya devam eder.
Yönetici güncellemeyi yaptığını sanır ama sunucu hâlâ savunmasızdır.
Çalışan çekirdek sürümünü kontrol etmek bu yanılgıyı ortadan kaldırır.
Bu kontrol, güncelleme sonrası rutin olmalıdır.
Canlı Yamalama Nasıl Çalışır
- Yama bir modül olarak yüklenir.
- Hatalı fonksiyon yönlendirilir.
- Yeni çağrılar düzeltilmiş koda gider.
İkinci madde tekniğin özüdür: canlı yamalama çekirdeği değiştirmez, açık barındıran fonksiyona giden çağrıları düzeltilmiş bir kopyaya yönlendirir — çalışan sistem hiç durmaz.
Yönlendirme, o fonksiyon o an kullanılmıyorken yapılır.
Bu nedenle uygulama anı sistem tarafından seçilir.
İşlem saniyeler sürer ve fark edilmez.
Neler Yamalanamaz
| Değişiklik türü | Canlı yamalama |
|---|---|
| Fonksiyon içi düzeltme | Uygulanabilir |
| Veri yapısı değişikliği | Genellikle uygulanamaz |
| Yeni sürüme geçiş | Uygulanamaz |
| Donanım desteği ekleme | Uygulanamaz |
İkinci satır tekniğin temel sınırını gösterir: bellekteki veri yapılarını değiştiren bir düzeltme canlı olarak uygulanamaz — çünkü çalışan sistemdeki mevcut yapıları dönüştürmek mümkün değildir.
Bu tür yamalar yine yeniden başlatma gerektirir.
Üçüncü satır ise en önemli beklenti düzeltmesidir.
Canlı yamalama, sürüm yükseltmenin yerine geçmez.
Yamalar Birikir
- Her yama üst üste eklenir.
- Karmaşıklık artar.
- Bir noktada yeniden başlatma gerekir.
Üçüncü madde gerçekçi bir planlama gerektirir: canlı yamalama yeniden başlatmayı ortadan kaldırmaz, erteler — birikmiş yamalar bir noktada temiz bir başlangıç gerektirir ve bu, planlı bir bakım penceresiyle yapılmalıdır.
Erteleme süresi genellikle aylarla ölçülür.
Bu süre, kesintinin uygun bir zamana alınmasını sağlar.
Asıl kazanç, acil kesinti yerine planlı kesinti yapabilmektir.
Kimler İçin Uygun
- Kesintiye tahammülü olmayan sistemler.
- Tek sunuculu kritik servisler.
- Bakım penceresi bulmakta zorlananlar.
İkinci madde en net faydayı görür: yedekli bir yapıda sunucular sırayla yeniden başlatılabildiği için canlı yamalamaya ihtiyaç azdır — asıl fayda, yedeği olmayan tek sunuculu kritik sistemlerdedir.
Yedekli mimari, bu ihtiyacı büyük ölçüde ortadan kaldırır.
Üçüncü madde ise yoğun çalışan işletmeler için geçerlidir.
Yirmi dört saat hizmet veren sistemlerde uygun pencere bulmak zordur.
Doğrulama
| Kontrol | Ne gösterir |
|---|---|
| Çalışan çekirdek sürümü | Temel sürüm |
| Yüklü yamalar listesi | Uygulanan düzeltmeler |
| Açık tarama sonucu | Kalan riskler |
Üçüncü satırda dikkat gerektiren bir durum vardır: güvenlik tarayıcıları genellikle yalnızca çekirdek sürüm numarasına bakar ve canlı yamalanmış bir sistemi savunmasız olarak raporlar — bu yanlış pozitif, denetim süreçlerinde açıklama gerektirir.
Yüklü yama listesi bu durumda kanıt olur.
İkinci satır ise hangi açıkların kapatıldığını belgeler.
Bu kayıt, uyum denetimlerinde saklanmalıdır.
Riskler
- Yama hatalı olabilir.
- Geri alma mümkündür.
- Önce test ortamında denenmeli.
İkinci madde önemli bir güvence sağlar: canlı yama bir modül olduğu için sorun çıkarsa kaldırılabilir ve sistem eski davranışına geri döner — bu, çekirdek sürümü yükseltmekten daha az riskli bir işlemdir.
Geri alma da yeniden başlatma gerektirmez.
Üçüncü madde ise her değişiklik için geçerli olan temel kuraldır.
Üretim öncesi doğrulama atlanmamalıdır.
Alternatif Yaklaşım
- Yedekli mimari kurmak.
- Sunucuları sırayla güncellemek.
- Kesintisiz güncelleme sağlamak.
Bu üçlü, uzun vadede daha sağlam bir çözümdür: iki sunuculu bir yapıda trafiği birinden diğerine alıp sırayla güncellemek, hem çekirdek hem uygulama güncellemelerini kesintisiz yapmayı sağlar — canlı yamalama ise yalnızca çekirdek için çalışır.
Yedekli yapı ayrıca donanım arızasına karşı da korur.
Maliyeti ise ikinci sunucudur.
Karar, kesinti maliyeti ile donanım maliyeti karşılaştırılarak verilir.
Çekirdek düzeyinde müdahale ve yama yönetimi tam yönetici yetkisi gerektirir; fiziksel sunucu hizmet paketleri ile güncelleme politikanızı kendiniz belirleyebilirsiniz.
Sonuç
Önce yaygın bir yanılgıyı düzeltin: paket güncellemesi çekirdeği güncellemez, yalnızca yeni sürümü diske yazar — sistem yeniden başlatılana kadar açık barındıran çekirdek çalışır. Canlı yamalama bu boşluğu kapatır ama sınırlıdır: veri yapısı değiştiren düzeltmeler uygulanamaz ve yeniden başlatmayı ortadan kaldırmaz, erteler. Uzun vadeli çözüm yedekli mimaridir.
Sıkça Sorulan Sorular (SSS)
Paketi güncelledim, açık kapandı mı?
Hayır. Paket güncellemesi yeni çekirdeği yalnızca diske yazar; sistem yeniden başlatılana kadar eski ve açık barındıran çekirdek bellekte çalışmaya devam eder. Güncelleme sonrası çalışan çekirdek sürümünü kontrol etmeyi rutin hâline getirin.
Canlı yamalama neyi değiştiriyor?
Çekirdeği değiştirmez; açık barındıran fonksiyona giden çağrıları düzeltilmiş bir kopyaya yönlendirir. Yönlendirme, o fonksiyon kullanılmıyorken yapılır, saniyeler sürer ve çalışan sistem hiç durmaz.
Her yama canlı uygulanabilir mi?
Hayır. Bellekteki veri yapılarını değiştiren düzeltmeler uygulanamaz çünkü çalışan sistemdeki mevcut yapıları dönüştürmek mümkün değildir. Sürüm yükseltme ve donanım desteği eklemek de yeniden başlatma gerektirir.
Güvenlik tarayıcısı hâlâ açık gösteriyor?
Tarayıcılar genellikle yalnızca çekirdek sürüm numarasına bakar ve canlı yamalanmış sistemi savunmasız raporlar. Bu bir yanlış pozitiftir; yüklü yama listesi denetimlerde kanıt olarak kullanılır ve saklanmalıdır.
