Özel Anahtar Çevrim İçi Araçlara Yüklenirse Ne Olur?

Sesli Dinle — Makale

Özel anahtar, imza oluşturmak, kimlik doğrulamak ya da şifre çözmek için kullanılan gizli kriptografik değerdir. TLS bağlantı güvenliğinde, DKIM e-posta imzalamada, SSH uzak sisteme erişimde, OpenPGP ise mesaj ve dosyaların imzalanıp şifrelenmesinde özel anahtar kullanır. Bu sistemlerin ortak güven koşulu, özel anahtarın yetkisiz bir tarafa geçmemesidir.

Özel anahtar, onu işlemesi için yetkilendirilmemiş bir çevrim içi doğrulama aracına gerçekten gönderildiyse, anahtar sahibi aracın bu değeri kopyalamadığını, günlük kayıtlarına yazmadığını, yedeklemediğini veya başka bir bileşene aktarmadığını sonradan kesin biçimde kanıtlayamaz. Bu nedenle anahtar sahibi olayı yalnız yanlış dosya yükleme olarak görmemeli; özel anahtarın açığa çıkmış olabileceğini kabul etmelidir.

Anahtar sahibi etkilenen anahtarı artık güvenilir saymamalı, kullanıldığı sistemleri belirlemeli, güvenilir bir ortamda yeni anahtar çifti üretmeli ve eski anahtarın yetkisini kullanım türüne uygun yöntemle kaldırmalıdır. Eski anahtarı yerel bilgisayardan silmek tek başına güveni geri getirmez.

Dosyayı Sunucuya Yükleme ile Tarayıcıda Yerel İşleme Arasındaki Farklar

Bir web sayfasında dosya seçmek her zaman dosyanın uzak sunucuya gönderildiği anlamına gelmez. Bazı araçlar işlemi yalnız tarayıcı içinde gerçekleştirebilir. Ancak arayüzdeki “yerel çalışıyor” ifadesi tek başına kanıt değildir; bu iddiayı doğrulamak için uygulamanın kodunu ve ilgili işlem sırasındaki ağ isteklerini incelemek gerekir. Olaydan sonra yapılan bir deneme, daha önceki yüklemede aynı kodun çalıştığını kanıtlamaz.

Anahtarın yetkisiz bir sunucuya gönderildiği biliniyorsa veya gönderilip gönderilmediği güvenilir biçimde belirlenemiyorsa anahtar sahibi, özel anahtarın açığa çıkmış olabileceğini varsaymalıdır. Bir hizmetin “saklamıyoruz” demesi, anahtarın günlüklerde, hata kayıtlarında, geçici depolamada veya yedeklerde hiç bulunmadığını teknik olarak kanıtlamaz.

Özel Anahtar Açığa Çıktığında Yetkiyi Kaldırma ve Anahtarı Yenileme

Amaç yalnız eski dosyayı silmek değil, anahtarın sağladığı yetkiyi güvenilir yeni bir anahtara taşımaktır. Yeni anahtara geçiş ile eski yetkinin kaldırılması birlikte planlanır. Anahtarın kötüye kullanıldığı görülüyorsa hizmet kesintisi pahasına eski yetkinin hemen kaldırılması gerekebilir; normal yenilemelerdeki bekleme süresi sızıntıya otomatik olarak uygulanmaz.

1. Olayı kayda alın. Hangi anahtarın, hangi araca, yaklaşık hangi zamanda ve hangi kullanıcı veya sistem tarafından gönderildiğini belirleyin. Dosyanın özel anahtarı açık metin olarak mı yoksa parola korumalı biçimde mi taşıdığı da önemlidir. Olay kaydına anahtarın kendisini veya parolasını yapıştırmayın.
2. Anahtarın kullanım envanterini çıkarın. Aynı özel anahtarın hangi sunucularda, alan adlarında, e-posta imzalama sistemlerinde, kullanıcı hesaplarında veya istemcilerde kullanıldığını bulun. Aynı anahtar birden fazla yerde kullanılıyorsa olayın kapsamı da genişler.
3. Yeni anahtar çifti üretin. Yeni anahtarı etkilenen anahtarın kopyalandığı ortamdan bağımsız, güvenilir ve erişimi sınırlı bir sistemde oluşturun. Eski özel anahtardan türetilmiş veya yalnız yeniden adlandırılmış bir kopyayı kullanmayın.
4. Eski yetkiyi kaldırın. Bağlı sertifikayı, DKIM DNS kaydını, SSH yetkisini veya OpenPGP anahtar durumunu yeni anahtara göre güncelleyin ve eski anahtarın kabul edilmesini durdurun.
5. Kötüye kullanım izlerini inceleyin. Olayın bilinen zamanını ve daha önce sızmış olma ihtimalini dikkate alarak beklenmeyen oturum açma, imzalama ve sertifika kullanımını araştırın.
6. Eski kopyaların saklanma ihtiyacını belirleyin. Eski şifreli dosyaları açmak için bu anahtar gerekiyorsa tek kopyayı silmeyin; anahtarı yeni imza veya kimlik doğrulama işlemlerinde kullanmadan, erişimi sınırlı bir arşivde koruyun. Olay incelemesi ve veri saklama gereksinimleri karşılandıktan sonra gereksiz kopyaları anahtar yönetimi politikasına göre güvenli biçimde silin.

TLS, DKIM, SSH ve OpenPGP Anahtarlarında Güveni Yeniden Kurma

Eski anahtarı devre dışı bırakma yöntemi kullanılan protokole göre değişir. Aşağıdaki tablo, kurulum ayrıntıları yerine her anahtar türünde kimliğin ve yetkinin nasıl yeni anahtara geçirileceğini gösterir.

