Menedżer haseł dla firmy, nie dla siebie

Menedżer haseł dla siebie to prosta sprawa: instalujesz, wrzucasz hasła, zapamiętujesz jedno główne. Menedżer haseł dla firmy to zupełnie inne zadanie, bo dochodzi warstwa, której w wersji prywatnej w ogóle nie ma -współdzielenie sekretów między ludźmi, którzy przychodzą i odchodzą.

I właśnie na tej warstwie większość wdrożeń się wykłada. Nie na sile hasła, nie na algorytmie, tylko na banalnym pytaniu: kto ma dostęp do hasła administratora routera i co się stanie, gdy ta osoba przestanie u Ciebie pracować.

Test, który przechodzi mniej firm, niż myślisz

Zanim wybierzesz narzędzie, odpowiedz uczciwie na trzy pytania:

• Odchodzi dziś Twój najbardziej doświadczony człowiek od IT. Ile haseł znika razem z nim?
• Potrzebujesz o 23:00 dostępu do panelu rejestratora domen, bo wygasa certyfikat. Wiesz, gdzie jest to hasło?
• Ktoś prosi o dostęp do systemu księgowego na dwa tygodnie zastępstwa. Umiesz go potem odebrać?

Jeśli przy którymkolwiek pytaniu odpowiedź brzmi „trzeba by zapytać Marka”, problemem nie są hasła. Problemem jest to, że firmowe sekrety mieszkają w cudzej głowie, w cudzym Keepassie na cudzym laptopie albo w mailu sprzed trzech lat.

Prywatny menedżer chroni Cię przed atakującym. Firmowy menedżer chroni firmę przed utratą dostępu - i to jest najczęstszy realny scenariusz, dużo częstszy niż włamanie.

Czego prywatny menedżer nie robi

Wersja darmowa czy osobista to dobre narzędzie, ale brakuje jej czterech rzeczy, bez których nie da się prowadzić firmy:

• Skarbce zespołowe - hasła należą do organizacji i do roli, nie do konta prywatnego pracownika.
• Role i uprawnienia - księgowa nie musi widzieć haseł do infrastruktury, a technik nie musi widzieć dostępu do banku.
• Log dostępu - kto, kiedy i do którego wpisu zaglądał. Bez tego po incydencie nie odtworzysz niczego.
• Odbieranie dostępu - jedno kliknięcie odcinające całe konto, a nie proszenie o „usunięcie pliku”.

Zero-knowledge, czyli co dostawca naprawdę widzi

Wszystkie poważne menedżery działają w modelu zero-knowledge i warto rozumieć, co to oznacza w praktyce, bo to jedyny powód, dla którego trzymanie haseł w cudzej chmurze ma sens.

Twoje hasło główne nigdy nie trafia na serwer dostawcy. Lokalnie, na Twoim urządzeniu, przechodzi przez funkcję wyprowadzania klucza (KDF - Argon2id lub PBKDF2 z dużą liczbą iteracji) i dopiero powstały z niego klucz szyfruje skarbiec. Do dostawcy trafia wyłącznie zaszyfrowana paczka.

hasło główne  ->  KDF (Argon2id)  ->  klucz szyfrujący  ->  skarbiec
                                        (zostaje u Ciebie)
serwer dostawcy widzi:  zaszyfrowany blob + metadane

Konsekwencja jest dwustronna. Dobra: wyciek u dostawcy nie oddaje atakującemu Twoich haseł od razu - musi jeszcze złamać hasło główne offline. Zła: jeśli zapomnisz hasła głównego, nikt Ci go nie odzyska. Dlatego hasło główne jest jedynym, które musisz umieć wystukać z pamięci - i idealnym kandydatem na frazę Diceware z siedmiu słów. O tym, ile to realnie znaczy, pisaliśmy przy okazji entropii.

Chmura czy własny serwer

To pierwsza decyzja architektoniczna i nie ma tu jednej dobrej odpowiedzi - jest wybór, za co wolisz odpowiadać.

Rozwiązanie chmurowe (Bitwarden, 1Password, Keeper i podobne) daje dostępność, synchronizację, aplikacje mobilne i zespół, który łata podatności za Ciebie. Płacisz abonament i akceptujesz, że zaszyfrowane dane leżą u dostawcy.

Rozwiązanie self-hosted (Vaultwarden, Passbolt) trzyma dane na Twoim serwerze. Brzmi bezpieczniej i bywa tańsze, ale przenosi na Ciebie całą odpowiedzialność operacyjną: aktualizacje, certyfikat, kopie zapasowe, dostępność. Kontener, o którym wszyscy zapomną na pół roku, jest gorszy niż chmura - a jeśli padnie razem z serwerem, na którym stoi, tracisz hasła dokładnie wtedy, gdy są najbardziej potrzebne.

Reguła kciuka: self-hosted ma sens tylko wtedy, gdy masz kogoś, kto realnie pilnuje aktualizacji i sprawdza kopie zapasowe. W przeciwnym razie chmura jest bezpieczniejsza - nie teoretycznie, tylko praktycznie.

