Po co chronić hasło, skoro można z niego zrezygnować?

Problem, który przywykliśmy uważać za normę

Praktycznie każda aplikacja internetowa ma panel administracyjny. A panel administracyjny zazwyczaj ma adres logowania, formularz autoryzacji, nazwę użytkownika i hasło.

Tak bardzo przywykliśmy do tej konstrukcji, że niemal przestaliśmy zadawać sobie pytanie: czy wszystko naprawdę musi działać właśnie w ten sposób?

Gdy masz jedną witrynę, problem nie wydaje się istotny. Tworzysz skomplikowane hasło, włączasz uwierzytelnianie dwuskładnikowe, konfigurujesz limit prób logowania — i gotowe.

Ale co się dzieje, gdy projektów robi się dziesięć, dwadzieścia albo trzydzieści?

W moim przypadku chodzi o ekosystem DigiMeld, który obejmuje ponad trzydzieści niezależnych projektów programistycznych. Każdy ma własną architekturę, logikę serwerową i interfejs administracyjny.

Każdy z nich potrzebuje więc mechanizmu dostępu administracyjnego.

Przez długi czas korzystałem z dość typowego rozwiązania: osobnych danych logowania administratora, skomplikowanych haseł i zapisywania ich w przeglądarce.

To działało.

Ale w pewnym momencie zacząłem się zastanawiać: dlaczego w ogóle muszę przechowywać tyle haseł administracyjnych? Dlaczego muszę chronić nie tylko serwery, lecz także same środki dostępu do nich?

I czy można zrezygnować z tej konieczności?

Doszedłem do wniosku, który później stał się podstawą mojego rozwiązania:

Może warto chronić nie stały punkt logowania, lecz samo prawo do czasowego uzyskania dostępu.

A co, jeśli tradycyjnej strony logowania w ogóle nie będzie?

Postanowiłem zrezygnować w swoich projektach z tradycyjnego modelu uwierzytelniania administratorów.

Nie chodziło tylko o ukrycie formularza logowania.

Nie o zmianę adresu.

Nie o zastąpienie hasła jeszcze bardziej skomplikowanym hasłem.

Chodziło o usunięcie samej potrzeby istnienia stałego logowania za pomocą hasła.

Oczywiście interfejsy administracyjne nie zniknęły. Nadal są niezbędne do zarządzania aplikacjami.

Zmienił się sposób uzyskiwania do nich dostępu.

Teraz, aby zalogować się do paneli administracyjnych podłączonych projektów, nie trzeba wpisywać zapisanej nazwy użytkownika ani hasła.

Zamiast tego korzystam z własnego systemu identyfikacji i zarządzania dostępem — MeldID.

Idea jest dość prosta: dostęp administracyjny jest przyznawany tylko wtedy, gdy rzeczywiście jest potrzebny, konkretnemu użytkownikowi i do konkretnego projektu.

Samo posiadanie konta nie oznacza jeszcze prawa do otwarcia panelu administracyjnego.

To uprawnienie trzeba przyznać osobno.

Dostęp, który nie istniał jeszcze minutę temu

To chyba najciekawsza część całej koncepcji.

W tradycyjnym modelu administrator ma stale dostępne dane logowania. Może z nich korzystać dziś, jutro albo za miesiąc, dopóki pozostają ważne.

Postanowiłem zmienić tę zasadę.

Zamiast stałych danych logowania administratora stosowana jest tymczasowa możliwość rozpoczęcia logowania.

Jest ona tworzona na żądanie za pośrednictwem zaufanego urządzenia mobilnego, zawiera kryptograficznie silny losowy element i ma ograniczony czas ważności.

Jednak samo posiadanie takiego tymczasowego łącza nie oznacza jeszcze uzyskania dostępu.

To kluczowa kwestia.

Załóżmy, że ktoś w jakiś sposób zdobył łącze. W zwykłym systemie, którego bezpieczeństwo opiera się wyłącznie na tajności adresu, taki wyciek mógłby stanowić poważny problem.

