Kurumsal Web Sitelerinde SSL Sertifikası, HTTPS ve TLS 1.3 Protokol Güvenliği

Kurumsal bir web sitesi; iletişim formlarından üyelik ekranlarına, bayi portallarından üçüncü taraf entegrasyonlarına kadar farklı noktalarda veri aktarır. Bu trafiğin korunması, yalnızca tarayıcıdaki kilit simgesini görünür hâle getirmekten ibaret değildir. SSL sertifikası olarak anılan dijital sertifika, HTTPS kullanımı ve güncel TLS yapılandırması birlikte ele alınmalıdır. Sertifikanın doğru alan adlarını kapsaması, özel anahtarın korunması, HTTP isteklerinin güvenli biçimde yönlendirilmesi, eski protokollerin sınırlandırılması ve yenileme sürecinin izlenmesi aynı güvenlik zincirinin parçalarıdır.

Bu nedenle kurumsal web sitesi projelerinde güvenlik, yayın gününde tamamlanan tek seferlik bir görev değildir. İhtiyaç analiziyle başlayan; geliştirme, entegrasyon, test, izleme ve bakım boyunca devam eden teknik bir süreçtir. Amaç yalnızca bağlantıyı şifrelemek değil, kullanıcıyı doğru sunucuya ulaştıran, veri bütünlüğünü koruyan ve ekip tarafından sürdürülebilen bir altyapı kurmaktır.

SSL sertifikası, HTTPS ve TLS ne anlama gelir?

Günlük kullanımda “SSL sertifikası” denilse de modern web bağlantılarında kullanılan protokol TLS’dir. SSL, TLS’in tarihsel öncülüdür; sektör dilinde yerleşmiş olduğu için sertifikalar hâlâ bu adla anılabilir. Dijital sertifika, alan adı ile sunucunun açık anahtarı arasındaki bağı güvenilir bir sertifika otoritesinin imzasıyla doğrular. Tarayıcı sertifikanın geçerlilik süresini, alan adı eşleşmesini ve güven zincirini denetler.

HTTPS ise HTTP iletişiminin TLS üzerinden gerçekleştirilmesidir. TLS; istemci ile sunucu arasındaki veriyi şifrelemeyi, aktarım sırasında değiştirilip değiştirilmediğini denetlemeyi ve istemcinin bağlandığı sunucunun kimliğini doğrulamayı amaçlar. RFC 8446’ya göre TLS 1.3, istemci-sunucu iletişimini dinleme, kurcalama ve mesaj sahteciliğine karşı korumak üzere tasarlanmıştır. Protokolün teknik kapsamı IETF tarafından yayımlanan TLS 1.3 standardında ayrıntılı biçimde açıklanır.

Bu üç kavram farklı görevler üstlenir: sertifika kimlik doğrulamasına temel sağlar, TLS güvenli iletişim kanalını kurar, HTTPS ise web trafiğini bu kanal üzerinden taşır. Bunlardan birinin bulunması diğer tüm güvenlik kontrollerinin doğru olduğu anlamına gelmez.

TLS 1.3 kurumsal web sitelerine ne kazandırır?

TLS 1.3, eski ve zayıf kabul edilen şifreleme seçeneklerini protokolün temel tasarımından çıkarır. Kalan simetrik şifreleme seçenekleri, şifreleme ile bütünlük doğrulamasını birlikte sağlayan AEAD algoritmalarına dayanır. Statik RSA ve statik Diffie-Hellman anahtar değişimi kaldırılmış; açık anahtarlı anahtar değişimlerinde ileriye dönük gizlilik sağlayan yöntemler benimsenmiştir. Böylece uzun vadeli özel anahtar ileride ele geçirilse bile daha önce kaydedilmiş oturumların çözülmesine karşı daha güçlü bir yapı hedeflenir.

