Cloudflare WAF Kullanırken Origin Sunucuyu Nasıl Korursunuz?

Bir web sitesinin DNS kaydı proxy arkasına alındığında trafik WAF üzerinden geçiyor ve ilk bakışta origin sunucu görünmez hale geliyor. Ancak daha önceki DNS kayıtları, e-posta başlıkları, sertifika geçmişi veya başka bir servis aynı adresi işaret ediyorsa origin bulunabilir. Güvenlik duvarı herkesten web trafiği kabul ediyorsa saldırgan WAF denetimlerini atlayarak doğrudan uygulamaya ulaşabilir.

Temmuz 2026 tarihli değerlendirmede WordPress benzeri bir kurumsal siteyi yalnızca ön katmanda değil, origin sınırında da koruyacak yaklaşımı ele aldık. Gerçek alan adı, ağ adresi ve kural ayrıntıları bu anlatımda yoktur. Amaç belirli bir üreticiyi koşulsuz önermek değil; CDN/WAF ile sunucu güvenliği arasındaki paylaşılan sorumluluğu doğru kurmaktır.

Sorunun ortaya çıkışı

Site Cloudflare proxy arkasında ve WAF kuralları aktifti. Buna rağmen origin erişim kayıtlarında beklenmeyen doğrudan istekler görülüyordu. İnceleme, web sunucusunun genel internetten bağlantı kabul ettiğini gösterdi. WAF yalnızca kendi üzerinden geçen trafiği değerlendirebildiği için doğrudan bağlantıların hız sınırlama, bot yönetimi ve uygulama kurallarından geçmediği anlaşıldı.

Yönetim erişimi ile yayın trafiği de aynı ağ yolunu kullanıyordu. Sunucuya bakım yapmak için geniş izin bırakılmış, bu izin zaman içinde kalıcı hale gelmişti. Ayrıca TLS ayarı ziyaretçi ile edge arasını koruyor, edge ile origin arasındaki doğrulama yeterince güçlü değildi. Sorunu tek bir firewall kuralıyla değil, trafik türlerini ve güven sınırlarını yeniden tanımlayarak çözmek gerekiyordu.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım turuncu proxy simgesinin origin adresini kalıcı olarak gizlediğiydi. DNS değişikliği gelecekteki sorguları etkiler; geçmiş kayıtları veya aynı altyapıdaki başka servisleri silemez. İkinci varsayım yalnızca Host başlığını kontrol etmenin yeterli olduğuydu. Bu başlık istemci tarafından üretilebilir ve tek başına isteğin güvenilir proxy katmanından geldiğini kanıtlamaz.

Doğrudan origin denemesinde sitenin açılması önemli belirtiydi, fakat test kontrollü ve yetkili biçimde yapılmalıdır. Yanlış teşhislerden biri bütün bilinmeyen trafiği uygulama katmanında engellemenin yeterli sayılmasıdır. Ağ sınırında kısıtlama yoksa sunucu yine bağlantı yükünü taşır. Diğeri ise yönetim panelini WAF arkasına koymanın güçlü kimlik ve ayrı yönetim politikası ihtiyacını kaldırdığı düşüncesidir.

Teknik analiz

Trafiği ziyaretçi-edge, edge-origin ve yönetici-origin olarak üç akışa ayırdık. Yayın portlarında origin güvenlik duvarının yalnızca hizmet sağlayıcının yayımladığı ve otomatik güncellenen ağ aralıklarını kabul etmesi hedeflendi. Bu liste sabit bir blog yazısından kopyalanmadı; resmi kaynaktan doğrulanan değişiklik süreciyle yönetildi. IPv4 ve IPv6, yük dengeleyici ve sağlık kontrolü ihtiyaçları birlikte ele alındı.

TLS modu edge ile origin arasında şifreleme ve sertifika doğrulaması sağlayacak şekilde seçildi. Buna ek olarak authenticated origin pull veya eşdeğer karşılıklı doğrulama seçeneği değerlendirildi. Uygulamanın gerçek istemci adresini yalnızca güvenilir proxy başlığından alması, diğer kaynakların gönderdiği benzer başlıkları kabul etmemesi sağlandı. Erişim kayıtlarında edge kimliği ile origin isteği ilişkilendirildi.

