Merhaba

TLS’e Genel Bakış

Birçok uyumluluk çerçevesi (compliance framework), internet üzerinden taşınan hassas verilerin şifreleme ile korunmasını zorunlu tutar. Bu şifreleme gereksinimini karşılamak için de en sık başvurulan yöntem Transport Layer Security (TLS) olur. Ancak sahada karşılaşılan tabloya bakınca, TLS’in nasıl çalıştığını tam olarak anlamayan ve bu yüzden güvensiz TLS yapılandırmaları devreye alan kurumların sayısı hiç de az değil. Sonuç: denetimlerde uyumluluk hataları.

Bu yazıda önce TLS’e üst seviyeden bakacağız ve neredeyse tüm uyumluluk gereksinimlerini karşılayacak güvenli bir yapılandırma için atılması gereken adımları özetleyeceğiz. Ardından TLS’in nasıl çalıştığını ve bu adımların neden önemli olduğunu daha derinlemesine inceleyeceğiz. Not: Bu yazı herhangi bir çerçevenin (PCI DSS, HIPAA vb.) kendine özgü gereksinimlerini tek tek ele almıyor; amaç genel geçer, sağlam bir temel oluşturmak.

Üst seviyeden bakıldığında TLS, iki uç nokta (endpoint) arasında şu üç işi yapan bir protokol olarak düşünülebilir:

1. Kimlik doğrulama: Bir veya iki uç noktanın kimliğini, içinde kriptografik bilgi barındıran certificate adı verilen özel dosyalar aracılığıyla doğrulamak.
2. Güvenli müzakere (negotiation): Her iki uç noktanın da desteklediği uygun bir kriptografik algoritma kümesini, yani cipher suite‘i belirlemek için güvenli bir pazarlık yürütmek.
3. İletişimin korunması: Üzerinde anlaşılan cipher suite’i kullanarak iletişimi yetkisiz dinlemeye, taklide (impersonation) ve değiştirilmeye karşı korumak.

Güvenliği zayıflatıp uyumluluk sorunlarına yol açabilecek başlıca TLS problemleri şunlardır:

• Protokolün kendisindeki zafiyetler: TLS protokolünde bir saldırganın şifrelemeyi kırmasına imkan verebilecek kusurlar bulunabilir. Bunları gidermek genelde eski sürümleri kapatmak, üretici yamalarını uygulamak ve kurulum bazında yapılandırma ayarlarıyla kusurları aşmak gibi adımların kombinasyonunu gerektirir.
• Kriptografik algoritmalardaki zayıflıklar: En güncel TLS sürümünde bile olsa, zayıf algoritmayı kullanan cipher suite’lerin devre dışı bırakılması gerekir.
• Certificate ve anahtar yönetiminin yanlış yapılması: Kötü yönetim, saldırganların uç noktaları taklit etmesine ve/veya hassas veriyi çözüp okumasına ya da değiştirmesine olanak tanır.
• Hatalı yazılım implementasyonu: TLS protokolünün ve algoritmaların yanlış uygulanması veya yazılıma sokulan istismar edilebilir hatalar. Bunlar üretici yamalarıyla giderilir.

Sık Karşılaşılan Sorunlar ve Çözümleri

TLS şifrelemesiyle ilgili en sık görülen uyumluluk sorunları ve çözümleri aşağıdaki tabloda özetlenmiştir. Her biri yazının devamında ayrıntılı olarak açıklanıyor.

