Zarządzanie danymi uwierzytelniającymi serwera w systemach Linux i Windows


12

Jesteśmy stosunkowo małym sklepem (pod względem liczby sysadminów) z mieszanką serwerów RHEL, Solaris, Windows 2003 i Windows 2008; w sumie około 200 serwerów.

W przypadku naszych kont administratora ( rootw systemie Linux i admnistratorWindows) mamy schemat haseł, który zależy od lokalizacji centrum danych i kilku innych udokumentowanych właściwości serwera.

W systemie Linux, nasza obecna praktyka jest utworzenie wspólnego konta nieuprzywijelowanym gdzie mogliśmy susię root. W systemach Windows tworzymy dodatkowe konto z uprawnieniami administratora. Oba te konta mają to samo hasło.

Okazało się to bardzo nieefektywne. Kiedy ktoś opuszcza nasz sklep, musimy:

  1. Zmień schemat haseł dla kont administratora
  2. Wygeneruj nowe hasło administratora dla każdego serwera
  3. Wymyśl nowe hasło do konta innego niż administrator
  4. Dotknij każdego serwera i zmień hasła

Chciałem wiedzieć, czy ktoś w podobnym środowisku może zasugerować bardziej rozsądny sposób zarządzania tymi poświadczeniami. Niektóre istotne informacje:

  • Chociaż większość naszych serwerów należy do naszej domeny AD, nie wszystkie są.
  • Zarządzamy wszystkimi naszymi serwerami Linux z Puppet (uwierzytelnianie klucza było opcją, o której myślałem, ale rozwiąże tylko problem nr 3 z góry).
  • Zaopatrujemy serwery Linux w Cobbler.
  • Około 10% naszego sprzętu jest dedykowane VMWare. W takich przypadkach używamy szablonów VMWare do kompilacji serwerów.

Wszelkie pomysły i sugestie będą mile widziane. Jest to problem, który utrzymuje się od dłuższego czasu i w końcu chcę go rozwiązać.

Odpowiedzi:


10

Oto kilka sugestii:

  • Serwery podłączone do systemu Windows AD mogą mieć ustawione hasła administratora lokalnego za pomocą zasad grupy za pomocą Preferencji zasad grupy (GPP) lub skryptu uruchamiania komputera. Zobacz http://social.technet.microsoft.com/Forums/en-US/winserverGP/thread/b1e94909-bb0b-4e10-83a0-cd7812dfe073/

  • Ogranicz tworzenie lokalnych kont na serwerach Windows, chyba że jest to wymagane. Jeśli to możliwe, używaj kont AD.

  • Użyj LDAP dla komputera z systemem Linux, aby uwierzytelnić konta administratora w AD. Upraszcza to nieco zarządzanie kontem. A kiedy administrator zostawił po prostu wyłącz w jednym miejscu i nie ma dostępu, możesz w dowolnym momencie oczyścić Linuksa.

  • Użyj pliku / etc / sudoers dla konkretnego konta administratora w systemie Linux, wtedy administratorzy nie potrzebują hasła roota. Może to być dobre w twoim przypadku, ponieważ wtedy rzadko potrzebują hasła roota, aby można je było zablokować. Zaktualizowano

  • Przechowuj hasła administratora i administratora lokalnego w bezpiecznym, a nie ogólnym stanie. Niektóre sejfy na hasła mają delegowanie i logowanie, więc może nie być konieczne resetowanie hasła, jeśli dana osoba nigdy nie miała do niego dostępu.

  • Zautomatyzuj proces resetowania hasła dla kont root i admin. Zarówno Linux, jak i Windows mogą być w tym celu napisane w skryptach, dzięki czemu możesz zaoszczędzić trochę czasu i nie obciążać go zbytnio.

Mam nadzieję, że to pomaga.


Mój problem z LDAP to jeden punkt awarii. Wolę zarządzać kontami za pośrednictwem Puppet. I doceniam twoje sugestie. Dziękuję @Bernie!
Belmin Fernandez,

1
@Beaming Jeśli korzystasz z usługi Active Directory, możesz mieć więcej niż jeden kontroler domeny (bez pojedynczego punktu awarii), a następnie wskaż nazwę domeny DNS, np. Domena.com, aby uzyskać wszystkie kontrolery domeny dla zapytania LDAP. Lub możesz skonfigurować rekord DNS, aby wskazywał na określone kontrolery domeny, jeśli chcesz, aby dwa lub trzy odpowiadały na LDAP, np. Ldap.domain.com. Nie korzystałem z Puppet, ale kluczem do łatwego administrowania użytkownikami nie jest jedno źródło tam, gdzie to możliwe. Jest prawdopodobne, że Puppet i tak może połączyć się z wewnętrznym serwerem LDAP, jeśli wolisz w ten sposób.
Bernie White,

Zgodzono się, że AD jest tutaj najlepszym sposobem. Przy ponad 2 kontrolerach domeny prawdopodobieństwo całkowitego upadku AD jest niewielkie, ale jeśli tak, prawdopodobnie masz znacznie większe problemy. Utrzymuj lokalne konta root na swoich serwerach Linux, aby były używane w ostateczności, jeśli wszystko inne zawiedzie.
EEAA

2
@Bernie - odnośnie twojego trzeciego punktu. Podczas korzystania z sudo nikt nigdy nie musi znać hasła roota. Określając „NOPASSWD” we wpisie sudo, użytkownik nie musi wprowadzać własnego hasła. Nie ma to nic wspólnego z hasłem roota.
EEAA

@ErikA +1 Bardzo prawda. Usunięto odniesienie do NOPASSWD, ponieważ nie pomaga odpowiedzieć na pytanie /
Bernie White,

2

Możesz spróbować sprawdzić, czy FreeIPA działa dla Ciebie.

Możesz zarządzać dostępem użytkowników do hostów z centralnej lokalizacji. Jak sugerują inni, możesz sprawdzić, czy sudo działa dla Ciebie w celu uzyskania dostępu na poziomie root. Freeipa obsługuje sudoery w LDAP, więc nie musisz utrzymywać go na każdym serwerze lub przez marionetkę itp.

Freeipa obsługuje klientów Linux, Solaris i Windows. Możesz utracić niektóre funkcje AD i nie jestem pewien, jakie inne ograniczenia będzie miał klient Windows.

Ma funkcje replikacji, dzięki czemu można uniknąć SPOF. Backend to LDAP, więc możesz ponownie użyć wielu narzędzi używanych przez LDAP, takich jak skrypty kopii zapasowej.

Obsługuje kontrolę dostępu opartą na hoście, dzięki czemu można powiedzieć „użytkownik X może zalogować się tylko do serwerów Y”.

Oferuje także synchronizację AD . Nie jestem osobą z Windows, więc nie mam pojęcia, co to w ogóle oznacza.


1

Nie używaj standardowego konta administratora. Po stronie systemu Windows utwórz konto użytkownika i konto administratora dla każdego użytkownika, który potrzebuje dostępu administratora. Możesz użyć dowolnego narzędzia do synchronizacji z UNIX.

Jeśli ktoś odejdzie, wystarczy usunąć jego konto użytkownika i administratora.

Aby zabezpieczyć standardowe konto administratora, podaj mu naprawdę długie i złożone hasło, a następnie upewnij się, że jedna osoba ma tylko połowę. Jeśli muszą korzystać z całego konta, muszą znaleźć kogoś, kto ma drugą połowę.

To jest tak bezpieczne, jak tylko mogę sobie wyobrazić.

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.