W moim modelu łącze pozwala jedynie rozpocząć procedurę potwierdzenia.

Aby ją kontynuować, potrzebna jest osobna zgoda za pośrednictwem zaufanego urządzenia mobilnego z MeldID.

Bez odpowiedniego potwierdzenia sesja administracyjna nie zostanie utworzona.

Dlatego traktuję tymczasowe łącze nie jako zamiennik hasła, lecz jako jeden z elementów procedury przyznawania dostępu.

Wiedzieć, gdzie się zgłosić, i mieć prawo do wejścia to dwie zupełnie różne rzeczy.

Telefon staje się narzędziem do zarządzania dostępem

W tym modelu urządzenie mobilne pełni znacznie ważniejszą rolę niż zwykły generator jednorazowych kodów.

Służy do potwierdzania działań związanych z dostępem administracyjnym.

Gdy chcę otworzyć panel administracyjny, system prosi o potwierdzenie za pośrednictwem MeldID.

Na zaufanym urządzeniu widzę odpowiednie żądanie i potwierdzam działanie.

Dopiero po pomyślnej weryfikacji system pozwala kontynuować procedurę logowania.

Potwierdzenie jest przy tym powiązane z konkretnym działaniem, a nie tylko z faktem odblokowania telefonu.

Biometria mobilna weryfikuje użytkownika lokalnie, a strona serwerowa sprawdza kryptograficzne potwierdzenie zarejestrowanego urządzenia.

Takie podejście pozwala nie polegać wyłącznie na haśle ani na komunikacie, że użytkownik rzekomo potwierdził logowanie.

Pojawia się tu również kolejna zaleta: zaufanymi urządzeniami można zarządzać.

Jeśli urządzenie nie powinno już służyć do potwierdzania dostępu, można odebrać mu status zaufanego.

Od tej chwili przestaje ono być aktywnym środkiem autoryzacji odpowiednich operacji.

Jeden system — wiele niezależnych projektów

Gdy zacząłem opracowywać ten mechanizm, jednym z głównych zadań było zachowanie niezależności każdego projektu.

Nie chciałem łączyć wszystkich paneli administracyjnych w jedną ogromną aplikację.

Każda usługa DigiMeld miała nadal zarządzać własną logiką, ustawieniami, użytkownikami i danymi.

Dlatego rozdzieliłem te dwa zadania.

MeldID odpowiada za identyfikację i przyznawanie dostępu administracyjnego.

Sam projekt odpowiada natomiast za własne funkcje administracyjne i weryfikację aktualnych uprawnień.

Powstał scentralizowany model zarządzania dostępem, bez konieczności centralizowania samych aplikacji.

Ponadto uprawnienia przyznawane są osobno.

Administrator jednego projektu nie uzyskuje automatycznie dostępu do pozostałych tylko dlatego, że ma konto MeldID.

Dla każdego obszaru administracyjnego można określić własną grupę uprawnionych użytkowników.

Uprawnienia zwykłych użytkowników i uprawnienia administratorów są przy tym rozdzielone.

W przypadku ekosystemu złożonego z dziesiątek usług okazało się to szczególnie wygodne.

Dlaczego wolę dostęp tymczasowy od stałego

W systemie świadomie uwzględniłem jeszcze jedną zasadę.

Dostęp administracyjny nie powinien być przyznawany bezterminowo.

Uprawnienie obowiązuje przez ograniczony czas i wygasa niezależnie od tego, czy użytkownik nadal pracuje w przeglądarce.

Aby kontynuować pracę po upływie tego czasu, trzeba ponownie przejść procedurę potwierdzenia.

Dzięki temu jednorazowa autoryzacja nie staje się uprawnieniem obowiązującym bez końca.

Samo ograniczenie czasu jednak nie wystarczy.

Ważna jest też możliwość wcześniejszego odebrania już przyznanego dostępu.

Dlatego MeldID umożliwia centralne cofanie uprawnień administracyjnych.

