Jakie jest najlepsze rozwiązanie do zarządzania hasłem roota tysięcy serwerów


12

Jestem administratorem systemu. W środowisku produkcyjnym muszę zarządzać tysiącami serwerów. Ja i moi koledzy korzystamy z centralnego serwera zarządzania i dystrybuujemy jego klucz publiczny przez inne serwery. Możemy więc użyć tego serwera zarządzania do ssh na inne serwery.

Czasami musimy użyć hasła roota, na przykład gdy serwer jest wyłączony, musimy użyć iLO, aby ustalić przyczynę.

Obecnie używamy wspólnego hasła roota. To niebezpieczne. Przyjrzałem się także rozwiązaniu z jednym serwerem, takim jak OPIE(jednorazowe hasła we wszystkim), ale ponieważ mamy tak wiele serwerów, nie jest to zbyt dobry pomysł.

EDYTOWAĆ:

Chcę od rozwiązania do zarządzania hasłami:

  1. Powinno być bezpieczne, więc Hasło jednorazowe to świetne rozwiązanie.
  2. Hasło można łatwo wprowadzić, czasem musimy podłączyć monitor do serwera lub za pomocą iLO, jak wspomniałem powyżej.
  3. Rozwiązanie powinno działać, nawet jeśli serwer jest offline (bez żadnego połączenia sieciowego)

Nie jest więc dobrym pomysłem ustawienie hasła roota na długi i losowy ciąg, chociaż jest on generowany z jakiegoś znanego polecenia (jak openssl passwd). Trudno zapamiętać, a czasem trudno jest wygenerować (bez mojego laptopa)


1
Czy korzystasz już z systemu zarządzania konfiguracją, takiego jak marionetka? Czego używasz?
Zoredache,

Puppet ++ do tego.
Tom O'Connor,

Używamy
cfengine

Odpowiedzi:


5

Możesz użyć Puppet, aby wypchnąć zmianę hasła na wszystkie swoje serwery. Zdefiniowałbyś rootużywając takiego usertypu :

    user { 'root':
            ensure => present,
            password => '$1$blablah$blahblahblahblah',
    }

Aby wygenerować zaszyfrowane hasło:

openssl passwd -1 -salt "blah"

Proponuję być może zmieniać go co jakiś czas - może używając schematu zapamiętanego przez twoje SA. Możesz również dystrybuować go za pomocą bezpiecznej metody lub umieścić w sejfie.


3

Zawsze możesz po prostu ustawić wyłączone hasło. Uniemożliwiłoby to dostęp do sieci rootowi, a jeśli uruchomisz system w trybie pojedynczego użytkownika, większość dystrybucji uruchomi się bezpośrednio do powłoki.

Prawdopodobnie nie jest to tak duży problem bezpieczeństwa, jak mogłoby się wydawać. W każdym razie omijanie hasła roota jest banalne, chyba że zablokowałeś grub za pomocą hasła, prawie każdy może po prostu powiedzieć grub, aby zaczął bash zamiast initrd.

Oczywiście może to oznaczać, że zamiast tego zastanawiasz się, jak zabezpieczyć program ładujący hasłem.


0

Możesz użyć hasła jednorazowego z centralnym zarządzaniem. Wiem, że to nie pasuje do „musi działać, gdy eth jest offline, a serwer uzyskuje dostęp za pomocą iLO”.

W każdym razie: pytanie brzmi, jak często serwer jest offline.

Możesz pomyśleć o następującej konfiguracji:

Skorzystaj z centralnie zarządzanego rozwiązania OTP, takiego jak privacyidea ( http://www.privacyidea.org ). Użytkownikowi root można przypisać kilka różnych tokenów OTP. Każdy token ma inny kod PIN OTP i jest innym urządzeniem. W ten sposób wszyscy twoi koledzy mogą zalogować się jako root użytkownika, ale w dzienniku kontroli zobaczysz, który token został uwierzytelniony, dzięki czemu będziesz wiedział, który kolega zalogował się w danym momencie.

Na serwerach musisz skonfigurować pam_radius, aby przekazywał żądanie uwierzytelnienia do RADIUS i privacyIDEA.

Porażka. Teraz twój serwer przechodzi w tryb offline. W takim przypadku powinieneś zagrać ze stosem pam. Mógłbym wymyślić coś takiego:

auth sufficient pam_unix.so
auth required pam_radius.so use_first_pass

Abyś mógł zalogować się przy użyciu ustalonego hasła offline, w przeciwnym razie hasło zostanie przekazane pam_radius i zostanie sprawdzone jako OTP przeciwko privacyIDEA.

Zobacz to https://www.howtoforge.com/manage-two-factor-authentication-in-your-serverfarm-with-privacyidea .

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.