Bir ekipteki SSH anahtarlarını yönetmek için en iyi yöntemler nelerdir?


42

Aşağıdaki özelliklere sahip geliştiricilerin ve yöneticilerin küçük ekipleriyle (<10) çalışıyorum:

  • Ekip üyelerinin çoğu, çoğu taşınabilir olan> 1 kişisel bilgisayara sahiptir
  • Ekip üyeleri genellikle sudo ile 10-50 sunucuya erişebilir

Bunun çoğu başlangıç ​​ve küçük ila orta ölçekli kurumsal BT grupları için oldukça tipik olduğunu düşünüyorum.

Böyle bir ekipte SSH anahtarlarını yönetmek için en iyi yöntemler nelerdir?

Tüm takım için tek bir anahtar paylaşmalı mıyım?

Her kişinin paylaşılan bir hesapta kendi anahtarı olmalı mı (her sunucuda "ubuntu")?

Ayrı hesaplar?

Her ekip üyesi dizüstü veya masaüstü bilgisayarlarının her biri için ayrı bir anahtar bulundurmalı mı?

Yanıtlar:


33

Şirketimde, tüm makinelerde tutarlı bir hesap kümesine sahip olmak için LDAP kullanıyoruz ve ardından authorized_keystüm kullanıcılara tüm sunuculara dosya dağıtmak için bir yapılandırma yönetimi aracı kullanıyoruz (bizim durumumuzda şu anda cfengine) . Anahtar dosyalarının kendisi (diğer sistem yapılandırma bilgileriyle birlikte) bir git havuzunda tutulur, böylece anahtarların ne zaman gelip gittiğini görebiliriz. cfengine ayrıca sudoers, LDAP dizinindeki kullanıcıları ve grupları kullanarak, her ana bilgisayarda neyin root olarak çalıştırılacağını kontrol eden bir dosyayı da dağıtır .

Üretim sunucularımızda parola doğrulaması tamamen devre dışı olduğundan, SSH anahtar yetkilendirme zorunludur. Politika, kaybolan / çalınan bir dizüstü bilgisayarın etkisini azaltmak için her bir dizüstü bilgisayar / masaüstü / ne olursa olsun ayrı bir anahtar kullanılmasını ve tüm anahtarlarda bir parola kullanılmasını teşvik eder.

Ayrıca üretim ağındaki ana makinelere erişmek için kullanılan ve bu ağın etrafında çok kısıtlayıcı güvenlik duvarı kurallarına sahip olmamızı sağlayan bir ana bilgisayar sunucumuz var. Çoğu mühendis bu şeffaflığı sağlamak için bazı özel SSH yapılandırmalarına sahiptir:

Host prod-*.example.com
     User jsmith
     ForwardAgent yes
     ProxyCommand ssh -q bastion.example.com "nc %h %p"

Yeni bir anahtar eklemek veya eski olanı kaldırmak bu düzende biraz tören gerektirir. Yeni bir anahtar eklemek için denetim izini bırakan ve herkes tarafından görülebilen bir işlem olması arzu edilir. Bununla birlikte, genel gider nedeniyle, insanların bazen artık ihtiyaç duyulmadığında eski bir anahtarı çıkarmayı ihmal ettiğini ve bir çalışanın şirketten ayrıldığı zaman temizlikten başka gerçek bir yolu olmadığını düşünüyorum. Aynı zamanda yeni bir mühendise binerken ek bir sürtünme yaratır, çünkü yeni bir anahtar üretmeleri gerekir ve tamamen üretken olmadan önce tüm ev sahiplerine gönderilmesini isterler.

Bununla birlikte, en büyük yarar, her kullanıcı için ayrı bir kullanıcı adına sahip olmaktır; bu, ihtiyaç duyduğumuzda daha ayrıntılı erişim kontrolü yapmayı kolaylaştırır ve her kullanıcıya, denetim günlüklerinde görünen ve her birini izlemeye çalışırken gerçekten yararlı olabilecek bir kimlik verir. üretim sorunu bir sysadmin eylemine geri döndü.

