B2B Kurumsal Siteler İçin SSL ve Güven Mimarisi

B2B Kurumsal Sitelerde Güven Mimarisi Neden Ayrı Bir Lig?

B2B tarafta çalışan kurumsal ekiplerle konuştuğumuzda, satış süreçlerinin önemli bir kısmının aslında güven inşa etmeye harcandığını görüyoruz. Satın alma departmanları, bilgi güvenliği ekipleri ve hukuk birimleri; teknik teklif kadar, altyapı güvenliğini ve uyumluluğu da masaya yatırıyor. Özellikle müşteri portalları, bayi panelleri, tedarikçi platformları ve doküman paylaşım sistemleri gibi B2B kurumsal siteler için “HTTPS var mı?” sorusu artık başlangıç noktası bile değil. Beklenti çok daha yüksek: modern TLS, HSTS preload, CAA kayıtları, güven damgaları, PCI/KVKK uyumu ve ölçülebilir süreçler.

DCHost olarak B2B müşterilerimizde gördüğümüz ortak nokta şu: Güven mimarisi doğru kurulduğunda, güvenlik denetimleri (security assessment), tedarikçi onay süreçleri ve regülasyon kontrolleri çok daha hızlı geçiliyor. Bu yazıda, bir B2B kurumsal sitenin uçtan uca SSL ve güven mimarisi nasıl tasarlanmalı sorusunu ele alacağız. Özellikle üç kritik bileşene odaklanacağız: HSTS preload ile tarayıcı düzeyinde zorunlu HTTPS, CAA DNS kayıtları ile sertifika yetkilendirme kontrolü ve güven damgaları ile son kullanıcı tarafında algılanan güvenin artırılması. Amacımız, teorik bir güvenlik listesi değil; gerçek dünyada uygulanabilir, denetlenebilir ve sürdürülebilir bir yol haritası sunmak.

SSL/TLS Temelleri: B2B Kurumsal Standart Nasıl Olmalı?

HSTS preload ve CAA gibi ileri seviye konulara geçmeden önce, B2B kurumsal bir sitenin SSL/TLS tarafında sağlam bir zemine oturması gerekiyor. Çünkü yanlış kurgulanmış bir temel, üzerine eklediğiniz gelişmiş güvenlik önlemlerini de anlamsız hale getirebilir.

DV, OV, EV Sertifika Seçimi: Hangi Seviyede Başlamalısınız?

Teknik olarak tümü HTTPS sağlar; ancak B2B güven algısı açısından DV, OV ve EV SSL sertifikaları arasında fark büyüktür:

• DV (Domain Validation): Sadece alan adının kontrol edildiği en temel seviye. Bloglar ve basit siteler için yeterli olabilir, ama B2B müşteri portalları için genellikle zayıf algılanır.
• OV (Organization Validation): Alan adı yanında kurum bilgileri doğrulanır. B2B kurumsal siteler için çoğu zaman asgari kabul edilebilir standart budur.
• EV (Extended Validation): Daha detaylı kurumsal doğrulama, sıkı dokümantasyon. Bazı sektörlerde (finans, sağlık, kamu ihaleleri) güçlü güven sinyali olarak istenir.

Detaylı karşılaştırma için DV, OV ve EV SSL sertifikaları arasındaki farkları anlattığımız rehbere göz atabilirsiniz. B2B tarafta genellikle en az OV, yüksek regülasyonlu sektörlerde ise EV tercih etmenizi öneriyoruz.

TLS Sürümleri ve Şifre Takımları: Eskiyi Kapatmadan İleri Gidemeyiz

B2B kurumsal sitenizde TLS 1.0 ve TLS 1.1 desteğinin artık tamamen kapatılmış olması gerekiyor. Standart hedef:

• Zorunlu: TLS 1.2
• Önerilen: TLS 1.3 etkin, mümkün olduğunca tercih edilir
• Kapatılacak: SSLv3, TLS 1.0, TLS 1.1

