Klucze są fajne, dopóki nie zmieni się pracownik
Każdy programista potrzebuje dostępu do niektórych serwerów, proste. Zwykle odbywa się to za pomocą klucza publicznego i prywatnego – każdy pracownik generuje własną parę kluczy publiczny-prywatny. Klucze publiczne każdego programisty są dodawane do pliku authorized_keys na każdym serwerze, do którego powinien mieć dostęp. Co się jednak dzieje, gdy dany deweloper odchodzi z firmy, bo np. znalazł lepszą ofertę pracy na TeamQuest?
W takim przypadku klucze publiczne tego programisty powinny zostać usunięte ze wszystkich serwerów. Ale o tym ktoś musi pamiętać i jest to naprawdę dużo pracy. Co więcej, jeśli zostanie to zrobione ręcznie, istnieje spore ryzyko, że klucz nadal spoczywa zapomniany na jakimś serwerze, więc dostęp do niego pozostaje otwarty.
Alternatywne rozwiązania
Istnieje kilka tak komercyjnych jak i otwartych rozwiązań, które chcą pomóc w rozwiązaniu tego problemu. Podstawową ideą jest to, że w takim programie dodajesz i utrzymujesz klucze i listy dostępu a kiedy usuniesz klucz, program usuwa go ze wszystkich Twoich serwerów. Ale jeśli ktoś uzyska dostęp do tej usługi, może uzyskać dostęp do wszystkich serwerów. A co jeśli utracisz dostęp? W najgorszym przypadku utracisz również dostęp do wszystkich serwerów.
Rozwiązanie: podpisywanie kluczy
Ogólny pomysł jest taki: nadal generujesz parę kluczy publiczny-prywatny dla każdego programisty. Jednak nie przesyłasz kluczy publicznych na swoje serwery. Zamiast tego podpisujesz klucze publiczne generowanym wcześniej tak zwanym kluczem urzędu certyfikacji (CA). To podpisanie po prostu generuje trzeci plik certyfikatu, który zwracasz danemu programiście (czy innemu użytkownikowi serwera) a ten umieszcza go w swoim folderze .ssh.
Na serwerach z kolei wystarczy podać serwerowi klucz publiczny swojego CA, a serwer może wykryć, czy użytkownik ma prawidłowo podpisany certyfikat i zezwalać na dostęp tylko programistom, którzy mają taki podpisany certyfikat. Podpisując certyfikat, możesz określić, jak długo to podpisanie jest ważne. Jeśli więc podpiszesz go z okresem ważności 3 miesiące i deweloper opuści firmę, to nawet jeżeli nikt z tym nic nie zrobi to najdalej po 3 miesiącach na pewno nie będzie miał dostępu do żadnego z serwerów. No tak, ale podpisywać certyfikaty na nowo co 3 miesiące?
Ułatwianie sobie życie, o to zawsze chodzi
Jedną z możliwości jest zautomatyzowanie procesu, na przykład poprzez zbudowanie usługi, w której użytkownik może automatycznie uzyskać podpisany certyfikat, gdy autoryzuje się przy użyciu firmowego adresu e-mail i hasła.
Prostszą alternatywą jest to, że wydajesz certyfikaty, które są dłużej ważne, a jeśli ktoś odejdzie z firmy, możesz cofnąć certyfikat, czyli go unieważnić. Możesz umieścić listę nieważnych certyfikatów na swoich serwerach i nie będą one już akceptować użytkownika. Można to zrobić na przykład z wykorzystaniem cronjob na każdym serwerze, który dzięki temu będzie regularnie pobierał taką black… oj… - denylistę.
Zalety
Takie rozwiązanie to możliwość zarządzania dostępem do swoich serwerów przez SSH w oparciu o role. Wystarczy tylko raz skonfigurować serwery (tj. jakie „role” mają do nich dostęp, np. konkretne grupy deweloperów). Dla każdego nowego dewelopera wystarczy wygenerować podpisany certyfikat, a on natychmiast uzyska dostęp do wszystkich odpowiednich maszyn pasujących do jego roli. A kiedy odchodzi z firmy, można w prosty sposób i natychmiastowo odebrać mu dostęp.
Nawet jeśli zdarzy się niefortunny wypadek (tj. przypadek sklerozy) i programista opuści program bez odebrania mu dostępu, jego certyfikat wygaśnie po pewnym czasie, więc automatycznie utraci dostęp.