Sorun	Çözüm
Eski, zafiyetli TLS ve/veya SSL sürümlerinin açık bırakılması	2026 itibarıyla yalnızca TLS v1.2 ve v1.3 açık olmalı
Eski, zayıf TLS cipher suite’lerinin açık bırakılması	IANA TLS Parameters listesini kullanarak önerilen, deprecated ve önerilmeyen suite’leri belirleyin; deprecated ve önerilmeyenleri devre dışı bırakın
Zayıf anahtar veya imzaya sahip certificate kullanımı	ECC destekleniyorsa 256-bit+ ECC anahtar + SHA-256+; ECC yoksa 2048-bit+ RSA + SHA-256+
Self-signed certificate’ların uygunsuz kullanımı	Yalnızca test ortamlarında veya uç noktalarda pinlenebildiği sıkı kontrollü durumlarda kullanın
Süresi dolmuş certificate kullanımı/kabulü	Sertifikaları süresi dolmadan yenileyin; sistemleri süresi dolmuş sertifikaları reddedecek şekilde yapılandırın
Domain’i yanlış tanımlanmış veya uyuşmayan certificate kullanımı/kabulü	Domain bilgisini doğru tanımlayın; domain uyuşmazlığı olan sertifikaları reddedin
Kriptografik anahtarların yönetilmemesi	Key management yazılımı ve/veya HSM kullanın; anahtarları en az yerde saklayın, en az kişiye erişim verin, envanter tutun
Gerektiğinde FIPS 140 doğrulaması olmayan TLS yazılımı kullanımı	Mümkünse FIPS 140-3, yoksa FIPS 140-2 doğrulanmış kriptografik yazılım kullanın
FIPS 140 gerekli iken FIPS dışı algoritma/özelliklerin açık bırakılması	Üretici dokümanına göre FIPS 140 uyumlu yapılandırma ayarlarını uygulayın

TLS Nasıl Çalışır?

Bir TLS implementasyonu, her biri aşağıda ayrı ayrı ele alınan beş ayrı parçadan oluşur:

• Protokol: Hangi kriptografik algoritmaların kullanılacağını müzakere etmek için standartlaştırılmış prosedürler bütünü.
• Cipher suite’ler: Bilgiyi okunamaz hale getiren ve değiştirilmediğini doğrulayan standart kriptografik algoritma kümeleri.
• Certificate’lar: Bir cihazın iddia ettiği kişi/sistem olduğunu kriptografik olarak doğrulamaya yarayan standart dosyalar.
• Key management: Şifreleme ve şifre çözme süreçlerinde kullanılan kriptografik anahtarların yönetimi.
• Yazılım implementasyonları: Müzakere protokolünü, cipher suite’leri, sertifika üretimini ve anahtar yönetimini gerçekleştiren yazılımlar.

Müzakere Protokolü (Negotiation Protocol)

Yaygın bir yanılgı vardır: TLS (Transport Layer Security) ve öncülü SSL’in (Secure Sockets Layer) kendisinin bir şifreleme türü olduğu sanılır. Oysa bunlar birer şifreleme değil, iki cihazın iletişimlerini güvence altına almak için şifrelemeyi nasıl kullanacaklarını güvenli biçimde müzakere ettiği protokollerdir. TLS 1.3 ya da SSL 3.0 gibi bir sürüm ifadesi, müzakere sürecinin kurallarını belirleyen protokol sürümüne işaret eder. Her TLS/SSL sürümü, cihazların içinden seçim yapabileceği standart bir kriptografik algoritma listesi barındırır.

SSL ve TLS protokolleri 1995’teki ilk SSL sürümünden bu yana zaman zaman güncellendi. Pratik açıdan SSL’den TLS’e geçiş yalnızca bir isim değişikliği olarak düşünülebilir; SSL sürümleri de TLS’in önceki sürümleri gibi ele alınabilir. Web sunucuları, mail sunucuları, VPN, VoIP gibi TLS destekleyen servislerin çoğu birden fazla TLS sürümünü aynı anda destekleyebilir. Bu sayede yeni bir sürüm devreye alınırken eski sürüm hemen kapatılmadan, henüz güncellenmemiş cihazlarla bağlantı korunabilir.

Tipik bir TLS güncellemesi; protokolün müzakere sürecini etkileyebilecek zayıflıklarını giderir, daha yeni ve güvenli algoritmalar için yeni cipher suite’ler ekler ve artık güvenli sayılmayan eski cipher suite’leri kaldırır.

Bu müzakere sürecinin güvenliği kritiktir: Bir saldırgan iki uç nokta arasındaki müzakereyi araya girip değiştirebilirse (man-in-the-middle / MitM saldırısı), uç noktaları zayıf şifrelemeye -hatta hiç şifreleme kullanmamaya- ikna edebilir ve iletişimi dinleyip okuyabilir, hatta değiştirebilir. Bu nedenle kurumların eski ve zayıf TLS/SSL sürümlerini kapatması gerekir; aksi halde bir MitM, uç noktaları güvensiz bir sürüme geri düşürebilir (downgrade).

