Połącz logi przepływów chmurowych z Sophos XDR i SIEM

Logi przepływów chmurowych opisują połączenia sieciowe, a nie pełną zawartość pakietów. Sophos XDR może je odbierać z AWS VPC Flow Logs, Azure Network Watcher, Google Cloud Platform (GCP) i Oracle Cloud Infrastructure (OCI). Ścieżka zależy od źródła: S3 i Lambda dla AWS, Azure Storage i Function dla Network Watcher, Pub/Sub dla GCP oraz Streaming dla OCI.

Telemetria netflow z tych integracji wymaga Sophos Next-Gen SIEM. GCP i OCI dostarczają przez te same integracje również inne schematy. Nie oznacza to obowiązku posiadania SIEM dla wszystkich chmurowych danych audytowych i bezpieczeństwa. Najpierw należy potwierdzić potrzebne kategorie, tenant, aktualizację Fusion i uprawnienia licencyjne. SIEM i planowanie retencji wyjaśnia zakres handlowy.

Te bezpośrednie integracje różnią się od kolektora syslog działającego w chmurze. Tę drugą ścieżkę opisuje runbook kolektora XDR.

Przed pierwszą zmianą w chmurze

Potrzebny jest kafelek właściwego produktu w docelowym tenancie pod Security Operations > Integrations > Marketplace, zatwierdzone uprawnienia administracyjne do zasobów chmurowych i zespół odpowiedzialny za bieżące koszty, klucze oraz jakość danych. Dostępność i pola należy sprawdzić w swoim tenancie. Brakującego kafelka nie zastępuje się integracją o podobnej nazwie.

Dla każdego źródła dokumentuje się konto lub subskrypcję chmurową, region, wymagane kategorie, integrację docelową i początek zbierania. Uprawnienia ogranicza się do zaplanowanej ścieżki. Rola administracyjna wymagana do wdrożenia nie uzasadnia stałego używania osobistego konta administratora jako tożsamości integracji. Lambda, Storage i Pub/Sub mogą generować osobne opłaty chmurowe.

Zielony stan integracji potwierdza komunikację, nie kompletne zbieranie danych. Odbiór wymaga zatwierdzonego, nieszkodliwego zdarzenia testowego z dowodem i czasem w źródle, a następnie odpowiadającego mu znormalizowanego rekordu. Przewodnik integracji wyjaśnia uprawnienia, przepływ i rozróżnienie od akcji reagowania.

AWS VPC Flow Logs przez własny bucket S3

AWS VPC Flow Logs pobiera się z własnego bucketu Amazon S3. Sophos udostępnia szablon CloudFormation tworzący funkcję przekazującą Lambda. Wymagane są konto AWS, bucket z logami oraz uprawnienia do utworzenia zasobów Lambda, CloudFormation i IAM.

W Marketplace Sophos otworzyć AWS VPC Flow Logs. Pod Configured integrations > Add new przeczytać informacje o S3, wybrać Next, nadać rozpoznawalną nazwę i wybrać Done. Pobrać szablon wygenerowany po provisioningu i przechowywać go z ograniczonym dostępem.
W AWS skierować planowany eksport VPC do tego bucketu. Miejscem docelowym musi być Amazon S3. Używać wyłącznie domyślnego formatu AWS; format własny może pogorszyć normalizację i wykrywanie.
W tym samym regionie AWS co bucket logów otworzyć CloudFormation > Create stack, przesłać szablon i nadać nazwę bez spacji. Ustawić IntegrationType na awsvpcflow. W NotificationBucket podać nazwę bucketu, nie URL ani URI S3. Jeżeli celowo używa się SNS zamiast powiadomień S3, wpisać jego ARN w SNSNotificationarn. Pozostałe parametry porównać z zaplanowaną ścieżką.
Sprawdzić i zatwierdzić tworzenie zasobów IAM, utworzyć stos i poczekać na CREATE_COMPLETE. Oddzielnego bucketu z szablonem nie trzeba udostępniać publicznie.
W Lambda otworzyć funkcję utworzoną przez stos. Pod Function overview > Add Trigger dodać bucket logów jako źródło S3. Wybrać Event Type: All Object Create Events. Prefix zawiera wyłącznie rzeczywisty prefiks logów; jeżeli nie jest używany, pozostaje pusty. Suffix pozostawić puste. Sprawdzić koszty i dodać trigger.
W wybranym zakresie VPC wygenerować odpowiedni, nieszkodliwy przepływ sieciowy. Najpierw potwierdzić rekord w buckecie, potem porównać okres i parametry połączenia w schemacie Sophos netflow.