TLS 1.3 ile daha hızlı el sıkışma, daha modern şifreler ve sade bir protokol seti elde ediyorsunuz. Kurumsal altyapınızda Nginx veya Apache kullanıyorsanız, TLS 1.3, OCSP stapling ve ileri gizlilik (PFS) ayarlarını anlattığımız rehberde pratik konfigürasyon örnekleri bulabilirsiniz.

Şifre takımı (cipher suite) tarafında da modern ve güvenli algoritmaları seçmeli, RC4, 3DES, zayıf Diffie-Hellman parametreleri gibi eski yaklaşımları devre dışı bırakmalısınız. Kurumsal güvenlik politikalarınız (örneğin kurum içi bilgi güvenliği standardınız) varsa, bu listeleri onlarla hizalamak önemlidir.

OCSP Stapling ve Sertifika Zinciri

B2B kullanıcılarınızın çoğu kurumsal ağlardan, sıkı proxy ve güvenlik cihazları üzerinden sisteme erişir. Bu ortamlarda sertifika zinciri ve OCSP stapling kritik hale gelir:

• Doğru intermediate sertifikaları sunmazsanız, bazı eski kurumsal istemcilerde “untrusted” uyarıları görebilirsiniz.
• OCSP stapling etkin değilse, tarayıcı her seferinde CA ile konuşacağı için gecikme artar ve bazı ağlarda doğrulama sorunları yaşanabilir.

Kurumsal kullanıcı tarafında tek bir kırmızı kilit, tüm güven algısını yerle bir eder. Bu yüzden HSTS preload ve CAA’ya geçmeden önce, sertifika zinciri ve OCSP tarafını netleştirmeniz şart.

HSTS ve HSTS Preload: Tarayıcıya Her Zaman HTTPS Dedirtmek

HSTS (HTTP Strict Transport Security), tarayıcıya “Bu alan adına sadece HTTPS üzerinden bağlan” demenin standart yoludur. Özellikle B2B portallarda, ilk isteğin dahi HTTP üzerinden gitmemesi, downgrade ve cookie çalma saldırılarını önlemek için çok kritik.

HSTS Nedir ve Nasıl Çalışır?

HSTS, tarayıcıya gönderilen bir HTTP başlığıdır. Temel örnek:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Bu başlıkla tarayıcıya şunları söylersiniz:

• max-age=31536000: 1 yıl boyunca bu alan adını sadece HTTPS üzerinden çağır.
• includeSubDomains: Tüm alt alan adları için de aynı kural geçerli.

Bir kez bu başlığı alan tarayıcı, kullanıcı manuel olarak “http://” yazsa bile isteği otomatik olarak HTTPS’e yükseltir. Bu, özellikle ortadaki adam (MITM) ve protokol düşürme saldırılarına karşı etkili bir kalkan sağlar.

HSTS dahil tüm HTTP güvenlik başlıklarını bir arada görmek isterseniz, HTTP güvenlik başlıkları rehberimizi mutlaka okumanızı öneririz.

HSTS Preload Nedir? Standart HSTS’ten Farkı Ne?

HSTS preload, büyük tarayıcı üreticilerinin (Chrome, Firefox, Edge, Safari) tuttuğu merkezi bir listedir. Bu listeye alan adınızı eklediğinizde, tarayıcılar hiçbir zaman HTTP denemesi yapmaz; kullanıcı ilk defa sitenize girse bile doğrudan HTTPS üzerinden bağlanır.

Yani:

• HSTS: İlk istekte HSTS başlığını görmesi gerekir.
• HSTS preload: Tarayıcı zaten sizin alan adınızı “sadece HTTPS” olarak biliyordur.

Özellikle B2B kurumsal sitelerde, ilk temasın dahi HTTPS olması güven politikaları ve bazı sızma testi (penetration test) raporları açısından bir gereklilik haline gelmiş durumda.

HSTS Preload Şartları ve Dikkat Edilmesi Gerekenler

Alan adınızı HSTS preload listesine eklemek geri dönüşü zor bir adımdır. Tarayıcılar, listeden çıkma talebinizi dağıtana kadar kullanıcılar sadece HTTPS üzerinden bağlanır. Bu yüzden şu şartlara dikkat etmelisiniz:

