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 przeciwnik przekroczy granicę, którą narysowałeś. Około 18% egzaminu. Akronimy vendorów mniej niż wzorce: dostęp oparty na tożsamości, jawne granice zaufania, chmurowy shared responsibility model, microsegmentation oraz odporność wbudowana w design — nie dokładana po findingu audytu.

Ten wpis łączy modele wdrożenia enterprise, formalną Zero Trust Architecture według NIST SP 800-207, wzorce infrastruktury i pułapki chmurowe — ze scenariuszami i exam traps pod praktykę egzaminacyjną.

Modele architektury i co zmieniają dla bezpieczeństwa

Każda topologia przeciąga na nowo kto jest właścicielem której kontroli, jak federowana jest tożsamość i gdzie wrażliwe dane przekraczają granice fizyczne lub logiczne. Stemy często ukrywają model wprost — „Tożsamość jest w Azure AD, ale core payroll nadal stoi na sprzęcie w piwnicy” — i oczekują, że zrozumiesz, co te dwa światy dzielą i kto odpowiada za to, co wpada między nie.

On-premises oznacza, że organizacja utrzymuje obiekty, sprzęt, hypervisory, sieci i większość stacku oprogramowania. To kupuje pełną widoczność, custody kluczy na własnym HSM i ścisłą kontrolę suwerenności danych — ale tylko jeśli jest staff i budżet, by to odpowiedzialnie prowadzić. Druga strona monety: Ty odpowiadasz za kontrolę fizyczną obiektu, dostęp fizyczny, patching firmware i OS, zasilanie, chłodzenie i każdą misconfiguration. Gdy odpowiedzi egzaminu faworyzują myślenie on-prem, szukaj segmentów air-gapped ICS, ścisłego języka compliance o custody fizycznej albo workloadów, których po prostu nie da się przenieść.

Chmura i shared responsibility model

Modele chmurowe — IaaS, PaaS, SaaS — przenoszą obciążenie operacyjne infrastruktury fizycznej na Cloud Service Provider (CSP). Przeniesienie operacji nie przenosi odpowiedzialności za dane i postawę tożsamości. We wszystkich modelach klient nadal odpowiada za klasyfikację danych, decyzje o tożsamości i dostępie oraz konfigurację tego, co provider udostępnia. CompTIA oczekuje wiedzy, że źle skonfigurowane zasoby chmurowe to nadal Twój problem.

Zwięzły model mentalny — klient zawsze ma górny wiersz; własność CSP rośnie w górę, gdy idziesz w prawo:

                 On-prem     IaaS       PaaS       SaaS
Dane i tożsamość   TY         TY         TY         TY
Aplikacje          TY         TY         TY      CSP+TY*
OS / runtime       TY         TY         CSP        CSP
Hypervisor         TY         CSP        CSP        CSP
Sprzęt / sieć      TY         CSP        CSP        CSP
Obiekty            TY         CSP        CSP        CSP

* SaaS: provider prowadzi aplikację; Ty nadal odpowiadasz za konfigurację, użytkowników i decyzje o danych.

Hybryda i multicloud

Hybryda łączy on-prem i chmurę; multicloud używa wielu CSP. Oba mnożą granice zaufania: użytkownik uwierzytelniony w SaaS może nadal sięgać do baz on-prem przez connector albo hybrydowy VPN, którego diagram architektury „zapomniał”. Wzorzec mitygacji jest spójny — federowana tożsamość z SSO i phishing-resistant MFA, conditional access, ujednolicone logowanie przez SIEM i SOAR, CSPM do ciągłej detekcji misconfiguration oraz szyfrowany transit bez hairpinowania wszystkiego przez jeden słaby link.

Gdy stem opisuje „CRM w SaaS, baza HR on-prem”, silne odpowiedzi sięgają po SSO i MFA w obu światach, DLP na eksport, kontrolowane ścieżki integracji zamiast płaskiego VPN scalającego strefy zaufania oraz logowanie w obu środowiskach z jasnymi granicami własności narysowanymi, zanim cokolwiek pójdzie live.

IoT, OT i ICS

