„Security by design” trafiło na slajdy sprzedażowe i do rozporządzeń, więc zaczęło znaczyć wszystko i nic. A pod spodem jest jedna, konkretna idea, na tyle konkretna, że zbudowaliśmy na niej całą firmę; nasze motto brzmi „bezpieczeństwo wbudowane, nie doklejone”.
Teza tego tekstu jest prosta: security by design to podejście, w którym bezpieczeństwo jest cechą PROJEKTU, wbudowaną od etapu projektowania, a nie warstwą doklejaną tuż przed audytem. Pokażemy to po kolei. Najpierw definicja i analogia. Potem trzy rzeczy, z którymi security by design bywa mylone. Dalej, jak wygląda w tygodniu pracy. Na końcu, od czego zacząć. Zapraszamy do lektury.
Definicja i analogia: dom i płot
Definicja w dwóch zdaniach: security by design (ang., dosłownie „bezpieczeństwo w fazie projektowania”) to podejście, w którym wymagania i decyzje dotyczące bezpieczeństwa powstają razem z projektem systemu, zanim powstanie kod czy infrastruktura. Bezpieczeństwo jest w nim wbudowane w architekturę, a nie dodawane po fakcie.
Mamy do tego analogię w rękawie. Projektując dom, ogrodzenie planujesz już na etapie rysunków razem z oknami i drzwiami. Oczywiście płot da się dostawić po pierwszym włamaniu, ale będzie brzydszy, droższy i na zawsze zostanie „doklejony” z boku. Z systemami jest tak samo: bezpieczeństwo dorobione na końcu zawsze kosztuje więcej i zawsze odstaje od reszty.
Skąd ta różnica w koszcie? Ponieważ im później złapiesz problem, tym drożej będzie Cię kosztować jego usunięcie. To jest ekonomiczny silnik całego podejścia (krzywą kosztu pokazujemy w przewodniku).
Security by design znaczy, że bezpieczeństwo jest świadomą decyzją projektową, a nie poprawką wdrażaną „po wszystkim”.
Z czym się myli (trzy odróżnienia)
Wokół tego pojęcia narosły trzy nieporozumienia. Warto je rozdzielić, bo każde prowadzi gdzie indziej.
To nie privacy by design. Prywatność i bezpieczeństwo to dwie różne osie: system bezpieczny może w ogóle nie dbać o prywatność, a system dbający o prywatność może być dziurawy. „Ochrona danych w fazie projektowania” (ang. privacy by design, w RODO ujęta w artykule 25) dotyczy danych osobowych; security by design dotyczy odporności całego systemu. Pojęcia pokrewne, ale nie tożsame.
To nie secure by default. By design to decyzje podejmowane w projekcie; secure by default (dosłownie „bezpieczne domyślnie”) to bezpieczne ustawienia fabryczne: brak haseł domyślnych, wyłączone zbędne usługi, bezpieczne opcje prosto „z pudełka”. Jedno bez drugiego kuleje. W praktyce spina je wzorzec Secure Defaults: bezpieczna ścieżka ma być dla dewelopera ścieżką najmniejszego oporu, a nie dodatkową pracą.
To nie „kupiliśmy narzędzie” ani „przeszliśmy audyt”. Narzędzie skaluje proces, nie osąd; audyt sprawdza stan, ale niczego nie projektuje. Security by design to praktyki wpięte w cykl wytwórczy, a nie pozycja na fakturze. Zgodność z regulacją i realne bezpieczeństwo to zresztą dwie różne rzeczy (piszemy o tym przy NIS2, DORA i CRA).
By design znaczy: w projekcie. By default: w ustawieniach. Kupione: ani jedno, ani drugie.
Jak to wygląda w praktyce
Dobrze, ale co to znaczy w tygodniu pracy, żeby nie zostało hasłem ze slajdu? Kilka konkretnych praktyk:
- Modelowanie zagrożeń jako pierwszy krok: ustrukturyzowane pytanie „co może pójść źle?” zadane na etapie projektu, zanim powstanie kod (sesja krok po kroku). To jedyna w pełni proaktywna praktyka bezpieczeństwa, więc pracuje inaczej niż pentest po fakcie.
- Wymagania bezpieczeństwa w definicji funkcji: kryteria akceptacji i wpisy do Definition of Done, zamiast osobnego „bezpieczeństwa na później” (pięć formatów akcji).
- Zasady architektoniczne: minimalna powierzchnia ataku, najmniejsze potrzebne uprawnienia, bezpieczne ustawienia domyślne. Trzymamy się przy tym doktryny, że źródłem prawdy zawsze powinny być kontrole globalne.
- Rytm, nie zryw: bezpieczeństwo wbudowujesz małymi dawkami, przy każdej zmianie, a nie jednym wielkim projektem raz do roku. To różnica między modelowaniem globalnym a iteracyjnym.
Security by design nie kończy się na zapisie w polityce. Widać je w tym, co Twój zespół robi w tygodniu, w którym projektuje.
Regulacje mówią o tym wprost
Wątek jest krótki, ale dla wielu zespołów rozstrzygający. CRA (ang. Cyber Resilience Act) wymaga, by produkty z elementami cyfrowymi projektować „bez znanych, możliwych do wykorzystania podatności”, wprost w duchu security by design. NIS2 i polska ustawa o KSC mówią z kolei o „bezpiecznym cyklu rozwojowym” i o analizie wymogów bezpieczeństwa na etapie projektowania. Innymi słowy: regulator opisuje dokładnie to podejście, tylko bez chwytliwej nazwy (co konkretnie i od kiedy, rozkładamy osobno).
Regulacje nie każą kupić „security by design”. Każą je praktykować.
Co robić, jak żyć?
Pięć kroków na start:
- Zacznij od jednej sesji modelowania zagrożeń dla najbliższej zmiany (przewodnik po sesji). To najtańszy pierwszy krok w stronę security by design.
- Wpisz bezpieczeństwo w definicję „zrobione”: kryteria akceptacji i Definition of Done (pięć formatów).
- Ustal dwie, trzy zasady architektoniczne (najmniejsze uprawnienia, minimalna powierzchnia ataku, bezpieczne ustawienia domyślne) i egzekwuj je w przeglądach kodu.
- Sprawdź, czego wymaga od Ciebie regulacja (NIS2, DORA, CRA).
- Zaplanuj, jak rozlać to na organizację.
Security by design nie jest produktem, który się wdraża i odhacza. To sposób pracy, w którym bezpieczeństwo jest domyślnym składnikiem projektu, a nie dodatkiem doklejanym, gdy „trzeba jeszcze przejść audyt”.
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: CISA „Secure by Design” (inicjatywa międzynarodowa); RODO, artykuł 25 („ochrona danych w fazie projektowania i domyślnie”); CRA (Cyber Resilience Act) oraz rozporządzenie wykonawcze (UE) 2024/2690; OWASP.