wp-config.php Dosyasında Güvenlik ve Parola Yönetimi

Bir WordPress bağlantı sorunu incelenirken en hızlı yöntem olarak yapılandırma dosyasını açıp veritabanı parolasını ekip sohbetine göndermek önerilmişti. Bu yöntem sorunu kısa süreli çözebilirdi, fakat kalıcı bir sır birden fazla kontrolsüz kopyaya dönüşecekti. Asıl ihtiyaç parolayı “bulmak” değil, yetkili kişinin güvenli biçimde doğrulaması ve gerekiyorsa izlenebilir şekilde yenilemesiydi.

21 Temmuz 2026 tarihli çalışmada `wp-config.php` dosyasını yalnızca bağlantı ayarı olarak değil, WordPress güven sınırlarından biri olarak ele aldık. Dosya yolu, web sunucusu kullanıcısı, dağıtım yöntemi, yedek ve destek süreçleri birlikte incelendi. Aşağıdaki yaklaşım gerçek parola veya altyapı ayrıntısı paylaşmadan savunmacı işletim prensiplerine odaklanır.

Sorunun ortaya çıkışı

Site veritabanına bağlanamıyor, ancak ekipte hangi hesabın kullanıldığına dair güncel kayıt bulunmuyordu. Dosyaya erişebilen herkes parolayı okuyabiliyor, bazı eski yedeklerde de yapılandırmanın kopyaları yer alıyordu. Önceki bir hata ayıklama sırasında debug kayıtları web dizininde bırakılmıştı. Tek bağlantı sorunu, sır yaşam döngüsü ve dosya yönetişimi eksiklerini görünür hale getirdi.

Dosyanın sahipliği geçmiş kurulumlardan dolayı belirsizdi. Web sunucusunun yazma yetkisi bulunması güncellemeyi kolaylaştırıyor gibi görünse de uygulama açığında yapılandırmanın değiştirilmesi riskini artırıyordu. Öte yandan izinleri düşünmeden aşırı daraltmak siteyi erişilemez yapabilirdi. Doğru model işletim sistemi kullanıcısı, PHP çalışma biçimi ve dağıtım sorumluluğuna göre kurulmalıydı.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım dosyanın web tarayıcısından normalde görüntülenememesinin yeterli koruma olduğuydu. Yanlış sunucu yapılandırması, yedek uzantısı, dizin listeleme, yerel kullanıcı veya ele geçirilmiş eklenti farklı erişim yolları oluşturabilir. İkinci varsayım dosya izninde tek bir sayısal değerin her sunucu için doğru olduğuydu. Sahiplik ve servis modeli bilinmeden kopyalanan izin önerileri kesinti ya da gereksiz açıklık yaratabilir.

Salt anahtarlarının veritabanı parolasıyla aynı işlevi gördüğü de karıştırılıyordu. WordPress authentication salts mevcut oturum çerezlerinin güvenliğini etkiler; değiştirilmeleri kullanıcı oturumlarını geçersiz kılar. Veritabanı parolasının rotasyonu ise MySQL hesabı ile yapılandırmanın eş zamanlı güncellenmesini gerektirir. İki işlem farklı etki ve geri dönüş planlarıyla yürütülmelidir.

Teknik analiz

Dosyanın gerçek konumu, sembolik bağlantıları, sahibi, grubu ve erişim listeleri doğrulandı. Web sunucusunun dosyayı okuması gerekiyor, fakat olağan çalışma sırasında değiştirmesi gerekmiyordu. Üst dizin izinleri de kontrol edildi; yalnızca dosyayı daraltıp dizini geniş bırakmak yeterli değildir. Web sunucusu yapılandırmasının `.bak`, `.old` veya editör geçici dosyalarını sunmadığı doğrulandı.

Yapılandırmada veritabanı kimliği, salt anahtarları, debug ayarı ve tablo öneki gibi alanlar envantere alındı; değerler rapora kopyalanmadı. Kaynak kod deposu geçmişi ve dağıtım paketi sır sızıntısı açısından kontrol edildi. Debug logunun konumu, erişimi ve saklama süresi belirlendi. Yedeklerin dosyayı içerip içermediği ve kimlerin yedek ortamına erişebildiği ayrıca değerlendirildi.

# Değerleri ekrana dökmeden yalnızca sahiplik ve izinleri inceleyin.
stat /guvenli/yol/wp-config.php

# PHP sözdizimini kontrol edin; dosya içeriğini paylaşmayın.
php -l /guvenli/yol/wp-config.php

# İzin değişikliği vermeden önce web/PHP çalışma kullanıcısını doğrulayın.
# Ortama özel sahiplik bilinmeden körlemesine chmod/chown uygulamayın.

Uygulanan çözüm veya önerilen mimari

Dosyanın sahibi dağıtım sorumluluğundaki ayrı kullanıcı, okuma grubu ise yalnızca PHP servisinin gerekli kimliği olacak şekilde tasarlandı. Web sürecine yazma verilmedi. Kesin izin değeri ortama göre test edilerek belirlendi ve yapılandırma web kökü dışında desteklenen konuma taşınabiliyorsa bu seçenek değerlendirildi. Sunucu, yedek ve geçici uzantılı yapılandırma dosyalarını yayınlamayacak biçimde sertleştirildi.

Parolalar kurumun secret yönetim sürecinde üretildi; dosyaya dağıtım sırasında güvenli kanaldan verildi ve depoya yazılmadı. Rotasyonda yeni sınırlı hesap oluşturma, yapılandırmayı atomik güncelleme, sağlık testi ve eski hesabı iptal etme adımları uygulandı. Salt yenilemesi ayrı değişiklik olarak kullanıcı oturum etkisiyle planlandı. Erişim ve değişiklikler kişisel sırları göstermeden denetim kaydına alındı.

Alternatifler ve karar gerekçesi

Sırları doğrudan `wp-config.php` içinde tutmak WordPress’in yaygın ve basit modelidir; dosya güvenliği kritik hale gelir. Ortam değişkenleri veya harici secret manager merkezi rotasyon ve dağıtım sağlayabilir, fakat PHP sürecinde değerin nasıl sunulduğu, hata çıktıları ve eklenti uyumluluğu incelenmelidir. Yalnızca farklı yere taşımak, erişim kontrolleri değişmiyorsa sihirli bir koruma sağlamaz.

Dosyayı tamamen değişmez yapmak izinsiz değişikliği azaltabilir; otomasyon, güncelleme ve acil müdahale sürecini zorlaştırabilir. Web sunucusuna yazma vermek ise kolaylık karşılığında olay etkisini büyütür. Kontrollü dağıtım hesabı, salt okunur uygulama erişimi ve izlenen değişiklik süreci kurumun işletim biçimine daha uygun bulundu. Karar, geri dönüş testiyle doğrulandı.

Güvenlik ve operasyonel riskler

Dosya içeriğini ticket, ekran görüntüsü veya sohbetle paylaşmak geri alınması zor kopyalar üretir. Bir sırın açığa çıktığından şüpheleniliyorsa mesajı silmek yeterli değildir; parola ve ilgili anahtarlar planlı biçimde yenilenmelidir. Kaynak depo geçmişindeki sır da yalnızca son commit’ten kaldırılınca yok olmaz. Erişim anahtarları önce iptal edilmeli, geçmiş temizliği kontrollü yürütülmelidir.

Yanlış sahiplik ya da izin değişikliği site kesintisine yol açabilir. Önce mevcut durum kaydedilmeli, ikinci yönetim oturumu korunmalı ve sağlık testi hazırlanmalıdır. Debug açık kalırsa kişisel veri, sorgu veya dosya yolu loglara düşebilir. Yedekler şifrelenmeli, erişimleri sınırlandırılmalı ve saklama sonlarında güvenli silinmelidir. Dosya bütünlüğü uyarıları yetkili dağıtımlarla ilişkilendirilmelidir.

Çıkarılan Dersler

Kontrol Listesi

Disk şifreleme çoğu zaman sessiz çalışan bir kontrol olduğu için dağıtımı kolay sanılır. Ancak firmware değişikliği, TPM durumu veya hatalı kurtarma anahtarı saklama süreci, bir sonraki açılışta kullanıcıyı iş yapamaz halde bırakabilir.

6-9 Temmuz 2026 tarihli pilotta TPMReady cihazlarda XTS-AES 256 ve Used Space Only yaklaşımı değerlendirildi. Algoritma kadar önemli olan soru şuydu: cihaz kurtarma ekranına düştüğünde doğru anahtara, yetkili destek personeli ne kadar güvenli ve hızlı ulaşabilecek?

