Przejdz do tresci
Avanet
Zaloguj sie

Wdrożenie Sophos XDR Data Collectors w AWS, Azure i GCP

Sophos Fusion Admin

Sophos XDR Data Collector odbiera zdarzenia syslog i przesyła je szyfrowanym połączeniem do XDR. Wdrożenie chmurowe rozpoczyna się w Security Operations > Integrations > Data Collectors > Actions > Add Collector > Cloud-Hosted. Następnie generuje się template AWS, Azure lub GCP powiązany z konkretną konfiguracją collectora i wdraża na własnym koncie chmurowym.

Te ścieżki nie używają wymiennych obrazów VM. AWS korzysta z AMI, CloudFormation i EC2 User Data, Azure z VHD, ARM i Custom Data, GCP z konfiguracji Terraform dla Infrastructure Manager. Ta instrukcja opisuje chmurę; migracja SVA i wdrożenie lokalne pozostają osobno.

Sieć, odpowiedzialność i koszty przed wdrożeniem

Potrzebne są właściwy tenant Sophos, zatwierdzone konto lub projekt chmurowy i uprawnienia dla wybranego template. Instancja, dyski, load balancer oraz inne zasoby mogą generować koszty. Przed wdrożeniem sprawdzić template, sieć docelową, reguły bezpieczeństwa, odpowiedzialnych i zakres usuwania. Chronić wygenerowane konfiguracje oraz zawarte credentials.

Dla każdego źródła zapisać zdarzenia, wymagany format i adres docelowy. Standardowe wejścia syslog to UDP/514 i TCP/601. Ograniczać reguły do potrzebnych sieci źródłowych zamiast otwierać je na cały internet. Collector wymaga wychodzącego TCP/443 do przydzielonego regionalnego uplinku XDR, DNS przez UDP/TCP 53 oraz początkowej synchronizacji czasu przez UDP 123. Cele regionalne omawia instrukcja migracji; przed zmianą porównać je z aktualną safelistą.

Bez własnego NTP collectory inne niż AWS używają udokumentowanych serwerów pool, a AWS 169.254.169.123. Po połączeniu synchronizację przejmuje kanał backendu; Admiral może pokazać ntp.collector. Host Proxy jest opcjonalne. Ogólna pomoc wyklucza stałe uwierzytelniane proxy, choć niektóre strony wdrożeniowe pokazują składnię z użytkownikiem/hasłem. Produkcyjną ścieżkę uwierzytelnianego proxy trzeba więc najpierw uzgodnić z Sophos; credentials w template nie rozwiązują sprzeczności.

Wspólne utworzenie w Sophos Fusion

  1. Otworzyć Security Operations > Integrations > Data Collectors > Actions > Add Collector.
  2. Wybrać Cloud-Hosted i przejść Next.
  3. Wprowadzić unikalne Name i Hostname, opcjonalnie opis, Host Proxy i własne NTP. Przed Create Collector sprawdzić tenant, sieć i wartości.
  4. Wybrać Create Collector, następnie właściwy Cloud Service Provider. Dalsze ustawienia i pliki dotyczą tylko tego collectora i nie mogą być użyte dla wielu niezależnych instancji.

AWS: CloudFormation, jeden collector i NLB

Wymagane są właściwe 12-cyfrowe AWS Account ID, region obsługiwany w dialogu Sophos i odpowiedni istniejący VPC z podsieciami. Przykładowy template tworzy Launch Template z AMI/User Data, Auto Scaling Group o stałym rozmiarze jednej instancji, Network Load Balancer i reguły syslog.

NLB działa w Layer 4 i obsługuje TCP oraz UDP. Stabilna nazwa DNS pozostaje celem źródeł także po wymianie instancji. Application Load Balancer lub klasyczny ELB nie zastępują tego udokumentowanego projektu. Collector AWS nie obsługuje HA w tej konfiguracji; Auto Scaling Group musi mieć rozmiar 1. Równoczesne dwie instancje z identycznym User Data nie są obsługiwane.

Wdrożenie konfiguracji AWS

  1. W Sophos wybrać Amazon Web Services (AWS), podać Account ID i obsługiwany region AWS.
  2. W razie potrzeby zachować i przejrzeć YAML przez Download. Launch Console otwiera Create stack CloudFormation z wygenerowanym template.
  3. Przypisać CollectorName, VpcId i Subnets do zamierzonego środowiska. Sprawdzić VpcCidr oraz dodatkowe SyslogIngress względem faktycznie dozwolonych źródeł. 0.0.0.0/0 oznacza nieograniczone źródła IPv4, i nie należy przyjmować go jako ustawienia domyślnego.
  4. Sprawdzić InstanceType. Template Sophos używa c5.xlarge z 4 vCPU i 8 GB RAM. We własnym template dodatkowy dysk danych musi mieć co najmniej 200 GB i przypisanie /dev/sdb.
  5. Przy EBS Encryption właściciel AWS sprawdza KmsCmkArn i wymaganą key policy. Błędna polityka może powodować cyklicznie nieudane starty.
  6. Przez Next sprawdzić opcje stacka. Uruchomić Create stack dopiero po zatwierdzeniu zasobów i reguł.
  7. Po sukcesie zapisać CTPxCollectorDnsName z Outputs stacka. Ten DNS NLB jest celem źródeł syslog, nie tymczasowy adres EC2.