2026 itibarıyla durum şu:

• TLS v1.3 (2018’de yayımlandı) en güncel sürümdür ve geniş biçimde desteklenir.
• TLS v1.2 (2008) doğru yapılandırıldığında hala güvenli kabul edilir ve geniş desteğe sahiptir.
• TLS 1.0 / 1.1 ve tüm SSL sürümleri güvensiz ve deprecated kabul edilir; kullanılmamalı, açık bırakılmamalıdır.

Bir TLS bağlantısı kurmak için her iki uç noktada da en az bir ortak TLS sürümünün açık olması yeterlidir; açık sürümlerin tam listesinin birebir aynı olması gerekmez.

Cipher Suite’ler

Cipher Suite Nedir?

Modern şifreleme karmaşık bir süreçtir; çünkü farklı kriptografik algoritmalar farklı amaçlara hizmet eder (bir mesajı dinlenmeye karşı korumak ile mesajın değiştirilmediğini doğrulamak farklı işlerdir). Bu farklı türde algoritmaları tek bir cipher suite altında birleştirmek, her algoritmanın güçlü yönlerinden yararlanıp zayıf yönlerinden kaçınan çok daha etkili ve verimli bir şifreleme çözümü sunar. Birçok algoritma farklı anahtar uzunluklarıyla kullanılabilir; daha uzun anahtar daha güçlü ama daha az verimlidir. Bir cipher suite, uygun yerlerde algoritmaları anahtar uzunlukları ve modlarıyla birlikte belirtir.

TLS’te Cipher Suite’ler

Her TLS protokol sürümü, standart bir cipher suite listesi içerir. Bir TLS oturumu başlatıldığında uç noktalar haberleşerek her birinin desteklediği suite’leri belirler ve hangisinin kullanılacağı üzerinde anlaşır. Cipher suite’ler, hangi TLS sürümleri açık olursa olsun uç nokta yapılandırmalarında tek tek devre dışı bırakılabilir. Bağlantı için iki uçta da en az bir ortak suite açık olmalıdır; tam liste eşleşmesi gerekmez.

Bu esneklik, bir algoritmada zayıflık bulunduğunda işe yarar: her zafiyette komple yeni bir TLS sürümü yaymaktansa, yapılandırmadan tek bir cipher suite’i kapatmak çok daha kolaydır. Kurumlar şifreleme kusurlarına dair güvenlik uyarılarını düzenli takip etmeli ve güvensiz algoritma kullanan suite’leri kapatmalıdır. Önerilen cipher suite’ler için kesin kaynak IANA TLS Parameters listesidir. Bu listedeki “Recommended” sütununda “Y” (Yes) kullanılması gerekenleri, “D” (Deprecated) kullanılmaması gerekenleri, “N” (No) ise uzlaşıya varılmamış veya yalnızca özel senaryolar için düşünülmüş (genelde kullanılmayan) suite’leri gösterir.

Bir başka sık başvurulan kaynak, birçok zafiyet tarama aracının da referans aldığı Ciphersuite.info‘dur. Ancak bağımsız bir proje olduğundan IANA önerilerinin gerisinde kalabilir; yazının hazırlandığı sırada, Ciphersuite.info’da “Secure” işaretli bazı algoritmaların IANA listesinde önerilmeyen olarak işaretlendiği görülmüştür. Bazı çerçeveler kabul edilebilir suite’ler için NIST SP 800-52‘ye atıf yapar; fakat seyrek güncellendiğinden pratik değeri sınırlıdır.

Cipher Suite İsimlerini Okumak

Bir cipher suite’in adı, her kriptografik amaç için kullandığı algoritmaları ve anahtar uzunluklarını tanımlar. Sistem yöneticilerinin bu isimleri okuyabilmesi önemlidir; çünkü bir algoritma ya da anahtar uzunluğunun zayıf olduğu ortaya çıktığında hangi suite’lerin kapatılacağını ancak böyle anlayabilirler. Standart bir isimlendirme formatı olsa da evrensel uygulanmaz (bazı yazılımlar alt çizgi yerine tire kullanır ya da “TLS”/”WITH” ifadelerini atlar). Her suite’e, bazı araçların gösterdiği benzersiz bir hex kod da atanır.

	TLS 1.2 ve Altı	TLS 1.3