Pilot hazırlığında güvenlik, masaüstü yönetimi ve servis masası aynı masaya oturdu. Güvenlik ekibi şifreleme standardını, uç nokta ekibi donanım uyumluluğunu, servis masası ise gerçek kurtarma deneyimini temsil etti. Bu üç bakış birleşmediğinde politika teknik olarak uygulanabilir görünürken kullanıcı desteği başarısız kalabiliyor. Ayrıca şifrelenmiş cihaz oranını tek KPI yapmak yerine escrow başarısı, şifrelemesi askıda kalan cihaz, tekrar eden kurtarma ekranı ve anahtar erişim süresi gibi göstergeleri kullandık. Böylece yüksek kapsama rakamının arkasındaki operasyonel sorunlar görünür kaldı.

Sorunun ortaya çıkışı

Taşınabilir cihazlarda veri kaybı riski için merkezi şifreleme hedeflendi. Envanterde TPM sürümü, firmware durumu, disk yapısı ve mevcut şifreleme bilgileri tutarlı değildi. GPO’yu bütün cihazlara bağlamak kolay, sonuçları öngörmek zordu.

Dağıtım öncesi teknik envanter, anahtar escrow, destek prosedürü ve kullanıcı iletişimi ayrı çalışma akışları olarak açıldı. Başarı, yalnızca şifreli cihaz yüzdesi değil; kurtarma anahtarının doğrulanması ve normal açılış deneyiminin korunmasıyla tanımlandı.

İlk belirtiler ve yanlış varsayımlar

TPMReady raporu tek başına yeterli değildi; askıya alınmış TPM, bekleyen firmware, uyumsuz bölümleme ve daha önce elle şifrelenmiş diskler görüldü. Used Space Only seçeneğinin her koşulda en iyi yöntem olduğu da varsayılamaz; yeni hazırlanmış cihaz ve uzun süredir kullanılan disk farklı veri kalıntısı risklerine sahiptir.

Kurtarma anahtarının dizine yazılacağı ayarı açmak, anahtarın gerçekten yazıldığını kanıtlamaz. Şifreleme başlamadan escrow doğrulanmalıdır. Kullanıcıya anahtar teslim etmek de merkezi yönetime alternatif değildir; anahtarın ekran görüntüsü veya e-posta ile paylaşılması yeni risk doğurur.

Teknik analiz

Cihazlar TPM, Secure Boot, işletim sistemi, disk düzeni, pil ve boş alan açısından raporlandı. GPO uygulama sonucu ile BitLocker gerçek durumu ayrı ölçüldü. Şifreleme yöntemi performans, kurumsal standart ve uyumluluk gereksinimiyle belirlendi; tek başına daha yüksek bit değeri karar gerekçesi olmadı.

Kurtarma anahtarı deposunda erişim en az yetkiye indirildi ve sorgular denetlendi. Pilot, farklı donanım modelleri ve uzaktan çalışan kullanıcıları kapsadı. Firmware güncellemesi, TPM temizleme, anakart değişimi ve kullanıcı PIN’i gibi durumlar destek senaryosunda denendi.

Uygulanan çözüm veya önerilen mimari

Ön koşul denetimi geçen cihazlar dinamik pilot grubuna alındı. Politika önce küçük BT grubunda, ardından temsili iş birimlerinde uygulandı. Şifreleme hızı, açılış sorunları, anahtar escrow başarısı ve destek kayıtları izlendi.

Yaygınlaştırma dalgalar halinde yapıldı ve kritik operasyon dönemlerinden kaçınıldı. Kullanıcı iletişimi şifreleme ayrıntısından çok cihazı kapatmama, güç bağlantısı ve kurtarma ekranında destek kanalını kullanma konularına odaklandı. Uyum raporu eksik ve askıya alınmış cihazları ayrıca gösterdi.

Alternatifler ve karar gerekçesi

Bulut tabanlı cihaz yönetimi modern cihazlarda daha ayrıntılı uygunluk ve anahtar yönetimi sunabilir; mevcut yönetim modeli ve lisans kapsamı değerlendirilmelidir. GPO köklü etki alanı ortamında uygulanabilir, fakat internetten uzun süre uzak cihazlarda görünürlük gecikebilir.

XTS-AES 256 kurum standardıyla uyumlu olduğu için pilot edildi; performans ve mevzuat ihtiyacı farklı kurumlarda başka seçimi haklı kılabilir. Karar üretici varsayılanına değil, risk gereksinimi, cihaz kapasitesi ve yönetilebilirlik testine bağlandı.

Güvenlik ve operasyonel riskler

Kurtarma anahtarları hassas güvenlik verisidir. Geniş okuma yetkisi, kontrolsüz dışa aktarma veya servis kayıtlarına açık metin ekleme engellenmelidir. Yetkili erişimler düzenli gözden geçirilmeli ve olağandışı anahtar sorguları izlenmelidir.

Elektrik kesintisi, firmware değişikliği ve donanım arızası operasyonu etkileyebilir. Dağıtım penceresi, güç koşulları ve kullanıcı desteği planlanmalıdır. BitLocker yedeklemenin yerine geçmez; şifreli cihazdaki silinme veya bozulma için ayrı veri koruma süreci gerekir.

Çıkarılan Dersler

Kontrol Listesi

Bir danışmana şirket uzantılı adres vermek, yazışmayı kolaylaştırırken karşı tarafa kurumsal kimlik de kazandırır. Alıcılar bu kişinin çalışan mı, yüklenici mi olduğunu ayırt etmeyebilir; uygulamalar da aynı adresi otomatik güven sinyali sayabilir.

20 Temmuz 2026 tarihindeki vakada resmi sözleşmesi tamamlanmadan teklif üzerinden hizmet veren kişiler için hesap talep edilmişti. Talebi yalnızca lisans açısından değil, kimlik yaşam döngüsü, veri sahipliği ve kurum adına iletişim riski açısından değerlendirdik.

İş biriminin talebi makuldü: danışmanın toplantılara katılması, belgeler üzerinde çalışması ve dış paydaşlarla düzenli iletişim kurması gerekiyordu. Ancak çözümün mutlaka çalışanla aynı kimlik türü olması gerekmiyordu. Kurumsal dizinde oluşan her nesnenin görünmeyen yan etkileri vardır; otomatik gruplar, uygulama varsayılanları ve paylaşım kolaylıkları zamanla erişimi büyütebilir. Bu nedenle hesabın ilk günkü yetkisinden çok, altı ay sonra kim tarafından hatırlanacağına odaklandık. Sorumlu sponsor, hizmet ilişkisini düzenli doğrulamadıkça teknik ekibin sözleşmenin bittiğini kendiliğinden bilmesi beklenemez.

Sorunun ortaya çıkışı

İş birimi hızlı iletişim ve toplantı erişimi için şirket hesabı istiyordu. Talepte hizmet bitiş tarihi, veri kapsamı, sponsor ve kapanış koşulu yoktu. Hesap açıldığında adres defteri, paylaşım davetleri ve bazı varsayılan uygulama erişimleri beklenenden geniş olabilirdi.

BT talebi tamamen reddetmek yerine iş ihtiyacını ve kimlik ihtiyacını ayırdı. Dış toplantı katılımı, konuk erişimi veya paylaşımlı kanal yeterliyse tam posta kutusu gerekmiyordu. Kurum adına yazışma gerekiyorsa hukuki ilişki ve sorumluluklar önce netleşmeliydi.

İlk belirtiler ve yanlış varsayımlar

“Sadece e-posta” ifadesi en yaygın yanlış varsayımdı. Modern bulut ortamında posta kimliği dosya paylaşımı, ekip üyeliği, uygulama kaydı ve parola sıfırlama akışlarına bağlanabilir. Lisans atanmaması da kimlik nesnesinin riskini ortadan kaldırmaz.

Yönetici onayı tek başına yeterli sayılıyordu; oysa hesabın günlük sponsoru, hizmet süresi ve veri sınıfı bilinmelidir. Danışmanın kendi cihazını kullanması halinde cihaz güvenliği, veri indirme ve olay bildirim yükümlülüğü ayrıca ele alınmalıdır.

Teknik analiz

Hesap türü çalışan kimliğinden ayrılmalı, görünür ad ve dizin niteliği dış kullanıcı durumunu doğru yansıtmalıdır. MFA, Conditional Access, riskli oturum politikaları ve cihaz koşulları uygulanmalıdır. Varsayılan grup üyelikleri ve otomatik lisans atamaları incelenmelidir.

Erişimler rol bazlı ve süreli olmalı; posta yönlendirme, uygulama onayı, toplu indirme ve hassas paylaşım olayları izlenmelidir. Hesap etkinliği yalnızca oturum açmaya göre değil, sponsor teyidiyle gözden geçirilmelidir. Offboarding, posta ve dosya sahipliğini yasal saklama gereksinimleriyle birlikte yönetmelidir.

Uygulanan çözüm veya önerilen mimari