# Dağıtıma özel adres veya kural vermeyen örnek politika mantığı:
# 1. Resmi sağlayıcı ağ listesini doğrulanmış kaynaktan alın.
# 2. Geçici bir yönetim oturumuyla erişimi kaybetmeye karşı geri dönüş hazırlayın.
# 3. Yayın portlarında yalnızca proxy ve gerekli sağlık kontrolü kaynaklarını kabul edin.
# 4. Yönetim erişimini ayrı VPN/zero-trust yoluna taşıyın.
# 5. Yetkili dış noktadan doğrudan origin erişiminin reddedildiğini doğrulayın.

Uygulanan çözüm veya önerilen mimari

Yayın trafiği Cloudflare edge üzerinden origin’e ulaştı; origin güvenlik duvarı web bağlantılarını doğrulanmış proxy kaynaklarıyla sınırladı. Uçtan uca doğrulanan TLS kullanıldı ve mümkün olan ortamda origin bağlantısı ek sertifika doğrulamasıyla güçlendirildi. Sunucunun varsayılan sanal host’u bilinmeyen alan adlarına içerik sunmadı. DNS kayıtları aynı origin’i gösteren gereksiz servisler açısından temizlendi.

Yönetim paneli ve sunucu bakımı yayın yolundan ayrıldı. Yönetici erişimi kimlik tabanlı özel erişim, MFA ve sınırlı yetkiyle sağlandı; genel internete yönetim servisi açılmadı. WAF kuralı, WordPress güvenliği, eklenti güncellemeleri ve yedekleme devam etti. Origin kısıtlamasının uygulama yamalarının veya güçlü kimlik doğrulamanın yerine geçmediği özellikle dokümante edildi.

Alternatifler ve karar gerekçesi

Yalnızca sağlayıcı IP aralıklarına izin vermek basit ve güçlü bir ağ kontrolüdür; ancak liste değişiklikleri, sağlık kontrolleri ve çoklu sağlayıcı kullanımı operasyon gerektirir. Tünel tabanlı bağlantı origin’de genel giriş ihtiyacını azaltabilir ve adres gizliliğini güçlendirebilir, buna karşılık ek agent, bağımlılık ve kapasite planı getirir. Mevcut işletim yetkinliğine göre iki yaklaşım da geçerli olabilir.

mTLS veya authenticated origin pull, kaynak doğrulamasını IP listesinin ötesine taşır; sertifika yaşam döngüsü dikkatli yönetilmezse kesinti yaratabilir. Uygulama başlığına dayalı gizli değer kolay uygulanır fakat sızma ve yanlış yapılandırma riski nedeniyle tek kontrol olmamalıdır. Katmanlı modelde ağ kısıtı, TLS doğrulama ve uygulama sertleştirme birbirini tamamladığı için tercih edildi.

Güvenlik ve operasyonel riskler

Yanlış firewall değişikliği gerçek kullanıcı trafiğini veya yönetim erişimini kesebilir. Kurallar aşamalı uygulanmalı, resmi kaynak listeleri doğrulanmalı, IPv6 unutulmamalı ve geri dönüş yöntemi değişiklikten önce test edilmelidir. Sağlayıcı durumunda sorun olduğunda origin’i geçici olarak herkese açmak hızlı görünse de WAF bypass riskini büyütür; önceden tanımlı süreli acil durum prosedürü kullanılmalıdır.

Origin adresinin geçmişte açığa çıkmış olabileceği kabul edilmelidir. Adres değişikliği yardımcı olabilir fakat kalıcı kontrol değildir. Loglar gerçek istemci verisi içerebileceği için erişim ve saklama sınırlandırılmalıdır. WAF olayları ile origin günlükleri birlikte izlenmeli; proxy dışı reddedilen isteklerdeki artış araştırılmalıdır. Yedek origin veya felaket kurtarma uç noktası da aynı koruma standardına dahil edilmelidir.

Çıkarılan Dersler

