Origin’i Korumak: Cloudflare Authenticated Origin Pulls ve mTLS ile Gerçek Kaynak Doğrulaması

Hikâyenin Başlangıcı: Kaynağa Kadar Güven

Hiç başınıza geldi mi? Trafik yağ gibi akıyor, grafikler neşeyle kıpırdanıyor, derken bir gece yarısı uykunuzu bölen bir bildirim: “Origin yoğun istek alıyor.” Klasik; CDN katmanı taş gibi duruyor ama kaynağa biri kapı arkasından sızmaya çalışıyor. O an düşündüm, aslında çoğu yükümüzü bulutta hafifletiyoruz, katmanlar kuruyoruz, duvarlar çekiyoruz ama kaynağın gerçekten kime konuştuğunu garanti altına almak bazen es geçiliyor. “TLS var ya” diyoruz. Var da, sunucunun kimi kabul ettiğini ispatlayan şey her zaman ortada olmuyor. İşte tam burada Cloudflare’ın Authenticated Origin Pulls özelliği ve mTLS (karşılıklı TLS) sahneye çıkıyor.

Bugün seninle şu yolu yürümek istiyorum: Cloudflare üzerinden gelen isteğin gerçekten Cloudflare’dan geldiğini nasıl doğrularız, araya giren hınzır trafiği nasıl elimizin tersiyle iteriz ve mTLS’le bu ilişkiyi nasıl çift taraflı güvene dönüştürürüz. Mesela şöyle düşün: Kapıda bir görevli var ve “şifreyi bilen” herkesi içeri alıyor. Güzel. Ama bir de isteği getiren kişinin üzerinde özel bir rozet olsun, rozetin arkasında da imzasını doğrulayabileceğin bir sertifika zinciri. İşte bu yazıda, o rozeti nasıl takacağımızı, kaynağa “içeri sadece güvenilir elçi girsin” demeyi konuşacağız.

Sonuna geldiğinde şunları cebine koymuş olacaksın: Authenticated Origin Pulls nedir, mTLS nasıl kurulur, Nginx ya da Apache’de hangi tuşlara basman gerekir, sertifika yönetimini nasıl dert etmezsin, log ve hata senaryolarında nereden yakalasın. Kendi deneyimimce, parça parça öğrendiğim ipuçlarını da aralara serpiştireceğim. Hadi başlayalım.

Authenticated Origin Pulls: Kapıda Rozet Kontrolü

Cloudflare neden “kim çekti” diye soruyor?

Cloudflare önünde duran bir kalkan gibi. İstekler önce ona geliyor, o da gerekirse cache’den cevap veriyor ya da origin’e gidip çekiyor. Peki origin’e gidenin gerçekten Cloudflare olduğundan nasıl emin olacağız? IP listeleri var, evet. Ama IP kontrolü tek başına yeterli değil; çünkü ağda rota değişir, vekil katmanlar eklenir, bir anlık yanlış yapılandırma seni yanıltır. Authenticated Origin Pulls tam olarak bu yüzden var: Cloudflare, origin’e giderken bir istemci sertifikası sunar, origin de bu sertifikayı doğrular. Böylece “Bu istek Cloudflare’dan geliyor” demek laf olmaktan çıkar, kriptografik bir kanıta dönüşür.

Bazen şöyle soruluyor: “Cloudflare tarafında bir düğmeye basmak yetmiyor mu?” Yetiyor ve yetmiyor. Evet, Cloudflare panelinden ya da API ile AOP’yi açıyorsun ve Cloudflare bir istemci sertifikası ile geliyor. Ama esas mesele origin’de gereğini yapmak. Yani Nginx ya da Apache’ye “misafir sertifika göstermeyene servis yok” demeyi öğretmen gerekiyor. Basit; ama doğru yerleri sıkmadan, doğru zincirleri doğrulamak önemli.

Daha çok detayı merak edenler için Cloudflare’ın bu konudaki sayfası oldukça net: authenticated origin pulls dokümanı. Ama ben burada adım adım, “kurarken nerede tökezlenir” düzeyinde gidelim istiyorum.

mTLS: El Sıkışırken İki Tarafın da Kimliği Doğrulansın

Tek taraflı TLS, çift taraflı güven ve küçük fark

