Diagramy architektury oprogramowania są podstawowym narzędziem komunikacji dla zespołów technicznych. Zamykają luki między abstrakcyjnymi wymaganiami a konkretną realizacją. Jednak typowy diagram architektury często skupia się wyłącznie na funkcjonalności i przepływie danych. Często pomija krytyczną warstwę kontrolek bezpieczeństwa, granic zaufania oraz strategii ograniczania zagrożeń. Gdy bezpieczeństwo traktowane jest jako pożądane dopiero w fazie projektowania, wady bezpieczeństwa są wbudowane w system jeszcze zanim zostanie napisany pierwszy wiersz kodu.

Model C4 zapewnia strukturalny sposób dokumentowania architektury oprogramowania poprzez hierarchię diagramów. Integracja rozważań dotyczących bezpieczeństwa na każdym poziomie hierarchii C4 pozwala architektom tworzyć język wizualny, który jasno przekazuje ryzyko, zgodność z wymogami oraz mechanizmy ochrony. Niniejszy przewodnik omawia sposób wbudowywania myślenia o bezpieczeństwie w diagramy poziomu Context, Container, Component i Code, bez konieczności używania określonych narzędzi lub dostawców.

🔍 Dlaczego widoczność bezpieczeństwa ma znaczenie w diagramach

Bezpieczeństwo często pozostaje niewidoczne, dopóki nie zawiedzie. Zapora ogniowa blokuje ruch, szyfrowanie zakłóca dane, a uwierzytelnianie potwierdza tożsamość. Te mechanizmy są niezbędne, a jednak rzadko są przedstawiane w standardowych dokumentach projektowych. Gdy bezpieczeństwo jest ukryte, staje się trudne do audytu, trudne do zrozumienia dla nowych członków zespołu oraz trudne do ochrony przed rozwijającymi się zagrożeniami.

Wbudowywanie bezpieczeństwa w diagramy architektury oferuje kilka istotnych zalet:

• Wspólne zrozumienie:Zespoły bezpieczeństwa i zespoły deweloperskie używają różnych języków. Wizualizacja kontrolek bezpieczeństwa na tym samym diagramie co przepływ aplikacji dopasowuje ich zrozumienie.
• Identyfikacja zagrożeń:Diagramy wyróżniają przepływy danych. Każdy przepływ danych to potencjalny wektor ataku. Wizualizacja tych ścieżek ułatwia identyfikację miejsc, gdzie dane mogą zostać ujawnione lub zmienione.
• Audyt zgodności:Wymagania często wymagają dowodu środków ochrony danych. Dobrze oznaczony diagram architektury stanowi dowód kontrolek bezpieczeństwa zaprojektowanych na etapie projektowania.
• Reakcja na incydenty:W trakcie incydentu bezpieczeństwa kluczowe jest zrozumienie, gdzie dane są przechowywane i jak się poruszają. Diagramy dostarczają mapę do ograniczenia szkód i naprawy.

🏗️ Przegląd hierarchii modelu C4

Model C4 to podejście warstwowe do dokumentowania architektury oprogramowania. Skaluje się od dużego obrazu do szczegółów implementacji. Każda warstwa służy innej grupie odbiorców i zapewnia inny poziom szczegółowości. Integracja bezpieczeństwa na odpowiedniej warstwie zapewnia, że odpowiednie informacje docierają do odpowiednich osób.

1. Diagram kontekstu (poziom 1):Opisuje system w jego środowisku. Skupia się na użytkownikach i systemach zewnętrznych.
2. Diagram kontenerów (poziom 2):Opisuje ogólną strukturę techniczną. Pokazuje systemy oprogramowania takie jak aplikacje internetowe, aplikacje mobilne i bazy danych.
3. Diagram komponentów (poziom 3):Opisuje ogólny projekt pojedynczego kontenera. Pokazuje elementy budowlane takie jak kontrolery, usługi i repozytoria.
4. Diagram kodu (poziom 4):Opisuje implementację pojedynczego komponentu. Pokazuje klasy i metody. Jest rzadko udostępniany zewnętrznie, ale jest kluczowy dla wewnętrznych przeglądów bezpieczeństwa.

