Web Yazılım Güvenliği ve Bakımı Nasıl Planlanır? İşletim Rehberi

Web yazılım güvenliği ve bakımı, yayın gününde tamamlanan tek seferlik kontroller değildir. Uygulama canlı kaldığı sürece kullanıcılar, veriler, bağımlılıklar, sunucular, entegrasyonlar ve iş kuralları değişebilir. Güvenli ve işletilebilir bir sistem için kimin neyi izleyeceği, hangi değişikliği nasıl test edeceği, bir olayda nasıl hareket edeceği ve sistemin nasıl geri getirileceği yazılı olmalıdır.

İyi bir işletim planı şu yedi alanı birbirine bağlar:

1. Yönetişim: Risk, karar, bütçe ve sorumluluk sahipleri.
2. Varlık ve risk envanteri: Uygulama, veri, hesap, servis ve bağımlılıklar.
3. Koruma: Erişim, güncelleme, yapılandırma ve veri güvenliği.
4. Değişiklik ve sürüm: Test, onay, yayın ve geri dönüş yöntemi.
5. Tespit: Kullanıcı akışları, hatalar, performans ve güvenlik sinyalleri.
6. Müdahale: Olay sınıflandırma, iletişim, sınırlama ve düzeltme.
7. Kurtarma ve iyileştirme: Yedekten dönüş, hizmetin doğrulanması ve öğrenilen dersler.

NIST Cybersecurity Framework 2.0 siber güvenlik sonuçlarını Govern, Identify, Protect, Detect, Respond ve Recover işlevleri altında düzenler; uygulanacak eylemlerin kuruma ve kullanım bağlamına göre değişeceğini belirtir (NIST CSF 2.0). Bu makaledeki yedi alan, aynı kavramları web yazılım işletimi için pratik bir bakım planına uyarlayan özgün bir editoryal çerçevedir; NIST uygunluğu veya sertifikasyonu iddiası değildir.

Güvenlik, bakım, destek ve yeni geliştirmeyi ayırın

Bu kavramlar birbiriyle ilişkilidir fakat aynı hizmet değildir.

• Hata desteği: Onaylı ve teslim edilmiş bir işlevin proje kaynaklı hata nedeniyle beklenen şekilde çalışmamasının incelenmesi ve düzeltilmesi.
• Bakım: Sistemi güncel, gözlemlenebilir ve işletilebilir tutmak için tekrarlanan planlı işler.
• Güvenlik çalışması: Riskleri belirleme, koruyucu kontroller, güvenlik izlemesi, doğrulama ve olay müdahalesi.
• Operasyonel destek: Kullanım, erişim veya canlı işlem konusunda gelen talebin yönetilmesi.
• Yeni geliştirme: Yeni özellik, rol, entegrasyon, rapor, tasarım veya değişen iş kuralı.

Bir isteğin kısa sürmesi onu otomatik olarak ücretsiz destek yapmaz. Örneğin yeni bir kullanıcı alanı arayüzde küçük görünse de veri modeli, yetki, entegrasyon, bildirim ve raporları etkileyebilir. Sınıflandırma için onaylı kapsam, sorun kaynağı, tekrar eden işletim ihtiyacı ve beklenen sonuç kullanılmalıdır.

Mevcut “ücretsiz destek ve sürekli bakım” rehberi bu sınırı ayrıntılı açıklar. WS-007 ise bu ayrımı daha geniş güvenlik, olay ve kurtarma modeli içine yerleştirir.

1. Yönetişim: sistemi kimin işleteceğini belirleyin

“Ajans ilgilenecek” veya “IT bakacak” yeterli sorumluluk tanımı değildir. Her canlı uygulama için en az şu roller belirlenmelidir:

• iş/ürün sahibi,
• teknik uygulama sahibi,
• altyapı veya barındırma sahibi,
• bilgi güvenliği veya risk sorumlusu,
• veri ve içerik sahipleri,
• kullanıcı erişimi yöneticisi,
• entegrasyon ve üçüncü taraf servis sahipleri,
• olay iletişimi ve nihai karar sahibi,
• bakım talebini ve bütçeyi onaylayan kişi.

Küçük ekiplerde bir kişi birden fazla rol taşıyabilir. Önemli olan isim, görev, yedek kişi ve iletişim yönteminin kayıtlı olmasıdır.