Normalde tarayıcı ile site konuşurken, tarayıcı sitenin sertifikasını doğrular. Site kendini ispatlar. Tarayıcı kendini ispatlamak zorunda değildir. İşte mTLS, “ben de benim diyenlerden misin?” diyerek istemciden de sertifika isteme halidir. Cloudflare bu noktada istemci rolünü üstlenir ve origin’e sertifika sunar. Origin de, “tamam, bu sertifika benim güvenilir listemde” diyerek trafiği kabul eder. Böylece sadece “şifreli” olmakla kalmaz, kimlik doğrulaması çift taraflı yapılmış olur.

Güzel yanı şu: AOP ve mTLS birleştiğinde, CDN’den gelmeyen bir istek doğrudan origin’e ulaşsa bile reddedilir. Bir yerde IP bir şeyler karışsa ya da DNS’te anlık bir şaşa yaşansa, konfigürasyonda sıkılan tek bir vida ile “origin sahasına yabancı giremez” diyebilirsin. Ben bunu özellikle staging ve prod ayrımında rahatlatıcı buluyorum. Çünkü zaman zaman test ortamları yanlışlıkla dışa açılır, o anda mTLS kafanı kurtarır.

Cloudflare’ın istemci sertifikalarıyla ilgili sayfasına da bakmanı öneririm: Cloudflare client sertifikaları. Burada mantık sade; önemli olan, origin’in sertifika zincirini doğru tanıması.

Kurulumun Mantığı: Nginx ve Apache Üzerinden Yürüyelim

“Mesela şöyle düşünün…” dizisini açalım

Mesela şöyle düşünün: Nginx’te bir sunucu bloğunuz var ve yalnızca Cloudflare’dan gelen isteği kabul etmek istiyorsunuz. Bunun için iki ana şey yaparsınız. Birincisi, client sertifikasını zorunlu kılarsınız. İkincisi, bu sertifikayı kime güveneceğinizi söyleyen bir “trust store” gösterirsiniz. Cloudflare’ın yayınladığı istemci sertifikasını veya sertifika otoritesini Nginx’e tanıtırsınız. Sonra, “sertifikayı doğrulayamadıysan 400 ile kapat” dersiniz. Bu kadar.

Apache için de benzer. Mod_ssl ile istemci sertifikasını zorunlu hale getirip doğrulamayı açarsınız. Burada dikkat edilecek bir nokta, ara sertifikalar ve zincirin tamamı. Nginx bazen “trusted_certificate” altında tam zinciri görmek ister. Apache de aynı şekilde “SSLCACertificateFile” için doğru dosya ister. Yanlış dosyayı gösterdiğinizde, her şey doğru gibi görünür ama istekleriniz 400’lenir. İlk denemelerde en çok burada tökezleniyor.

Bir de küçük ama önemli bir ayrıntı: HTTP/2 ve HTTP/3 kullanan Cloudflare akışında bazen proxy protokolleri ve başlıklar farklı davranır. mTLS tarafı için kritik olmasa da, log’larda aradığınız IP’yi bulamayınca paniğe gerek yok. X-Forwarded-For veya CF-Connecting-IP gibi başlıklara bakıp gerçek istemciyi, TLS katmanında da sertifika doğrulama sonuçlarını ayrı düşünün. AOP, origin’e “isteği ben getiriyorum” diyor; istemci kimliği başka bir hikâye.

Sertifika Yönetimi: Döngü, Otomasyon ve Rahat Nefes

Rutin bir iş haline getirmek

İşin güzel yanı, bu sertifikalar devasa bir kargaşa yaratmıyor. Ama doğru bir otomasyon kurmazsan, zamanla küçük hatalar büyüyor. Bir projede ilk kez mTLS açtığımda “bir daha uğraşmam” diye düşünmüştüm; üç ay sonra sertifika yenileme tarihi geldiğinde, “hangi dosyaydı, hangi klasördeydi” diye loglarda gezindim. O gün bugün, konfigürasyon dosyalarına yorum satırları eklemeyi ve sertifika yollarını sistemde mantıklı yerlere yerleştirmeyi alışkanlık haline getirdim.