"İyi bilinen" SSH anahtarları alternatif bir erişim yolu olarak kullanılabildiğinden, bu kurulum altında üretim sahiplerine karşı önlem alan otomatik sistemlere sahip olmak oldukça zordur. Şimdiye kadar bu otomatik sistemlerin kullanıcı hesaplarını sadece işlerini yapmak için ihtiyaç duydukları minimum erişime sahip olduk ve kötü niyetli bir kullanıcının (zaten üretim erişimi olan bir mühendis olmalı) aynı işlemleri yapabileceklerini kabul ettik. anonim olarak uygulamanın anahtarını kullanarak.


Bu gerçekten iyi bir cevap! Takip eden soru: .authorized_keys dağıtmak için cfengine kullanıyorsunuz. SSH ortak anahtarlarını doğrudan LDAP sunucunuzda saklama yöntemlerinden herhangi birini araştırdınız mı? Çoğunlukla kırılgan hisseden yama sshd'ye ihtiyaç duyarlar.
Evan Prodromou

Şef ile benzer bir şey yaptım.
gWaldo

1
@EvanProdromou LDAP’de SSH açık anahtarlar kurdum, fakat SSH paketlerini kendim güncel tutmam gerektiğinden, değersiz olduğundan çok daha fazla güçlüydü ve birkaç SSH güvenlik açığı vardı
Daniel Lawson

1
Sudo kuralları ve SSH anahtarları LDAP'a da yerleştirilebilir, bunu ayarlamak için SSSD kullanılabilir. Bağlantılar: sudo.ws/sudoers.ldap.man.html ve access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/…
fuero

Senin ProxyCommand ssh -qorada biraz olsun hoşuma gitti ! Bunu hiç görmedim. Bir bastion sunucusunu kurmakta tereddüt ediyorum ama son kullanıcılar için şeffaf olabilirse, o zaman hepsi için olabilirim. Teşekkürler Martin!
Ağustos'ta

6

Şahsen, üzerinde temel bir kullanıcı hesabı bulunan özel bir ssh bastion makinesinde bir anahtar bulunan her personel üyesinin fikrini seviyorum. Bu kullanıcı hesabının kullanması gereken tüm sunuculara erişim sağlayan 1 ssh anahtarı var. (bu diğer sunucular da güvenlik duvarından kapatılmalıdır, bu nedenle yalnızca temel makineden ssh erişimi etkindir)

Daha sonra günlük iş makinelerinde, dizüstü bilgisayarlarında, tabletlerinde vb. Kendi aralarında bir anahtar veya birden çok anahtar arasında kendi seçimlerini yapabilirler.

Bu ağdaki bir sistem yöneticisi olarak, bakılacak en az sayıda anahtara sahip olursunuz (dev başına bir tane), ağ üzerinden ssh erişimini kolayca izleyebilir (tüm bunlar bastion makinesinden geçerken) kendi makineleri arasında paylaştıkları tek bir sorun değil, çünkü güncellenecek tek bir makineniz var. (BastS ssh anahtarlarının güvenliği ihlal edilmedikçe, kullanıcı anahtarlarından birinden çok daha olası olmayan bir durum)


5

120 geliştiriciden oluşan bir sunucuya SSH anahtar erişimi sağlamak için ihtiyacım olan durumdan ~ 120 kadar uzak sunucuya gittim.

Geliştiricileri, tek bir "atlama sunucusuyla" bağlanmaya zorlayarak erişimi kontrol ettim. Bu ana bilgisayardan özel / genel anahtarlar oluşturdum ve onları müşteri sunucularına gönderdim. Geliştiricilerin bir dizüstü bilgisayardan erişmeleri gerekiyorsa, aynı tuş takımını yerel sistemlerinde kullanabilirler.


2