🌍 Poziom 1: Bezpieczeństwo diagramu kontekstu

Diagram kontekstu to punkt wejścia. Definiuje granice systemu. Bezpieczeństwo na tym poziomie dotyczy granic zaufania i tożsamości. Musisz jasno rozróżnić, co znajduje się w Twojej strefie zaufania, a co poza nią.

🔑 Zarządzanie tożsamością i dostępem

Na poziomie kontekstu najważniejszym elementem bezpieczeństwa jest uwierzytelnianie. Musisz pokazać, kto ma prawo interakcji z systemem.

• Aktory ludzkie:Jasno oznacz użytkowników. Rozróżnij użytkowników administracyjnych i zwykłych użytkowników końcowych. Dostęp administracyjny często wymaga bardziej rygorystycznych kontrolek.
• Systemy zewnętrzne: Często są to najbardziej słabe miejsce. Pokaż, jak się uwierzytelniają. Czy używają kluczy API, tokenów OAuth czy wzajemnego TLS?
• Strefy zaufania: Użyj wizualnych wskazówek, aby oznaczyć granice zaufania. Pełna linia może oznaczać wysokie zaufanie wewnętrzne połączenie, podczas gdy kreska oznacza niskie zaufanie zewnętrzne połączenie.

🔗 Bezpieczeństwo przepływu danych

Każda linia na diagramie kontekstu reprezentuje przepływ danych. Nie wszystkie przepływy danych są równe. Niektóre przenoszą poufne informacje, podczas gdy inne przenoszą publiczne aktualizacje stanu.

• Wymagania szyfrowania:Zaznacz przepływy wymagające szyfrowania w tranzycie. Użyj etykiet takich jakHTTPSlubWSS.
• Obsługa danych osobowych: Jeśli dane zawierają informacje identyfikujące osobę, oznacz przepływ. Zapewnia to, że zespoły końcowe wiedzą, by stosować dodatkowe zabezpieczenia.
• Mechanizmy uwierzytelniania:Wskazuj, czy przepływ wymaga uwierzytelnienia. Na przykład,Token nośniklubCiasteczko sesjiwymóg powinien być zaznaczony na połączeniu.

📦 Poziom 2: Bezpieczeństwo diagramu kontenerów

Po ustaleniu granicy systemu diagram kontenerów dzieli ją na jednostki wdrażalne. To tutaj widoczne stają się kontrole bezpieczeństwa techniczne. Kontenery to zazwyczaj aplikacje internetowe, aplikacje mobilne, mikroserwisy lub bazy danych.

🛡️ Bezpieczeństwo sieci i strefy

Kontenery są często rozprowadzane na różnych strefach sieciowych. Wizualizacja tych stref pomaga zrozumieć segmentację sieci.

• Umiejscowienie DMZ: Pokaż, które kontenery są narażone na publiczny internet. Wymagają one najwyższej ostrożności.
• Usługi wewnętrzne: Pokaż, które kontenery są tylko wewnętrzne. Nie powinny one mieć bezpośredniego dostępu do internetu.
• Zasady zapory ogniowej: Użyj kodowania kolorów lub adnotacji, aby wskazać, które kontenery mogą ze sobą komunikować się. Zapobiega to rozprzestrzenianiu się w przypadku naruszenia zabezpieczeń.

🔐 Ochrona danych w spoczynku

Kontenery często przechowują dane. Niezależnie czy jest to baza danych, magazyn plików czy kolejka komunikatów, nośnik danych musi być zabezpieczony.