• Doğru başlık:

  Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• Tüm alt alan adları: includeSubDomains zorunludur; api.example.com, old.example.com gibi tüm subdomain’lerin HTTPS üzerinden sorunsuz çalıştığından emin olmalısınız.
• Kalıcı HTTPS yönlendirmesi: http:// istekleri, alan adınızın tek bir kanonik HTTPS adresine 301 ile yönlenmelidir.
• Geçerli sertifika: Tüm alan ve alt alanlarda geçerli, süreleri yakından takip edilen SSL sertifikaları olmalı.

Topoloji tarafında da önemli bir kararınız var: www mi çıplak alan adı mı kanonik olacak? Bu konu doğrudan HSTS preload planınızı etkiliyor. Eğer bu tercihi henüz netleştirmediyseniz, canonical domain ve HSTS için doğru ayarları anlattığımız yazıya mutlaka göz atın.

HSTS Preload İçin Güvenli Geçiş Stratejisi

B2B kurumsal ortamda kimse “bir header ekledik, bakalım ne olacak” demek istemez. Daha kontrollü bir yol izleyebilirsiniz:

1. Önce canlı sitede HSTS (preload’suz) başlığı ekleyin ve 1-3 ay gözlemleyin.
2. Alt alan adlarınızın tamamını tarayıp, HTTP üzerinden çalışan ya da eski sertifikaya sahip servisleri temizleyin.
3. Test alan adlarında (ör. test.example.com) preload deneyip olası sorunları görün.
4. Tüm ekipler (BT, yazılım, güvenlik, iş birimleri) onay verdiğinde preload parametresini ekleyin ve tarayıcıların preload listesine başvuru yapın.

Bu şekilde ilerlediğinizde, hem güvenlik denetimlerinde güçlü bir artı puan kazanır, hem de “geri dönüşü zor” bir kararı kontrollü şekilde yönetmiş olursunuz.

CAA Kayıtları: Sertifika Yetkilendirmesini DNS Üzerinden Yönetmek

SSL tarafında bir diğer kritik katman da CAA (Certification Authority Authorization) kayıtlarıdır. CAA, DNS seviyesinde “Bu alan adı için hangi sertifika otoriteleri sertifika verebilir?” sorusunun cevabıdır.

CAA Neden Önemli?

Teorik olarak, herhangi bir tanınmış sertifika otoritesi (CA), alan adınız adına sertifika üretebilir. Bir yanlış doğrulama, sosyal mühendislik ya da proses hatası ile size ait bir alan adına yetkisiz sertifika basılabilir. Bu da MITM saldırıları veya trafik gözetleme riskini gündeme getirir.

CAA ile şunu söylersiniz:

• “Bu alan adı için sadece şu CA’lar sertifika verebilir.”
• İhlal olursa, CA raporlamak zorundadır (iodef parametresi).

Örneğin:

example.com.  IN CAA 0 issue "ca1.example.net"
example.com.  IN CAA 0 issuewild "ca1.example.net"
example.com.  IN CAA 0 iodef "mailto:[email protected]"

Bu kayıtlarla example.com ve wildcard türevleri (*.example.com) için sadece belirttiğiniz CA’dan sertifika alınmasını zorunlu kılarsınız.

Alt Alan Adları ve Çoklu CA Stratejisi

B2B kurumsal yapılarda genelde şu senaryoları görüyoruz:

• Genel site için kurumsal bir OV/EV CA,
• Geliştirme ve test ortamları için daha esnek bir CA,
• Özel subdomain’ler (ör. partner.example.com) için farklı güven politikaları.

CAA kayıtlarını doğru tasarlamadığınızda, bu çoklu yapı sizi zorlayabilir. DNS hiyerarşisi açısından, alt alan adları kendi CAA kayıtlarıyla ana alanın kurallarını geçersiz kılabilir. Bu özelliği doğru kullanarak, örneğin:

example.com.        IN CAA 0 issue "kurumsal-ca.example.net"
example.com.        IN CAA 0 iodef "mailto:[email protected]"