İsim Standardı	TLS_[Key_Exchange]_[Authentication]_WITH_[Encryption]_[MAC]	TLS_[AEAD]_[Hash]
Örnek İsim	TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256	TLS_AES_256_GCM_SHA384
Örnek Kod	0xC0,0x2B	0x13,0x02

Yukarıdaki TLS 1.2 örneğinin açılımı: Key Exchange → ECDHE (Elliptic Curve Diffie-Hellman Ephemeral), Authentication → ECDSA (Elliptic Curve Digital Signature Algorithm), Encryption → AES 128 GCM (128-bit anahtarlı AES, Galois/Counter mode), MAC → SHA-256. TLS 1.3 örneğinde ise AEAD → AES 256 GCM, Hash → SHA-384.

Certificate’lar

Certificate Nedir?

TLS certificate’ları, müzakere sürecinin başında bağlantının bir ya da iki ucunun kimliğini doğrulamak için kullanılır. Sertifikalar doğru kullanılmazsa bir saldırgan uç noktaları taklit ederek MitM saldırısı gerçekleştirebilir; trafiği araya girip çözer, okur veya değiştirir, ardından yeniden şifreleyip hedefe iletir. Bir TLS certificate’ı, iki parçalı bir şifreleme anahtarının paylaşılabilen public kısmını içeren özel biçimli bir dosyadır. Gizli tutulması gereken private kısım ise sertifikanın temsil ettiği cihaz(lar)da saklanır. Sertifikadaki ek veriler sahibi, geçerli domain’leri, son kullanma tarihini ve diğer ayrıntıları tanımlayabilir.

Bazı iletişimlerde yalnızca bir ucun kimliği doğrulanır (örneğin bir tarayıcının bankacılık sitesine bağlanması: banka sunucusu sertifikayla, kullanıcı ise parola ve çok faktörlü kimlik doğrulama ile). Bazılarında ise -örneğin site-to-site VPN- her iki uç da birbirini sertifikayla doğrular.

Certificate İmzalama ve Güven

Bir saldırgan, herhangi bir domain için kendi anahtar ve sertifikasını üreterek uç noktaları taklit etmeye çalışabilir. Bunu önlemek için sertifikalar bir otorite tarafından kriptografik olarak imzalanmalı ve TLS implementasyonları bu imzaları doğrulamalıdır. Bunun üç yolu vardır:

İmzalama Türü	Açıklama	Kullanım Senaryosu
Public CA	Tanınmış, üçüncü taraf bir otorite, sertifikayı kendi anahtarlarıyla imzalamadan önce kurumun kimliğini doğrular.	Kamuya açık web siteleri, e-posta gibi geniş kitleye açık servisler. İnternetteki her sistem, işletim sistemleri ve tarayıcılara gömülü public CA anahtarlarıyla sertifikayı doğrulayabilir.
Private CA	Kurum, kendi ürettiği sertifikaları imzalamak için kendi ana anahtar setini oluşturur.	Tek bir kurum veya yakın çalışan kurum grubu içinde yaygın kullanım (dahili uygulamalar, VPN). Private CA sertifikası, doğrulama yapacak tüm cihazlarda güvenilir tanımlanmalıdır. Anahtar yönetimi yükü getirir.
Self-Signed	Sertifika kendi anahtarıyla imzalanır.	Yalnızca sıkı kontrollü durumlar (site-to-site VPN) veya güvenliğin önemsiz olduğu test ortamları. Güvenlik gereken yerlerde uç noktalar yalnızca bilinen-geçerli sertifikaya güvenecek şekilde yapılandırılmalıdır (bkz. Certificate Pinning).

Yanlış imza türünü kullanmak sık sık uyumluluk sorununa yol açar. Sahada, self-signed sertifikaların uygunsuz yerlerde kullanıldığına -ya da uygun yerlerde kullanılıp uç noktaların yalnızca yetkili sertifikaya güvenecek şekilde yapılandırılmadığına- sıkça rastlanır; ikinci durumda TLS fiilen etkisiz kalır. Kurumlar mümkün olduğunda public ya da private CA kullanmalı, self-signed kullanıldığında sistemleri yalnızca yetkili sertifikalara güvenecek şekilde dikkatle yapılandırmalıdır. Private CA yönetecek olgunluğa sahip olmayan kurumlar public CA tercih etmelidir.