Industrial Control Systems, SCADA i IoT priorytetyzują bezpieczeństwo fizyczne i dostępność nad szybkim patchingiem czy agresywnym skanowaniem. Okna utrzymaniowe ciągną się długo; firmware lockowany przez vendora może nigdy nie dostać czystego patcha; kruche stacki embedded padają pod skanami credentialed. Myślenie Purdue obowiązuje: izoluj IT od OT i monitoruj pasywnie TAP lub SPAN, gdy aktywne skanowanie jest niebezpieczne. Dostęp uprzywilejowany idzie przez jump hosty i elevację just-in-time (JIT), nigdy standing domain admin na hali produkcyjnej. Pułapka egzaminu to pewna rada w stylu „patch wszystko w ten weekend”, gdy stem opisuje linię produkcyjną, która nie może stanąć.

Wirtualizacja, kontenery i infrastructure as code

Wirtualizacja koncentruje ryzyko na hypervisorze. VM escape jest architektonicznie istotne nawet gdy rzadkie — kompromitacja hosta dotyczy wszystkich gości. Kontenery dzielą kernel hosta, więc higiena obrazów ma znaczenie: żadnych sekretów wypieczonych w warstwach, minimalne base images, wymuszony RBAC orchestracji i podpisywanie registry, by ograniczyć ekspozycję supply chain. Zbyt uprawnione service accounty Kubernetes pojawiają się regularnie jako finding misconfiguration wart znajomości z nazwy.

Infrastructure as Code — Terraform, CloudFormation, Ansible — czyni architekturę powtarzalną, co jest wygraną bezpieczeństwa, gdy szablony są reviewowane i skanowane w CI, a stratą, gdy jeden zły moduł otwiera security groups jednocześnie we wszystkich środowiskach. terraform apply, które otwiera port 22 globalnie, bo developer skopiował nieprzejrzany moduł, to finding misconfiguration, nie nowatorski atak. Mitygacja biegnie przez skan IaC w pipeline, egzekwowanie policy-as-code, bramki akceptacji produkcji i ciągły CSPM po fakcie.

Zero Trust Architecture (NIST SP 800-207)

Zero trust to paradygmat architektoniczny, nie SKU produktu. Modele „zamek i fosa” zakładają, że wszystko wewnątrz perimeteru jest godne zaufania. Zero trust odrzuca to implicit trust całkowicie.

Trzy rdzeniowe zasady to naprawdę jedna ciągła idea wyrażona z trzech kątów. Uwierzytelniasz i autoryzujesz każde żądanie w kontekście i szyfrujesz niezależnie od tego, czy ruch pochodzi z LAN, czy z otwartego internetu — bo samo pochodzenie nic sensownego nie mówi o intencji ani ryzyku. Minimalny dostęp wynika z tego: elevacja JIT i polityka kontekstowa zastępują standing szerokie prawa VPN, które czynią lateral movement tanim. A gdy assume breach, projektujesz, jakby przeciwnik już miał foothold, ograniczając ruch przez microsegmentation i ciągły monitoring sesji zamiast stawiać wszystko na to, że perimeter utrzyma. Tradycyjne modele VPN często dają szeroki dostęp sieciowy po jednej autentykacji. Zero trust przenosi decyzję na każde żądanie i sesję: kto to jest, jaka jest postura urządzenia, jaki konkretny zasób jest osiągany i jak wygląda sygnał ryzyka teraz?

Control plane vs data plane (PE / PA / PEP)

CompTIA oczekuje rozróżnienia gdzie decyzja polityki jest podejmowana od gdzie ruch jest egzekwowany:

                 CONTROL PLANE
  +------------------+      +------------------------+
  |  Policy Engine   | ---> | Policy Administrator   |
  |  (decide)        |      | (issue/revoke tokens)  |
  +------------------+      +------------------------+
                                      |
                                      v
                 DATA PLANE
  Subject/Device ---> Policy Enforcement Point ---> Zasób enterprise
                      (PEP: allow / deny / kill)

Tożsamość jest perimeterem w tym modelu — MFA plus zdrowie urządzenia, microsegmentation ruchu east-west, continuous validation, gdzie sygnał impossible travel odpala re-auth albo blok, oraz analityka skorelowana przez tożsamość, urządzenie, aplikację i sieć. ZTNA (Zero Trust Network Access) przekłada to na praktykę, zastępując „VPN do całego LAN” dostępem per aplikacja. Gdy kontrahenci mają sięgać jednej aplikacji i niczego więcej, wzorce ZTNA biją full-tunnel VPN z dużą przewagą.

Pułapka warta wypalenia w pamięć: „Zero trust oznacza brak firewalla.” Fałsz. Firewalle i PEP zostają. Znika domyślne implicit trust.

