Zanim wybierzesz zabezpieczenia: model zagrożeń dla urządzenia, aplikacji i chmury

Zespół ma urządzenie, aplikację mobilną, usługę w chmurze i narzędzie serwisowe. Każdy element przeszedł własne testy, ale nadal nie wiadomo, czy urządzenie jednego klienta może zgłosić dane jako urządzenie innego, czy były serwisant zachowa dostęp ani czy poprawnie podpisana aktualizacja pasuje do konkretnej rewizji sprzętu. Te pytania leżą między komponentami i wymagają wspólnego modelu.

Modelowanie zagrożeń pomaga zdecydować, gdzie potrzebna jest kontrola i jaki test powinien ją potwierdzić. Wynikiem nie powinna być wyłącznie lista ogólnych haseł, takich jak szyfrowanie i silne hasła. Potrzebujemy opisanego scenariusza, warunków jego zajścia, skutku, zabezpieczenia, właściciela oraz ryzyka, którego zabezpieczenie nie usuwa.

Przykład jest fikcyjny. Dotyczy urządzeń pomiarowych przypisanych do kont organizacji, z odczytem danych, zmianą ustawień i aktualizacją firmware. Nie przedstawia audytu BBest24 ani wyników testu penetracyjnego. Proste reguły sprawdzamy lokalnie, natomiast ochrona kluczy, poprawność kryptografii i zachowanie rzeczywistej infrastruktury pozostają osobnymi zadaniami weryfikacyjnymi.

Zacznij od niepożądanej decyzji

Dla zespołu produktu cenniejsze od pytania „czy mamy TLS?” jest pytanie „czy obcy klient może zmienić ustawienia mojego urządzenia?”. Pierwsze dotyczy mechanizmu. Drugie wskazuje chronioną właściwość i efekt naruszenia. Mechanizm wybieramy dopiero po zrozumieniu, gdzie system podejmuje decyzję o tożsamości, właścicielu i uprawnieniach.

W naszym zakresie chronimy przypisanie urządzenia do konta, integralność pomiarów, autoryzowane zmiany konfiguracji oraz możliwość uruchomienia właściwego firmware. Dostępność także ma znaczenie: odrzucenie wszystkich żądań może chronić dane, ale uniemożliwić usługę. Nie zakładamy jednak, że ogólna analiza cyberbezpieczeństwa zastępuje osobną analizę skutków fizycznych w zastosowaniu krytycznym.

OWASP Threat Modeling Cheat Sheet porządkuje pracę od opisu systemu przez zagrożenia i odpowiedzi do weryfikacji. Model ma być aktualizowany razem z produktem. W praktyce oznacza to, że dodanie lokalnego serwisu offline wymaga przeglądu wcześniejszych założeń, nawet jeśli publiczne API nie zmieniło się ani o jedną ścieżkę.

Dobry zakres mówi również, czego jeszcze nie oceniono. W naszym przykładzie nie analizujemy szczegółowo odporności układu na laboratoryjną ekstrakcję kluczy ani całej organizacji dostawcy chmury. Nie oznacza to braku ryzyka. Oznacza jawne ograniczenie analizy, które powinno być uwzględnione przy decyzji o zastosowaniu produktu i kolejnych pracach.

Narysuj przepływy i miejsca zmiany zaufania

Aplikacja użytkownika wysyła żądania do usługi. Usługa przechowuje dane kont i wysyła komendy do urządzeń. Urządzenie publikuje telemetrię. Narzędzie technika ma dodatkowy kanał lokalny, a wydawca dostarcza pakiety aktualizacji. Każdy z tych przepływów przenosi dane, których odbiorca nie powinien uznawać za prawdziwe wyłącznie dlatego, że pochodzą z oczekiwanej sieci.

Granica zaufania nie musi pokrywać się z granicą infrastruktury. Dwa konta w tej samej bazie wymagają rozdzielenia uprawnień. Telefon zalogowanego użytkownika pozostaje źródłem danych wejściowych, które można zmienić. Narzędzie firmowego serwisanta może zostać utracone. Podpisany pakiet ma określone pochodzenie, ale nadal może być przeznaczony dla innego modelu urządzenia.

Na diagramie warto oznaczyć także magazyny danych i tożsamości, które mają prawo do nich sięgać. W uproszczeniu połączyliśmy usługę i dane w jednym polu, lecz w rzeczywistym projekcie kolejka, magazyn plików i panel administracyjny mogą wymagać osobnego rozwinięcia. Poziom szczegółowości powinien ujawniać decyzje bezpieczeństwa, a nie odtwarzać każdy proces systemu operacyjnego.