Certificate Pinning

TLS uygulayan çoğu yazılım, varsayılan olarak sertifika imzasını önceden yüklü public CA (ve varsa private CA) sertifikalarıyla doğrular ve testi geçen her sertifikayı kabul eder. Alternatif yöntem sertifikayı pinlemektir: TLS yazılımı, belirli bir host için yalnızca belirli bir sertifikayı kabul edip diğerlerini reddeder. Certificate pinning, production ortamında self-signed sertifika kullanılırken şiddetle önerilir; çünkü self-signed sertifikalar hiçbir CA tarafından imzalanmadığından varsayılan doğrulamayı asla geçemez. Pinning, public/private CA imzalı sertifikalarda da yüksek güvenlikli uygulamalar için yararlıdır: geçerli bir CA ele geçirilse bile, o host için sahte sertifikaların kabulünü engeller.

Certificate Üretimi

Sertifikalar hem kriptografik algoritmaların bileşenlerini içerir hem de bu algoritmalarla üretilir. Zayıf algoritma veya anahtar uzunluğu, sertifikaların taklit edilmesine yol açabilir. Yayın tarihi itibarıyla ECC anahtarlar, çok daha kısa anahtar uzunluğuyla eşdeğer güvenlik sunduğu için RSA’nın önüne geçiyor: 256-bit ECC anahtar kabaca 2048-bit RSA ile eşdeğer orta düzey güvenlik sağlar; imza için tipik olarak SHA-256 kullanılır.

Certificate Süre Dolumu (Expiration)

Kurumlar sık sık süresi dolmuş sertifikalar kullanarak uyumluluk sorunu yaratır. Son kullanma tarihinin nedeni, private anahtar ele geçirilirse saldırganın geçerli bir sertifikayı sonsuza dek kullanamamasıdır. Kurumlar sertifikaları süresi dolmadan yenilemeli ve sistemleri süresi dolmuş sertifikaları reddedecek şekilde yapılandırmalıdır.

Certificate Domain’leri

Bir diğer sık hata, uç noktanın domain’i ile sertifikadaki domain’in eşleşmemesidir. Domain uyuşmazlığı çoğu zaman domain adı yerine IP adresine bağlanınca ya da bir uç noktaya birden fazla domain adı atanınca ortaya çıkar. Sertifikadaki domain “*.bakicubuk.com” gibi geniş ya da “www.bakicubuk.com” gibi dar tanımlanabilir. En iyi uygulama, private anahtar ele geçirilirse zararı sınırlamak için domain’i mümkün olan en dar biçimde tanımlamaktır.

Key Management (Anahtar Yönetimi)

Key Management Nedir?

Dünyanın en iyi şifrelemesi bile, anahtarlar yanlış üretilir veya kötü yönetim yüzünden ele geçirilirse işe yaramaz hale gelir. Key management, kriptografik anahtarların güvenli biçimde üretilmesi, saklanması ve dağıtılması sürecidir. Özel key management yazılımları ya da HSM’ler (Hardware Security Module) bu süreci güvenli biçimde otomatikleştirebilir. Derin bir inceleme için NIST SP 800-57 iyi bir kaynaktır.

Anahtar Üretimi (Key Generation)

Güçlü algoritma ve anahtar uzunluğunun yanında, anahtar üretiminde kullanılan verinin kaynağı da önemlidir. Saldırganın tahmin edemeyeceği güçlü anahtarlar için rastgelelik şarttır. Geçmişte, öngörülebilir anahtarlar üreten sözde rastgele sayı üreteçleri üzerinden şifreleme arka kapıları (backdoor) oluşturulmuş ve istismar edilmiştir. Yüksek güvenlikli uygulamalarda -özellikle private CA ana anahtarları- kriptografik olarak güvenli sözde-rastgele sayı üreteçleri (CPRNG) veya tercihen donanımsal rastgele sayı üreteçleri kullanılmalıdır.

Anahtar Saklama (Key Storage)

