Driftsätt Sophos Server Protection på AWS EC2 och virtuella Azure-datorer

En EC2-instans eller virtuell Azure-dator skyddas i gästoperativsystemet med Sophos Server Protection. För Windows Server används Windows Server Installer och för Linux-servrar som stöds används Sophos Protection for Linux (SPL). Var den virtuella datorn körs ändrar inte valet av serveragent. Sophos Firewall som virtuell appliance i AWS eller Azure skyddar och dirigerar nätverkstrafik; den ersätter inte en agent i gästen. Sophos Cloud Optix är en separat produkt för molnsäkerhetskonfiguration och inventering, inte ett krav för serverinstallationen: enligt Sophos meddelande om produktens livscykel upphör support och åtkomst den 30 september 2026. Produkten är därför ingen grund för en ny eller långsiktig process för molninventering och rensning. Kontrollera separat om Server Protection och dess funktioner är tillgängliga och omfattas av avtalet för den egna klientorganisationen.

Snabbväg: Välj en representativ virtuell dator, godkänn operativsystem och skyddsläge, testa anslutningen till Sophos Fusion från dess faktiska molnnätverk och installera det klientorganisationsbundna serverinstallationsprogrammet. Kontrollera sedan My Products > Server > Servers och serverinformationen. Släpp inte fram nästa våg förrän registrering, grupp, policyer, agenthälsa och applikation fungerar. För kortlivade instanser krävs dessutom en separat plan för avstämning mot molninventariet.

Före piloten: klargör skydd och nätverksväg

1. Virtuell dator och avtal: Dokumentera AWS-konto respektive Azure-prenumeration, region, datorns roll, operativsystemsversion eller Linux-distribution, arkitektur och livscykel. Kontrollera aktuellt stöd för just detta gästoperativsystem och de komponenter som behövs. Bekräfta licensen för den aktuella klientorganisationen, den beställda server-SKU:n och avtalsvillkoren för dessa virtuella datorer; en synlig nedladdningsknapp bevisar inte att licensrätt finns.
2. Skyddsläge: Välj fullständigt skydd mot skadlig kod från Sophos eller XDR Sensor. Enbart XDR Sensor ger inget skydd mot skadlig kod och kräver ett aktivt skydd från tredje part. Red ut konflikter med befintlig säkerhetsprogramvara och en återgångsplan för den berörda virtuella datorn innan du byter läge.
3. Utgående anslutning: Kontrollera från det avsedda undernätet att DNS, HTTPS, de Sophos-destinationer som klientorganisationen behöver och i förekommande fall proxy eller Message Relay kan nås under både installation och drift. Security Groups, Network Security Groups, molnrutter, NAT, brandväggar och TLS-inspektion kan påverka vägen. Aktuell lista över tillåtna destinationer och proxydiagnostik finns under nätverks- och proxykrav. Utgå inte från att en fast lista med moln-IP-adresser kan ersätta Sophos-destinationerna.
4. Pilot och godkännande: Välj en liten grupp virtuella datorer med representativ serverroll, OS-version, nätverkssegment och eventuell proxyväg. Dokumentera namn, förväntad servergrupp, målpolicyer, omstartsfönster, arbetsbelastningstest och kriterier för att stoppa utrullningen. Finns det flera undernät eller images bör minst ett relevant test planeras för varje avvikande väg.

Exempel: En virtuell Windows-applikationsdator och en virtuell Linux-arbetardator i olika privata undernät är två pilotfall, inte ett gemensamt nätverkstest. En lyckad installation på den första datorn visar inte att den andra når sin uppdateringsdestination via sin NAT- eller proxyväg.

Kör installationsprogrammet i gästen och hantera images rätt

Välj Windows Server Installer respektive Linux Server Installer för det godkända skyddsläget från rätt Sophos Fusion-klientorganisation under My Environment > Installers > Server Protection. Överför SophosSetup.exe säkert till en enskild virtuell Windows-dator, kör det med lokala administratörsbehörigheter, beakta förkontrollerna som visas och slutför installationen inklusive eventuell begärd omstart. Överför SophosSetup.sh säkert till en virtuell Linux-dator, gör filen körbar och kör först sudo ./SophosSetup.sh --test, sedan sudo ./SophosSetup.sh om testet lyckas. Kontrollera därefter registreringen i klientorganisationen och agentens lokala hälsostatus; att installationsprogrammet har avslutats räcker inte. Skyddsläge, avancerade CLI-alternativ, loggar och felsökning beskrivs i Installera och driftsätt Windows Server Protection och Installera och driftsätt SPL. Förvara det klientorganisationsbundna installationsprogrammet och dess nedladdningsadress endast i ett skyddat paketförråd, inte i ett offentligt VM-image eller kodförråd.

Klona inte en redan registrerad master-VM utan förberedelser. För SPL i ett Linux-gold image måste master-VM:en efter installationen avregistreras med registerCentral --deregister enligt proceduren för Linux-gold images, stängas av omedelbart och sparas som image i avstängt tillstånd. Om master-VM:en startas igen kan den registreras på nytt; avregistrera den i så fall igen innan imagen sparas. Starta två kloner och kontrollera att de har skilda identiteter.