Önce konuk erişimi ve mevcut dış iletişim seçenekleri değerlendirildi. Kurumsal posta kutusu gerçekten gerekliyse sözleşme sahibi, iş sponsoru, veri sınıfı, başlangıç ve bitiş tarihi zorunlu alan yapıldı. Hesap ayrı yüklenici grubunda sınırlı politikalarla açıldı.

Süre bitiminden önce sponsora otomatik gözden geçirme gönderildi; teyit gelmezse erişim askıya alındı. Uzatma yeni onay gerektirdi. Hizmet bitiminde oturumlar sonlandırıldı, grup ve uygulama atamaları kaldırıldı, içerik sahipliği kayıtlı prosedüre göre devredildi.

Alternatifler ve karar gerekçesi

Konuk hesap, federasyon ve güvenli dosya paylaşım alanı birçok senaryoda kurumsal posta kutusundan daha düşük risklidir. Paylaşımlı posta kutusu bireysel hesap yerine kullanılmamalıdır; hesap verebilirliği zayıflatır. Danışmanın kendi kurumsal adresiyle yazışması kimlik sınırını daha açık tutabilir.

Tam hesap yalnızca danışmanın kurum adına düzenli iletişim kurması ve iç uygulamalara tanımlı erişim gerektirmesi halinde seçildi. Kolaylık tek başına gerekçe kabul edilmedi. Karar, en az ayrıcalık ve açık kurumsal temsil ihtiyacına göre verildi.

Güvenlik ve operasyonel riskler

Hesap ele geçirilirse saldırgan şirket uzantısını sosyal mühendislik için kullanabilir. Dış danışmanların cihaz ve ağ kontrolleri kurum çalışanlarıyla aynı olmayabilir. Güçlü MFA, oturum koşulları, veri kaybı kontrolleri ve olay bildirim zorunluluğu bu nedenle önemlidir.

Sahipsiz hesaplar yıllarca açık kalabilir, lisans tüketebilir ve denetim bulgusu yaratabilir. Sponsor işten ayrıldığında sahiplik otomatik devredilmelidir. Hukuk, İK, satınalma ve BT arasında kapanış tetikleyicisi kurulmadıkça teknik otomasyon tek başına yeterli olmaz.

Çıkarılan Dersler

Kontrol Listesi

DLP projeleri çoğunlukla kimlik numarası ve finansal veriyle başlar. Oysa bir yapılandırma dosyasındaki API anahtarı veya destek kaydındaki yönetici parolası kurum için en az bu veriler kadar kritik olabilir. Teknik sırların biçimi değişken olduğu için hazır bir desen her ortamda yeterli olmaz.

14 Temmuz 2026 tarihli çalışmada amaç gerçek sır örneklerini merkezi bir dosyada toplamak değildi. Güvenli sentetik verilerle özel bilgi türünü geliştirdik; önce yalnızca görünürlük sağladık, yanlış pozitifleri azalttıktan sonra kullanıcı uyarısı ve olay akışını devreye aldık.

Bu tür bir kontrolün sosyal boyutu da var. Teknik ekipler hızlı çözüm için bazen bir değeri sohbet kanalına veya destek kaydına bırakabiliyor; yalnızca engelleyici politika koymak çalışma alışkanlığını ortadan kaldırmıyor. Kullanıcıya güvenli sır paylaşım kanalını göstermeden üretilen uyarı, kısa sürede geçilmesi gereken bir engel gibi görülür. Bu nedenle DLP olaylarından süreç iyileştirme verisi çıkardık: hangi uygulama güvenli entegrasyonu zorlaştırıyor, hangi ekipte sır kasası kullanımı eksik ve hangi şablon yanlış pozitif üretiyor? Politika böylece yalnız ihlal arayan değil, kötü iş akışını görünür kılan bir kontrol oldu.

Sorunun ortaya çıkışı

Yönetici parolası, root hesabı, private key, recovery key, API token ve VPN secret ifadelerinin e-posta ve belgelerde dolaşabildiği görüldü. Mevcut DLP yalnızca klasik kişisel veri türlerini izliyordu; teknik sırlar olay müdahalesinde tesadüfen fark ediliyordu.

İhtiyaç bütün kod parçalarını engellemek değil, geçerli sır olma olasılığı yüksek içerikleri doğru ekibe yönlendirmekti. Kapsam e-posta, iş birliği alanı ve yönetilen uç nokta kanalları için veri sınıfına göre ayrıldı.

İlk belirtiler ve yanlış varsayımlar

“password” veya “token” kelimesini arayan ilk kural dokümantasyon, eğitim ve boş şablonlarda alarm üretti. Uzun rastgele karakter dizileri de dosya özeti ve örnek kodlarla karıştı. Çok gürültülü kural, analistin gerçek olayı kaçırmasına neden olur.

Bir başka hata, yakalanan içeriği olay kaydına açık biçimde kopyalamaktı. DLP kanıtı erişimi sınırlı ve maskeli olmalıdır. Kural, sır kasasının alternatifi değildir; asıl hedef sırların güvenli üretim, saklama ve rotasyon sürecine taşınmasıdır.

Teknik analiz

Özel bilgi türünde ana örüntüye yakın mesafede “admin”, “secret”, “private key”, “recovery” veya yapılandırma alanı gibi destekleyici bağlam arandı. Belirgin başlık ve biçime sahip anahtarlar yüksek güven, genel karakter dizileri daha düşük güven aldı. Türkçe ve İngilizce iş bağlamları ayrı test edildi.

Sentetik pozitif örnekler ile sözleşme, kaynak kodu şablonu ve eğitim dokümanı gibi negatif örneklerden test seti hazırlandı. Hassas değerlerin kendisi loglanmadı. Sonuçlar kanal, kullanıcı grubu, dosya türü ve eşleşme gerekçesine göre incelendi.

# Savunmacı kural mantığı (temsili)
if pattern_matches and context_within_300_chars:
    classify(confidence='high')
elif pattern_matches:
    classify(confidence='low', action='audit')

Uygulanan çözüm veya önerilen mimari

Politika önce seçili teknik ekipte audit-only çalıştı. Haftalık örnekleme ile gerçek pozitif, kabul edilebilir iş kullanımı ve yanlış pozitif sınıfları çıkarıldı. Eşik ve yakınlık ayarları oturduktan sonra kullanıcıya açıklayıcı uyarı gösterildi; yalnızca yüksek riskli kanallarda engelleme değerlendirildi.

Doğrulanan olay güvenlik ekibi ile sır sahibine yönlendirildi. Paylaşım kaldırma yeterli sayılmadı; anahtar iptali veya parola rotasyonu, erişim logu incelemesi ve kök neden düzeltmesi kapanış kriteri oldu.

Alternatifler ve karar gerekçesi

Kaynak kodu secret scanning araçları depo bağlamında daha kesin sonuç verebilir; DLP e-posta ve doküman kanallarını kapsar. Sır kasası güvenli saklama sağlar fakat yanlış paylaşımı tek başına önlemez. Bu kontroller birbirini tamamlar.

Tam engelleme hızlı görünür ancak iş akışını bozup kontrol dışı kanalları teşvik edebilir. Kademeli görünürlük, kullanıcı eğitimi ve seçici engelleme tercih edildi. Ürün hazır sınıflandırıcıları pilot sonuçlarıyla doğrulanmadan güvenilir kabul edilmedi.

Güvenlik ve operasyonel riskler

DLP analistleri son derece hassas içeriğe erişebilir. Rol ayrımı, gerekçeli görüntüleme, denetim izi ve sınırlı saklama uygulanmalıdır. Test için gerçek parola veya token kullanılmamalı; olay kayıtları sır değerini tekrar yaymamalıdır.

Yanlış negatifler kaçınılmazdır; DLP mutlak garanti olarak sunulmamalıdır. Şifreli arşivler, görseller ve yeni token biçimleri görünürlüğü etkiler. Kural performansı ve ürün formatları düzenli gözden geçirilmeli, olay sonrası rotasyon prosedürü tatbik edilmelidir.

Çıkarılan Dersler

Kontrol Listesi

Güvenlik duvarı sorunlarında en pahalı yöntem, her tahmin için bir kural değiştirmektir. Kaynak sistem firewall’ı suçlar, ağ ekibi rotayı, güvenlik ekibi uygulamayı işaret eder; paket ise bu katmanlardan yalnızca birinde belirli bir nedenle duruyordur. FortiGate debug flow doğru sınırlarla kullanıldığında cihazın paket için verdiği kararları sıralı biçimde gösterir ve tartışmayı kanıta çevirir.