Sprawdzić status w Sophos Fusion. AWS przydziela adresy dynamicznie, więc pusta kolumna Address nie oznacza automatycznie błędu. Pętle startów Auto Scaling Group badać w zdarzeniach AWS; przy Client.InternalError: Client error on launch i aktywnym EBS Encryption szczególnie sprawdzić KMS key policy. Nie uruchamiać równolegle kolejnych instancji tej samej konfiguracji.

Azure: świeży template ARM i ograniczone uprawnienia

Wymagana jest subskrypcja Azure oraz odpowiedni Virtual Network z podsiecią. Template Sophos wymaga Owner albo Contributor + User Access Administrator. Dopasować te role do potrzebnego zakresu i zatwierdzonego wdrożenia, zamiast stale nadawać je wszystkim operatorom.

Template kopiuje VHD do Storage Account z prywatnym kontenerem, tworzy Managed Image i jedną VM collectora z Network Security Group. Storage Account służy temu zadaniu. SAS URL obrazu VHD jest ważny tylko trzy godziny od wygenerowania ARM. Nie ponawiać więc po prostu starego niezmienionego template.

Template pobrane od 3 sierpnia 2026 używają tymczasowego Azure Deployment Script poza Virtual Network do kopiowania VHD. Nie wymagają bootstrap VM, bootstrap NSG ani dodatkowego wyjątku wyjściowego bootstrap w VNet. Starsze template miały inny projekt z tymczasową VM i kontenerem czyszczącym; nie przenosić zapobiegawczo ich wyjątków do nowego wdrożenia. Dla nowego rollout pobrać świeży template.

Wdrożenie konfiguracji Azure

  1. Wybrać Microsoft Azure w Sophos. W razie potrzeby Download ARM Template; Deploy in Azure otwiera przygotowane Custom deployment.
  2. Wybrać Subscription i właściwy Resource group. Osobna grupa ułatwia identyfikację i usuwanie, ale nie uzasadnia przenoszenia do niej współdzielonej sieci.
  3. Wybrać region zgodny z VNet. Ustawić Vm Name i Vm Size; obecna instrukcja Sophos zaleca Standard_D4s_v3.
  4. Dokładnie wskazać grupę VNet, Azure Virtual Network i Azure Virtual Network Subnet. W Static Private IP podać wolny odpowiedni adres lub pozostawić puste dla automatycznego przydziału.
  5. Zachować wygenerowane domyślne Utc Now i Random Seed. Służą odpowiednio unikalnym nazwom i tymczasowemu hasłu wdrożeniowemu.
  6. Sprawdzić NSG: dokumentacja podaje przychodzące UDP/514 i TCP/601 z VNet oraz wymagany ruch wyjściowy XDR, DNS i NTP. Uwzględnić inne własne zasady sieci i bezpieczeństwa w template.
  7. Przeczytać warunki Marketplace i rozpocząć Purchase dopiero po zatwierdzeniu zasobów. Porównać wynik Azure ze statusem w Sophos Fusion.

We własnym template dodatkowy dysk pozostaje co najmniej 200 GB i /dev/sdc. Azure również nie obsługuje HA w opisanym projekcie; ewentualny własny VM Scale Set może uruchamiać tylko jedną instancję z tym samym Custom Data. Działająca VM collectora sama nie aktywuje audytu Microsoft 365; to źródło konfiguruje się i weryfikuje osobno.

GCP: Infrastructure Manager i własny Service Account

GCP wymaga zatwierdzonego projektu, włączonego Infrastructure Manager API, Cloud Shell lub dostępnego już gcloud CLI oraz user-managed Service Account. Zarządzane przez Google konto <numeric ID>@cloudservices.gserviceaccount.com nie jest według Sophos właściwe.

Administrator wdrożenia przygotowuje konto, np. infra-manager-sa, z roles/compute.instanceAdmin.v1, roles/compute.securityAdmin i roles/config.agent w projekcie docelowym. Role umożliwiają tworzenie instancji/dysków, zarządzanie regułami i działanie Infrastructure Manager. Ich prawa zapisu wymagają osobnego przygotowania i akceptacji; przegląd collectora tylko do odczytu ich nie potrzebuje.

Generowanie i zastosowanie konfiguracji GCP

  1. Wybrać Google Cloud Platform (GCP) i wprowadzić GCP Project ID.
  2. W Service Agent ID przypisać zamierzony user-managed Service Account. Mimo nazwy pola nie używać Google-managed Service Agent.
  3. Sprawdzić GCP Region, GCP Zone, Network Name, Subnet Name i Network CIDR. CIDR musi odpowiadać zamierzonym regułom; nie wpisywać ogólnego otwarcia internetu.
  4. Zapisać archiwum Terraform przez Download. W konsoli właściwego projektu otworzyć Cloud Shell, wgrać konkretny ZIP i rozpakować do osobnego katalogu. Nazwa pliku musi odpowiadać właśnie utworzonemu collectorowi.