Eğer kendi iç servislerin için istemci sertifikası üretip döndürüyorsan, ACME ile tanışıklığın varsa bu iş iyice tatlı hale gelir. ACME’ye dayalı bir akışta, yenileme işi bir cron’a bakar ve kesintisiz rotasyon mümkün olur. Konuyla ilgili daha geniş bir senaryoyu, sertifika otoritelerini yedeklemek ve limitlere takılmadan yenilemek başlıklarıyla birlikte şu yazıda detaylandırmıştım: ACME otomasyonunda yedekli CA kurma ve fallback ile güvenli ölçekleme. Buradaki mantığı mTLS tarafına da uyarlayabilirsin.

Cloudflare’ın kendi istemci sertifikaları için yönetim adımları basit. Ancak origin’in kabul ettiği trust store’u da güncel tutman gerekiyor. Küçük bir ipucu: Sertifika dosyalarını ayrı bir dizinde tutup “current.pem” gibi bir sembolik link ile Nginx/Apache konfigürasyonuna gösterirsen, yenilemede yalnızca linki güncelleyip servis yeniden yüklemesi ile tertemiz bir geçiş yaparsın. Böylece “dosya adı değişti, konfigürasyon kırıldı” riskini de sıfırlarsın.

Gerçek Hayattan Aksaklıklar: Nerede Takılır, Nasıl Çözülür?

Hata 400… Ama neden?

İlk açtığında en sık göreceğin şey 400 hatasıdır. mTLS zorunlu ise ve istemci sertifikası bekleniyorsa, Cloudflare tarafında AOP aktif değilse istekler patır patır geri döner. Panik yok. Önce Cloudflare panelinde zone veya hostname düzeyinde Authenticated Origin Pulls gerçekten açık mı bak. İkinci adımda, origin üzerinde doğru CA/sertifika zincirine referans verip vermediğini kontrol et. Log’larda “unknown ca” veya “no required SSL certificate was sent” gibi mesajlar görürsün; ikisi farklı sorunu işaret eder. Biri “sertifika geldi ama tanımıyorum”, diğeri “sertifika gelmedi” diyor.

Bazen, kaynakta başka bir şey daha devreye girer: WAF ya da rate limiting gibi katmanlar. AOP ve mTLS sağlıklı olsa bile üstteki kurallar “ben bu pattern’i sevmiyorum” diyerek trafiği kısıverir. O yüzden sorun giderirken katmanları tek tek eleyerek ilerle. Ben, mTLS’i kurduğum günlerde akses logları bir ekranda, error logları ayrı bir ekranda açıyorum. Cloudflare tarafında da etkinlik günlüğüne bakıp, “istek bana geldi mi, ben gönderdim mi” izini sürüyorum.

Bu arada, Cloudflare’ın dokümantasyon örnekleri ile birebir gitmeye çalışırken, sunucunun OpenSSL sürümü ya da derleme parametreleri gibi küçük farklar bazen sürpriz çıkarabiliyor. Çok teknik detaylara girmeden şunu söyleyeyim: Eğer Nginx’te beklenmedik bir davranış görüyorsan, “ssl_verify_client on” gibi direktiflerin doğru blokta olduğundan ve “ssl_client_certificate” ile “ssl_trusted_certificate” ayrımını doğru yaptığından emin ol. Apache’de de benzer şekilde “SSLVerifyClient require” ve “SSLCACertificateFile” kombinasyonu doğru yerde mi, bunu kontrol et.

AOP mi, mTLS mi, Yoksa İkisi Birlikte mi?

Katmanlı güvenin tadı

Authenticated Origin Pulls aslında mTLS’in pratik hayata geçirilmiş, Cloudflare’a özgü bir kullanım şekli. İstediğinde bir adım ileri gidip, tam teşekküllü mTLS ile özel istemci sertifikan üzerinden daha sıkı bir doğrulama yapabilirsin. Bazı kurulumlarda AOP yeterli gelir; çünkü Cloudflare, kendi istemci sertifikasıyla zaten “benim” diyor. Bazılarında ise kurum politikaları, özel bir CA’dan imzalanmış müşteriye özgü istemci sertifikası ister. İkisi de mümkün. Asıl kritik olan, “origin’e doğrudan istek kabul etmiyorum” ilkesini sağlamlaştırmak.

