HTTPS sertifikasında kurulum kadar yenileme de önemlidir

Örnek bir iş senaryosu

Yenileme görevi başarılı çalışmış olsa bile site eski sertifikaya bağlı kalabilir. Bu durumda yönetici dosya veya depoda yeni tarihi görürken ziyaretçi tarayıcısı süresi dolmuş sertifikayı almaya devam eder. Kontrolün dışarıdan gerçek alan adı üzerinden yapılması bu farkı ortaya çıkarır. Ana alan adı ile www adresi ayrı ayrı test edilmeli, yönlendirmeler de doğrulanmalıdır.

Dört adımda çalışma düzeni

İlk bakışta görünmeyen noktalar

Yenileme görevinde kullanılan hesabın gerekli sertifika deposuna ve bağlama işlemine erişimi olmalıdır. Görev etkileşimli kullanıcı oturumuna bağımlıysa sunucu yeniden başladıktan sonra çalışmayabilir. Son çalıştırma sonucunu tek başına yeterli saymayın; sertifikanın gerçekten değiştiğini kontrol edin. Birden fazla sertifika aracı aynı alan adı için işlem yapıyorsa sorumluluk karmaşası oluşabilir. Hangi aracın yenilediği ve hangi görevin bağlamayı güncellediği belgelenmelidir. Eski sertifikaları hemen silmek yerine kullanımda olmadıkları doğrulanmalıdır. Yayın değişikliğinde doğrulama yönteminin ihtiyaç duyduğu yol veya portun erişilebilir kalması da yenilemenin devamı için önemlidir.

Kontrolü kanıtla kapatma

Güvenlik ve yayın kontrolünde her madde için gözlenebilir bir sonuç belirleyin. “Giriş güvenli” demek yerine yetkisiz isteğin reddedildiğini, çıkış sonrası oturumun çalışmadığını veya çok büyük form gövdesinin kabul edilmediğini test edin. Sonuçları kullanılan sürüm ve tarih bilgisiyle kaydedin. Böylece daha sonraki değişikliklerde aynı davranış yeniden kontrol edilebilir. Test verileri gerçek müşteri verisinden ayrılmalıdır. Kayıt oluşturan testler sonrasında yalnızca test kayıtlarının temizlendiği doğrulanmalıdır. Başarılı kontrolün kapsamını açık tutun; birkaç test bütün sistemin kusursuz olduğunu göstermez.

Uygulama ile sunucu sorumluluklarını ayırın. Kod alan doğrulamasını yapabilir fakat dosya izinleri, sertifika bağlaması ve yedek erişimi sunucu düzeyinde doğru kurulmalıdır. Bir katmanın varlığı diğerini gereksiz hale getirmez. Kaynak dosyaları, yapılandırma sırları ve veritabanı herkese açık web klasörüne konulmamalıdır. Kullanıcıya gösterilen hata mesajı teknik ayrıntı veya gizli bilgi içermemeli; sunucu tarafındaki kayıt tanı koymaya yetecek kadar bilgi taşımalıdır. Yeni bir bileşen eklendiğinde saldırı yüzeyi ve bakım sorumluluğu da değerlendirilmelidir. Gereksiz özellikleri açık bırakmak sonraki kontrol yükünü artırır.

Kontrolleri tek seferlik teslim maddesi olarak görmeyin. Yeni sürüm, yeni entegrasyon veya yetki değişikliği bazı varsayımları geçersiz kılabilir. Düzenli bağımlılık taraması, erişim gözden geçirmesi ve geri dönüş denemesi planlayın. Otomatik taramanın bulgu vermemesi bütün açıkların bulunmuş olduğu anlamına gelmez. Kritik uygulamalarda kapsamlı bağımsız güvenlik değerlendirmesi ayrıca düşünülmelidir. Küçük bir işletme için başlangıçta en değerli adım çoğu zaman sorumlulukları ve kontrol takvimini netleştirmektir. Sertifika, yedek ve yönetici hesabı gibi temel bileşenlerin sahibi belli olduğunda sorunlar kişisel hafızaya daha az bağımlı kalır.

Ekibinize sorabileceğiniz sorular

• Ziyaretçiye hangi sertifika sunuluyor?
• www ve ana alan adı birlikte çalışıyor mu?
• Yenileme hatası kime bildiriliyor?

Bu soruları seçtiğiniz örnek kayıt üzerinde yanıtlayın. Her açık nokta için sorumlu kişiyi, yapılacak düzeltmeyi ve yeniden kontrol tarihini not edin. Böylece görüşme, uygulanabilir bir iş listesiyle tamamlanır.