Sophos Server Protection uitrollen op AWS EC2 en Azure-VM's

Een EC2-instantie of Azure-VM wordt in het gastbesturingssysteem beveiligd met Sophos Server Protection. Voor Windows Server gebruik je het Windows Server Installer; voor ondersteunde Linux-servers Sophos Protection for Linux (SPL). De locatie van de VM verandert niets aan de keuze van de serveragent. Sophos Firewall als virtuele appliance in AWS of Azure beveiligt en routeert netwerkverkeer; deze vervangt geen agent in het gastbesturingssysteem. Sophos Cloud Optix is een afzonderlijk product voor cloudbeveiligingsstatus en inventarisatie, geen voorwaarde voor de installatie van Server Protection. Volgens de levenscyclusmededeling van Sophos eindigen ondersteuning en toegang op 30 september 2026. Het is daarom geen basis voor een nieuw of blijvend proces voor cloudinventarisatie en opschoning. Controleer afzonderlijk of Server Protection en de benodigde functies beschikbaar zijn in de eigen tenant en onder het contract vallen.

Snelle route: Kies een representatieve VM, keur het besturingssysteem en de beveiligingsmodus goed, test de verbinding met Sophos Fusion vanuit het daadwerkelijke cloudnetwerk, installeer het tenantgebonden serverinstallatieprogramma en controleer vervolgens My Products > Server > Servers en de serverdetails. Geef de volgende uitrolfase pas vrij als registratie, groep, beleidsregels, agentstatus en applicatie naar behoren werken. Plan voor kortlevende instanties ook een eigen vergelijking met de cloudinventaris.

Voor de pilot: beveiliging en netwerkpad bepalen

1. VM en contract: Leg AWS-account of Azure-subscription, regio, VM-rol, build van het besturingssysteem of Linux-distributie, architectuur en levenscyclus vast. Controleer de actuele ondersteuning voor precies dit gastbesturingssysteem en de benodigde onderdelen. Bevestig de licentie van de betreffende tenant en de bestelde server-SKU met de contractvoorwaarden voor deze VM’s; een zichtbare downloadknop bewijst geen gebruiksrecht.
2. Beveiligingsmodus: Kies volledige Sophos-malwarebescherming of XDR Sensor. De zelfstandige XDR Sensor biedt geen malwarebescherming en vereist actieve bescherming van een andere leverancier. Onderzoek vóór omschakeling mogelijke conflicten met bestaande beveiligingssoftware en bepaal hoe je de wijziging voor de betrokken VM terugdraait.
3. Uitgaande verbinding: Controleer vanuit het beoogde subnet of DNS, HTTPS, de voor de tenant vereiste Sophos-eindpunten en, indien van toepassing, proxy of Message Relay tijdens installatie en gebruik bereikbaar zijn. Security Groups, Network Security Groups, cloudroutes, NAT, firewalls en TLS-inspectie kunnen het pad beïnvloeden. De actuele allowlist en proxydiagnose staan bij netwerk- en proxyvereisten. Ga er niet van uit dat een vaste lijst cloud-IP-adressen de Sophos-eindpunten vervangt.
4. Pilot en acceptatie: Kies een kleine groep VM’s met een representatieve serverrol, OS-versie, netwerksegment en eventueel proxypad. Leg namen, verwachte servergroep, beoogde beleidsregels, herstartvenster, workloadtest en stopcriteria vast. Plan bij meerdere subnetten of images minstens één passende test per afwijkend pad.

Voorbeeld: een Windows-applicatie-VM en een Linux-worker-VM in verschillende privésubnetten zijn twee pilotgevallen, geen gezamenlijke netwerktest. Een geslaagd installatieprogramma op de eerste VM bewijst niet dat de tweede haar update-eindpunt via haar NAT- of proxypad kan bereiken.

Installatieprogramma in de VM uitvoeren en images correct voorbereiden

Selecteer onder My Environment > Installers > Server Protection het Windows Server Installer of Linux Server Installer dat past bij de goedgekeurde beveiligingsmodus, vanuit de juiste Sophos Fusion-tenant. Breng SophosSetup.exe veilig over naar een afzonderlijke Windows-VM, start het met lokale beheerdersrechten, volg de weergegeven controles vooraf en rond de installatie inclusief de gevraagde herstart af. Breng op een Linux-VM SophosSetup.sh veilig over, maak het uitvoerbaar en voer eerst sudo ./SophosSetup.sh --test uit en na een geslaagde test sudo ./SophosSetup.sh. Controleer daarna de registratie in de tenant en de lokale agentstatus; alleen het afronden van het installatieprogramma is niet voldoende. Beveiligingsmodus, geavanceerde CLI, logboeken en probleemoplossing staan in Windows Server Protection installeren en uitrollen en SPL installeren en uitrollen. Bewaar het tenantgebonden installatieprogramma en de download-URL alleen in een beveiligde pakketopslag, niet in een openbaar VM-image of repository.

Kloon een al geregistreerde master-VM niet ongewijzigd. Bij SPL in een Linux-golden-image moet de master-VM na installatie met registerCentral --deregister volgens de procedure voor Linux-golden-images worden afgemeld, onmiddellijk worden uitgeschakeld en in uitgeschakelde toestand als image worden opgeslagen. Als de master-VM later opnieuw wordt gestart, kan deze zich opnieuw registreren; meld haar in dat geval vóór het opslaan nogmaals af. Start twee klonen en controleer hun afzonderlijke identiteiten.