21 Temmuz 2026 tarihinde kaynak, hedef ve servis bilgisi bilinen fakat erişim sonucu açıklanamayan bir vakayı bu yöntemle ele aldık. Debug’ı genel olarak açmadık. Önce tek test oturumu, bakım zamanı ve dar filtre tanımladık; timestamp ve function-name görünürlüğünü etkinleştirdik. Yeterli paket sayısından sonra tanıyı durdurup filtreyi temizledik. Bu disiplin, aracın kendisinin operasyonel probleme dönüşmesini önledi.

Sorunun ortaya çıkışı

Bir iç uygulamadan dış hizmete belirli TCP bağlantısı zaman aşımına uğruyordu. Policy loglarında aynı hedefe ait izin ve ret kayıtları farklı zamanlarda görülüyor, standart trafik günlüğü paketin hangi route ve kural değerlendirmesinden geçtiğini yeterince açıklamıyordu. Uygulama tekrar denemeleri de çok sayıda benzer oturum üretiyordu. Tek bir kontrollü akışı izole etmek gerekiyordu.

Başlamadan önce saatler eşitlendi ve uygulama sahibinden test anı alındı. Kaynakta ad çözümleme sonucu, gerçek hedef adres ve port doğrulandı. NAT öncesi ve sonrası adresin nerede görüleceği belirlendi. Debug flow’un şifreli uygulama içeriğini çözmek için değil, FortiOS’un akış kararlarını görmek için kullanılacağı ekiplerle netleştirildi.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış yaklaşım hiçbir filtre koymadan debug başlatmaktı. Yoğun cihazda bu, konsolu okunamaz hale getirir, CPU ve yönetim oturumu üzerinde ek yük oluşturur. İkinci varsayım “received a packet” satırının paketin başarıyla iletildiği anlamına geldiğiydi. Bu yalnızca paketin bir arayüze ulaştığını gösterir; route, policy, NAT ve güvenlik profili kararları henüz verilmemiş olabilir.

Tek bir drop satırını bağlamdan koparmak da yanıltıcıdır. Aynı hedef için health check, kullanıcı testi ve yeniden iletimler farklı oturumlar olabilir. Offload edilmiş mevcut oturumların tüm paketleri CPU akışında görünmeyebilir. Debug çıkmaması paketin kesinlikle cihaza gelmediğini düşündürür, ancak yanlış VDOM, yanlış filtre, IPv6 akışı veya mevcut hızlandırılmış oturum önce elenmelidir.

Teknik analiz

Filtre kaynak ve hedef adres, gerekiyorsa port ve protokolle daraltıldı. CLI bağlamının doğru VDOM’da olduğu doğrulandı. Timestamp farklı sistem günlüklarını eşleştirmeyi, function-name ise route lookup, policy check, session ve NAT adımlarını okumayı kolaylaştırdı. Trace sayısı birkaç test bağlantısını görecek kadar sınırlandı. Test bitince önce trace durduruldu, sonra debug kapatıldı ve filtre sıfırlandı.

Çıktı kronolojik okundu: giriş arayüzü ve orijinal beşli, mevcut session eşleşmesi, route sonucu, politika kimliği, NAT dönüşümü ve drop gerekçesi. “No matching policy” ile “reverse path check fail” aynı çözümü gerektirmez; birincisi politika bağlamına, ikincisi rota simetrisine yönlendirir. UTM veya SSL inceleme sonucu görüldüğünde ilgili profil günlüklarıyla korelasyon yapıldı.

# Üretici dokümantasyonuna göre uyarlayın; örnekler placeholder'dır
diagnose debug reset
diagnose debug flow filter addr 192.0.2.40
diagnose debug flow show function-name enable
diagnose debug flow show console enable
# Kısa, onaylı trace sonrasında mutlaka durdurun
diagnose debug disable
diagnose debug reset

Uygulanan çözüm veya önerilen mimari

Dar trace, paketin beklenen politikaya ulaştığını ancak dönüş yolu kontrolünde asimetri bulunduğunu gösterdi. İkinci WAN üzerindeki daha özel rota geri dönüşü farklı arayüze yönlendiriyordu. Rota tasarımı ağ ekibiyle doğrulandı ve yalnızca ilgili hedef için istenen simetri sağlandı. Güvenlik kontrolünü global olarak gevşetmek yerine yönlendirme niyeti düzeltildi. Yeni oturumla test başarıyla tekrarlandı.

Kalıcı sorun giderme prosedürüne bir debug çalışma kartı eklendi: talep numarası, onaylayan kişi, VDOM, filtre, başlangıç-bitiş süresi ve kapatma kontrolü. Hazır komutlar gerçek adres içermeyen şablon olarak tutuldu. Standard trafik logları yeterliyse debug kullanılmıyor; yalnızca karar zinciri açıklanamadığında ve yetkili yönetici gözetiminde devreye alınıyor.

Alternatifler ve karar gerekçesi

Packet sniffer arayüz seviyesinde paketin gelip gittiğini gösterir ve debug flow’dan daha düşük karar ayrıntısına sahiptir; ikisi farklı soruları cevaplar. Trafik logları geçmiş analizi için değerlidir ancak her dahili değerlendirme adımını içermez. Policy lookup belirli bir akışın kural eşleşmesini hızlı sınar, gerçek oturumun route ve session davranışını bütünüyle göstermeyebilir.

Her sorunda debug flow kullanmak doğru değildir. Performans sorunu için arayüz sayaçları ve kapasite metrikleri, uygulama katmanı hatası için sunucu günlüğü daha uygun olabilir. Bu vakada paket FortiGate’e ulaşıyor ve karar noktası belirsiz olduğu için debug flow seçildi. Araç seçimi alışkanlığa değil, doğrulanmak istenen hipoteze bağlandı.

Güvenlik ve operasyonel riskler

Debug çıktısı ağ topolojisi, adresler, portlar, politika adları ve NAT ilişkileri içerir. Ham çıktı genel destek kanalına yüklenmemeli; erişimi sınırlı olay kaydında saklanıp paylaşım öncesi anonimleştirilmelidir. CLI yönetici yetkisi kişisel hesapla ve MFA korumalı yönetim yolundan kullanılmalıdır. Komut geçmişine parola veya gizli anahtar yazılmamalıdır.

Sınırsız trace yüksek trafikte yönetim düzlemini etkileyebilir ve kritik satırların kaçmasına yol açar. Kapatma komutu çalışma planının parçası olmalı, oturum koparsa ikinci yönetici kontrol etmelidir. Session temizlemek aktif kullanıcıları kesebileceğinden otomatik adım yapılmamalıdır. Tanı sonunda geçici filtre, policy ve rota değişikliklerinin kalmadığı bağımsız olarak doğrulanmalıdır.

Çıkarılan Dersler

Kontrol Listesi

Onlarca subnet’i güvenlik duvarına eklemek ilk bakışta mekanik bir iştir. Tam da bu nedenle hata riski küçümsenir: bir octet yanlış yazılır, mevcut obje sessizce değiştirilir, grup üyeliği eksik kalır veya benzer isim başka VDOM’da farklı anlam taşır. CLI hızı artırır; fakat hızın kontrolsüzlüğe dönüşmemesi için girdinin kaynağı, isim standardı ve doğrulama çıktısı tasarımın parçası olmalıdır.

20 Temmuz 2026 tarihinde çok sayıda şube ağını ortak politika grubuna alma ihtiyacında, doğrudan üretim cihazına komut yapıştırmadık. IP planını temizledik, mevcut objelerle çakışmaları karşılaştırdık ve laboratuvar yapılandırmasında tekrar çalıştırılabilir bir komut seti hazırladık. Değişiklik öncesi yedek, kapsamlı diff, grup üyeliği kontrolü ve politika etkisi testiyle CLI işlemini denetlenebilir bir mini otomasyona dönüştürdük.

Sorunun ortaya çıkışı

Yeni şube ve kullanıcı subnetleri ortak erişim politikasına eklenmeliydi. GUI üzerinden tek tek obje oluşturmak zaman alıyor ve farklı yöneticilerin farklı ad/açıklama kullanmasına yol açıyordu. Kaynak liste elektronik tabloda tutulmuştu; bazı satırlarda host adresi, bazılarında CIDR ve bazılarında eski açıklama bulunuyordu. Listeyi doğrudan komuta dönüştürmek güvenilir değildi.

İş sadece adres objesi oluşturmakla bitmiyordu. Objelerin doğru VDOM’da, doğru tipte ve var olan grup içinde olması; grubun bağlı olduğu politikaların beklenmedik erişim açmaması gerekiyordu. Ayrıca aynı isimli mevcut bir objenin farklı subnet göstermesi halinde otomasyonun onu sessizce üzerine yazmaması şarttı. Başarı ölçütünü “CLI hata vermedi” yerine yapılandırma ve trafik sonucu olarak tanımladık.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım, `edit` komutunun her zaman yeni nesne oluşturacağıydı. Aynı ad varsa mevcut nesne düzenlenir; set komutları çalışan politikayı değiştirebilir. İkinci varsayım, grup için `set member` kullanmanın ekleme yapacağıydı. Bu kullanım mevcut üyeleri değiştirebilir; korunması gereken üyeler gözden kaçarsa geniş bir servis kesintisi oluşur. Komut semantiği sürüm dokümantasyonuyla doğrulanmalıdır.