Po cofnięciu uprawnienia podłączone projekty otrzymują odpowiednie zdarzenie i unieważniają powiązane sesje administracyjne.

W ten sposób zarządzanie dostępem nie kończy się w chwili pomyślnego zalogowania użytkownika.

Możliwość odebrania uprawnień jest dla mnie nie mniej ważna niż możliwość ich przyznania.

System rozproszony musi przy tym uwzględniać opóźnienia w dostarczaniu zdarzeń, czasową niedostępność poszczególnych komponentów i inne okoliczności związane z działaniem systemu. Ograniczony czas ważności sesji stanowi dodatkową granicę.

Co zmieniło się w codziennej pracy?

Przede wszystkim zniknęła potrzeba ciągłego sięgania po zapisane hasła administracyjne.

Nie muszę już przechowywać w przeglądarce zestawu danych logowania do każdego podłączonego panelu administracyjnego.

Zamiast tego zarządzam uprawnieniami za pomocą jednego mechanizmu.

Wybieram potrzebny projekt, potwierdzam dostęp i pracuję.

Gdy dostęp administracyjny przestaje być potrzebny, można go odebrać.

Szczególnie wygodne jest to, że dodanie nowego projektu nie wymaga ponownego projektowania całego systemu uwierzytelniania administratorów.

Wystarczy podłączyć go do istniejącego modelu i określić niezbędne uprawnienia.

Oczywiście nie oznacza to, że zniknęły wszystkie zagrożenia bezpieczeństwa.

Tymczasowe uprawnienia, zaufane urządzenia, sesje serwerowe i centralna infrastruktura również wymagają ochrony.

Nie muszę już jednak rozwiązywać tego samego problemu zarządzania hasłami administracyjnymi osobno dla każdej aplikacji.

I to właśnie był jeden z moich pierwotnych celów.

Czy podobne technologie już nie istnieją?

Oczywiście, że istnieją.

Uwierzytelnianie bezhasłowe, zarządzanie dostępem uprzywilejowanym, tymczasowe uprawnienia i potwierdzanie za pośrednictwem zaufanych urządzeń są od dawna znane w branży bezpieczeństwa informacji.

Takie podejścia można znaleźć w systemach Identity and Access Management, Privileged Access Management oraz w koncepcjach Zero Trust.

Nie twierdzę, że wymyśliłem te zasady.

Moje zadanie było inne.

Potrzebowałem stworzyć własny, zintegrowany system, który rozwiązywałby konkretne problemy infrastruktury DigiMeld i pozwalał zarządzać dostępem administracyjnym do wielu niezależnych projektów.

W rezultacie połączyłem kilka znanych podejść w jedną architekturę odpowiadającą moim wymaganiom.

Uważam, że wartość pracy inżynierskiej niekoniecznie polega na wymyślaniu zupełnie nowej technologii.

Czasami polega na właściwym sformułowaniu problemu i znalezieniu odpowiedniego rozwiązania.

MeldID nie służy wyłącznie do obsługi paneli administracyjnych

Warto w tym miejscu wyjaśnić jeszcze jedną kwestię.

MeldID nie powstał wyłącznie jako narzędzie do mojego własnego dostępu administracyjnego.

Udostępnia również programistom SDK do integrowania mechanizmów identyfikacji i potwierdzania logowania we własnych aplikacjach.

Co więcej, SDK jest dostępne bezpłatnie.

Na przykład zewnętrzny programista może wykorzystać MeldID jako dodatkową warstwę potwierdzania uwierzytelniania użytkownika.

Nawet jeśli aplikacja nadal obsługuje tradycyjne logowanie za pomocą nazwy użytkownika i hasła, samo poprawne wpisanie tych danych może nie wystarczyć do zakończenia autoryzacji.

Na zaufane urządzenie mobilne użytkownika trafia żądanie, które może on zaakceptować lub odrzucić.

Pozwala to ograniczyć ryzyko nieuprawnionego dostępu w przypadku przejęcia danych logowania.