Wzorce bezpiecznej infrastruktury enterprise

Segmentacja i screened subnets

Network segmentation ogranicza lateral movement — jest krytyczna w stemach ransomware opisujących flat network, gdzie jeden skompromitowany workstation staje się incydentem firmowym. Microsegmentation stosuje ten sam pomysł na poziomie workload lub tożsamości, co oznacza, że skompromitowana warstwa web nie może swobodnie odpytywać warstwy bazy bez trafienia w punkt egzekwowania wymagający świeżej autoryzacji.

Screened subnets (DMZ) wystawiają tylko konieczne usługi do internetu, podczas gdy aplikacje wewnętrzne i bazy siedzą za kolejnymi granicami:

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

Oznacz granicę zaufania na każdym skoku w mentalnym diagramie. Dual-homed serwery łączące DMZ i sieci internal bez ścisłych zestawów reguł to klasyczny błąd egzaminacyjny — zapadają dwie odrębne strefy bezpieczeństwa w jeden odsłonięty box i usuwają kontrolkę, którą DMZ miała zapewniać.

Bezpieczna łączność i ścieżki privileged access

VPN, IPsec site-to-site, private links i ZTNA rozwiązują różne problemy, a egzamin oczekuje dopasowania rozwiązania do potrzeby. VPN szyfruje ścieżkę; nie wymusza automatycznie least privilege wewnątrz tunelu. Private links zmniejszają ekspozycję publiczną, ale nadal potrzebują IAM i segmentacji na końcach.

Administratorzy nie powinni RDP z domowych laptopów prosto na domain controllery. Bastiony, PAM, nagrywanie sesji i elevacja JIT chronią płaszczyznę admin. Gdy stem opisuje technika helpdesku używającego credentiali domain admin „dla wygody”, ścieżka odpowiedzi biegnie przez least privilege i PAM — nie przez memo polityki, którego nikt nie czyta.

Wysoka dostępność i load balancing

HA i load balancery wspierają availability, którą egzamin traktuje jako cel bezpieczeństwa, gdy w stemie pojawia się DDoS albo single point of failure. Konfiguracje active-active versus active-passive, health checks i dystrybucja geograficzna mają znaczenie w narracjach disaster. Pułapka: dwa zbalansowane serwery WWW z domyślnymi credentialami admina to nie odporność — to podwojona powierzchnia ataku ukryta za pozorem redundancji.

Umiejscowienie urządzeń i IoT

Kamery, drukarki i kontrolery HVAC nie należą do tego samego VLAN co bazy finansowe. Koncepcje NAC i 802.1X wiążą tożsamość urządzenia z umiejscowieniem w sieci, a architektura alokuje subnety i egzekwuje polityki, zanim operacje Domeny 4 przejmą day-to-day.

Defense in depth zrobione poprawnie

Defense in depth układa niezależne kontrolki przez tożsamość, endpoint, sieć, aplikację, dane i monitoring. Dwa identyczne firewalle z tą samą złą regułą to redundancja, nie głębokość — rozróżnienie ma znaczenie w stemach, które pytają „best”, a nie „most”.

Aplikacja web zrobiona dobrze ilustruje pomysł konkretnie. WAF na brzegu ogarnia ataki warstwy aplikacji; segmentowane warstwy app i bazy zawierają lateral movement, jeśli padnie web; parameterized queries usuwają ryzyko SQL injection, które WAF może przegapić w zły dzień; szyfrowanie bazy połączone z least-privilege użytkownikiem bazy ogranicza, co atakujący może przeczytać nawet przy ważnych credentialach; MFA na dostęp admin ogranicza nadużycie privilege; a SIEM patrzący na logi auth i WAF oznacza, że bypass nie zostaje niewidzialny. Każda warstwa jest niezależna — bypass WAF nie oddaje odczytu bazy, tylko usuwa jedną przeszkodę. To jest depth. Dwa WAF z identycznymi rulesetami to droga pojedyncza kontrolka.

Instynkty architektury chmurowej