Başka bir yanılgı, isim standardının kozmetik olduğuydu. Objede lokasyon, ağ rolü ve ortam anlaşılmıyorsa sonraki politika incelemesi zorlaşır; ancak isme bütün teknik ayrıntıyı doldurmak da değişiklikte yeniden adlandırma yükü yaratır. Açıklama ve yorum alanı sahiplik ile talep referansı için kullanılmalı, sır veya gerçek kişi bilgisi içermemelidir.

Teknik analiz

Kaynak liste şema kontrolünden geçirildi: benzersiz obje adı, geçerli ve ağ sınırına oturan CIDR, lokasyon kodu, iş sahibi ve hedef grup. Çakışan subnetler yalnızca metin eşitliğiyle değil ağ kapsaması açısından incelendi. FortiGate yapılandırmasındaki mevcut adresler ve gruplar salt okunur çıktıyla dışa alındı; ad ve değer farkları değişiklik öncesi raporlandı.

Komut üretimi deterministik sırada yapıldı. Her adres için edit, subnet, comment ve next blokları; grup için mevcut üyeleri koruyan açık üyelik listesi hazırlandı. CLI toplu çalıştırma öncesi desteklenen maksimum ad ve grup sınırları kontrol edildi. Değişiklik sonrası show çıktısı beklenen veriyle makine ve insan gözüyle karşılaştırıldı; politika hit ve lookup testi yapıldı.

# Dokümantasyon subnetleriyle güvenli şablon; üretim değerleri değildir
config firewall address
    edit "BRANCH-DEMO-USERS"
        set subnet 192.0.2.0 255.255.255.0
        set comment "Onaylı değişiklik kaydına bağlı örnek"
    next
end
# Grup üyeliğini değiştirmeden önce mevcut yapılandırmayı mutlaka okuyun.

Uygulanan çözüm veya önerilen mimari

Standart, büyük harfle kısa lokasyon kodu, ağ rolü ve ortam bileşenlerinden oluşturuldu; subnet değeri isim yerine obje alanında kaldı. Her obje açıklamasına kişisel veri içermeyen sahiplik ve değişiklik referansı eklendi. Üretim öncesi tam yapılandırma yedeği alındı, komut seti ikincil yönetici tarafından gözden geçirildi ve bakım penceresinde doğru VDOM bağlamında çalıştırıldı.

Grup üyelikleri değişiklik öncesi ve sonrası sıralı liste olarak karşılaştırıldı. Yeni subnetlerin beklenen politikaya eşleştiği policy lookup ile, izin verilmeyen hedeflere erişemediği negatif testle doğrulandı. Kaynak veri ile üretilen komut ve doğrulama raporu aynı değişiklik kaydında saklandı. Böylece sonraki toplu ekleme, eski dosyayı kopyalamak yerine güncel envanterden yeniden üretilebildi.

Alternatifler ve karar gerekçesi

GUI az sayıda obje için görsel doğrulama sağlar ve hata mesajlarını okumayı kolaylaştırır. Bu kapsamda tekrar sayısı fazla olduğu için tutarsızlık riski yükseliyordu. FortiManager veya API tabanlı otomasyon daha güçlü onay, şablon ve idempotency sağlayabilir; mevcut ölçek ve araç yetkinliğinde gözden geçirilmiş CLI seti en küçük güvenli adımdı.

Subnetleri tek bir büyük özet ağ objesiyle temsil etmek grup üyeliğini azaltabilirdi, fakat arada kuruma ait olmayan veya farklı güven bölgesinde kalan adresleri istemeden kapsayabilirdi. Açık subnet objeleri daha uzun ama denetlenebilirdi. Dinamik connector seçenekleri bulut kaynaklarında değerlidir; statik şube IP planı için kaynak envanter ve kontrollü obje grubu tercih edildi.

Güvenlik ve operasyonel riskler

Yanlış subnet maskesi beklenenden geniş kaynak grubuna erişim verebilir. Özellikle ağ adresine oturmayan girdiler normalize edilip sessizce farklı kapsam yaratabilir. Toplu komutlar yüksek ayrıcalıkla çalıştığı için kişisel yönetici hesabı, MFA korumalı yönetim ağı ve oturum kaydı kullanılmalıdır. Komut dosyasında parola, token veya gerçek dış erişim detayları bulunmamalıdır.

Geri dönüş yalnızca yeni objeleri silmek değildir; objeler politikada kullanılıyorsa silme başarısız olabilir veya ilişkiyi bozabilir. Önce eski grup üyeliği geri yüklenmeli, politika etkisi doğrulanmalı, sonra kullanılmayan objeler kontrollü kaldırılmalıdır. Ad standardı ve kaynak IP planı sahiplenilmezse birkaç ay içinde otomasyon yeniden dağınık veriye dönüşür; periyodik kullanılmayan obje gözden geçirmesi gerekir.

Çıkarılan Dersler

Kontrol Listesi

Yeni yayına alınmış bir kurumsal alan adı bazı kullanıcılarda açılırken güvenlik filtresi arkasında engellenebilir. İş birimi bunu kesinti, web ekibi DNS sorunu, güvenlik ekibi ise itibar kararı olarak görür. Üçü de kısmen haklı olabilir. False positive demeden önce alan adının gerçekten kuruma ait, doğru yapılandırılmış ve zararlı içerikten arınmış olduğunu kanıtlamak gerekir.

16 Temmuz 2026 tarihli olayda düşük yaş ve sınırlı itibar verisi nedeniyle bir alan adı istenmeyen kategoride değerlendiriliyordu. Global filtreyi kapatmak veya tüm kategoriyi allow yapmak yerine önce bağımsız DNS ve TLS kontrolleri yaptık, ürün günlüğündeki kategori kararını doğruladık. Yalnızca gerekli FQDN için süreli istisna açarken üreticiye kanıtlı yeniden sınıflandırma talebi gönderdik ve istisnaya kapanış tarihi verdik.

Sorunun ortaya çıkışı

Kurumsal duyuru sitesi yayına alındıktan sonra bazı lokasyonlarda güvenlik uyarısı ile engellendi. Mobil ağdan erişim mümkündü; kurum DNS güvenliği kullanan istemciler farklı bir yanıt veya block page alıyordu. Alan adı yeni olduğu için iş etkisi hızla büyüyor, iletişim ekibi hemen whitelist talep ediyordu. Ancak sahiplik ve teknik bütünlük kontrol edilmeden istisna vermek doğru değildi.

Olay kapsamı istemci, lokasyon, resolver ve zaman bilgisiyle çıkarıldı. Yalnızca ana alan adı mı, belirli alt alan mı ve yönlendirme zincirindeki üçüncü taraf hedef mi engelleniyor soruları ayrıldı. Gerçek alan adını genel destek ekranlarına taşımadan kanıtlar güvenli olay kaydında toplandı. Böylece “site açılmıyor” ifadesi belirli bir kategori kararıyla ilişkilendirildi.

İlk belirtiler ve yanlış varsayımlar

İlk varsayım, mobil ağda açılan sitenin otomatik olarak güvenli olduğuydu. Farklı resolver ve filtre politikası yalnızca engelin nerede olduğunu gösterir; içeriğin güvenliğini kanıtlamaz. İkinci varsayım kategori hatasının DNS kaydı hatasıyla aynı olduğuydu. Yanlış A/CNAME, süresi yaklaşan TLS sertifikası veya ele geçirilmiş içerik de güvenlik ürününün şüpheli kararını destekleyebilir.

Tüm “newly observed” veya “uncategorized” kategorisini izinli yapmak hızlı görünüyordu, ancak başka yeni ve riskli alanları da geçirirdi. Wildcard istisna da gereksiz alt alanları kapsayabilirdi. Sadece block page ekran görüntüsüne dayanmak yerine cihaz günlüğündeki kategori, profil, policy ve çözümleme sonucunu gördük. Tarayıcı önbelleği ve yerel DNS cache etkisini kontrollü tekrarlarla ayırdık.

Teknik analiz

Yetkili DNS zinciri, A/AAAA ve CNAME kayıtları, nameserver tutarlılığı ve DNSSEC kullanılıyorsa doğrulama durumu incelendi. TLS sertifikasının ad kapsamı, zinciri ve geçerlilik zamanı kontrol edildi. HTTP yönlendirmelerinin alan dışı beklenmeyen hedefe gitmediği doğrulandı. Web ekibi yayın dosyalarını ve yönetim hesaplarını gözden geçirdi; güvenlik taraması temiz sonuç vermeden false positive kararı verilmedi.