Ben şahsen kullanıcı başına giderdim, o zaman anında hesap verebilirlik yapıyorsun ve kısıtlamaları çok daha kolay belirliyorsun - başkalarının ne düşündüğünü bilmiyorum?


2

Duyduğum, ancak kendimi kullanmadığım bir yaklaşım, her kullanıcının kendi ssh public key config ve ayrıca özelleştirmek istedikleri nokta dosyalarının bulunduğu bir pakete (örneğin, deb, .rpm) sahip olmalarıdır. , .profile, .vimrc vb.). Bu bir şirket deposunda imzalanır ve saklanır. Bu paket aynı zamanda kullanıcı hesabını oluşturmaktan sorumlu olabilir veya hesabı oluşturan başka bir şeyi (cfengine / kukla vb.) Veya LDAP gibi merkezi bir kimlik doğrulama sistemini destekleyebilir.

Bu paketler daha sonra ne tür bir mekanizma (cfengine / kukla vb. Cron işi) vasıtasıyla ana makinelere kurulur. Bir yaklaşım, kullanıcı başına paketlere bağımlı olan bir meta paketine sahip olmaktır.

Bir genel anahtarı kaldırmak, ancak kullanıcıyı kaldırmak istemiyorsanız, kullanıcı başına paket güncellenir. Bir kullanıcıyı kaldırmak istiyorsanız, paketi kaldırırsınız.

Heterojen sistemleriniz varsa ve hem .rpm hem de .deb dosyalarının bakımını yapmak zorunda kalırsanız, uzaylı gibi araçlar biraz daha kolay olsa da, bunun biraz sinir bozucu olduğunu görebiliyorum.

Dediğim gibi, bunu kendim yapmadım. Bu yaklaşımın bana sağladığı yarar, merkezi bir LDAP sistemini ve kullanıcı hesaplarının merkezi yönetimini desteklemesidir, çünkü kullanıcının paketini kolayca yönetmesine izin vermeksizin. Bir kullanıcının erişemeyeceği kukla gibi araçlar ile.


1

Daha güvenli bir rota izlemeli ve her kullanıcıyı ayrı anahtarlara ve muhtemelen her bir cihaz için kullanmaya zorlamalısınız.

Kullanıcılar arasında paylaşılan anahtarlar varsa - küçük bir takım olsanız bile - bir anahtarın iptal edilmesi diğer herkes için bir sakınca değildir.

Personelinizin tüm cihazları için bir tuşa sahip olmasına izin verirseniz, o cihazla hangi sunuculara bağlanabileceklerini seçebilir ve seçebilirler. Örneğin, mobil bir dizüstü bilgisayar bir veya iki sunucu ile sınırlandırılabilir, ancak ofisteki masaüstü tüm sunuculara erişebilir.


1

Birkaç yıl önce, Envy Labs, geliştirme ekipleri için böyle bir şeyle başa çıkmak için Keymaster (müşteri Gatekeeper ile ortak) adlı bir araç yazdı.

Projenin son iki yıl boyunca fazla sevgisi yoktu, ancak muhtemelen inceltebileceğiniz ve belki de hayata döndürebileceğiniz bir şey?

Depo github'da mevcuttur: https://github.com/envylabs/keymaster


-4

Bir yaklaşım, NIS üzerinden NIS sunucusunu / home share ile ayarlayabilir. Bu, sunuculardaki sudo ile birleştirilmiştir ve her sunucu için yalnızca ssh yapılandırmasıyla istediğiniz kullanıcılara izin vermektedir.

Bu şekilde, ekibin her üyesi tüm sunuculara erişmek için yalnızca bir kullanıcı ve anahtarını kullanır. Yönetici görevleri için Sudo ve bir şifre.

Saygılarımızla,

Rafael


1
1) NIS'nin etkinleştirilmesi bir güvenlik deliğidir. 2) Bir parolaya ve hesaba sahip olmak izlenebilirlik ve hesap verebilirliğe aykırıdır.
Deer Hunter
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.