Czy korzystasz ze środowiska natywnego w chmurze z myślą o lokalnych operacjach związanych z bezpieczeństwem?Tradycyjne architektury SOC zostały zaprojektowane dla środowisk centrów danych — scentralizowane zapory ogniowe, wykrywanie oparte na sieci i monitorowanie skoncentrowane na serwerze. Środowiska chmurowe wymagają zasadniczo innego podejścia: widoczność oparta na API, wykrywanie skoncentrowane na tożsamości i elastyczne przetwarzanie dzienników, które skaluje się wraz z obciążeniami w chmurze.
Kluczowe wnioski
- Natywny dla chmury SOC korzysta z narzędzi natywnych dla chmury:Azure Sentinel, AWS Security Lake, GuardDuty i Defender zastępują tradycyjne lokalne rozwiązania SIEM i IDS.
- Tożsamość jest główną powierzchnią wykrywania:W chmurze większość ataków obejmuje naruszenie poświadczeń i manipulację IAM, a nie włamanie do sieci.
- Architektura dziennika określa skuteczność SOC:To, co gromadzisz, jak je normalizujesz i jak długo je przechowujesz, określa, jakie zagrożenia możesz wykryć.
- Automatyzacja jest niezbędna, a nie opcjonalna:Środowiska chmurowe zmieniają się zbyt szybko, aby można było wykonywać wyłącznie ręczne operacje bezpieczeństwa.
Natywna dla chmury architektura referencyjna SOC
| Warstwa | AWS | Azure | Cel |
|---|---|---|---|
| Zbieranie dzienników | CloudTrail, VPC Dzienniki przepływu, GuardDuty | Dziennik aktywności, dzienniki przepływu NSG, obrońca | Pozyskiwanie surowych danych bezpieczeństwa |
| SIEM / Analityka | Bezpieczeństwo Lake + Athena / OpenSearch | Strażnik Microsoftu | Normalizacja, korelacja, detekcja |
| Wykrywanie zagrożeń | Strażnik, Inspektor, Macie | Obrońca chmury, obrońca tożsamości | Wykrywanie zagrożeń natywnie w chmurze |
| SOAR / Automatyka | Funkcje kroku, Lambda, EventBridge | Aplikacje logiczne, funkcje Azure | Zautomatyzowana reakcja i orkiestracja |
| Zarządzanie postawą | Centrum zabezpieczeń, konfiguracja | Obrońca chmury (CSPM) | Monitorowanie konfiguracji |
| Bezpieczeństwo tożsamości | IAM Analizator dostępu, CloudTrail | Entra ID Protection, Sentinel UEBA | Wykrywanie zagrożeń tożsamości |
AWS Architektura operacji bezpieczeństwa
Scentralizowane logowanie za pomocą AWS Security Lake
AWS Security Lake normalizuje dane bezpieczeństwa z CloudTrail, dzienniki przepływu VPC, dzienniki Route 53 DNS, dzienniki dostępu S3 i ustalenia GuardDuty w ramach Open Cybersecurity Schema Framework (OCSF). Ta normalizacja ma kluczowe znaczenie — umożliwia analitykom SOC wykonywanie zapytań we wszystkich źródłach danych przy użyciu spójnego schematu, zamiast uczenia się unikalnego formatu dziennika każdej usługi. Security Lake przechowuje dane w formacie S3 w formacie Parquet, umożliwiając ekonomiczne długoterminowe przechowywanie i szybkie zapytania analityczne za pośrednictwem usługi Athena.
Bezpieczeństwo wielu kont w organizacjach AWS
Środowiska korporacyjne AWS korzystają z wielu kont (programowanie, przemieszczanie, produkcja, usługi wspólne). Natywny w chmurze SOC centralizuje dane dotyczące bezpieczeństwa ze wszystkich kont w dedykowanym koncie bezpieczeństwa. GuardDuty, Security Hub i CloudTrail są skonfigurowane z delegowanym administratorem na koncie bezpieczeństwa, zapewniając ujednolicony wgląd w całą organizację AWS. Dzięki tej architekturze żadne konto nie jest martwym punktem.
Automatyczna odpowiedź za pomocą EventBridge i Lambda
AWS EventBridge przechwytuje w czasie rzeczywistym zdarzenia związane z bezpieczeństwem z GuardDuty, Security Hub i CloudTrail. Funkcje Lambda wykonują automatyczne akcje reagowania: izolowanie zainfekowanych instancji EC2 poprzez modyfikację grup zabezpieczeń, unieważnianie skompromitowanych poświadczeń IAM, udostępnianie kryminalistycznych migawek zainfekowanych woluminów i powiadamianie zespołu SOC za pośrednictwem SNS lub PagerDuty. Ta automatyzacja zapewnia reakcję w ciągu kilku minut na znane wzorce zagrożeń.
Azure Architektura operacji bezpieczeństwa
Microsoft Sentinel jako natywny dla chmury SIEM
Microsoft Sentinel to natywna dla chmury platforma SIEM firmy Azure zbudowana na platformie Azure Monitor Log Analytics. Pozyskuje dane z dzienników aktywności Azure, dzienników logowania Azure AD (Entra ID), dzienników audytu Microsoft 365, alertów Defender i źródeł innych firm za pośrednictwem wbudowanych łączników. Model płatności za wykorzystanie oprogramowania Sentinel skaluje się w zależności od środowiska bez konieczności planowania pojemności. Wbudowane modele ML wykrywają nietypowe zachowanie podczas logowania, niemożliwe podróżowanie i nieznane właściwości logowania.
Obrońca integracji z chmurą
Usługa Microsoft Defender for Cloud udostępnia funkcje CSPM (zarządzanie stanem zabezpieczeń w chmurze) i CWPP (platforma ochrony obciążenia w chmurze), które są dostarczane do rozwiązania Sentinel. CSPM stale skanuje konfiguracje Azure pod kątem testów bezpieczeństwa. CWPP zapewnia ochronę środowiska uruchomieniowego maszyn wirtualnych, kontenerów, baz danych i App Service. Alerty usługi Defender integrują się natywnie z rozwiązaniem Sentinel, tworząc ujednolicony potok wykrywania i reagowania.
Automatyczna odpowiedź za pomocą Logic Apps
Podręczniki Sentinel (oparte na Azure Logic Apps) automatyzują przepływy pracy odpowiedzi. Gdy Sentinel wykryje przejęte konto, podręcznik może automatycznie wyłączyć konto w Entra ID, unieważnić wszystkie aktywne sesje, wywołać ponowną rejestrację MFA, powiadomić zespół SOC i utworzyć zgłoszenie incydentu — a wszystko to w ciągu kilku sekund od wykrycia.
Inżynieria wykrywania w chmurze
Reguły wykrywania skoncentrowane na tożsamości
Środowiska chmurowe skupiają się na tożsamości — większość ataków polega na ujawnieniu danych uwierzytelniających, a nie na wykorzystaniu sieci. Reguły wykrywania priorytetów obejmują: niemożliwą podróż (logowanie z odległych geograficznie lokalizacji w ciągu kilku minut), ataki zmęczenia MFA (powtarzające się monity MFA), eskalację uprawnień (modyfikacje zasad IAM, wzorce zakładania ról), anomalie kont usług (wywołania API z nietypowych adresów IP lub w nietypowych porach) i ataki z udzieleniem zgody (nadużycie autoryzacji aplikacji OAuth).
Wykrywanie ataków specyficznych dla chmury
Reguły wykrywania muszą obejmować techniki ataków specyficzne dla chmury: modyfikacje zasad zasobnika S3, dostęp do metadanych instancji EC2 (wykorzystywanie IMDS), łańcuchy założeń ról dla wielu kont, wstrzykiwanie kodu funkcji Lambda za pomocą zmiennych środowiskowych oraz obejście zasad bezpieczeństwa poda Kubernetes. Techniki te nie mają odpowiednika w tradycyjnych środowiskach lokalnych i wymagają specjalnie opracowanej logiki wykrywania.
Jak Opsio tworzy natywną chmurę SOC
- AWS + Azure + GCP wiedza specjalistyczna:Budujemy architektury SOC dla wszystkich trzech głównych platform chmurowych, w tym środowisk wielochmurowych.
- Normalizacja OCSF:Spójny schemat dziennika we wszystkich źródłach w chmurze w celu skutecznego wykrywania na wielu platformach.
- Ponad 300 reguł wykrywania chmur:Specjalnie zaprojektowane wykrywanie technik ataków specyficznych dla chmury, mapowanych na MITRE ATT&CK Cloud Matrix.
- Podręczniki automatycznego reagowania:Wstępnie zbudowana automatyzacja reakcji na typowe zagrożenia w chmurze z możliwością dostosowania do potrzeb klienta.
- Wiele kont/wiele subskrypcji:Scentralizowana widoczność zabezpieczeń w złożonych organizacjach korporacyjnych działających w chmurze.
Często zadawane pytania
Czy powinienem używać AWS Security Lake lub Microsoft Sentinel?
Jeśli Twoje środowisko to głównie AWS, Security Lake + SIEM (Sentinel może pozyskiwać z Security Lake) zapewnia najgłębszą widoczność AWS. Jeśli Twoje środowisko jest Azure-podstawowe lub obciąża Microsoft, Sentinel jest naturalnym wyborem. W przypadku wielu chmur każda z nich może służyć jako podstawowa SIEM z pozyskiwaniem danych między chmurami. Opsio pomaga dokonać wyboru na podstawie konkretnego środowiska.
Ile kosztuje zbudowanie natywnego rozwiązania chmurowego SOC?
Koszty platformy (SIEM, pamięć masowa, obliczenia do celów analitycznych) zazwyczaj wynoszą 3 000–20 000 USD miesięcznie, w zależności od ilości danych. Koszty operacyjne (analitycy, procesy, ciągłe doskonalenie) są odrębne. Całkowity koszt natywnego rozwiązania SOC w chmurze (platforma + operacje) wynosi zazwyczaj 10 000–50 000 USD miesięcznie dla organizacji średniej wielkości. SOCaaS łączy oba elementy w jeden przewidywalny koszt.
Czy mogę uruchomić natywną chmurę SOC bez SIEM?
W małych środowiskach usługi wykrywania natywne w chmurze (GuardDuty, Defender for Cloud) wraz z podstawową agregacją dzienników mogą zapewnić podstawowe monitorowanie bezpieczeństwa bez pełnego wdrożenia SIEM. Jednak bez możliwości korelacji i badania SIEM tracisz możliwość wykrywania złożonych, wieloetapowych ataków i prowadzenia dokładnego badania incydentów.