Karar sınırları

Şunları önceden yazın:

• acil güvenlik düzeltmesini kim onaylayabilir,
• planlı bakım penceresine kim karar verir,
• hizmeti geçici kapatma yetkisi kimde,
• kullanıcılara veya müşterilere kim bilgi verir,
• hangi durumda hukuk/uyum veya nitelikli güvenlik uzmanı dahil edilir,
• üçüncü taraf değişikliği bakım mı yeni geliştirme mi sayılır,
• kabul edilebilir risk istisnasını kim ve ne kadar süreyle onaylar.

2. Varlık ve bağımlılık envanteri oluşturun

Koruyamadığınız veya sahibi bilinmeyen bir bileşeni düzenli yönetmek zordur. Envanter yalnızca sunucu listesinden oluşmamalıdır.

Her varlık için kritiklik, sahibi, yenileme veya kullanım bitişi, destek kanalı ve değişiklik etkisini ekleyin. Kullanılmayan hesap, servis veya uçları envanterde “pasif” bırakmak yerine güvenli biçimde kapatma sürecine alın.

3. Koruma planını risk ve gereksinimle oluşturun

Güvenlik planı yalnızca TLS sertifikası ve güçlü parola maddelerinden ibaret değildir. Uygulamanın verisi, kullanıcı rolleri, kritik işlemleri, dış erişimi ve entegrasyonları değerlendirilmelidir.

Erişim ve kimlik

• Kişiler ortak hesap yerine ayrı hesap kullanıyor mu?
• Yetkiler rol ve iş ihtiyacına göre sınırlı mı?
• Kritik yönetici erişiminde ek doğrulama gerekli mi?
• Yeni kullanıcı, rol değişikliği ve işten ayrılma süreçleri tanımlı mı?
• Servis hesaplarının sahibi ve anahtar yenileme yöntemi belli mi?
• Geçici veya tedarikçi erişimi ne zaman kaldırılacak?
• Kritik işlemler araştırılabilecek biçimde kaydediliyor mu?

Güncelleme ve zafiyet yönetimi

• Hangi uygulama, paket, işletim ortamı ve servisler izlenecek?
• Güvenlik duyurularını kim takip edecek?
• Risk nasıl önceliklendirilecek?
• Güncelleme önce hangi ortamda test edilecek?
• Uyumsuzluk halinde geçici azaltım ve istisna kararı nasıl verilecek?
• Güncelleme sonucu ve açık kalan risk nerede kaydedilecek?

NIST Secure Software Development Framework, güvenlik gereksinimlerinin yaşam döngüsü boyunca bilinmesini ve üçüncü taraf bileşen risklerinin yönetilmesini önerir (NIST SSDF SP 800-218). Bu, her güncellemenin aynı aciliyette olduğu anlamına gelmez; uygulamanın maruziyeti, etkilenen işlev, istismar durumu ve iş etkisi birlikte değerlendirilmelidir.

Güvenlik doğrulaması

Otomatik tarama, manuel inceleme ve bağımsız sızma testi aynı kapsamı kanıtlamaz. OWASP Web Security Testing Guide; yapılandırma, kimlik, yetkilendirme, oturum, girdi doğrulama, iş mantığı, istemci tarafı ve API gibi test alanları sunar (OWASP WSTG).

Plan; test edilecek uygulama/sürüm, yöntem, ortam, test hesabı, kapsam dışı alan, veri güvenliği, rapor, önem sınıflaması, düzeltme ve yeniden test sorumluluğunu yazmalıdır. Test sıklığı ve derinliği risk, değişiklik ve sözleşmeye göre belirlenmelidir. Hiçbir güvenlik testi sistemin gelecekte kesinlikle ihlal edilmeyeceğini garanti etmez.

4. Değişiklik ve sürüm yönetimini bakımın merkezine koyun

Bir güncellemenin varlığı kadar nasıl yayınlandığı da önemlidir. Canlı sistemde doğrudan, kayıtsız değişiklik yapmak geri dönüşü ve hata araştırmasını zorlaştırır.

Her değişiklik kaydında şu alanlar bulunabilir:

