Oturum çalındığında yalnızca token doğrulamak yetmez; oturumun bağlamını da doğrulamak gerekir.
Session hijacking klasik ama hâlâ kritik bir problemdir. Kullanıcının oturum cookie'si ele geçirildiğinde saldırgan aynı token ile oturumu devralmaya çalışır. Eğer sistem yalnızca token'ın varlığına bakıyorsa, bu token'ın hangi IP, cihaz, tarayıcı veya kullanıcı bağlamında üretildiğini kontrol etmez. Bu durumda oturum kimliği tek başına güvenlik sınırı haline gelir.
Cookie güvenlik bayraklarının unutulması da yaygın bir zayıflıktır. HttpOnly olmadan istemci tarafı script'ler cookie'ye erişebilir; Secure olmadan taşıma katmanı zayıflar; SameSite olmadan çapraz site istekleri daha riskli hale gelir. Bu ayarların her uygulama ekibi tarafından tutarlı uygulanmasını beklemek büyük kurumlarda gerçekçi değildir.
Timeout yönetimi de çoğu zaman eksik kurulur. Idle timeout, son aktiviteden sonra ne kadar süre oturumun açık kalacağını belirler; absolute timeout ise kullanıcı aktif olsa bile login anından itibaren maksimum ömrü sınırlar. Özellikle finans, sağlık ve kurumsal portallarda bu iki sınırın ayrı ayrı yönetilmesi gerekir.
Eş zamanlı oturum kontrolü standart cookie sistemiyle kendiliğinden çözülmez. Bir kullanıcı kaç cihazdan giriş yapabilir, yeni giriş eski oturumu düşürmeli mi, yoksa yeni giriş reddedilmeli mi gibi kararlar merkezi session store ve aktif oturum takibi gerektirir. Çoklu node yapılarında bu durum daha da kritik hale gelir.
TR7 Oturum Koruması bu ihtiyacı tek policy graph altında toplar: session ID üretimi, cookie güvenlik bayrakları, IP / IP+UA / composite binding, idle ve absolute timeout, maksimum eş zamanlı oturum ve opsiyonel cookie şifreleme aynı yönetim modelinde birleşir.
Yaklaşımımız
TR7, oturum korumasını tek bir cookie ayarı olarak değil, üretimden doğrulamaya ve yenilemeden sonlandırmaya kadar uzanan çok katmanlı bir politika olarak uygular.
SAM katmanı cookie ve session ID üretimini yönetir
SAM, session affinity, cookie adı, cookie kaynağı, session formatı ve güvenlik bayraklarını birlikte yönetir. TR7 session ID üretebilir veya kurum servisinin ürettiği cookie ile çalışabilir; UUID, IP+timestamp+random, IP+random veya custom format seçenekleri kullanılabilir.
Session binding login sonrası bağlam değişimini yakalar
Oturum açıldıktan sonra IP, IP+UA, composite veya none binding modlarından biri uygulanabilir. Bağlam değişimi tespit edildiğinde session mismatch işaretlenir ve uygulama yeniden doğrulama veya ek kontrol isteyebilir.
Opsiyonel cookie şifreleme tampering ve replay riskini azaltır
AES-256-CBC tabanlı cookie şifreleme etkinleştirildiğinde seçilen cookie'ler istemci tarafında okunamaz hale gelir. IP+UA bağlamı ile türetilen ek bağlama sayesinde token'ın başka istemcide tekrar kullanılması zorlaştırılır.
Redis tabanlı atomik session refresh timeoutları güvenli yönetir
Session refresh işlemi Redis Lua fonksiyonlarıyla atomik yürütülür. Idle timeout her aktivitede yenilenebilir; absolute timeout login zamanına bağlı kalır. Maksimum eş zamanlı oturum kontrolü de merkezi session state üzerinden uygulanabilir.
Yetenekler
Oturum Koruması, farklı güvenlik ve kullanıcı deneyimi ihtiyaçları için hazır profiller, binding seçenekleri, timeout yönetimi ve cookie güvenliği sunar.
Dört built-in policy preset farklı oturum güvenliği profilleri sağlar
default profili IP binding, 8 saat idle timeout ve 7 gün absolute timeout ile kurumsal standart kullanım için tasarlanır. session_strict profili IP+UA binding, 30 dakika idle, 8 saat absolute timeout ve tek eş zamanlı oturum ile daha sıkı güvenlik sağlar. session_relaxed profili binding olmadan 7 gün idle ve 90 gün absolute timeout ile uzun süreli SaaS oturumlarına uygundur. session_singleDevice profili IP binding ve tek eş zamanlı oturum politikasıyla lisans veya cihaz kısıtı gereken uygulamalarda kullanılır.
Session ID formatı uygulama ve güvenlik ihtiyacına göre seçilir
TR7, session ID formatını tek bir sabit modele zorlamaz. ipTimestampRandom formatı IP, zaman ve random değer kombinasyonuyla varsayılan güçlü format sağlar; uuid formatı opak ve IP içermeyen bir değer üretir. ipRandom formatı IP ve random değer kullanır; custom format ise operatörün header, cookie veya özel değişkenlerden session anahtarı oluşturmasına izin verir. Bu esneklik, farklı uygulama mimarilerine uyum sağlar.
Cookie security flags merkezi olarak uygulanır ve standartlaştırılır
SAM katmanında HttpOnly minimum güvenlik bayrağı olarak yapılandırılabilir. Secure, SameSite=Strict veya SameSite=Lax gibi ek bayraklar da politika seviyesinde eklenebilir. Cookie Max-Age değeri absolute timeout ile ilişkilendirilebilir. Böylece her uygulama ekibinin cookie güvenlik ayarlarını ayrı ayrı hatasız yapması beklenmez.
Cookie kaynağı TR7 veya kurum servisi olarak seçilebilir
samCookieSource değeri TR7 olduğunda session cookie ADC katmanında üretilir. Kurum servisi kendi cookie'sini üretmeye devam edecekse kurum servisi kaynaklı cookie kullanılabilir. Hibrit modelde kurum servisinin cookie'si varsa o değerle devam edilir, yoksa TR7 yeni session değeri oluşturabilir. Bu yaklaşım hem yeni uygulamalara hem eski sistemlere uyum sağlar.
Dört binding modu farklı güvenlik ve mobilite dengeleri kurar
ip binding kullanıcının login olduğu kaynak IP bağlamını korur; kurumsal ofis veya VPN senaryolarında güçlüdür. ip+ua binding IP ve User-Agent çiftini birlikte değerlendirerek daha sıkı kontrol sağlar. composite binding, Accept-Language, özel header veya TLS fingerprint gibi ek bileşenlerle genişletilebilir. none modu ise uzun süreli oturum ve sık ağ değişimi olan SaaS kullanımında daha esnek davranır.
AES-256-CBC cookie şifreleme seçili cookie'lerde opt-in çalışır
Cookie şifreleme varsayılan açık kabul edilmez; seçilen cookie'ler için etkinleştirilen opsiyonel bir korumadır. Etkin olduğunda response tarafında cookie_encrypt, request tarafında cookie_decrypt akışı uygulanır. Her cookie için salt, padding ve base64 formatlama kullanılarak istemci tarafındaki değer anlamsız hale getirilir. Decryption başarısız olduğunda değer güvenilir oturum verisi gibi ele alınmaz ve uygulama yeniden doğrulama veya reddetme kararı verebilir.
Idle ve absolute timeout ayrı ayrı yönetilir
sessionIdleTimeout son aktiviteden sonra oturumun ne kadar süre geçerli kalacağını belirler. sessionAbsoluteTimeout ise login anından itibaren maksimum oturum ömrünü sınırlar ve aktiviteyle sürekli uzamaz. Bu ayrım özellikle bankacılık, kurumsal portal ve hassas veri içeren uygulamalarda kritiktir. Kullanıcı deneyimi ile güvenlik sınırı aynı politikada dengelenir.
Maksimum eş zamanlı oturum kullanıcı başına sınırlandırılabilir
maxConcurrentSessions değeri ile bir kullanıcının aynı anda kaç aktif oturuma sahip olabileceği belirlenir. Limit aşıldığında logout_oldest ile en eski oturum düşürülebilir veya deny_new ile yeni giriş reddedilebilir. Bu yapı tek cihaz lisansı, bankacılık güvenliği veya kurumsal erişim kontrolü için kullanılabilir. Aktif oturum listesi merkezi session state üzerinde takip edilir.
Session lifecycle olayları create, refresh, mismatch ve logout olarak izlenir
Login sırasında session oluşturulur, her request sırasında idle refresh yapılabilir, binding mismatch olduğunda oturum şüpheli duruma işaretlenir ve logout sırasında session geçersiz kılınır. Bu yaşam döngüsü, oturumun yalnızca başlangıçta değil tüm kullanım süresince yönetilmesini sağlar. SIEM ve audit akışları bu olaylardan güvenlik sinyali üretebilir. Özellikle hesap ele geçirme incelemelerinde session geçmişi önemlidir.
Multi-node yapılarda session sürekliliği peer sync ve Redis ile korunur
Çoklu TR7 düğümünde session state'in korunması için peer senkronizasyonu ve Redis tabanlı merkezi store birlikte kullanılabilir. Failover veya rolling restart senaryolarında session sürekliliği korunacak şekilde tasarım yapılır. Redis tarafında replication ve kalıcılık seçenekleriyle session state dayanıklılığı artırılabilir. Bu yapı, oturum korumasının tek node'a bağlı kalmasını engeller.
Operasyonel derinlik
Oturum koruması; cookie adı, attribute üretimi, composite binding, audit kategorileri, session store ve timeout fallback davranışlarıyla birlikte işletilir.
Yapılandırılabilir cookie adı
Varsayılan cookie adı TR7SID olarak kullanılabilir. Her pool için samCookieName ile farklı ad tanımlanabilir. Bu, marka uyumu, uygulama standardı veya mevcut cookie mimarisiyle uyum için kullanılır.
Runtime cookie attribute üretimi
Cookie değeri oluşturulurken HttpOnly, Secure, SameSite ve Max-Age gibi attribute'lar politika ayarlarına göre eklenir. Bu attribute'lar yalnızca yeni session üretildiğinde set edilebilir. Böylece cookie güvenliği merkezi politika ile standartlaştırılır.
Composite binding bileşenleri
Composite binding varsayılan olarak kaynak IP ve User-Agent gibi bileşenlerle kurulabilir. Operatör Accept-Language, Accept-Encoding, özel header veya TLS fingerprint gibi ek bileşenleri dahil edebilir. Bu hesaplama, ilgili değişkenler üretildikten sonra geç aşamada yapılmalıdır.
Audit kategorileri
Oturum ve erişim olayları whitelisted, authorized veya unauthorized gibi kategorilerle loglanabilir. Bu bilgi SIEM tarafında hesap ele geçirme, kötüye kullanım ve yetkisiz erişim incelemelerini kolaylaştırır. Her request için kullanıcı ve oturum bağlamı daha görünür hale gelir.
Redis session store
AAM session state Redis üzerinde tutulabilir ve session refresh işlemleri Lua fonksiyonlarıyla atomik yürütülür. Bu model klasik veritabanı gecikmesini session kontrol yolundan çıkarır. AOF ve replication gibi Redis özellikleriyle kalıcılık ve dayanıklılık artırılabilir.
Güvenli fallback değerleri
Idle timeout yapılandırması eksikse 1 saat fallback kullanılabilir. Absolute timeout eksikse 24 saat fallback değeri uygulanabilir. Bu değerler, konfigürasyon eksik olduğunda sınırsız oturum oluşmasını engelleyen güvenli varsayımlar sağlar.
Hangi senaryolarda kullanılır
Bankacılıkta sıkı binding ve tek cihaz oturumu
Bankacılık uygulaması kullanıcıyı tek cihazda tutmak ve 30 dakika inaktivitede oturumu kapatmak isteyebilir. session_strict profili IP+UA binding, 30 dakika idle, 8 saat absolute timeout ve tek eş zamanlı oturum politikasıyla uygulanır. Çalınan oturum farklı bağlamda kullanılırsa mismatch sinyali üretilir.
SaaS uygulamasında uzun süreli esnek oturum
B2B SaaS kullanıcıları laptop, telefon ve tablet üzerinden aynı hesaba erişmek isteyebilir. session_relaxed profili binding olmadan uzun idle ve absolute timeout değerleriyle kullanıcı deneyimini korur. IP değişimi veya cihaz çeşitliliği gereksiz yeniden doğrulama üretmez.
Kurumsal portalda IP binding ve iş günü oturumu
Çalışan portalında kullanıcı ofis veya VPN ağı üzerinden giriş yapar ve iş günü boyunca tekrar login olmadan çalışır. default profili IP binding, 8 saat idle timeout ve 7 gün absolute timeout ile uygulanabilir. IP bağlamı değişirse uygulama yeniden doğrulama isteyebilir.
Tek cihaz lisansı için eş zamanlı oturum sınırı
Premium uygulama veya lisanslı servis, hesabın aynı anda tek cihazda kullanılmasını isteyebilir. session_singleDevice profili max 1 concurrent session ve logout_oldest davranışıyla yeni girişte eski oturumu düşürür. Lisans paylaşımı ve kontrolsüz çoklu kullanım zorlaşır.
Sık sorulanlar
Session binding mismatch tespit edildiğinde ne olur?
Idle timeout ile absolute timeout arasındaki fark nedir?
AES-256-CBC cookie şifreleme varsayılan olarak açık mı?
CSRF ve JWT koruması bu sayfanın kapsamında mı?
Maksimum eş zamanlı oturum sınırı aşıldığında ne olur?
Multi-node TR7 kurulumunda oturum sürekliliği nasıl sağlanır?
Oturum güvenliğini uygulama kodundan çıkarın
Session ID üretimi, cookie güvenlik bayrakları, IP+UA binding, timeout politikası ve eş zamanlı oturum sınırı tek policy graph altında. Kendi servislerinizle canlı bir kurulumda gezdirelim.