BioAffix Mul‑Sec, Ones Technology tarafından geliştirilmiş bir şifreleme protokolüdür. Halihazırda BioAffix altyapısında etkin olarak kullanılmaktadır. İstemci – sunucu – işlemci iletişim zincirinde, standart TLS/SSL tünelinin içerisine uygulamaya özgü ikinci bir TLS tüneli (“TLS‑in‑TLS”) kurar. Bu sayede işletim sistemi seviyesinde yapılan TLS araya‑girme/MITM/debug ve yük dengeleyicideki TLS offload/inspection senaryolarında uygulama verisi opak kalır; package id özelliği sayesinde yeniden gönderim (replay-attack) ve sahte istemci riskleri azaltılır. İç tünel, İşletim Sistemi Kök Sertifika Deposundan bağımsız bir güven kökünden beslenir ve her oturum‑başı için yeniden oluşturulan kısa ömürlü sertifikalarla kuruludur. Böylece, kritik kimlik/erişim operasyonları uçtan uca gizlilik ve kimlik doğrulamasıyla korunur.
BioAffix Mul‑Sec, Ones Technology tarafından, Sosyal Güvenlik Kurumu’nun Biyometrik Geçiş Kontrol Sistemleri gerçekleştirilirken; tüm ülke vatandaşlarının biyometrik verilerinin toplanması sürecinde sunucu/veri merkezi tarafındaki kötü niyetli personel ya da sistemi kodlayan‑geliştiren çalışanlar kaynaklı risklere karşı biyometrik ve hassas verilerin ele geçirilmesini önlemek amacıyla geliştirilmiş bir iletişim protokolüdür. Kurumsal CA enjeksiyonu, TLS offload ve istemci‑tarafı debug araçlarının yarattığı görünürlük risklerinin pratikte gözlemlenmesi sonucunda, Mul‑Sec bu boşluğu uygulama‑düzeyi, oturum‑başı TLS‑in‑TLS yaklaşımıyla kapatmıştır.
Terminoloji
- TLS/SSL: Teknik olarak TLS 1.2/1.3 kastedilir.
- Dış Tünel (Outer TLS): Standart x.509 sertifikalarıyla kurulan, tarayıcı/OS kütüphanesinin yönettiği tünel. Bu tünel Load Balancer/Yük Dengeleyici üzerinde sonlandırılabilir.
- İç Tünel (Inner TLS / Mul‑SEC Tüneli): Uygulama içinde çalışan, yalnızca Mul‑SEC güven köküne ve derleme imzasına dayalı olarak kurduğu ikinci tünel. Her bağlantı için kısa ömürlü (ephemeral) sertifikalar/anahtarlar kullanır.
- İstemci: BioAffix İstemci Uygulamaları.
- Sunucu: BioAffix Uygulama Sunucusu, BioAffix OneServer.
Sorun Tanımı: Standart TLS’in Tek Başına Yetersiz Kaldığı Durumlar
İstemci tarafında TLS’in debug edilmesi
İşletim Sistemi seviyesinde TLS’i kullanan uygulamalar, Fiddler / HTTPS Analyzer benzeri araçlar veya kurumsal kök sertifikası enjekte edilerek man‑in‑the‑middle (MITM) ile incelenebilir. Bu durumda veri paketleri görülebilir veya paketler yeniden gönderilebilir.
Yük dengeleyicide TLS offload / inspection
Yüksek trafiğe sahip mimarilerde SSL/TLS, Load Balancer/Yük Dengeleyici üzerinde sonlandırılıp içeriği L7’de incelenebilir ve ardından veri merkezinde daha zayıf/kurumsal CA ile yeniden şifrelenebilir. Kötü niyetli veya yetkisi aşılmış personel gelen‑giden veriyi inceleyebilir (Port mirroring – package mirroring).Bu iki durum, gizliliği zedeler. Özellikle “güvenilen sertifika deposu” cihaz/işletim sistemi tarafından yönetiliyorsa, kurum içi CA sertifikasına erişim veya yükleme ile içerik okunabilir.
Mul‑Sec Tasarım İlkeleri
- Uygulama‑düzeyi gizlilik: Dış TLS açılmış olsa bile uygulama verisi ikinci bir tünel ile gizli kalır.
- Derleme zamanı güven kökü: İç tünel güveni, uygulamanın imzası ve Mul‑Sec gömülü kök anahtarı üzerinden kurulur; işletim sistemi kök deposundan bağımsızdır.
- Oturum‑başına anahtarlar: Her bağlantı için kısa ömürlü sertifika/anahtar üretimi; yeniden kullanımı ve replay attackları zorlaştırır.
- Şeffaf topoloji uyumu: Load Balancer/Yük Dengeleyici offload, reverse proxy vb. varlığında dahi içerik opak kalır.
- Güven Kökü (Root CA): Yazılım içine gömülüdür.
- Uygulama İmzası: Uygulama imzasını doğrular; beklenenle eşleşmezse iç tünel kurulmaz.
- Oturum Sertifikaları: Her bağlantı için tek‑kullanımlık istemci ve/veya sunucu sertifikası oluşturulur.
Güvenlik Özellikleri ve Tehdit Azaltımları
- İşletim Sistemi kök deposundan bağımsızlık: İç tünel yalnızca yazılım içine gömülü güven köküne güvenerek kurulur; kurumsal CA enjekte edilse dahi işe yaramaz.
- Çift katman şifreleme: Dış TLS açılsa bile, uygulama verisi ikinci katmanda şifreli kalır.• Oturum‑başı anahtar/sertifika: Replay ve anahtar sızıntısının etkisi tek bağlantı ile sınırlıdır.
- Derleme imzası doğrulaması: Yalnızca beklenen uygulama binarisi iç tünel açabilir; re‑packaged/patch’li istemciler engellenir.
- Load Balancer/Yük Dengeleyici: L7 inspection etkin olsa bile iç tünel içeriği görülemez; yalnızca şifreli byte‑stream taşınır.
Not: Mul‑Sec, ağ uçlarında trafik metadatasını (kaynak IP, zaman, byte sayısı vb.) saklamaz; gizlilik uygulama yükündedir.
Politikalara Uygunluk
- KVKK/GDPR: Aktarım sırasında ek şifreleme katmanı ile veri sızıntısı riskini azaltır.
- ISO/IEC 27001 (A.8 Kriptografi, A.5 Erişim Kontrolleri): Politika ve teknik kontrol gereksinimlerine uygunluğu kolaylaştırır.
Sınırlamalar
- Çift katman şifreleme CPU ve gecikme üzerinde ölçülebilir bir ek yük getirir. Tipik etkiler; paket boyutu, el sıkışma sıklığı ve donanım hızlandırmasına göre değişir.
- İç tünel trafiği L7 cihazları tarafından denetlenemez.
Sık Sorulan Sorular
Zaten mTLS kullanıyoruz, farkı ne?
Mul‑Sec, mTLS’i de içeren ama dış TLS’in içine gömülü ek bir tünel kurar ve güveni işletim sistemi kökünden bağımsız hale getirir. Dolayısıyla LB’de TLS/mTLS offload yapılsa bile, Mul-SEC’in iç tünelindeki uygulama verisi opak kalır.
Load Balancer/Yük Dengeleyici’de TLS’i açıyoruz, sorun olur mu?
Hayır. İç tünel şifreli kaldığı için uygulama yükü Load Balancer/Yük Dengeleyici’de görünmez.
Anahtar sızarsa ne olur?
Oturum anahtarları kısa ömürlüdür; sızıntının etkisi tek bağlantıyla sınırlanır.
BioAffix E-Posta Bültenine Abone Olun
Dört ayda bir yayınlanan BioAffix elektronik posta bültenine abone olarak yeni gelişmeler hakkında bilgi sahibi olabilirsiniz.
