Distribuire Sophos Server Protection su AWS EC2 e sulle VM Azure

Un’istanza EC2 o una VM Azure viene protetta all’interno del sistema operativo guest con Sophos Server Protection. Per Windows Server si usa il Windows Server Installer; per i server Linux supportati, Sophos Protection for Linux (SPL). La posizione della VM non cambia la scelta dell’agente server. Sophos Firewall come appliance virtuale in AWS o Azure protegge e instrada il traffico di rete, ma non sostituisce l’agente nel sistema guest. Sophos Cloud Optix è un prodotto distinto per la postura di sicurezza e l’inventario cloud, non un prerequisito per installare la protezione dei server: secondo la comunicazione di Sophos sul ciclo di vita, supporto e accesso termineranno il 30 settembre 2026. Non è quindi una base per un nuovo processo, o per un processo duraturo, di inventario e pulizia delle risorse cloud. La disponibilità di Server Protection e delle sue funzionalità nel proprio tenant, così come la relativa copertura contrattuale, va verificata separatamente.

Percorso rapido: scegliere una VM rappresentativa, approvare sistema operativo e modalità di protezione, testare la connettività a Sophos Fusion dalla sua effettiva rete cloud, installare l’installer server associato al tenant e controllare My Products > Server > Servers e i dettagli del server. Autorizzare la distribuzione alla fase successiva solo dopo aver verificato registrazione, gruppo, criteri, stato dell’agente e funzionamento dell’applicazione. Per le istanze di breve durata occorre inoltre pianificare un confronto specifico con l’inventario cloud.

Prima del test pilota: definire protezione e percorso di rete

1. VM e contratto: registrare account AWS o subscription Azure, regione, ruolo della VM, build del sistema operativo o distribuzione Linux, architettura e ciclo di vita. Verificare il supporto attuale per quello specifico sistema operativo guest e per i componenti richiesti. Confermare la licenza del tenant interessato e lo SKU server acquistato, comprese le condizioni contrattuali applicabili a queste VM; la presenza di un pulsante di download non prova il diritto d’uso.
2. Modalità di protezione: scegliere la protezione antimalware completa di Sophos oppure XDR Sensor. XDR Sensor da solo non offre protezione antimalware e richiede una protezione di terze parti attiva. Prima di cambiare modalità, valutare i conflitti con il software di sicurezza esistente e definire un piano di ripristino per la VM interessata.
3. Connettività in uscita: dalla subnet prevista, verificare che DNS, HTTPS, le destinazioni Sophos richieste dal tenant ed eventualmente il proxy o il Message Relay siano raggiungibili durante l’installazione e il funzionamento. Security Groups, Network Security Groups, route cloud, NAT, firewall e ispezione TLS possono influire sul percorso. L’allowlist aggiornata e la diagnostica del proxy sono descritte nei requisiti di rete e proxy. Non considerare un elenco fisso di indirizzi IP cloud come sostituto delle destinazioni Sophos.
4. Test pilota e criteri di accettazione: scegliere un piccolo gruppo di VM rappresentativo per ruolo server, versione del sistema operativo, segmento di rete ed eventuale percorso proxy. Registrare nomi, gruppo server previsto, criteri da applicare, finestra di riavvio, test del carico applicativo e criteri di arresto. Se vi sono più subnet o immagini, prevedere almeno un test adeguato per ogni percorso diverso.

Esempio: una VM applicativa Windows e una VM worker Linux in due subnet private distinte sono due casi pilota, non un unico test di rete. Il completamento dell’installer sulla prima VM non dimostra che la seconda possa raggiungere la destinazione degli aggiornamenti attraverso il proprio percorso NAT o proxy.

Eseguire l’installer nel sistema guest e preparare correttamente le immagini

In My Environment > Installers > Server Protection, selezionare dal tenant Sophos Fusion corretto il Windows Server Installer o il Linux Server Installer adatto alla modalità di protezione approvata. Su una singola VM Windows trasferire SophosSetup.exe in modo sicuro, eseguirlo con privilegi di amministratore locale, seguire i controlli preliminari mostrati e completare l’installazione e l’eventuale riavvio richiesto. Su una VM Linux trasferire SophosSetup.sh in modo sicuro, renderlo eseguibile e lanciare prima sudo ./SophosSetup.sh --test, poi, se il test riesce, sudo ./SophosSetup.sh. Verificare quindi la registrazione nel tenant e lo stato locale dell’agente: il solo completamento dell’installer non basta. Modalità di protezione, opzioni CLI avanzate, log e risoluzione dei problemi sono descritti in Installare e distribuire Windows Server Protection e Installare e distribuire SPL. Conservare l’installer associato al tenant e il relativo indirizzo di download solo in un archivio di pacchetti protetto, mai in un’immagine VM pubblica o in un repository.

Non clonare senza modifiche la VM master già registrata. Per SPL in una golden image Linux, dopo l’installazione occorre deregistrare la VM master con registerCentral --deregister secondo la procedura per le golden image Linux, spegnerla subito e acquisirne l’immagine da spenta. Un successivo avvio della VM master potrebbe registrarla di nuovo; in tal caso, deregistrarla nuovamente prima di salvare l’immagine. Avviare due cloni e verificare che abbiano identità distinte.