Güvenlik ürününde alanın mevcut kategorisi, ilk görülme/itibar bağlamı ve hangi DNS profili tarafından engellendiği belirlendi. Farklı resolver sonuçları TTL dikkate alınarak karşılaştırıldı. Ürün önbelleği ile istemci önbelleğinin ayrı süreleri olduğu unutulmadı. Aynı registrable domain altındaki servislerin iş amacı ve sahipliği kontrol edilerek istisna kapsamı yalnızca gereken tam alan adına indirildi.

# example.invalid gerçek bir hedef değildir; salt okunur doğrulama
nslookup portal.example.invalid
Resolve-DnsName portal.example.invalid -Type A
Resolve-DnsName portal.example.invalid -Type CNAME

Uygulanan çözüm veya önerilen mimari

Sahiplik, DNS, TLS ve içerik doğrulandıktan sonra yalnızca ihtiyaç duyulan FQDN için dar ve süreli bir allow override oluşturuldu. İstisna belirli güvenlik profiline uygulandı; tüm kullanıcı ve kategorileri kapsamadı. Değişiklik sahibi, iş gerekçesi, son kullanma tarihi ve geri alma adımı kaydedildi. Kullanıcılardan cache temizleme yerine TTL sonrası kontrollü yeniden test istendi.

Aynı anda üreticinin sınıflandırma portalına işlev, sahiplik ve teknik doğrulama kanıtlarıyla başvuru yapıldı. Kategori düzeltmesi farklı ağlardan doğrulandıktan sonra yerel istisna kaldırıldı ve block/allow sonucu tekrar test edildi. Yeni alan adı yayına alma kontrol listesine DNS güvenlik kategorisi, TLS izleme, alan sahipliği ve ön bildirim adımları eklendi; sorun lansman sonrası sürpriz olmaktan çıkarıldı.

Alternatifler ve karar gerekçesi

DNS Security profilini geçici kapatmak sorunu ayırabilirdi ama tüm alanlar için korumayı kaldırırdı. Test amacıyla yalnızca izole bir istemci ve kısa pencere kullanılabilse de üretim çözümü olamazdı. Hosts dosyasına kayıt eklemek kategori kontrolünü atlatabilir, DNS değişikliklerini gizler ve yönetilemez istemci sapması yaratır; bu nedenle kullanılmadı.

Yalnızca üretici yeniden sınıflandırmasını beklemek yerel riski en aza indirir fakat iş etkisi kabul edilemez süreye uzayabilirdi. Teknik güvenlik kanıtları tamamlandığı için süreli dar istisna ile üretici başvurusunu paralel yürüttük. Wildcard yerine exact FQDN seçimi biraz daha fazla bakım gerektirdi, ancak yetki alanını ölçülebilir tuttu ve yeni alt alanları otomatik güvenilir saymadı.

Güvenlik ve operasyonel riskler

Whitelist kalıcı güven damgası değildir. Alan adı daha sonra ele geçirilebilir, içerik veya DNS sağlayıcısı değişebilir. İstisnalar süreli olmalı, düzenli yeniden doğrulanmalı ve SIEM’de görünür kalmalıdır. Alan sahipliği yenileme hesabı, MFA ve registrar lock ile korunmalıdır. TLS sertifikası yalnızca şifreli bağlantıyı doğrular; içeriğin güvenli olduğunu tek başına kanıtlamaz.

Üreticiye gönderilen ekran görüntüsü ve günlüklerde gerçek kullanıcı, iç IP ve politika adı bulunabilir; paylaşım öncesi maskelenmelidir. Yeniden sınıflandırma küresel olduğundan yanlış kategori talebi başka müşterileri de etkileyebilir, açıklama dürüst ve kanıtlı olmalıdır. Override envanteri sahibi olmayan istisnalara dönüşürse güvenlik kontrolü zamanla aşınır; son kullanma uyarısı ve periyodik rapor zorunludur.

Çıkarılan Dersler

Kontrol Listesi

Siber güvenlik yol haritası ürün logolarıyla başladığında genellikle iki sonuç çıkar: aynı olayı gören fakat konuşmayan araçlar ve kimsenin düzenli işletmediği pahalı kontroller. Katmanlı güvenliğin anlamı daha fazla kutu satın almak değildir. Bir saldırı veya hata tek kontrolü geçtiğinde sonraki katmanın bunu önlemesi, tespit etmesi, etkisini sınırlaması ya da sistemi güvenilir biçimde kurtarmasıdır.

8 Haziran 2026 tarihinde orta ölçekli, çok lokasyonlu bir kurumun mimarisini olgunlaştırırken kullanıcıdan veriye kadar güven yollarını çıkardık. NGFW, EDR/XDR, e-posta güvenliği, kimlik, SIEM, MDR/SOC, DLP, PAM, WAF ve yedeklemeyi ayrı satınalma başlıkları yerine risk senaryolarındaki görevleriyle değerlendirdik. Her kontrol için veri kaynağı, sahibi, müdahale süresi, bağımlılık ve başarısızlık halinde telafi edici katman tanımladık.

Sorunun ortaya çıkışı

Kurumda yeni nesil güvenlik duvarı, uç nokta koruması ve yedekleme vardı; buna rağmen yönetim “ne kadar güvendeyiz?” sorusuna kanıtlı cevap alamıyordu. E-posta olayları ayrı, kimlik uyarıları ayrı ekipte kalıyor, kritik sunuculardaki ayrıcalıklı erişim kişisel bilgilerle yürüyordu. Kontrollerin varlığı biliniyor fakat kapsama oranı, alarm sahipliği ve kurtarma testi ortak görünümde izlenmiyordu.

İlk çalışma ürün envanteri değil, kritik iş hizmetleri ve olası etki senaryoları oldu. Kimlik ele geçirilmesi, zararlı e-posta, uç nokta ihlali, web uygulaması saldırısı, veri sızıntısı, ayrıcalık kötüye kullanımı ve fidye yazılımı sonrası kurtarma gibi yollar seçildi. Her senaryoda hangi kontrolün önlediği, hangisinin tespit ettiği ve karar verecek kişinin kim olduğu haritalandı.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım, EDR kurulu tüm cihazların yönetildiği ve korunduğuydu. Envanter karşılaştırması bazı cihazların ajan dışı, bazılarının güncel olmayan politika ile çalıştığını gösterdi. SIEM’e log göndermek de izleme anlamına gelmiyordu; zaman senkronu, ayrıştırma, use case, alarm eşiği ve müdahale sahibi yoksa veri yalnızca depolanıyordu. Lisans sayısı kontrol etkinliğini ölçmüyordu.

İkinci varsayım yedek varsa fidye yazılımı riskinin kapandığıydı. Aynı kimlik düzleminden silinebilen, geri dönüşü denenmemiş veya iş RTO’sunu karşılamayan kopya kurtarma katmanı değildir. MFA’nın tüm kimlik saldırılarını çözdüğü düşüncesi de eksikti; eski protokoller, hizmet hesapları, oturum çalma ve yardım masası süreçleri ayrıca korunmalıdır. Her güçlü kontrolün sınırı vardır.

Teknik analiz

Mimari altı yetenek etrafında analiz edildi: varlık ve kimlik bilgisi, koruma, tespit, müdahale, kurtarma ve yönetişim. NGFW segment ve kontrollü geçişi; e-posta güvenliği ilk teslim kanalını; EDR uç davranışını; NDR ağ anomalilerini; WAF web uygulama sınırını kapsıyordu. SIEM korelasyon sağlıyor, SOC/MDR insan ve süreçle alarmı karara dönüştürüyordu. Bu rollerin örtüşmesi boşluk kadar görünür kılındı.

Kimlik katmanında MFA, koşullu erişim, ayrıcalıklı hesap ayrımı, PAM ve yaşam döngüsü kontrol edildi. Veri katmanında sınıflandırma, DLP, erişim gözden geçirme, şifreleme ve değiştirilemez yedek ele alındı. Her kontrol için kapsam yüzdesi yerine doğrulanabilir sorular yazıldı: kritik cihaz telemetri gönderiyor mu, alarm denenmiş mi, müdahale runbook’u var mı, geri dönüş iş sahibi tarafından kabul edilmiş mi?

Uygulanan çözüm veya önerilen mimari