Voor Windows Server geldt een ander imageproces: Controleer vóór het maken van het image of Tamper Protection voor de imageconfiguratie is uitgeschakeld en of Server Lockdown of Update Cache actief is; maak van zulke servers geen golden image. Ook met BitLocker versleutelde masters en masters met Sophos Encryption-onderdelen zijn uitgesloten. Voer met het tenantgebonden Windows Server Installer als beheerder SophosSetup.exe --goldimage uit volgens de procedure voor Windows-golden-images (ook voor servers), controleer de installatie en de status, schakel Tamper Protection weer in en sluit de master af vóór de image-snapshot. Bij de eerste start moet elke kloon tijdig vóór de Sophos-detectie een definitieve computernaam krijgen die verschilt van die van de master: Sophos herkent klonen aan de naamswijziging, niet aan de cloudinstantie-ID. Controleer bij vertraagde naamtoekenning de timeoutmodus uit de handleiding; de Notification Mode wordt daar beschreven voor VMware Horizon Instant Clone en is niet zonder meer toepasbaar op EC2/Azure. Ga er niet van uit dat een gewone Windows-installatie al klaar is om te klonen. Controleer ook hier twee klonen afzonderlijk in Fusion.

Cloud-uitrol controleren en bij fouten stoppen

Open na installatie of de start van een pilotkloon onder My Products > Server > Servers elke verwachte server afzonderlijk. Voor twee gelijktijdig draaiende klonen moeten twee te onderscheiden serverobjecten zichtbaar zijn. Leg bij de acceptatie een externe koppeling vast tussen AWS-account/Azure-subscription, regio, EC2-instantie-ID/Azure-VM-resource-ID, Fusion-server-ID, eigenaar en aanmaaktijdstip; cloud-ID’s verschijnen niet automatisch in de serverlijst. Controleer in de details Summary, Status en Policies, evenals de laatste activiteit, de status, geïnstalleerde onderdelen en toegepaste serverbeleidsregels. De aanvankelijk automatisch toegewezen Default Policy is niet noodzakelijk het beoogde productiebeleid. Vergelijk vervolgens de dienst, applicatietoegang, back-ups en een representatieve workloadtest vóór en na een eventuele herstart.

Ontbreekt een VM in Fusion, controleer dan eerst de tenant en filters, daarna DNS, proxy, uitgaand netwerkpad en installatielogboeken volgens de toepasselijke Windows-handleiding of het Linux-runbook. Zijn klonen niet te onderscheiden, stop dan de image-uitrol en controleer de identiteitsstap van de golden-image-procedure. Geef bij verkeerde onderdelen, slechte agentstatus of een verstoorde workload geen volgende uitrolfase vrij; onderzoek de betrokken fase afzonderlijk in plaats van installatieprogramma en beleidsregels herhaaldelijk blind toe te passen.

Beëindigde instanties en inactieve apparaten afzonderlijk behandelen

Kortlevende VM’s kunnen beëindigd zijn terwijl hun vermelding in Sophos Fusion nog zichtbaar is. Een oud Last Active-tijdstip bewijst niet dat een cloudinstantie is beëindigd en is evenmin een universele automatische opschoningstermijn. Vergelijk de externe koppeling van account/subscription, regio, cloudinstantie-/resource-ID en Fusion-server-ID regelmatig met de AWS-/Azure-inventaris en de Fusion-apparaatinventaris; leg eigenaar, levenscyclusmomenten en bewijs van de EC2-Terminate- of Azure-VM-Delete-gebeurtenis vast. Een hergebruikte hostnaam of een gestopte Azure-VM bewijst niet dat het bijbehorende serverobject buiten gebruik is gesteld.

Handmatige vergelijking en gericht Delete blijven de basis: bewaar pas na positief bewijs van beëindiging in de cloud en eenduidige ID-koppeling de benodigde alerts en onderzoeksgegevens, controleer mogelijke duplicaten en documenteer de buitengebruikstelling of vervangende bescherming. Delete in Fusion vervangt noch de deïnstallatie op een nog draaiende VM, noch het cloudlevenscyclusproces.

Afzonderlijk beschrijft Sophos bij Removal of inactive devices een configureerbare Server-regel voor inactieve apparaten: gericht op groepen of globaal met groepsuitzonderingen (uitzonderingen gelden niet voor gerichte regels). Deze reageert op inactiviteit, niet op een bevestigde EC2-Terminate- of Azure-Delete-gebeurtenis en verwijdert geen agent. Test vóór activering in de eigen tenant de groepen, termijn, uitzonderingen, gegevensbewaring en gevolgen voor gestopte of tijdelijk onbereikbare productie-VM’s met een testgroep; ga niet uit van een algemene termijn of licentie-effect. De vroegere Cloud Optix-integratie bood voor bestaande AWS-/Azure-omgevingen met serveragents die in dezelfde tenant waren gekoppeld een afzonderlijke opschoning bij beëindiging. Die was standaard uitgeschakeld, kon alleen door een Super Admin worden ingeschakeld en werkte niet met terugwerkende kracht voor eerder beëindigde instanties. Omdat ondersteuning en toegang op 30 september 2026 eindigen, is dit uitsluitend historische context, geen aanbeveling voor een nieuwe inrichting of blijvende automatisering. Voor autoscaling-verwijderhooks, API-automatisering of licentietelling wordt geen onbevestigd proces beloofd.