• Szyfrowanie w spoczynku:Wskazuje, czy dane przechowywane w kontenerze są szyfrowane. Jest to kluczowe dla zgodności z przepisami.
• Zarządzanie kluczami:Pokaż, gdzie przechowywane są klucze szyfrowania. Czy zarządzane są przez sam kontener, czy przez zewnętrzny serwis zarządzania kluczami?
• Klasyfikacja danych:Oznaczaj kontenery w zależności od wrażliwości danych, które przechowują.Publiczne, Wewnętrzne, Sekretne, lub Ograniczone.

📡 Ochrona protokołów

Protokoły używane między kontenerami określają poziom bezpieczeństwa wewnętrznej komunikacji.

• Wewnętrzne interfejsy API:Upewnij się, że wewnętrzne interfejsy API nie używają zwykłego HTTP. Oznacz połączenia za pomocą HTTPS lub gRPC z mTLS.
• Sieć usług:Jeśli używana jest sieć usług, wskazuje, że ruch między kontenerami jest automatycznie szyfrowany i uwierzytelniany.
• Protokoły zastarzałe:Jeśli używany jest protokół zastarzały, np. FTP lub niezaszyfrowany SMTP, zaznacz to jako obszar ryzyka wymagający poprawy.

⚙️ Poziom 3: Ochrona diagramu składników

Diagram składników przenika do wnętrza pojedynczego kontenera. Pokazuje logiczne elementy budowlane. Tutaj realizowane jest zapewnienie bezpieczeństwa.

🧩 Logika uwierzytelniania i autoryzacji

Logika bezpieczeństwa często jest rozproszona między komponentami. Jest istotne, aby pokazać, gdzie ta logika znajduje się.

• Obsługi uwierzytelniania:Zidentyfikuj komponenty odpowiedzialne za logowanie użytkowników. Są to wysokiej wartości cele dla atakujących.
• Pośrednictwo autoryzacji:Pokaż, gdzie odbywają się sprawdzania kontroli dostępu. Czy odbywa się to na poziomie kontrolera czy poziomie usługi?
• Weryfikacja tokena:Wskaż komponenty, które weryfikują tokeny bezpieczeństwa. Jeśli ta weryfikacja jest skupiona, zmniejsza to ryzyko niezgodnych zasad bezpieczeństwa.

🛑 Weryfikacja i oczyszczanie danych wejściowych

Naruszenia bezpieczeństwa często zaczynają się od złych danych wejściowych. Diagramy komponentów powinny wyróżniać miejsca przetwarzania danych wejściowych.

• Punkty wejścia:Zaznacz komponenty odbierające dane zewnętrzne. Są to pierwsza linia obrony przed atakami wstrzyknięcia.
• Logika oczyszczania:Pokaż komponenty odpowiedzialne za oczyszczanie danych przed ich zapisaniem lub przetworzeniem. Zapobiega to atakom typu SQL injection i cross-site scripting.
• Kodowanie danych wyjściowych:Wskaż, gdzie dane są kodowane przed wysłaniem do użytkownika. Zapewnia to, że złośliwe skrypty nie są wykonywane w przeglądarce.

📊 Rejestrowanie i monitorowanie

Operacje bezpieczeństwa opierają się na dziennikach. Jeśli nie możesz zobaczyć, co się stało, nie możesz wykryć naruszenia.

• Dzienniki bezpieczeństwa:Zidentyfikuj komponenty generujące dzienniki związane z bezpieczeństwem. Przykłady to nieudane próby logowania, odmowy uprawnień oraz zmiany konfiguracji.
• Zagregowanie dzienników:Pokaż, gdzie są wysyłane dzienniki. Czy są wysyłane do centralnego serwisu rejestrowania? Zapewnia to, że dzienniki nie zostaną utracone, jeśli komponent zostanie naruszony.
• Maskowanie danych poufnych:Wskaż, czy dzienniki są oczyszczane, aby zapobiec wyciekom poświadczeń lub poufnych danych.

🧠 Poziom 4: Bezpieczeństwo diagramu kodu