Kontrol Listesi

Değiştirilemez yedek devreye alındığında “artık DR tamam” cümlesini sık duyarım. Oysa sağlam bir yedek kopyası, uygulamanın nerede çalışacağını, kullanıcıların nasıl bağlanacağını veya bağımlı servislerin hangi sırayla açılacağını cevaplamaz.

Kasım 2025 ile 22 Şubat 2026 arasındaki mimari çalışmada birincil veri merkezi, private cloud, DR ortamı ve immutable repository rolleri ayrıştırıldı. Her bileşenin farklı arızaya cevap verdiği, ancak ortak test programı olmadan hiçbirinin tek başına iş sürekliliği sağlamadığı görüldü.

Mimariyi yönetimle konuşurken üç somut senaryo kullandık: tek bir veritabanının yanlışlıkla silinmesi, ana veri merkezinin erişilemez olması ve yönetici kimliklerinin ele geçirilerek yedeklerin hedef alınması. İlk senaryo tarihsel ve tutarlı geri yükleme noktası, ikincisi çalışabilir alternatif kapasite, üçüncüsü ise yönetim düzlemi ayrımı ve değiştirilemezlik gerektiriyordu. Aynı ürün bu ihtiyaçların bazılarını destekleyebilir, fakat kontrol hedefleri birbirine karıştırılmamalıdır. Senaryo bazlı yaklaşım sayesinde “yedek var mı?” sorusu, “hangi olayda hangi kopyayı, kim, ne kadar sürede kullanacak?” sorusuna dönüştü.

Sorunun ortaya çıkışı

Kurum yedekleri değiştirilemez depoya taşırken ikinci lokasyonda iş yükü çalıştırmayı da planlıyordu. Yedek, replikasyon ve DR kavramları aynı proje adı altında kullanıldığı için yönetimin beklediği dönüş süresiyle teknik tasarım uyuşmuyordu.

Önce veri koruma ile hizmet kurtarma ayrıldı. Hangi veri kaybının kabul edilebilir olduğu RPO, hizmetin ne kadar sürede dönmesi gerektiği RTO ile ifade edildi. Bu hedefler uygulama sahipleri tarafından onaylanmadan teknoloji seçimine geçilmedi.

İlk belirtiler ve yanlış varsayımlar

Replika sistemin yedek olduğu sanılıyordu; kaynakta silinen veya bozulan veri replikaya da taşınabilir. Immutable kopyanın her felakette hızlı dönüş sağlayacağı varsayılıyordu; büyük veri hacmi, ağ kapasitesi ve yeniden kurulum süresi RTO’yu aşabilir.

Başarılı yedekleme işi de geri dönüş kanıtı değildir. Uygulama tutarlılığı, şifreleme anahtarı, DNS, kimlik, sertifika ve ağ bağımlılığı test edilmeden açılan sanal makine kullanılır hizmet anlamına gelmez.

Teknik analiz

Yedek veri noktası üretir; immutable katman bu noktaların belirli süre değiştirilmesini sınırlar. Replikasyon hazır kopyayı güncel tutar. DR ise altyapı, bağlantı, bağımlılık, runbook, karar yetkisi ve kullanıcı doğrulamasıyla hizmeti geri getirir. Katmanlar ayrı hata senaryolarına göre tasarlandı.

Her uygulama için veri kaynağı, bağımlı servis, yedek sıklığı, saklama, replikasyon, kurtarma sırası ve test yöntemi kaydedildi. Repository yönetim düzlemi ayrıldı; silme yetkileri ve saklama kilidi denetlendi.

Uygulanan çözüm veya önerilen mimari

3-2-1 yaklaşımını destekleyen, farklı hata alanlarında ve bir değiştirilemez kopya içeren katmanlı mimari kuruldu. Kritik iş yükleri için DR kapasitesi ayrıldı; daha düşük öncelikli sistemler yedekten geri yükleme planına alındı.

Runbook altyapı açılışından önce kimlik, DNS, ağ ve güvenlik bağımlılıklarını sıraladı. İzole kurtarma testleri üç aylık teknik doğrulama ve yıllık iş birimi tatbikatıyla yürütüldü. Ölçülen gerçek süreler hedef RTO ile karşılaştırıldı.