Bir TLS sertifikasına ait private anahtarlar korunmalıdır; private anahtarı ele geçiren saldırgan iletişimi çözebilir veya sertifikanın kapsadığı domain’deki herhangi bir sistemi taklit edebilir. Private CA anahtarları kritiktir; sahte sertifikalar üretmek için kullanılabilirler. Public CA anahtarları ise daha da kritiktir; ele geçirilmeleri internet çapında taklit sonuçları doğurur. HSM’ler burada yardımcı olur: Bir anahtarı HSM’den çıkarmak, dosyadan kopyalamaktan çok daha zordur. Anahtarı mümkün olan en az yerde saklamak ve en az sayıda kişiye erişim vermek de önerilir.

Anahtar Dağıtımı (Key Distribution)

Anahtar dağıtımı, istenmeyen anahtar saklamaya yol açabileceği için kritiktir; örneğin private anahtarı e-posta ile göndermek, anahtarın mail sunucusunda ve alıcı cihazlarda belirsiz süre saklanmasına neden olur. Benzer şekilde çıkarılabilir medyayla dağıtılan anahtarlar, medya düzgün temizlenmezse silinseler bile kurtarılabilir. Private anahtarların dağıtım sırasında ve sonrasında güvenliğini korumak için ayrıntılı prosedürler oluşturulmalı; gerekirse anahtarlar dağıtım sırasında şifrelenmelidir.

Anahtar Envanteri (Key Inventory)

Kurumlar, ürettikleri kriptografik anahtar ve sertifikaların ayrıntılarını içeren bir envanter tutmalıdır. Bu, algoritmalarda zayıflık bulunduğunda ya da bir anahtar ele geçirildiğinde ilgili anahtar ve sertifikaların hızlıca emekliye ayrılmasını sağlar. Aynı şekilde kullanılan TLS yazılımı, key management yazılımı ve HSM’lerin de envanteri tutulmalı ki ilgili zafiyetler hızla tespit edilip yamalanabilsin.

Yazılım Paketleri (Software Packages)

TLS protokolü ve algoritmaları açık standartlarda tanımlıdır ve herkes tarafından implemente edilebilir. Her yazılımda olduğu gibi burada da hatalar mümkündür; yanlış implementasyon ya da yazılıma yönelik saldırılara imkan veren kusurlar zafiyet yaratabilir. Kurumlar TLS yazılım ve kütüphanelerini etkileyen üretici güvenlik güncellemelerine karşı tetikte olmalıdır. Sık karşılaşılan senaryolar: işletim sistemlerine gömülü kütüphaneler (Windows SSPI API, Apple Network Framework); açık kaynak kütüphaneler (GnuTLS, LibreSSL, OpenSSL); ticari kütüphaneler; ve yazılım paketlerinin kendi TLS implementasyonlarını barındırması.

FIPS 140 Validation

“FIPS Encryption” olarak anılan şey aslında FIPS 140 ile doğrulanmış yazılım ya da donanıma yapılan bir atıftır. FIPS 140, kriptografik yazılım ve donanım için güvenlik gereksinimlerini belirler. Doğrulanan şey, algoritmaların yazılım/donanım implementasyonudur; algoritmalar ve TLS protokolünün kendisi zaten standartlaşmıştır. ABD federal kurumları FIPS 140 doğrulanmış ürünleri kullanmak zorundadır; hükümet adına bilgi işleyen kuruluşlar sözleşme gereği FIPS 140 doğrulanmış şifreleme kullanmak durumunda kalabilir. Doğrulanmış ürün kullanılsa bile uyumluluğu korumak için bazı yapılandırma ayarları (“FIPS 140 modu” açmak gibi) gerekebilir.

FIPS 140-2, yerini FIPS 140-3’e bırakıyor. FIPS 140-2 doğrulamaları 21 Eylül 2026‘da emekliye ayrılacak; federal gereksinimlere tabi kuruluşlar aksi belirtilene dek bunları satın almaya devam edebilir. Gelecekteki alımlarda mümkün olduğunda FIPS 140-3 doğrulanmış çözümler tercih edilmelidir.

TLS’in Regülasyon, Denetim ve Güvenlik Çerçeveleriyle İlişkisi

