Na publicznej tablicy informacyjnej przy zaporze, w holu urzędu czy w centrum dla zwiedzających każdy powinien móc podejść i zobaczyć aktualne dane ze stacji. Taka tablica nie potrzebuje ekranu logowania - i nie może go bezpiecznie mieć. Nikt nie będzie wpisywał hasła na wspólnym ekranie dotykowym przykręconym do ściany. A gdyby nawet wpisał, to hasło należałoby do każdego, kto kiedykolwiek przed nim stał.
Dwa najprostsze rozwiązania zawodzą z tego samego powodu. Wystarczy jeden zrzut ekranu, żeby wspólne konto „publiczne” z prawdziwym hasłem zostało użyte tam, gdzie nie powinno. A pełny dostęp administratora z ładniejszym interfejsem to nadal pełny dostęp administratora. Kiosk wcale nie potrzebuje logowania. Potrzebuje ograniczonego dostępu, który wygasa, którego nie da się rozszerzyć i który w ogóle nie wymaga hasła.
Dokładnie to zbudowałem w Wodowskazie: zeskanowanie kodu QR z publicznej tablicy przenosi odwiedzającego prosto do danych z lokalnych stacji, na bieżąco, z odczytami co 10 minut - bez logowania i bez wglądu w cokolwiek poza tym zakresem.
Uprawnienie, a nie tożsamość
Większość systemów kontroli dostępu zaczyna od pytania: kim jest ten użytkownik? W przypadku publicznego kiosku to pytanie nie ma sensownej odpowiedzi - nie ma użytkownika, jest tylko urządzenie, do którego każdy może podejść. Właściwe pytanie brzmi inaczej: co wolno zobaczyć przez ten konkretny link i do kiedy?
Na tej zmianie perspektywy opiera się cały wzorzec. Zamiast nadawać tożsamość i sprawdzać jej uprawnienia przy każdym zapytaniu, wydaję podpisany link, który sam zawiera swoje uprawnienia - token uprawnień (capability token), a nie login. Administrator wybiera zakres (jedna stacja, jeden region, jeden zestaw danych demonstracyjnych), ustawia datę wygaśnięcia, a platforma generuje link. Kto ma ten link, może zrobić dokładnie to, na co link pozwala, i nic więcej - dopóki jest ważny i bez potwierdzania, kim jest.
Jak to działa w praktyce
Parametr w adresie to podpisany token, którego nie da się niepostrzeżenie zmienić - a nie identyfikator z bazy danych, który tylko wygląda na losowy. Zawiera zakres zasobów i datę wygaśnięcia, a serwer go podpisuje. Zmiana choćby jednego znaku unieważnia token, zamiast po cichu dawać dostęp do czegoś innego.
Po otwarciu linku serwer weryfikuje podpis, sprawdza termin ważności i tworzy sesję ograniczoną dokładnie do tego, na co pozwala token - bez panelu administracyjnego, bez innych stacji, bez zarządzania użytkownikami. Odwiedzający nie widzi formularza logowania, bo nie ma się do czego logować: sam link służy za przepustkę i nie otwiera niczego poza tym, do czego go wprost podpisano.
To celowo nie jest OAuth ani wspólny klucz API. OAuth rozwiązuje problem „udowodnij zewnętrznej usłudze, kim jesteś” - a tu nie ma żadnej zewnętrznej tożsamości. Wspólny klucz API w publicznie dostępnym urządzeniu prędzej czy później wycieknie - a jego unieważnienie wyłączy wszystkie inne kioski, które korzystają z tego samego klucza. Podpisany, ograniczony i wygasający link omija oba problemy: nie potrzebuje dostawcy tożsamości, a odebranie dostępu jednemu kioskowi nie wpływa na pozostałe.
W praktyce: jeden panel, wiele publicznych punktów
Ten wzorzec bezpieczeństwa ma sens tylko wtedy, gdy tworzenie linków i zarządzanie nimi jest proste dla osób, które na co dzień obsługują system - a nie tylko dla programistów, którzy go zbudowali. W praktyce to ekran w panelu administracyjnym, na którym osoba bez wiedzy technicznej wybiera zakres, ustawia czas ważności i dostaje kod QR oraz link do skopiowania - gotowy do wydrukowania, zalaminowania i przykręcenia do tablicy przy następnej wizycie w terenie.
Dla integratora obsługującego kioski w dziesiątkach publicznych miejsc kontrola dostępu przestaje być powtarzającym się zleceniem dla programisty i staje się pięciosekundowym zadaniem w panelu. Link demonstracyjny na targi, stały link dla centrum zwiedzających przy zaporze i link ważny 48 godzin na konferencję prasową to ten sam mechanizm z innym zakresem i datą ważności - bez zmian w kodzie, bez nowego wdrożenia i bez wspólnego hasła, które kiedyś trzeba będzie zmienić.
Najczęstszy błąd przy dostępie publicznym to traktowanie go jak okrojonej wersji logowania administratora. To zupełnie inny problem - i hasło nigdy nie miało go rozwiązywać. Podpisane, ograniczone i wygasające linki dają kioskowi dokładnie taki dostęp, jakiego potrzebuje, i nic ponad to. To ta sama zasada, co przy udostępnianiu danych publicznie bez odsłaniania platformy, która je generuje: najpierw zdecyduj, co świat zewnętrzny może zobaczyć, a potem zbuduj do tego możliwie najwęższe drzwi. Cały proces zobaczysz w realizacji Wodowskaz.
