Chcesz zacząć modelowanie zagrożeń i wszyscy mówią Ci jedno i to samo: „najpierw narysuj DFD”. Otwierasz pierwszy lepszy poradnik i… ściana symboli. Notacja Yourdona-DeMarco, strzałki, kółka, podwójne kreski, jakieś przerywane linie. Wygląda jak rocket science. Nie jest.
Powiemy Ci coś, czego większość tych poradników nie mówi wprost: DFD (ang. Data Flow Diagram), czyli diagram przepływu danych, ma tylko 5 elementów, a najważniejszy z nich, granicę zaufania, połowa tych poradników w ogóle pomija. Tyle i aż tyle.
W tym artykule pokażemy Ci, czym DFD jest (i czym NIE jest), z czego się składa, jak narysować go krok po kroku, i dlaczego skończony diagram to dopiero początek zabawy, a nie jej koniec. Zapraszamy do lektury.
Co to jest DFD — i po co nam w modelowaniu zagrożeń
Definicja w jednym zdaniu:
DFD to mapa tego, jak dane wędrują przez Twój system — kto je wysyła, co je przetwarza, gdzie lądują i którędy płyną.
Po co nam taka mapa? Bo w modelowaniu zagrożeń kolejność jest stała: najpierw reprezentujemy system, a dopiero potem pytamy „co może pójść źle” sesja modelowania zagrożeń krok po kroku. Nie da się sensownie szukać zagrożeń, gapiąc się w pustą kartkę. Mózg potrzebuje czegoś, na co patrzy.
I tu dochodzimy do sedna. „Myśl jak atakujący” to jedna z najbardziej bezużytecznych rad, jakie można dać inżynierowi. Sam Microsoft doszedł do tego wniosku. Bo jak masz myśleć jak ktoś, kim nie jesteś i nigdy nie byłeś? DFD rozwiązuje ten problem inaczej: zamiast pustej kartki i abstrakcyjnej rady daje Ci konkretne miejsca do obejrzenia. Tu encja, tu proces, tu granica: sprawdź każde z osobna.
Jeszcze jedno, ważne dla całej filozofii. Patrzymy na pudełka, ale w kontekście danych. Proces czy magazyn jest dla nas istotny dlatego, że albo dane w nim spoczywają (jak w bazie danych), albo przez nie przepływają. Dlatego rysujemy diagram przepływu danych, a nie diagram ładnie poukładanych klocków: system jest o tyle ważny i ryzykowny, o ile są w nim ważne, wrażliwe dane. To one decydują, gdzie ryzyko jest realne.
DFD nie rysujemy dla sztuki — rysujemy, żeby mieć na co patrzeć, gdy pytamy „co może pójść źle”.
5 elementów DFD (i ten jeden, który wszyscy pomijają)
Przejdźmy przez całą piątkę. Po pierwsze encja zewnętrzna, po drugie proces, po trzecie magazyn danych, po czwarte przepływ danych, i po piąte granica zaufania (ta najważniejsza).
| # | Element | Symbol (konwencja) | Co reprezentuje | Przykład |
|---|---|---|---|---|
| 1 | Encja zewnętrzna (ang. external entity) | prostokąt | aktor lub system POZA Twoją kontrolą: użytkownik, klient, zewnętrzne API | przeglądarka użytkownika, brama płatności |
| 2 | Proces (ang. process) | koło lub zaokrąglony prostokąt | coś, co przetwarza dane: usługa, funkcja, endpoint | serwis logowania, API zamówień |
| 3 | Magazyn danych (ang. data store) | dwie poziome kreski | miejsce, gdzie dane spoczywają | baza danych, kolejka, bucket S3, cache |
| 4 | Przepływ danych (ang. data flow) | strzałka | dane W RUCHU między elementami | request HTTP, zapis do bazy, event na kolejce |
| 5 | Granica zaufania (ang. trust boundary) | przerywana linia | gdzie zmienia się poziom zaufania — moment, w którym dane przechodzą z obszaru mniej zaufanego do bardziej zaufanego (lub odwrotnie) | granica między internetem a backendem; między aplikacją a bazą; między dwoma mikroserwisami o różnych uprawnieniach |
Tak to wygląda na żywym przykładzie. Poniżej DFD prostego systemu płatności, narysowany w draw.io, z zaznaczoną przerywaną linią granicy zaufania.
Cztery pierwsze elementy opiszemy szybko, bo są intuicyjne. Czym różni się proces od magazynu? Proces COŚ ROBI; magazyn tylko TRZYMA. A encja zewnętrzna od procesu? Encja jest poza Twoją kontrolą: nie napiszesz jej kodu i nie naprawisz jej błędów. Proces jest Twój. Przepływ to po prostu strzałka pokazująca dane w drodze z jednego miejsca w drugie. Tyle.
A teraz piąty element. Ten zasługuje na osobny akapit, bo to bohater całego diagramu.
Granica zaufania — bohater tego diagramu
Granica zaufania (ang. trust boundary) to przerywana linia, która oddziela obszary o różnym poziomie zaufania. I to nie jest ozdoba.
To właśnie NA granicach zaufania mieszka większość zagrożeń — bo tam dane z obszaru, któremu ufasz mniej, trafiają do obszaru, któremu ufasz bardziej.
Każda strzałka przecinająca przerywaną linię to czerwona flaga. Walidujesz to, co przez nią wpada? Sprawdzasz autoryzację? Szyfrujesz w tranzycie? To pierwsze miejsca, w które zaglądasz, gdy zaczynasz szukać zagrożeń STRIDE jako driver sesji. I dokładnie dlatego tak nas boli, gdy ktoś pomija granice zaufania na diagramie: to jak narysować mapę miasta bez zaznaczenia, gdzie kończy się Twoja dzielnica, a zaczyna cudza.
Jedna nota na koniec, żeby uciąć potencjalny spór. Symbole bierzemy z szablonu draw.io, który rekomendujemy na naszych warsztatach i projektach i to jest konwencja, której się tu trzymamy. Warto jednak wiedzieć, że oficjalna, akademicka notacja bywa inna (klasyczny Yourdon-DeMarco kontra konwencja Adama Shostacka z książki Threat Modeling). My o to wojen nie toczymy. Ważne jest jedno: żeby cały zespół czytał diagram tak samo. Reszta to detal.
DFD a diagram architektury a PFD — co czym
OK, ale czym to się różni od zwykłego diagramu architektury, który zespół już ma w repo? Już Ci mówimy!
Diagram architektury pokazuje KLOCKI (komponenty, serwery, warstwy) i to, jak są ze sobą połączone. To statyczna struktura, zdjęcie tego, z czego system jest zbudowany. DFD pokazuje, co dzieje się MIĘDZY tymi klockami — czyli dane w ruchu i granice zaufania, których diagram architektury zwykle nawet nie zaznacza. To dwa różne pytania zadane temu samemu systemowi.
Mała, praktyczna uwaga: jeśli masz już diagram architektury, możesz go użyć jako punktu startu do modelowania zagrożeń. Nie trzeba od razu przepisywać wszystkiego na DFD. Tylko zrób to świadomie: DFD i diagram architektury mają swoje plusy, oba wymagają trochę pracy, a sięgając po gotowy diagram architektury, warto wiedzieć, czego na nim nie zobaczysz, przede wszystkim przepływu danych i granic zaufania. Na pilota albo na start procesu to często rozsądny wybór.
Jest jeszcze trzeci zawodnik. PFD (ang. Process Flow Diagram), czyli diagram przepływu procesu, pokazuje kolejność kroków: krok 1, potem krok 2, potem krok 3. Bliżej user flow czy sekwencji zdarzeń. I tu ciekawostka: dla wielu programistów PFD bywa naturalniejszy niż DFD, bo programista myśli „co się dzieje po kolei”, a nie „jak płyną dane”. I to jest zupełnie OK. Cel to mieć obrazek, który zespół rozumie, a nie wygrać konkurs na czystość notacji.
Oba diagramy, DFD i PFD, działają w modelowaniu zagrożeń i można stosować je obok siebie. W praktyce wiele zespołów korzysta z obydwu: PFD do opisania sekwencji zdarzeń tam, gdzie jest naturalniejszy, DFD wszędzie tam, gdzie ważniejszy jest przepływ danych i granice zaufania. Cel to mieć obrazek, który zespół rozumie. Konkurs na czystość notacji nie wchodzi w grę.
| Diagram | Pokazuje | Pytanie, na które odpowiada | Granice zaufania? |
|---|---|---|---|
| Architektury | klocki i połączenia (struktura) | „z czego to się składa?" | zwykle nie |
| DFD | dane w ruchu MIĘDZY klockami | „jak płyną dane i gdzie przekraczają zaufanie?" | tak — to jego clou |
| PFD | kolejność kroków (sekwencja) | „co dzieje się po kolei?" | rzadziej; naturalny dla devów |
Diagram architektury mówi, Z CZEGO zbudowany jest system. DFD mówi, CO DZIEJE SIĘ MIĘDZY tymi klockami — i to właśnie tam szukamy zagrożeń.
„Mapa to nie teren”: po co w ogóle modelujemy
Mamy tu analogię w rękawie i nadszedł moment, żeby ją wyciągnąć: mapa to nie teren.
DFD jest mapą. A mapa z definicji upraszcza, pomija i zniekształca. I bardzo dobrze, bo mapa w skali 1:1 byłaby wielkości terenu, który opisuje, czyli zupełnie bezużyteczna. Nikt nie nosi przy sobie mapy miasta wielkości miasta. Twój DFD ma tak samo świadomie pomijać szczegóły — pokazywać dość, żeby było widać, gdzie boli, i ani grama więcej.
Jest takie zdanie, pod którym podpisujemy się rękoma i nogami: słowa statystyka George’a Boxa — „wszystkie modele są błędne, ale niektóre są przydatne”. Twój diagram nie odda systemu w 100% i nie ma takiego zadania. Ma być przydatny. To łączy się wprost z naszą zasadą małych kroków: jedna sesja daje tylko częściowy widok, i to jest w porządku. Nie martw się o kompletność. Lepszy diagram „wystarczająco dobry” dziś niż idealny nigdy.
Twój DFD ma być PRZYDATNY, nie KOMPLETNY. Rysujesz tyle, ile trzeba, żeby zobaczyć, gdzie boli — i wracasz później z innym przybliżeniem.
Jak narysować DFD krok po kroku
Dość teorii. Oto 5 kroków. Niczego nie musisz kupować: wystarczy tablica i kartki albo draw.io z szablonem DFD. Każdy krok to jedno zdanie „co robisz” i jedno „na co uważać”.
- Ustal zakres. Zdecyduj, CO modelujesz (jedną aplikację? jeden feature? cały system?) i, równie ważne, czego NIE. Uwaga: bez zakresu diagram puchnie w nieskończoność. (Zakres zależy od poziomu, do którego wracamy niżej.)
- Wypisz aktorów i encje zewnętrzne. Wskaż, kto i co rozmawia z systemem od zewnątrz: użytkownicy, inne systemy, zewnętrzne API. Uwaga: to są Twoje prostokąty na brzegach diagramu, wszystko, czego kodu nie piszesz.
- Narysuj procesy, magazyny i przepływy. Wrzuć to, co przetwarza dane (procesy), gdzie one spoczywają (magazyny), i pociągnij strzałki pokazujące, którędy płyną. Uwaga: zacznij od głównej ścieżki, a dopiero potem dorzucaj boczne, inaczej utoniesz.
- Zaznacz granice zaufania. Przerywanymi liniami oddziel obszary o różnym poziomie zaufania: internet kontra backend, aplikacja kontra baza, serwis A kontra serwis B. Uwaga: to NAJWAŻNIEJSZY krok. Strzałki przecinające te linie to Twoja gotowa lista miejsc do obejrzenia.
- Oznacz, gdzie żyją wartościowe dane. Przy magazynach i przepływach zaznacz, gdzie siedzą dane wrażliwe i krytyczne. Uwaga: to one decydują, gdzie ryzyko jest realne, a gdzie kosmetyczne. Bez tego potraktujesz formularz kontaktowy tak samo poważnie jak bazę z danymi kart.
Gdy przejdziesz te 5 kroków, diagram jest gotowy, ale gotowy jako wejście do sesji, nie jako cel sam w sobie. Teraz dopiero zaczynasz pytać „co może pójść źle” sesja krok po kroku, jeżdżąc driverem po elementach diagramu STRIDE jako driver.
Skończony DFD nie jest celem — jest punktem startu sesji.
Na koniec garść mikro-wskazówek, które oszczędzą Ci nerwów:
- Trzymaj się jednego poziomu szczegółowości na jednym diagramie: nie mieszaj lotu ptaka z pojedynczą funkcją.
- Nazywaj przepływy konkretnie: nie „dane”, tylko „token sesji” czy „numer karty”.
- Jeden diagram na jedno pytanie; nie próbuj zmieścić całego świata na jednej kartce.
- Nie poleruj. Przydatny bije kompletny (patrz wyżej).
DFD to NIE STRIDE
Tu prostujemy bardzo częste nieporozumienie. Mnóstwo ludzi wrzuca DFD i STRIDE do jednego worka: „modelowanie zagrożeń to DFD plus STRIDE i tyle”. Otóż NIE. To dwie zupełnie różne rzeczy, które robią dwie różne robotę.
DFD to NOTACJA: sposób, w jaki przedstawiasz system, czyli obrazek. STRIDE to DRIVER — narzędzie do burzy mózgów, które NAPĘDZA sesję, podsuwając pytanie „co może pójść źle” dla każdego elementu po kolei. Mówiąc krótko:
DFD to mapa. STRIDE to sposób, w jaki po niej chodzisz. Nie myl notacji z narzędziem, które ją napędza.
I jeszcze jedno: STRIDE to taksonomia używana jako driver, a NIE metodyka. To już temat na osobny artykuł STRIDE: driver, nie metodyka.
Kolejność jest stała: najpierw rysujesz DFD, potem driver jeździ po jego elementach, zwłaszcza po tych strzałkach przecinających granice zaufania. I tu rzecz, którą warto zapamiętać: driver możesz wymienić, a DFD zostaje ten sam. Patrzysz pod kątem prywatności? Sięgasz po TRIM zamiast STRIDE. Chcesz oprzeć sesję na znanych klasach ataków? Bierzesz bibliotekę ataków (np. OWASP Top 10). Diagram się nie zmienia, zmienia się tylko to, czym po nim chodzisz.
Działa to też w drugą stronę: nie jesteś przywiązany do samej notacji. Ten sam driver (STRIDE czy inny) możesz puścić nie tylko po DFD, ale i po PFD, diagramie architektury, modelu C4, a nawet po spisanej liście wymagań, i to też będzie modelowanie zagrożeń. Notacja i driver to dwie niezależne osie: jedną zmieniasz, nie ruszając drugiej.
Na których poziomach działa DFD (i kiedy sięgnąć po C4)
Krótka, ale ważna rzecz, bo to częste pytanie. DFD jest notacją level-agnostic — technicznie działa na każdym poziomie modelowania. Nie ma żadnego prawa zakazującego rysować DFD dla całej organizacji.
Ma jednak swoje naturalne miejsce. Na poziomie aplikacji i funkcjonalności pasuje najlepiej, tam gdzie patrzysz na komponenty i przepływy danych wewnątrz jednej aplikacji. Wyżej bywa inaczej. Na poziomie systemu (zestaw aplikacji plus integracje) naturalniejszy często okazuje się diagram architektury albo C4. A na poziomie organizacji ważniejszy od notacji bywa wybór drivera sesji — to tam wchodzi np. MITRE ATT&CK. Pełną mapę „kto, na co i czym patrzy na którym poziomie” rozkładamy w przewodniku po poziomach modelowania zagrożeń.
Zasada, która porządkuje cały ten temat: notacja to osobna oś od drivera sesji. DFD mówi, na czym modelujesz. STRIDE czy ATT&CK mówi, czym szukasz zagrożeń. To dwie niezależne decyzje; możesz połączyć DFD z dowolnym driverem.
A C4? C4 (ang. C4 model) to alternatywna notacja, która daje wiele widoków jednego systemu i działa na różnych poziomach. Ale z jednym zastrzeżeniem: ma sens tylko wtedy, gdy zespół ją zna. Bo i tu obowiązuje ta sama reguła co przy DFD — używaj notacji, którą organizacja już rozumie. Nie ma sensu wdrażać C4 tylko po to, żeby raz narysować model.
DFD jest level-agnostic: działa na każdym poziomie. W praktyce naturalnie pasuje niżej (aplikacja, funkcjonalność); wyżej sięgnij po C4 lub diagram architektury — byle wszyscy w zespole czytali to tak samo.
Co robić, jak żyć?
Zbierzmy to w pięć praktycznych kroków na wynos:
- Weź narzędzie, którego nie trzeba kupować. Tablica i kartki albo draw.io z szablonem DFD. Tyle wystarczy.
- Ustal zakres na jeden poziom. Najpewniej aplikacja albo feature: to tam DFD pasuje najnaturalniej poziomy modelowania zagrożeń.
- Przejdź 5 kroków. Aktorzy i encje zewnętrzne, potem procesy, magazyny i przepływy, potem granice zaufania, na końcu wartościowe dane.
- Potraktuj diagram jako wejście do sesji, nie jako cel. Odpal driver po jego elementach i przekuj zagrożenia w akcje STRIDE · sesja krok po kroku · 5 formatów akcji do backloga.
- Nie poleruj. Przydatny bije kompletny. Wróć z innym przybliżeniem później.
To NIE jest rocket science. Pierwszy model stworzysz w godzinę, a jako artefakt przyda Ci się też tam, gdzie regulacje (NIS2, DORA, CRA) każą udowodnić, że wiesz, co Ci zagraża modelowanie zagrożeń a NIS2/DORA/CRA.
Damy Ci znać, gdy opublikujemy coś nowego.
Artykuł albo odcinek podcastu. Bez spamu. W każdej chwili możesz się wypisać.
Zapisując się, akceptujesz politykę prywatności.
Referencje i wzmianki: Adam Shostack, Threat Modeling: Designing for Security (notacja DFD i granice zaufania); draw.io (wraz z szablonem DFD / threat modeling); George Box („all models are wrong, but some are useful”); model C4 (c4model.com, jako alternatywna notacja). Oficjalna, akademicka notacja DFD (Yourdon-DeMarco kontra konwencja Shostacka) bywa różna; istotne, by zespół czytał diagram jednakowo.