dev.example.com.    IN CAA 0 issue "dev-ca.example.net"

şeklinde bir politika kurabilirsiniz. Böylece üretim ve geliştirme ortamlarını net şekilde ayırmış olursunuz.

Bu konuya daha derin inmek isterseniz, CAA kayıtlarını derinlemesine ele aldığımız yazımızda senaryo bazlı örnekler ve çoklu-CA stratejileri bulabilirsiniz.

CAA ve DNS Operasyonları: B2B’de Yapılmaması Gereken Hatalar

CAA tamamen DNS üzerinde çalıştığı için, B2B ortamlarda sık gördüğümüz bazı hatalar kritik etkilere yol açabiliyor:

• DNS taşımasında CAA unutmak: Domain’i veya DNS sağlayıcısını taşırken A/MX kayıtları taşınıyor, CAA atlanıyor; yeni sertifika yenilemelerinde beklenmedik hatalar görülüyor.
• Wildcard CAA yokluğu: issuewild tanımı yapılmadığı için wildcard sertifika talepleri reddediliyor.
• Yanlış CA ismi: CA’nın tam etki alanı ismi (FQDN) yanlış yazılıyor, ACME otomasyon süreçleri kırılıyor.

DCHost tarafında, B2B müşterilerimiz için domain, DNS ve SSL süreçlerini planlarken, CAA kayıtlarını mutlaka standart DNS kayıt kontrol listemizin bir parçası olarak ele alıyoruz. Böylece ileride otomasyon ya da sertifika yenileme sırasında sürprizlerle karşılaşmıyorsunuz.

Güven Damgaları ve Sertifika Rozetleri: Algılanan Güveni Nasıl Yükseltirsiniz?

Teknik olarak ne kadar güçlü olursanız olun, ziyaretçi tarafında bunu görsel ve metinsel sinyallerle desteklemezseniz, algılanan güven düşük kalabilir. Özellikle B2B’de, sitede form dolduran kişi çoğu zaman şirket adına hareket eden bir çalışandır ve ekran görüntülerini güvenlik ekibine iletmek zorunda kalabilir. İşte güven damgaları (trust seals) burada devreye giriyor.

Hangi Güven Damgaları B2B İçin Anlamlı?

Kurumsal sitelerde genellikle şu tip damgalar ve rozetler kullanılıyor:

• SSL/Güvenli bağlantı rozetleri: Kullanılan sertifikanın türünü (OV/EV), CA’yı ve bağlantının şifrelendiğini vurgulayan görseller.
• PCI DSS uyum rozetleri: Online ödeme kabul eden B2B portallarda, özellikle sanal POS ve kart saklama senaryolarında önem kazanır.
• ISO 27001 / SOC 2 gibi bilgi güvenliği sertifikaları: Daha üst seviye güvenlik olgunluğunu göstermek için.
• Penetrasyon testi / güvenlik taraması rozetleri: Düzenli olarak bağımsız güvenlik taramasından geçtiğinizi kanıtlayan damgalar.

Eğer e-ticaret de yapıyorsanız veya kart saklama/işleme süreçleriniz varsa, PCI DSS uyumlu e-ticaret hosting rehberimizde güven damgalarının uyumluluk dokümantasyonu ile nasıl ilişkilendirilebileceğini detaylı şekilde anlattık.

Güven Damgalarını Sayfaya Nereye Koymalı?

B2B sitelerde güven damgalarını gelişi güzel her yere serpiştirmek yerine, kritik karar noktalarına yerleştirmek daha etkilidir:

• Giriş ve kayıt formlarında, form alanlarının hemen yanında veya altında,
• Doküman yükleme, teklif talebi, sözleşme onayı gibi adımların yanında,
• Kurumsal “Güvenlik ve Uyumluluk” sayfasında toplu halde, teknik açıklamalarla birlikte.

Bu sayfada, kullandığınız SSL seviyesi, HSTS/HSTS preload ve CAA stratejiniz, yedekleme ve felaket kurtarma politikalarınız, KVKK/GDPR yaklaşımınız gibi detayları şeffaf bir dille anlatarak, potansiyel müşterilerinizin hukuk ve bilgi güvenliği ekiplerinin sorularını baştan yanıtlayabilirsiniz.