• talep veya sorun kimliği,
• değişiklik nedeni ve kapsamı,
• etkilenen işlev, veri ve entegrasyonlar,
• risk ve güvenlik etkisi,
• test senaryoları ve sonucu,
• veri taşıma veya yapılandırma adımı,
• onaylayan kişi,
• yayın tarihi ve uygulayan kişi,
• aktif sürüm/commit/release kimliği,
• geri dönüş yöntemi,
• yayın sonrası doğrulama sonucu.

Ortamlar ve test

Karmaşık projelerde geliştirme, test/ön izleme ve canlı ortamların ayrılması; değişikliklerin gerçekçi veri yapısıyla fakat gereksiz gerçek kişisel veri kullanılmadan doğrulanmasını sağlar. Ortamların birebir aynı olması her zaman mümkün değildir; farklılıklar kaydedilmelidir.

Geri dönüş

“Sorun olursa eski sürüme döneriz” yeterli plan değildir. Kod geri alınsa bile veri yapısı, yeni kayıtlar veya üçüncü taraf değişikliği geri alınamayabilir. Şunları tanımlayın:

• geri dönüşü tetikleyen koşul,
• karar sahibi,
• önceki çalışır sürüm ve yapılandırma,
• veritabanı değişikliğinin geri/ileri düzeltme yöntemi,
• yayın sırasında alınacak yedek,
• doğrulanacak kritik akışlar,
• kullanıcı ve paydaş iletişimi.

5. Tespit: yalnızca sunucuyu değil kullanıcı sonucunu izleyin

Sunucunun yanıt vermesi; formun e-posta gönderdiğini, ödemenin siparişle eşleştiğini veya entegrasyonun doğru veri taşıdığını kanıtlamaz. İzleme katmanlarını ayırın:

Erişilebilirlik ve altyapı

• uygulama ve kritik uçların erişimi,
• yanıt süresi, kaynak ve kapasite sinyalleri,
• TLS, alan adı, lisans veya sertifika bitişleri,
• depolama ve kuyruk doluluğu.

Uygulama ve hata

• hata türleri ve artışları,
• başarısız görev/işlem,
• kullanıcı oturumu ve yetki hataları,
• kritik zamanlanmış işlerin son çalışması,
• yeni sürüm sonrası regresyon sinyalleri.

İşlevsel izleme

• form gerçekten gönderiliyor ve kaydediliyor mu,
• bildirim doğru alıcıya ulaşıyor mu,
• ödeme ve sipariş durumu mutabık mı,
• entegrasyon son başarılı işlemi ne zaman yaptı,
• kritik kullanıcı akışı baştan sona tamamlanabiliyor mu?

Güvenlik ve anomali

• olağan dışı yönetici girişi veya yetki değişikliği,
• tekrarlanan başarısız giriş/istek,
• beklenmedik veri dışa aktarma veya yüksek kullanım,
• güvenlik kontrolü ve servis uyarıları.

Her sinyal için eşik/tetikleyici, uyarı alıcısı, çalışma saati, ilk kontrol adımı ve kayıt yeri yazılmalıdır. Günlüklere parola, gizli anahtar, tam ödeme verisi veya gereksiz kişisel veri konulmamalıdır.

Mevcut form izleme rehberi, tek bir kritik kullanıcı işlevinin görünür olmasını ayrıntılı açıklar. Ana bakım planı bu kontrolü diğer işlevsel ve teknik sinyallerle aynı olay zincirine bağlamalıdır.

6. Olay müdahale planı hazırlayın

Olay yalnızca siber saldırı değildir. Kritik erişim kaybı, yanlış veri görünümü, başarısız ödeme akışı, geniş kesinti veya geri döndürülemeyen hatalı yayın da tanımlı müdahale gerektirebilir.

NIST SP 800-61 Rev. 3, olay müdahalesinin siber güvenlik risk yönetimi boyunca ele alınmasını; tespit, müdahale ve kurtarma faaliyetlerinin hazırlanmasını önerir (NIST Incident Response SP 800-61 Rev. 3). Gerçek olay planı kuruluşun hukuki, sözleşmesel ve sektörel yükümlülüklerine göre nitelikli kişilerce değerlendirilmelidir.

Öncelik matrisi örneği

Bu tablo evrensel SLA değildir. Proje; veri, iş etkisi, kullanıcı sayısı, süre ve hukuki gereksinime göre kendi tanımını oluşturmalıdır.