unzip collector-*.zip -d collector-infrastructure

Przykład producenta używa wildcard. Katalog roboczy musi więc zawierać dokładnie zamierzone archiwum; jeśli pasuje kilka plików, podać dokładną nazwę. Przed zastosowaniem przejrzeć Terraform pod kątem zasobów, sieci, reguł i tożsamości. Konfiguracja tworzy Compute instance z interfejsem i dyskiem co najmniej 200 GB jako /dev/sdb.

Sophos dokumentuje następujące polecenie:

gcloud infra-manager deployments apply \
  projects/PROJECT_ID/locations/LOCATION/deployments/taegis-collector \
  --service-account projects/PROJECT_ID/serviceAccounts/infra-manager-sa@PROJECT_ID.iam.gserviceaccount.com \
  --local-source="./collector-infrastructure" \
  --tf-version-constraint="1.5.7"

Wszędzie zastąpić PROJECT_ID zatwierdzonym projektem, a LOCATION obsługiwaną lokalizacją Infrastructure Manager. Nazwa Service Account musi odpowiadać rzeczywiście utworzonemu kontu. taegis-collector nazywa zasób deployment i nie może przypadkowo nadpisać innego istniejącego wdrożenia. apply tworzy lub zmienia rzeczywiste zasoby chmurowe; wykonywać je dopiero po przeglądzie i zgodzie.

Sophos wskazuje gcloud infra-manager previews create jako wcześniejszą opcję podglądu. Także preview musi używać właściwego projektu i zatwierdzonego konta, i nie zastępuje sprawdzenia proponowanych zmian. Po udanym Apply zweryfikować collector i źródła. Według instrukcji Provisioning powinien zakończyć się w ciągu dziesięciu minut; w przeciwnym razie badać wdrożenie i łączność, zamiast wielokrotnie niekontrolowanie tworzyć ten sam deployment.

Shared VPC: rozdzielenie projektu sieci i usługi

Domyślnie template oczekuje sieci i instancji w jednym projekcie. W Shared VPC Host Project posiada VPC, podsieci i reguły, a Service Project instancję collectora i dysk. Oba projekty muszą wcześniej istnieć.

Administrator organizacji włącza Shared VPC w projekcie hosta i dołącza projekt usługowy. Wymagane jest roles/compute.xpnAdmin na poziomie organizacji, nie zwykła rola projektu. Następnie infra-manager-sa z projektu usługowego otrzymuje w projekcie hosta dodatkowo roles/compute.securityAdmin do reguł oraz roles/compute.networkUser do sieci.

W kreatorze Sophos wypełnić Network Project ID identyfikatorem hosta; inne pola projektu pozostawić skierowane na projekt usługowy. Również PROJECT_ID w celu Apply i adresie Service Account pozostaje ID projektu usługowego. Przed akceptacją osobno odczytać to przypisanie: zamiana wszystkich placeholderów na hosta zniosłaby zamierzony podział zasobów.

Odbiór źródeł i zachowanie trwałej konfiguracji

Po wdrożeniu collector musi być osiągalny w Sophos Fusion. Następnie ograniczone źródło pilotażowe wysyła poprawny syslog do właściwego celu. W wyszukiwaniu XDR porównać źródło, czas, typ i oczekiwane pola. Zdrowy collector lub udany stack nie dowodzi pełnej ingestii i normalizacji.

Instrukcja operacyjna opisuje widoki źródeł, backlog i Admiral. Pozostałe źródła przełączać dopiero po odbiorze pilota; zachować poprzednie ścieżki logów do uzgodnionego odbioru. Collector nie zastępuje ani uprawnień SIEM i inwentaryzacji retencji, ani integracji API danego produktu.

Po późniejszej zmianie konfiguracji w Sophos Fusion zapisać nowe pliki i zaktualizować także istniejącą chmurę: stack AWS CloudFormation bieżącym template, Azure aktualnym ARM, GCP nową konfiguracją Terraform. Inaczej przyszła wymiana instancji może przywrócić stare wartości bootstrap. Sama udana zmiana online nie dowodzi trwałości.

Przy wycofaniu najpierw przywrócić źródła na zachowaną wcześniejszą ścieżkę i wykazać świeże zdarzenia. Potem usuwać wyłącznie jednoznacznie przypisane zasoby collectora zgodnie z procedurą zmiany chmury. Nie usuwać wspólnych VPC/VNet, podsieci, kluczy czy Service Accounts w ramach ogólnego „czyszczenia collectora”. Rollback infrastruktury nie odtwarza automatycznie utraconych lub źle znormalizowanych zdarzeń historycznych.