Diagram kodu to najszczegółowszy poziom. Pokazuje klasy i metody. Choć rzadko jest udostępniany poza zespołem deweloperskim, jest niezbędny do głębokiej analizy bezpieczeństwa.

🔒 Operacje kryptograficzne

Na tym poziomie możesz dokładnie zobaczyć, jak wykorzystywana jest kryptografia.

• Ukryte tajemnice w kodzie:Sprawdź, czy w strukturze kodu znajdują się zakodowane klucze API lub hasła. Powinny one być oznaczone jako krytyczne luki bezpieczeństwa.
• Użycie algorytmów: Upewnij się, że używane są silne algorytmy. Słabe algorytmy, takie jak MD5 lub SHA1, należy unikać.
• Generowanie liczb losowych: Upewnij się, że do generowania identyfikatorów sesji i tokenów używane są kryptograficzne generatory liczb losowych.

🧪 Testy jednostkowe zabezpieczeń

Wymagania dotyczące zabezpieczeń muszą być testowane. Diagram kodu może pokazywać, gdzie są zdefiniowane testy zabezpieczeń.

• Przypadki testów zabezpieczeń: Zidentyfikuj metody poświęcone testom zabezpieczeń. Powinny one obejmować obejście uwierzytelniania, wstrzykiwanie danych oraz kontrolę dostępu.
• Testy integracyjne: Pokaż, jak testowane są kontrole zabezpieczeń w kontekście całego systemu.

🚧 Strefy zaufania i granice

Na wszystkich poziomach modelu C4 strefy zaufania to powtarzający się temat. Strefa zaufania to obszar, w którym kontrole zabezpieczeń są spójne, a granice dobrze zdefiniowane.

Typ strefy	Poziom zaufania	Typowe kontrole	Reprezentacja na diagramie
Zewnętrzna internet	Zero Trust	Branżowe zapory, WAF, TLS	Przerywana czerwona obramowa
DMZ	Niskie zaufanie	Ścisłe filtrowanie, ograniczony dostęp	Przerywana pomarańczowa obramowa
Sieć wewnętrzna	Średnie zaufanie	Segmentacja sieci, uwierzytelnianie	Pełna niebieska obramowa
Bezpieczne jądro	Wysokie zaufanie	Szyfrowanie, zarządzanie kluczami, audyt	Pełny zielony obramowanie

Wizualizacja tych stref pomaga stakeholderom zrozumieć profil ryzyka różnych części systemu. Naruszenie DMZ nie powinno zagrozić Bezpiecznemu Jądrzu. Ten koncept nazywa się obroną na głębinę.

🧩 Powszechne wzorce bezpieczeństwa w C4

Niektóre wzorce bezpieczeństwa pojawiają się często w różnych architekturach. Dokumentowanie tych wzorców jasno oszczędza czas i zmniejsza zamieszanie.

🔑 Wzorzec bramy interfejsu API

Brama interfejsu API działa jako jedyny punkt wejścia dla wszystkich żądań klientów. Obsługuje uwierzytelnianie, ograniczanie szybkości i routowanie.

• Umiejscowienie: Znajduje się między zewnętrznymi użytkownikami a wewnętrznymi kontenerami.
• Rola bezpieczeństwa: Przenosi logikę bezpieczeństwa z poszczególnych usług, zapewniając spójne stosowanie zasad.
• Uwaga do diagramu: Oznacz bramę jako AuthN/AuthZ etykiety.

🔒 Wzorzec szyfrowania danych

Dane muszą być chronione w spoczynku i w trakcie przesyłania. Jest to podstawowy wzorzec.

• W trakcie przesyłania: Używaj TLS do wszystkich komunikacji sieciowej.
• W spoczynku: Szyfruj bazy danych i magazyny plików.
• Klucze: Przechowuj klucze oddzielnie od danych.

👁️ Wzorzec rejestrowania audytu

Każda istotna czynność powinna być zapisywana w dzienniku. Jest to istotne dla analizy kryminalistycznej.