Dla każdego przepływu zapisz, kto go inicjuje, co odbiorca sprawdza i co robi przy braku możliwości sprawdzenia. „Weryfikujemy token” jest niepełne bez wskazania odbiorcy, zakresu, ważności i powiązania z zasobem. Podobnie „urządzenie jest nasze” nie mówi, do którego klienta należy i czy nadal jest uprawnione do działania.

S1: urządzenie deklaruje cudzą tożsamość

Urządzenie D-A ma własny poświadczeniowy identyfikator i należy do konta A. W treści wiadomości wysyła jednak deviceId = D-B albo wskazuje konto B. Jeśli usługa użyje tych pól bez porównania z tożsamością uwierzytelnionego nadawcy, poprawnie zestawione połączenie może przenieść dane do cudzego zasobu. Szyfrowanie kanału nie rozwiązuje tego błędu logicznego.

Kontrola powinna wyprowadzać tożsamość z zaufanego wyniku uwierzytelnienia i sprawdzać bieżące przypisanie właściciela. Pole z wiadomości może być dodatkową informacją, ale nie może samo nadawać prawa. W naszym modelu identyfikator uwierzytelniony musi zgadzać się z deklarowanym, a właściciel z rejestru z kontem wskazanym przez żądanie.

Próba negatywna używa prawidłowego poświadczenia D-A i obcego identyfikatora lub konta. Oczekujemy odmowy przed zapisem danych, bez skutku ubocznego w koncie B. Trzeba sprawdzić także logi, indeksy i zdarzenia: odrzucone żądanie nie powinno pozostawić cudzego pomiaru w pomocniczym magazynie, nawet jeśli główna tabela pozostała poprawna.

Pozostaje ryzyko kradzieży prawidłowego klucza D-A. Kontrola powiązania nie rozpoznaje automatycznie, że ktoś podszywa się pod właściwe urządzenie przy użyciu jego sekretu. Potrzebne są ochrona poświadczeń, możliwość unieważnienia, obserwacja nietypowego zachowania i procedura ponownego ustanowienia tożsamości. To osobne środki, a nie dowód słabości samej reguły właściciela.

Przeniesienie własności zmienia odpowiedź

Urządzenie może zostać sprzedane, wymienione lub przypisane do innej organizacji. Wtedy właściciel nie jest niezmienną cechą certyfikatu. Należy ustalić proces przeniesienia, potwierdzenie prawa do urządzenia i moment utraty dostępu przez poprzednie konto. Sama znajomość numeru seryjnego nie powinna wystarczać do przejęcia zasobu.

Po zmianie trzeba sprawdzić istniejące sesje, kolejki komend, linki do eksportów i kopie danych w pamięci podręcznej. Unieważnienie dostępu w jednym endpointcie nie usuwa uprawnień zapisanych gdzie indziej. Również historia pomiarów wymaga jawnej decyzji: czy pozostaje przy poprzednim koncie, przechodzi z urządzeniem, czy podlega odrębnej procedurze.

Test przeniesienia powinien obejmować stary i nowy kontekst równocześnie. Poprzedni właściciel próbuje odczytu oraz sterowania istniejącą sesją, nowy właściciel wykonuje dozwolone działania, a urządzenie wysyła dane podczas zmiany. Oczekiwane zachowanie musi być ustalone przed implementacją, szczególnie dla wiadomości czekających w kolejce.

S2: były serwisant nadal ma token

Serwisant uzyskał dostęp do urządzeń konta A. Uprawnienie zostaje cofnięte, lecz jego komputer nadal przechowuje ważny kryptograficznie token. Jeśli usługa sprawdza wyłącznie podpis i datę wygaśnięcia, może nadal akceptować działania. Tożsamość użytkownika została potwierdzona, ale aktualne prawo do operacji już nie istnieje.

OWASP Authorization Cheat Sheet zaleca kontrolę uprawnień przy każdym żądaniu, domyślną odmowę i najmniejsze potrzebne uprawnienia. W przykładzie sprawdzamy aktywność serwisanta, właściwe konto, rolę oraz generację uprawnień. Token z wcześniejszą generacją jest odrzucany po zmianie bieżącego stanu.