Alıcı e-posta sunucuları, önbelleklerindeki eski DNS kaydının süresi dolana kadar DKIM anahtarının iptal edildiğini görmeyebilir. Eski anahtarla imzalanmış meşru iletiler de iptal sonrasında doğrulanamayabilir. Sertifika ve OpenPGP iptallerinin etkili olması, karşı tarafın güncel iptal bilgisini denetlemesine bağlıdır. Doğrudan güvenilen kendinden imzalı TLS sertifikalarında ise yöneticinin eski sertifikayı istemcilerin güven listesinden çıkarması gerekir.

Özel Anahtarın Açığa Çıkmasının Geçmiş Verilere ve İmzalara Etkisi

Anahtarı değiştirmek, gelecekteki işlemleri güvenilir bir anahtara taşır ancak geçmişte yaşananları otomatik olarak “temizlemez”. Bir imzalama anahtarı sızdıysa ve sızıntının tam zamanı bilinmiyorsa güvenlik ekibinin hangi imzaları yetkili tarafın ürettiğini ayrıca değerlendirmesi gerekebilir. Olay öncesi ve sonrası kayıtların zaman çizelgesi bu ayrım için önemlidir.

Şifre çözmek için kullanılan özel anahtarın kopyalanması farklı bir sonuç doğurabilir. Saldırgan daha önce ele geçirdiği şifreli veriyi bu anahtarla çözebiliyorsa yalnız yeni anahtar üretmek geçmiş verinin gizliliğini geri getirmez. TLS bağlantılarında geçmiş oturumların etkilenmesi, kalıcı anahtar sonradan sızsa bile eski oturum anahtarlarını koruyan ileri gizliliğin sağlanıp sağlanmadığına bağlıdır; sunucu sertifikasının özel anahtarının sızması her eski TLS oturumunun otomatik olarak çözülebileceği anlamına gelmez.

SSH kimlik doğrulama anahtarında temel sorun, eski açık anahtar yetkili kaldığı sürece kopyalanmış özel anahtarın yeni oturum açma denemelerinde kullanılabilmesidir. Bu nedenle sistem yöneticisi yalnız istemcideki özel anahtar dosyasını değiştirmekle yetinmemeli, sunucudaki eski açık anahtarın yetkisini de kaldırmalıdır. Bu işlem önceden açılmış SSH oturumlarını kendiliğinden kapatmaz; yönetici şüpheli oturumları ve bunlarla yapılan değişiklikleri ayrıca incelemelidir.

Parola Korumalı Özel Anahtar da Değiştirilmeli mi?

Parola ile şifrelenmiş bir özel anahtar dosyası, açık metin özel anahtara göre ek koruma sağlar. Parola çevrim içi araca verilmediyse güçlü bir parola anahtarın hemen kullanılmasını zorlaştırabilir; ancak uzak sisteme geçen dosyanın kopyası daha sonra çevrim dışı parola denemelerine konu olabilir.

Özel anahtar dosyası yetkisiz bir sisteme gönderildiyse anahtar sahibi yalnız parola korumasına güvenmemeli ve anahtarı yenilemelidir. Yerel dosyanın parolasını değiştirmek, daha önce kopyalanan dosyanın parolasını değiştirmez ve eski anahtarı yenilemenin yerine geçmez. Parola da aynı hizmete gönderildiyse saldırganın anahtarı kullanma olasılığı artar ve güvenlik ekibi daha hızlı müdahale etmelidir.

Silme Talebi Güveni Geri Getirir mi?

Çevrim içi araç sağlayıcısının yüklenen dosyayı sildiğini bildirmesi riski azaltabilir, ancak eski anahtarı yeniden güvenilir kılmaz. Anahtar sahibi dosyanın daha önce kopyalanmadığını, günlüklerde tutulmadığını veya başka sistemlere aktarılmadığını doğrulayamıyorsa eski anahtarı güvenilir saymamalıdır.

Tarayıcı geçmişini temizlemek, sekmeyi kapatmak, yerel dosyayı silmek veya özel anahtarın adını değiştirmek de eski yetkiyi kaldırmaz. Anahtar sahibi güveni, eski gizli değerin unutulduğunu varsayarak değil, yeni ve bağımsız bir anahtarla yeniden kurmalıdır.

Özel Anahtarın Çevrim İçi Araçlara Gönderilmesini Önleme

• Çevrim içi doğrulama araçlarına mümkün olduğunda yalnız sertifika, açık anahtar, anahtar parmak izi veya DNS'te zaten yayımlanan açık değerleri gönderin. Bu verilerdeki kuruluş ve iç sistem adlarının da paylaşılabilir olduğunu kontrol edin.
• Özel anahtar isteyen çevrim içi aracın buna gerçekten gereksinim duyup duymadığını doğrulayın; pek çok kontrol özel anahtarsız yapılabilir.
• Üretim anahtarlarıyla test yapmak yerine yalnız test için oluşturulmuş ayrı anahtarlar kullanın.
• Özel anahtarların nerede bulunduğunu, hangi kimliğe bağlı olduğunu ve kim tarafından yönetildiğini gösteren güncel bir envanter tutun.
• Mümkün olan altyapılarda özel anahtarın dışarı aktarılmasını zorlaştıran veya engelleyen korumalı kriptografik depolar kullanın.
• Aynı özel anahtarı farklı hizmetlerde yeniden kullanmayın; bir sızıntının etkisini tek bir kullanım alanıyla sınırlandırın.