• Co zapisywać w dzienniku: Działania użytkownika, zmiany systemu i zdarzenia bezpieczeństwa.
• Integralność dziennika: Upewnij się, że atakujący nie mogą zmieniać dzienników.
• Zachowanie: Określ, jak długo są przechowywane dzienniki w celu zgodności.

🔄 Konserwacja i ewolucja

Bezpieczeństwo to nie jednorazowe zadanie. Systemy ewoluują, zagrożenia się zmieniają, a nowe luki bezpieczeństwa są odkrywane. Diagramy architektury muszą ewoluować razem z nimi.

📅 Aktualizacja diagramów

Gdy wprowadzana jest zmiana w systemie, diagram powinien zostać zaktualizowany. Zapewnia to, że dokumentacja pozostaje wiarygodnym źródłem informacji.

• Kontrola zmian: Zintegruj aktualizacje diagramów z potokiem wdrażania.
• Cykle przeglądu: Zaprojektuj okresowe przeglądy diagramów architektury wraz z zespołem bezpieczeństwa.
• Wersjonowanie: Przechowuj wersje diagramów, aby śledzić zmiany kontrolek bezpieczeństwa w czasie.

🧪 Integracja modelowania zagrożeń

Modelowanie zagrożeń to proces identyfikacji potencjalnych zagrożeń bezpieczeństwa. Działa w takt z diagramami C4.

• Model STRIDE: Użyj modelu STRIDE (fałszowanie, modyfikacja, zaprzeczenie, ujawnienie informacji, negacja usługi, podniesienie uprawnień) do przeglądu każdego elementu na diagramie.
• Analiza przepływu danych: Przejdź przez każdy przepływ danych na diagramie. Zadaj pytanie, czy dane są chronione na każdym etapie.
• Identyfikacja aktywów: Zidentyfikuj aktywy o wysokiej wartości na diagramie. Skup się na ochronie tych aktywów.

📝 Lista kontrolna dla diagramów bezpieczeństwa

Użyj tej listy kontrolnej, aby upewnić się, że Twoje diagramy C4 są gotowe pod kątem bezpieczeństwa.

• [ ] Czy granice zaufania są jasno oznaczone?
• [ ] Czy szyfrowanie w transmisji jest oznaczone we wszystkich przepływach danych?
• [ ] Czy szyfrowanie w spoczynku jest oznaczone dla kontenerów przechowywania?
• [ ] Czy punkty uwierzytelniania są oznaczone?
• [ ] Czy przepływy danych poufnych są wyróżnione?
• [ ] Czy zależności zewnętrzne zostały zidentyfikowane i ocenione?
• [ ] Czy segmenty sieci i strefy są wizualizowane?
• [ ] Czy punkty rejestrowania i monitorowania są pokazane?
• [ ] Czy znane luki bezpieczeństwa są zapisane?
• [ ] Czy diagramy są aktualizowane wraz z zmianami kodu?

💡 Ostateczne rozważania dotyczące wizualizacji bezpieczeństwa

Tworzenie systemów bezpiecznych wymaga więcej niż tylko pisanie bezpiecznego kodu. Wymaga to bezpiecznego projektowania. Model C4 oferuje solidny framework do wizualizacji tego projektowania. Wbudowując myślenie o bezpieczeństwie we wszystkie warstwy, od diagramu kontekstu po poziom kodu, zespoły mogą tworzyć systemy, które są odpornościowe domyślnie.

Bezpieczeństwo to wspólna odpowiedzialność. Gdy diagramy jasno przekazują kontrole bezpieczeństwa, programiści, operatorzy i inżynierowie bezpieczeństwa mogą skuteczniej współpracować. Ta wspólna widoczność zmniejsza ryzyko i buduje zaufanie do oprogramowania, które jest dostarczane. Pamiętaj, że diagram to dokument żywy. Powinien być traktowany z taką samą starannością, jak kod, który reprezentuje.