Per Windows Server la procedura di creazione dell’immagine è diversa: prima di crearla, controllare che Tamper Protection sia disattivata per la configurazione dell’immagine e verificare se Server Lockdown o Update Cache sono attivi; non creare golden image da server con queste funzionalità attive. Sono esclusi anche i master cifrati con BitLocker o dotati di componenti Sophos Encryption. Come amministratore, eseguire SophosSetup.exe --goldimage con il Windows Server Installer associato al tenant secondo la procedura per le golden image Windows (valida anche per i server), verificare installazione e stato dell’agente, riattivare Tamper Protection e spegnere il master prima dello snapshot dell’immagine. Al primo avvio, ogni clone deve ricevere, prima del rilevamento da parte di Sophos, un nome computer definitivo e diverso da quello del master: Sophos riconosce i cloni dal cambio di nome, non dall’ID dell’istanza cloud. Se l’assegnazione del nome avviene in ritardo, valutare la modalità timeout descritta nella guida; la modalità Notification è descritta lì per VMware Horizon Instant Clone e non va applicata indiscriminatamente a EC2/Azure. Non considerare una normale installazione Windows già pronta per la clonazione. Anche in questo caso, convalidare separatamente due cloni in Fusion.

Verificare la distribuzione nel cloud e fermarsi in caso di problemi

Dopo l’installazione o l’avvio di un clone pilota, aprire singolarmente i server attesi in My Products > Server > Servers. Due cloni in esecuzione contemporaneamente devono comparire come due oggetti server distinguibili. Per la verifica, registrare all’esterno di Fusion la corrispondenza tra account AWS/subscription Azure, regione, ID dell’istanza EC2/ID della risorsa VM Azure, ID del server Fusion, responsabile e data e ora di creazione: l’elenco dei server non mostra automaticamente gli ID cloud. Nei dettagli verificare Summary, Status e Policies, oltre a ultima attività, stato dell’agente, componenti installati e criteri server effettivi. Il primo criterio predefinito applicato automaticamente non coincide necessariamente con quello previsto per la produzione. Confrontare quindi servizio, accesso all’applicazione, backup e un test rappresentativo del carico applicativo prima e dopo l’eventuale riavvio.

Se una VM non compare in Fusion, controllare prima tenant e filtri, poi DNS, proxy, percorso di rete in uscita e log d’installazione secondo il runbook per Windows o per Linux. Se non si riesce a distinguere i cloni, interrompere la distribuzione dell’immagine e ricontrollare il passaggio relativo all’identità nella procedura per le golden image. In presenza di componenti errati, stato dell’agente insoddisfacente o problemi al carico applicativo, non autorizzare la fase successiva: esaminare isolatamente la fase interessata, anziché riapplicare alla cieca installer e criteri.

Gestire separatamente le istanze terminate e i dispositivi inattivi

Le VM di breve durata possono essere già terminate mentre il loro record è ancora visibile in Sophos Fusion. Un valore Last Active datato non prova che l’istanza cloud sia stata terminata, né indica un termine universale per la pulizia automatica. Confrontare regolarmente la corrispondenza esterna tra account/subscription, regione, ID dell’istanza o risorsa cloud e ID del server Fusion con l’inventario AWS/Azure e con l’inventario dei dispositivi Fusion; registrare il responsabile, le date del ciclo di vita e la prova dell’evento Terminate per EC2 o Delete per la VM Azure. Un nome host riutilizzato o una VM Azure arrestata non dimostrano che l’oggetto server associato sia stato dismesso.

Il confronto manuale e l’operazione mirata di Delete restano la procedura di base: solo dopo aver accertato la terminazione nel cloud e la corrispondenza univoca degli ID, conservare gli alert e i dati delle indagini necessari, verificare eventuali duplicati e documentare la dismissione o la protezione sostitutiva. Delete in Fusion non sostituisce né la disinstallazione su una VM ancora in esecuzione né la gestione del ciclo di vita nel cloud.

Separatamente, Sophos documenta in Removal of inactive devices una regola Server configurabile per i dispositivi inattivi: mirata a gruppi specifici oppure globale con esclusioni di gruppi (le esclusioni non si applicano alle regole mirate). La regola reagisce all’inattività, non alla conferma di un evento EC2 Terminate o Azure Delete e non disinstalla l’agente. Prima di attivarla nel proprio tenant, verificare su un insieme di prova gruppi, intervallo di inattività, esclusioni, conservazione dei dati e conseguenze per le VM di produzione arrestate o temporaneamente irraggiungibili; non presumere un intervallo standard né effetti sulle licenze. La precedente integrazione con Cloud Optix offriva, per gli ambienti AWS/Azure esistenti collegati allo stesso tenant e dotati di agenti server, una funzione separata di pulizia dopo la terminazione: disattivata per impostazione predefinita, attivabile solo da un Super Admin e non retroattiva per le istanze terminate in precedenza. Poiché supporto e accesso termineranno il 30 settembre 2026, questo è solo un riferimento storico, non una raccomandazione per nuove configurazioni o automazioni durature. Non si promette alcuna procedura non verificata per hook di eliminazione legati all’autoscaling, automazione tramite API o conteggio delle licenze.