Protokol ayrıca bağlantı kurma sürecini sadeleştirerek uygun koşullarda daha az gidiş gelişle güvenli oturum oluşturabilir. Bu özellik, özellikle farklı coğrafyalardaki kullanıcılara hizmet veren kurumsal sitelerde gecikmenin azaltılmasına katkı sağlayabilir. Ancak performans sonucu yalnızca TLS sürümüne bağlı değildir; sunucu konumu, CDN, önbellek, sayfa ağırlığı ve uygulama mimarisi de birlikte değerlendirilmelidir.

TLS 1.3 içindeki 0-RTT özelliği, önceki bir oturumdan dönen istemcinin bazı verileri daha erken göndermesine imkân tanır; fakat RFC 8446 bu verilerin yeniden oynatma riskine sahip olduğunu belirtir. Bu nedenle ödeme, form gönderimi, oturum açma veya kayıt değiştirme gibi tekrarlandığında sonuç doğuran işlemlerde 0-RTT varsayılan bir hızlandırma seçeneği olarak açılmamalıdır. Kullanım kararı, uygulama katmanındaki tekrar önleme kontrolleriyle birlikte verilmelidir.

Doğru sertifika türü nasıl seçilir?

Sertifika seçiminde ilk soru, kaç alan adı ve alt alan adının korunacağıdır. Tek alan adlı sertifika belirli bir alan adını, çok alan adlı sertifika birden fazla adı, wildcard sertifika ise belirli bir seviyedeki alt alan adlarını kapsayabilir. Wildcard kullanımı operasyonel kolaylık sağlasa da aynı özel anahtarın çok sayıda sistemde paylaşılması güvenlik etkisini büyütebilir. Sertifika kapsamı, sistem envanteri ve anahtar yönetimiyle birlikte belirlenmelidir.

DV, OV ve EV sınıfları sertifika otoritesinin başvuru sahibini hangi kapsamda doğruladığını ifade eder. Bunlar, kullanılan şifrelemenin otomatik olarak daha güçlü veya web uygulamasının daha güvenli olduğu anlamına gelmez. Kurumsal seçimde marka doğrulama beklentisi, tedarik politikaları, otomasyon imkânı ve operasyon maliyeti birlikte değerlendirilmelidir.

Seçim sırasında kontrol edilmesi gerekenler

• Sertifika, kök alan adı ile kullanılan tüm alt alan adlarını kapsamalıdır.
• Özel anahtar güvenli ortamda üretilmeli, erişimi sınırlandırılmalı ve geliştirici cihazlarında dolaştırılmamalıdır.
• Sunucu, ara sertifikaları içeren doğru sertifika zincirini sunmalıdır.
• Yenileme otomatikleştirilmeli; başarısızlıklar için izleme, bildirim ve sorumlu ekip tanımlanmalıdır.
• İptal, anahtar değişimi ve olağanüstü durum adımları önceden belgelenmelidir.

ACME gibi otomasyon mekanizmaları alan adı kontrolü doğrulaması, sertifika talebi, yenileme ve iptal işlemlerinin yönetilmesini kolaylaştırır. Sürecin genel çalışma biçimi Let’s Encrypt’in sertifika otomasyonu açıklamasında görülebilir. Otomasyon kurulsa bile sertifikanın süresi, alan adı kapsamı ve yenileme işinin sonucu bağımsız olarak izlenmelidir.

HTTPS geçişi yalnızca sertifika kurmak değildir

Sertifika sunucuya yüklendikten sonra bütün HTTP adresleri karşılık gelen HTTPS adresine kalıcı yönlendirmeyle taşınmalıdır. Yönlendirme zincirleri azaltılmalı; alan adının www kullanılan ve kullanılmayan sürümleri için tek bir standart adres belirlenmelidir. Canonical etiketleri, XML site haritası, robots yönergeleri, analitik araçları, reklam hedefleri ve harici servislerde kayıtlı geri dönüş adresleri de HTTPS sürümüne geçirilmelidir.

