Jakie są najlepsze praktyki zarządzania kluczami SSH w zespole?

Pracuję z małymi zespołami (<10) programistów i administratorów o następujących cechach:

• Większość członków zespołu ma> 1 komputer osobisty, z których większość jest przenośna
• Członkowie zespołu mają dostęp do 10–50 serwerów, zwykle z sudo

Myślę, że jest to dość typowe dla większości startupów oraz małych i średnich korporacyjnych grup IT.

Jakie są najlepsze praktyki zarządzania kluczami SSH w takim zespole?

Czy powinieneś udostępnić jeden klucz dla całego zespołu?

Czy każda osoba powinna mieć swój własny klucz na wspólnym koncie („ubuntu” na każdym serwerze)?

Oddzielne konta?

Czy każdy członek zespołu powinien przechowywać osobny klucz dla każdego laptopa lub komputera stacjonarnego?

W mojej firmie używamy LDAP, aby mieć spójny zestaw kont na wszystkich komputerach, a następnie używamy narzędzia do zarządzania konfiguracją (w naszym przypadku obecnie cfengine) do dystrybucji authorized_keysplików dla każdego użytkownika na wszystkich serwerach. Same pliki kluczy są przechowywane (wraz z innymi informacjami o konfiguracji systemu) w repozytorium git, abyśmy mogli zobaczyć, kiedy klucze przychodzą i odchodzą. cfengine dystrybuuje również sudoersplik, który kontroluje, kto ma dostęp do uruchamiania tego, co root, na każdym hoście, używając użytkowników i grup z katalogu LDAP.

Uwierzytelnianie za pomocą hasła jest całkowicie wyłączone na naszych serwerach produkcyjnych, więc autoryzacja klucza SSH jest obowiązkowa. Zasady zachęcają do używania osobnego klucza dla każdego laptopa / komputera stacjonarnego / czegokolwiek i używania hasła na wszystkich kluczach, aby zmniejszyć wpływ zgubionego / skradzionego laptopa.

Mamy również host bastionowy, który służy do uzyskiwania dostępu do hostów w sieci produkcyjnej, co pozwala nam na stosowanie bardzo restrykcyjnych reguł zapory w tej sieci. Większość inżynierów ma specjalną konfigurację SSH, aby ta przejrzystość:

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

Dodanie nowego klucza lub usunięcie starego wymaga nieco ceremonii w tej konfiguracji. Twierdzę, że dla dodania nowego klucza pożądane jest, aby była to operacja, która pozostawia ślad audytu i jest widoczna dla wszystkich. Jednak ze względu na związane z tym koszty ogólne myślę, że ludzie czasami zaniedbują usunięcie starego klucza, gdy nie jest on już potrzebny, i nie mamy prawdziwego sposobu, aby go wyśledzić, z wyjątkiem wyczyszczenia, gdy pracownik opuszcza firmę. Powoduje to również dodatkowe tarcie podczas dołączania nowego inżyniera, ponieważ muszą oni wygenerować nowy klucz i wypchnąć go na wszystkie hosty, zanim będą w pełni produktywni.

Jednak największą zaletą jest osobna nazwa użytkownika dla każdego użytkownika, co ułatwia bardziej szczegółową kontrolę dostępu, gdy jest to potrzebne, i zapewnia każdemu użytkownikowi tożsamość, która pojawia się w dziennikach kontroli, co może być bardzo przydatne podczas próby śledzenia problem z produkcją wraca do akcji sysadmin.

W tej konfiguracji kłopotliwe jest posiadanie zautomatyzowanych systemów, które podejmują działania przeciwko hostom produkcyjnym, ponieważ ich „dobrze znane” klucze SSH mogą służyć jako alternatywna ścieżka dostępu. Do tej pory właśnie utworzyliśmy konta użytkowników dla tych zautomatyzowanych systemów, które mają tylko minimalny dostęp do potrzebnych im zadań i przyjęliśmy, że złośliwy użytkownik (który musi być już inżynierem z dostępem produkcyjnym) może również wykonywać te same czynności częściowo, anonimowo za pomocą klucza aplikacji.

Osobiście podoba mi się pomysł, aby każdy członek personelu miał jeden klucz na dedykowanej maszynie bastionowej ssh, na której ma podstawowe konto użytkownika. To konto użytkownika ma 1 klucz ssh, który zapewnia dostęp do wszystkich serwerów, których potrzebują. (te inne serwery powinny być również wyłączone firewallem, aby umożliwić dostęp tylko ssh z maszyny bastionowej)

Następnie na maszynach do codziennej pracy, laptopach, tabletach itp. Mogą samodzielnie wybrać jeden klucz lub kilka kluczy.

