Ir al contenido
Avanet
Iniciar sesion

Desplegar Sophos XDR Data Collectors en AWS, Azure y GCP

Sophos Fusion Admin

Un Sophos XDR Data Collector recibe eventos syslog y los reenvía cifrados a XDR. El despliegue cloud empieza en Security Operations > Integrations > Data Collectors > Actions > Add Collector > Cloud-Hosted. Después se genera una plantilla AWS, Azure o GCP asociada a la configuración concreta y se despliega en la cuenta cloud propia.

Las tres rutas no usan imágenes VM intercambiables. AWS utiliza AMI con CloudFormation y EC2 User Data, Azure VHD con ARM y Custom Data, GCP Terraform para Infrastructure Manager. Esta guía trata cloud; migración SVA y despliegue local permanecen separados.

Aclarar red, responsabilidad y costes antes del despliegue

Se requieren tenant Sophos correcto, cuenta o proyecto cloud autorizado y permisos para la plantilla elegida. Instancias, discos, balanceadores y otros recursos pueden generar costes. Revisar plantilla, red destino, reglas, responsables y alcance de retirada antes de desplegar. Proteger configuraciones generadas y credentials incluidas.

Registrar por fuente eventos, formato esperado y dirección destino. Las entradas syslog estándar son UDP/514 y TCP/601. Limitar reglas a redes fuente necesarias, sin abrirlas a todo Internet. Se requieren TCP/443 saliente al uplink XDR regional asignado, DNS por UDP/TCP 53 y sincronización inicial por UDP 123. El runbook de migración explica los destinos regionales; compararlos con la safelist actual antes del cambio.

Sin NTP propio, collectors no AWS usan los servidores pool documentados; AWS utiliza 169.254.169.123. Una vez conectado, el canal backend sincroniza la hora; Admiral puede mostrar ntp.collector. Host Proxy es opcional. La ayuda general excluye proxies autenticados configurados de forma fija, aunque algunas páginas muestran usuario/contraseña en la sintaxis. Aclarar primero con Sophos un proxy autenticado de producción; incluir credentials en la plantilla no resuelve la contradicción.

Creación común en Sophos Fusion

  1. Abrir Security Operations > Integrations > Data Collectors > Actions > Add Collector.
  2. Elegir Cloud-Hosted y Next.
  3. Introducir Name y Hostname únicos y, si procede, descripción, Host Proxy y NTP propios. Revisar tenant, red y valores antes de Create Collector.
  4. Elegir Create Collector y el Cloud Service Provider adecuado. Los datos y archivos posteriores corresponden solo a este collector y no se reutilizan en varias instancias independientes.

AWS: CloudFormation, un collector y un NLB

Se necesitan AWS Account ID de 12 dígitos correcto, región admitida por Sophos y VPC existente adecuado con subredes. La plantilla crea Launch Template con AMI/User Data, Auto Scaling Group de tamaño estático de una instancia, Network Load Balancer y reglas syslog.

El NLB funciona en Layer 4 y admite TCP y UDP. Su DNS estable sigue siendo destino válido al sustituir la instancia. Un Application Load Balancer o ELB clásico no sustituye este diseño documentado. El collector AWS no admite HA en esta configuración; mantener Auto Scaling Group en 1. Dos instancias simultáneas con User Data idéntica no están admitidas.

Desplegar la configuración AWS

  1. En Sophos elegir Amazon Web Services (AWS), introducir Account ID y seleccionar región AWS admitida.
  2. Si procede, guardar y revisar YAML mediante Download. Launch Console abre Create stack de CloudFormation con la plantilla generada.
  3. Asignar CollectorName, VpcId y Subnets al entorno previsto. Comprobar VpcCidr y SyslogIngress adicional frente a redes realmente permitidas. 0.0.0.0/0 es un rango fuente IPv4 sin restricciones y no debe adoptarse por defecto.
  4. Revisar InstanceType. La plantilla Sophos usa c5.xlarge, 4 vCPU y 8 GB RAM. En una plantilla propia, el disco adicional debe mantener al menos 200 GB y asociación /dev/sdb.
  5. Con EBS Encryption, pedir al responsable AWS que revise KmsCmkArn y key policy. Una política incorrecta puede causar lanzamientos fallidos repetidos.
  6. Revisar opciones con Next. Ejecutar Create stack solo tras aprobar recursos y reglas concretos.
  7. Tras éxito, guardar CTPxCollectorDnsName en Outputs del stack. Ese DNS NLB es el destino syslog, no una IP EC2 temporal.