Sayfanın kendisi HTTPS üzerinden açılırken JavaScript, CSS, font, görsel veya iframe gibi alt kaynakların HTTP üzerinden çağrılması karma içerik oluşturur. Tarayıcılar bu kaynakları yükseltebilir ya da engelleyebilir; kritik bir betiğin engellenmesi formu veya menüyü çalışmaz hâle getirebilir. Karma içerik riskleri ile HSTS’nin işlevi, MDN’nin TLS güvenliği rehberinde açıklanır. Yayın öncesinde yalnızca görünen sayfalar değil, kod içindeki sabit URL’ler, CMS içerikleri ve üçüncü taraf bileşenleri de taranmalıdır.

HSTS kontrollü biçimde etkinleştirilmelidir

Strict-Transport-Security başlığı, tarayıcıya belirli bir süre boyunca alan adına yalnızca HTTPS ile bağlanmasını bildirir. Bu, sonraki ziyaretlerde HTTP’ye düşürme girişimlerine karşı koruma sağlar. Ancak includeSubDomains veya preload seçenekleri hazırlıksız etkinleştirilirse HTTPS desteği bulunmayan alt alan adlarına erişim kesilebilir. Önce tüm alt alan adları envantere alınmalı, kısa bir süreyle kontrollü deneme yapılmalı ve geri dönüş planı doğrulanmalıdır.

Formlar ve entegrasyonlar uçtan uca korunmalıdır

HTTPS, tarayıcı ile bağlantının sonlandığı sunucu arasındaki aktarımı korur; verinin uygulama içinde nasıl işlendiğini garanti etmez. İletişim formunun girdileri sunucuda doğrulanmalı, gereksiz kişisel veri toplanmamalı, yetkilendirme uygulanmalı ve hassas bilgiler loglara açık biçimde yazılmamalıdır. CSRF, XSS, SQL enjeksiyonu, kötü amaçlı dosya yükleme ve bot trafiği için ayrıca uygulama katmanı kontrolleri gerekir.

CRM, ERP, e-posta, ödeme veya pazarlama platformlarına aktarılan form verileri de güvenli bağlantı üzerinden iletilmelidir. API sertifikası doğrulanmalı, erişim anahtarları kod deposunda tutulmamalı, minimum yetki uygulanmalı ve başarısız aktarım kayıtları hassas veri sızdırmadan izlenmelidir. Formdan satış sistemine uzanan veri hattını planlarken B2B sipariş takip portalı yaklaşımındaki durum, belge, yetki ve görünürlük ilkeleri de benzer kurumsal entegrasyonlar için yol gösterici olabilir.

Yayın öncesi HTTPS ve TLS kontrol listesi

• Sertifikanın alan adı kapsamı, geçerlilik tarihi ve güven zinciri denetlenmelidir.
• TLS 1.3 etkinleştirilmeli; gerekli uyumluluk analizi sonrasında TLS 1.2 desteklenebilir, eski sürümler kapatılmalıdır.
• HTTP’den HTTPS’ye yönlendirmeler tek adımda ve sorgu parametrelerini koruyarak çalışmalıdır.
• Karma içerik, güvensiz form hedefleri ve kod içine yazılmış HTTP bağlantıları taranmalıdır.
• HSTS, güvenlik başlıkları, çerezlerin Secure, HttpOnly ve uygun SameSite nitelikleri kontrol edilmelidir.
• Masaüstü ve mobil tarayıcılarda sayfalar, formlar, dosya yüklemeleri ve entegrasyonlar test edilmelidir.
• Sertifika yenilemesi prova edilmeli; izleme, uyarı ve sorumluluk matrisi tanımlanmalıdır.

