Architektura zero trust w chmurze: praktyczny przewodnik dla AWS, Azure i GCP
Model perymetryczny, ufaj wszystkiemu wewnątrz sieci prywatnej czyli w obrębiefirewalla, zakładał sieć kontrolowaną od brzegu do brzegu. W chmurze nie ma takiego konceptu: usługi rozciągają się między kontami i regionami, pracownicy łączą się zewsząd, a aplikacje stale komunikują się z endpointami SaaS i ze sobą nawzajem. Zero trust zastępuje “zaufane, bo wewnątrz sieci” przez “zaufane, bo właśnie udowodniło, kim jest i co mu wolno”. To architektoniczny element praktyk z naszego przewodnika po bezpieczeństwie cloud native; tutaj skupiamy się konkretnie na modelu zero trust.
Podstawowe zasady
Trzy idee podpierają cały model:
- Weryfikuj jawnie. Uwierzytelniaj i autoryzuj każde żądanie na wszystkich dostępnych sygnałach: tożsamość, kondycja urządzenia, lokalizacja, obciążenie, wrażliwość danych. Nie raz na perymetrze, za każdym razem.
- Stosuj dostęp least privilege. Przyznawaj minimum potrzebnych uprawnień, just-in-time i just-enough, żeby skompromitowana tożsamość miała najmniejszy możliwy zasięg rażenia.
- Zakładaj naruszenie. Projektuj tak, jakby atakujący był już w środku. Segmentuj, by ograniczyć ruch boczny, szyfruj end-to-end i loguj wszystko dla celów detekcji i audytów śledczych.
Jeśli decyzja nie służy jednej z tych trzech, to nie jest zero trust, to tylko więcej narzędzi.
Filary NIST
Model NIST SP 800-207 (i model dojrzałości CISA na nim zbudowany) rozbija zero trust na filary. To użyteczna struktura, bo zamienia abstrakcyjną zasadę w checklistę, którą faktycznie da się wdrożyć.
| Filar | Pytanie zero trust, na które odpowiada | Główne kontrole |
|---|---|---|
| Tożsamość | Czy ten użytkownik/usługa jest tym, za kogo się podaje? | Silne MFA, federacja, krótkotrwałe poświadczenia, brak stałego admina |
| Urządzenia | Czy to urządzenie jest znane i zdrowe? | Inwentarz urządzeń, kontrole postawy, wymuszanie zarządzanych urządzeń |
| Sieci | Czy ten ruch jest dozwolony i czy jest izolowany? | Mikro-segmentacja, mTLS, brak domyślnego zaufania east-west |
| Aplikacje / obciążenia | Czy ta aplikacja może działać i wywołać inną? | Tożsamość obciążeń, autoryzacja usługa-usługa, podpisane artefakty |
| Dane | Czy ta tożsamość powinna sięgnąć po te dane, tu i teraz? | Klasyfikacja, szyfrowanie, polityki dostępu powiązane z wrażliwością |
| Widoczność / analityka | Co się właściwie dzieje i czy to normalne? | Scentralizowane logowanie, detekcja anomalii, ciągła ewaluacja |
Sens filarów to sekwencjonowanie. Nie wdrażasz wszystkich sześciu naraz; podnosisz ich dojrzałość w czasie, zaczynając tam, gdzie Twoje ryzyko jest najwyższe (prawie zawsze tożsamość).
Tożsamość to miejsce, gdzie zaczyna się zero trust
W chmurze tożsamość jest płaszczyzną kontroli. Zrób ją dobrze, a pozostałe filary mają na czym się oprzeć; zrób źle, a żadna segmentacja sieci Cię nie uratuje. Elementy nienegocjowalne:
- Silne, odporne na phishing MFA dla tożsamości ludzkich, wymuszone, nie opcjonalne.
- Federacja zamiast kont lokalnych - jeden dostawca tożsamości, SSO, więc dostęp przyznaje się i odbiera w jednym miejscu.
- Krótkotrwałe, związane z obciążeniem poświadczenia zamiast długotrwałych kluczy. Federacja OIDC dla pipeline’ów; IRSA (EKS), Workload Identity (GKE) lub managed identities (Azure) dla obciążeń.
- Uprawnienia just-in-time - brak stałych praw admina; podnoszenie na żądanie, z akceptacją i wygaśnięciem.
Chcesz wiedzieć, gdzie naprawdę są Twoje luki zero trust?
Umów bezpłatną rozmowę 30 min
Jak to mapuje się na AWS, Azure i GCP
Zero trust jest niezależne od dostawcy jako zasada, ale wdrażasz je natywnymi klockami każdej chmury. To mapowanie, którego używamy.
| Filar | AWS | Azure | GCP |
|---|---|---|---|
| Tożsamość | IAM Identity Center, role IAM, federacja OIDC | Entra ID, Conditional Access, PIM | Cloud IAM, Workload Identity Federation |
| Zaufanie urządzeń | Verified Access, sygnały urządzeń | Intune + zgodność urządzeń w Conditional Access | BeyondCorp Enterprise, Endpoint Verification |
| Sieć | VPC + grupy bezpieczeństwa, PrivateLink, Verified Access | VNet, NSG, Private Link, Azure Firewall | VPC Service Controls, Private Service Connect |
| Tożsamość obciążeń | IAM Roles for Service Accounts (IRSA) | Managed identities | Workload Identity (GKE) |
| Dane | KMS, Macie, S3 access points | Key Vault, Purview, Information Protection | Cloud KMS, DLP, VPC Service Controls |
| Widoczność | CloudTrail, GuardDuty, Security Hub | Microsoft Sentinel, Defender for Cloud | Security Command Center, Cloud Audit Logs |
Wspólny mianownik: każdy dostawca daje Ci warstwę dostępu świadomą tożsamości (AWS Verified Access, Azure Conditional Access, Google BeyondCorp), która jest praktycznymi drzwiami frontowymi do zero trust. Jeśli standaryzujesz między więcej niż jedną, wyzwaniem governance jest utrzymanie spójnej polityki, co jest tym samym problemem, który opisujemy w opanowywaniu cloud sprawl.
Model dojrzałości: jak faktycznie tam dojść
Zero trust to podróż, nie przełącznik. Próba zrobienia wszystkiego naraz to sposób, w jaki programy się zacinają. Rozsądna progresja:
- Tradycyjny (gdzie większość startuje). Zaufanie perymetryczne, długotrwałe poświadczenia, stały admin, płaskie sieci.
- Początkowy. Wymuszone MFA, SSO/federacja na miejscu, scentralizowane logowanie. Pierwszy krok o najwyższej dźwigni i głównie praca nad tożsamością.
- Zaawansowany. Krótkotrwałe poświadczenia wszędzie, mikro-segmentacja dla krytycznych obciążeń, kontrole postawy urządzeń, zautomatyzowane przeglądy least privilege.
- Optymalny. Ciągła, oparta na sygnałach ewaluacja dostępu; polityka jako kod; zautomatyzowana reakcja; decyzje dostępu świadome danych we wszystkich filarach.
Wybierz obecny szczebel uczciwie, potem awansuj jeden filar naraz, zaczynając od tożsamości. Zespół, który dojdzie tylko do “Początkowego” w całym zakresie, już usunął większość realnych ścieżek ataku.
Zero trust a zgodność
Architektura zero trust znacząco ułatwia zgodność, bo kontrole, o które pytają audytorzy (kontrola dostępu, least privilege, szyfrowanie, logowanie, segmentacja) to dokładnie te, których zero trust wymaga. Załącznik A ISO 27001, SOC 2 i NIS2 mapują się czysto na powyższe filary. Zbuduj zero trust dobrze, a dowody audytowe są w dużej mierze produktem ubocznym, co omawiamy w naszym przewodniku po certyfikacji ISO 27001 w chmurze.
FAQ
Czym jest architektura zero trust w prostych słowach? Model bezpieczeństwa, w którym nic nie jest zaufane domyślnie. Każde żądanie jest uwierzytelniane i autoryzowane na własnych zasadach, niezależnie od tego, skąd pochodzi, dostęp jest least-privilege, a projekt zakłada, że atakujący może już być w środku.
Czy zero trust to produkt? Nie. To zasada architektury wdrażana wieloma kontrolami (tożsamość, urządzenie, sieć, obciążenie, dane, widoczność). Dostawcy sprzedają produkty, które pomagają, ale nie da się kupić “zero trust” z półki.
Od czego zacząć zero trust? Od tożsamości. Wymuś silne MFA, przejdź na federację/SSO, zastąp długotrwałe poświadczenia krótkotrwałymi i usuń stałe prawa admina. Ten jeden filar usuwa większość realnych ścieżek ataku i jest fundamentem dla reszty.
Czym zero trust różni się od VPN? VPN przyznaje dostęp do sieci, która potem domyślnie Ci ufa (klasyczne myślenie perymetryczne). Zero trust przyznaje dostęp do konkretnych aplikacji per żądanie na podstawie tożsamości i kontekstu, nie umieszczając Cię “wewnątrz” zaufanej sieci. Proxy świadome tożsamości (Verified Access, Conditional Access, BeyondCorp) to zastępstwo zero trust dla szerokiego dostępu VPN.
Czy zero trust działa między wieloma chmurami? Tak. Zasady są niezależne od dostawcy; każda chmura ma równoważne klocki. Trudną częścią w multi-cloud jest governance: utrzymanie spójnej polityki tożsamości i dostępu między dostawcami.
Podsumowanie
- Zero trust to zasada, nie produkt: nigdy nie ufaj, zawsze weryfikuj. Weryfikuj jawnie, egzekwuj least privilege, zakładaj naruszenie.
- Filary NIST czynią to wykonalnym - tożsamość, urządzenia, sieci, obciążenia, dane, widoczność - a tożsamość to miejsce, gdzie każdy program powinien zacząć.
- Jest niezależne od dostawcy, ale wdrażane natywnie. AWS, Azure i GCP dają każdy warstwę dostępu świadomą tożsamości; podnoś dojrzałość jeden filar naraz, a dowody zgodności przychodzą w dużej mierze za darmo.
Jeśli chcesz pomocy w projektowaniu lub rozwijaniu architektury zero trust w AWS, Azure lub GCP, zajrzyj do naszych usług bezpieczeństwa i zgodności.
Budujesz architekturę zero trust?
Umów bezpłatną 30-minutową rozmowę. Pomagamy zespołom ocenić, gdzie są na krzywej dojrzałości, spriorytetyzować kroki zaczynające od tożsamości, które usuwają najwięcej ryzyka, i wdrożyć zero trust natywnie w AWS, Azure i GCP.