Wymagany format domyślny:

${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status}

Jeżeli dane nie docierają, porównać miejsce eksportu, nowe obiekty, region i prefiks triggera. Szablon domyślnie ustawia Reserved Concurrency na 5; nie jest to gwarancja odpowiedniego rozmiaru. Ocenić obciążenie i metryki CloudWatch. Rate Exceeded może dotyczyć limitu współbieżności AWS. Wielokrotne tworzenie integracji Sophos nie usuwa tej granicy.

Azure Network Watcher przez Storage i Azure Function

Network Watcher zapisuje NSG Flow Logs lub VNet Flow Logs w Azure Storage Account. Nie można już tworzyć nowych NSG Flow Logs. Dla nowych źródeł planować VNet Flow Logs. Istniejące NSG Flow Logs można podłączyć do czasu ich zastąpienia; Microsoft wycofa tę funkcję 30 września 2027 r. Zaplanować ich migrację do VNet Flow Logs przed tym terminem. Oba typy wymagają oddzielnych integracji Sophos, ponieważ używają różnych kontenerów Blob lub Data Source Keys.

Potrzebne są aktywna subskrypcja Azure, Storage Account z kontenerem Blob i włączonymi logami oraz obsługiwany plan Azure Function. Udokumentowano Basic z B1, B2 lub B3, Dynamic z Y1 i określone kody Premium. Isolated nie jest obsługiwany. Kod Premium wybiera się z aktualnie oferowanej listy, bez wnioskowania z podobnej nazwy planu Azure.

W Network Watcher skierować VNet Flow Logs dla nowego źródła do zaplanowanego Storage Account; istniejące NSG Flow Logs stosować tylko przejściowo do czasu migracji. Zapisać nazwę konta i kontenera oraz sprawdzić, czy faktycznie pojawiają się nowe obiekty.
W Marketplace Sophos otworzyć Microsoft Azure Network Watcher - Azure Storage Account i utworzyć integrację pod Azure Storage Accounts > Set Up.
Dokładnie skopiować Storage Account Name. Function App Name jest własną nazwą opisową, np. NSGFlowLogsForwarder, a nie stałą produktu. Data Source Key ustawić na insights-logs-networksecuritygroupflowevent dla NSG albo insights-logs-flowlogflowevent dla VNet.
Wybrać Azure Function Service Plan Type, właściwy Service Plan Code i Num Workers. Domyślnie jest jeden worker. Dla Basic B2/B3 udokumentowano maksimum trzech; nie należy rozszerzać tego ograniczenia na inne plany.
Wybrać Done, aby wygenerować i pobrać AzureFunction.json. W Azure załadować plik przez Deploy a custom template > Build your own template in the editor. Sprawdzić Resource Group i parametry, następnie Review + Create i Create.
Storage Account i Function mogą być w różnych Subscription IDs lub Resource Groups. Wtedy jawnie ustawić Storage Account Subscription ID i Storage Account Resource Group wskazujące rzeczywiste źródło.
Po wdrożeniu potwierdzić oczekiwany przepływ w odpowiednim kontenerze i jako netflow w Sophos. Przy obu typach odebrać każdą integrację osobno.

Jeżeli Function istnieje, ale danych brakuje, porównać kontener, Data Source Key, przypisanie Subscription/Resource Group i plan. Druga integracja tego samego strumienia może powodować duplikaty i nie jest uniwersalną naprawą.

GCP przez Pub/Sub

GCP dostarcza cloudaudit, thirdpartyalert, a z SIEM także netflow. Obsługiwane źródła obejmują Cloud Audit Logs, Security Command Center Findings, VPC Flow Logs i GKE Dataplane V2. Dołącza się tylko świadomie wybrane kategorie.