AB Testi ve Dönüşüm Etkisi

Birçok B2B müşteri, “Güven damgası gerçekten işe yarıyor mu?” sorusunu haklı olarak soruyor. En sağlıklı cevap: AB testi. Farklı sayfa düzenlerinde:

• Formun yanında küçük bir SSL/güven rozeti,
• Footer’da toplu güven ve sertifika logoları,
• Onay sayfasında ek bir güven mesajı

gibi varyasyonları deneyerek, dönüşüm oranlarını ölçebilirsiniz. Özellikle ilk defa teklif isteyen ya da demo talep eden kullanıcılar üzerinde, doğru konumlandırılmış bir güven mesajının kayda değer fark yarattığını pratikte sıkça görüyoruz.

Otomasyon, İzleme ve DCHost Altyapısında Uygulama

Güven mimarisini bir defa kurup bırakmak mümkün değil; sertifikaların süresi biter, domain yapısı değişir, yeni alt alanlar açılır. B2B kurumsal tarafta asıl fark yaratan nokta, operasyonel sürdürülebilirliktir.

SSL Sertifika Otomasyonu: ACME, DNS-01 ve Çoklu Alan Adları

Manuel sertifika yenileme süreçleri, özellikle çok sayıda alt alan ve ortam (test, staging, üretim) bulunan B2B projelerde sürdürülemez hale gelir. Bu noktada ACME tabanlı otomasyon devreye giriyor. DCHost altyapısında:

• cPanel/DirectAdmin entegrasyonlarıyla otomatik DV sertifika yenileme,
• VPS ve dedicated sunucularda acme.sh gibi araçlarla DNS-01 challenge ile wildcard/çoklu domain yönetimi,
• Yüksek trafikli siteler için özel CA ve özel otomasyon senaryoları

kurabiliyoruz. Bu alanda daha teknik bir yol haritası arıyorsanız, SSL sertifika otomasyon araçlarını detaylı anlattığımız yazımıza mutlaka göz atın.

Sertifika Süre Sonu İzleme ve Alarm Mekanizmaları

B2B ortamda sık gördüğümüz en acı hatalardan biri, büyük bir kurumun müşteri portalında sertifika süresinin bitmesi ve birkaç saatlik “site güvenli değil” uyarıları ile itibar kaybı yaşanması. Bunu önlemek için:

• Sadece CA e-posta bildirimlerine güvenmeyin; bağımsız sertifika tarayıcıları ve uptime izleme araçları kullanın.
• Monitoring sistemlerinize (Prometheus, Zabbix vb.) TLS sertifika son kullanma metrikleri ekleyin.
• Alarm eşiklerini en az 30, tercihen 45-60 gün öncesine ayarlayın.

Bu yaklaşımı domain ve DNS izleme ile birleştirmek için, uptime, SSL ve domain alarm mimarisini anlattığımız rehberden fikir alabilirsiniz. Aynı mantığı B2B kurumsal sitenize uygulamak oldukça kolay.

DCHost Üzerinde B2B Güven Mimarisi Nasıl Konumlanır?

DCHost tarafında B2B müşterilerimizle çalışırken genellikle şu kombinasyonları görüyoruz:

• Kurumsal web sitesi + içerik sitesi: Yönetilen veya klasik VPS altyapısı üzerinde, OV/EV sertifika, HSTS ve HTTP güvenlik başlıkları ile güçlendirilmiş.
• Müşteri/partner portalları: Ayrı bir VPS veya dedicated sunucu üzerinde, sıkılaştırılmış güvenlik duvarı, WAF ve gelişmiş TLS ayarlarıyla.
• Yoğun veritabanı ve entegrasyon yükü: Uygulama ve veritabanı sunucularının ayrıldığı, gerekirse colocation ile kurum içi sistemlerle düşük gecikmeli iletişim kuran mimariler.