Olay kaydı

• olayın zamanı ve ilk sinyal,
• etkilenen sürüm, kullanıcı, veri ve servisler,
• doğrulanmış gerçekler ve henüz varsayımlar,
• yapılan sınırlandırma,
• erişim ve değişiklik kaydı,
• iletişim verilen kişiler,
• kararlar ve zamanları,
• kurtarma ve doğrulama sonucu,
• kök neden veya katkıda bulunan koşullar,
• tekrarını azaltacak takip işleri.

Olay sırasında suçlayıcı veya kesinleşmemiş açıklamalar yerine doğrulanmış bilgi ve karar sahibi kullanılmalıdır. Delil niteliği taşıyabilecek kayıtların korunması gerektiğinde uzman yönlendirmesi alınmalıdır.

7. Yedekleme, kurtarma ve iyileştirmeyi test edin

“Her gün yedek alınıyor” tek başına kurtarma planı değildir. Hangi verinin, hangi sıklıkla, ne kadar süreyle, nerede ve kim tarafından yedeklendiği; geri yüklemenin hangi koşulda ve nasıl test edildiği bilinmelidir.

RPO ve RTO’yu iş diliyle tanımlayın

• Kabul edilebilir veri kaybı penceresi (RPO): Olaydan önceki hangi zamana kadar veri kaybı işletme tarafından tolere edilebilir?
• Hizmeti geri getirme hedefi (RTO): Kritik hizmetin hangi süre içinde yeniden çalışması beklenir?

Bu hedefler teknik ekip tarafından tek başına seçilmemelidir. İş etkisi, veri üretim sıklığı, altyapı ve bütçe birlikte değerlendirilmelidir; hedefler garanti değil, planlama ve doğrulama ölçütüdür.

Yedek kapsamı

• veritabanı,
• kullanıcı dosyaları ve medya,
• uygulama kodu ve paketlenmiş sürüm,
• yapılandırma ve altyapı tanımları,
• şifrelerin kendisi yerine güvenli yeniden kurulum/erişim yöntemi,
• entegrasyon ve alan eşleme belgeleri,
• gerekli lisans ve servis envanteri,
• kurtarma talimatı.

CISA StopRansomware Guide, kritik verilerin çevrimdışı ve şifreli yedeklerinin tutulmasını ve yedeklerin erişilebilirlik/bütünlüğünün kurtarma senaryosunda düzenli test edilmesini önerir (CISA StopRansomware Guide). Her web uygulaması için tek bir yedek sıklığı çıkarmaz; sıklık ve saklama, projenin riskine ve kurtarma hedeflerine göre seçilmelidir.

Geri yükleme testi

Test kaydı şunları göstermelidir:

• kullanılan yedek ve tarihi,
• temiz ve uygun hedef ortam,
• işlemi yapan kişi,
• geçen süre,
• geri dönen veri/sürüm,
• kritik akışların sonucu,
• eksik veya bozuk bileşenler,
• RPO/RTO hedefleriyle karşılaştırma,
• düzeltme ve sonraki test tarihi.

Yedek dosyasının bulunması, kullanılabilir ve güvenilir biçimde geri yüklendiğini kanıtlamaz.

Bakım görev kartı ve işletim takvimi

Her bakım maddesini şu kartla kaydedin:

Örnek takvim; proje özelinde uyarlanmalıdır

“Aylık” veya “yıllık” tek başına kalite göstermez. Görev, kapsam, sahip ve sonuç kanıtı olmadan takvim yalnızca hatırlatıcıdır.

Müşteri, yazılım ekibi ve üçüncü taraf sorumluluk matrisi

Gerçek sorumluluklar sözleşmeye göre yazılmalıdır. Barındırma sağlayıcısının altyapı yedeği, uygulama ekibinin veritabanı geri yükleme sorumluluğuyla aynı olmayabilir. Müşteri adına açılmamış hesaplar ve tek kişide kalan erişimler devir riskini artırabilir.

Bakım planında hizmet hedefleri nasıl yazılır?

“7/24 destek” veya “hemen çözüm” ifadeleri tek başına ölçülebilir değildir. Varsa şu kavramları ayırın:

