Ostatni dzień współpracy

Firma kończy współpracę z wykonawcą, który przez trzy lata prowadził jej sklep internetowy. Rozstają się w zgodzie. Szef chce tylko mieć pewność, że od poniedziałku wykonawca nie ma dostępu do niczego, i prosi księgową, żeby zebrała wszystkie hasła.

Hasło do panelu sklepu księgowa znajduje w starym mailu, który dostali też wykonawca i dwie osoby, które dawno odeszły z firmy. Hasło do serwera jest w arkuszu „dostępy” na wspólnym dysku, obok kilkunastu innych, z których część jest nieaktualna, tylko nikt nie pamięta która. Nowy wykonawca zagląda do kodu sklepu i mówi, że hasło do bazy danych jest wpisane wprost w kod. Zna je więc każdy, kto kiedykolwiek miał kopię tego kodu.

Przy okazji wychodzi jeszcze jedna rzecz. Księgowa przed urlopem podała swoje hasło koledze, żeby mógł zatwierdzać faktury, i w historii wszystkie te zatwierdzenia są na jej nazwisko.

Na koniec ktoś pyta, co przestanie działać, jeśli zmienią hasło do bazy. Nikt nie umie odpowiedzieć, więc hasła zostają bez zmian.

Co zostaje po takim dniu

Dostęp do systemów ma dalej ktoś, kto z firmą już nie pracuje. Nie musi mieć złych zamiarów. Wystarczy, że jego skrzynka pocztowa albo stary laptop z zapisanymi hasłami trafi w niepowołane ręce.

Hasło wpisane w kod wycieka razem z każdą kopią kodu. Wiele firm ma też wersję testową, na której wykonawca sprawdza zmiany, zanim trafią do systemu, na którym pracują ludzie. Jeśli obie wersje mają to samo hasło, wyciek z testu otwiera też prawdziwe dane. A gdy zmiana hasła wydaje się ryzykowna, w praktyce nikt jej nie robi.

Jak powinno być

Hasła nie leżą w kodzie, w mailu, w arkuszu ani na kartce pod monitorem. Są w jednym miejscu, przeznaczonym do ich przechowywania.

Każdy ma własny dostęp. Zamiast jednego hasła do panelu, które zna pięć osób, każda osoba ma swoje konto. Programy, które łączą się z innymi systemami, też mają własne konta. Nie korzystają z hasła któregoś z pracowników.

Gdy odchodzi pracownik albo wykonawca, odbiera się jego dostęp, a hasła, które znał, się zmienia.

Wersja testowa i system, na którym pracuje firma, mają osobne hasła. Test jest zwykle słabiej chroniony, bo zagląda do niego więcej osób i programów, na przykład testy uruchamiane automatycznie. Wyciek hasła z testu nie powinien otwierać prawdziwego systemu. Jak jeszcze oddzielić test od prawdziwych danych, piszemy w artykule Testy na prawdziwych klientach.

Na urlop nikt nie pożycza hasła. Dobrze zbudowana aplikacja pozwala wskazać zastępcę na określony czas, a historia pokazuje potem, że zmiany zrobił zastępca w czyimś imieniu. O tym, co jeszcze powinna pokazywać historia zmian, piszemy w artykule „Kto to zmienił?”. Jeśli aplikacja firmy tego nie umie, warto to zgłosić wykonawcy jako brak, zamiast obchodzić go pożyczonym hasłem.

Tak to ustawiamy na serwerach, które przygotowujemy: hasła leżą poza kodem, w jednym miejscu, a wersja testowa i prawdziwy system mają osobne hasła. Na serwery logujemy się kluczem, a logowanie hasłem jest wyłączone. Klucz to plik zapisany na komputerze osoby, która się loguje. Nie da się go odgadnąć ani podejrzeć przez ramię. Konto, z którego wdrażamy nowe wersje, nie ma uprawnień administratora. W aplikacjach, które budujemy, każdy ma własne konto, a zastępstwo na czas urlopu ustawiamy wtedy, gdy firma go potrzebuje.

Sejf na hasła

Do przechowywania haseł służy sejf na hasła, fachowo nazywany menedżerem sekretów. To program, który działa w chmurze albo na serwerach firmy.

Dostęp do każdego hasła nadaje się w nim osobno każdej osobie i każdej aplikacji. Sejf prowadzi dziennik, kto i kiedy sięgnął po dane hasło. Hasło wymienia się w jednym miejscu, zamiast w dziesięciu. Gdy odchodzi jedna osoba, odbiera się dostęp tylko jej. Z dziennika wiadomo, po które hasła sięgała, więc zmienia się tylko te.

Zaszyfrowany plik czy sejf?

Bardzo mała firma z kilkoma kontami może zacząć od zaszyfrowanego pliku z hasłami. Plik nie prowadzi jednak dziennika, więc nie wiadomo, kto po które hasło sięgał. Gdy odchodzi osoba, która znała plik, trzeba zmienić wszystkie hasła, jakie w nim są.

Kiedy systemów i wykonawców przybywa, takie zmiany przestają być do zrobienia ręcznie i wtedy przydaje się sejf. Systemy w chmurze mogą korzystać z sejfu u dostawcy chmury, a te na własnych serwerach z sejfu uruchomionego u siebie.

Póki współpraca trwa

Najlepiej sprawdzić to wtedy, gdy wykonawca jeszcze pracuje z firmą. Wystarczy go zapytać, ile haseł trzeba by zmienić, gdyby jutro przestał, i czy ktoś poza nim wie, gdzie one wszystkie są.