Kapsam ve Temel Riskler

TLS sertifikaları yalnızca son kullanma tarihinden önce yenilenmesi gereken dosyalar değildir. Yanlış alan adı, zayıf özel anahtar koruması, eksik güven zinciri, hatalı dağıtım veya unutulmuş eski sertifikalar hizmet kesintisine ve güvenlik zafiyetlerine yol açabilir. Bu nedenle sertifika yönetimi; envanter, yetkilendirme, güvenli saklama, dağıtım, doğrulama, izleme ve gerektiğinde iptal adımlarından oluşan bir yaşam döngüsü olarak ele alınmalıdır.

İlk adım, internete açık ve kurum içi servislerin kapsamını belirlemektir. Her kayıt için alan adı, servis sahibi, teknik sorumlu, ortam, son geçerlilik tarihi, anahtar türü, sertifika otoritesi ve yenileme yöntemi tutulmalıdır. Hassas ortamlarda özel anahtara kimlerin ve hangi otomasyon hesaplarının erişebildiği ayrıca izlenmelidir.

Güvenli Sertifika Envanteri Oluşturma

Envanter yalnızca merkezi web sunucularını değil; yük dengeleyicileri, API geçitlerini, VPN uçlarını, e-posta servislerini, konteynerleri, CDN katmanlarını ve üçüncü taraf entegrasyonlarını da kapsamalıdır. Aynı sertifikanın birden fazla sistemde kullanılması, yenileme veya iptal sırasında etki alanını büyütür. Bu nedenle sertifika ile özel anahtar arasındaki ilişki, kullanım noktaları ve bağımlı servisler belgelenmelidir.

Kontrol listesi:

• Alan adı, servis sahibi ve teknik sorumlu belirlenmiş mi?
• Sertifika, zincir ve özel anahtar ayrı ayrı izleniyor mu?
• Örneğin 60, 30, 14 ve 7 gün kala kademeli uyarılar tanımlı mı?
• Test, ön üretim ve üretim sertifikaları birbirinden ayrılmış mı?
• Kullanılmayan veya sahibi belirsiz sertifikalar düzenli olarak gözden geçiriliyor mu?
• Aynı özel anahtarın birden fazla serviste kullanılıp kullanılmadığı biliniyor mu?

Envanter güvenli bir varlık yönetimi sisteminde tutulmalı; özel anahtarlar düz metin dosyalarında, ortak klasörlerde veya kaynak kodu depolarında saklanmamalıdır. Envanter kaydının kendisi de erişim kontrolü ve değişiklik denetimiyle korunmalıdır.

Anahtar ve Dağıtım Güvenliği

Özel anahtar üretimi ve saklanması, sertifikanın kendisi kadar önemlidir. Anahtarlar mümkünse erişim kontrolü, denetim kaydı ve otomatik rotasyon desteği bulunan bir gizli bilgi yönetim sisteminde tutulmalıdır. Dosya tabanlı kullanım zorunluysa işletim sistemi izinleri en az ayrıcalık ilkesine göre sınırlandırılmalı, yedekler şifrelenmeli ve anahtarların loglara yanlışlıkla yazılmadığı kontrol edilmelidir.

Dağıtım sürecinde şu ayrımlar korunmalıdır:

• Sertifika imzalama yetkisi ile sunucuya dağıtım yetkisi farklı roller olmalıdır.
• Üretim anahtarları geliştirici bilgisayarlarına veya kişisel depolama alanlarına kopyalanmamalıdır.
• Yenileme sonrasında zincir dosyası, dosya izinleri ve sunucu yapılandırması birlikte doğrulanmalıdır.
• Otomasyon hesabı yalnızca gerekli servis ve dosyalara erişebilmelidir.
• Değişiklikler onay, sürümleme, gözden geçirme ve geri alma adımlarıyla uygulanmalıdır.

Otomatik yenileme kullanılıyorsa görev başarısız olduğunda merkezi izleme sistemine uyarı gönderilmelidir. Başarılı yenileme de ayrıca doğrulanmalı; yalnızca dosyanın değiştirilmiş olması yeterli kabul edilmemelidir. Yenileme sonrası ilgili uç noktaya bağlantı kurulması, doğru sertifikanın sunulması ve uygulamanın sağlıklı yanıt vermesi kontrol edilmelidir.

TLS Yapılandırmasını Doğrulama

Sertifika geçerli görünse bile istemci ile sunucu arasındaki TLS yapılandırması hatalı olabilir. Yetkili ortamlarda yapılan kontrollerde sertifikanın alan adıyla eşleşmesi, Subject Alternative Name alanlarının doğruluğu, güven zincirinin tamamlanması, eski protokollerin kapatılması ve kurumun güvenlik politikasına uygun şifre takımlarının kullanılması incelenmelidir.

Örnek doğrulama adımları:

• Farklı işletim sistemi ve istemci türleriyle el sıkışma ve zincir doğrulama testi yapılır.
• Sunucunun süresi dolmuş, iptal edilmiş veya beklenmeyen eski sertifikayı sunmadığı kontrol edilir.
• Yük dengeleyici, uygulama sunucusu ve CDN katmanlarının aynı TLS politikasını uyguladığı incelenir.
• Değişiklik sonrasında uygulama sağlığı, bağlantı hataları ve sertifika uyarıları loglardan gözden geçirilir.
• Kontrol sonuçları, değişiklik kaydı ve beklenen etkiyle birlikte belgelenir.

Kontroller yalnızca üretimde değil, değişiklik öncesi test ortamında da yapılmalıdır. Tarama sonuçları tek başına karar vermemeli; servis sahibi ve güvenlik ekibi bulgunun gerçek etkisini, uyumluluk gereksinimlerini ve geri dönüş planını birlikte değerlendirmelidir.

İzleme, Olay Müdahalesi ve Geri Dönüş

İzleme sisteminde sertifikanın süresinin dolmasına kalan zaman, zincir doğrulama hataları, beklenmeyen sertifika değişimleri, başarısız yenileme görevleri ve özel anahtara erişim olayları takip edilmelidir. Kritik servislerde sorumlu ekip, nöbetçi ekip ve olay yönetimi kaydı arasında yedekli bildirim kurulması kesinti riskini azaltır. Uyarıların yalnızca üretilmesi değil, zamanında sahiplenilip kapatılması da ölçülmelidir.

Yetkisiz anahtar erişimi şüphesinde yalnızca yeni sertifika yüklemek yeterli değildir. İlgili sertifika ve anahtar kullanım politikalarına göre iptal edilmeli, yeni bir anahtar çifti oluşturulmalı, erişim logları incelenmeli ve aynı anahtarın kullanıldığı diğer servisler belirlenmelidir. Gerekirse ilgili kimlik bilgileri döndürülmeli ve etkilenen uç noktalar geçici olarak sınırlandırılmalıdır. Olay sonrasında kök neden, tespit süresi, müdahale süresi ve otomasyonun başarısız olduğu noktalar kayıt altına alınarak süreç güncellenmelidir.

Her yenileme döneminden sonra kısa bir tatbikat yapılması faydalıdır: sorumlu kişi bulunamadığında ne olur, otomasyon çalışmazsa manuel geri dönüş nasıl yapılır ve eski sertifikaya dönüş hangi koşullarda güvenlidir? Bu soruların yanıtı önceden belgelenir, yetkili ekiplerle denenir ve kritik servislerde yedek iletişim kanalları hazır tutulursa hem güvenlik hem de hizmet sürekliliği güçlenir.