Jako administrator systemu w tej sieci masz minimalną liczbę kluczy do opieki (jeden na programistę), możesz łatwo monitorować dostęp do ssh przez sieć (ponieważ wszystkie trasy prowadzą przez maszynę bastionową) i jeśli programista chce wielu kluczy lub po prostu jeden, który współużytkują między swoimi komputerami, to nie jest prawdziwy problem, ponieważ masz tylko jeden komputer do aktualizacji. (chyba że klucze ssh bastionów zostaną naruszone, jednak jest to znacznie mniej prawdopodobne niż jeden z kluczy użytkowników)

Miałem sytuację, w której musiałem zapewnić dostęp do klucza SSH zespołowi 40 programistów do ~ 120 zdalnych serwerów klientów.

Kontrolowałem dostęp, zmuszając programistów do łączenia się za pośrednictwem jednego „hosta skoku”. Z tego hosta wygenerowałem klucze prywatne / publiczne i wypchnąłem je na serwery klientów. Jeśli programiści potrzebowali dostępu z laptopa, mogliby użyć tej samej pary kluczy w swoim systemie lokalnym.

Osobiście wybrałbym dla każdego użytkownika, a wtedy masz od razu odpowiedzialność i znacznie łatwiej ustawiasz ograniczenia - nie wiem, co myślą inni ludzie?

Jedną z metod, o której słyszałem, ale której sam nie używałem, jest posiadanie przez każdego użytkownika pakietu (np. .Deb, .rpm), który zawiera konfigurację klucza publicznego ssh, a także dowolne pliki dot, które lubią dostosowywać (.bashrc , .profile, .vimrc itp.). Jest to podpisane i przechowywane w repozytorium firmy. Ten pakiet może być również odpowiedzialny za utworzenie konta użytkownika lub może uzupełniać coś innego, tworząc konto (cfengine / puppet itp.) Lub centralny system uwierzytelniania, taki jak LDAP.

Pakiety te są następnie instalowane na hostach za pomocą dowolnego mechanizmu (cfengine / puppet itp., Zadanie crona). Jednym z podejść jest posiadanie metapakietu, który jest zależny od pakietów na użytkownika.

Jeśli chcesz usunąć klucz publiczny, ale nie użytkownika, pakiet dla użytkownika zostanie zaktualizowany. Jeśli chcesz usunąć użytkownika, usuń pakiet.

Jeśli masz heterogeniczne systemy i musisz utrzymywać zarówno pliki .rpm, jak i .deb, to widzę, że jest to trochę denerwujące, chociaż narzędzia takie jak obcy mogą to nieco ułatwić.

Jak mówię, sam tego nie zrobiłem. Zaletą tego podejścia jest to, że uzupełnia on centralny system LDAP i centralne zarządzanie kontami użytkowników, ponieważ pozwala użytkownikowi na łatwą aktualizację pakietu, aby na przykład zawierał plik .vimrc, bez konieczności zarządzania tym plikiem za pomocą narzędzi takich jak marionetka, do których użytkownik może nie mieć dostępu.

Powinieneś wybrać bezpieczniejszą trasę i zmusić każdego użytkownika do posiadania oddzielnych kluczy, i prawdopodobnie dla każdego urządzenia.

Jeśli masz klucze współdzielone między użytkownikami --- nawet jeśli jesteś małym zespołem - odwołanie klucza jest niedogodnością dla wszystkich innych.

Jeśli zezwolisz swoim pracownikom na posiadanie jednego klucza dla wszystkich swoich urządzeń, mogą oni wybrać i wybrać serwery, z którymi mogą się połączyć z tym urządzeniem. Na przykład laptop przenośny może być ograniczony do jednego lub dwóch serwerów, ale komputer stacjonarny w biurze może mieć dostęp do wszystkich serwerów.

Kilka lat temu Envy Labs napisał narzędzie o nazwie Keymaster (we współpracy z klientem Gatekeeper) do obsługi czegoś takiego dla zespołów programistycznych.

Projekt nie cieszył się dużym zainteresowaniem w ciągu ostatnich dwóch lat, ale prawdopodobnie jest to coś, z czym możesz majstrować, a może przywrócić do życia?

Repozytorium jest dostępne w github: https://github.com/envylabs/keymaster

Podejściem może być skonfigurowanie serwera NIS z udziałem / home przez NFS. To w połączeniu z sudo na serwerach i pozwalanie tylko użytkownikom, którzy chcą na każdym serwerze za pomocą konfiguracji ssh.

W ten sposób każdy członek zespołu używa tylko jednego użytkownika i jego klucza, aby uzyskać dostęp do wszystkich serwerów. Sudo i jedno hasło do zadań administracyjnych.

Pozdrowienia,

Rafael