Patch ve configuration drift ayrı başlıklar gibi görünür ama aynı soruya dayanır. Çalışan sistemler, bildiğiniz ve onayladığınız durumda mı. Patch, bilinen bir açığı kapatan güncellemedir. Configuration drift ise sistemlerin zaman içinde tanımlı yapılandırmadan haberiniz olmadan uzaklaşmasıdır. Yamayı uyguladığınız bir sunucu, elle değiştirilmiş bir ayar yüzünden hâlâ riskli olabilir. Bu yüzden iki kontrol aynı envanterden ve aynı kayıt düzeninden beslenmelidir. Bu yazı yönetilen bulut servisleri ve operasyon hizmeti sayfasının yama ve yapılandırma tarafını destekler. Kapsam, süre veya sonuç taahhüdü içermez.
Hızlı Özet
Patch kontrolü, hangi sistemin hangi güncelleme seviyesinde olduğunu ve eksiklerin ne zaman kapanacağını gösterir. Drift kontrolü, her sistemin onaylı hedef durumla uyuşup uyuşmadığını gösterir. İkisi için de önce envanter gerekir, çünkü listede olmayan sistem ne yamalanır ne karşılaştırılır. Leon-X bulut altyapısının sahibi değildir. Yama ve yapılandırma sorumluluğunu sorumluluk matrisiyle ayırır ve sağlayıcı dokümantasyonuyla doğrular.
İçindekiler
- Patch Kontrolü Neyi Doğrular
- Configuration Drift Nasıl Oluşur
- Drift Nasıl Tespit Edilir
- Patch ve Drift Kaydı Nasıl Birleşir
- Sorumluluk Nerede Ayrılır
- Yaygın Hatalar
- Kontrol Listesi
- Leon-X ile Sonraki Adım
- Sık Sorulan Sorular
- Sonuç
- Kaynaklar
Kaynak Wikimedia Commons, Comp lab cables 20171121 131906. Fotoğraf Kbh3rd tarafından çekilmiş olup CC BY 4.0 lisansıyla yayımlanmıştır. Kare, bir bilgisayar ve ağ laboratuvarındaki düzensiz kablolamayı gösterir.
Patch Kontrolü Neyi Doğrular
Patch kontrolü, bir güncellemenin yayımlanmasıyla sistemlerde uygulanması arasındaki farkı yönetir. Tek bir tarama sonucu bu işi yapmaz. Düzenli işleyen bir kontrol şu sorulara cevap verir.
- Hangi sistemler envanterde ve hangi güncelleme seviyesinde
- Hangi güncelleme hangi sistemler için geçerli
- Güncellemenin önceliği nedir ve neye göre belirlendi
- Uygulamadan önce hangi ortamda denendi
- Geri dönüş yolu ve uygulama sonrası doğrulama nedir
Öncelik belirlerken sağlayıcının güvenlik bülteni ve açığın iş yükünüze etkisi birlikte okunur. Açığa erişilebilir bir sistem, yalnızca iç ağdaki bir sistemden daha önce ele alınır. Bu sıralama bir kez yazılırsa her yeni bülten için yeniden tartışılmaz.
Uygulamadan önce bir anlık görüntü almak yaygın bir geri dönüş yoludur. Ancak anlık görüntü yedek değildir ve açık unutulduğunda diski şişirir. Bu konu bulut sunucuda snapshot kullanımı yazısında ayrıntılı anlatılır. Yama sonrası doğrulama tamamlandığında anlık görüntü silinmelidir.
Configuration Drift Nasıl Oluşur
Drift çoğu zaman kötü niyetten değil, iyi niyetli kısa yollardan doğar.
Bir olay sırasında bir ayar elle değiştirilir ve olay bittikten sonra eski haline döndürülmez. Bir sunucu otomasyon dışında, doğrudan bağlanılarak yapılandırılır. Aynı rolü taşıyan iki sunucudan biri güncellenir, diğeri unutulur. Test ve üretim ortamları zamanla farklı ayarlara kavuşur ve test sonuçları üretimi temsil etmez.
Bu sapmaların her biri tek başına küçük görünür. Birikince aynı uygulamanın iki sunucuda farklı davranmasına, yamanın bir sunucuda çalışıp diğerinde çalışmamasına ve güvenlik ayarlarının bir kısmının sessizce zayıflamasına yol açar.
Drift Nasıl Tespit Edilir
Drift'i görmek için önce bir hedef durum gerekir. Hedef durum, bir sistemin olması gereken ayarlarının yazılı ya da şablon halinde tanımlanmasıdır. Tanım yoksa karşılaştırılacak bir şey de yoktur.
Hedef durum tanımlandıktan sonra üç adım yeterlidir.
- Sistemlerin gerçek yapılandırması düzenli aralıklarla okunur.
- Okunan değerler hedef durumla karşılaştırılır.
- Fark çıkan her kalem ya düzeltilir ya da gerekçeli bir istisna olarak kaydedilir.
Üçüncü adım önemlidir. Her fark hata değildir. Bazen bir istisna bilinçli seçilmiştir. Ama bu seçimin kaydı yoksa bir sonraki denetimde yine fark olarak çıkar ve kimse nedenini hatırlamaz. İstisna kaydı sahibini, gerekçesini ve gözden geçirme tarihini taşımalıdır.
Hedef durumu kod olarak tutan ekipler karşılaştırmayı otomatikleştirebilir. Elle yönetilen ortamlarda aynı mantık bir kontrol tablosuyla da uygulanır. Önemli olan karşılaştırmanın düzenli yapılması ve sonucunun kayıt altına alınmasıdır.
Patch ve Drift Kaydı Nasıl Birleşir
İki kontrol aynı değişiklik numarasıyla bağlandığında birbirini tamamlar. Bir yama uygulandığında değişiklik kaydı açılır. Yamadan sonra aynı sistem için drift karşılaştırması yapılır. Böylece yamanın bir ayarı sıfırlayıp sıfırlamadığı, hedef durumdan sapma yaratıp yaratmadığı görülür.
Tersi de geçerlidir. Bir drift kalemi düzeltilirken yapılan değişiklik de kayda girer. Bu düzen, olay anında hangi değişikliğin ne zaman yapıldığını tek zaman çizgisinde okumaya yarar. İzleme tarafında aynı kayıt numarasının nasıl kullanıldığı managed cloud izleme temelleri yazısında anlatılır.
Sorumluluk Nerede Ayrılır
Yama ve yapılandırma kimin işi sorusunun tek cevabı yoktur. Platform katmanının güncellenmesi bulut sağlayıcıya aittir. Sanal makinenin işletim sistemi ve üzerindeki yazılım ise kullanım modeline göre kuruma ya da yönetilen hizmete düşer. Bu çizgi bulut sunucunun operasyon modeli yazısında ve yönetilen bulut sorumluluk matrisi yazısında ele alınır.
Yama için özellikle şu üç sahip ayrı yazılmalıdır. Yamayı kim uyguluyor, uygulama testini kim yapıyor ve başarısız olan yamanın geri alınmasına kim karar veriyor. Test sahibi belli değilse yama sırada beklerken sistem açık kalır. Yama yönetiminin daha geniş bir uygulama planı için zafiyet ve yama yönetimi rehberine bakabilirsiniz.
Yaygın Hatalar
Envanterde olmayan sistemi yamalamak mümkün değildir. Bu yüzden eksik envanter, iki kontrolün de en sık kırıldığı yerdir.
Yamayı doğrudan üretimde denemek ve geri dönüş yolunu önceden yazmamak, başarısız yama sonrasında uzun bir kesintiye yol açabilir.
Hedef durumu tanımlamadan drift taraması yapmak, çıkan farkların hangisinin hata olduğunu cevapsız bırakır.
Acil müdahalede yapılan elle değişikliği kayda geçirmemek, drift'in en yaygın kaynağıdır. Olay kapandığında bu değişikliğin geri alınması ya da hedef duruma işlenmesi için bir iş kaydı açılmalıdır.
İstisnaları sahipsiz bırakmak da sık yapılır. Gözden geçirme tarihi olmayan istisna zamanla kalıcı hale gelir.
Kontrol Listesi
- Tüm sistemler envanterde ve güncelleme seviyesi biliniyor mu
- Yama önceliği için yazılı bir ölçüt var mı
- Yama önce test ortamında deneniyor mu
- Geri dönüş yolu ve uygulama sonrası doğrulama yazılı mı
- Anlık görüntü doğrulamadan sonra siliniyor mu
- Her sistem rolü için hedef durum tanımlı mı
- Hedef durum karşılaştırması düzenli aralıkla yapılıyor mu
- İstisnaların sahibi, gerekçesi ve gözden geçirme tarihi var mı
- Yama ve drift düzeltmeleri aynı değişiklik numarasıyla kayda giriyor mu
Leon-X ile Sonraki Adım
Leon-X mevcut bulut ortamınızdaki envanteri, yama düzenini ve yapılandırma hedef durumunu birlikte inceler. Hangi sistemlerin karşılaştırma dışında kaldığını, hangi istisnaların sahipsiz olduğunu ve yama testinin kimde olduğunu listeler. Kapsam ve düzen ortamınıza göre netleşir. Sağlayıcıya ait ayrıntılar resmi dokümantasyonla doğrulanır. Ayrıntılar yönetilen bulut servisleri ve operasyon hizmeti sayfasında yer alır. Keşif için iletişime geçin.
Sık Sorulan Sorular
Configuration drift ile yama eksikliği aynı şey mi?
Hayır. Yama eksikliği, yayımlanmış bir güncellemenin uygulanmamasıdır. Drift ise yapılandırmanın onaylı hedef durumdan sapmasıdır. Biri yazılım sürümünü, diğeri ayarları ilgilendirir. İkisi birlikte sistemin gerçek riskini belirler.
Drift taraması için hedef durum şart mı?
Evet. Karşılaştırılacak bir tanım olmadan yalnızca sistemler arası farklar görülür ve hangisinin doğru olduğu bilinemez.
Yama sonrası drift kontrolü neden gerekir?
Bazı güncellemeler ayarları varsayılan değerlere döndürebilir. Karşılaştırma bu değişikliği yakalar.
Yönetilen bulutta yamayı sağlayıcı mı uygular?
Bu sözleşmede ve sorumluluk matrisinde yazılır. Platform güncellemesi ile işletim sistemi ve uygulama yamaları ayrı kalemlerdir.
Sonuç
Patch ve configuration drift kontrolü, çalışan sistemlerin bilinen ve onaylı durumda olup olmadığını düzenli sormaktır. Envanter, hedef durum, gerekçeli istisna ve ortak değişiklik kaydı bu sorunun cevabını tutarlı kılar. Kapsam için yönetilen bulut servisleri ve operasyon hizmeti sayfasına bakabilirsiniz.
Kaynaklar
- NIST SP 800-40, kurumsal yama yönetimi planlama rehberi
- NIST SP 800-128, bilgi sistemleri için güvenlik odaklı yapılandırma yönetimi rehberi
- Leon-X, yönetilen bulut servisleri ve operasyon hizmeti