Comprobar estado en Sophos Fusion. Como AWS asigna direcciones dinámicamente, Address vacío no implica automáticamente error. Investigar bucles de lanzamiento mediante eventos AWS; con Client.InternalError: Client error on launch y EBS Encryption activo, revisar especialmente la política KMS. No iniciar más instancias idénticas en paralelo.

Azure: ARM reciente y permisos delimitados

Se necesitan suscripción Azure y Virtual Network con subred adecuado. La plantilla Sophos requiere Owner o Contributor + User Access Administrator. Ajustar permisos al alcance y despliegue autorizados, sin darlos permanentemente a todos los operadores.

La plantilla copia VHD a un Storage Account con contenedor privado, crea Managed Image y una sola VM collector con Network Security Group. Ese almacenamiento es para esta tarea. La SAS URL de VHD solo vale tres horas desde generar ARM. No reintentar simplemente una plantilla antigua sin cambios.

Las plantillas descargadas desde el 3 de agosto de 2026 usan un Azure Deployment Script temporal fuera del Virtual Network para copiar VHD. No se necesitan bootstrap VM, bootstrap NSG ni excepción saliente bootstrap adicional en VNet. Las antiguas usaban VM temporal y contenedor de limpieza; no trasladar preventivamente sus excepciones a un despliegue nuevo. Usar una plantilla reciente para un rollout nuevo.

Desplegar la configuración Azure

  1. Elegir Microsoft Azure en Sophos. Usar Download ARM Template si procede; Deploy in Azure abre Custom deployment preparado.
  2. Elegir Subscription y Resource group correcto. Un grupo dedicado facilita identificación y retirada, sin justificar mover recursos de red compartidos.
  3. Seleccionar región adecuada al VNet. Definir Vm Name y Vm Size; Sophos recomienda Standard_D4s_v3 en la guía actual.
  4. Identificar exactamente grupo del VNet, Azure Virtual Network y Azure Virtual Network Subnet. Poner una Static Private IP libre y apropiada o dejar vacío para asignación automática.
  5. Mantener valores generados de Utc Now y Random Seed, destinados respectivamente a nombres únicos y contraseña temporal de despliegue.
  6. Revisar NSG: entradas documentadas UDP/514 y TCP/601 desde VNet, salidas XDR, DNS y NTP necesarias. Incorporar otros requisitos propios en la plantilla.
  7. Revisar condiciones Marketplace y comenzar Purchase solo después de aprobar los recursos. Comparar resultado Azure y estado Sophos Fusion.

En una plantilla adaptada, conservar disco adicional de al menos 200 GB en /dev/sdc. Azure tampoco admite HA en este modelo; un VM Scale Set propio solo puede ejecutar una instancia con esa Custom Data. Una VM funcional no activa por sí sola una integración de auditoría Microsoft 365; configurar y validar esa fuente aparte.

GCP: Infrastructure Manager y Service Account propio

GCP requiere proyecto autorizado, Infrastructure Manager API activada, Cloud Shell o gcloud CLI ya disponible y user-managed Service Account. La cuenta Google-managed <numeric ID>@cloudservices.gserviceaccount.com no es adecuada según Sophos.

El administrador crea la cuenta, por ejemplo infra-manager-sa, con roles/compute.instanceAdmin.v1, roles/compute.securityAdmin y roles/config.agent en el proyecto. Permiten crear instancias/discos, gestionar reglas y operar Infrastructure Manager. Aprobar estos permisos de escritura es una preparación separada; una revisión de lectura del collector no los necesita.