Benim yaklaşımım şu oldu: Önce AOP ile temel kilidi takıyorum. Sonra, ihtiyaç varsa mTLS’i özelleştirip, belirli hostname’lerde çok daha sıkı doğrulama şartı koyuyorum. Böylece riskli uygulamalarda güveni artırırken, daha az kritik olanlarda esnek kalıyorum. Bu denge, ekiplerin özgüvenini de artırıyor. Çünkü herkes bilir ki, katmanların her biri ayrı ayrı koruyor ve biri şaşarsa diğeri tutuyor.

DNS, Anycast, ve Yol Boyunca Güven

Yönlendiren sistemler, şaşırtmayan doğrulama

Güven işini yalnızca TLS katmanına yığmak zorunda değilsin. DNS tarafında doğru kurgulanmış bir yerleşim, failover senaryolarında başına iş açmaz. Katmanlı güvenin en güzel yanı, bir yerde esneme olsa bile tüm sistem ayakta kalır. Çok sağlayıcılı DNS geçişleri yapıyorsan, mTLS ve AOP ile aynı anda oynadığında bile hizmet akmaya devam eder. Bu konuyu farklı bağlamda anlatırken, zero-downtime geçişlerin nasıl tatlı tatlı yürüdüğünü şu rehberde toplamıştım. İlgini çekerse, octoDNS ile dayanıklı geçiş akışı örnekleri güzel esin veriyor.

Yolun kendisi kadar, yoldaki tabelalar da önemli. Origin kimliğini doğrularken, DNS ve yönlendirme tarafındaki etiketleri de düzenli tutarsan, sorun anında “ağ mı, TLS mi, uygulama mı” diye gezinmezsin. Kendi pratiğimde, hata anında parçalayıcı sorular sormayı alışkanlık edindim: İstek bana geldi mi? Ben ona geri döndüm mü? Dönemediysem nerede takıldım? Bu küçük checklist, log’ların arasında kaybolmayı engelliyor.

Cloudflare Tunnel, Private Network ve mTLS: Perde Arkası Büyüsü

Kalabalıklaşan topolojilerde sade kalmak

Bazen origin doğrudan internete çıkmak zorunda değildir. Cloudflare Tunnel, arka uçtaki servisin üzerine bir tünel açarak “public IP yok, ama dünya erişebiliyor” konforu sağlar. Tünelin arkasına mTLS ve AOP eklediğinde, üç katmanlı bir huzur elde edersin. Dışarıdan bakan “kapı yok” der, içerideki “gelen kim” sorusunun cevabı da nettir. Cloudflare One tarafındaki mTLS kurgularına göz atmak istersen, private network ve mTLS notları iyi bir rehber olur.

Bu yaklaşımı seviyorum, çünkü ekipler büyüdükçe dokunulan yer sayısı artıyor. Tünel üzerinde tutarlı politikalar, origin üzerinde zorunlu mTLS ve Cloudflare katmanında AOP açıldığında, yeni eklenen servislerde “varsayılan güvenli” başlıyoruz. Sonradan açık kapı aramak yerine, kapıları baştan sadece doğru anahtarla açılır kuruyoruz.

Performans, Önbellek ve “Ya Yavaşlarsa?” Endişesi

Güven + hız, güzel bir ikili

Güven deyince akla bazen yavaşlık gelir. Oysa AOP ve mTLS, doğru kurulduğunda gözle görünür bir yavaşlık yaratmaz. Çünkü sertifika doğrulaması el sıkışma sırasında bir kez yapılır ve bağlantı devam ettikçe bir daha aynı masrafa girmezsin. Üstelik Cloudflare zaten önbellek üzerinde güçlü. Origin’e sadece gerektiğinde gidiyor. Bu yüzden “ekstra güven, ekstra gecikme” korkusu genelde boşa çıkar. Benim gördüğüm, yavaşlık şikâyetleri daha çok yanlış yönlendirmeler veya gereksiz yeniden el sıkışmalardan geliyor. Keepalive ve doğru TLS ayarları burada kurtarıcıdır.

