Cyberbezpieczeństwo i dostępność cyfrowa
Przez ostatnie lata dostępność cyfrowa i cyberbezpieczeństwo rozwijały się równolegle, nie widząc się nawzajem. Tymczasem codziennie użytkownicy doświadczają ich jednocześnie, za każdym razem, gdy logują się do banku, korzystają z portalu urzędowego, robią zakupy w Internecie, podróżują z użyciem aplikacji mobilnej czy komunikują się w mediach społecznościowych.
Dostępność cyfrowa ma umożliwić możliwie wszystkim użytkownikom korzystanie z zasobów cyfrowych w sposób łatwy i pozbawiony barier. Jednak wśród użytkowników Internetu są również cyberprzestępcy, agresywne boty, oszuści i grupy dezinformacyjne. I właśnie w tym miejscu pojawia się jedno z najważniejszych wyzwań współczesnego Internetu. Z jednej strony chcemy Internetu dostępnego dla wszystkich ale z drugiej strony musimy chronić się przed utratą danych, kradzieżami, fake newsami i dezinformacją.
Powstaje więc pytanie, czy regulacje dotyczące bezpieczeństwa oraz regulacje dotyczące dostępności nie powinny zostać ze sobą silniej skorelowane?
W Polsce mamy co najmniej trzy główne filary prawa dostępności: ustawę o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych, ustawę o zapewnianiu dostępności osobom ze szczególnymi potrzebami oraz ustawę o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze. Równolegle wzmacniane są regulacje cyberbezpieczeństwa związane z NIS2 i nowelizacją ustawy o krajowym systemie cyberbezpieczeństwa. Niestety te dwa obszary regulacyjne nie widzą się dostatecznie i brakuje spójnych zasad, jak projektować rozwiązania jednocześnie bezpieczne i dostępne.
Potrzebujemy zatem nie tylko zaleceń technicznych, ale też wspólnego języka dla tych dwóch światów. Specjaliści od cyberbezpieczeństwa pytają dostępnościowców „czy osoba niewidoma przejdzie proces?”. Specjaliści od dostępności pytają speców od bezpieczeństwa: „czy napastnik nie obejdzie procesu?”. Tymczasem prawidłowe pytanie powinno brzmieć: czy legalny użytkownik przejdzie proces bez bariery, a nielegalny napotka skuteczny opór?
Problem da się ująć bardzo precyzyjnie. System ma odróżnić użytkownika uprawnionego od użytkownika nieuprawnionego, ale nie może robić tego metodą, która sama w sobie jest barierą. To jest kluczowe napięcie współczesnego Internetu. Widać je szczególnie w logowaniu, uwierzytelnianiu wieloskładnikowym, CAPTCHA, limitach czasu, blokadach sesji, wykrywaniu anomalii, filtrowaniu treści.
To prowadzi do bardzo ważnego wniosku, że dostępność i bezpieczeństwo powinny być traktowane jako wspólna architektura zaufania. NIS2 buduje obowiązki zarządzania ryzykiem i odporności usług, a prawo dotyczące dostępności nakłada obowiązek projektowania usług, z których może skorzystać każdy użytkownik. Połączenie tych dwóch perspektyw daje usługę publiczną lub komercyjną, która jest odporna na ataki i sprawiedliwa wobec użytkowników.
Zabezpieczenia nie mogą opierać się wyłącznie na jednym kanale lub jednej sensoryce. Jeżeli system wymaga szybkiego przepisania kodu z SMS, to musi istnieć alternatywa np. dłuższy czas, inny kanał, potwierdzenie w aplikacji, biometria urządzenia, wsparcie asysty. Sam krótki czas może być uzasadniony z perspektywy bezpieczeństwa, ale brak alternatywy jest już błędem projektowym.
Nie każda czynność wymaga tego samego poziomu ochrony. Odczyt publicznej informacji, pobranie prostego dokumentu, przeczytanie regulaminu czy deklaracji dostępności nie powinny być blokowane tak samo jak zmiana hasła czy chociażby wypłata pieniędzy. Im bardziej krytyczna operacja, tym silniejsze zabezpieczenie jest bardziej uzasadnione. Ale nawet wtedy organizacja powinna oferować co najmniej dwa dostępne sposoby przejścia procesu. Z kolei ochronę przed botami należy przesuwać do warstwy analitycznej i serwerowej, a możliwie mało opierać na zadaniach obciążających człowieka. Innymi słowy, to nie człowiek ma udowadniać w nieskończoność, że nie jest botem, lecz system ma mądrzej rozpoznawać ryzyko.
Rekomendacje połączenia cyberbezpieczeństwa i dostępności cyfrowej
- Bezpieczeństwo i dostępność powinny być projektowane równocześnie, jako jeden model zaufania do usług i produktów cyfrowych.
- Poziom zabezpieczeń powinien zależeć od wagi operacji – inne dla odczytu zwykłej informacji, inne dla zmiany danych, płatności czy podpisania umowy.
- Dla operacji podwyższonego ryzyka należy zapewnić co najmniej dwie dostępne metody logowania lub potwierdzenia tożsamości.
- Nie opierać procesów bezpieczeństwa wyłącznie na pamięci użytkownika, szybkim przepisywaniu kodów, rozpoznawaniu obrazów czy precyzyjnych działaniach manualnych.
- Limity czasu powinny wynikać z analizy ryzyka oraz umożliwiać bezpieczne przedłużenie sesji tam, gdzie to możliwe.
- Ochronę przed nadużyciami np. przed botami, należy przenosić do warstw analitycznych ograniczając obciążanie użytkownika.
- CAPTCHA stosować wyłącznie ostatecznie i zawsze z dostępną alternatywą.
- Procedury odzyskiwania konta, zgłaszania oszustw, blokad, zmiany danych i weryfikacji po ataku, muszą być dostępne dla wszystkich użytkowników, a komunikaty bezpieczeństwa powinny być jasne i napisane prostym językiem.
- Audyty stron, aplikacji i systemów powinny badać jednocześnie zgodność z wymaganiami dostępności oraz wpływ zabezpieczeń na użytkownika.
Wymagany jest nowy model działania, w którym bezpieczeństwo i dostępność będą wspólnym standardem projektowania usług cyfrowych. Wydaje się konieczne wprowadzenie do wytycznych regulatorów i organów nadzoru, wspólnego rozdziału dotyczącego projektowania zabezpieczeń bez wykluczenia użytkowników oraz zmianę podejścia w audytach stron internetowych i aplikacji mobilnych tak aby obejmować oba te obszary.
Istotną rolę mogą odegrać również fora współpracy, takie jak Trialog lub podobne formaty, w ramach których możliwe byłoby uzgadnianie rekomendacji akceptowalnych dla biznesu, regulatorów i użytkowników.
Wchodzimy bowiem w epokę, w której sztuczna inteligencja będzie jednocześnie wzmacniała ataki, ale też wspierała ochronę systemów. Tym bardziej nie można dopuścić do sytuacji, w której człowiek staje się najsłabszym ogniwem tylko dlatego, że nie rozumie procesu, nie zdąży wpisać kodu, nie potrafi przejść weryfikacji albo zostaje błędnie uznany za zagrożenie.