Karta Przedmiotu
| Politechnika Białostocka | Wydział Informatyki | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Kierunek studiów | Cyberbezpieczeństwo |
Poziom i forma studiów |
pierwszego stopnia stacjonarne |
||||||||||||||||||||||||
| Grupa przedmiotów / specjalność |
Profil kształcenia | ogólnoakademicki | |||||||||||||||||||||||||
| Nazwa przedmiotu | Architektury systemów informatycznych | E | Kod przedmiotu | CYB1WMB | |||||||||||||||||||||||
| Rodzaj zajęć | obowiązkowy | ||||||||||||||||||||||||||
| Formy zajęć i liczba godzin | W | Ć | L | P | Ps | T | S | Semestr | 4 | ||||||||||||||||||
| 30 | 30 | Punkty ECTS | 5 | ||||||||||||||||||||||||
| Program obowiązuje od | 2026/2027 | ||||||||||||||||||||||||||
| Przedmioty wprowadzające | |||||||||||||||||||||||||||
| Cele przedmiotu |
Przekazanie wiedzy z zakresu architektur współczesnych systemów informatycznych, od systemów monolitycznych po mikroserwisy i architektury chmurowe, ze szczególnym uwzględnieniem aspektów bezpieczeństwa. Rozwinięcie umiejętności analizy i projektowania architektury systemów ICT z perspektywy bezpieczeństwa, w tym identyfikowania zagrożeń i wbudowywania mechanizmów ochrony na poziomie architektonicznym (security-by-design). Kształtowanie umiejętności krytycznej oceny kompromisów architektonicznych w kontekście bezpieczeństwa, wydajności i utrzymywalności systemów. Odniesienia do frameworka edukacyjnego mikrokompetencji SFIA: Architektura rozwiązania ARCH - poziom 3 Bezpieczeństwo informacji SCTY – poziom 3 Architektura przedsiębiorstw i biznesu STPL - poziom 2 |
||||||||||||||||||||||||||
| Ramowe treści programowe | Przegląd paradygmatów architektonicznych systemów informatycznych: od monolitu do mikroserwisów, architektury zdarzeniowej, serverless i hybrydowych modeli chmurowych. Wzorce projektowe stosowane w inżynierii systemów: separacja warstw, zasady SOLID, wzorce integracyjne. Modelowanie architektury systemów: UML, C4 Model, ArchiMate. Bezpieczeństwo w cyklu życia architektury systemu: threat modeling, security-by-design, privacy-by-design. Zarządzanie tożsamością i dostępem jako komponent architektoniczny. Aspekty bezpieczeństwa w architekturach API, systemów rozproszonych i systemów legacy. | ||||||||||||||||||||||||||
| Inne informacje o przedmiocie | przedmiot ma związek z prowadzoną na Uczelni działalnością naukową | ||||||||||||||||||||||||||
| przedmiot kształtuje umiejętności praktyczne | |||||||||||||||||||||||||||
| Wyliczenie: | Nakład pracy studenta związany z: | Godzin ogółem |
W tym kontaktowych |
W tym praktycznych |
|||||||||||||||||||||||
| udziałem w wykładach | 30 | 30 | |||||||||||||||||||||||||
| udziałem w innych formach zajęć | 30 | 30 | 30 | ||||||||||||||||||||||||
| przygotowaniem do bieżących zajęć o charakterze praktycznym | 30 | 30 | |||||||||||||||||||||||||
| wykonaniem projektu | 25 | 25 | |||||||||||||||||||||||||
| przygotowaniem do egzaminu | 10 | ||||||||||||||||||||||||||
| Razem godzin: | 125 | 60 | 85 | ||||||||||||||||||||||||
| Razem punktów ECTS: | 5 | 2.4 | 3.4 | ||||||||||||||||||||||||
| Zakładane kierunkowe efekty uczenia się | Wiedza | Umiejętności | Kompetencje społeczne |
||||||||||||||||||||||||
| CYB1_W03 | CYB1_U07 | CYB1_K04 | |||||||||||||||||||||||||
| CYB1_W04 | CYB1_U11 | ||||||||||||||||||||||||||
| CYB1_W05 | CYB1_U13 | ||||||||||||||||||||||||||
| CYB1_W06 | |||||||||||||||||||||||||||
| CYB1_W17 | |||||||||||||||||||||||||||
| Cele i treści ramowe sformułował(a) | dr inż. Paweł Tadejko | Data: | 08/04/2026 | ||||||||||||||||||||||||
| Realizacja w roku akademickim | 2027/2028 | ||||||||||||||||||||||||||
| Treści programowe | |||||||||||||||||||||||||||
| Wykład | |||||||||||||||||||||||||||
| 1. | Wprowadzenie do architektur systemów informatycznych - definicja architektury, role architekta, przegląd paradygmatów, związek z bezpieczeństwem | ||||||||||||||||||||||||||
| 2. | Architektura monolityczna - struktura, zalety i ograniczenia bezpieczeństwa, typowe podatności, scenariusze modernizacji | ||||||||||||||||||||||||||
| 3. | Architektura warstwowa i N-tier - separacja warstw prezentacji, logiki biznesowej i danych; security boundaries | ||||||||||||||||||||||||||
| 4. | Architektura mikroserwisów - wzorzec dekomponowania, service mesh, komunikacja synchroniczna i asynchroniczna | ||||||||||||||||||||||||||
| 5. | Architektura zdarzeniowa (EDA) i kolejkowanie wiadomości - Kafka, RabbitMQ, bezpieczeństwo broker messaging | ||||||||||||||||||||||||||
| 6. | Architektura serverless i Function-as-a-Service - model wykonania, kontrola dostępu, ryzyka bezpieczeństwa | ||||||||||||||||||||||||||
| 7. | Architektura API-first i REST/GraphQL - projektowanie bezpiecznych API, OAuth 2.0 / OpenID Connect, rate limiting | ||||||||||||||||||||||||||
| 8. | Zarządzanie tożsamością i dostępem jako komponent architektury - IAM, SSO, federacja tożsamości, RBAC/ABAC | ||||||||||||||||||||||||||
| 9. | Security-by-design i privacy-by-design w architekturze systemów - zasady, wzorce implementacji, DevSecOps | ||||||||||||||||||||||||||
| 10. | Security-by-design i privacy-by-design w architekturze systemów - zasady, wzorce implementacji, DevSecOps | ||||||||||||||||||||||||||
| 11. | Modelowanie architektur - UML (diagramy sekwencji, komponentów), C4 Model, notacja ArchiMate | ||||||||||||||||||||||||||
| 12. | Modelowanie architektur - UML (diagramy sekwencji, komponentów), C4 Model, notacja ArchiMate | ||||||||||||||||||||||||||
| 13. | Architektura systemów legacy - integracja starszych systemów, bramki API, zarządzanie ryzykiem systemów legacy | ||||||||||||||||||||||||||
| 14. | Bezpieczeństwo systemów rozproszonych - problemy CAP theorem, distributed tracing | ||||||||||||||||||||||||||
| 15. | Bezpieczeństwo komunikacji w systemach rozproszonych | ||||||||||||||||||||||||||
| Pracownia specjalistyczna | |||||||||||||||||||||||||||
| 1. | Wprowadzenie do narzędzi modelowania i scenariusz projektowy - konfiguracja draw.io / C4-PlantUML; omówienie scenariusza biznesowego; pierwszy szkic diagramu kontekstowego (C4 Level 1) | ||||||||||||||||||||||||||
| 2. | Diagram kontenerów (C4 Level 2) - identyfikacja głównych kontenerów (aplikacja webowa, API, baza danych, usługi zewnętrzne); naniesienie granic zaufania i przepływów danych | ||||||||||||||||||||||||||
| 3. | Diagram komponentów (C4 Level 3) - uszczegółowienie wybranego kontenera; identyfikacja komponentów wewnętrznych i ich interfejsów | ||||||||||||||||||||||||||
| 4. | Architektura monolityczna vs. mikroserwisowa - przeprojektowanie dotychczasowego systemu z monolitu na wariant mikroserwisowy; porównanie diagramów, analiza konsekwencji bezpieczeństwa | ||||||||||||||||||||||||||
| 5. | Diagramy przepływu danych (DFD) - sporządzenie DFD dla kluczowych procesów systemu; oznaczenie granic zaufania, zewnętrznych podmiotów i magazynów danych | ||||||||||||||||||||||||||
| 6. | Projektowanie bezpieczeństwa warstwy API - uzupełnienie diagramów o mechanizmy uwierzytelniania i autoryzacji (OAuth2/OIDC schematycznie), rate limiting, szyfrowanie; specyfikacja OpenAPI dla wybranego endpointu | ||||||||||||||||||||||||||
| 7. | Architektura warstwy danych - diagram architektury bazy danych z uwzględnieniem podziału na strefy (hot/warm/cold), szyfrowania w spoczynku, polityk dostępu i backupu | ||||||||||||||||||||||||||
| 8. | Projektowanie pod kątem wysokiej dostępności i odtwarzania po awarii - rozszerzenie diagramów o elementy redundancji, load balancing, failover; naniesienie RTO/RPO na schemat architektury | ||||||||||||||||||||||||||
| 9. | Architektura środowiska wdrożeniowego - diagram infrastruktury: strefy sieci, firewalle, segmentacja, środowiska (dev/staging/prod); uwzględnienie modelu chmurowego lub hybrydowego | ||||||||||||||||||||||||||
| 10. | Security review i walidacja projektu - przegląd kompletnego zestawu diagramów pod kątem zasad security-by-design; identyfikacja i udokumentowanie decyzji architektonicznych (Architecture Decision Records) | ||||||||||||||||||||||||||
| 11. | Finalizacja dokumentacji i przygotowanie do obrony - skompletowanie pakietu architektonicznego: diagramy C4 (poziomy 1–3), DFD, diagram infrastruktury, ADR; przygotowanie krótkiej prezentacji uzasadniającej wybory projektowe | ||||||||||||||||||||||||||
| 12. | Realizacja projektu | ||||||||||||||||||||||||||
| 13. | Realizacja projektu | ||||||||||||||||||||||||||
| 14. | Realizacja projektu | ||||||||||||||||||||||||||
| 15. | Prezentacja i obrona projektu końcowego, wystawienie ocen | ||||||||||||||||||||||||||
| Metody dydaktyczne (realizacja stacjonarna) |
|||||||||||||||||||||||||||
| W | wykład problemowy, wykład informacyjny, wykład z prezentacją multimedialną | ||||||||||||||||||||||||||
| Ps | programowanie z użyciem komputera, metoda projektów | ||||||||||||||||||||||||||
| Metody dydaktyczne (realizacja zdalna) |
|||||||||||||||||||||||||||
| W | wykład problemowy, wykład informacyjny, wykład z prezentacją multimedialną | ||||||||||||||||||||||||||
| - | |||||||||||||||||||||||||||
| Forma zaliczenia | |||||||||||||||||||||||||||
| W | egzamin pisemny | ||||||||||||||||||||||||||
| Ps | zadania realizowane na zajęciach, ocena projektu | ||||||||||||||||||||||||||
| Warunki zaliczenia | |||||||||||||||||||||||||||
| W | Uzyskanie min. 30% punktów z każdego efektu uczenia się z zakresu wiedzy, a po spełnieniu tego warunku ostateczna ocena wynika z sumy uzyskanych punktów. Kryteria oceny: [ 0 – 50]% punktów – 2.0 (50 – 60]% punktów – 3.0 (60 – 70]% punktów – 3.5 (70 – 80]% punktów – 4.0 (80 – 90]% punktów – 4.5 (90 – 100]% punktów – 5.0 |
||||||||||||||||||||||||||
| Ps | Uzyskanie min. 30% punktów z każdego efektu uczenia się z zakresu umiejętności/kompetencji społecznych, a po spełnieniu tego warunku ostateczna ocena wynika z sumy uzyskanych punktów. Kryteria oceny: [ 0 – 50]% punktów – 2.0 (50 – 60]% punktów – 3.0 (60 – 70]% punktów – 3.5 (70 – 80]% punktów – 4.0 (80 – 90]% punktów – 4.5 (90 – 100]% punktów – 5.0 |
||||||||||||||||||||||||||
| Symbol efektu | Zakładane efekty uczenia się | Odniesienie do efektów uczenia się zdefiniowanych dla kierunku studiów | |||||||||||||||||||||||||
| Wiedza | Umiejętności | Kompetencje społeczne |
|||||||||||||||||||||||||
| Wiedza: student zna i rozumie | |||||||||||||||||||||||||||
| E1 | paradygmaty architektoniczne współczesnych systemów informatycznych (monolityczne, mikroserwisy, serverless, hybrydowe chmurowe) oraz wynikające z nich implikacje bezpieczeństwa. | ||||||||||||||||||||||||||
| E2 | zasady security-by-design i privacy-by-design oraz metodologie modelowania zagrożeń stosowane w projektowaniu systemów ICT. | ||||||||||||||||||||||||||
| E3 | wzorce zarządzania tożsamością i dostępem (IAM, OAuth2, OIDC, RBAC/ABAC) jako komponent architektury systemów. | ||||||||||||||||||||||||||
| Umiejętności: student potrafi | |||||||||||||||||||||||||||
| E4 | zaprojektować i udokumentować architekturę bezpiecznego systemu ICT z użyciem notacji C4 lub UML, uwzględniając mechanizmy ochrony na poziomie architektonicznym. | ||||||||||||||||||||||||||
| E5 | przeprowadzić analizę threat modeling dla systemu informatycznego z zastosowaniem metodologii STRIDE i opracować rekomendacje architektoniczne. | ||||||||||||||||||||||||||
| E6 | krytycznie ocenić kompromisy architektoniczne (wydajność vs. bezpieczeństwo, złożoność vs. utrzymywalność) i uzasadnić wybory projektowe. | ||||||||||||||||||||||||||
| Kompetencje społeczne: student jest gotów do | |||||||||||||||||||||||||||
| E7 | współpracy z interdyscyplinarnym zespołem projektowym (programiści, administratorzy, analitycy biznesowi) w zakresie integrowania wymagań bezpieczeństwa w procesie projektowania systemów. | ||||||||||||||||||||||||||
| Symbol efektu | Sposób weryfikacji efektu uczenia się | Forma zajęć na której zachodzi weryfikacja | |||||||||||||||||||||||||
| E1 | egzamin pisemny | W | |||||||||||||||||||||||||
| E2 | egzamin pisemny | W | |||||||||||||||||||||||||
| E3 | egzamin pisemny | W | |||||||||||||||||||||||||
| E4 | zadania realizowane na zajęciach, ocena projektu | Ps | |||||||||||||||||||||||||
| E5 | zadania realizowane na zajęciach, ocena projektu | Ps | |||||||||||||||||||||||||
| E6 | zadania realizowane na zajęciach, ocena projektu | Ps | |||||||||||||||||||||||||
| E7 | ocena projektu | Ps | |||||||||||||||||||||||||
| Literatura podstawowa | |||||||||||||||||||||||||||
| 1. | S. Newman, Od monolitu do mikrousług. Ewolucyjne wzorce przekształcania systemów monolitycznych, Helion, Gliwice, 2020 | ||||||||||||||||||||||||||
| 2. | S. Shrivastava, N. Srivastav, Podręcznik architekta rozwiązań. Poznaj reguły oraz strategie projektu architektury i rozpocznij niezwykłą karierę, Helion, Gliwice, 2023 | ||||||||||||||||||||||||||
| 3. | J. Gough, D. Bryant, M. Auburn, Architektura API, Helion, Gliwice, 2024 | ||||||||||||||||||||||||||
| 4. | S.S. Shetty, C.A. Kamhoua, L.L. Njilla, Blockchain i bezpieczeństwo systemów rozproszonych, Wydawnictwo Naukowe PWN, 2020 | ||||||||||||||||||||||||||
| 5. | D.W. Hubbard, R. Seiersen, Ryzyko w cyberbezpieczeństwie. Metody modelowania, pomiaru i szacowania ryzyka, Helion, Gliwice, 2024 | ||||||||||||||||||||||||||
| Literatura uzupełniająca | |||||||||||||||||||||||||||
| 1. | R.C. Martin, Czysta architektura. Struktura i design oprogramowania, Helion, Gliwice, 2022 | ||||||||||||||||||||||||||
| 2. | F. Swiderski, Modelowanie zagrożeń, APN Promise, 2005 | ||||||||||||||||||||||||||
| 3. | OWASP Threat Dragon - dokumentacja i szablony, dostępne online: https://owasp.org/www-project-threat-dragon/ | ||||||||||||||||||||||||||
| 4. | Simon Brown, The C4 model for visualising software architecture, dostępne online: https://c4model.com/ | ||||||||||||||||||||||||||
| Koordynator przedmiotu: | dr inż. Paweł Tadejko | Data: | 08/04/2026 | ||||||||||||||||||||||||