Poza shared responsibility stemy chmurowe nagradzają kilka konkretnych instynktów. Zbyt szerokie role IAM, długowieczne access keys wypieczone w konfiguracjach serwerów i brak MFA na root lub admin to najczęstsze findings warstwy tożsamości — preferuj role zamiast keys, krótko żyjące credentiale i permission boundaries. Ekspozycja storage przez public buckets, nieszyfrowane snapshoty udostępnione publicznie i niezalogowane backupy w object storage to odpowiedniki warstwy danych. CASB ogarnia shadow IT w SaaS; ciągła detekcja misconfiguration w stylu CSPM patrzy na IaaS i PaaS — CompTIA może różnić akronimy, ale idea ciągłej oceny postawy zostaje. Customer-managed keys dają kontrolę regulacyjną nad szyfrowaniem; TLS trzyma dane bezpiecznie wszędzie, gdzie przechodzą niezaufaną ścieżką.

Przykład wart znajomości na zimno: klucze API wrzucone do publicznego repozytorium GitHub. Awaria to secrets management, nie widoczność repo — zrobienie repo private po fakcie nie pomaga, jeśli forki już istnieją. Naprawa to vault lub secret manager, skan sekretów w CI i krótko żyjące tokeny.

Zastosowanie architektury do scenariusza hybrydowego

Stem: Regionalny bank przenosi chat klientów do SaaS, a core banking zostaje on-prem przez connectory mainframe.

Silna odpowiedź prowadzi pełną historię granic zaufania. Agenci chat uwierzytelniają się przez federację i SSO z MFA, trzymane osobno od auth mainframe tam, gdzie legacy tego wymaga. Minimalizacja danych i limity retencji dotyczą logów chat przechowujących PII, więc vendor SaaS trzyma tylko to, co biznes uzasadnia. DLP blokuje numery kont przed wpływaniem do niesankcjonowanych kanałów — bank nie kontroluje, gdzie pracownik wklei screenshot, gdy już opuści przeglądarkę. Ścieżka sieciowa z SaaS z powrotem do connectora on-prem biegnie przez kontrolowaną warstwę integracji, a nie płaski VPN, który uczyniłby mainframe osiągalnym z dowolnej skompromitowanej sesji chat. Vendor risk assessment, raporty assurance i SLA powiadomień o incydentach definiują granicę kontraktową, żeby rozliczalność przeżyła relację. Logowanie płynie do SIEM z audit API SaaS i connectora on-prem, żeby jedna powierzchnia korelacji widziała pełną historię. Planowanie ciągłości pokrywa scenariusz niedostępności SaaS udokumentowanym kanałem zapasowym, bo obowiązek banku wobec klientów nie pauzuje na awarię vendora.

Słabe odpowiedzi sięgają po „szyfruj laptopy” (ortogonalne do ryzyka integracji) albo „air-gap internetu” (co niszczy uzasadnienie biznesowe SaaS u źródła).

Ćwiczenie szkicowe do nauki

Narysuj na papierze trzy strefy: użytkownicy, warstwa aplikacji i warstwa danych. Umieść identity provider na perimeterze, gdzie użytkownicy się uwierzytelniają, WAF lub API gateway na brzegu, gdzie wchodzi ruch zewnętrzny, agregację logów SIEM z boku zbierającą z każdej strefy oraz ścieżkę backupu celowo poza strefą zaufania produkcji, by uchwycić koncept immutable lub offline copy. Opisz każdą strzałkę protokołem i mechanizmem auth — HTTPS z OIDC, SSH przez bastion z auth certyfikatowym, cokolwiek flow naprawdę wymaga. Potem nałóż pętlę w stylu NIST: subject trafia w PEP, który sprawdza PE i PA poza ścieżką danych, zanim pozwoli requestowi iść do zasobu. Jeśli nie potrafisz oznaczyć granic zaufania na własnym diagramie bez notatek, pytania architektury będą wyglądać jak losowy wybór narzędzi. Powtórz ćwiczenie z jednym boxem SaaS poza borderem sieci, żeby wymusić wariant hybrydowy. Oba diagramy razem pokrywają większość przestrzeni scenariuszy, które Domena 3 rzuca kandydatom.

Podsumowanie pułapek egzaminacyjnych

Zamknięcie

Pytania architektury brzmią: Gdzie zmienia się zaufanie? Kto może dotrzeć do czego? Co failuje bezpiecznie? Zero trust według NIST SP 800-207, segmentacja i shared responsibility to soczewki do odpowiadania na te pytania — nie buzzwordy do posypania na każdą odpowiedź. Ćwicz split PE/PA/PEP, aż narysujesz go z pamięci, i tabelę shared responsibility, aż wiersz IaaS produkuje „guest OS jest Twój” bez świadomego wysiłku.

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