Jest to jeden możliwy mechanizm, nie uniwersalny projekt sesji. Inne rozwiązania mogą korzystać z krótkich sesji, introspekcji lub list unieważnień. Ważne, aby znać maksymalny czas skuteczności cofnięcia i zachowanie przy niedostępności źródła uprawnień. Pamięć podręczna decyzji musi mieć jawny wpływ na ten czas.

Próba negatywna zachowuje wcześniej wydany token, cofa uprawnienie i ponawia operację na tym samym urządzeniu. Oczekujemy odmowy oraz braku zmiany konfiguracji. Powtórz próbę dla aktywnego połączenia, odświeżenia sesji i odczytu wcześniejszego wyniku. Usunięcie przycisku z interfejsu nie jest testem egzekwowania uprawnień po stronie usługi.

Wariant offline odwraca część założeń

Narzędzie serwisowe może potrzebować działania bez sieci. Urządzenie nie odczyta wtedy natychmiast nowej decyzji o cofnięciu uprawnień. Nie można jednocześnie obiecać nieograniczonego działania offline i natychmiastowego globalnego unieważnienia bez dodatkowego kanału. To ograniczenie architektury, które trzeba przedstawić właścicielowi produktu.

Możliwy wariant ogranicza zakres i czas lokalnego uprawnienia, wiąże je z konkretnym urządzeniem i wymaga ponownego potwierdzenia po wygaśnięciu. Jednak zegar, restart i możliwość cofnięcia czasu stają się częścią modelu. Jeżeli urządzenie nie potrafi wiarygodnie egzekwować czasu życia, sam napis „ważne przez godzinę” w pakiecie nie rozwiązuje problemu.

W naszym przykładzie nie implementujemy takiego protokołu. Mapa pozostawia ograniczony dostęp offline jako ryzyko wymagające osobnej decyzji i dowodu. W zależności od produktu można ograniczyć offline do odczytu diagnostyki, wymagać obecności fizycznej lub całkowicie wyłączyć zmianę konfiguracji. Wybór powinien wynikać ze skutku nadużycia i realnego procesu serwisowego.

S3: podpis jest poprawny, pakiet niewłaściwy

Urządzenie otrzymuje aktualizację podpisaną przez zaufanego wydawcę. Pakiet jest jednak przeznaczony dla innego modelu albo zawiera starszą wersję poniżej przyjętego minimum. Weryfikacja podpisu potwierdza autentyczność podpisanych danych, lecz sama nie ustala ich zgodności z odbiorcą i polityką wersji.

Kontrola obejmuje podpis, identyfikator modelu, obsługiwane rewizje, wersję oraz warunki instalacji. Krytyczne metadane muszą być objęte ochroną integralności razem z pakietem. Jeśli nazwę modelu można zmienić poza podpisanym zakresem, sprawdzanie tego pola daje pozorne zabezpieczenie. Wydawca i urządzenie muszą zgodnie interpretować manifest.

NIST SP 800-193 ujmuje odporność firmware przez ochronę przed nieuprawnioną zmianą, wykrywanie i odzyskiwanie. W naszym scenariuszu oznacza to, że poprawna odmowa instalacji nie wystarcza do oceny całego procesu. Trzeba także wiedzieć, jak urządzenie wróci do działania po przerwanym zapisie i jak zachowa się przy uszkodzonym obrazie.

Testy powinny obejmować zmodyfikowany pakiet, obcy model, zbyt starą wersję, brak miejsca i przerwanie zasilania w kontrolowanych punktach. Prosty model lokalny otrzymuje już wynik signatureVerified; nie wykonuje operacji kryptograficznej. Dlatego jego pozytywny wynik sprawdza logikę polityki, a nie bezpieczeństwo implementacji podpisu lub bootloadera.

Zaufany wydawca też może zawieść

Przejęcie klucza podpisującego zmienia sytuację: atakujący może przygotować pakiet przechodzący zwykłą kontrolę autentyczności. Potrzebne są odpowiednie zasady dostępu do kluczy, rozdzielenie uprawnień wydawniczych, rejestrowanie operacji i plan reakcji. Ochrona kanału pobierania nie zastępuje ochrony procesu, który tworzy zaufany artefakt.

Rotacja i unieważnianie kluczy muszą być możliwe do przeprowadzenia na urządzeniach, które nie łączą się codziennie. Trzeba ustalić, co stanie się ze starszą flotą i jak uniknąć zablokowania legalnych aktualizacji. Mechanizm odzyskiwania nie powinien być ukrytą drogą pomijającą wszystkie kontrole, bo wtedy staje się alternatywnym kanałem instalacji.