Alternatifler ve karar gerekçesi

Sürekli replikasyon düşük RPO sağlar fakat maliyet ve bozulma yayılımı riski getirir. Yedekten kurtarma daha ekonomik olabilir ancak büyük sistemlerde RTO uzar. Bulut DR esneklik sunar; veri çıkışı, bağımlılık, yetkinlik ve düzenli çalışma maliyeti değerlendirilmelidir.

Tek yöntem bütün uygulamalara uygulanmadı. İş etkisi yüksek sistemlere hazır kapasite, diğerlerine kademeli geri yükleme seçildi. Ürün adı değil ölçülen kurtarma hedefi karar ölçütü oldu.

Güvenlik ve operasyonel riskler

Yedek yöneticisi ile üretim yöneticisinin aynı kimlik alanına bağımlılığı fidye yazılımı etkisini büyütebilir. Ayrıcalıklar ayrılmalı, MFA ve değiştirilemezlik politikası korunmalı, silme girişimleri alarm üretmelidir.

Test edilmeyen runbook güncelliğini kaybeder. Lisans, DNS, sertifika ve üçüncü taraf bağlantıları kurtarmayı durdurabilir. Test verisi kişisel veri gereksinimlerine uygun korunmalı ve tatbikat üretim hizmetini riske atmamalıdır.

Çıkarılan Dersler

Kontrol Listesi

Felaket kurtarma toplantıları çoğu zaman kaç sanal makinenin replike edileceğiyle başlıyor. İlk sorduğum soru ise hangi iş sürecinin önce dönmesi gerektiğidir. Çünkü yüz sunucuyu yanlış sırada açmak, üç kritik hizmeti doğru sırada açmaktan daha az değerli olabilir.

22 Şubat 2026 tarihli çalışmada teknik envanteri iş etkisi analiziyle eşleştirdik. Uygulama sahibi, altyapı ekibi ve yönetim aynı “kritik” kelimesine farklı anlam verdiği için kararları ölçülebilir süre ve kabul edilebilir veri kaybıyla ifade ettik.

Atölyelerde “Bu sistem duramaz” cevabını doğrudan kabul etmedik; kesintinin bir saat, bir gün ve üç gün sonraki etkisini ayrı sorduk. Finansal kayıp tek ölçüt değildi. İş güvenliği, yasal bildirim, müşteri taahhüdü, üretim planı ve biriken manuel işlem yükü de değerlendirildi. Ayrıca geçici manuel yöntem gerçekten uygulanabilir mi, gereken form ve yetki çevrimdışı bulunabilir mi diye kontrol ettik. Bu görüşmeler bazı sistemlerin beklenenden daha kritik, bazılarının ise birkaç gün kontrollü biçimde bekleyebileceğini gösterdi. Sonuçta DR kapasitesi eşit dağıtılmadı; işin kritik yoluna ve doğrulanmış bağımlılıklara yönlendirildi.

Sorunun ortaya çıkışı

Çok sayıda uygulama DR kapsamına alınmak isteniyor, fakat iş önceliği ve bağımlılık bilgisi bulunmuyordu. Her sistem kritik işaretlenince kapasite ve proje maliyeti gerçekçi olmaktan çıktı.

BIA atölyelerinde süreç kesintisinin zaman içindeki etkisi, manuel çalışma alternatifi, veri kaybı toleransı ve mevzuat yükümlülüğü soruldu. Teknik ekip bu sonuçları servis ve altyapı bağımlılıklarına çevirdi.

İlk belirtiler ve yanlış varsayımlar

Uygulamanın açılması hizmetin dönmesi sayılıyordu. Kimlik, ağ, DNS, veri tabanı, dosya paylaşımı ve dış entegrasyon çalışmadan uygulama kullanılamaz. Her sistem için sıfıra yakın RPO/RTO istemek de teknik ve mali gerçekliği göz ardı eder.