Test yalnızca ana sayfada yapılmamalıdır. Eski kampanya adresleri, dil sürümleri, yönetim paneli, API uçları, alt alan adları ve CDN üzerinden sunulan varlıklar kapsam içine alınmalıdır. Yük dengeleyici veya CDN’de sonlandırılan TLS bağlantısının arka uçta nasıl devam ettiği de doğrulanmalıdır. Dışarıdan HTTPS görünen bir sistemin iç ağdaki aktarımı kontrolsüz bırakılmamalıdır.

Sertifika yaşam döngüsü ve sürekli bakım

Sertifikanın süresinin dolması, doğru çalışan bir web sitesini kullanıcılar açısından erişilemez veya güvensiz gösterebilir. Bu nedenle yenileme, kişinin takvim hatırlatıcısına bağlı olmamalıdır. Otomatik yenileme işi, süre sonu izleme servisi ve farklı iletişim kanallarından uyarı birlikte kullanılmalıdır. Sertifika yenilendiğinde ilgili servislerin yeniden yüklenmesi ve yeni sertifikanın gerçekten sunulması da kontrol edilmelidir.

Alan adı, DNS sağlayıcısı, CDN, barındırma ve sertifika otoritesi hesaplarının sahipliği kurumsal olarak belgelenmelidir. Çalışan değişikliği veya tedarikçi geçişi sırasında erişim kaybı yaşamamak için rol bazlı yetki, çok faktörlü kimlik doğrulama ve kurtarma prosedürleri kurulmalıdır. Envanterde kullanılmayan alt alan adları ve eski sertifikalar da kaldırılmalıdır.

SSL tek başına web sitesi güvenliği anlamına gelmez

Geçerli bir sertifika, sitenin zararlı kod içermediğini, yazılım açıklarının kapatıldığını veya veri işleme süreçlerinin mevzuata uygun olduğunu kanıtlamaz. Saldırganlar da kendi alan adları için geçerli sertifika alabilir. Bu nedenle kullanıcı güveni yalnızca kilit simgesine bağlanmamalı; güvenli yazılım geliştirme, güncelleme yönetimi, erişim kontrolü, yedekleme, kayıt izleme ve olay müdahalesiyle desteklenmelidir.

Kurumsal web projesinde güvenlik kararları bilgi mimarisi ve arayüz kadar erken verilmelidir. Hangi formların veri toplayacağı, hangi sistemlerle entegrasyon kurulacağı, TLS’in nerede sonlanacağı ve bakım sorumluluğunun kimde olacağı ihtiyaç analizinde belirlenirse sonradan yapılacak riskli müdahaleler azalır. Kumsal Ajans’ın web ve mobil yazılım yaklaşımı; özel geliştirme, entegrasyon, performans ve yönetilebilirliği aynı proje bağlamında ele alır.

Güvenli ve sürdürülebilir web altyapısı nasıl planlanır?

Sağlam bir yapı; doğru sertifika kapsamını, TLS 1.3 desteğini, güvenli yönlendirmeleri, karma içerik temizliğini, korunan formları ve otomatik yenilemeyi tek plan altında birleştirir. Teknik gereksinimler farklı tarayıcı ve cihaz testleriyle doğrulanmalı; alan adı, DNS ve yayın süreçleri kayıt altına alınmalıdır. Böylece güvenlik, yalnızca BT ekibinin müdahale ettiği görünmez bir ayar olmaktan çıkarak marka itibarı ve kullanıcı deneyiminin ölçülebilir bir bileşenine dönüşür.

Kumsal Ajans, İstanbul merkezli dijital ajans yaklaşımıyla kurumsal web tasarım ve projeye özel web yazılım çalışmalarını marka hedefleri, kullanıcı deneyimi, entegrasyonlar, performans ve veri güvenliğiyle birlikte planlar. Kurumsal web sitenizin HTTPS, sertifika ve TLS yapılandırmasını proje kapsamında değerlendirmek; güvenli, hızlı ve yönetilebilir bir web altyapısı planlamak için Kumsal Ajans ile iletişime geçin.