Cyberbezpieczeństwo i dostępność cyfrowa bywają przedstawiane jako dwa konkurencyjne wymagania. Zespół bezpieczeństwa chce ograniczyć ryzyko, więc wprowadza dodatkowe logowanie, krótkie sesje, blokady i testy CAPTCHA. Specjalista dostępności wskazuje natomiast, że część użytkowników nie może przejść przez tak zaprojektowane zabezpieczenia.
Taki konflikt najczęściej nie wynika z samych celów, lecz ze sposobu wdrożenia. Bezpieczny system nie musi być niedostępny, a dostępna usługa nie wymaga rezygnacji z ochrony danych i tożsamości użytkowników. Oba obszary powinny być analizowane razem, ponieważ dotyczą tego samego procesu: umożliwienia właściwej osobie bezpiecznego wykonania zadania.
Znaczenie cyberbezpieczeństwa stale rośnie. CERT Polska odnotował w 2024 roku ponad 600 tysięcy zgłoszeń cyberzagrożeń, a najczęściej rejestrowanym typem incydentu był phishing. Pokazuje to, że zabezpieczenia usług cyfrowych są rzeczywistą koniecznością, a nie formalnym dodatkiem.
Problem pojawia się jednak wtedy, gdy zastosowane mechanizmy skuteczniej blokują legalnych użytkowników niż atakujących.
Niedostępne zabezpieczenie może zamknąć całą usługę
Strona informacyjna może spełniać wymagania WCAG, lecz jej najważniejsza funkcja może pozostać niedostępna. Wystarczy, że użytkownik nie przejdzie przez logowanie, potwierdzenie operacji, mechanizm odzyskiwania konta albo test odróżniający człowieka od programu.
W takim przypadku dostępność wcześniejszych ekranów ma niewielkie znaczenie. Odbiorca nie skorzysta z formularza, nie pobierze danych, nie potwierdzi tożsamości i nie zakończy sprawy.
Największe ryzyko dotyczy usług, w których użytkownik wykonuje czynności istotne prawnie lub finansowo. Niedostępne uwierzytelnianie może uniemożliwić złożenie wniosku, dokonanie płatności, sprawdzenie decyzji albo zarządzanie własnym kontem.
Z tego powodu mechanizmy bezpieczeństwa muszą być oceniane jako integralna część usługi, a nie zewnętrzna warstwa pozostająca poza audytem dostępności.
CAPTCHA nie jest neutralnym testem
Jednym z najbardziej rozpoznawalnych zabezpieczeń jest CAPTCHA. Użytkownik musi przepisać zniekształcony tekst, rozpoznać obiekty na zdjęciach, rozwiązać zadanie albo wykonać określony ruch.
Mechanizm ma zatrzymać automaty, ale może także blokować osoby niewidome, słabowidzące, z trudnościami poznawczymi, dysleksją lub ograniczoną sprawnością manualną.
Wersja dźwiękowa nie zawsze rozwiązuje problem. Nagrania bywają celowo zniekształcone, zawierają szum i wymagają szybkiego zapamiętania ciągu znaków. Dla części użytkowników mogą być równie trudne jak wariant graficzny.
WCAG 2.2 wskazuje, że uwierzytelnianie nie powinno opierać się na teście funkcji poznawczych, chyba że zapewniono odpowiednią alternatywę lub mechanizm wspierający użytkownika. Dotyczy to między innymi konieczności zapamiętywania hasła, przepisywania kodu albo rozwiązywania łamigłówki.
Sam fakt, że system oferuje kilka rodzajów CAPTCHA, nie potwierdza więc jego dostępności. Trzeba ocenić, czy użytkownik może skorzystać z usługi bez wykonywania zadania, którego ze względu na swoją niepełnosprawność nie jest w stanie ukończyć.
Bezpieczne logowanie nie powinno zależeć od pamięci użytkownika
Wiele systemów wymaga zapamiętania złożonego hasła, jego ręcznego wpisania, a następnie przepisania kodu z wiadomości. Dodatkowo blokuje możliwość wklejania danych lub korzystania z menedżera haseł.
Takie rozwiązanie może wyglądać na bezpieczne, ale zwiększa liczbę błędów i prowadzi do stosowania przewidywalnych haseł zapisywanych w łatwo dostępnych miejscach. Może więc osłabiać bezpieczeństwo zamiast je wzmacniać.
Dla osób z niepełnosprawnościami poznawczymi, trudnościami z pamięcią lub sprawnością manualną ręczne odtwarzanie danych uwierzytelniających może być poważną barierą.
WCAG 2.2 uwzględnia dostępne uwierzytelnianie właśnie po to, aby użytkownicy mogli korzystać z takich mechanizmów jak menedżery haseł, wklejanie danych i automatyczne uzupełnianie.
Dostępność nie oznacza usunięcia hasła ani rezygnacji z wieloskładnikowego uwierzytelniania. Oznacza zaprojektowanie procesu, który nie wymaga od każdego użytkownika tych samych zdolności poznawczych i manualnych.
Wieloskładnikowe uwierzytelnianie również wymaga wyboru
Dodatkowe potwierdzenie tożsamości może znacząco zwiększyć bezpieczeństwo. Problem pojawia się, gdy system przewiduje tylko jedną metodę.
Kod wysyłany SMS-em może być niedostępny dla osoby, która nie korzysta z telefonu komórkowego lub ma trudność z szybkim przepisywaniem znaków. Potwierdzenie w aplikacji może wymagać obsługi niedostępnego interfejsu. Klucz sprzętowy może być trudny do użycia dla osoby z ograniczoną sprawnością dłoni.
Nie oznacza to, że należy rezygnować z dodatkowego zabezpieczenia. Potrzebne są alternatywne metody zapewniające porównywalny poziom ochrony.
Aktualne wytyczne NIST dotyczące tożsamości cyfrowej łączą wymagania bezpieczeństwa i prywatności z jakością doświadczenia użytkownika. NIST wskazuje także na potrzebę ograniczania zbędnego obciążenia oraz liczby czynności wymaganych podczas uwierzytelniania.
W praktyce wybór metody nie jest więc osłabieniem zabezpieczeń. Może być elementem bardziej odpornego systemu, który nie uzależnia dostępu od jednego urządzenia, kanału komunikacji lub rodzaju sprawności.
Krótka sesja może chronić dane i jednocześnie niszczyć proces
Automatyczne wylogowanie po okresie bezczynności jest stosowane w systemach przetwarzających dane wrażliwe. Ogranicza ryzyko pozostawienia otwartego konta na niestrzeżonym urządzeniu.
Osoba korzystająca z technologii wspomagającej może jednak potrzebować więcej czasu na przeczytanie instrukcji, przejście przez formularz i sprawdzenie wpisanych danych. Jeśli system wyloguje ją bez ostrzeżenia i usunie cały postęp, zabezpieczenie staje się barierą blokującą usługę.
WCAG zwraca uwagę na problem ponownego uwierzytelniania po wygaśnięciu sesji. Po zalogowaniu użytkownik powinien móc kontynuować czynność bez utraty wcześniej wprowadzonych danych, o ile nie powoduje to zagrożenia dla ich bezpieczeństwa.
Profesjonalna ocena musi więc uwzględniać zarówno czas sesji, sposób ostrzegania, możliwość jej przedłużenia, jak i zachowanie danych po ponownym zalogowaniu.
Nie wystarczy stwierdzenie, że wylogowanie jest wymagane przez politykę bezpieczeństwa. Trzeba ocenić, czy politykę wdrożono proporcjonalnie i bez niepotrzebnego obciążania użytkownika.
Dostępna alternatywa nie może być słabszym kanałem bezpieczeństwa
Gdy główny proces okazuje się niedostępny, instytucja czasami proponuje obsługę telefoniczną lub przesłanie danych pocztą elektroniczną. Taka alternatywa może być mniej bezpieczna niż pierwotna usługa.
Pracownik może prosić o przekazanie danych, których nie należy podawać telefonicznie. Zwykła wiadomość e-mail może zostać użyta do przesłania dokumentów zawierających dane osobowe. Proces może nie zapewniać wiarygodnego potwierdzenia tożsamości ani śladu wykonanej operacji.
Alternatywa dostępnościowa nie powinna tworzyć nowych zagrożeń dla osoby, która z niej korzysta. Nie może też wymagać ujawnienia większej ilości danych tylko dlatego, że użytkownik nie przeszedł przez niedostępny mechanizm.
Najlepszym rozwiązaniem jest dostępność podstawowego procesu. Metoda alternatywna powinna być stosowana wtedy, gdy jest rzeczywiście potrzebna, i zapewniać odpowiedni poziom poufności, integralności oraz rozliczalności.
Komunikaty bezpieczeństwa również muszą być dostępne
System może prawidłowo wykryć nietypowe logowanie albo zablokować podejrzaną operację, ale użytkownik musi jeszcze zrozumieć, co się wydarzyło.
Komunikat przekazany wyłącznie kolorem, ikoną lub krótkim kodem błędu nie pozwala podjąć właściwego działania. Osoba korzystająca z czytnika ekranu może nie otrzymać informacji o wygaśnięciu sesji, odrzuceniu kodu albo konieczności ponownego potwierdzenia operacji.
Tekst powinien jasno wskazywać przyczynę, bez ujawniania informacji ułatwiających atak. Powinien również wyjaśniać bezpieczny następny krok.
Zbyt ogólny komunikat „wystąpił błąd” powoduje wielokrotne próby, blokowanie kont i kontakt z pomocą techniczną. Z kolei nadmiernie techniczna informacja może ujawnić szczegóły działania systemu.
Dostępność komunikatu i bezpieczeństwo jego treści wymagają więc wspólnego projektowania.
Ochrona przed phishingiem wymaga zrozumiałej komunikacji
Phishing wykorzystuje presję czasu, strach i podobieństwo do prawdziwych komunikatów. Osoby korzystające z technologii wspomagających mogą mieć dodatkową trudność z oceną wizualnych cech wiadomości i fałszywej strony.
Instytucja powinna komunikować działania bezpieczeństwa w sposób spójny i przewidywalny. Użytkownik musi wiedzieć, jak wyglądają prawidłowe powiadomienia, gdzie samodzielnie sprawdzić status sprawy i jak zgłosić podejrzaną wiadomość.
Nie należy wymagać klikania linku z wiadomości, jeśli tę samą czynność można bezpiecznie rozpocząć po samodzielnym wejściu do serwisu. Komunikaty nie powinny też odwoływać się wyłącznie do elementów wizualnych, takich jak kolor paska adresu lub wygląd logo.
Dostępna i zrozumiała komunikacja zmniejsza ryzyko błędów użytkownika. Nie jest więc przeciwieństwem cyberbezpieczeństwa, lecz jednym z jego narzędzi.
Zabezpieczenia muszą działać z technologiami wspomagającymi
Mechanizm może być bezpieczny na poziomie kryptograficznym, a jednocześnie niemożliwy do obsłużenia przez czytnik ekranu lub klawiaturę.
Dotyczy to aplikacji do potwierdzania logowania, klawiatur ekranowych, kodów QR, przycisków kopiowania, okien zgód i ekranów odzyskiwania konta.
Jeśli użytkownik nie może odczytać kodu, przejść do pola albo rozpoznać aktualnego stanu, może zacząć korzystać z pomocy osoby trzeciej. Przekazuje wtedy hasło, telefon lub dostęp do prywatnych informacji.
Niedostępność zwiększa zatem ryzyko bezpieczeństwa. Zmusza użytkownika do obchodzenia procedur albo dzielenia się danymi uwierzytelniającymi.
Audyt zabezpieczeń powinien uwzględniać sposób działania technologii wspomagających oraz wszystkie etapy procesu, łącznie z rejestracją, logowaniem, potwierdzaniem operacji i odzyskiwaniem dostępu.
Odzyskiwanie konta bywa najsłabszym elementem usługi
Proces resetowania hasła często jest badany mniej dokładnie niż standardowe logowanie. Tymczasem to właśnie w nim użytkownik może napotkać dodatkowe pytania, krótkie terminy ważności kodów i ograniczone metody kontaktu.
Jeżeli procedura jest niedostępna, osoba może utracić możliwość korzystania z konta. Jeżeli jest zbyt łatwa, staje się atrakcyjnym celem ataku.
Potrzebna jest więc ocena zarówno bezpieczeństwa, jak i użyteczności. System powinien umożliwiać odzyskanie dostępu bez angażowania przypadkowej osoby, przekazywania poufnych danych lub przechodzenia przez niedostępne zadania.
Szczególnego znaczenia nabiera obsługa użytkownika, który zmienił numer telefonu, utracił urządzenie albo nie może skorzystać z wcześniej wybranej metody uwierzytelniania.
To właśnie takie sytuacje pokazują, czy system został zaprojektowany dla rzeczywistych ludzi, czy tylko dla idealnego scenariusza technicznego.
Zespoły bezpieczeństwa i dostępności powinny pracować razem
Problemy pojawiają się najczęściej wtedy, gdy wymagania są wdrażane osobno. Zespół bezpieczeństwa wybiera mechanizm ochronny, a dostępność jest sprawdzana dopiero po zakończeniu projektu.
Późniejsza poprawa może być kosztowna, ponieważ wymaga zmiany architektury logowania, integracji z dostawcą tożsamości albo przebudowy całego procesu.
Znacznie skuteczniejsze jest wspólne określenie ryzyka i potrzeb użytkowników przed wyborem rozwiązania. Pozwala to porównać alternatywne metody ochrony, zamiast przyjmować pierwsze technicznie dostępne zabezpieczenie.
Nie oznacza to, że audytor dostępności powinien decydować o poziomie zabezpieczeń ani że specjalista bezpieczeństwa sam oceni zgodność z WCAG. Potrzebna jest współpraca kompetencji.
Audyt powinien obejmować więcej niż stronę logowania
Ocena dostępności i bezpieczeństwa nie może kończyć się na sprawdzeniu, czy pola loginu i hasła mają etykiety.
Trzeba przeanalizować cały proces:
- utworzenie konta,
- potwierdzenie danych,
- logowanie,
- dodatkowe uwierzytelnienie,
- wygaśnięcie sesji,
- potwierdzanie operacji,
- odzyskiwanie dostępu,
- blokadę konta,
- kontakt z pomocą.
Znaczenie mają także systemy zewnętrzne. Instytucja może korzystać z dostawcy płatności, tożsamości albo podpisu elektronicznego. Dla użytkownika nadal jest to jedna usługa, nawet jeśli poszczególne etapy obsługują różne podmioty.
Automatyczny skaner nie pokaże wszystkich zależności. Potrzebne są testy manualne, analiza scenariuszy i ocena wpływu przyjętych zabezpieczeń na różne grupy użytkowników.
Dostępność może wzmacniać cyberbezpieczeństwo
Czytelne komunikaty, przewidywalny proces, możliwość korzystania z menedżera haseł i wybór metod uwierzytelnienia ograniczają liczbę błędów użytkownika.
Osoba, która może samodzielnie obsłużyć usługę, nie musi przekazywać urządzenia, kodu ani hasła komuś innemu. Nie jest również zmuszona korzystać z mniej bezpiecznego kanału alternatywnego.
Dobrze zaprojektowana dostępność zmniejsza więc potrzebę obchodzenia zabezpieczeń.
Konflikt między ochroną a dostępem nie jest nieunikniony. Pojawia się przede wszystkim wtedy, gdy bezpieczeństwo sprowadza się do mnożenia przeszkód, bez oceny ich rzeczywistej skuteczności i wpływu na odbiorców.
Bezpieczna usługa powinna skutecznie ograniczać działania nieuprawnionej osoby, a jednocześnie umożliwiać dostęp właściwemu użytkownikowi. Jeżeli zabezpieczenie blokuje osobę uprawnioną tylko dlatego, że korzysta ona z czytnika ekranu, potrzebuje więcej czasu albo nie może wykonać precyzyjnego gestu, system nie realizuje swojego celu prawidłowo.
Dostępność i cyberbezpieczeństwo nie są więc kompromisem między wygodą a ochroną. Są dwoma warunkami dobrze zaprojektowanej usługi cyfrowej.