DR lokasyonunun her senaryoda kullanılabilir olacağı varsayılamaz. Aynı kimlik bağımlılığı, ortak telekom güzergâhı veya bölgesel olay iki ortamı birden etkileyebilir. Personel erişimi ve karar yetkisi de tasarımın parçasıdır.

Teknik analiz

Servis kataloğu sunucu envanteriyle eşleştirildi. Her servis için sahip, kullanıcı grubu, veri kaynağı, upstream ve downstream bağımlılık, RPO, RTO, minimum kapasite ve doğrulama adımı yazıldı. Kritik yol diyagramı kurtarma dalgalarını belirledi.

Kapasite hesabı normal zirveyi kopyalamak yerine felaket anındaki minimum kabul edilebilir hizmete göre yapıldı. Ağ adresleme, isim çözümleme, sertifika, lisans ve üçüncü taraf izinleri test sorularına eklendi.

Uygulanan çözüm veya önerilen mimari

Servisler üç kurtarma dalgasına ayrıldı. Runbook teknik komut listesinden ibaret tutulmadı; karar, iletişim, bağımlılık kontrolü, iş birimi testi ve normale dönüş adımlarını içerdi.

Masa başı tatbikatla belirsiz roller bulundu, ardından izole teknik test yapıldı. Test sonucu gerçek RTO, veri noktası, başarısız bağımlılık ve düzeltme sahibiyle kaydedildi. Mimari bu ölçümlere göre güncellendi.

Alternatifler ve karar gerekçesi

Aktif-aktif, sıcak bekleme, pilot light ve yedekten geri yükleme farklı maliyet ve süre profillerine sahiptir. En pahalı model her iş yükü için en doğru model değildir. Uygulama mimarisi ve iş etkisi seçimde belirleyicidir.

Karma yaklaşım seçildi: en kritik servisler hazır kapasiteye, toleranslı servisler yedekten dönüşe bağlandı. Karar üretici özelliklerinden önce ölçülebilir iş hedefleriyle gerekçelendirildi.

Güvenlik ve operasyonel riskler

DR ortamı daha seyrek kullanıldığı için yama ve erişim açısından zayıf kalabilir. Üretimle aynı güvenlik tabanı, ayrıcalık kontrolü ve izleme uygulanmalıdır. Replikasyon zararlı değişikliği taşıyabileceğinden temiz kurtarma noktası korunmalıdır.

Eski iletişim listesi ve tek kişiye bağlı runbook tatbikatta başarısız olur. Roller yedeklenmeli, çevrimdışı erişilebilir kopyalar tutulmalı ve üçüncü tarafların kriz yükümlülükleri sözleşmede doğrulanmalıdır.

Çıkarılan Dersler

Kontrol Listesi

Bir sunucunun yedekleme konsolunda görünmesi, üzerindeki bütün SQL veritabanlarının korunduğunu göstermez. Named instance, farklı recovery model veya yeni eklenen uygulama veritabanı sessizce kapsam dışında kalabilir.

8 Temmuz 2026 tarihli vakada SQL Server 2022 named instance üzerindeki birden fazla uygulama veritabanı için günlük bulut yedeği talep edildi. Talebi doğrudan zamanlamaya çevirmek yerine instance, veritabanı, veri kaybı hedefi ve geri dönüş sorumluluğunu envanterledik.

Veritabanı korumasında sorumluluk sınırı açık değilse herkes kendi parçasının çalıştığını söyleyebilir: DBA bakım işinin başarılı olduğunu, altyapı ekibi dosyanın kopyalandığını, bulut ekibi nesnenin depoda bulunduğunu gösterir. Fakat geri yükleme anında doğru zincirin, sertifikanın ve uygulama bilgisinin bir arada olmadığı anlaşılabilir. Bu yüzden uçtan uca hizmet sahibi belirledik ve teknik kayıtları ortak kurtarma kanıtında birleştirdik. Yeni veritabanı açma prosedürüne de yedek sınıfı ve iş hedefi seçimini ekledik; koruma sonradan hatırlanan bir operasyon olmaktan çıktı.

Sorunun ortaya çıkışı

