Jak zastosować zasadę zerowego zaufania w środowiskach chmurowych, w których nie ma granic sieci?Środowiska chmurowe z natury nie ograniczają granic — obciążenia działają we współdzielonej infrastrukturze, użytkownicy mają do nich dostęp z dowolnego miejsca, a interfejsy API łączą wszystko. To sprawia, że środowiska chmurowe są zarówno idealnie dostosowane do zerowego zaufania, jak i pilnie go potrzebują.
Kluczowe wnioski
- Chmura jest już bez granic:Zero zaufania nie jest dodatkiem do chmury — tak chmura powinna być zabezpieczona od początku.
- IAM to główna płaszczyzna kontrolna:W chmurze wszystko jest wywołaniem API. Zasady IAM kontrolują, kto i co może dzwonić. To jest Twój punkt egzekwowania zerowego zaufania.
- Tożsamość obciążenia jest tak samo ważna jak tożsamość użytkownika:Usługi, kontenery i funkcje wymagają weryfikacji tożsamości, tak jak ludzie.
- Natywne narzędzia chmurowe zapewniają najwięcej możliwości:AWS IAM, Azure Entra ID, grupy zabezpieczeń VPC/VNet i KMS zapewniają elementy konstrukcyjne o zerowym zaufaniu bez narzędzi innych firm.
Architektura Cloud Zero Trust
| Filar zerowego zaufania | AWS Wdrożenie | Azure Wdrożenie |
|---|---|---|
| Tożsamość (Użytkownicy) | IAM Centrum tożsamości, MFA, zasady SCP | Entra ID, dostęp warunkowy, PIM |
| Tożsamość (obciążenia) | IAM Role, STS, profile instancji | Tożsamości zarządzane, jednostki usług |
| Sieć | VPC, Grupy zabezpieczeń, PrivateLink, Zapora sieciowa | Sieć wirtualna, sieciowe grupy zabezpieczeń, prywatne punkty końcowe, zapora sieciowa Azure |
| Dane | KMS, S3 zasady, Macie, zasady wiaderkowe | Key Vault, szyfrowanie magazynu, dostęp |
| Oblicz | Zweryfikowany dostęp, menedżer systemów, IMDSv2 | Azure Bastion, JIT VM Dostęp, Zaufane uruchomienie |
| Monitorowanie | CloudTrail, GuardDuty, centrum bezpieczeństwa | Dziennik aktywności, Defender for Cloud, Sentinel |
Tożsamość-pierwsze zerowe zaufanie w AWS
Zasady najniższych uprawnień IAM
AWS IAM to warstwa egzekwowania zerowego zaufania. Każde wywołanie API jest oceniane pod kątem zasad IAM. Zaimplementuj najmniejsze uprawnienia poprzez: użycie narzędzia IAM Access Analyzer do identyfikacji nieużywanych uprawnień, wdrożenie zasad kontroli usług (SCP) w celu ustawienia maksymalnych granic uprawnień, użycie granic uprawnień dla ról IAM oraz regularne przeglądanie i usuwanie nieużywanych zasad IAM. Cel: każda tożsamość (użytkownik, rola, usługa) ma dokładnie takie uprawnienia, jakich potrzebuje i nic więcej.
Tożsamość obciążenia z rolami IAM
Nigdy nie używaj długowiecznych kluczy dostępu. Instancje EC2 korzystają z profili instancji (role IAM przypisane do instancji). Funkcje Lambda korzystają z ról wykonawczych. Zadania ECS korzystają z ról zadaniowych. Pody EKS używają ról IAM dla kont usług (IRSA). Każde obciążenie otrzymuje własną tożsamość z uprawnieniami o określonym zakresie — zaatakowany serwer sieciowy nie może uzyskać dostępu do bazy danych, jeśli jego rola nie obejmuje uprawnień do bazy danych.
Wymuś IMDSv2
Powszechnym wektorem ataku jest usługa metadanych instancji EC2 (IMDS). IMDSv1 umożliwia dostęp nieuwierzytelniony — każdy proces w instancji może pobrać poświadczenia IAM. IMDSv2 wymaga tokena sesji uzyskanego poprzez żądanie PUT, co zapobiega kradzieży danych uwierzytelniających w oparciu o SSRF. Wymuś IMDSv2 we wszystkich instancjach poprzez szablony uruchamiania i zasady SCP, które blokują IMDSv1.
Tożsamość-pierwsze zerowe zaufanie w Azure
Dostęp warunkowy jako silnik polityki zerowego zaufania
Azure Zasady dostępu warunkowego to aparat decyzyjny o zerowym zaufaniu. Skonfiguruj zasady oceniające: tożsamość użytkownika i członkostwo w grupach, stan zgodności urządzenia (Intune), lokalizację (sieci zaufane i niezaufane), poziom ryzyka logowania (Azure AD Identity Protection) i czułość aplikacji. Zasady mogą wymagać usługi MFA, blokować dostęp, ograniczać czas trwania sesji lub egzekwować zasady ochrony aplikacji na podstawie tych sygnałów.
Zarządzane tożsamości dla obciążeń
Azure Tożsamości zarządzane zapewniają automatyczne zarządzanie poświadczeniami dla zasobów Azure. Tożsamości zarządzane przypisane przez system są powiązane z określonym zasobem (VM, App Service, aplikacja funkcji) i są usuwane po usunięciu zasobu. Tożsamości zarządzane przypisane przez użytkownika mogą być współużytkowane między zasobami. Obydwa eliminują potrzebę podawania poświadczeń w kodzie lub konfiguracji — platforma Azure obsługuje uwierzytelnianie w sposób przejrzysty.
Zarządzanie uprzywilejowaną tożsamością (PIM)
Azure PIM zapewnia uprzywilejowany dostęp just-in-time, ograniczony czasowo. Zamiast stałych ról administratorów użytkownicy aktywują role uprzywilejowane na żądanie za pomocą przepływów pracy związanych z weryfikacją i zatwierdzaniem usługi MFA. Aktywacje są ograniczone czasowo (np. 4 godziny) i podlegają pełnemu audytowi. To radykalnie zmniejsza stały przywilej, który atakujący wykorzystują do utrzymywania się.
Sieć Zero zaufania w chmurze
Mikrosegmentacja z grupami bezpieczeństwa
AWS Grupy zabezpieczeń i Azure sieciowe grupy zabezpieczeń zapewniają mikrosegmentację na poziomie obciążenia. Zaimplementuj sieci o najniższych uprawnieniach: serwery WWW zezwalają tylko na przychodzące połączenia HTTPS, serwery aplikacji akceptują połączenia tylko z serwerów WWW, serwery baz danych akceptują tylko połączenia z serwerów aplikacji. Domyślnie odrzucaj cały inny ruch. Użyj dzienników przepływu VPC/VNet, aby sprawdzić, czy wzorce ruchu odpowiadają zamierzonej segmentacji.
Prywatna łączność
Użyj AWS PrivateLink i Azure Private Endpoints, aby uzyskać dostęp do usług w chmurze bez przechodzenia przez publiczny Internet. Eliminuje to powierzchnię ataku w publicznie dostępnych punktach końcowych usług. Dostęp do usług S3, RDS, Key Vault i setek innych usług można uzyskać za pośrednictwem prywatnych adresów IP w sieci VPC/VNet.
Jak Opsio wdraża Cloud Zero Trust
- Ocena bezpieczeństwa chmury:Oceniamy Twoje obecne zasady IAM, architekturę sieci i zabezpieczenia pod kątem zasad zerowego zaufania.
- IAM naprawa:Wdrażamy zasady najniższych uprawnień, usuwamy stały dostęp administratora i wdrażamy tożsamość obciążeń w Twoich środowiskach chmurowych.
- Wzmocnienie sieci:Implementacja mikrosegmentacji, łączności prywatnej i monitorowania sieci.
- Ciągłe monitorowanie:Nasz SOC monitoruje skuteczność polityki zerowego zaufania, wykrywa próby obejścia i raportuje stan bezpieczeństwa.
Często zadawane pytania
Czy potrzebuję narzędzi innych firm, aby uzyskać zaufanie do chmury zero?
W przypadku większości możliwości nie. AWS IAM, Azure Entra ID, grupy zabezpieczeń VPC/VNet i natywne usługi szyfrowania stanowią podstawowe elementy składowe zerowego zaufania. Narzędzia innych firm stanowią wartość dodaną w zakresie: ujednoliconego zarządzania wieloma chmurami, zaawansowanego zarządzania tożsamością, ZTNA do dostępu użytkowników i CASB do kontroli SaaS. Zacznij od narzędzi natywnych i dodawaj rozwiązania innych firm tylko tam, gdzie w narzędziach natywnych występują luki.
Jak wdrożyć zerowe zaufanie dla Kubernetes?
Kubernetes zero zaufania wymaga: zasad sieciowych na poziomie poda (Calico, Cilium) zamiast polegania na izolacji przestrzeni nazw, siatki usług (Istio, Linkerd) dla mTLS między usługami, kontroli dostępu RBAC z najniższymi uprawnieniami dla dostępu do serwera API, tożsamości obciążenia (IRSA dla EKS, Workload Identity dla GKE) zamiast kont usług wspólnych oraz kontrolerów dostępu (OPA/Gatekeeper) w celu egzekwowania zasad bezpieczeństwa na wszystkie wdrożenia.
Jaki jest największy błąd we wdrażaniu Cloud Zero Trust?
Począwszy od mikrosegmentacji sieci przed ustaleniem tożsamości. Segmentacja sieci jest ważna, ale złożona i destrukcyjna. Kontrola tożsamości (MFA, dostęp warunkowy, najniższe uprawnienia IAM) zapewnia większy wpływ na bezpieczeństwo przy mniejszych zakłóceniach i zawsze powinna być najważniejsza. Napraw tożsamość, następnie zajmij się siecią, a następnie aplikacją i danymi.