Bir de küçük bir not: Sertifikaları doğrularken zinciri diskten okuma veya yükleme biçimi de mikro farklar yaratır. Eğer çok yoğun trafikte milisaniyelerin peşindeysen, Nginx’in yükleme düzenini ve açık dosya sınırlarını gözden geçir. Ama çoğu uygulamada bu kadarcık ayrıntıya inmeye gerek kalmıyor. Önce sağlam doğrulama, sonra gerekiyorsa cilalama.

Uygulamalı Yol Haritası: Sıfırdan Canlıya

Basit adımlar, akıcı kurulum

Ben yeni bir projede şunu yapıyorum. Bir: Cloudflare’da ilgili hostname için Authenticated Origin Pulls’u açıyorum. İki: Origin sunucuda Nginx veya Apache konfigürasyonunda istemci sertifikasını zorunlu kılıyorum ve Cloudflare’ın yayımladığı sertifika/CA’yı güvenilen listeye ekliyorum. Üç: Test için staging bir hostname üzerinde deniyorum, üretim trafiğini akıtıp log’ları izliyorum. Dört: Sertifika dosya yollarını netleştirip rotasyon stratejisini yazıyorum. Beş: Alarm ve gözlemi ekliyorum; mTLS doğrulama hataları için anlamlı uyarı şart.

Bu akış taş gibi duruyor. Çünkü bir defa kurduktan sonra işler rutine biniyor. Sürprizleri seviyorsan ayrı, ama üretim ortamı sürpriz sevmez. Her şeyin adı sanı belli olsun, yenileme tarihleri ve dosya yolları ortada olsun, hata anında kimin neye bakacağı belli olsun. Bu kadar. Sen de bir süre sonra “AOP ve mTLS bizim için varsayılan” demeye başlıyorsun.

Güvenlik Kültürü: Küçük Alışkanlıkların Büyük Etkisi

Günün sonunda insan, süreç ve ufak dokunuşlar

AOP ve mTLS birer araç. Asıl mesele, bu araçları gündelik çalışma biçiminin parçası yapmak. Konfigürasyon değişiklikleri için kod inceleme zorunluluğu, prod’a çıkarken küçük bir checklist, sertifika yenileme alarmı ve log’ların düzenli gözden geçirilmesi… Bu küçük alışkanlıklar zinciri, pahalı sorunların önüne geçiyor. Ben bir yerde “neden böyle oldu” diye soruyorsam, çok büyük ihtimalle süreçte küçük bir boşluk bırakmışımdır. Kapattıkça ferahlarsın.

İstersen bu çemberi daha da güçlendirmek için, uygulama katmanında ek başlık doğrulamaları ya da imza kontrolü yapabilirsin. Ama unutma, önce temel güven oturmalı. AOP ve mTLS o temel. Üzerine eklediğin her şey, zaten iyi olanı daha iyi hale getirir. Yeter ki karmaşayı büyütme. Sade kal, anlaşılır kal.

Kapanış: Origin’in Kapısını Doğru Anahtarla Aç

Toparlayalım ve küçük bir veda

Bugün şunu konuştuk: Origin’i gerçekten kimin aradığını bilmek, gecenin bir yarısı gelen “trafik arttı” mesajına sakince bakabilmenin anahtarı. Cloudflare Authenticated Origin Pulls ile Cloudflare’ın gerçekten o olduğunu, mTLS ile de bu ilişkinin çift taraflı güvene dayandığını gördük. Nginx ve Apache’de küçük dokunuşlarla, doğru sertifika zincirini işaret ederek ve basit bir otomasyonla bu yapıyı kurabilirsin. Testi staging’de yap, log’larını izle, hatayı okurken katman katman düşün. Bitti gitti.

Pratik tavsiye: Sertifika yollarını yalın tut, yenilemeyi otomatikleştir, alarm kur, dokümantasyonunu iki satırla bile olsa güncel bırak. Bir de ufak bir hatırlatma; eğer ACME’yi seviyorsan, mTLS tarafındaki sertifika yenilemelerini de aynı disipline çekmek işleri çok kolaylaştırıyor. Cloudflare’ın AOP sayfasına ve istemci sertifikaları notlarına göz atmayı da unutma. Umarım bu yazı sana yol gösterici olmuştur. Soruların olursa her zaman beklerim; bir sonraki yazıda görüşmek üzere.