W odpowiednim projekcie GCP utworzyć topic pod Pub/Sub > Topics, a następnie subskrypcję w Subscriptions. Acknowledgement deadline ustawić na 300 sekund.
Pod Logging > Log router > Create Sink utworzyć sink do tego Cloud Pub/Sub topic. Filtry ograniczyć do potrzebnych logów. Logi organizacji i folderów wymagają odpowiedniego zagregowanego sinka; sink projektu nie obejmuje ich automatycznie.
Utworzyć dedykowane konto usługi. Pod Add Principal w subskrypcji Pub/Sub nadać jego identyfikatorowi rolę Pub/Sub Subscriber.
Utworzyć również rolę niestandardową z monitoring.timeSeries.list i przypisać ją kontu. Konto już używane przez Sophos XDR można wykorzystać ponownie, jeżeli to dodatkowe wymagane uprawnienie jest zatwierdzone.
Wygenerować klucz JSON i zabezpieczyć go. W Marketplace Sophos otworzyć GCP > Configured integrations > Add new, wpisać nazwę, Project ID i Subscription ID Pub/Sub, a następnie przesłać właściwy JSON przez Upload Key File.
Faktycznie włączyć źródła: logi Data Access wymagają wybrania usług pod IAM & Admin > Audit Logs. Findings SCC korzystają z odpowiedniego eksportu Pub/Sub. VPC Flow Logs włącza się na poziomie podsieci; próbkowanie ogranicza ich zakres dowodowy wobec pełnego przechwycenia pakietów.
GKE Dataplane V2 trzeba wybrać podczas tworzenia klastra. Następnie sprawdzić Network Policy Logging i filtr sinka. Nie zastępować bez planu istniejącego klastra wyłącznie na potrzeby pilota logowania.
Dla każdej kategorii wygenerować odpowiednie zdarzenie i osobno sprawdzić dowód źródłowy, trasę Pub/Sub oraz schemat normalizacji.

Podczas rotacji najpierw utworzyć nowy klucz JSON i zaktualizować istniejącą integrację Sophos. W API Query Log komunikat secrets cache invalidated. Integration was updated. Restarting. wskazuje aktualizację. Stary klucz GCP usunąć dopiero po ponownym potwierdzeniu odbioru danych. Samo przesłanie pliku nie wystarcza.

OCI przez Streaming

OCI dostarcza cloudaudit, http, nids, a z SIEM także netflow. Wymagane są stream OCI, wybrane logi i service connector. Tożsamość integracji potrzebuje stream-pull do odczytu; ogólne uprawnienia administracyjne nie są potrzebne do ciągłego pobierania.

Przygotować dedykowanego użytkownika logowania oraz zatwierdzoną strukturę grup i compartments. Nadać tylko wymagany odczyt właściwego strumienia.
Pod OCI Streams > Create Stream wybrać odpowiedni Stream Pool. Zapisać Stream Pool OCID; nie jest zamienny z dowolnym ID strumienia lub compartmentu.
Przez Connector Hub skierować do streamu zatwierdzone logi audit, flow, load balancer, WAF lub firewall. Przed konfiguracją Sophos sprawdzić dostarczanie do właściwego celu Streaming. Inny cel connectora nie zasila automatycznie tego streamu.
W Marketplace Sophos otworzyć OCI > Configured integrations > Add new. Wpisać Name, dedykowany Username, jego Auth token, Stream Pool ID, Tenant Name, Topic Name streamu i Region.
Dla zagnieżdżonych compartments Tenant Name jest nazwą tenancy bez łańcucha compartments. Dla użytkowników federacyjnych w udokumentowanym przypadku OracleIdentityCloudService używa się np. acme/OracleIdentityCloudService, gdzie acme oznacza własną tenancy. Nie mieszać tych przypadków.
Wybrać Done i potwierdzić odpowiednie zdarzenie w OCI, na ścieżce Streaming i w oczekiwanym schemacie Sophos. Zdarzenie cloud audit nie testuje dodatkowego strumienia netflow.

Przy braku danych sprawdzić najpierw Stream Pool, nazwę streamu, region, token i stream-pull. Jeżeli brakuje jednej kategorii, przeanalizować wybór źródeł i routing connectora przed ponownym tworzeniem całej integracji.

Jakość danych i kontrolowane wycofanie

Dla każdej kategorii zapisać źródło, początek zbierania, okres, znormalizowany schemat i powtarzalny przykład. Czas i strefę porównać z dowodem źródłowym. Zwykły flow lub rekord audit nie musi generować detection ani case MDR. Zielone połączenie lub znaleziony rekord nie dowodzą też wieloletniej retencji.

Przed wycofaniem zinwentaryzować ścieżkę i wspólne zasoby. Zatrzymać tylko zatwierdzony eksport, sink, trigger lub connector; nie usuwać bez rozróżnienia wspólnego bucketu, topicu, Storage Account czy streamu. Po potwierdzeniu braku nowych rekordów usunąć odpowiednią konfigurację Sophos oraz wyłącznie dedykowane klucze lub zasoby zgodnie z decyzjami change i retencji. Usunięcie połączenia nie dowodzi skasowania historycznej telemetrii.

Przy nieudanym pilocie zachować poprzednie potrzebne trasy logowania. Rollback cofa udokumentowaną nową zmianę routingu lub eksportu i sprawdza rezultat. Nie cofa automatycznie wysłanych danych, kosztów chmury ani utraconych zdarzeń.