Öncelik temel hijyene verildi: güncel varlık envanteri, güvenli yapılandırma, zafiyet ve yama süreci, merkezi kimlik, MFA, en az yetki ve segmentasyon. İnternet sınırında NGFW ile e-posta/web kontrolleri, uçta EDR, kritik ağlarda ek görünürlük konumlandırıldı. Loglar SIEM’de kullanım senaryosuna göre toplandı; her kaynağı sınırsız almak yerine kimlik, endpoint, firewall, e-posta ve kritik uygulama olayları önceliklendirildi.

SOC/MDR için alarm sahipliği ve eskalasyon süreleri tanımlandı. PAM ayrıcalıklı oturumları, WAF internete açık uygulamaları, DLP doğrulanmış hassas veri akışlarını kapsayacak aşamalı plana alındı. Yedekleme ayrı kimlik, değiştirilemez kopya ve düzenli restore testiyle kurtarma katmanına dönüştürüldü. Kontroller masa başında değil güvenli masaüstü tatbikatı ve izinli doğrulama senaryolarıyla ölçüldü.

Alternatifler ve karar gerekçesi

Tek üreticili platform entegrasyon ve yönetim kolaylığı sunabilir, fakat tüm yeteneklerde aynı derinliği sağlamayabilir ve bağımlılık oluşturabilir. Best-of-breed yaklaşımı uzman özellikler getirir; entegrasyon, lisans ve yetkinlik maliyeti yükselir. Kurum için temel katmanlarda mevcut platform entegrasyonlarından yararlanıp kritik boşluklarda bağımsız ürün değerlendiren dengeli model seçildi.

İç SOC kurmak kurum bilgisini içeride tutar ancak vardiya, uzmanlık ve süreklilik gerektirir. Tam MDR dış kaynak modeli hızlı kapasite sağlar; bağlam ve karar hakları iyi tanımlanmazsa yalnızca alarm ileten hizmete dönüşebilir. Hibrit modelde kurum olay sahibi ve iş kararı vereni olarak kaldı, dış ekip 7/24 izleme ve ilk analiz sağladı. Seçim bütçeden önce çalışma modeliyle gerekçelendirildi.

Güvenlik ve operasyonel riskler

Katman sayısı arttıkça yanlış yapılandırma, entegrasyon kesintisi ve alarm yorgunluğu riski büyür. Aynı olayı üç ürünün bildirmesi üç kat güvenlik değil, korelasyon yoksa üç kat iş yüküdür. API ve servis hesapları en az yetkili olmalı, sırlar kasada dönmeli, log aktarımındaki kişisel veri ve saklama süresi hukuki gereksinimlerle yönetilmelidir.

Araçlar operasyon sahibi olmadan raf ömrü dolan lisanslara dönüşür. Her kontrolün RACI’si, bakım penceresi, kapasite izlemesi, sağlık alarmı ve devreden çıkarma planı olmalıdır. Güvenlik ürününün kendisi de yönetim ağı, MFA, yedek ve güncelleme ile korunmalıdır. Kurtarma planı saldırganın kimlik ve yönetim katmanına eriştiği varsayımıyla ayrıştırılmalı; test kanıtları yönetim kuruluna risk diliyle raporlanmalıdır.

Çıkarılan Dersler

Kontrol Listesi

Bir bütçe toplantısında beş farklı kısaltmanın beş ayrı güvenlik katmanı olduğu varsayılmıştı. Sunumlarda hepsi alarm üretiyor, korelasyon yapıyor ve tehditleri görünür kılıyordu; bu yüzden ürün sayısı arttıkça kapsamanın da aynı oranda artacağı düşünülüyordu. Oysa lisans listesini veri akışlarıyla eşleştirdiğimizde bazı kayıtların üç platforma gittiğini, kritik bir ağ bölümünden ise hiçbir anlamlı telemetri gelmediğini gördük.

Bu çalışma ilk olarak 22 Temmuz 2026 tarihinde bir güvenlik yatırım planını sadeleştirirken ele alındı. Temel soru hangi kısaltmanın daha gelişmiş olduğu değil, hangi riskin kim tarafından, hangi veriyle ve ne kadar sürede yönetileceğiydi. Bu ayrım yapılmadığında güçlü bir teknoloji yığını, bakılamayan alarm kuyruklarına dönüşebiliyor.

Sorunun ortaya çıkışı

Çok lokasyonlu kurumda uç nokta koruması yenilenirken eş zamanlı olarak merkezi loglama ve yönetilen izleme hizmeti gündeme geldi. Tedarikçi görüşmelerinde EDR ürününün davranış analizi, XDR platformunun korelasyonu, SIEM çözümünün log toplaması ve NDR sisteminin ağ görünürlüğü aynı olay örnekleriyle anlatılıyordu. Yönetim doğal olarak “Bunlardan biri diğerlerinin yerini tutmuyor mu?” diye sordu.

Sorunu ürün tablosundan önce varlık ve kontrol tablosuna çevirdik. İş istasyonları, sunucular, kimlik altyapısı, e-posta, güvenlik duvarı, bulut hizmetleri ve yönetilemeyen ağ cihazları için hangi telemetrinin üretildiğini işaretledik. Ardından tespit, inceleme, müdahale ve raporlama sorumlularını yazdık. Boşlukların önemli bölümü lisans değil; sahiplik, entegrasyon ve çalışma saatleriyle ilgiliydi.

İlk belirtiler ve yanlış varsayımlar

İlk belirti aynı olayın farklı önem dereceleriyle birden fazla konsolda görünmesiydi. Ekip bir alarmı EDR üzerinde kapatıyor, SIEM kaydı açık kalıyor, hizmet sağlayıcı ise ayrı bir vaka numarası oluşturuyordu. Ortalama müdahale süresi ölçümü güvenilmez hale gelirken vardiya devrinde olayın gerçek sahibi belirsizleşiyordu.

En yaygın yanlış varsayım XDR’nin her üreticiden gelen her veriyi doğal olarak anlayacağıydı. Bir diğeri SIEM kurulunca 7/24 izleme kapasitesinin de satın alınmış sayılmasıydı. MDR bir ürün kutusu değil, insan ve süreç içeren yönetilen hizmettir; kalitesi kapsama, erişim yetkisi, müdahale sınırı ve hizmet seviyesine bağlıdır. NDR ise şifreli trafik ve sensör konumu gibi fiziksel gerçeklerden etkilenir.

Teknik analiz

EDR, uç noktadaki süreç, dosya, kayıt defteri, kullanıcı ve bağlantı davranışını izler; gerektiğinde cihazı izole etme veya süreci durdurma gibi doğrudan müdahaleler sunar. NDR, ağ akışları ve uygun noktalardaki paket veya metadata üzerinden yönetilemeyen cihazları ve doğu-batı trafiğini görmeye çalışır. İkisi farklı kör noktaları kapatır; biri diğerinin basit yükseltmesi değildir.

SIEM çok farklı sistemlerden log alır, normalleştirir, saklar ve korelasyon kuralları çalıştırır. XDR genellikle belirli güvenlik ürünleri arasında daha hazır entegrasyon ve olay odaklı inceleme sağlar; açık ekosistem iddiası ürün bazında doğrulanmalıdır. MDR ise bu teknolojilerden birini veya birkaçını işleten uzman ekiptir. Değerlendirmede günlük veri hacmi, olay başına bağlam, API kısıtları, saklama, sorgu performansı ve müdahale yetkisini ayrı satırlar halinde ölçtük.

Uygulanan çözüm veya önerilen mimari

Önerilen mimaride önce uç nokta ve kimlik telemetrisi güvenilir hale getirildi. Kritik ağ kesimleri için NDR ihtiyacı, mevcut güvenlik duvarı ve akış kayıtlarının görünürlüğüyle karşılaştırıldı. SIEM’e her logu göndermek yerine tespit, denetim veya olay inceleme değeri olan kaynaklar alındı. XDR, doğal entegrasyon sağladığı alanda hızlı müdahale katmanı olarak konumlandı.

Her alarm türü için tek bir vaka sahibi ve kayıt sistemi belirlendi. MDR sağlayıcısının hangi koşulda yalnızca bildirim yapacağı, hangi koşulda cihaz izolasyonu önereceği ve acil durumda kime ulaşacağı yazılı hale getirildi. Üç aylık kullanım senaryoları; kimlik riski, zararlı süreç, olağandışı veri hareketi ve kritik yapılandırma değişikliği üzerinden test edildi. Böylece mimari ürün adlarından değil ölçülebilir kontrol zincirlerinden oluştu.

Alternatifler ve karar gerekçesi

Tek üretici ekosistemi daha az entegrasyon eforu ve daha tutarlı olay görünümü sağlayabilir. Buna karşılık lisans bağımlılığı, desteklenen veri kaynaklarının sınırı ve gelecekte geçiş maliyeti değerlendirilmelidir. En iyi ürünlerin ayrı ayrı seçildiği yaklaşım daha esnek olabilir; fakat entegrasyon, içerik geliştirme ve çoklu konsol yükünü kurum üstlenir.