Podobnie zakaz cofania wersji ma koszt operacyjny. Może uniemożliwić prosty powrót po błędnym wydaniu. Potrzebna jest zgodna z polityką droga naprawy, na przykład nowe wydanie z wyższym numerem i przywróconą funkcją. Ochrona przed rollbackiem i plan odzyskania powinny być projektowane razem, z uwzględnieniem konfiguracji oraz zgodności danych.

Od scenariusza do sprawdzalnej kontroli

Dla S1 właścicielem kontroli może być zespół usługi przyjmującej telemetrię, dla S2 zespół tożsamości i narzędzia serwisowego, a dla S3 zespół wydawniczy oraz firmware. Wspólna odpowiedzialność bez wskazania konkretnego właściciela często oznacza, że każda strona zakłada wykonanie pracy przez inną.

NISTIR 8259A daje punkt odniesienia dla podstawowych zdolności cyberbezpieczeństwa urządzeń IoT. Warto użyć go do sprawdzenia, czy nie pominięto identyfikacji, konfiguracji, ochrony danych, dostępu do interfejsów, aktualizacji i informacji o stanie bezpieczeństwa. Taka lista pomaga ocenić zakres, ale nie dowodzi skuteczności konkretnej implementacji.

Wymaganie powinno określać obserwowalny wynik. „Zapewnić autoryzację” jest zbyt ogólne. „Żądanie D-A deklarujące konto B jest odrzucane przed zapisem w każdym magazynie danych” wskazuje warunek, granicę i skutek. Następnie można sprawdzić, czy test rzeczywiście obejmuje wszystkie ścieżki zapisu, także asynchroniczne.

Ryzyko pozostające potrzebuje właściciela

Nie każdy scenariusz można usunąć całkowicie. Warto rozdzielić brak kontroli, kontrolę zaplanowaną, kontrolę wdrożoną i kontrolę sprawdzoną. Zielony status po utworzeniu zadania w backlogu jest mylący. Podobnie test jednostkowy reguły nie jest równoważny próbie całego przepływu z rzeczywistym magazynem i kolejką.

Ocena priorytetu powinna uwzględniać skutek, dostęp potrzebny do nadużycia, skalę, wykrywalność i możliwość odzyskania. Jeżeli nie mamy danych o prawdopodobieństwie, lepiej użyć opisowych kategorii z uzasadnieniem niż mnożyć arbitralne liczby i prezentować wynik jako precyzyjny pomiar. Najważniejsze jest uzasadnienie kolejności prac.

Akceptacja ryzyka powinna wskazywać osobę odpowiedzialną, warunki i termin przeglądu. Na przykład ograniczony serwis offline może być dopuszczony wyłącznie dla odczytu i urządzeń w kontrolowanym miejscu. Po rozszerzeniu go o zmianę konfiguracji wcześniejsza decyzja wymaga ponowienia. Ryzyko jest związane z konkretną funkcją i zakresem, a nie wiecznie przypisane do nazwy produktu.

Model zmienia się razem z produktem

Nowa rola użytkownika, wspólny eksport danych, lokalny interfejs serwisowy, dodatkowy dostawca aktualizacji albo przeniesienie urządzeń między kontami powinny uruchamiać przegląd właściwych scenariuszy. Nie trzeba za każdym razem zaczynać od pustej kartki. Trzeba znaleźć przepływy i założenia, których dotyczy zmiana.

Przegląd powinien obejmować także usunięte funkcje. Zamknięcie endpointu nie gwarantuje, że stare aplikacje, zaplanowane zadania albo pakiety serwisowe przestały z niego korzystać. Pozostawiony kanał zgodności może zachować wcześniejsze uprawnienia. Warto sprawdzać rzeczywiste punkty wejścia oraz zachowanie poprzednich wersji klientów.

Incydenty i wyniki testów zasilają model nową wiedzą. Jeśli kontrola została pominięta w jednym przepływie, należy poszukać podobnego założenia w innych. Nie chodzi o dopisywanie każdego błędu do ogromnej tabeli, lecz o aktualizację wspólnego rozumienia granic zaufania i sposobu ich egzekwowania.

Pierwsze uruchomienie i odzyskanie dostępu