Ważne jest, by odróżniać tę ogólnodostępną funkcję MeldID od opracowanego przeze mnie modelu dostępu administracyjnego dla projektów DigiMeld.

Korzystają ze wspólnych zasad zaufania i potwierdzania działań, ale służą do rozwiązywania różnych problemów.

Bezpieczeństwo to nie tylko ochrona tego, co już istnieje

Praca nad tym systemem skłoniła mnie do innego spojrzenia na znane mechanizmy uwierzytelniania.

Często próbujemy chronić coś, co istnieje z powodów historycznych.

Dodajemy nowe weryfikacje, ograniczenia, dodatkowe hasła i kolejne warstwy zabezpieczeń.

Czasami jest to rzeczywiście konieczne.

Ale czasami lepiej zadać inne pytanie:

Czy mechanizm, który chcemy chronić, naprawdę musi nadal istnieć w dotychczasowej formie?

W moim przypadku odpowiedź brzmiała: nie.

Nie potrzebowałem stale dostępnego formularza logowania do panelu administracyjnego.

Potrzebowałem możliwości bezpiecznego uzyskiwania uprawnień administracyjnych dokładnie wtedy, gdy są potrzebne.

To dwa różne zadania.

Przejście od pierwszego do drugiego zmieniło nie tylko architekturę techniczną, lecz także codzienną pracę z projektami.

To nie koniec, lecz obrany kierunek

Obecnie ta architektura działa już w znacznej części ekosystemu DigiMeld.

Pozostałe projekty są stopniowo przenoszone na nowy model dostępu administracyjnego.

Przeprowadzam migrację etapami, sprawdzając działanie każdej aplikacji, a po zakończeniu tego procesu planuję dodatkowy audyt całego systemu.

Niektóre elementy interfejsu i zasady zarządzania sesjami mogą się jeszcze zmienić.

Główna idea jest jednak już określona.

Nie chcę wracać do modelu, w którym zarządzanie dziesiątkami własnych projektów wymaga ciągłego przechowywania i używania dziesiątek haseł administracyjnych.

Nie uważam jednak, że moje rozwiązanie jest uniwersalne.

Różne organizacje mają różne wymagania, infrastrukturę, modele zagrożeń i sposoby administrowania.

To, co jest wygodne i uzasadnione w ekosystemie DigiMeld, niekoniecznie będzie optymalne dla innego programisty.

Sama zasada czasowego przyznawania uprawnień zasługuje jednak na uwagę.

Zamiast zakończenia

Postanowiłem podzielić się tym doświadczeniem nie dlatego, że uważam się za wynalazcę nowej metody uwierzytelniania.

Nie dlatego też, że chcę przedstawić kolejny system jako całkowicie bezpieczny.

Absolutne bezpieczeństwo nie istnieje.

Po prostu sama zmiana sposobu postawienia problemu wydaje mi się interesująca.

Zamiast bez końca chronić stały dostęp administracyjny, można zastanowić się, czy musi on w ogóle istnieć.

Zamiast przechowywać wiele haseł — korzystać z tymczasowych uprawnień.

Zamiast automatycznie ufać po pierwszym uwierzytelnieniu — potwierdzać przyznanie konkretnych uprawnień.

Zamiast czekać na wygaśnięcie sesji — zapewnić możliwość centralnego odebrania dostępu.

I wreszcie, zamiast tworzyć osobny mechanizm logowania dla każdego projektu — zbudować jeden system zarządzania dostępem administracyjnym, zachowując niezależność aplikacji.

Nie twierdzę, że takie podejście eliminuje ryzyko przejęcia dostępu.

Po prostu przenosi akcent z ochrony stale istniejących danych logowania na kontrolowane przyznawanie i odbieranie uprawnień.

Być może czasami najskuteczniejszym sposobem ograniczenia powierzchni ataku nie jest dodanie kolejnego zabezpieczenia, lecz rezygnacja z czegoś, bez czego system może z powodzeniem działać.

Właśnie od tej myśli zaczęła się dla mnie historia MeldID Admin Gateway.