Generar y aplicar la configuración GCP

  1. Elegir Google Cloud Platform (GCP) e introducir GCP Project ID.
  2. En Service Agent ID, asignar el user-managed Service Account previsto. Pese al nombre del campo, no usar Google-managed Service Agent.
  3. Revisar GCP Region, GCP Zone, Network Name, Subnet Name y Network CIDR. El CIDR debe corresponder a las reglas previstas, sin apertura general a Internet.
  4. Guardar el archivo Terraform con Download. Abrir Cloud Shell en el proyecto correcto, subir el ZIP específico y extraerlo en un directorio propio. El nombre debe corresponder al collector recién generado.
unzip collector-*.zip -d collector-infrastructure

El ejemplo usa un comodín. El directorio debe contener exactamente el archivo previsto; si coinciden varios, usar su nombre exacto. Revisar recursos, redes, reglas e identidad en Terraform antes de aplicar. La configuración crea instancia Compute con interfaz y disco de datos de al menos 200 GB en /dev/sdb.

Sophos documenta el siguiente comando:

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"

Sustituir siempre PROJECT_ID por el proyecto autorizado y LOCATION por una ubicación Infrastructure Manager admitida. El nombre del Service Account debe coincidir con el creado realmente. taegis-collector identifica el recurso de despliegue y no debe sobrescribir otro existente por accidente. apply crea o modifica recursos cloud reales; ejecutar solo tras revisión y aprobación.

Sophos indica gcloud infra-manager previews create como vista previa inicial. También requiere proyecto correcto y cuenta autorizada, y no sustituye revisar los cambios propuestos. Tras Apply correcto, revisar estado y fuentes. Según la guía, Provisioning debe terminar en un máximo de diez minutos; si no, investigar despliegue y conectividad en vez de crear repetidamente el mismo despliegue sin control.

Shared VPC: separar proyectos de red y servicio

Por defecto, la plantilla espera red e instancia en el mismo proyecto. En Shared VPC, Host Project posee VPC, subredes y reglas; Service Project contiene instancia collector y disco. Ambos deben existir previamente.

El administrador de organización activa Shared VPC en el host y asocia el proyecto de servicio. Se requiere roles/compute.xpnAdmin a nivel de organización, no un rol de proyecto normal. Después infra-manager-sa del proyecto de servicio recibe en el host roles/compute.securityAdmin para reglas y roles/compute.networkUser para uso de red.

En el asistente Sophos, completar Network Project ID con el ID host y dejar los otros proyectos apuntando al de servicio. PROJECT_ID en destino Apply y dirección Service Account sigue siendo el ID del proyecto de servicio. Releer esas asignaciones por separado antes de aprobar: cambiar todos los marcadores al host eliminaría la separación prevista.

Aceptar fuentes y conservar configuración persistente

Tras desplegar, el collector debe estar accesible en Sophos Fusion. Hacer que una fuente piloto limitada envíe el syslog adecuado al destino correcto. Comparar fuente, hora, tipo y campos esperados en la búsqueda XDR. Un collector sano o stack correcto no demuestra ingesta y normalización completas.

El runbook operativo explica vistas de fuentes, backlog y Admiral. Mover otras fuentes solo tras aceptar el piloto; preservar las rutas anteriores hasta la aceptación acordada. El collector no sustituye ni derechos SIEM e inventario de retención, ni una integración API específica.

Si después cambia la configuración en Sophos Fusion, guardar nuevos archivos y actualizar asimismo el despliegue cloud existente: stack AWS CloudFormation con plantilla actual, Azure con ARM actual y GCP con nueva configuración Terraform. De lo contrario, sustituir una instancia puede restaurar valores bootstrap antiguos. Un cambio online correcto no demuestra esa persistencia.

Para retirar, devolver primero fuentes a la ruta anterior conservada y comprobar allí eventos recientes. Eliminar después solo recursos claramente asignados al collector mediante el proceso cloud correspondiente. No eliminar VPC/VNet, subredes, claves o Service Accounts compartidos como «limpieza del collector» general. Revertir infraestructura no recupera automáticamente eventos históricos perdidos o mal normalizados.