Zero Trust, chmura i bezpieczna architektura enterprise

Domena 3 SY0-701 — Security Architecture — testuje, czy potrafisz rozumieć, gdzie zaufanie się zaczyna, gdzie kończy i co się dzieje, gdy atakujący przekroczy narysowaną linię. Około 18% egzaminu. Nazwy narzędzi mniej niż wzorce: segmentacja, dostęp oparty na tożsamości, shared responsibility w chmurze, odporność wbudowana w design — nie dokładana po findingu audytu.

Ten wpis łączy modele wdrożenia, zasady Zero Trust, wzorce infrastruktury enterprise i pułapki chmurowe — ze scenariuszami pod egzamin.

Modele architektury i co zmieniają dla bezpieczeństwa

Każdy model przesuwa kto jest właścicielem której kontroli i gdzie płyną dane. Stemy często ukrywają model wprost („IdP to Azure AD, ale payroll zostaje w piwnicy”).

On-premises

On-premises — organizacja operuje obiekty, sprzęt, sieci i większość stacku. Plus: pełna widoczność i egzekwowanie polityk przy staff i budżecie. Minus: własne patching, dostęp fizyczny, zasilanie, chłodzenie, każda misconfiguration.

Kiedy egzamin faworyzuje myślenie on-prem: Segmenty air-gapped, ścisła data residency, legacy bez migracji, język regulacyjny o kontroli fizycznej.

Chmura

Chmura (IaaS, PaaS, SaaS) przenosi operacje do providera, ale nie odpowiedzialność za dane i tożsamości. Shared responsibility model jest obowiązkowy:

Linia zależy od vendora — CompTIA oczekuje wiedzy, że źle skonfigurowane zasoby chmurowe to nadal Twój problem.

Hybryda i multicloud

Hybryda łączy on-prem i chmurę (lub wiele chmur). Federacja tożsamości, VPN/private links, zduplikowane logowanie, niespójny patch cadence — mnożenie granic zaufania. User autentykowany w SaaS może nadal sięgać on-prem SQL przez connector zapomniany na diagramie.

Wzorzec stemu: „CRM w SaaS, HR DB on-prem.” Silne odpowiedzi: SSO/MFA, conditional access, szyfrowany transit, DLP na eksport, ścieżki sieciowe bez hairpin przez słaby link, logowanie w obu światach z jasną własnością.

IoT, OT i ICS

IoT/OT/ICS priorytetyzują dostępność i bezpieczeństwo fizyczne nad szybkim patchingiem. Restart PLC w produkcji może być niedopuszczalny; agresywne skany credentialed mogą crashować urządzenia.

Implikacje:

• Długie okna patchy i firmware od vendora
• Segmentacja IT/OT (myślenie Purdue)
• Monitoring anomalii protokołów, nie tylko CVE
• Ograniczenia fizyczne i środowiskowe (HVAC, sensory) jako attack surface

Pułapka: „Patch wszystko w ten weekend”, gdy stem opisuje linie produkcyjne, które nie mogą stanąć.

Wirtualizacja, kontenery i IaC

Wirtualizacja koncentruje ryzyko na hypervisorze. VM escape rzadkie, ale architektonicznie istotne — kompromitacja hosta dotyka wszystkich gości.

Kontenery dzielą kernel hosta. Higiena obrazów (bez sekretów w warstwach), minimalne base images, RBAC orchestracji (nadmierne uprawnienia service account K8s = misconfiguration), podpisywanie registry.

Infrastructure as Code (IaC) — Terraform, CloudFormation, Ansible — czyni architekturę powtarzalną. Win, gdy szablony są reviewowane i skanowane; strata, gdy jeden zły moduł propaguje otwarte security groups wszędzie.

Przykład: terraform apply otwiera port 22 globalnie przez skopiowany moduł dev. Klasa: misconfiguration. Mitygacja: skan IaC w CI, policy-as-code (OPA/Sentinel), manual approval prod, CSPM.

Zero Trust: verify explicitly, assume breach

Zero trust to nie SKU produktu — postawa projektowa: never trust, always verify, least privilege, assume breach, microsegmentation z polityką świadomą tożsamości.

Tradycyjny VPN „zamek i fosa” często daje szeroki dostęp sieciowy po jednej autentykacji. Zero trust przesuwa decyzje na każde żądanie/sesję: kto, jaka postura urządzenia, jaki zasób, jaki risk score?

Elementy pod egzamin:

• Identity as perimeter — silna autentykacja (MFA), sygnały zdrowia urządzenia
• Microsegmentation — ograniczenie ruchu east-west, nie tylko north-south na firewall
• Continuous validation — impossible travel → re-auth lub block
• Logging and analytics — widoczność tożsamość, urządzenie, aplikacja, sieć

ZTNA (Zero Trust Network Access) zastępuje „VPN do całego LAN” dostępem per aplikacja przez broker. Stem: „kontrahenci tylko do jednej app, nie file serwerów” → ZTNA, nie full-tunnel VPN.

Pułapka: „Zero trust = bez firewall”. Fałsz — firewalls i PEP zostają; znika domyślne implicit trust.

Wzorce bezpiecznej infrastruktury enterprise

Segmentacja i screened subnets

Network segmentation ogranicza lateral movement — kluczowe w ransomware na „flat network”. Microsegmentation — ten sam pomysł na poziomie workload lub tożsamości.

