Linux ve Windows için sunucu kimlik yönetimi


12

RHEL, Solaris, Windows 2003 ve Windows 2008 sunucularının bir karışımıyla nispeten küçük bir dükkanız (sistem yöneticilerinin sayısı kadar); toplamda yaklaşık 200 sunucu.

Yönetici hesaplarımız için ( rootLinux ve admnistratorWindows'da), veri merkezi konumuna ve sunucunun diğer birkaç belgelenmiş özelliğine bağlı bir şifre düzenimiz var.

Linux'ta şu anki uygulamamız, yapabileceğimiz ayrıcalıklı olmayan bir hesap suoluşturmaktır root. Windows tabanlı sistemlerde, yönetici ayrıcalıklarına sahip ek bir hesap oluştururuz. Bu hesapların her ikisi de aynı şifreyi paylaşır.

Bunun çok verimsiz olduğu kanıtlanmıştır. Birisi dükkanımızı terk ettiğinde:

  1. Yönetici hesapları için şifre düzenini değiştirme
  2. Her sunucu için yeni bir yönetici parolası oluşturun
  3. Yönetici olmayan yeni bir hesap şifresi oluşturun
  4. Her sunucuya dokunun ve şifreleri değiştirin

Benzer bir ortamdaki herhangi birinin bu kimlik bilgilerini yönetmenin daha akılcı bir yolunu önerip öneremeyeceğini bilmek istedim. İlgili bazı bilgiler:

  • Sunucularımızın çoğu AD alan adımızın bir parçası olsa da, hepsi değildir.
  • Tüm Linux sunucularımızı Kukla ile yönetiyoruz (anahtar kimlik doğrulaması düşündüğüm bir seçimdi, ancak yalnızca yukarıdaki 3 numaralı sorunu ele alacak).
  • Cobbler ile Linux sunucuları sunuyoruz.
  • Donanımımızın yaklaşık% 10'u VMWare'e adanmıştır. Bu durumlarda, sunucu derlemeleri için VMWare şablonlarını kullanırız.

Herhangi bir fikir veya öneri büyük takdir edilecektir. Bu bir süredir devam eden bir problem ve sonunda bunu çözmek istiyorum.

Yanıtlar:


10

Ben olurdu birkaç öneri:

  • Windows AD bağlantılı sunucular, Grup İlkesi Tercihleri'ni (GPP) veya bir bilgisayar başlangıç ​​komut dosyasını kullanarak yerel yönetici parolalarını grup ilkesi aracılığıyla ayarlayabilir. Bkz. Http://social.technet.microsoft.com/Forums/en-US/winserverGP/thread/b1e94909-bb0b-4e10-83a0-cd7812dfe073/

  • Gerekmedikçe Windows sunucularında yerel hesap oluşturmayı sınırlandırın. Mümkün olduğunda AD hesaplarını kullanın.

  • Yönetici hesaplarının AD'de kimliğini doğrulamak için Linux bilgisayar için LDAP kullanın. Bu hesap yönetimini biraz kolaylaştırır. Ve bir yönetici sadece tek bir yerde devre dışı bırakıldığında ve erişim yokken, Linux tarafını boş zamanlarınızda temizleyebilirsiniz.

  • Linux'ta belirli yönetici hesabı için / etc / sudoers dosyasını kullanın, ardından yöneticilerin kök parolaya ihtiyacı yoktur. Bu sizin örneğinizde iyi olabilir, çünkü kilitlenebilmeleri için nadiren kök parolaya ihtiyaç duyarlar. Güncellenmiş

  • Kök ve yerel yönetici parolalarını genel bilgi değil güvenli bir parolada saklayın. Bazı şifre kasalarında yetki verme ve günlük kaydı bulunur, böylece kişi hiç erişim sağlamamışsa bir parolayı sıfırlamanız bile gerekmeyebilir.

  • Kök ve yönetici hesapları için şifre sıfırlama işlemini otomatikleştirin. Hem Linux hem de Windows bunu yapmak için yazılabilir, böylece size biraz zaman kazandırabilir ve çok fazla yük getirmeyebilir.

Umarım yardımcı olur.


LDAP ile ilgili sorunum bir başarısızlık noktası. Kukla ile hesapları yönetmeyi tercih ederim. Ve önerilerinizi takdir edin. Teşekkürler @Bernie!
Belmin Fernandez

1
@Beaming Active Directory kullanıyorsanız, birden fazla Etki Alanı Denetleyiciniz olabilir (tek bir hata noktası olmaz) ve sonra bir LDAP sorgusu için tüm etki alanı denetleyicilerini almak için DNS etki alanı adını (örn. Domain.com) gösterebilirsiniz. Veya ldap.domain.com gibi LDAP'ye yalnızca iki veya üçünün yanıt vermesini istiyorsanız, belirli DC'leri işaret edecek şekilde bir A DNS kaydı oluşturabilirsiniz. Kukla kullanmadım ama kolay kullanıcı yönetiminin anahtarı mümkün olan tek bir kaynak değil. Bu şekilde tercih ederseniz, Kukla'nın bir arka uç LDAP sunucusuna yine de bağlanması muhtemeldir.
Bernie White

AD'nin buraya gitmenin yolu olduğunu kabul etti. 2+ etki alanı denetleyicisiyle, AD'nin tamamen düşme olasılığı zayıftır, ancak aynı zamanda büyük olasılıkla çok daha büyük sorunlarınız vardır. Her şey başarısız olursa, son çare olarak kullanılacak linux sunucularınızda yerel kök hesapları tutun.
EEAA

2
@ Bernie - 3. noktanızla ilgili. Sudo kullanırken hiç kimsenin root şifresini bilmesine gerek yoktur. Bir sudo girişinde "NOPASSWD" belirterek, kullanıcının kendi şifresini girmesine gerek yoktur . Bunun root şifresi ile ilgisi yoktur.
EEAA

@ErikA +1 Çok doğru. Soruyu cevaplamaya yardımcı olmadığı için NOPASSWD referansı kaldırıldı /
Bernie White

2

FreeIPA'nın sizin için işe yarayıp yaramadığını görebilirsiniz .

Ana bilgisayarlara kullanıcı erişimini merkezi bir konumdan yönetebilirsiniz. Diğerleri tarafından önerildiği gibi, sudo'nun sizin için kök düzeyinde erişim için çalışıp çalışmadığını görebilirsiniz. Freeipa, LDAP'deki sudo'ları destekler, böylece her sunucuda veya kukla vb.

Freeipa Linux, Solaris ve Windows istemcilerini destekler. Belirli AD özelliklerini kaybedebilirsiniz ve bir Windows istemcisinin başka hangi kısıtlamalara sahip olacağından emin değilim.

Çoğaltma özelliklerine sahiptir, böylece bir SPOF'dan kaçınabilirsiniz. Arka uç LDAP'dir, bu nedenle yedek komut dosyaları gibi insanların LDAP için kullandığı birçok aracı yeniden kullanabilirsiniz.

Ana bilgisayar tabanlı erişim kontrolünü destekler, böylece "X kullanıcısı sadece Y sunucularına giriş yapabilir" diyebilirsiniz.

Ayrıca AD senkronizasyonu da sunar . Ben bir Windows insanı değilim, bunun ne anlama geldiğini bile bilmiyorum.


1

Standart Yönetici hesabını kullanmayın. Windows tarafında, Yönetici erişimine ihtiyaç duyan her kullanıcı için bir kullanıcı hesabı ve bir Yönetici hesabı oluşturun. UNIX ile senkronize etmek için herhangi bir aracı kullanabilirsiniz.

Birisi ayrılırsa, kullanıcı ve Yönetici hesaplarını silmeniz yeterlidir.

Standart Yönetici hesabını güvence altına almak için, ona gerçekten uzun ve karmaşık bir şifre verin, ardından herhangi bir kişinin sadece yarısına sahip olduğundan emin olun. Hesabın tamamını kullanmaları gerekiyorsa, diğer yarısı olan birini bulmaları gerekir.

Düşündüğüm kadar güvenli.

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.