Rejestr tożsamości nie powstaje sam. Trzeba ustalić, jak nowe urządzenie otrzymuje poświadczenie, kto może je przypisać do konta i jak potwierdza się poprawność tego przypisania. Wspólny sekret dla całej floty może uprościć prototyp, lecz jego ujawnienie zmienia skalę incydentu. Model powinien wskazywać, czy utrata jednego egzemplarza daje dostęp tylko do niego, czy także do innych.

Procedura odzyskania po utracie telefonu lub komputera technika jest równie ważna jak zwykłe logowanie. Jeśli pozwala ominąć silną kontrolę przez łatwo dostępny numer seryjny, staje się prostszą drogą przejęcia. Należy opisać dowód prawa do zasobu, osobę zatwierdzającą wyjątek i ślad audytowy. Wygoda wsparcia nie powinna zależeć od trwałego, wspólnego konta o pełnych uprawnieniach.

Podczas wycofania urządzenia z użycia trzeba rozstrzygnąć los kluczy, danych lokalnych i powiązania z kontem. Reset ustawień użytkownika może nie usuwać wszystkich poświadczeń. Z drugiej strony przypadkowe wymazanie tożsamości fabrycznej może utrudnić legalne ponowne uruchomienie. Procedura powinna odróżniać reset konfiguracji, przeniesienie właściciela i trwałe wycofanie, ponieważ mają inne skutki.

Próba odmowy potrzebuje próby dozwolonej

Test bezpieczeństwa może pozornie przejść, gdy cała usługa nie działa. Jeżeli żądanie obcego urządzenia zostaje odrzucone z powodu awarii sieci, nie dowodzi to poprawności kontroli właściciela. Obok próby negatywnej wykonaj dozwoloną operację w tych samych warunkach i sprawdź, że dociera do właściwego zasobu. Dzięki temu wiadomo, że badamy decyzję, a nie przypadkowy brak dostępności.

Oceniaj także brak skutku ubocznego. Kod odmowy w odpowiedzi nie wystarcza, jeśli dane zostały wcześniej zapisane, komenda trafiła do kolejki lub plik został udostępniony. Test powinien obserwować właściwą granicę transakcji i późniejsze zadania asynchroniczne. W niektórych systemach potrzebne będzie odczekanie ustalonego czasu, aby wykryć opóźniony skutek.

Próby wymagają kontrolowanych kont, urządzeń i danych testowych. Ich wynik należy przypisać do konkretnego wydania i konfiguracji. Zmiana sposobu buforowania uprawnień albo nowy konsument kolejki może unieważnić wcześniejszy dowód, mimo że funkcja sprawdzająca token pozostała bez zmian. Model pomaga wskazać tę zależność i dobrać zakres ponownego testu.

Karta robocza dla zespołu

Taka karta pozwala zakończyć spotkanie konkretną pracą: zmianą kontraktu, implementacją kontroli, testem albo świadomą decyzją o ograniczeniu funkcji. Model jest wartościowy wtedy, gdy pomaga rozstrzygnąć te działania i zachowuje ich podstawę. Sam diagram bez powiązania z dowodami szybko staje się opisem intencji, którego nikt nie potrafi zweryfikować.

Komunikat odmowy również należy do modelu. Odpowiedź dla obcego konta nie powinna ujawniać zbędnych szczegółów o istnieniu urządzenia, jego właścicielu lub wersji. Wewnętrzny dziennik może zachować dokładniejszy powód potrzebny do diagnostyki, z właściwą kontrolą dostępu. Rozdzielenie informacji publicznej i operacyjnej pomaga uniknąć sytuacji, w której poprawna blokada działania staje się źródłem danych o cudzych zasobach. Test powinien oceniać treść odpowiedzi i skutki, a nie tylko jej kod.

Źródła

• OWASP Threat Modeling Cheat Sheet, opis systemu, granice zaufania, scenariusze i weryfikacja; dokumentacja rozwijana na bieżąco.
• OWASP Authorization Cheat Sheet, domyślna odmowa, najmniejsze uprawnienia i kontrola każdego żądania.
• NISTIR 8259A: IoT Device Cybersecurity Capability Core Baseline, maj 2020; zakres podstawowych zdolności urządzenia.
• NIST SP 800-193: Platform Firmware Resiliency Guidelines, maj 2018; ochrona, wykrywanie i odzyskiwanie firmware.

Źródła sprawdzono 21 października 2026 r. Scenariusze i reguły są dydaktyczne. Nie przeprowadzono audytu systemu, testu penetracyjnego ani walidacji kryptografii; dokument nie stanowi potwierdzenia zgodności regulacyjnej.