W obu wariantach obowiązuje ta sama zasada: kopia zapasowa skarbca to osobny temat i nie zastępuje jej „przecież jest w chmurze”. Regularny eksport w zaszyfrowanej formie, przechowywany poza systemem - dokładnie w duchu tego, o czym pisaliśmy przy backupie, który naprawdę działa.

Jak ułożyć skarbce, żeby to działało

Najczęstszy błąd we wdrożeniu to jeden wielki skarbiec „Firma”, do którego mają dostęp wszyscy. Po pół roku nikt nie wie, co tam jest, a każdy nowy pracownik dostaje komplet kluczy do królestwa.

Działający układ jest prosty i opiera się na trzech poziomach:

• Skarbiec osobisty - konta imienne pracownika, do których nikt inny nie potrzebuje dostępu.
• Skarbce działowe - osobno księgowość, osobno handel, osobno infrastruktura. Dostęp przypisany do roli, nie do osoby.
• Skarbiec krytyczny - domeny, konta root, dostęp do bankowości, klucze do backupu. Maksymalnie dwie-trzy osoby, log dostępu włączony.

Do tego jedna twarda zasada: konta imienne wszędzie, gdzie system na to pozwala. Współdzielone hasło do panelu jest ostatecznością, a nie domyślnym rozwiązaniem - przy koncie imiennym odebranie dostępu jest natychmiastowe i nie wymaga zmiany hasła u pięciu osób naraz.

Offboarding, czyli moment prawdy

Tu trzeba powiedzieć rzecz, którą sprzedawcy menedżerów pomijają: odcięcie pracownika od menedżera nie unieważnia haseł, które już widział. Jeśli przez rok zaglądał do hasła administratora firewalla, to hasło jest w jego głowie albo w jego notatkach - niezależnie od tego, jak szybko zablokujesz konto.

Dlatego offboarding ma dwa kroki, nie jeden:

• Natychmiast: zablokuj konto w menedżerze, unieważnij aktywne sesje, wyrejestruj jego klucze i urządzenia.
• W ciągu doby: zrotuj hasła do wszystkiego, do czego miał dostęp w skarbcu krytycznym. Log dostępu powie Ci dokładnie, co to było - jeśli go włączyłeś.

Ten drugi krok jest tym, co odróżnia wdrożenie na papierze od wdrożenia, które działa.

Break-glass, czyli co gdy zabraknie właściciela

Scenariusz, o którym nikt nie lubi myśleć: osoba trzymająca dostęp do konta administracyjnego menedżera trafia do szpitala albo po prostu przestaje odbierać telefon. Bez przygotowania firma zostaje odcięta od własnych systemów.

Zabezpieczenie jest niskotechnologiczne i dlatego skuteczne: hasło główne konta administracyjnego plus kody odzyskiwania, wydrukowane, w zaklejonej kopercie, w sejfie, z zapisaną datą i informacją, kto ma prawo ją otworzyć. Wiele menedżerów oferuje też funkcję awaryjnego dostępu z opóźnieniem czasowym - warto ją skonfigurować, ale koperta i tak powinna istnieć.

Wdrożenie w małej firmie - realna kolejność

• Inwentaryzacja. Wypisz, jakie konta w ogóle istnieją: domeny, hosting, poczta, bank, sieć, systemy branżowe. Ten etap zwykle jest najbardziej pouczający.
• Wybór narzędzia i struktura skarbców według trzech poziomów opisanych wyżej.
• Hasło główne i drugi składnik dla każdego konta - fraza Diceware plus klucz sprzętowy albo aplikacja TOTP.
• Migracja z rotacją. Nie przenoś starych haseł jeden do jednego - przy okazji wygeneruj nowe w generatorze, a te, które gdzieś krążyły, sprawdź w sprawdzarce wycieków.
• Koperta break-glass do sejfu.
• Krótkie szkolenie - 20 minut wystarczy. Bez tego ludzie wrócą do arkusza w chmurze.
• Przegląd co kwartał: kto ma jaki dostęp, co jest nieużywane, co wymaga rotacji.

Kontekst regulacyjny

Jeśli Twoja firma podlega pod NIS2, kontrola dostępu i uwierzytelnianie są wprost wymienione wśród środków zarządzania ryzykiem. Menedżer haseł z rolami i logiem dostępu jest tu najprostszą drogą do pokazania, że dostęp jest kontrolowany i rozliczalny - a przy audycie „mamy to opanowane” bez dowodów nie znaczy nic.

Ale nawet bez żadnej regulacji argument jest ten sam co zawsze: firma powinna mieć dostęp do własnych systemów niezależnie od tego, kto akurat w niej pracuje. Menedżer haseł jest najtańszym narzędziem, jakie to zapewnia. Jeśli chcesz przejrzeć, jak Wasze dostępy wyglądają dziś, to dokładnie ten obszar sprawdzamy w ramach audytu IT.