Screened subnets (DMZ) wystawiają tylko konieczne usługi. Aplikacje wewnętrzne i bazy za kolejnymi granicami. Dual-homed serwery łączące DMZ i internal bez ścisłych reguł — klasyczny błąd egzaminu.

Internet → [WAF] → DMZ (web tier) → internal firewall → app tier → data tier

Uproszczony szkic; mentalny diagram powinien oznaczać granice zaufania na każdym skoku.

Bezpieczna łączność

VPN, IPsec site-to-site, MPLS/private links, ZTNA rozwiązują różne problemy. VPN szyfruje ścieżki; nie wymusza automatycznie least privilege w tunelu. Private links zmniejszają ekspozycję na public internet, ale nadal wymagają IAM i segmentacji na końcach.

Wysoka dostępność i load balancing

HA i load balancery wspierają availability — filar CIA, gdy DDoS lub SPOF. Active-active vs active-passive, health checks, dystrybucja geograficzna w narracjach disaster.

Pułapka: HA bez security — dwa serwery WWW z default admin creds to podwojone ryzyko, nie odporność.

Jump hosty i ścieżki privileged access

Administratorzy nie powinni RDP z domowych laptopów prosto na DC. Jump hosts/bastions, PAM, nagrywanie sesji, just-in-time elevation chronią płaszczyznę admin. Stem: „helpdesk używa domain admin dla wygody” → least privilege i PAM.

Umiejscowienie urządzeń i IoT

Kamery, drukarki, kontrolery HVAC nie na VLAN z bazami finansów. NAC i 802.1X wiążą tożsamość urządzenia z segmentem — zapowiedź Domeny 4, ale architektura musi najpierw alokować subnets i polityki.

Defense in depth done correctly

Defense in depth układa niezależne kontrolki przez tożsamość, endpoint, sieć, aplikację, dane, monitoring. Dwa identyczne firewalle z tą samą złą regułą to redundancja, nie głębokość.

Dobry przykład web app:

1. WAF na brzegu (warstwa aplikacji)
2. Segmentacja app i DB (sieć)
3. Parameterized queries (aplikacja)
4. Szyfrowanie DB + least-privilege DB user (dane)
5. MFA dla adminów (tożsamość)
6. SIEM korelujący auth i logi WAF (monitoring)

Jedna warstwa fail (WAF bypass) — inne nadal ograniczają blast radius.

Instynkty architektury chmurowej

Poza shared responsibility:

Tożsamość w chmurze: Zbyt szerokie role IAM, długowieczne access keys na serwerach, brak MFA na root/admin. Preferuj role nad keys, rotuj creds, permission boundaries.

Storage i ekspozycja: Public buckets, publiczne snapshoty, backupy w object storage bez access logging.

Widoczność: CASB dla shadow SaaS; CSPM — ciągła detekcja misconfiguration IaaS/PaaS. Akronimy mogą się różnić; idea ciągłej oceny postawy zostaje.

Szyfrowanie: Customer-managed keys (CMK/KMS) pod kontrolę regulacyjną; TLS wszędzie, gdzie dane przechodzą przez niezaufane sieci.

Przykład: Startup wrzuca API keys na GitHub. Awaria architektury: secrets management. Mitygacja: vault/secret manager, skan CI na wycieki, krótko żyjące tokeny — nie tylko „private repo”, jeśli są forki.

Architektura scenariusza hybrydowego

Stem: Regionalny bank przenosi chat klientów do SaaS; core banking zostaje na mainframe connectors on-prem.

Silny wątek odpowiedzi:

• Federacja/SSO + MFA dla agentów chat; oddzielnie od mainframe auth, gdzie wymagane
• Data minimization — co w logach chat (PII), limity retencji
• DLP blokujący eksport numerów kont do niesankcjonowanych kanałów
• Ścieżka sieciowa SaaS → connector on-prem przez kontrolowaną warstwę integracji, nie płaski VPN
• Vendor risk assessment, raporty SOC 2/ISO, SLA notification incydentów
• Logowanie do SIEM z audit API SaaS i connectora on-prem
• BCP/DR przy niedostępności SaaS — udokumentowany kanał zapasowy

Słabe: „Szyfruj laptopy” (ortogonalne) lub „air-gap internetu” (ignoruje potrzebę SaaS).

Ćwiczenie szkicowe

Narysuj trzy strefy: użytkownicy, warstwa aplikacji, warstwa danych. Umieść:

• Identity provider (IdP)
• WAF lub API gateway na brzegu
• Agregację logów SIEM
• Ścieżkę backupu poza strefą zaufania produkcji (immutable/offline)

Opisz każdą strzałkę protokołem i mechanizmem auth. Jeśli nie oznaczysz granic zaufania, pytania architektury to losowy wybór narzędzi. Powtórz dla wariantu hybrydowego z jednym boxem SaaS poza borderem sieci.

Podsumowanie pułapek

Zamknięcie części pierwszej Domeny 3

Pytania architektury: Gdzie zmienia się zaufanie? Kto może dotrzeć do czego? Co failuje bezpiecznie? Zero trust, segmentacja i shared responsibility to soczewki — nie buzzwordy do posypania na każdą odpowiedź.

Companion post o ochronie danych i odporności domyka drugą połowę secure design: po narysowaniu stref musisz sklasyfikować, co w nich mieszka, odpowiednio szyfrować i przetrwać utratę site lub weekendu systemów. Opanuj obie połowy — Domena 3 przestaje być testem słownictwa.