Her 90 günde bir SSH anahtarlarını kesen bir sisteme sahip olun

Artık GSYİH'yi yorumlamaları nedeniyle her 90 günde bir her şifreyi değiştirmemizi gerektiren bir müşterim var. Bu kuralları kendileri için geliştirdiğimiz web tabanlı sistem için sorun yok çünkü bu kuralları uygulayabiliyoruz. Ancak, sunuculara erişmek için kullanılan SSH anahtarlarımızdaki şifreleri değiştirmemizi de istiyorlar, bu iyi değil.

1. Mevcut bir SSH anahtarındaki şifreyi değiştirmek mümkün müdür?

2. Değilse, bununla başa çıkmak için kullanabileceğimiz herhangi bir araç var mı? Düşünüyorum:

   a. Yeni anahtarlar oluştur.
   b. Tüm ortak anahtarları mevcut sunuculara dağıtın.
   c. Mevcut ortak anahtarları kaldırın.
   d. Eski özel anahtarları arşivle.

   Burada Kukla hakkında bazı yazılar okudum, ancak anladıkları gibi, genel anahtarların sunucular arasında dağıtılması ve her geçen gün yeni anahtarlar oluşturmama sorununu çözmek istiyorlar. Kukla araştırmamla daha ileri gitmeli miyim?

3. Parola saklama ve ssh tuşları söz konusu olduğunda topluluk standardı nedir? Bunu nasıl yapıyorsun?

Müşteri burada yanlış ve ne hakkında konuştuğunu anlamıyor. Özel anahtardaki parolayı değiştirmek çok kötü bir fikir çünkü çok sezgisel güvenlik özelliklerine sahip.

Normalde, kullanıcılar "artık gizli değil" olarak değiştirdikleri şifreleri düşünürler. Düşük değerli siteler, çevrimiçi tanıtıcılar / takma adlar, esprilerdeki yumruklar vb.

Özel bir anahtarı şifrelemek için kullanılan bir parola için, bu şekilde çalışmaz ! Anahtarla ilişkili tüm ayrıcalıklar iptal edilmediği sürece parola sonsuza kadar gizli tutulmalıdır (ve aşağıdaki ssh anahtarlarına uygulanmaz, ancak parola yalnızca imzalamak için değil, özel mesajlar almak için kullanılan bir anahtar için ise, o zaman sonsuza dek gerçekten sonsuza kadar demektir ). Bunun nedeni, şifreli özel anahtar dosyasının bir saldırgan tarafından edinilmiş olması veya gelecekte bir saldırgan tarafından alınabileceği bir yerde (yedeklemede olduğu gibi) saklanması olasılığıdır. Eğer parola hiç ortaya çıkarsa, o zaman tehlikeye girer.

Bir anlamda, kullanım ömrü boyunca N kodundan geçen özel bir anahtar güvenli bir şekilde 1 / N'dir, çünkü saldırganın şifreli özel anahtar dosyaya erişimi varsa, geçmiş anahtar sözcüklerden birinin bilgisi , anahtarı tehlikeye atmak için yeterlidir. .

Şimdi, sorununa geri dönelim.

Eğer müşteri bu "ssh şifrelerini" yanlış algılamaya kilitlememiş ve üzerine girmemiş olsaydı, yapılacak en doğru şey asla onları gündeme getirmeyecek ve anahtar ele almak için en iyi uygulamaları takip etmek olacaktır. Ama şimdi onlar sahip, muhtemelen onları tatmin etmek için bir şeyler yapmak zorunda. Özel anahtarları şifreleyen parolaların parolalardan farklı güvenlik özelliklerine sahip olduğunu açıklamayı deneyebilirsiniz, ancak müşterinin burada bir çok şeyle ilgili ne kadar yanlış olduğu göz önüne alındığında (parola sona ermesi genel olarak kötü bir fikirdir) bunun işe yarayacağından şüpheliyim.