Küçük bir ekip için iyi tanımlanmış MDR hizmeti, kullanılmayan gelişmiş SIEM özelliklerinden daha fazla sonuç verebilir. Büyük ve yetkin bir SOC ise ham telemetriye, uzun saklamaya ve özel analitik geliştirmeye ihtiyaç duyabilir. Kararı özellik sayısına göre değil, kapsanan senaryo başına toplam işletme yükü, kanıtlanmış entegrasyon ve müdahale süresi üzerinden verdik.

Güvenlik ve operasyonel riskler

Bu platformlar yüksek ayrıcalık, hassas telemetri ve bazen uzaktan müdahale yetkisi taşır. Yönetici hesaplarında güçlü MFA, rol ayrımı, denetim kaydı ve acil erişim prosedürü bulunmalıdır. Sensörlerin performans etkisi pilotta ölçülmeli; otomatik izolasyon gibi aksiyonlar kritik sunucularda kontrollü uygulanmalıdır. Logların bölgesel saklama ve kişisel veri gereksinimleri hukuk ve uyum ekipleriyle değerlendirilmelidir.

En büyük operasyonel risk alarm üretip işleyememektir. Kural bakımının durması, entegrasyon anahtarlarının süresinin dolması veya sensör kapsamının gerilemesi sessiz kör noktalar yaratır. Bu nedenle aylık kapsama raporu, veri kaynağı sağlık kontrolü, örnek olay doğrulaması ve hizmet sağlayıcı performans değerlendirmesi mimarinin zorunlu parçasıdır.

Çıkarılan Dersler

Kontrol Listesi

Yönetim sunumlarında güvenlik olgunluğu bazen bir ilerleme çubuğu gibi ele alınıyor: yeni ürün devreye girince yüzde birkaç artış bekleniyor. Sahada ise lisansı alınmış ama sensörleri eksik, alarmı sahipsiz veya raporu hiç incelenmeyen sistemlerle karşılaştım. Böyle bir yatırım bütçeyi tüketir, denetim tablosunda bir satırı doldurur; riski aynı ölçüde azaltmaz.

22 Temmuz 2026 tarihindeki bir yatırım değerlendirmesinde NDR, veritabanı aktivite izleme, oltalama simülasyonu, siber tatbikat ve BAS başlıklarının puana etkisini tartıştık. Tek bir tahmini oran vermek yerine her yatırımı kontrol yaşam döngüsüne bağladık. Bu yaklaşım, yönetimin teknoloji ile doğrulanmış kabiliyet arasındaki farkı görmesini sağladı.

Sorunun ortaya çıkışı

Kurum daha önce yapılan bir değerlendirmede belirli bir olgunluk seviyesinde konumlanmıştı. Sonraki bütçe döneminde çeşitli güvenlik ürünleri listeye eklendi ve hedef puanın ne kadar yükseleceği soruldu. Fakat başlangıç değerlendirmesindeki soruların bir kısmı politika, bir kısmı teknik kontrol, bir kısmı da olaylara müdahale yetkinliğiyle ilgiliydi. Ürün listesini doğrudan puana çevirmek metodolojik olarak doğru değildi.

Önce kullanılan çerçevenin kapsamını sabitledik. NIST CSF işlevleri ve kurumun kendi risk kayıtları üzerinden mevcut kontrol, hedef kontrol ve beklenen kanıt tanımlandı. “NDR alınacak” ifadesi yerine “kritik ağ bölümlerindeki olağandışı iletişim belirlenen sürede tespit edilip incelenecek” gibi sonuç cümleleri kuruldu. Böylece yatırımın hangi boşluğu kapatacağı tartışılabildi.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım lisans başlangıç tarihinin kontrolün etkinlik tarihi sayılmasıydı. Kurulum, entegrasyon, temel davranış öğrenme, kural ayarı, ekip eğitimi ve prosedür güncellemesi hesaba katılmıyordu. İkinci varsayım ise bütün ürünlerin birbirinden bağımsız puan getireceğiydi; oysa aynı tespit hedefini destekleyen iki araç aynı kontrolü iki kez olgunlaştırmaz.

Bir başka belirti, kanıt sorulduğunda yalnızca satınalma belgesinin gösterilmesiydi. Denetçi veya iç kontrol ekibi için geçerli kanıt; kapsama raporu, alarm kaydı, zamanında müdahale, test sonucu ve onaylı prosedür olabilir. Honeypot alarmı SOC kuyruğuna düşmüyorsa veya oltalama simülasyonunun ardından eğitim süreci çalışmıyorsa teknoloji ile süreç zinciri kopuktur.

Teknik analiz

Her kontrolü beş boyutta puanladık: tasarım, kapsam, işletim, ölçüm ve doğrulama. Tasarım kontrolün neyi engelleyeceğini veya tespit edeceğini açıklar. Kapsam, hedef varlıkların ne kadarının dahil olduğunu gösterir. İşletim; alarm sahipliği, vardiya ve eskalasyonu kapsar. Ölçüm, sonuçların eğilimini izler. Doğrulama ise örnekleme, tatbikat veya bağımsız test yoluyla kontrolün gerçekten çalıştığını kanıtlar.

Örneğin BAS, mevcut savunmaların bazı senaryolara verdiği tepkiyi sürekli ölçebilir; ancak eksik yamayı kapatmaz ve SOC personeli yerine geçmez. DAM hassas veritabanı faaliyetini görünür kılabilir; doğru kapsam ve ayrıcalıklı kullanıcı senaryoları olmadan gürültü üretir. NDR ağdaki anormallikleri gösterebilir; sensörün görmediği segment için puan iddia edilemez. Her yatırımın katkısı, bu sınırlara göre ağırlıklandırıldı.

Uygulanan çözüm veya önerilen mimari

Yol haritasını ürün bazlı değil kontrol bazlı hazırladık. Her satıra risk, mevcut seviye, hedef seviye, kontrol sahibi, teknik bağımlılık, hedef tarih ve kabul kanıtı eklendi. Teknoloji kurulumu tamamlanınca otomatik olarak kapanmayan bir geçiş kapısı oluşturuldu: kapsama hedefi sağlanacak, ekip eğitilecek, prosedür onaylanacak ve örnek bir olay uçtan uca işletilecekti.

Puan raporunda da tek sayı yerine güven aralığı ve alan bazlı görünüm kullandık. Kimlik, koruma, tespit, müdahale ve kurtarma yetenekleri ayrı gösterildi. Böylece güçlü endpoint kontrolü zayıf kurtarma kapasitesini gizlemedi. Çeyreklik yönetim toplantılarında harcanan bütçe değil, kapanan risk senaryosu ve sürdürülebilir kanıt sayısı konuşulmaya başlandı.

Alternatifler ve karar gerekçesi

Basit bir öz değerlendirme hızlı ve düşük maliyetlidir; ancak iyimser puanlama ve ekipler arası tutarsızlık riski taşır. Bağımsız değerlendirme daha güçlü güvence sunar, fakat bağlamı iyi aktarılmazsa kontrol listesi yaklaşımına sıkışabilir. Otomatik güvenlik puanları güncel yapılandırma sinyali verir; tüm iş süreçlerini, fiziksel kontrolleri veya kriz yönetimini kapsamaz.

Karma modeli seçtik: ekipler kanıtları topladı, kontrol sahipleri çapraz değerlendirme yaptı, kritik alanlar dönemsel olarak bağımsız doğrulandı. Üretici panellerindeki skorları faydalı operasyon göstergesi olarak kullandık fakat kurumsal olgunluk puanıyla eşitlemedik. Karar, uygulanabilirlik ile güvenilirlik arasında daha dengeli sonuç verdi.

Güvenlik ve operasyonel riskler

Puan hedefi yanlış teşvik yaratabilir. Ekipler zor fakat önemli iyileştirmeler yerine kolay puan getiren maddelere yönelebilir; istisnalar gizlenebilir veya kısmi kapsam tam uygulanmış gibi raporlanabilir. Bu nedenle puanın yanında açık riskler, kabul edilmiş istisnalar, kapsama oranı ve kanıt tarihi gösterilmelidir. Olgunluk hiçbir zaman mutlak güvenlik garantisi olarak sunulmamalıdır.

Yeni araçlar ek operasyon yükü, veri saklama sorumluluğu ve yüksek ayrıcalıklı entegrasyonlar getirir. Personel kapasitesi bütçeye dahil edilmezse kontrol zamanla zayıflar. Lisans yenileme, içerik bakımı, sensör sağlığı, veri kalitesi ve hizmet sağlayıcı bağımlılığı toplam sahip olma maliyetinde değerlendirilmelidir.

Çıkarılan Dersler

Kontrol Listesi