Trzy telefony, router i jedna kontrola monitoringu wciąż trzymają stare hasło, a jedno z nich łączy się ponownie co dziewięćdziesiąt sekund. Hasło konta zmieniło się dziesięć minut temu, więc każdy z tych klientów wysyła teraz wartość, którą serwer odrzuca. To moment, w którym mit pęka: zmiana hasła dotyczy konta, a nie kopii starej wartości na każdym urządzeniu. To, co następuje, to praca, której zmiana nie wykonała.

Mit: jedna zmiana, wszędzie naraz

Panuje przekonanie, że zmiana hasła wylogowuje wszystko i wymusza czyste nowe logowanie. Tak nie jest, bo serwer śledzi tylko to, które dane logowania przyjął ostatnio, podczas gdy klienci trzymają to, co zapisali. Urządzenie z zapisanym hasłem ponawia je według własnego harmonogramu i po cichu zawodzi, dopóki ktoś nie zauważy, że konto jest zablokowane. Gdy przyjmie się, że kopie żyją poza kontem, rotacja przestaje wyglądać jak jedna czynność.

Nic z tego nie przemawia przeciw rotacji. Przemawia za traktowaniem zapisanych kopii jako części zmiany, a nie jako myśli po fakcie. Blokada zwykle bierze się z równoległych ponowień: każde urządzenie dalej wysyła starą wartość według własnego harmonogramu, aż zadziała licznik. Konto wygląda wtedy na atakowane, choć podaje mu się tylko dane logowania, których nikt nie zastąpił. Ta różnica ma znaczenie, bo rozwiązaniem jest lista urządzeń, a nie surowsza polityka blokad.

Spisz kopie przed rotacją

Napisz inwentarz, zanim otworzysz formularz hasła. Wymień każdego klienta, skrypt, automatyzację i profil zarządzany, który uwierzytelnia się jako to konto: telefon, który łączy się sam, router skonfigurowany dwa lata temu, laptop, który budzi się tylko w poniedziałki, i kontrolę monitoringu, która próbuje co minutę. Dla każdego zapisz, gdzie przechowywane są dane logowania, czy urządzenie jest osiągalne podczas zmiany i jaka ścieżka odzyskiwania istnieje, jeśli nie może się ponownie połączyć. Ta lista zmienia ryzykowną zmianę w zaplanowaną i musi istnieć, zanim stare hasło przestanie działać.

Urządzenia offline to klasyczne przeoczenie. Laptop w szufladzie wraca trzy tygodnie później i przedstawia nieaktualną wartość w najgorszym momencie. Zapisz też jego lokalizację i harmonogram, bo będziesz musiał go gonić, a nie czekać na niego.

W flocie Linuksa wyszukiwanie jest mechaniczne, a nie sprytne. Szukaj profili, które odwołują się do pliku danych logowania, a potem samych plików danych logowania, bo to druga lista wymaga przepisania. Powtórz ćwiczenie dla klientów stacjonarnych i telefonów, gdzie magazynem jest profil lub wpis w pęku kluczy, a nie ścieżka. Celem jest lista, przez którą można przejść, a nie skan, który twierdzi, że znajduje każdą kopię.

grep -rl auth-user-pass /etc/openvpn /etc/NetworkManager
grep -rl auth-user-pass ~/.config 2>/dev/null

Zestaw kopie z ludźmi, którzy je posiadają. Urządzenie, którego nikt nie zgłasza, to urządzenie, którego nikt nie zaktualizuje, i właśnie ono najprawdopodobniej będzie dalej ponawiać.

Który sekret tak naprawdę rotujesz

Hasło konta to tylko jedne dane logowania we wdrożeniu VPN. Fraza hasła klucza, tożsamość certyfikatu i opcjonalny sekret partnera mają własną ścieżkę wymiany i własnego właściciela. Zmiana hasła konta nic nie daje urządzeniu, które uwierzytelnia się certyfikatem, a ponowne wydanie certyfikatu nic nie daje klientowi z zapisanym hasłem. Nazwij sekret, zanim nazwiesz rozwiązanie.

Jeśli rotacją kieruje podejrzenie, a nie polityka, proces incydentu ma pierwszeństwo przed planem wygody. Unieważnij to, czego wymagają dowody, i zaakceptuj dodatkową pracę na liście urządzeń. Ta decyzja należy do właściciela incydentu, a nie do tego, kto akurat trzyma formularz resetowania hasła.

Zastąp zapisaną wartość tam, gdzie żyje

Zmień dane logowania mechanizmem, który dokumentuje usługa, następnie zaktualizuj zapisaną kopię lub wykonaj przepływ logowania na każdym urządzeniu, które chcesz zachować. Nie edytuj wygenerowanej konfiguracji za menedżerem, który ją przepisuje, bo menedżer przywraca starszą wartość przy następnym uruchomieniu, a edycja staje się opóźnioną awarią. Zaktualizuj źródło, które czyta menedżer, albo użyj własnego magazynu danych logowania klienta. Tak czy inaczej, urządzenie musi skończyć z nową wartością w miejscu, które klient naprawdę czyta.

Klient, który przechowuje plik hasła, potrzebuje przepisanego pliku, natomiast klient, który pyta, potrzebuje ukończonego logowania. NetworkManager trzyma sekret w profilu połączenia, więc zmiana przechodzi przez nmcli, a nie przez edytor tekstu:

nmcli connection modify work vpn.secrets "password=NEW"
nmcli connection up work

Profil, który czyta plik danych logowania, to trzeci przypadek. Zastąp zawartość tego pliku, pozostaw jego uprawnienia zamknięte i przeładuj klienta zamiast edytować profil, który na niego wskazuje. Profil się nie zmienił; zmienił się tylko sekret, który czyta.

Połącz ponownie każde zamierzone urządzenie raz, świadomie, i obserwuj, które zawiodą. Jeśli urządzenie wciąż zawodzi, sprawdź konto, na które wskazuje, i magazyn, który czyta, zanim ponownie zmienisz hasło, bo druga zmiana mnoży kopie do aktualizacji. Urządzenie, które zawodzi dwa razy, zwykle wskazuje na niewłaściwe konto albo czyta magazyn, którego jeszcze nie znalazłeś. Napraw to, a potem połącz ponownie.

Sesje i tokeny przeżywają hasło

Zmiana hasła nie dowodzi, że istniejące sesje lub osobne certyfikaty zostały unieważnione. Niektóre usługi utrzymują sesję żywą, aż wygaśnie albo zostanie wyraźnie zakończona, a wydane tokeny mają własny czas życia. Sprawdź, co usługa naprawdę robi, zamiast zakładać, że zmiana była globalna. Jeśli zmiana była podyktowana podejrzeniem, zakończ sesje wyraźnie i potwierdź wynik.

Wytyczne dotyczące cyklu życia danych logowania w NIST SP 800-63B trzymają uwierzytelnianie i sesje w osobnych kategoriach, dlatego zmiana hasła i globalne wylogowanie to różne operacje. Traktuj je jako dwa zadania z dwoma kryteriami ukończenia. Pierwsze kończy się, gdy nowa wartość działa, a drugie, gdy starych sesji nie ma.

Zapisz ukończenie, nie wpisując nowego hasła do rejestru. Dziennik rotacji zawierający dane logowania to nowy incydent czekający na wspólnym dysku. Zapisz datę, zaktualizowane urządzenia i urządzenia wciąż oczekujące.

Powiązane artykuły