--- url: 'https://www.corbado.com/tr/blog/cihazlara-bagli-oturum-kimlik-bilgileri-dbsc' title: 'Cihazlara Bağlı Oturum Kimlik Bilgileri (DBSC) açıklandı' description: 'Cihazlara Bağlı Oturum Kimlik Bilgileri''nin (DBSC) oturum ele geçirmeyi ve çerez hırsızlığını nasıl önlediğini, tarayıcı destek durumunu ve kurumsal güvenliği öğrenin.' lang: 'tr' author: 'Vincent Delitz' date: '2026-06-15T13:57:51.273Z' lastModified: '2026-06-16T06:08:15.552Z' keywords: 'Cihazlara Bağlı Oturum Kimlik Bilgileri, DBSC, Oturum ele geçirmeyi önleme, Çerez hırsızlığı koruması, TPM oturum bağlama' category: 'Authentication' --- # Cihazlara Bağlı Oturum Kimlik Bilgileri (DBSC) açıklandı **Tarayıcı Destek Durumu** > **En Güncel (Nisan 2026):** Chrome 146, > [DBSC'yi Windows'ta genel erişime sundu](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/), > ve özelliği Origin Trial (Orijin Denemesi) aşamasından çıkardı. macOS desteği (Secure > Enclave kullanarak) yaklaşan bir Chrome sürümünde sunulacak. Google ayrıca federe kimlik > (çapraz kökenli [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) bağlamaları), gelişmiş kayıt > (mTLS / donanım anahtarları) ve güvenli donanımı olmayan cihazlar için yazılım tabanlı > anahtarlar için halka açık bir yol haritası duyurdu. | Tarayıcı | Windows | macOS | Linux | Android | iOS | Durum | | ----------- | ----------------------- | --------------------------- | ------------ | ------------ | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | **Chrome** | ✅ GA (Chrome 146, TPM) | 🚧 Yakında (Secure Enclave) | ❌ | ❌ | ❌ | [Windows'ta GA (Genel Erişim)](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/) (Nisan 2026), macOS yakında | | **Edge** | ⏸️ Deneme bitti | ❌ | ❌ | ❌ | ❌ | Origin Trial Ekim 2025'te bitti, GA duyurulmadı | | **Safari** | N/A | 🔄 Değerlendiriliyor | N/A | N/A | 🔄 Değerlendiriliyor | WebKit tartışıyor, uygulama duyurulmadı | | **Firefox** | 🔄 İzleniyor | 🔄 İzleniyor | 🔄 İzleniyor | 🔄 İzleniyor | 🔄 İzleniyor | Değerlendiriliyor, uygulama taahhüdü yok | **Gösterge:** ✅ Genel erişimde | 🚧 Duyuruldu / geliştirme aşamasında | ⏸️ Deneme bitti | 🔄 Değerlendiriliyor/izleniyor | ❌ Henüz mevcut değil **Not:** [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc), Chrome 146 (Nisan 2026) itibarıyla TPM'ye sahip Windows'ta genel erişimdedir. Güvenli Bölge (Secure Enclave) üzerinden macOS desteği bir sonraki aşamada kullanıma sunuluyor. Google'ın belirtilen yol haritası, korumayı özel güvenli donanımı olmayan cihazlara genişletmek için yazılım tabanlı anahtarları da içermektedir. **Önemli Avantajlar: DBSC vs Mevcut Model** | **Özellik** | **Mevcut çerez modeli** | **DBSC modeli** | | ------------------------ | ---------------------------------- | ---------------------------------------------------------------- | | **Token türü** | Taşıyıcı (sahip olma = erişim) | Bağlı (sahip olma + anahtar = erişim) | | **Hırsızlık sonucu** | Hesabın tamamen ele geçirilmesi | İşe yaramaz token (yenilenemez) | | **Oturum süresi** | Kısa (güvenlik için) | Uzun / sınırsız (tasarım gereği güvenli) | | **Kullanıcı sürtünmesi** | Yüksek (sık girişler) | Düşük (görünmez güvenlik) | | **MFA atlama** | Savunmasız (çerez aktarımı) | Dirençli (cihaz gerekir) | | **İptal etme** | Yavaş (süresinin dolması beklenir) | Neredeyse gerçek zamanlı (bir sonraki yenilemede başarısız olur) | ## Key Facts - **DBSC**, web oturumlarını cihazda tutulan bir kriptografik anahtara bağlayarak, çalınan çerezleri başka bir cihazdan yenilenemeyecekleri için işe yaramaz hale getirir. - Tarayıcı, dışa aktarılamayan özel bir anahtarı **TPM** içinde depolar ve kullanıcı etkileşimi olmadan cihaz sahipliğini kanıtlamak için her 5 dakikada bir sunucu sorgularını imzalar. - TLS katmanı altyapı karmaşıklığı nedeniyle başarısız olan **Token Binding**'in (Token Bağlama) aksine, DBSC, HTTP uygulama katmanında çalışır ve mevcut yük dengeleyiciler ve CDN'lerle şeffaf bir şekilde çalışır. - **Chrome 146, DBSC'yi Windows'ta (Nisan 2026) GA (Genel Erişim) olarak sunuyor** ve macOS Güvenli Bölge (Secure Enclave) desteği yaklaşan bir sürümde geliyor. Google'ın yayınlanan yol haritası ayrıca federe kimliği (çapraz kökenli SSO bağlamaları), gelişmiş kaydı (mTLS / donanım anahtarları) ve güvenli donanımı olmayan cihazlar için yazılım tabanlı anahtarları kapsar. Safari ve Firefox hâlâ değerlendirme aşamasındadır; Edge'in Origin Trial'ı (Orijin Denemesi) Ekim 2025'te sona erdi ve GA duyurulmadı. ## 1. Giriş: Cihazlara Bağlı Oturum Kimlik Bilgileri (DBSC) World Wide Web'in mimarisi, durumsuzluk (statelessness) ilkesi üzerine kurulmuştur. HTTP ilk tasarlandığında, istekler arasında kullanıcılar hakkında bilgi tutmuyordu. Bunu çözmek için, bir web sitesinden gönderilen ve kullanıcının bilgisayarında depolanan, sonraki her istekle web sitesine geri gönderilecek küçük bir veri parçası olan "çerez" (cookie) icat edildi. Onlarca yıl boyunca bu mekanizma, oturum yönetiminin temeli olarak hizmet etti. Bir kullanıcı giriş yaptığında, sunucu kimlik bilgilerini doğrular ve bir çerez verir. Bu çerez bir "taşıyıcı token" (bearer token) görevi görür. Fiziksel dünyada taşıyıcı belgesi, sahibine temsil ettiği hakları veya varlıkları veren bir belgedir; tahvili elinizde tutarsanız, tahvilin sahibi olursunuz. Benzer şekilde, HTTP'nin dijital dünyasında çerezi elinizde tutarsanız kullanıcı sizsiniz. Bu taşıyıcı yeteneği, aynı zamanda web'in en büyük faydası ve en derin [güvenlik açığı](https://www.corbado.com/tr/blog/tamamen-sifresiz-sisteme-nasil-gecilir)dır. Tüm oturumun ve dolayısıyla kullanıcının kimliğinin, verilerinin ve finansal varlıklarının güvenliği tamamen o çerez dizisinin gizliliğine dayanır. Kötü niyetli bir aktör bu diziyi kopyalayabilirse, ilk [kimlik doğrulama](https://www.corbado.com/tr/blog/digital-credentials-api) kontrollerini tamamen atlayarak dünyanın herhangi bir yerinden, herhangi bir cihazdan kullanıcı kimliğine bürünebilir. Bu spesifik güvenlik açığı, endüstriyel ölçekte bir "çerez hırsızlığı" ve "oturum ele geçirme" yeraltı ekonomisinin doğmasına neden oldu. Sektör, FIDO (Fast Identity Online) standartlarının ve [Geçiş Anahtarları](https://www.corbado.com/tr/glossary/cda)nın (Passkeys) benimsenmesiyle kimlik doğrulamanın "ön kapısını" başarıyla güçlendirirken, saldırganlar odaklarını "arka kapıya", yani aktif oturuma kaydırıyor. Bir parolayı oltalama yoluyla ele geçirmek (phishing) zorlaşıyor, ancak bir oturum çerezini çalmak tehlikeli derecede etkili olmaya devam ediyor. Sektörün artan bu tehdide yanıtı **Cihazlara Bağlı Oturum Kimlik Bilgileridir (DBSC)**. [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc), web oturumlarının nasıl sürdürüldüğüne dair bir paradigma değişikliğini temsil eder. Oturumun [kriptografik olarak cihaza bağlandığı](https://www.w3.org/TR/dbsc/) bir modele doğru basit taşıyıcı tokenlerden uzaklaşmayı önerir. [Chrome 146'nın (Nisan 2026) DBSC'yi Windows'ta GA olarak sunmasıyla](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/), standart, web ekiplerinin bugün dağıtabileceği deneysel bir üretim yeteneğinden çıkmıştır. Chrome, Windows'ta TPM'leri kullanır ve ardından macOS'ta [Secure Enclave](https://www.corbado.com/glossary/secure-enclave) (Güvenli Bölge) desteğini sunmaya hazırlanmaktadır; spesifikasyonun kendisi anahtar depolama konusunda agnostiktir, yalnızca "açıklanan tehdide karşı sağlam" olmasını gerektirir. Bu, çalınan çerezleri çok daha az değerli hale getirir. Bağlı anahtar olmadan başka bir cihazdan yenilenemezler. Bu makale, güvenlik mimarları, ürün yöneticileri ve geliştiriciler için tasarlanmış [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc)'nin kapsamlı bir analizini sunmaktadır. Teknik mimariyi, "sürtünmesiz güvenliğin" ticari etkilerini, Paylaşılan Sinyaller (CAEP/RISC) gibi yeni ortaya çıkan standartlarla olan ilişkiyi ve kuruluşların Corbado gibi platformları kullanarak bu geleceğe nasıl hazırlanabileceğini araştırıyor. **Bu Makalenin Yanıtladığı Temel Sorular** 1. Mevcut oturum yönetimi neden hesap devralmalarını önlemede başarısız oluyor? 2. DBSC, mevcut "Güvenli" (Secure) çerezlerden ve HttpOnly bayraklarından nasıl farklıdır? 3. DBSC ve Geçiş Anahtarları, oltalama saldırılarına karşı daha güçlü direnç için birlikte nasıl çalışır? 4. Token Binding'e ne oldu ve DBSC onun başarısız olduğu yerde neden başarılı oluyor? 5. Ürün Yöneticileri için ticari etkiler ve yatırım getirisi (ROI) fırsatları nelerdir? 6. DBSC'yi bugün hangi tarayıcılar ve işletim sistemleri destekliyor? 7. Kuruluşlar DBSC'yi sıfırdan oluşturmadan nasıl uygulayabilir? 8. DBSC, DPoP ve [OAuth 2.0](https://www.corbado.com/glossary/oauth2) arasındaki ilişki nedir? 9. DBSC, gerçek zamanlı tehdit yanıtı için Paylaşılan Sinyallerle (CAEP/RISC) nasıl entegre olur? ## 2. Temel Sorunları ve Çözümleri Anlamak Bu yeni standardın karmaşıklığında gezinmek için, öncelikle mevcut oturum yönetimindeki temel sorunları ve DBSC'nin nasıl çözümler sunduğunu anlamalıyız. Bu alanların her biri, DBSC'nin ele aldığı kritik bir [güvenlik açığı](https://www.corbado.com/tr/blog/tamamen-sifresiz-sisteme-nasil-gecilir)nı veya sınırlamayı temsil eder. ### 2.1 Mevcut Oturum Yönetiminin Başarısızlığı Mevcut oturum yönetiminin temel başarısızlığı, güvenin "taşınabilirliğidir". Bir sunucu bir oturum çerezi verdiğinde, aslında onu elinde tutan herkes için çalışan bir pasaport veriyor. Tarayıcılar [HttpOnly ve Secure bayrakları](https://www.wisp.blog/blog/understanding-token-storage-local-storage-vs-httponly-cookies) (JavaScript erişimini engelleme ve HTTPS üzerinden iletimi sağlama) gibi savunmalar uygulamış olsa da, bu savunmalar yalnızca Siteler Arası Komut Dosyası Çalıştırma (XSS) veya ağ dinleme gibi belirli çıkarma vektörlerine karşı koruma sağlar. Ana bilgisayar cihazında çalışan kötü amaçlı yazılımlara karşı hiçbir koruma sunmazlar. "Bilgi Çalanlar" (Infostealers), özellikle diski tarayıcının çerez depolama dosyasını bulmak, şifresini çözmek (genellikle kullanıcının kendi işletim sistemi düzeyindeki kimlik bilgilerini kullanarak) ve içerikleri bir komuta ve kontrol sunucusuna sızdırmak için tasarlanmış kötü amaçlı yazılımlardır. Saldırgan çereze sahip olduğunda, oturumu ele geçirmek için çalınan tokeni kendi tarayıcısına enjekte ederek bir [Çerez Aktarımı (Pass-the-Cookie) saldırısı](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html) gerçekleştirebilir. Sunucu, geçerli bir çerez görerek isteğin meşru olduğunu varsayar. ### 2.2 DBSC'nin Geleneksel Güvenli Çerezlere Göre Kriptografik Avantajı DBSC, kimlik doğrulamasının ikinci bir faktörünü oturum bakım döngüsünün kendisine dahil eder. Statik bir sır olan standart bir güvenli çerezin aksine, bir DBSC oturumu kısa ömürlü bir taşıyıcı token ve bir kriptografik sahiplik kanıtından oluşur. Tarayıcı, cihazda güvenli bir şekilde depolanan bir genel-özel anahtar çifti oluşturur. Sunucu, oturumu genel anahtara bağlar. Periyodik olarak, tarayıcı sunucudan gelen bir sorguyu imzalayarak özel anahtarı hala elinde tuttuğunu kanıtlamalıdır. [Spesifikasyon, "açıklanan tehdide karşı sağlam" anahtar depolama gerektirir](https://www.w3.org/TR/dbsc/). Chrome, mevcut olduğunda Windows'ta TPM'yi kullanır. Bir saldırgan çerezi farklı bir cihazdan çalarsa, onu yenileyemez çünkü gerekli kriptografik imzayı oluşturamaz. "Taşıyıcı" yönü çok kısa bir pencereye indirgenirken, "bağlayıcı" yönü uzun vadeli süreklilik sağlar. ### 2.3 Geçiş Anahtarları ve DBSC Arasındaki Sinerji Geçiş Anahtarları ve DBSC, kullanıcı yaşam döngüsünün farklı aşamalarını güvence altına alan tamamlayıcı teknolojilerdir. Geçiş Anahtarları (FIDO2), parolalar olmadan bir oturum başlatmak için kimliği kanıtlama, _kimlik doğrulama_ sorununu çözer ve böylece kimlik bilgisi avını ortadan kaldırır. DBSC, çerez hırsızlığı yoluyla oturum ele geçirmeyi önemli ölçüde zorlaştırarak _kimlik doğrulama sonrası_ sorunu ele alır. [FIDO Alliance, DBSC'yi](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/) oturum ele geçirmeye karşı "çıtayı yükselten" tamamlayıcı bir teknoloji olarak çerçeveler. Birlikte, giriş ve oturum yaşam döngüsü genelinde saldırı yüzeyini azaltırlar, ancak DBSC, devam eden cihaz erişimine sahip kötü amaçlı yazılımlara veya aynı cihazdaki gerçek zamanlı ortadaki tarayıcı (browser-in-the-middle) saldırılarına karşı koruma sağlamaz. | Teknolojiler | Uzaktan Oltalama | Kimlik Bilgisi Doldurma | Token Hırsızlığı | | ----------------------------------- | ---------------- | ----------------------- | ---------------- | | **Geçiş Anahtarları** | ✅ | ✅ | ❌ | | **DBSC / DPoP** | ❌ | ❌ | ✅ | | **Geçiş Anahtarları + DBSC / DPoP** | ✅ | ✅ | ✅ | **Geçiş Anahtarları ve DBSC nasıl birlikte çalışır?** | **Yön** | **Geçiş Anahtarları** | **DBSC** | **Birleşik fayda** | | ---------------------- | ----------------------------------------------------- | -------------------------------------------- | -------------------------------------------------- | | **Kapsam** | Kimlik doğrulama (giriş) | Oturum yönetimi | Uçtan uca koruma | | **Azaltılan tehdit** | Parola oltalama, kimlik bilgisi doldurma | Uzaktan oturum ele geçirme, çerez hırsızlığı | Hesap devralma için çıtayı önemli ölçüde yükseltir | | **Kullanıcı deneyimi** | Parolasız giriş | Şeffaf oturum koruması | Sorunsuz, güvenli deneyim | | **Anahtar depolama** | Cihaza bağlı veya senkronize edilmiş kimlik bilgileri | Cihaza bağlı (mevcut olduğunda HSM) | Esnek kimlik doğrulama, katı oturum bağlama | | **Dağıtım** | Parolaların yerini alır | Mevcut oturumları geliştirir | Artımlı güvenlik iyileştirmeleri | ### 2.4 Token Binding'in Başarısızlığından Ders Çıkarmak DBSC, bu sorunu çözmeye yönelik ilk girişim değil. "Token Binding", çerezleri temel alınan TLS (Transport Layer Security - Taşıma Katmanı Güvenliği) bağlantısına bağlamaya çalışan önceki bir standarttı. Kriptografik olarak sağlam olmasına rağmen, TLS katmanına aşırı bağımlılığı nedeniyle Token Binding benimsenemedi. Modern web'de, TLS bağlantıları genellikle yük dengeleyiciler, CDN'ler veya ters proxy'lerde sonlandırılırken, uygulama mantığı bunların arkasındaki sunucularda bulunur. Token Binding bilgilerini bu karmaşık ağ katmanları aracılığıyla yaymak çok zor oldu. DBSC, [tamamen Uygulama Katmanında (HTTP) çalışarak](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/) bu başarısızlıktan ders çıkarır. Temel ağ bağlantısına bağlı değildir, bu da onu mevcut yük dengeleyiciler, proxy'ler ve bulut altyapısıyla uyumlu hale getirir. ### 2.5 Ticari Etkiler ve Yatırım Getirisi Fırsatları Ürün liderleri için DBSC, kullanıcı deneyimini (UX) iyileştirirken aynı zamanda güvenliği iyileştirme fırsatı sunar. Geleneksel olarak, yüksek güvenlik kısa oturum zaman aşımları anlamına geliyordu ve kullanıcıları sık sık (sürtünme) giriş yapmaya zorluyordu. Oturumu cihaza bağlayarak, _uzaktan_ çerez hırsızlığı riski önemli ölçüde azalır. İşletmeler, çalınan çerezlerin başka bir cihazdan yenilenemeyeceğini bilerek daha uzun oturum süreleri düşünebilirler. Bununla birlikte, DBSC cihaz hırsızlığına, cihazdaki kalıcı kötü amaçlı yazılımlara veya kötü niyetli bir kullanıcı tarafından kötüye kullanıma karşı koruma sağlamadığından, oturum ömrü politikaları hala bu kalan riskleri yansıtmalıdır. ## 3. Tehdit Ortamı: Çerez Hırsızlığının Sanayileşmesi DBSC'nin arkasındaki aciliyeti anlamak için, modern tehdit ortamının karmaşıklığını takdir etmek gerekir. Oturum çerezlerinin çalınması, niş bir hacker hilesinden ölçeklenebilir, otomatikleştirilmiş bir sektöre dönüştü. ### 3.1 Bilgi Çalanların Yükselişi ```mermaid graph TD A[Kullanıcı Kötü Amaçlı Yazılım
İndiriyor] -->|Yürütme| B[Bilgi Çalan (Infostealer) Cihazda
Etkinleşiyor] B --> C[Tarayıcı Verilerini Buluyor] C --> D[Chrome/Edge/Firefox
Çerez Depolaması] C --> E[Parola Veritabanı] C --> F[Kripto Cüzdanları] D --> G[İşletim Sistemi Kimlik Bilgilerini
Kullanarak Şifreyi Çözüyor] E --> G F --> G G --> H[Çalınan Verilerle
Günlük Dosyası Oluşturuyor] H --> I[C2 Sunucusuna Sızdırıyor] I --> J[Karanlık Web (Dark Web) Pazarı] J --> K[Saldırgan Günlüğü Satın Alıyor] K --> L[Çerezi Kendi
Tarayıcısına Aktarıyor] L --> M[MFA'yı Atlıyor] M --> N[Hesabı Ele Geçirme
Tamamlandı] style A fill:#ff6b6b,color:#fff style B fill:#ff6b6b,color:#fff style N fill:#ff6b6b,color:#fff style J fill:#495057,color:#fff style M fill:#ffd43b,color:#000 ``` Hizmet Olarak [Kötü Amaçlı Yazılım](https://www.corbado.com/tr/glossary/kotu-amacli-yazilim) (MaaS), siber suçlular için giriş engelini düşürdü. RedLine, Raccoon, Vidar ve Taurus gibi "Bilgi Çalanlar", öncelikli bir hedefle tasarlanmış, ticari olarak satılan [kötü amaçlı yazılım](https://www.corbado.com/tr/glossary/kotu-amacli-yazilim) türleridir: web tarayıcılarından veri sızdırma. Bu bilgi çalanlar oltalama e-postaları, kırılmış (cracked) yazılımlar veya kötü amaçlı reklamlar yoluyla dağıtılır. Yüklendikten sonra, Chrome, Edge ve Firefox gibi tarayıcıların verilerini depoladığı belirli dosya yollarını hedeflerler. - **Hedef:** Çerez veritabanı (genellikle bir [SQLite](https://www.corbado.com/blog/passkey-webauthn-database-guide) dosyası) ve Giriş Verileri veritabanı (kaydedilen parolalar). - **Mekanizma:** Tarayıcılar, bu veritabanlarını kullanıcının işletim sistemi girişine bağlı Veri Koruma API'lerini (Windows'ta DPAPI) kullanarak şifreler. [Kötü amaçlı yazılım](https://www.corbado.com/tr/glossary/kotu-amacli-yazilim) _kullanıcı olarak_ çalıştığı için, bu dosyaların şifresinin çözülmesini önemsiz bir şekilde isteyebilir. - **Çıktı:** Kötü amaçlı yazılım, şifresi çözülmüş çerezleri, parolaları, sistem bilgilerini ve bazen kripto [cüzdan](https://www.corbado.com/tr/blog/dijital-cuzdan-guvencesi)ı anahtarlarını içeren bir zip dosyası olan bir "günlük" (log) oluşturur. ### 3.2 "Günlükler" Pazarı Bu günlükler toplanır ve Genesis Market (kapatılmadan önce) ve Russian Market gibi karanlık web [pazar yerlerinde](https://www.corbado.com/passkeys-for-e-commerce) satılır. Alıcılar, belirli yüksek değerli hedefler için aktif çerezler içeren günlükleri arayabilirler: "Salesforce," "Gmail," "Bank of America," veya "[AWS](https://www.corbado.com/blog/passkeys-amazon-cognito) Console." **Atlatma:** Bir çerez günlüğünün değeri, Çok Faktörlü Kimlik Doğrulamayı (MFA) atlama yeteneğinde yatar. Çoğu MFA zorluğu (SMS, TOTP, Push) yalnızca _giriş_ olayı sırasında ortaya çıkar. Oturum kurulduktan ve çerez verildikten sonra, sunucu kullanıcının güvenilir olduğunu varsayar. Geçerli bir oturum çerezini içe aktaran bir saldırgan, [MFA kapısından kayarak geçer](https://workspace.google.com/blog/identity-and-security/defending-against-account-takeovers-top-threats-passkeys-and-dbsc) ve sunucuya aktif bir sekmeye dönen kullanıcı gibi görünür. ### 3.3 Google Workspace ve Microsoft Entra Tehdidi Bulut üretkenlik paketleri birincil hedeflerdir. Bir Google Workspace veya Microsoft Entra ID (eski adıyla Azure AD) hesabı için çalınan bir oturum çerezi, bir saldırgana kurumsal e-postalara, belgelere ve dahili sistemlere erişim sağlayabilir. [Google'ın kendi tehdit istihbaratı](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html), Google Hesaplarına erişmek için birincil vektör olarak çerez hırsızlığında büyük bir artış olduğunu bildirdi ve bunu DBSC'ye yaptıkları yatırımın arkasındaki itici güç olarak açıkça adlandırdı. 2 Adımlı Doğrulamayı (2SV) ve [geçiş anahtarları](https://www.corbado.com/tr/glossary/cda)nı zorunlu kıldıkça, saldırganların sadece kimlik bilgisi avından (2SV / [geçiş anahtarları](https://www.corbado.com/tr/glossary/cda)nın durdurduğu) çerez hırsızlığına (2SV / geçiş anahtarlarının genellikle durdurmadığı) yöneldiğini belirtiyorlar. ### 3.4 "Cihaz Parmak İzi Oluşturma" Sınırları Tarihsel olarak, risk motorları [User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) (Kullanıcı Aracısı) dizesine, ekran çözünürlüğüne, yüklü yazı tiplerine ve IP adresine bakarak cihaz parmak izlerini analiz ederek oturum hırsızlığını tespit etmeye çalıştı. Bir oturum çerezi aniden biraz farklı bir tuval (canvas) parmak izi ile yeni bir IP'den görünürse, sunucu bunu geçersiz kılabilir. **Sorun:** Tarayıcılardaki gizlilik girişimleri (Safari'nin Akıllı İzleme Koruması ve Chrome'un Privacy Sandbox'ı gibi), reklam izlemeyi durdurmak için bu parmak izlerinin entropisini aktif olarak azaltıyor. Bu, güvenlik için "iyi" parmak izi oluşturmayı giderek zorlaştırıyor. Ayrıca, saldırganlar artık kurbanın profiline mükemmel şekilde uyması için bu parmak izlerini taklit etmelerine olanak tanıyan, sezgisel algılamayı etkisiz hale getiren "Anti-Detect" (Algılama Karşıtı) Tarayıcılar kullanıyor. DBSC, bu olasılıksal tahmin oyununu deterministik kriptografik kanıtla değiştirir. ## 4. Teknik Mimari: DBSC Nasıl Çalışır Cihazlara Bağlı Oturum Kimlik Bilgileri (DBSC), istemci cihazındaki bir anahtara bağlı oturumlar oluşturmak için [standartlaştırılmış bir API ve protokol](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials) sunar. Spesifikasyon, "açıklanan tehdide karşı sağlam" anahtar depolama gerektirir ancak uygulama konusunda agnostiktir. Chrome, mevcut olduğunda Windows'ta TPM'yi kullanır. Bu bölüm, W3C Çalışma Taslağı ve Chrome belgelerinde tanımlanan mekaniği ayrıntılarıyla anlatmaktadır. ### 4.1 Temel Bileşenler | **Bileşen** | **Açıklama** | **DBSC'deki Rolü** | | -------------------------------- | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | **Kullanıcı aracısı (tarayıcı)** | İstemci uygulaması (Chrome, Edge vb.). | Anahtar çiftini yönetir, HSM etkileşimini yönetir ve kanıt eklemek için ağ isteklerini durdurur. | | **Bağlı Taraf (sunucu)** | Web uygulaması (örn. bankacılık portalı). | Sorgular yayınlar, imzaları doğrular ve oturum yaşam döngüsünü yönetir. | | **Anahtar depolama** | Güvenli depolama (TPM, Secure Enclave veya diğer) | Özel anahtarı saklar. Chrome, mevcut olduğunda Windows'ta TPM kullanır; spesifikasyon uygulama konusunda agnostiktir. | | **Oturum çerezi** | Standart bir HTTP çerezi. | Taşıyıcı token olarak kullanılır, ancak çok kısa bir ömre sahiptir (örneğin, 5-10 dakika). | | **Sahiplik kanıtı** | Kriptografik bir imza. | Tarayıcı tarafından özel anahtara hala sahip olduğunu kanıtlamak için gönderilen bir JWT. | ### 4.2 DBSC Protokolü Yaşam Döngüsü DBSC yaşam döngüsü, standart bir oturumdan bağlı bir oturuma sorunsuz bir geçiş sağlayarak geriye dönük uyumluluk ve aşamalı geliştirme sağlar. ```mermaid sequenceDiagram participant User participant Browser participant HSM as HSM (TPM/Secure Enclave) participant Server Note over User,Server: Aşama 1: Kimlik Doğrulama ve Bağlama User->>Browser: Kimlik bilgileri/geçiş anahtarı ile giriş Browser->>Server: Kimlik doğrulama isteği Server->>Browser: Başarı + DBSC kayıt başlığı Browser->>HSM: Anahtar çifti oluştur HSM->>Browser: Genel/Özel anahtar (özel anahtar dışa aktarılamaz) Browser->>Server: Genel anahtarı kaydet (JWT imzalı) Server->>Server: Oturumu genel anahtara bağla Server->>Browser: Kısa ömürlü çerez (5 dk) Note over User,Server: Aşama 2: Normal Kullanım loop 5 dakika içinde her istek Browser->>Server: Çerezli istek Server->>Browser: Yanıt end Note over User,Server: Aşama 3: Yenileme (süresi dolduktan sonra) Browser->>Server: Süresi dolmuş çerezle istek Server->>Browser: 401 + Sorgu nonce (Challenge nonce) Browser->>HSM: Sorguyu imzala HSM->>Browser: İmza Browser->>Server: İmza kanıtı Server->>Server: Depolanan genel anahtarla doğrula Server->>Browser: Yeni kısa ömürlü çerez Browser->>Server: Orijinal isteği yeniden dene Server->>Browser: Başarı yanıtı ``` #### 4.2.1 1. Aşama: Başlatma ve Bağlama Bağlama işlemi, kullanıcı standart yöntemleri (parola, geçiş anahtarı vb.) kullanarak kimlik doğrulamasını başarıyla yaptıktan hemen sonra başlar. 1. **Sunucu Sinyali:** Başarılı giriş üzerine, sunucu bir oturum çerezi ayarlar (her zamanki gibi) ancak DBSC desteğini gösteren belirli bir başlık ekler. ``` HTTP HTTP/1.1 200 OK Set-Cookie: session_id=xyz123...; Secure; HttpOnly; SameSite=Strict Secure-Session-Registration: (ES256 RS256); path="/auth/dbsc/register" ``` - Secure-Session-Registration başlığı tarayıcıya şunu söyler: "ES256 ve RS256 algoritmalarını destekliyorum. Lütfen /auth/dbsc/register uç noktasında bağlı bir oturum kaydedin." 2. **Anahtar Oluşturma:** Tarayıcı bu başlığı ayrıştırır. Cihazda güvenli bir şekilde depolanan yeni bir asimetrik anahtar çifti (örn. Eliptik Eğri P-256) oluşturur. - **Uygulama Notu:** Chrome, mevcut olduğunda Windows'ta TPM kullanır; spesifikasyon, depolama mekanizması konusunda agnostiktir, yalnızca "açıklanan tehdide karşı sağlam" olmasını gerektirir. - **Gizlilik Kapsamı:** Anahtar, web kökenine (örn. bank.com) göre kapsamlandırılır. Tarayıcı, siteler arası izlemeyi önleyerek bu anahtarın retailer.com için asla kullanılmamasını sağlar. 3. **Kayıt İsteği:** Tarayıcı, belirtilen kayıt yoluna bir istek gönderir. Bu istek, Özel Anahtar (kendinden imzalı onay) tarafından imzalanmış, bir JSON Web Token (JWT) içindeki yeni oluşturulan **Genel Anahtarı** (Public Key) içerir. ``` HTTP POST /auth/dbsc/register HTTP/1.1 Content-Type: application/jwt \.\.\ ``` 4. **Oturum Bağlama:** Sunucu, genel anahtarın işlevsel olduğundan emin olmak için imzayı doğrular. Ardından, kullanıcının oturumunu (session_id=xyz123) bu özel Genel Anahtar ile ilişkilendirmek için veritabanını günceller. Bu andan itibaren oturum "bağlıdır". #### 4.2.2 2. Aşama: Kısa Ömürlü Çerez Döngüsü Güvenliği performansla dengelemek için (güvenli anahtar işlemleri gecikme ekleyebilir), DBSC çift tokenli bir sistem kullanır. 1. **Verme:** Sunucu _yeni_, kısa ömürlü bir çerez (örneğin 5 dakika geçerli) verir. Buna access_token diyelim. 2. **Kullanım:** Tarayıcı bu access_token'ı tüm normal istekler (görüntüleri getirme, API çağrıları, sayfalarda gezinme) için kullanır. Çerez geçerli olduğu sürece hiçbir kriptografik işlem yapılmaz. Bu, gezinmenin hızlı kalmasını sağlar. 3. **Sona Erme:** 5 dakika sonra access_token'ın süresi dolar. #### 4.2.3 3. Aşama: Yenileme (Sahiplik Kanıtı) Güvenlik mekanizmasının kalbi budur. Kısa ömürlü çerezin süresi dolduğunda, farklı bir cihazdaki saldırgan kilitlenir, ancak meşru kullanıcı (bağlı anahtara erişimi olan) devam edebilir. 1. **Tespit:** Tarayıcı bir istekte bulunmaya çalışır. Çerezin süresinin dolduğunu fark eder (veya sunucu 401 veya belirli bir Secure-Session-Challenge başlığı döndürür). 2. **Kesişme:** Tarayıcı ağ isteğini _duraklatır_. Kullanıcıya bir hata göstermez. 3. **Yenileme İsteği:** Tarayıcı, oturum yapılandırmasında tanımlanan yenileme uç noktasını otomatik olarak çağırır. - Sunucu kriptografik bir **Sorgu** (bir nonce) gönderir. - Tarayıcı, bu sorguyu imzalamak için bağlı anahtarı kullanır. - İmza, özel anahtarın sahipliğini kanıtlar. 4. **Gönderim:** Tarayıcı, imzalı sorguyu sunucuya geri gönderir. ``` HTTP POST /auth/dbsc/refresh HTTP/1.1 Sec-Secure-Session-Id: \ Secure-Session-Response: \ ``` 5. **Doğrulama:** Sunucu, imzayı doğrulamak için depolanan Genel Anahtarı kullanır. - _Geçerliyse:_ Sunucu isteğin oturumu başlatan aynı fiziksel cihazdan geldiğini bilir. _Yeni_ kısa ömürlü bir access_token (başka bir 5 dakika için geçerli) verir. - _Geçersizse:_ İstek reddedilir. Oturum sonlandırılır. 6. **Devam Etme:** Tarayıcı yeni çerezi alır ve duraklatılan orijinal isteği şeffaf bir şekilde yeniden dener. [Kullanıcı hiçbir kesinti yaşamaz](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials). ### 4.3 Uygulama Nüansları #### 4.3.1 "Lift and Shift" (Al ve Taşı) Savunması ```mermaid graph LR subgraph "Kurbanın Cihazı" A[DBSC'li
Kullanıcı Oturumu] B[HSM/TPM
Özel Anahtarı] C[Çerez +
Oturum Kimliği] A --> B A --> C B -.->|Dışa aktarılamaz| X[Özel Anahtar
Çıkarılamaz] end subgraph "Saldırı Senaryosu" D[RedLine Çalıcı
Cihaza Bulaşır] D --> E[Çerez ve Oturum Kimliğini
Çalar] E --> F[Saldırgana
Aktarır] end subgraph "Saldırganın Cihazı" G[Çalınan Çerezi
İçe Aktarır] H[Oturumu Kullanmaya
Çalışır] I[Sunucu DBSC
Yenileme İster] J[Sorguyu
İmzalayamaz] K[Oturum Reddedildi] G --> H H --> I I --> J J --> K end C -.->|Çalındı| E F --> G style D fill:#ff6b6b,color:#fff style K fill:#51cf66,color:#fff style B fill:#4c6ef5,color:#fff style X fill:#51cf66,color:#fff style J fill:#ff6b6b,color:#fff ``` Kullanıcının bilgisayarına RedLine Stealer bulaştıran bir saldırgan düşünün. `access_token` ve `session_id`'yi çalarlar. Bunları kendi tarayıcılarına aktarırlar. - **Senaryo A (5 dakika içinde):** Saldırgan, kısa ömürlü tokenin süresi dolana kadar birkaç dakika erişim sağlayabilir. - **Senaryo B (Süre dolduktan sonra):** Saldırganın tarayıcısı (farklı bir cihazda) tokeni kullanmaya çalışır. Sunucu bunu reddeder ve yenileme talep eder. Saldırganın tarayıcısı DBSC başlıklarını görür, ancak bağlı özel anahtara sahip olmadığı için yenileme işlemini gerçekleştiremez. Saldırı başarısız olur. #### 4.3.2 Kapsam ve Gizlilik Gizlilik, DBSC'nin merkezi bir tasarım hedefidir. [W3C spesifikasyonu](https://www.w3.org/TR/dbsc/), kullanıcıları siteler arasında izleyebilecek küresel tanımlayıcıların kullanımını açıkça yasaklamaktadır. - **Köken Başına Anahtarlar:** Tarayıcı, her site için benzersiz bir anahtar çifti oluşturur. google.com Anahtar A'yı görür; amazon.com Anahtar B'yi görür. Aralarında hiçbir korelasyon yoktur. - **Kullanıcı Temizleme:** Kullanıcı çerezlerini/site verilerini temizlerse, tarayıcı da ilişkili DBSC anahtarlarını siler. Bu, DBSC'nin silinmiş kimlikleri diriltmek için bir "süper çerez" olarak kullanılamamasını sağlar. #### 4.3.3 Sunucu Tarafı Hususları DBSC'nin uygulanması, sunucunun genel anahtarlar hakkında durum bilgisini korumasını gerektirir. - **Veritabanı Şeması:** Oturum tablosu, `public_key` ve `last_challenge`'ı `user_id` ve `session_expiry` ile birlikte depolamak üzere güncellenmelidir. - **Performans:** Yenileme işlemi kriptografik doğrulama içerir (örneğin, bir ECDSA imzasının doğrulanması). Hızlı olmakla birlikte, basit bir dizeyi kontrol etmekten daha fazla CPU yoğunlukludur. Ancak, yenilemeler her istekte değil, her birkaç dakikada bir gerçekleştiğinden, genel yük önemsizdir. ## 5. Ticari ve Ürün Etkileri Teknik spesifikasyonların ötesinde DBSC; iş stratejisi, ürün yol haritaları ve uyumluluk duruşları için önemli etkiler taşır. ### 5.1 Sürtünmesiz Güvenliğin Yatırım Getirisi (ROI) Güvenlik girişimleri genellikle maliyet merkezleri veya sürtünme oluşturucular olarak görülür. DBSC bu anlatıyı tersine çevirir. Aşağıdaki diyagram, cihaz bağlamanın nasıl bir dizi ticari fayda yarattığını göstermektedir: - **Dolandırıcılıkta Azalma:** Hesap Ele Geçirme (ATO) için birincil vektörü etkisiz hale getirerek, işletmeler dolandırıcılık kayıplarında milyonlar tasarruf edebilir. - **Destek Maliyetleri:** [Hesap kurtarma](https://www.corbado.com/tr/blog/tamamen-sifresiz-sisteme-nasil-gecilir) pahalıdır. [Saldırıyı ilk etapta önlemek](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/) bu operasyonel yükü doğrudan azaltır. - **Dönüşüm Optimizasyonu:** [E-ticarette](https://www.corbado.com/passkeys-for-e-commerce), her giriş istemi potansiyel bir ayrılma noktasıdır. DBSC, agresif "oturumu açık tut" politikalarına izin vererek, parola istemleri olmadan anında ödeme yapılmasını sağlar. ### 5.2 Uyumluluk ve "Son Teknoloji" Avrupa'daki GDPR (Genel Veri Koruma Yönetmeliği) gibi yasal çerçeveler, kuruluşların güvenliği sağlamak için "uygun teknik ve organizasyonel önlemleri" uygulamasını gerektirir. - **Savunulabilir Güvenlik:** DBSC bir standart haline geldikçe, oturum yönetimi için "en son teknoloji" olarak yorumlanması muhtemeldir. Bir ihlal durumunda, DBSC'nin uygulandığını kanıtlamak, ihmal iddialarına karşı güçlü bir savunma olabilir. - **Bankacılık Standartları (PSD2):** [Ödeme](https://www.corbado.com/tr/blog/dijital-kimlik-bilgileri-odemeler) Hizmetleri Direktifi 2, "Güçlü Müşteri Kimlik Doğrulaması" (SCA) gerektirir. [SCA](https://www.corbado.com/tr/blog/psd2-ve-passkeys) girişe odaklansa da, oturumun cihaza dinamik olarak bağlanması, direktifin kimlik doğrulamayı belirli miktarlara ve alıcılara bağlama hedefleriyle mükemmel uyum sağlar. ### 5.3 Yüksek Güvenceye Karşı Orta Güvence [FIDO Alliance teknik incelemeleri](https://fidoalliance.org/white-paper-high-assurance-enterprise-fido-authentication/), "Güvence Düzeyleri" kavramını vurgulamaktadır. - **Orta Güvence:** Senkronize geçiş anahtarlarını (iCloud Anahtar Zinciri'ndekiler gibi) kullanır. Tüketici uygulamaları için harikadır, kurtarılabilir, kullanımı kolaydır. - **Yüksek Güvence:** Cihaza bağlı anahtarlar gerektirir. DBSC'nin parladığı yer burasıdır. Kurumsal kaynaklar (İK portalları, kod depoları) veya yüksek değerli [bankacılık](https://www.corbado.com/passkeys-for-banking) için kuruluş, _yalnızca_ belirli bir yönetilen cihaza bağlı oturumlardan erişime izin veren bir politika uygulayabilir. DBSC, bu politika için teknik uygulama mekanizması sağlar. ## 6. DBSC ve Alternatifler DBSC'yi tam olarak takdir etmek için onu benzer sorunları çözmeye çalışan diğer teknolojilerle karşılaştırmalıyız. ```mermaid graph RL subgraph "Geleneksel Çerezler" TC1[Yalnızca Taşıyıcı Token] TC2[Hırsızlığa Karşı Savunmasız] TC3[Uzun Oturumlar = Risk] TC1 --> TC2 TC2 --> TC3 end subgraph "Token Binding" TB1[TLS Katmanı Bağlaması] TB2[❌ Başarısız: Karmaşık Altyapı] TB3[Yük Dengeleyicilerde Kırıldı] TB1 --> TB2 TB2 --> TB3 end subgraph "DPoP" DP1[OAuth Token Bağlaması] DP2[✅ API Koruması] DP3[Tarayıcı Oturumları İçin Değil] DP1 --> DP2 DP2 --> DP3 end subgraph "DBSC" D1[HTTP Katmanı Bağlaması] D2[✅ Donanım Anahtarı Koruması] D3[✅ CDN'ler/YB'lerle Çalışır] D4[✅ Tarayıcı Oturumları] D1 --> D2 D2 --> D3 D3 --> D4 end style TC2 fill:#ff6b6b,color:#fff style TB2 fill:#ff6b6b,color:#fff style D2 fill:#51cf66,color:#fff style D3 fill:#51cf66,color:#fff style D4 fill:#51cf66,color:#fff style DP2 fill:#51cf66,color:#fff ``` ### 6.1 DBSC ve Token Binding Belirtildiği gibi Token Binding, oturumu TLS katmanına bağlamaya çalıştı. - **Token Binding:** İstemciden, sunucudan _ve_ aradaki her adımdan (Yük Dengeleyiciler, TLS Sonlandırıcılar) destek gerektiriyordu. Bir bağlantı sonlandırılıp yeniden şifrelendiğinde kırılıyordu. - **DBSC:** [HTTP uygulama katmanında çalışır](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/). Standart başlıklar/çerezler olarak Yük Dengeleyicilerden şeffaf bir şekilde geçer. TLS'nin genellikle bulut sağlayıcısının uç ağı tarafından işlendiği modern bulut mimarilerinde (AWS/GCP/Azure) dağıtımı çok daha kolaydır. ### 6.2 DBSC ve DPoP (Sahiplik Kanıtını Gösterme) [DPoP (RFC 9449)](https://datatracker.ietf.org/doc/html/rfc9449), "gönderen kısıtlamalı" OAuth tokenleri için standarttır. Hem erişim (access) tokenlerini _hem de_ yenileme (refresh) tokenlerini ortak bir anahtara bağlar—yenileme tokenleri de uzun ömürlü taşıyıcı kimlik bilgileri olduğu için bu kritiktir. Her API isteği bir DPoP kanıtı içerir: HTTP yöntemi, URL, zaman damgası ve benzersiz tanımlayıcı içeren imzalı bir JWT. [FAPI 2.0](https://openid.net/specs/fapi-2_0-security-profile.html) gibi yüksek güvenceli spesifikasyonlar, gönderen kısıtlamalı tokenleri zorunlu kılar; mTLS kullanılamadığında önerilen yöntem DPoP'dur. **Temel fark:** DPoP anahtarları uygulama bağlamında yaşar. En iyi uygulama, dışa aktarılamayan depolama için OS API'lerini kullanmaktır, ancak bu zorunlu değildir—birçok uygulama anahtarları JavaScript erişimine açık bellekte tutar. Bir saldırgan rastgele kod yürütebilirse (XSS, kötü amaçlı yazılım), DPoP anahtarlarına erişebilir veya isteğe bağlı olarak kanıtlar oluşturabilir. DPoP, tokenin _farklı istemciler arasında_ tekrar oynatılmasını (replay) durdurur, ancak güvenliği ihlal edilmiş bir tarayıcı bağlamını koruyamaz. DBSC, sahiplik kanıtını tarayıcıya ve donanıma taşır. Özel anahtar, JavaScript'in okuyamayacağı veya dışa aktaramayacağı bir TPM veya güvenli bölgede yaşar. Tarayıcı protokolü işler ve uygulama koduna anahtarları ifşa etmeden imzalar üretir. Web uygulaması tamamen tehlikeye atılsa bile, bir saldırgan başka bir makinedeki çalınmış çerezler için yeni kanıtlar basamaz. | Yön | DPoP | DBSC | | --------------------- | ----------------------------------------------- | -------------------------------- | | **Hedef** | OAuth erişim + yenileme tokenleri | Tarayıcı oturum çerezleri | | **Anahtar depolama** | Uygulama bağlamı (en iyi uygulama: OS API'leri) | Donanım destekli (TPM) | | **XSS direnci** | ⚠️ Uygulamaya bağlı | ✅ Anahtarlar dışa aktarılamaz | | **Birincil kullanım** | Yerel uygulamalar, SPA'lar, FAPI 2.0 | Kullanıcıya dönük web oturumları | **Sinerji:** [FIDO Alliance'ın belirttiği gibi](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/), geçiş anahtarları girişte oltalama saldırılarını ortadan kaldırırken, DBSC/DPoP [kimlik doğrulama](https://www.corbado.com/tr/blog/digital-credentials-api) sonrası tokenleri korur. Modern bir mimari her ikisini birleştirir: OAuth API'leri için DPoP (özellikle düzenlenmiş açık [bankacılık](https://www.corbado.com/passkeys-for-banking)), tarayıcı oturumları için DBSC. Birlikte, tüm oturum yaşam döngüsü boyunca "al ve taşı" saldırı vektörünü kapatırlar. ### 6.3 DBSC ve Kısa Ömürlü Çerezler (Tek Başına) Çerez ömürlerini kısaltmak (örneğin 15 dakikaya), güvenliği artırır ancak UX'i mahveder. Kullanıcılar sürekli giriş yapmaya zorlanır. DBSC, 30 günlük bir çerezin _Kullanıcı Deneyimi_ ile 5 dakikalık bir çerezin _etkili_ güvenliğine olanak tanır. ## 7. Paylaşılan Sinyaller ve Dinamik Yanıt (CAEP/RISC) ```mermaid %%{init: { "theme": "default", "themeVariables": { "actorBkg": "#ffffff", "actorBorder": "#000000", "noteBkgColor": "#f1f3f5", "noteTextColor": "#000000", "activationBkgColor": "#e0e0e0", "actorColours": { "ST": "#ff6b6b", "IdP": "#4c6ef5" } } }}%% sequenceDiagram participant ST as Güvenlik Araçları
(CrowdStrike, Defender) participant IdP as Kimlik Sağlayıcı
(Okta, Google, Azure) participant SP1 as Hizmet Sağlayıcı 1
(Slack) participant SP2 as Hizmet Sağlayıcı 2
(Salesforce) participant SP3 as Hizmet Sağlayıcı 3
(Bankacılık Uygulaması) participant Session as Kullanıcı Oturumu
(DBSC Korumalı) Note over ST,Session: Tehdit Algılama Aşaması ST->>ST: Kullanıcı cihazında
kötü amaçlı yazılım algılar ST->>IdP: RISC Sinyali:
"Cihaz Ele Geçirildi" Note over IdP,SP3: Sinyal Yayılma Aşaması IdP->>SP1: CAEP Olayı:
"Cihaz Ele Geçirildi" IdP->>SP2: CAEP Olayı:
"Cihaz Ele Geçirildi" IdP->>SP3: CAEP Olayı:
"Cihaz Ele Geçirildi" Note over SP1,Session: Yürütme Aşaması (DBSC ile) Session->>SP1: Bir sonraki yenileme denemesi
(dakikalar içinde) SP1-->>Session: x İmzayı reddet Session->>SP2: Bir sonraki yenileme denemesi SP2-->>Session: x İmzayı reddet Session->>SP3: Bir sonraki yenileme denemesi SP3-->>Session: x İmzayı reddet Note over Session: Oturumlar bir sonraki yenileme denemesinde sonlandırılabilir ``` DBSC'nin potansiyeli, [**Paylaşılan Sinyaller Çerçevesi (SSF)**](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/), özellikle **Sürekli Erişim Değerlendirme Profili (CAEP)** ve **Risk Yönetimi (RISC)** ile birleştirildiğinde daha da artar. Not: SSF/CAEP gelişmekte olan bir ekosistem yeteneğidir—mimari desen tanımlanmıştır, ancak yaygın çapraz satıcı dağıtımı hala olgunlaşmaktadır. Eski modelde, bir kullanıcının cihazı ele geçirilirse, Kimlik Sağlayıcının (IdP) Hizmet Sağlayıcıya (SP) oturumu _hemen şimdi_ sonlandırmasını söylemesinin bir yolu yoktu. SP'nin çerezin süresinin dolmasını beklemesi gerekirdi. Öngörülen DBSC + CAEP akışı: 1. **Tetikleyici:** Bir uç nokta güvenlik aracı (CrowdStrike veya Microsoft Defender gibi), kullanıcının dizüstü bilgisayarında kötü amaçlı yazılım algılar. 2. **Sinyal:** Güvenlik aracı, Kimlik Sağlayıcıya (örn. Okta/Google) bir RISC sinyali gönderir. 3. **Yayılma:** IdP, bağlı uygulamalara bir CAEP olayı gönderir: "Cihaz Ele Geçirildi." 4. **Yürütme (DBSC):** Tarayıcı kısa ömürlü DBSC çerezini yenilemeye çalıştığında, sunucu imzayı reddeder ve oturumu sonlandırır.\ Bu [mimari desen](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/) daha hızlı iptale olanak tanır—gerçek gecikme, sitenin yenileme süresine ve hem DBSC hem de SSF'yi uygulayıp uygulamadıklarına bağlıdır. ## 8. Tarayıcı ve Ekosistem Desteği DBSC'nin benimsenmesi tarayıcı satıcılarına bağlıdır. 2026'daki manzara önemli ölçüde değişti: Chrome, Nisan 2026'da DBSC'yi Origin Trial'dan (Orijin Denemesi) Windows'ta genel kullanıma taşıdı, macOS ise sırada. Diğer tarayıcılar hala değerlendirme aşamasında. ### 8.1 Google Chrome Google, DBSC'nin birincil itici gücü ve onu geniş çapta sunan ilk tarayıcıdır. - **Durum (Nisan 2026):** [Chrome 146, DBSC'yi Windows'ta genel erişime sundu](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/) ve Origin Trial aşamasını sonlandırdı. [Secure Enclave](https://www.corbado.com/glossary/secure-enclave)'i kullanan macOS desteğinin yaklaşan bir Chrome sürümü için duyuruldu. - **Donanım:** Windows TPM'yi kullanır, macOS [Secure Enclave](https://www.corbado.com/glossary/secure-enclave)'i kullanacak. Google, özel güvenli donanımı olmayan cihazlara DBSC korumasını genişletmek için **yazılım tabanlı anahtarları** da araştırdığını belirtti. - **Yol Haritası:** Google'ın GA duyurusu ayrıca bir sonraki adım yol haritasını yayınladı: - **Federe kimliği güvence altına alma:** çapraz kökenli DBSC bağlamaları, böylece bağlı taraf (RP) oturumu kimlik sağlayıcı (IdP) oturumuyla aynı cihaz anahtarına bağlı kalır ve [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) aracılığıyla kesintisiz bir güven zincirini korur. - **Gelişmiş kayıt:** DBSC oturumlarını, oturum açarken yeni bir anahtar oluşturmak yerine **mTLS sertifikaları** veya **donanım güvenlik anahtarları** gibi önceden var olan güvenilir anahtar materyaline bağlama. - **Daha geniş cihaz desteği:** TPM / Secure Enclave olmayan cihazlar için yazılım tabanlı anahtarlar. - **Operasyonel sonuçlar:** Kullanıma sunulması sırasında Google, DBSC tarafından korunan oturumlar için "oturum hırsızlığında önemli bir azalma" bildirdi. - **Google Hesapları:** Ayrı olarak Google, kurumsal politika aracılığıyla kontrol edilen [Windows için Chrome'daki Google hesabı çerezleri](https://support.google.com/chrome/a/answer/2657289) için DBSC tarzı korumayı zaten kullanıma sunmuştu. Bu, Gmail/Workspace'i korur ve artık genel web için GA olan aynı teknoloji ailesidir. ### 8.2 Microsoft Edge ve Windows Microsoft aktif olarak katılıyor. - **Durum:** Edge, Ekim 2025'te sona eren Windows'ta bir [DBSC Origin Trial](https://developer.microsoft.com/microsoft-edge/origin-trials/trials/0c292c9b-58fe-4f23-b066-c3b58911024d) çalıştırdı. Yedek deneme veya GA duyurulmadı. - **Kurumsal Bağlam:** Edge, kavramsal olarak DBSC'ye benzeyen Entra/Azure AD [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) için ["Birincil Yenileme Belirteci" (PRT) mimarisini](https://learn.microsoft.com/en-us/entra/identity/devices/concept-primary-refresh-token) kullanır. PRT, Microsoft'a özgü bir mekanizma olmaya devam ediyor; üçüncü taraf siteler için DBSC web standardıyla birleştirmeye yönelik açıklanmış bir plan yok. ### 8.3 Apple Safari (WebKit) Apple'ın duruşu mobil kapsama alanı için kritik. - **Durum:** WebKit'te, kullanılabilirlik/gizlilik endişeleri belirtilerek DBSC'yi değerlendiren bir [standart konum sorunu (standards-position issue)](https://github.com/WebKit/standards-positions/issues/281) var. Safari sürüm notları DBSC'den bahsetmiyor. Halka açık bir "aktif olarak uygulanıyor" açıklaması mevcut değil. - **Önce Gizlilik:** Apple'ın temel endişesi, DBSC'nin "süper çerezler" (silinemeyen izleme) için kullanılabilmesidir. W3C spesifikasyonu, anahtarların web sitesi verileriyle birlikte temizlenmesini sağlayarak bunu ele alır. - **Katılım:** WebKit standart sürece katılıyor, ancak uygulama durumu belirsiz—"geliştirme aşamasında" olmaktan çok "tartışma aşamasında". ### 8.4 Mozilla Firefox Mozilla'nın, karmaşıklık ve gizlilikle ilgili belirtilen endişelerle DBSC'yi değerlendiren bir [standart konum sorunu](https://github.com/mozilla/standards-positions/issues/912) var. Standart istikrara kavuştuktan sonra uygulamak için kamuya açık bir taahhüt yoktur. ## 9. Öneriler: Bugün Kullanıcıları Korumak DBSC ve geçiş anahtarları için mevcut ekosistem desteği göz önüne alındığında, kuruluşlar bu tamamlayıcı teknolojileri uygulamak için aşamalı bir yaklaşım benimsemelidir. Aşağıdaki yol haritası, acil eylemleri ve stratejik planlama kilometre taşlarını ana hatlarıyla belirtmektedir: ### 9.1 Acil Eylemler (şimdi Chrome 146 GA olduğuna göre) 1. **Önce Geçiş Anahtarlarını Dağıtın**: [Kimlik doğrulama](https://www.corbado.com/tr/blog/digital-credentials-api) katmanını güvence altına almak için geçiş anahtarı uygulamasıyla başlayın. Bu, kimlik bilgisi avına karşı anında koruma sağlar ve DBSC'den gerçek değer elde etmenin önkoşuludur. 2. **DBSC Kayıt ve Yenileme Uç Noktalarını Gönderin**: Chrome 146 GA ile gerçekçi çalışma artık arka uç entegrasyonudur: giriş yanıtlarına `Secure-Session-Registration` başlıkları ekleyin ve `/dbsc/register`'ı, imzalı sorguları doğrulayan bir yenileme uç noktasıyla birlikte uygulayın. Ön uç kodunun değişmesi gerekmez. 3. **Yenileme Tokenleri ile Kısa Ömürlü Oturumları Uygulayın**: Henüz DBSC'ye hazır değilseniz, yenileme mekanizmaları ile kısa ömürlü tokenlerin mimari desenini benimseyin. Bu, bugün güvenliği artırırken arka ucunuzu DBSC'ye hazırlar. ### 9.2 Stratejik Planlama (önümüzdeki 12 ay) 1. **Hibrit Bir Yaklaşım Benimseyin**: Geri dönüş seçeneklerini (fallback) korurken yetenekli tarayıcılara (şu anda Windows'ta Chrome 146+, sırada macOS Secure Enclave) DBSC sunmak için özellik algılamayı kullanın. Bu, Safari, Firefox veya Edge'deki kullanıcıları dışlamadan güvenliği en üst düzeye çıkarır. 2. **Sonraki Yol Haritası Öğelerine Hazırlanın**: Google, daha geniş cihaz kapsamı için federe kimlik (çapraz kökenli SSO bağlamaları), gelişmiş kayıt (mTLS / donanım anahtarları) ve yazılım tabanlı anahtarları açıkça belirtti. Bir SSO veya IdP katmanı çalıştırıyorsanız, şimdiden çapraz kökenli bağlamayı (cross-origin binding) kapsamaya başlayın. 3. **Kimlik Sağlayıcılarla Entegre Olun**: Okta, [Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis) veya benzer IdP'leri kullanıyorsanız, SDK'larında DBSC desteğini etkinleştirmek için onlarla birlikte çalışın. Birçoğu Origin Trial'lara (Orijin Denemelerine) katıldı ve Chrome GA olduğuna göre DBSC özelliklerini aktif olarak kullanıma sunuyor. ### 9.3 Uygulama En İyi Uygulamaları - **Yüksek Değerli Hedeflerle Başlayın**: Yönetici panelleri, finansal işlemler ve hassas veri erişimi için DBSC'ye öncelik verin. - **Yönetilen Çözümleri Kullanın**: DBSC uygulamasının ve tarayıcı uyumluluğunun karmaşıklığını ele alan Corbado gibi platformları düşünün. - **Ölçün ve Tekrarlayın**: ROI'yi göstermek için oturum ele geçirme girişimleri, destek biletleri ve kullanıcı sürtünmesi gibi metrikleri izleyin. - **Uyumluluğa Hazırlanın**: Hassas verilerin işlenmesinde muhtemelen bir uyumluluk gereksinimi haline geleceği için DBSC uygulamanızı belgeleyin. ## 10. Corbado Nasıl Yardımcı Olabilir: Geleceğe Köprü DBSC'yi sıfırdan uygulamak büyük bir mühendislik yüküdür. Kriptografik uzmanlık, tarayıcı tutarsızlıkları hakkında derin bilgi ve anahtarları ve sorguları yönetmek için sağlam bir sunucu tarafı altyapısı gerektirir. İşte bu noktada **Corbado** bir etkinleştirici olarak hizmet eder. ### 10.1 Temel: Geçiş Anahtarları Düşük güvenceli bir girişin üzerine yüksek güvenceli bir oturum kuramazsınız. Bir kullanıcı zayıf bir parolayla giriş yaparsa, oturum yalnızca o parola kadar güvenli olur. Corbado'nun temel ürünü (**yönetilen geçiş anahtarları**) gerekli temeli sağlar. Kuruluşlar, Corbado'yu entegre ederek geçiş anahtarlarını kolayca dağıtabilir ve oturumun başlangıcının oltalama saldırılarına karşı dirençli olmasını sağlar. ### 10.2 Gelecek: Güvenilir Cihaz Tespiti için DBSC Corbado, güvenilir cihaz tespitini geliştirmek için DBSC'den yararlanacaktır. DBSC sinyalleri mevcut olduğunda, bir oturumun belirli bir cihazdan kaynaklandığına dair kriptografik kanıt sağlarlar ve bu da Corbado'nun kimlik doğrulama güven düzeylerini buna göre artırmasına olanak tanır. - **Senkronize Geçiş Anahtarı Belirsizliğini Çözmek:** Senkronize geçiş anahtarları (synced passkeys) kullanışlıdır ancak bir güven boşluğu yaratır: bir kullanıcı senkronize edilmiş bir [geçiş anahtarı](https://www.corbado.com/tr/blog/guvenli-belge-yonetimi)yla kimlik doğruladığında, bunun onun her zamanki dizüstü bilgisayarı mı yoksa kimlik bilgisini yeni senkronize eden yepyeni bir cihaz mı olduğunu anlayamazsınız. DBSC bu boşluğu kapatır. Corbado, cihazın kurulu bir DBSC bağına sahip olup olmadığını kontrol ederek, cihazın sadece ilk senkronizasyon değil, gerçekten bilinen ve güvenilen bir cihaz olduğunu doğrulayabilir. - **Bilinen Cihazlar İçin Daha Yüksek Güven:** DBSC sinyalleri bir cihazın daha önce görüldüğünü onayladığında, Corbado daha emin risk kararları verebilir: meşru dönen kullanıcılar için daha az ek kimlik doğrulama (step-up authentication) istemi, tanınmayan cihazlardan gelen oturumlar için daha sıkı inceleme. - **Geçiş Anahtarı Zekasını Tamamlama:** DBSC sinyalleri, Corbado'nun mevcut [**Passkey Intelligence**](https://docs.corbado.com/corbado-connect/features/passkey-intelligence) motoruyla entegre olur. Geçiş anahtarı tabanlı kimlik doğrulama ve DBSC tabanlı cihaz bağlamanın birleşimi, girişten tüm oturum yaşam döngüsüne kadar eksiksiz bir güven zinciri oluşturur. Corbado'nun DBSC'yi platformuna nasıl entegre etmeyi planladığına dair sorularınız için [ekibe ulaşın](https://www.corbado.com/contact). ### 10.3 Zarif Geri Dönüş ("Hibrit" Gerçeklik) Önümüzdeki birkaç yıl boyunca web hibrit (karma) olacak. Bazı kullanıcılar DBSC yetenekli tarayıcılara (Windows 11'de Chrome) sahip olacak; diğerleri ise eski sistemlerde olacak. Bu parçalanmayı idare etmek zordur. Corbado'nun [**Passkey Intelligence**](https://docs.corbado.com/corbado-connect/features/passkey-intelligence) motoru, yetenekli cihazlara geçiş anahtarları ve diğerlerine geri dönüşler (fallbacks) sunarak tam olarak bu tür geri dönüş mantığını işlemek üzere tasarlanmıştır. Aynı zeka, oturum bağlamaya da uygulanır ve güvenliğin her kullanıcı için cihazlarının yeteneklerine göre en üst düzeye çıkarılmasını sağlar. ## 11. Sonuç: DBSC İçin İleriye Giden Yol "Taşıyıcı Token" dönemi sona eriyor. Mevcut oturum yönetimi feci şekilde başarısız oluyor — taşıyıcı tokenler, endüstriyel ölçekteki kötü amaçlı yazılım operasyonları tarafından çalınabilir ve en güçlü kimlik doğrulama yöntemlerini bile atlayan hesap ele geçirmelerine olanak tanıyarak herhangi bir cihazdan kullanılabilir. Bu temel güvenlik açığı, milyarlarca dolar değerinde bir yeraltı ekonomisi yarattı. Cihazlara Bağlı Oturum Kimlik Bilgileri (DBSC), sektörün gelişmekte olan yanıtını temsil ediyor. HttpOnly bayrakları ve statik sırlarıyla geleneksel güvenli çerezlerin aksine DBSC, cihaza bağlı anahtarlar aracılığıyla kriptografik sahiplik kanıtı ekler. Bu, çalınan çerezleri çok daha az değerli hale getirir. Başka bir cihazdan yenilenemezler. Token Binding, tüm altyapıda karmaşık TLS katmanı değişiklikleri gerektirerek başarısız olduğu yerde, DBSC mevcut yük dengeleyiciler ve CDN mimarileriyle uyumlu olarak HTTP uygulama katmanında çalışarak başarılı olur. Not: DBSC'nin tarayıcının bağlamayı atladığı (TPM kullanılamıyor, ağ hataları) belgelenmiş geri dönüş (fallback) yolları vardır, bu nedenle çerez hırsızlığı riskini ortadan kaldırmaz ancak büyük ölçüde azaltır. DBSC ve Geçiş Anahtarları (Passkeys) arasındaki sinerji, kullanıcı yolculuğu boyunca saldırganlar için çıtayı önemli ölçüde yükseltir. Geçiş anahtarları, girişte kimlik bilgisi oltalama saldırılarını ortadan kaldırırken, DBSC, uzaktan çerez hırsızlığı yoluyla oturum ele geçirmeyi çok daha zorlaştırır - ikisi birlikte, [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance)'ın öngördüğü "yüksek güvenceli" kimlik çerçevesini oluşturur. [Chrome 146'nın Nisan 2026'da Windows'ta GA olarak DBSC sunmasıyla](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/) ve macOS Secure Enclave desteğinin de sırada olmasıyla, standart hazırlık aşamasından çıkıp sunum aşamasına geçmiştir. Google'ın yayınlanan yol haritası (federe kimlik, mTLS / donanım anahtarı kaydı, yazılım tabanlı anahtarlar) önümüzdeki 12 aylık genişlemenin sinyalini veriyor. Ürün Yöneticileri için iş senaryosu (business case) ilgi çekicidir: DBSC, dolandırıcılık kayıplarını ve destek maliyetlerini aynı anda azaltırken, giriş sürtünmesini önemli ölçüde azaltan "sınırsız" güvenli oturumlara olanak tanır. ROI, daha yüksek dönüşüm oranları, daha az parola sıfırlama bileti ve ortadan kalkan hesap ele geçirme olayları olarak kendini gösterir. OAuth kullanan kuruluşlar, API tokenleri için DPoP aracılığıyla aynı anahtar bağlama konseptinden yararlanabilirken, Paylaşılan Sinyaller (CAEP/RISC) ile entegrasyon, gerçek zamanlı tehdit yanıtını mümkün kılar — tehlikeye atılmış oturumları bir sonraki yenileme girişiminde anında iptal eder. Uygulamanın sıfırdan oluşturulması gerekmez. [Corbado](https://www.corbado.com/features) gibi platformlar geçiş anahtarı altyapısı sağlar ve tarayıcı desteği olgunlaştıkça cihaz bağlamayı entegre etmek için DBSC gelişmelerini takip etmektedir. [W3C spesifikasyonu](https://www.w3.org/TR/dbsc/) aktif bir Çalışma Taslağıdır (Working Draft), Chrome 146 Windows'ta GA'dır ve macOS'a sunulmaktadır ve diğer tarayıcılar hala standardı değerlendirmektedir. Gidişat nettir: Bugün Geçiş Anahtarlarını ve DBSC'yi benimsemeye başlayan kuruluşlar, [parolasız](https://www.corbado.com/tr/blog/gecis-anahtari-uygulamalari-neden-basarisiz-olur), oltalamaya dirençli gelecek için en iyi şekilde konumlanacaktır. Soru, cihaza bağlı oturumların uygulanıp uygulanmayacağı değil, kullanıcılarınızı ve işinizi korumak için bunları ne kadar hızlı dağıtabileceğinizdir. Web güvenliğinin geleceği yalnızca kimliği doğrulanmış (authenticated) değil; güvendiğimiz cihazlara kriptografik olarak bağlıdır. ## Sıkça Sorulan Sorular ### DBSC, ele geçirilmiş oturumları gerçek zamanlı olarak iptal etmek için CAEP ve RISC ile nasıl çalışır? CrowdStrike gibi uç nokta güvenlik araçları kötü amaçlı yazılım algıladığında, Kimlik Sağlayıcıya bir RISC sinyali gönderir, bu da bağlı uygulamalara bir CAEP 'Cihaz Ele Geçirildi' olayı gönderir. Bir sonraki DBSC yenileme girişiminde (dakikalar içinde), bu uygulamalar oturum imzasını reddeder ve erişimi sonlandırır. Çapraz satıcı CAEP/RISC dağıtımı hala olgunlaşmaktadır. ### Web uygulaması oturumlarını korumak için DBSC ve DPoP arasındaki fark nedir? DPoP (RFC 9449), öncelikle yerel uygulamalarda ve SPA'larda API çağrılarını koruyarak OAuth erişim ve yenileme tokenlerini uygulama katmanında genel bir anahtara bağlar. DBSC, tarayıcı oturum çerezlerini JavaScript'in okuyamayacağı veya dışa aktaramayacağı donanım destekli TPM anahtarlarına bağlar ve web uygulamasının kendisi XSS veya kötü amaçlı yazılım tarafından tehlikeye atılmış olsa bile kullanıcıya dönük oturumları korur. ### DBSC neden güvenlik riskini artırmadan daha uzun oturum sürelerine izin veriyor? Geleneksel güvenli tasarım, bir çerez çalınıp uzaktan yeniden oynatıldığında (replayed) hasarı sınırlamak için kısa oturum zaman aşımlarını zorunlu kılar. DBSC, yenileme yeteneğini kaynağı olan cihazın özel anahtarına bağlar, böylece farklı bir cihazdan kullanılan çalınmış bir çerez kriptografik sorguda başarısız olur. Uzaktan yeniden oynatma saldırıları etkisiz hale getirildiği için oturumlar etkili bir şekilde süresiz olabilir. ### Kuruluşlar DBSC dağıtımından hangi ticari ROI'yi bekleyebilir? DBSC, birincil Hesap Ele Geçirme vektörü olarak çerez hırsızlığını etkisiz hale getirir ve doğrudan dolandırıcılık kayıplarını ve [hesap kurtarma](https://www.corbado.com/tr/blog/tamamen-sifresiz-sisteme-nasil-gecilir) destek maliyetlerini azaltır. Güvenli uzun oturumlar, tekrarlanan giriş istemlerini ortadan kaldırarak e-ticarette dönüşüm oranlarını iyileştirir ve müşteri kaybını (drop-off) azaltır. [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance), DBSC'yi kullanıcı sürtünmesini aynı anda azaltırken güvenlik çıtasını yükselten bir teknoloji olarak konumlandırır.