Güncellemeler nasıl yönetilmeli? Politika ve süreç.
Güncelleme, sunucu yönetiminin en çok ertelenen ama en kritik işidir. Ertelendiğinde sistem savunmasız kalır; plansız yapıldığında kesinti yaratır.
Çözüm, yazılı bir politikadır.
Neden politika gerekir?
- Kim yapacak sorusu netleşir
- Ne zaman yapılacağı öngörülebilir olur
- Riskli güncellemeler test edilir
- Kesintiler planlı olur
- Sorun çıktığında geri dönüş yolu bellidir
- Denetimlerde belge sunulur
Güncelleme türleri
| Tür | Aciliyet | Yaklaşım |
|---|---|---|
| Kritik güvenlik yaması | Çok yüksek | En kısa sürede |
| Normal güvenlik yaması | Yüksek | Planlı, kısa vadede |
| Hata düzeltmesi | Orta | Planlı |
| Özellik güncellemesi | Düşük | Değerlendirilerek |
| Büyük sürüm geçişi | Planlı | Proje olarak |
Ayrım önemlidir: Her güncellemeyi aynı süreçle ele almak ya çok yavaş ya çok riskli olur.
Politikada yer alacaklar
1. Sorumluluk
- Güncellemeleri kim yapar?
- Kim onaylar?
- Yedek sorumlu kim?
- Dış hizmet alınıyorsa kapsam nedir?
2. Takip
- Güvenlik bültenleri nasıl takip edilir?
- Üretici duyuruları kime gelir?
- Ne sıklıkla kontrol edilir?
3. Sınıflandırma
- Kritik yama tanımı
- Her sınıf için azami uygulama süresi
- Öncelik kuralları
4. Test
- Hangi güncellemeler test ortamında denenir?
- Test kapsamı nedir?
- Kritik iş akışları test ediliyor mu?
5. Uygulama
- Bakım penceresi ne zaman?
- Kullanıcılar ne kadar önce bilgilendirilir?
- Öncesinde yedek/anlık görüntü alınır mı?
- Sırayla mı, toplu mu uygulanır?
6. Doğrulama
- Sonrasında ne kontrol edilir?
- Kim doğrular?
- Kayıt tutulur mu?
7. Geri dönüş
- Sorun çıkarsa ne yapılır?
- Kararı kim verir?
- Ne kadar sürede dönülebilir?
Standart güncelleme süreci
- ☐ Güncelleme duyurusu incelendi
- ☐ Etki değerlendirildi
- ☐ Aciliyet sınıfı belirlendi
- ☐ Bakım penceresi planlandı
- ☐ Kullanıcılar bilgilendirildi
- ☐ Tam yedek alındı
- ☐ Anlık görüntü alındı (sanal sunucuda)
- ☐ Test ortamında denendi
- ☐ Kritik iş akışları test edildi
- ☐ Canlıya uygulandı
- ☐ Servisler doğrulandı
- ☐ Uygulamalar test edildi
- ☐ İzleme kontrol edildi
- ☐ Kayıt tutuldu
Yedinci madde sanal ve bulut ortamlarda geri dönüşü dakikalara indirir; mutlaka kullanın.
Kritik yama süreci (hızlandırılmış)
Aktif olarak istismar edilen bir açık için:
- ☐ Etkilenen sistemler belirlendi
- ☐ Geçici azaltma önlemi uygulanabilir mi, bakıldı
- ☐ Anlık görüntü alındı
- ☐ Yama uygulandı
- ☐ Doğrulandı
- ☐ Sonrasında ayrıntılı test yapıldı
Bu durumda test aşaması sonraya bırakılabilir; risk dengesi yamayı geciktirmemeyi gerektirir.
Otomatik güncelleme
| Avantaj | Risk | |
|---|---|---|
| Açık | Güvenlik açıkları hızla kapanır | Bir güncelleme sistemi bozabilir |
| Kapalı | Kontrol sizde | Ertelenir, unutulur |
Dengeli yaklaşım:
- Güvenlik yamaları otomatik uygulansın
- Büyük sürüm geçişleri kontrollü olsun
- Kritik sistemlerde önce test ortamı
- Otomatik güncelleme öncesi anlık görüntü alınsın
- Güncelleme sonrası izleme yakından takip edilsin
Sürüm desteği takibi
- ☐ Kullanılan işletim sistemi sürümleri listelendi
- ☐ Destek bitiş tarihleri öğrenildi
- ☐ Takvime işlendi
- ☐ Yükseltme bütçesi planlandı
- ☐ Uygulama uyumu kontrol edildi
Destek biten bir sistemde çalışmaya devam etmek, orta ölçekli şirketlerde en yaygın güvenlik açığı kaynaklarından biridir.
Güncelleme kaydı
Her güncelleme için kaydedin:
- Tarih ve saat
- Hangi sistem
- Ne güncellendi (sürüm bilgisi)
- Kim yaptı
- Test edildi mi
- Sorun yaşandı mı
- Doğrulama sonucu
Bu kayıt, bir sorun çıktığında "ne değişti?" sorusunu dakikalar içinde cevaplar.
Asgari politika
Kaynağınız çok kısıtlıysa şu dört madde bile büyük fark yaratır:
- Güvenlik yamaları belirli bir süre içinde uygulanır
- Her güncelleme öncesi anlık görüntü/yedek alınır
- Kritik sistemlerde güncelleme test ortamında denenir
- Yapılan güncellemeler kayıt altına alınır
Yorumlar (0)
Henüz yorum yok — ilk yorumu siz yazın.
Yorum yaz