TLS yapılandırması havada asılı bir teknik detay değildir; birçok yasal düzenleme, sektör standardı ve güvenlik çerçevesi doğrudan ya da dolaylı olarak “aktarım halindeki verinin güçlü şifrelenmesini” şart koşar. Aşağıda, sık karşılaşılan sekiz çerçevenin TLS’e nasıl baktığını özetliyorum. Burada önemli bir ayrım var: PCI DSS, HIPAA, KVKK ve TCMB düzenlemeleri yaptırımı olan zorunluluklar; ISO 27001, NIST CSF ve CIS Controls en iyi uygulama çerçeveleri; MITRE ATT&CK ise bir çerçeve değil, zayıf TLS’in hangi saldırı tekniklerine kapı araladığını gösteren bir bilgi tabanıdır.

Çerçeve	Türü	TLS ile İlişkisi
PCI DSS	Zorunlu (sektör standardı)	Kart sahibi verisinin açık ağlarda güçlü kriptografiyle taşınması; zayıf protokol/cipher yasak
HIPAA	Zorunlu (ABD federal)	Korunan sağlık bilgisinin (ePHI) aktarımda şifrelenmesi (transmission security)
ISO 27001	Best-practice / sertifikasyon	Kriptografi ve ağ güvenliği kontrolleri (Annex A) kapsamında TLS
KVKK (No. 6698)	Zorunlu (TR yasa)	Kişisel verinin aktarımında uygun teknik tedbir olarak şifreleme
TCMB	Zorunlu (TR regülasyon)	Ödeme/finans sistemlerinde güçlü kriptografi ve güvenli iletişim şartı
NIST CSF	Best-practice / çerçeve	“Protect” fonksiyonu altında veri güvenliği ve aktarım koruması
CIS Controls	Best-practice / çerçeve	Veri koruma ve güvenli konfigürasyon kontrollerinde TLS
MITRE ATT&CK	Bilgi tabanı (framework değil)	Zayıf TLS’in ilişkili olduğu MitM/AiTM tekniklerinin haritalanması

PCI DSS (Payment Card Industry Data Security Standard)

Kart ödeme sistemleriyle çalışan herkesi bağlayan bu standart, kart sahibi verisinin açık/genel ağlar üzerinden taşınırken güçlü kriptografi ile korunmasını açıkça şart koşar. Zayıf ya da eskimiş protokol sürümlerinin (SSL ve erken TLS) kullanımı doğrudan uyumsuzluk sebebidir; nitekim standart, bu sürümlerden güvenli sürümlere geçişi yıllar önce zorunlu kılmıştır. Denetimde en sık düşülen noktalar: eski protokolün açık bırakılması, zayıf cipher suite’ler ve sertifika/anahtar yönetimindeki eksiklerdir. Yani bu yazıdaki adımların neredeyse tamamı doğrudan PCI DSS kapsamına girer.

HIPAA (Health Insurance Portability and Accountability Act)

ABD sağlık sektörü verisini (özellikle elektronik korunan sağlık bilgisi, ePHI) düzenleyen HIPAA’nın Security Rule bölümü, verinin aktarım sırasında yetkisiz erişime karşı korunmasını (transmission security) ister. Yasa belirli bir algoritma dayatmaz ama pratikte bu gereksinim, ağ üzerinden taşınan ePHI için güncel TLS yapılandırmasıyla karşılanır. Türkiye’den ABD’li sağlık kuruluşlarına hizmet veren veya onların verisini işleyen şirketler için de bağlayıcı hale gelebilir.

ISO 27001 (Bilgi Güvenliği Yönetim Sistemi – BGYS)

ISO 27001, bir Bilgi Güvenliği Yönetim Sistemi kurmanın çerçevesini çizer ve Annex A kontrol setinde kriptografi ile ağ güvenliğine yer verir. TLS burada, “aktarım halindeki bilginin korunması” ve “kriptografik kontrollerin uygun kullanımı” gibi kontrollerin somut uygulama aracıdır. Sertifikasyon denetiminde, kurumun yalnızca TLS kullanması değil; hangi sürüm ve cipher’lara izin verdiğini, sertifika ve anahtarları nasıl yönettiğini belgelenmiş bir politika ile göstermesi beklenir.

KVKK (Kişisel Verilerin Korunması Kanunu – No. 6698)