Bu, yeni anahtarları dağıtmak için bir sistemi otomatikleştirme görevini yerine getirir. Ben ediyorum şiddetle vazgeçirmek beri merkezi olarak yeni anahtarlar üreten bir sistem otomatik hale sizi özel tuşlar makineler arasında taşınan asla . Bunun yerine, tarafınızdaki yeni özel anahtarlar oluşturmak ve ilgili ortak anahtarlar yayınlamak için erişime ihtiyaç duyan çalışanlarınız / yükleniciler için kolaylık sağlamak için işlemlere / hatırlatıcılara / komut dosyalarına sahip olmanız ve ortak anahtar dağıtım sistemine (Kukla veya başka bir şekilde) sahip olmanız gerekir. Bunları, erişmeleri gereken sistemlere doğru itiyorsunuz.

Ek olarak: Müşteriyi bunu bırakmaya ikna edebilecek bir şey, yeni özel anahtarın eskisinden farklı bir parolaya sahip olmanın, hatta bir parolaya sahip olmanın zorunluluğunun bir yolu olmadığını belirtmektir.

İlk sorunuzun cevabı: "Mevcut bir SSH anahtarındaki şifreyi değiştirmek mümkün mü?" Evet. Openssh ile bu kadar basitssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]

Sorun, şifrenin son kullanma tarihi için desteği olmayan basit bir format olan özel anahtar dosyasında / içinde olmasıdır. Ayrıca, ssh içindeki anahtar tabanlı kimlik doğrulama kavramının büyük bir kısmı, özel anahtarın merkezi olarak yönetilmemesidir, yalnızca kullanıcının iş istasyonunda bulunması gerekir; bu, özel anahtar üzerinde bir parola süresinin dolması politikasının uygulanmasını olanaksız kılar.

Bunun yerine: Şifre politikasından önce bulunduğum her ortamda, söz konusu hesaba erişmek için kullanılan yöntemde değil, kullanıcı hesabı nesnesinde. Bir parolanın süresi dolduğunda veya bir hesap kilitlendiğinde, ssh anahtarı dahil tüm erişim yöntemleri kilitlenir.

Bir hesapta daha fazla güvenlik gerektiğinde çok faktörlü kimlik doğrulama ekleyin.

Ancak diğer kişilerin geçerli kaygılarınızı gidermek için neler yaptıklarını merak ediyorum.

AuthorizedKeysCommand kullanılarak , sunucu tarafında bazı sona erme mekanizmaları uygulanabilir. Dosya zaman damgasını basit kontrol etmekten daha karmaşık bir şeye.

Yeterli olan veya olmayan bir olasılık, imzalı anahtar üzerinde bir ömür boyu ayarlamanıza izin veren bir SSH kullanıcısı CA kullanmaktır. Anahtar imzalamanın etrafına koyduğunuz otomasyon ne olursa olsun, 90 günden daha uzun süre imza atmayı reddedebilir. Ardından, kullanıcı CA'nızın genel anahtarını / etc / ssh / sshd_config içindeki TrustedUserCAKeys öğesine ekleyin ve AuthorizedKeysFile öğesini hiçbiri olarak ayarlayın.

Kısa ömürlü, imzalı SSH anahtarları oluşturmak için Hashicorp'un Kasası gibi bir araç kullanabilirsiniz . Her kullanıcı her gün yeni bir anahtar alır (ya da öylesine). LDAP sunucusu gibi, bugün kullandıklarınızı kullanarak sertifikayı almak için Vault kimliğini doğrularsınız.

Bunu kurma çabası çok büyük değil, ama benim tecrübeme göre, @Mark'ın yorumunda neye atıfta bulunduğundan daha büyük. Temel olarak bir problemi (ipucu olmayan müşteri gereksinimleri) bir diğeriyle değiştiriyorsunuz (parça yönetimi ).

Ancak, şirket içi X509 sertifikalarının kolayca üretilmesi ve veritabanı şifrelerinin yönetilmesi, metin dosyasındaki uygulama sırları gibi birkaç senaryonun yapılmasını sağlar. Çaba ve yatırım getirisini yargılıyorsun.

Ayrıca, açık kaynaklı sürümün DR özelliklerine sahip olmadığını unutmayın (başka her şeye sahiptir).

Zamana dayalı bir kerelik şifreler (TOTP) içeren bir anahtar ajan kullanabilirsiniz. Şimdi "şifreniz" her dakika değişiyor.

_{Buradaki herkes doğru olsa da: Bu aptalca.}