• resmi talep ve olay kanalı,
• hizmet saatleri ve tatiller,
• öncelik tanımı,
• ilk yanıt hedefi,
• inceleme veya durum güncelleme aralığı,
• geçici çözüm hedefi,
• kalıcı çözümün tahmin/plan yöntemi,
• müşteri bilgisi veya erişimi beklenirken saatin durumu,
• üçüncü taraf kaynaklı olayların kapsamı,
• raporlama ve eskalasyon.

İlk yanıt süresi çözüm süresi değildir. Güvenlik olayı veya karmaşık veri sorunu, etkiyi sınırlandırma ve kanıt koruma nedeniyle normal hata talebinden farklı süreç gerektirebilir.

Bakım planı teklifinde kırmızı bayraklar

• “Düzenli bakım” var fakat görev ve sonuç kaydı yok.
• “Yedek alınıyor” deniyor fakat kapsam, saklama ve geri yükleme testi yok.
• Güncelleme doğrudan canlıda uygulanıyor; test ve geri dönüş açıklanmıyor.
• İzleme yalnızca sunucu erişimine bakıyor; temel kullanıcı akışları kontrol edilmiyor.
• Ortak yönetici hesabı ve süresiz tedarikçi erişimi kullanılıyor.
• Güvenlik testi, otomatik tarama ve sızma testi aynı şeymiş gibi sunuluyor.
• İlk yanıt ve çözüm süresi karıştırılıyor.
• Hata desteği, bakım ve sınırsız yeni geliştirme tek belirsiz pakette birleştiriliyor.
• Üçüncü taraf servis değişikliği ve ücretleri sahipsiz bırakılıyor.
• Hesap, kod, veri ve dokümantasyon yalnızca sağlayıcıda kalıyor.
• Güvenlik, kesintisizlik veya veri kaybı olmaması koşulsuz garanti ediliyor.

Kopyalanabilir web yazılım işletim planı

1. Sistem ve iş amacı
2. Kritik kullanıcı akışları
3. İş, teknik, güvenlik ve iletişim sahipleri
4. Varlık, veri, hesap ve üçüncü taraf envanteri
5. Risk ve kritiklik sınıfları
6. Erişim ve yetki yaşam döngüsü
7. Güncelleme ve zafiyet yönetimi
8. Güvenlik doğrulama kapsamı
9. Ortam, değişiklik, test ve yayın yöntemi
10. Sürüm ve geri dönüş kaydı
11. Altyapı, uygulama, işlev ve güvenlik izlemesi
12. Uyarı ve eskalasyon matrisi
13. Olay öncelikleri, roller ve iletişim
14. Yedek kapsamı, RPO/RTO ve geri yükleme testi
15. Bakım görev kartları ve takvim
16. Destek kanalı ve hizmet hedefleri
17. Hata, bakım ve yeni geliştirme ayrımı
18. Üçüncü taraf sürüm, ücret ve yenileme takibi
19. Aylık/dönemsel sonuç raporu
20. Devir, erişim kaldırma ve hizmet sonlandırma planı

İşletim sorumlulukları proje sonunda eklenmemelidir. Bunları web yazılım proje sürecinde erken planlayın, gereksinim dokümanında ölçülebilir hâle getirin ve dış sistemlerin izleme, hata ve uzlaştırma sorumluluğunu entegrasyon planıyla eşleştirin.

Sonuç

Web yazılım güvenliği ve bakımı, “güncellemeler yapılır” veya “teknik destek verilir” cümlelerinden oluşmamalıdır. Canlı sistemi yöneten kişiler, varlıklar, riskler, değişiklikler, sinyaller, olaylar ve kurtarma hedefleri aynı işletim planında görünmelidir.

Her bakım görevini amacı, tetikleyicisi veya sıklığı, sahibi, yöntemi, kanıtı ve eskalasyonuyla tanımlayın. Sunucunun açık olmasının ötesinde kritik kullanıcı sonuçlarını izleyin; güvenlik kontrolünü riske göre planlayın; değişiklikleri test ve geri dönüş kaydıyla yayınlayın; yedeği geri yükleme testiyle doğrulayın. Böylece destek, bakım, güvenlik ve yeni geliştirme hem teknik hem ticari olarak yönetilebilir sınırlar kazanır.