Windows Server har en annan image-process: Kontrollera före skapandet om Tamper Protection är avaktiverat för image-konfigurationen och om Server Lockdown eller Update Cache är aktiva; skapa inget gold image från servrar där de sistnämnda funktionerna är aktiva. Masterdatorer som är krypterade med BitLocker eller har Sophos Encryption-komponenter är också uteslutna. Kör SophosSetup.exe --goldimage med det klientorganisationsbundna Windows Server-installationsprogrammet som administratör enligt proceduren för Windows-gold images (även för servrar), kontrollera installation och hälsostatus, aktivera Tamper Protection igen och stäng av masterdatorn före image-ögonblicksbilden. Vid första starten måste varje klon få ett slutgiltigt datornamn som skiljer sig från masterdatorns, i god tid innan Sophos identifierar den: Sophos identifierar kloner via namnändringen, inte via molninstansens ID. Om namntilldelningen dröjer, kontrollera timeout-läget som beskrivs i guiden; Notification Mode beskrivs där för VMware Horizon Instant Clone och ska inte utan vidare användas för EC2/Azure. Utgå inte från att en vanlig Windows-installation är redo att klonas. Godkänn även här två kloner var för sig i Fusion.

Kontrollera molnutrullningen och stoppa vid fel

Efter installationen eller starten av en pilotklon öppnar du de förväntade servrarna var för sig under My Products > Server > Servers. För två kloner som körs samtidigt måste två åtskiljbara serverobjekt synas. Dokumentera vid godkännandet en extern koppling mellan AWS-konto/Azure-prenumeration, region, EC2-instans-ID/Azure-VM-resurs-ID, Fusion-server-ID, ansvarig och skapandetidpunkt; serverlistan visar inte automatiskt moln-ID:n. Kontrollera Summary, Status och Policies i detaljerna, liksom senaste aktivitet, hälsostatus, installerade komponenter och tillämpade serverpolicyer. Den första automatiska Default Policy är inte nödvändigtvis den planerade produktionspolicyn. Jämför därefter tjänst, applikationsåtkomst, säkerhetskopiering och ett representativt arbetsbelastningstest före och efter en eventuell nödvändig omstart.

Om en virtuell dator saknas i Fusion, kontrollera först klientorganisation och filter, därefter DNS, proxy, utgående nätverksväg och installationsloggar enligt relevant Windows- eller Linux-runbook. Om klonerna inte kan skiljas åt, stoppa image-utrullningen och kontrollera identitetssteget i gold image-proceduren. Släpp inte fram fler vågor om komponenterna är felaktiga, hälsostatusen är dålig eller arbetsbelastningen störs; undersök den berörda vågen separat i stället för att upprepade gånger tillämpa installationsprogram och policyer på måfå.

Hantera avslutade instanser och inaktiva enheter separat

Kortlivade virtuella datorer kan ha avslutats medan deras poster fortfarande syns i Sophos Fusion. En gammal Last Active-tidpunkt bevisar varken att en molninstans har avslutats eller att det finns en generell automatisk rensningsfrist. Stäm regelbundet av den externa kopplingen mellan konto/prenumeration, region, molninstans-/resurs-ID och Fusion-server-ID mot beståndet i AWS/Azure och enhetsinventariet i Fusion; dokumentera ansvarig, livscykeltidpunkter och belägg för händelsen EC2-Terminate respektive Azure-VM-Delete. Ett återanvänt värdnamn eller en stoppad virtuell Azure-dator är inget bevis för att det kopplade serverobjektet har avvecklats.

Manuell avstämning och riktad Delete är fortfarande grunden: Först efter bekräftad molnavslutning och entydig ID-koppling ska nödvändiga varningar och utredningsdata sparas, eventuella dubbletter kontrolleras och avvecklingen eller ersättningsskyddet dokumenteras. Delete i Fusion ersätter varken avinstallation på en virtuell dator som fortfarande körs eller molnets livscykelprocess.

Sophos dokumenterar separat under Removal of inactive devices en konfigurerbar Server-regel för inaktiva enheter: den kan riktas mot grupper eller gälla globalt med gruppundantag (undantagen gäller inte riktade regler). Regeln reagerar på inaktivitet, inte på en bekräftad EC2-Terminate- eller Azure-Delete-händelse, och avinstallerar ingen agent. Innan regeln aktiveras i den egna klientorganisationen bör grupper, tidsfrist, undantag, datalagring och följderna för stoppade eller tillfälligt oåtkomliga virtuella produktionsdatorer testas mot en testgrupp; anta varken en generell tidsfrist eller en viss licenspåverkan. Den tidigare Cloud Optix-integrationen erbjöd för befintliga AWS-/Azure-miljöer med serveragenter, kopplade till samma klientorganisation, en separat rensning vid avslutning. Den var avaktiverad som standard, kunde bara aktiveras av en Super Admin och gällde inte retroaktivt för instanser som redan avslutats. Eftersom support och åtkomst upphör den 30 september 2026 är detta endast historisk bakgrund, ingen rekommendation för ny konfiguration eller långsiktig automatisering. Här utlovas inget obekräftat förfarande för raderingshooks vid autoskalning, API-automatisering eller licensräkning.