Bu altyapılarda ortak nokta, SSL/TLS, HSTS preload, CAA ve güven damgalarını başından itibaren mimarinin bir parçası olarak ele almamız. Yani “site bitti, şimdi biraz da güvenlik ekleyelim” yerine, tasarım aşamasından itibaren güven mimarisini planlıyoruz.

Adım Adım Yol Haritası: B2B Kurumsal Sitenizde Güven Mimarisi

Konuyu toparlamak için, B2B kurumsal sitenizde uygulayabileceğiniz pratik bir yol haritası çıkaralım:

1. Mevcut durumu envanterleyin: Hangi alan adları, alt alanlar, ortamlar (dev, test, prod) ve hangi sertifikalar kullanılıyor? Tümü HTTPS mi, yoksa arada HTTP servisler var mı?
2. Doğru sertifika seviyesini seçin: Genel site ve portallar için DV mi, OV mi, EV mi kullanacağınıza karar verin; gerekirse ayrı alan adlarına farklı seviyeler atayın.
3. TLS temelini güçlendirin: TLS 1.0/1.1’i kapatın, TLS 1.2 ve 1.3’ü etkinleştirin, modern cipher setlerini uygulayın, OCSP stapling’i açın.
4. HSTS’yi aşamalı devreye alın: Önce preload’suz HSTS, sonra tüm subdomain’lerin HTTPS’e hazır olduğundan emin olun, en son preload başvurusuna geçin.
5. CAA kayıtlarını tasarlayın: Hangi CA’ların hangi alanlar için yetkili olduğuna kurumsal bir politika ile karar verin, bu politikayı DNS’e yansıtın.
6. HTTP güvenlik başlıklarını ekleyin: HSTS, Content-Security-Policy (CSP), X-Frame-Options, Referrer-Policy gibi başlıkları kurumsal güvenlik politikanızla hizalayın.
7. Güven damgaları ve uyumluluk sayfası hazırlayın: SSL seviyesi, güvenlik testleri, yedekleme ve regülasyon uyumunu şeffaf ve sade bir dille anlatan bir sayfa oluşturun.
8. Otomasyon ve izleme kurun: Sertifika yenileme, SSL süresi, domain ve DNS değişiklikleri için alarm mekanizmaları oluşturun; süreçleri dokümante edin.

Bu adımların her birini tek seferde yapmak zorunda değilsiniz; önemli olan, kurumsal olarak kabul edilmiş bir yol haritasına sahip olmak ve adım adım ilerlemek.

Özet ve Sonraki Adımlar: Güveni Dokümante Edilebilir Hale Getirin

B2B dünyasında karar vericiler için “güven” soyut bir his değil, dokümante edilebilir ve denetlenebilir bir gereklilik. SSL/TLS yapılandırmanız, HSTS preload stratejiniz, CAA kayıtlarınız ve güven damgalarınız; güvenlik ekibinin checklist’inde tik atabildiği somut maddelere dönüştüğünde, satış ve entegrasyon süreçleriniz de doğal olarak hızlanıyor.

Bu yazıda, B2B kurumsal siteniz için modern bir güven mimarisi kurarken dikkat etmeniz gereken ana başlıkları özetledik: doğru sertifika seviyesi, güncel TLS ayarları, HSTS ve HSTS preload, CAA ile sertifika yetkilendirme kontrolü, güven damgaları ve tüm bunları taşıyan bir otomasyon/izleme katmanı. Bir sonraki adım, bunları kendi alan adı ve mimarinize uyarlamak.

Eğer mevcut altyapınız DCHost üzerinde ise ya da taşımayı planlıyorsanız, B2B kurumsal siteniz için VPS, dedicated veya colocation seçeneklerini; SSL, HSTS preload ve CAA politikalarıyla birlikte tasarlamanıza yardımcı olabiliriz. Güven mimarinizi beraber gözden geçirmek, eksik noktaları tespit etmek veya sıfırdan yeni bir altyapı kurgulamak isterseniz, ekibimizle iletişime geçmeniz yeterli. Böylece sadece hızlı ve stabil değil, aynı zamanda denetlenebilir şekilde güvenli bir B2B platformu oluşturabilirsiniz.