Web uygulamaları oturum, kullanıcı tercihi, işlem bağlamı ve bazen yetki ipuçlarını çerezler üzerinden taşır. Sorun şudur: çerez istemci tarafında tutulur, tarayıcı araçlarıyla görülebilir, kopyalanabilir ve değiştirilebilir. Değer düz metin veya tahmin edilebilir formattaysa, saldırgan için çerez yalnızca taşıyıcı değil, manipüle edilebilir bir kontrol yüzeyidir.
Geleneksel yaklaşım bu sorunu uygulama kodunda çözmeye çalışır. Geliştirici her kritik çerezi ayrıca imzalar, şifreler, doğrular ve hata durumunu yönetir. Ancak büyük kurumlarda uygulamalar farklı ekipler, farklı teknolojiler ve farklı yaşlardaki kod tabanlarıyla çalışır. Her uygulamaya aynı güvenlik disiplinini sonradan eklemek pratik değildir.
Yalnızca güvenlik bayrakları da yeterli değildir. Secure, HttpOnly ve SameSite gibi ayarlar çerezin nasıl taşınacağını ve hangi bağlamda kullanılacağını düzenler; ancak çerez değerinin istemci tarafından görülmesini veya anlamlı biçimde değiştirilmesini tek başına çözmez. Değer korunmuyorsa, taşıma güvenliği ile içerik güvenliği birbirine karıştırılmış olur.
Doğru yaklaşım, kritik çerez değerlerini istemci tarafında anlamsız hale getirmek, fakat kurum servisi tarafında uygulama davranışını bozmamaktır. Kural, hangi çerezlerin korunacağını liste bazlı seçebilmeli, response tarafında şifreleme ve request tarafında çözme işlemini şeffaf yürütmelidir.
TR7 Çerez Şifreleme Kuralı bu boşluğu kapatır: kurum servisi kodunu değiştirmeden, seçilen çerez değerlerini istemciye karşı okunamaz ve kurcalamaya dayanıksız hale getirir.
TR7, çerez şifrelemeyi uygulama koduna gömülü bir özellik değil, merkezi trafik ve güvenlik kuralı olarak uygular.
Seçilen çerezlerin value alanı response yönünde şifrelenir ve istemciye yalnızca şifreli değer gönderilir. Request yönünde değer çözülerek kurum servisine beklediği çerez formatı iletilir.
Operatör tüm çerezleri kör biçimde işlemek yerine korunacak çerez adlarını açıkça tanımlar. Bu sayede yalnızca oturum, yetki veya hassas iş bağlamı taşıyan çerezler politikaya alınır.
Şifreleme ve çözme işlemi TR7 katmanında yapılır. Kurum servisi çerezi kendi beklediği formatta görür; istemci tarafında ise gerçek değer gizlenmiş olur.
İstemcinin şifreli değeri bozması veya kendi değeriyle değiştirmesi durumunda çözme ve doğrulama akışı başarısız olur. Böylece çerez tampering denemeleri kurum servisine normal oturum verisi gibi taşınmaz.
Çerez Şifreleme Kuralı, seçilen çerezlerin istemci tarafındaki gizliliğini ve bütünlüğünü merkezi bir ADC/WAAP politikasıyla güçlendirir.
TR7, seçilen çerezlerin value alanını AES-256 ile şifreleyerek istemci tarafında okunamaz hale getirir. Tarayıcı, güvenlik aracı veya kullanıcı yalnızca şifrelenmiş değeri görür. Bu, oturum kimliği veya uygulama bağlamı taşıyan çerezlerin düz metin olarak sızmasını azaltır. Şifreleme edge katmanında uygulandığı için uygulama geliştiricisinin her çerez için ayrı kod yazması gerekmez.
Response tarafında kurum servisinden gelen seçili çerezler şifrelenerek istemciye gönderilir. Request tarafında istemciden dönen şifreli çerezler çözülür ve kurum servisine beklenen açık değerle aktarılır. Bu çift yönlü model, uygulama davranışını değiştirmeden istemci tarafındaki değeri korur. Kullanıcı deneyimi aynı kalırken çerez içeriğinin kontrolü TR7 üzerinde merkezileşir.
Operatör hangi çerezlerin şifreleneceğini liste bazlı tanımlar. Oturum, kullanıcı bağlamı, işlem durumu veya hassas uygulama verisi taşıyan çerezler seçilir; sıradan tercih çerezleri dışarıda bırakılabilir. Bu kontrollü kapsam, gereksiz işlem maliyetini azaltır ve politika davranışını öngörülebilir kılar. Farklı vService veya havuzlar için farklı çerez listeleri kullanılabilir.
Kural, aynı havuz üzerinde bir kez uygulanacak şekilde tasarlanır. Bu yapı, aynı çerez değerinin trafik zincirinde tekrar tekrar şifrelenmesi gibi operasyonel hataları önler. Özellikle birden fazla kuralın veya katmanın devreye girdiği yapılarda deterministik davranış sağlar. Operasyon ekibi hangi havuzda hangi çerez politikasının geçerli olduğunu daha net yönetir.
İstemci, şifrelenmiş çerez değerini değiştirirse çözme işlemi beklenen sonucu üretmez. Bu durumda çerez normal ve güvenilir bir oturum verisi gibi kurum servisine aktarılmaz. Böylece saldırganın rol, tenant, oturum veya işlem bağlamı gibi alanları elle değiştirerek uygulama davranışını manipüle etmesi zorlaştırılır. Politika, çerez bütünlüğünü uygulama koduna bırakmadan edge seviyesinde kontrol eder.
Çerez Şifreleme Kuralı hem uygulama teslimi hem web uygulama ve API koruması senaryolarına yerleşir. ADC tarafında trafik akışını bozmadan çerez dönüşümü yapılır; WAAP tarafında ise oturum ve istek güvenliğiyle birlikte değerlendirilebilir. Bu ortak kullanım, çerez güvenliğini ayrı ürün veya ayrı kod parçası olmaktan çıkarır. Politika, TR7 üzerinde merkezi olarak tanımlanır ve ilgili servislerin önünde tutarlı biçimde uygulanır.
Eski uygulamalarda çerez güvenliği çoğu zaman kod değişikliği, test süreci ve sürüm yayını gerektirir. TR7, bu yükü azaltarak çerez değerini uygulama dışında korumaya alır. Kurum servisi çerezi kendi alıştığı formatta görmeye devam ettiği için büyük yeniden geliştirme ihtiyacı doğmaz. Bu, özellikle finans, sağlık ve kamu gibi değişiklik maliyeti yüksek ortamlarda pratik bir güvenlik kazanımı sağlar.
Çerez şifreleme kuralı; anahtar yönetimi, hata davranışı, audit, yüksek erişilebilirlik ve servis uyumluluğu dikkate alınarak işletilir.
Şifreleme politikasının güvenliği kullanılan anahtarların korunmasına bağlıdır. TR7 üzerinde anahtarların merkezi, kontrollü ve yetkili erişimle yönetilmesi gerekir. Anahtar değişimi planlanırken aktif oturumlar, kademeli geçiş ve geri dönüş senaryoları birlikte değerlendirilmelidir.
Birden fazla TR7 düğümünün çalıştığı yapılarda aynı politika ve anahtar bilgisinin tutarlı olması gerekir. Aksi halde bir düğümün şifrelediği çerezi diğer düğüm çözemeyebilir. Bu nedenle çerez şifreleme, küme yapılandırması ve konfigürasyon senkronizasyonuyla birlikte ele alınmalıdır.
Bozuk, eksik veya çözülemeyen çerezlerde sistemin nasıl davranacağı politika seviyesinde netleştirilmelidir. Kritik oturum çerezlerinde güvenli seçenek isteği reddetmek veya oturumu yeniden başlatmaya zorlamaktır. Daha düşük riskli çerezlerde uygulama ihtiyacına göre çerezi düşürme veya varsayılan akışa bırakma tercih edilebilir.
Hangi vService üzerinde hangi çerez adlarının korunduğu operasyonel olarak izlenebilir olmalıdır. Çözme hataları, bozuk değerler ve politika eşleşmeleri güvenlik incelemeleri için değerli sinyaldir. SIEM entegrasyonunda bu olaylar oturum koruma ve veri sızıntısı önleme kontrolleriyle birlikte yorumlanabilir.
Bazı uygulamalar çerez değerini istemci tarafı betiklerle okumaya çalışabilir. Bu tür çerezler şifrelendiğinde istemci tarafındaki mantık bozulabilir. Bu nedenle politika önce kritik ve sunucu tarafında kullanılan çerezlere uygulanmalı, istemci tarafından okunması gereken çerezler ayrı değerlendirilmelidir.
Çerez şifreleme tüm çerezlere otomatik uygulanacak kaba bir ayar olarak görülmemelidir. Doğru kapsam; çerez adı, vService, havuz ve uygulama davranışı birlikte analiz edilerek belirlenir. Bu yaklaşım hem güvenlik etkisini artırır hem de gereksiz uyumluluk sorunlarını azaltır.
Finans ve sağlık uygulamaları, oturum kimliği taşıyan çerezleri istemci tarafında okunamaz hale getirebilir. Kurum servisi kodu değişmeden çalışır; çerez sızıntısı ve elle değer değiştirme riski azaltılır.
Güvenlik ekipleri, kullanıcı rolü veya işlem bağlamı taşıyan çerezlerin değiştirilmesini TR7 katmanında kontrol edebilir. Bozulmuş değerler normal oturum verisi gibi kurum servisine taşınmaz.
Değiştirilmesi zor eski uygulamalarda çerez şifreleme uygulama koduna dokunmadan devreye alınabilir. Kurum, uzun modernizasyon sürecini beklemeden istemci tarafındaki çerez görünürlüğünü azaltır.
Tenant, rol veya işlem durumu gibi hassas bağlam taşıyan çerezler istemcide anlamlı veri olarak görünmez. Bu sayede saldırganın çerez içeriğinden uygulama mantığını çıkarması ve deneme yapması zorlaşır.
AES-256 şifreleme, liste bazlı çerez seçimi ve sıfır kod değişikliği. Kendi servislerinizle canlı bir kurulumda gezdirelim.