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.