Talepte yalnızca sunucu adı bulunuyor, named instance ve veritabanı listesi yer almıyordu. Sistem veritabanları, uygulama veritabanları, recovery model ve bakım işlerinin sahibi belirsizdi. Günlük full yedek her uygulamanın RPO ihtiyacını karşılamayabilirdi.

DBA, uygulama sahibi, altyapı ve yedekleme ekibi ortak envanter oluşturdu. Her veritabanına iş sahibi, kritiklik, RPO/RTO, recovery model, boyut, büyüme ve saklama gereksinimi atandı.

İlk belirtiler ve yanlış varsayımlar

Named instance adına uzaktan erişilebilmesi için kullanılan keşif yöntemlerinin her ağda güvenilir olacağı sanılıyordu. Sabit bağlantı parametresi ve kontrollü envanter otomatik keşiften daha öngörülebilir olabilir. Tarayıcı servisini açmak varsayılan çözüm yapılmadı.

Full yedek almanın transaction log yönetimini gereksiz kıldığı da yanlıştı. Recovery model ve hedef RPO log yedeği ihtiyacını belirler. Dosyanın buluta kopyalanması, SQL tutarlılığı ve geri yüklenebilir zincir anlamına gelmez.

Teknik analiz

Savunmacı envanter sorgusu yalnızca yetkili DBA hesabıyla çalıştırıldı; sonuçlarda sır bulunmadı. Durum, recovery model ve son yedek zamanları merkezi kayıtla karşılaştırıldı. Yeni veritabanlarını algılayan günlük uyum kontrolü planlandı.

Full temel, differential değişim ve transaction log yedekleri hedeflere göre zincirlendi. CHECKSUM, yedek şifreleme, anahtar saklama, aktarım güvenliği ve offsite kopya değerlendirildi. Sistem veritabanları ile şifreleme sertifikalarının kurtarma ihtiyacı ayrıca ele alındı.

-- Yetkili DBA için savunmacı envanter örneği
SELECT name, state_desc, recovery_model_desc
FROM sys.databases
ORDER BY name;

Uygulanan çözüm veya önerilen mimari

Kritik veritabanları için full, differential ve log planı iş hedeflerine göre oluşturuldu; düşük kritiklikteki sistemlere daha sade plan uygulandı. Yedek dosyaları şifreli biçimde farklı hata alanına kopyalandı ve saklama politikası yasal gereksinimle sınırlandı.

Aylık otomatik doğrulamaya ek olarak dönemsel izole restore testi yapıldı. Test; veritabanını açma, tutarlılık kontrolü, uygulama sahibinin temel işlemi doğrulaması ve ölçülen süreyi kapsadı. Başarısız test operasyon kaydı olarak takip edildi.

Alternatifler ve karar gerekçesi

Native SQL yedekleri şeffaflık ve taşınabilirlik sunar; merkezi platformlar orkestrasyon, izleme ve offsite yönetimini kolaylaştırabilir. Sanal makine görüntüsü hızlı kurtarma sağlayabilir, fakat uygulama tutarlılığı ve noktasal dönüş ihtiyacı doğrulanmalıdır.

Tek araç bütün hedefleri karşılıyor varsayılmadı. SQL-aware yedek, güvenli offsite kopya ve düzenli restore testi birlikte seçildi. Karar lisans özelliğinden çok kanıtlanmış kurtarma zincirine dayandı.

Güvenlik ve operasyonel riskler

Yedekler üretim verisinin tam kopyasıdır. Servis hesabı en az yetkili olmalı, aktarım ve depolama şifrelenmeli, silme yetkisi ayrılmalı ve erişimler loglanmalıdır. Şifreleme anahtarı kaybolursa sağlam yedek kullanılamaz.

Log zincirinin kırılması, depolama doluluğu ve fark edilmeyen yeni veritabanı RPO’yu bozar. Alarm sahipliği ve kapasite eğilimi izlenmelidir. Restore testi üretim üzerine yapılmamalı; izole, yetkili ve veri gizliliğine uygun ortam kullanılmalıdır.

Çıkarılan Dersler

Kontrol Listesi