KVKK, kişisel verinin işlenmesinde ve aktarılmasında “uygun güvenlik düzeyini sağlamaya yönelik teknik ve idari tedbirlerin” alınmasını zorunlu tutar. Kurul rehberlerinde, verinin ağ üzerinden aktarımında şifreleme açıkça tavsiye edilen bir tedbirdir. Web siteleri, API’ler, e-posta ve iç sistemler arası trafikte güncel TLS kullanmak, bu “uygun teknik tedbir” beklentisinin en temel karşılığıdır. Zayıf ya da yanlış yapılandırılmış TLS, bir veri ihlali durumunda “gerekli tedbirin alınmadığı” değerlendirmesine ve idari yaptırıma zemin hazırlayabilir.

Türkiye Cumhuriyet Merkez Bankası (TCMB)

TCMB’nin ödeme ve elektronik para kuruluşlarına yönelik düzenlemeleri ile bilgi sistemleri denetim çerçevesi, finansal veri ve ödeme trafiğinin güçlü kriptografi ile korunmasını ve güvenli iletişim kanallarının kullanılmasını şart koşar. Ödeme hizmeti sağlayıcıları için TLS yapılandırması, düzenleyici denetimin doğrudan incelediği kalemlerden biridir; eski protokol veya zayıf cipher kullanımı bulgu olarak raporlanır. Fintech tarafında çalışan kurumlar için bu bölüm, yazının en kritik ayağıdır.

NIST Cybersecurity Framework (CSF)

NIST CSF, güvenlik faaliyetlerini Identify, Protect, Detect, Respond, Recover fonksiyonları etrafında düzenler. TLS özellikle Protect fonksiyonu altındaki veri güvenliği (aktarım halindeki verinin korunması) kategorisine denk gelir. CSF bir zorunluluk değil, kurumun güvenlik olgunluğunu ölçüp iyileştirmesi için bir yol haritasıdır; ancak birçok sözleşme ve iç politika onu referans alır.

CIS Controls

CIS Controls, önceliklendirilmiş ve uygulanabilir güvenlik kontrolleri sunar. Veri koruma ve güvenli konfigürasyon kontrolleri, aktarım halindeki hassas verinin şifrelenmesini ve sistemlerin güvenli varsayılanlarla yapılandırılmasını içerir. Bu yazıdaki “yalnızca güncel TLS sürümlerini aç, zayıf cipher’ları kapat, sertifikaları doğru yönet” tavsiyeleri, CIS’in güvenli konfigürasyon mantığının birebir uygulamasıdır.

MITRE ATT&CK

ATT&CK bir uyumluluk çerçevesi değil, gerçek saldırgan davranışlarını taktik ve tekniklere göre sınıflayan bir bilgi tabanıdır. TLS’i buraya bağlamak, “yanlış yapılandırma neye yarar?” sorusunu saldırgan gözünden yanıtlar. Zayıf ya da düşürülebilir (downgrade edilebilir) TLS, ortadaki adam / Adversary-in-the-Middle (AiTM) tekniklerini mümkün kılar; sahte veya uygunsuz sertifikalar kimlik taklidine, ele geçirilmiş anahtarlar ise şifreli trafiğin çözülmesine kapı aralar. Yani bu yazıdaki her sağlamlaştırma adımı, ATT&CK’teki ilgili tekniklerin önünü kapatan bir savunma olarak düşünülebilir.

Genel Görünüm

TLS çoğu uyumluluk denetiminde basit bir “kontrol kutusu” gibi görünse de, doğru yapılandırılması sanıldığından çok daha fazla ayrıntı barındırıyor. Özetle atılması gereken adımlar net: yalnızca TLS 1.2 ve 1.3’ü açık tutun, zayıf cipher suite’leri IANA listesine göre kapatın, güçlü anahtar ve imzalarla üretilmiş, doğru domain’e sahip ve süresi dolmamış sertifikalar kullanın, anahtarlarınızı disiplinli biçimde yönetin ve gerektiğinde FIPS 140 doğrulanmış yazılımı doğru yapılandırın. Bu temeli sağlam kuran bir kurum, neredeyse tüm çerçevelerin şifreleme gereksinimlerini rahatlıkla karşılar.