Konfigurera MDR- och XDR-integreringar i Sophos Fusion

Med integreringar kan Sophos Fusion (tidigare Sophos Central) samla telemetri från Sophos-produkter och produkter från tredje part i Sophos Data Lake, eller erbjuda riktade Response Actions. Det är viktigt att välja rätt integreringstyp: Data Ingest levererar data för frågor, Detections och undersökningar, medan Response Action utför en åtgärd i den anslutna produkten. Alla produkter stöder inte båda riktningarna.

Ingången beror på produktläget i tenanten. För den utökade XDR-/MDR-lösningen gäller Security Operations > Integrations > Marketplace; befintliga Classic-konfigurationer finns under Threat Analysis Center > Integrations. TAC-anvisningarna som behålls nedan beskriver Classic-vägen och är inte samma klickföljd som i det nya gränssnittet. Den tenantspecifika uppgraderingskontrollen hjälper dig att välja rätt väg. Enbart synliga Fusion-namn bevisar inte att produktuppgraderingen är slutförd.

I onboarding-spåret för Endpoint täcker artikeln den produktövergripande integreringsfasen mellan skyddskonfiguration och driftgodkännande.

Ett praktiskt arbetsflöde är att först kontrollera licensen och källsystemet, välja rätt produktruta och konfiguration i Marketplace, skapa anslutningen med minsta möjliga behörigheter, kontrollera den under Configured och verifiera den med en förväntad testhändelse. Betrakta inte integreringen som produktionsklar förrän detta är gjort.

Kontrollera anslutning och faktiskt dataflöde separat

Öppna Security Operations > Integrations > Configured Integrations i den aktuella vyn. Under Data Ingest visar statusen konfiguration och anslutning för API-, syslog- eller Sophos-integrationen. Grönt bekräftar kommunikation, inte redan korrekt normaliserade händelser. En varning kan visas efter 20 minuter utan kommunikation eller när vissa resurser inte rapporterar; ett fel efter 60 minuter eller misslyckad autentisering. Hovringstexten anger den konkreta orsaken.

För en API-integration öppnas namnet och API Query Logs. Standard är senaste dygnet; upp till sju dagar kan väljas. Jämför parametrarna med rätt källtenant under Details. Hierarkiska integrationer kan ha en parent med flera child-endpoints; en frisk delväg bevisar inte att alla children fungerar.

Kontrollera sedan Security Operations > Integrations > Configured Data Sources. Den separata vyn visar om loggar faktiskt kommer in och vilka scheman de mappas till. Healthy innebär aktivitet inom en timme, Warning mellan en och 24 timmar och Unhealthy över 24 timmar utan aktivitet. Detta är andra kriterier än anslutningsgränserna ovan. Bedöm en sällan sändande källa mot förväntad aktivitet, inte genom att förklara den frisk med en påhittad testhändelse.

Ett klick på källan visar meddelandehistorik per schema för senaste dygnet. Generera en godkänd händelse i källsystemet för acceptans och jämför tid, källa, obligatoriska fält och normaliserat schema. Advanced Search i detaljerna öppnar en förberedd sökning på sensor-ID för senaste dygnet. Sökguiden förklarar ytterligare avgränsning. Om data saknas kontrolleras först källa → integration/collector → schema; en vanlig revisionshändelse behöver inte ge en detection.

Export All as CSV eller Export Selected as CSV sparar källinventeringen via Data Exports. Papperskorgen tar däremot endast bort källposten, inte redan mottagen telemetri. Borttagningen kan inte ångras; en fortsatt sändande källa återkommer och borttagning kan ta upp till fem minuter. Radering är därför varken bekräftelse på telemetriradering eller ett reparationstest.

Synlighet, behörighet och aktuell API-tillåtelselista

Beroende på produkt visar Marketplace separata Ingest- och Actions-kort. EDR utan XDR visar inga ingestkort för annat än endpoints; response actions kan fortfarande vara synliga. Admin och Super Admin kan hantera integrationer. Help Desk och Read-only ser bara konfiguration och status. För Custom Roles ges Integration: read och endast nödvändiga create, update, delete och download. Kontrollera licens och roll innan rättigheter utökas för en saknad funktion.

Skilj den aktuella XDR-listan från Classic-IP-ögonblicksbilden som behålls nedan och collector-uplinken. Bestäm faktisk geografisk XDR-region under Profile icon > Support settings, inte utifrån ett produktnamn. Tillverkarlistan från 25 september 2026 anger dessa nät för administrativa/API-anrop till tredje part:

Tillåt endast rätt intervall för den faktiska integrationen efter godkänd ändring. Listan bevisar inte att alla produkter är tillgängliga i alla regioner och ersätter inte kontroll av nu nödvändiga API-mål. Collectorns utgående mTLS-väg använder andra mål.

Rikta Health-meddelanden noggrant

Reglerna nedan för 24 timmars sammanhängande fel, återställning av nedräkning och upprepning var 30:e dag gäller också aktuell Fusion-hjälp från 20 oktober 2026. E-postmeddelandet är inget omedelbart larm efter de 20 eller 60 minuter som nämns ovan.

Öppna en egen mottagarregel under General Settings > Platform > Notification Settings > Configure email alerts > Custom rules > + Create new rule. Efter roll, administratörer/distributionslistor och enhetsomfång väljs under Alert Types filtren Medium alert, produkten Sophos Central och kategorin Central Integrations Alert. Ange sedan namn/beskrivning och spara. Planera annan larmdistribution innan sparande: den första egna regeln stänger av standardutskick av alla e-postlarm till alla administratörer. Behåll övriga nödvändiga mottagare med fler lämpliga regler; orsaka inte ett testavbrott på en produktionsconnector bara för att tvinga fram ett mejl.

Nästa steg per källa

För egna källor förklarar HTTP Ingest, S3 och Azure skilda transportvägar. Collectordrift och molndistribution kompletterar migrationsrunbooken. Cloud Flow Logs, nätverkstelemetri och Windows Event Logs behandlar källformat och schemarelaterade licensgränser. All telemetri från en leverantör är inte automatiskt SIEM-exklusiv.

Efter uppgraderingen: återställ Response Actions till fungerande drift

Kontrolläge 11 oktober 2026: den utökade lösningen använder en annan modell för körning och behörigheter för Actions. Befintliga TAC-anslutningar och deras autentiseringsuppgifter överförs inte bara till denna modell. Dokumentera berörda Microsoft-tenants, anslutningar, aktiverade åtgärder och ansvariga före en ändring. Att en separat Audit- eller Graph-anslutning hämtar data är inget test av Response Actions.

Anslut Microsoft 365 på nytt eller auktorisera autentiseringsuppgifterna igen

För dessa steg krävs Admin eller Super Admin i Sophos Fusion och en Microsoft 365 administrator på Microsoft-sidan. Kontrollera de rättigheter som faktiskt begärs och rätt Microsoft-tenant i varje samtyckesdialog; återanvänd inte en gammal TAC-apps behörighetsuppsättning utan granskning.

Om den tidigare TAC-anslutningen ännu inte har konfigurerats i det nya gränssnittet skapas den så här:

1. Öppna Security Operations > Integrations > Marketplace och Actions-rutan Microsoft Graph API.
2. Välj Add new connection. Välj sedan Add new connection igen i Add a Connection, ange Name samt vid behov Description och Tags, och fortsätt med Done.
3. Starta Microsofts guidade auktorisering med Proceed. Ett namn som M365-Response-Produktion är bara en fritt vald beteckning; rätt källtenant och godkända rättigheter är det avgörande.
4. Välj det avsedda administratörskontot i Pick an account. Den första dialogen Permissions requested auktoriserar Sophos huvudapplikation. Efter återkomsten till Sophos följer ett andra Microsoft-steg för själva Response-anslutningen. Slutför båda dialogerna med Accept efter att ha granskat rättigheterna. Om någon avbryts skapas ingen anslutning.
5. Granska de erbjudna åtgärderna efter återkomsten och spara endast godkänd omfattning med Save. Den nya anslutningen ska visas i Configured Integrations.
6. Kontrollera i Microsoft Entra under Manage > All applications, med Refresh, att den nya Response-applikationen visas som aktiverad.

Om en anslutning redan finns under Microsoft Graph API > Configured Integrations, öppna trepunktsmenyn vid anslutningsnamnet och välj Edit Connection. Välj Re-Authorize Credentials och genomför Microsoft-auktoriseringen. Knappen visas bara när ny auktorisering behövs och försvinner när den är klar. Upprepa för varje berörd anslutning; att reparera en enda anslutning räcker inte för alla tenants eller konfigurationer.

Den uppdaterade anvisningen från 7 oktober 2026 skiljer uttryckligen mellan skydd som fortsätter fungera och Microsoft-svarsåtgärder som kan misslyckas fram till den nya auktoriseringen. Den anger 1 oktober 2027 som sista giltighetsdag för de tidigare autentiseringsuppgifterna. Vänta inte till dess om Actions behövs: funktionen måste verifieras nu.

Godkännandet omfattar rätt Entra-applikation, förväntade anslutningar och aktiverade åtgärder samt ett godkänt test med ett särskilt testkonto. Använd endast en reversibel ändring som är dokumenterad för den aktuella åtgärden. Classic-paret Block user sign-in / Allow user sign-in som beskrivs nedan bevisar inte att varje ny Action har samma namn eller samma återställningsväg. Återkallade sessioner kan inte återställas. I åtgärdsdetaljerna visar View Executions > History körningshistoriken; kontrollera även det faktiska tillståndet i Microsoft. Ett samtycke eller en lyckad körningspost ersätter inte denna motkontroll.

Lägg till Sophos Firewall (Actions) endast om anslutningen saknas

Öppna först ett Case efter produktuppgraderingen och kontrollera om Sophos Firewall-åtgärder är tillgängliga. Om de finns behövs ingen ny anslutning. Om de saknas:

1. Öppna Security Operations > Integrations > Marketplace.
2. Sök efter och öppna Sophos Firewall (Actions).
3. Välj Add new connection och spara med Save.

Denna anslutning kräver inga autentiseringsuppgifter. Därefter finns svarsåtgärder för brandväggen tillgängliga från Cases, exempelvis blockering av skadliga IP-adresser, domäner eller URL:er. MDR-analytiker kan utföra sådana åtgärder inom den godkända Response-inställningen; XDR-användare kan starta dem själva från ett Case. Kontrollera tillgängligheten utan att blockera produktionsmål. Ett test av effekten är en separat, godkänd ändring med en produktspecifik återställningsväg som har klargjorts i förväg.

Inaktivera nya Actions riktat i stället för att radera anslutningar blint

För Actions i den utökade lösningen finns ett dokumenterat reglage: öppna berörd Action under Security Operations > Integrations > Marketplace, Configured > Actions, och inaktivera den i Enable/disable integration. Detta är inte ett universellt reglage för alla Data Ingest-anslutningar. En inaktivering återställer inte ändringar som redan har utförts i källsystemet.

Delete Integration tar bort tillhörande anslutningar och villkor och återställer Action-konfigurationen till utgångsläget. När den enda anslutningen tas bort raderas även dess tillhörande villkor. Säkerhetskopiera eller dokumentera därför anslutningar och villkor först. För att återställa teståtgärder gäller fortfarande den konkreta återställningsvägen i Microsoft eller brandväggen, inte borttagning av anslutningen.

XDR-automatiseringar: skilj Classic REST från GraphQL

API-läget är ett tillägg från 9 oktober 2026, inte ett retroaktivt löfte för septemberlanseringen. Nya XDR-integreringar och skrivande XDR-arbetsflöden på Fusion ska använda de nya GraphQL APIs. Detta måste skiljas från en Marketplace-API-anslutning: dess REST-anrop kan fortfarande gå till tredjepartsleverantören.

De tidigare Cases REST API och Detections REST API heter nu Classic XDR APIs och är utfasningsmarkerade. Detections REST API är redan read-only. Cases REST API är fortfarande tillgängligt för befintliga integreringar; även det ska senare bli read-only. Därefter ska båda API:erna tillhandahålla historiska data fram till borttagningen. Detta läge anger inget konkret avstängningsdatum. Radera därför inte befintliga integreringar generellt och ändra inte deras värdar på grund av namnet Fusion.

Anteckna API, läsande och skrivande operationer, dataperiod, tenant, rättigheter och felhantering för varje automatisering. Kontrollera separat om befintliga klienter förväntar sig aktuella eller historiska data och om ett skrivande arbetsflöde fortfarande försöker använda Classic Detections. För övergången till GraphQL måste fältmappning, paginering, autentisering, behörigheter och felhantering implementeras mot det konkreta nya schemat och jämföras i ett isolerat test. Artikeln anger medvetet inga påhittade endpoints, mutationsnamn eller payloads. Inventeringen är klar när varje klient har en ansvarig och ett spårbart beslut om fortsatt drift eller migrering; det är ännu inte ett lyckat API-migreringstest.

Vilket GraphQL API hör till klienten?

Publiceringen den 18 september 2026 omfattade fem GraphQL-API:er med olika uppgifter:

• Detections v2: Sök efter och bearbeta Detections från endpoints, nätverkssensorer och andra källor.
• Cases v2: Hantera Cases samt Evidence, kommentarer, filer och länkar.
• Threat Timeline v2: Sök efter processamband för upp till 100 processer i ett anrop.
• Events v1: Hämta händelsedetaljer utifrån kända Event-ID:n.
• Live Endpoint Search v1 (LES): Kör osquery-liknande frågor på anslutna endpoints och hämta resultat samt Telemetry.

Live Discover REST omfattas inte av utfasningen av Classic Cases/Detections APIs. Befintliga Live Discover REST-integreringar kan fortsätta fungera; byte till LES är valfritt. Livevägen och XDR Query API för historiska data har olika uppgifter. Avgränsningen av Live Discover-API:erna förklarar även det sessionsbaserade målurvalet i LES. Inte heller Endpoint API under /endpoint/v1 eller dess Device Migration övergår till GraphQL på grund av denna XDR-utfasning.

Sedan 12 oktober 2026 är även Search GraphQL API v1 publicerat för historiska QL-sökningar. Det erbjuder createSearch, getOrCreateSearch, search och searchResults; Sök i Sophos Fusion Data Lake med Search GraphQL API beskriver begärandekontrakt, körningsstatus, resultatsidor och kontroll av SQL-migrering. Data Lake Search förblir den interaktiva sökvägen; XDR Query API är fortsatt tillgängligt. Det nya API:et kräver inget omedelbart byte och är inget LES-arbetsflöde för live-endpoints. För Assets och Entity Graph återstår separata referens- och tenantkontroller: omnämnandet i Cases-guiden är inget fullständigt implementeringsgodkännande.

Kontrollera det konkreta migreringskontraktet

Bytet innebär inte att bara ersätta URL:en med klienten oförändrad. För Cases, Detections och valfritt LES jämförs respektive eget arbetsflöde, inte ett gemensamt recept för REST till GraphQL:

• GraphQL returnerar endast valda fält. Klienten kontrollerar både HTTP-status, arrayen errors och operationsspecifika statusfält; HTTP 200 kan innehålla ett frågefel. Nödvändiga nästlade fält och tidsuppgifter med seconds/nanos väljs och bearbetas medvetet.
• För Detections ersätter detectionSearch REST-flödet med frågestart, statusförfrågan och resultathämtning. Små sökmängder använder offset/limit, stora sökmängder det returnerade search_id med detectionPoll. Stäm av alla delar och det totala antalet. Filter kontrolleras individuellt som QL-predikat; en Host Lookup förväntar sig ett ID, inte bara enhetsnamnet. Ett REST-type eller en Intelix Reputation har ingen garanterat identisk ersättning.
• Detection Severity i REST och GraphQL bedömer separata datamängder enligt separata modeller. REST använder en heltalsskala upp till 10, GraphQL metadata.severity en skala från 0 till 1. Räkna inte om genom division. Gör en ny saklig bedömning av tröskelvärdena utifrån respektive data. Case.severity med 2/4/6/8/10 är ytterligare en annan skala.
• För Cases använder API-klienten UUID:t id, inte det läsbara shortId i formatet CSE#####. Gamla REST-Case-ID:n översätts inte och gamla Cases blir inte tillgängliga via det nya API:et. Nödvändiga underlag för gamla ärenden sparas före bytet med den bekräftade tidigare hämtningsmetoden; detta innebär varken en universell exportknapp eller att historiken överförs.
• Case-typer, status och Verdicts slås upp som dynamiska, licensberoende referensdata för tenanten och uppdateras regelbundet. assigneeId förväntar sig en Subject ID eller en @mention som stöds, inte en e-postadress. Ett assigneeSubject som inte kan slås upp kan vara null; visningen behöver därför ett medvetet valt ersättningsvärde.
• caseEvidence returnerar länknings-ID:n, inte färdiga Evidence-payloads. Detections hämtas i efterhand via detectionRetrieveById med argumentet exakt skrivet som iDs, Events via sina oförändrade Resource Names. Beroenden till Assets och Entity Graph förblir öppna tills motsvarande referens och tenant har kontrollerats. Detection-, Event-, Asset- och Entity Graph-ID:n är inte utbytbara; en ingång till Entity Graph för ett Case använder dess UUID som INVESTIGATION, inte shortId.
• Case-paginering använder Offset eller Cursor, inte båda i samma förfrågan. Föredra Cursor för en lista som förändras och skicka tillbaka den oförändrad. keyFindings är ett typat dokument och returneras vid enskild hämtning, inte i Case-listan. De tidigare filtren overviewContains och escalated har ingen direkt ersättning; fatta uttryckliga beslut om nödvändiga funktioner före bytet.
• Det finns inget deleteCase som ersättning för REST-DELETE. Stängning, vid behov med det Verdict som Case-typen kräver, och efterföljande valfri arkivering är separata steg. För leverantörshanterade MDR-Cases är de faktiskt tillåtna skrivfälten mer begränsade och måste kontrolleras i förväg.

En pilot måste besvara samma sakfråga i rätt tenant med spårbara ID:n, fullständig paginering och utvärderade fel. Ytterligare GraphQL-funktioner som kommentarer, filer, länkar, regler, Templates samt Split/Merge är separata utökningar, inte en förutsättning för varje byte. Saknade fältmotsvarigheter eller oklar historik förblir en öppen beslutspunkt för klienten; de förbigås inte genom att likvärdighet antas.

Omfattning: XDR, MDR och licenser

En integrering ersätter varken en XDR- eller MDR-licens. XDR tillhandahåller analysfunktioner som det egna säkerhetsteamet kan använda för att undersöka data i Threat Analysis Center och Data Lake. MDR kompletterar detta med Sophos hanterade tjänst. Vilka integreringar som kan väljas i tenanten beror på Sophos-avtal, produkt, integreringstyp och eventuellt licensen för produkten från tredje part.

För längre datalagring eller egna datakällor förklarar Sophos Next-Gen SIEM hur det valfria tillägget bedöms och hur lagringsbehoven inventeras per källa.

Påståendet att vissa integreringar är kostnadsfria betyder inte att hela Marketplace är gratis. För MSP Flex finns separata Integration License Packs för kategorier som Endpoint, Network, Email och Firewall. Den tidigare MSP Flex-regeln angav att Sophos NDR, Sophos Cloud Optix, Microsoft Graph Security och Microsoft 365 audit appliance med en XDR-licens inte behövde något extra Integration License Pack. Regeln gäller uttryckligen endast MSP Flex-kunder. Cloud Optix är numera bara en historisk post i listan: dess End of Life den 30 september 2026 medger ingen ny produktionsplanering med tjänsten. Kontrollera därför vad som är aktiverat i den egna tenanten och avtalet i stället för att anta en generell kostnadsfri omfattning.

Även motparten kan kräva licenser. Sophos Microsoft 365-sidor är motsägelsefulla: översikten anger att Management Activity-auditloggar är tillgängliga för alla Microsoft 365-kunder, medan den konkreta konfigurationssidan kräver Purview Audit (Standard eller Premium), en användarlicens från den angivna listan och aktiverad Auditing. Använd de konkreta förutsättningarna vid konfigurationen. Detections från Graph Security V2 beror dessutom på Microsoft-licensens omfattning och tillgängliga Defender XDR-funktioner. För Microsoft 365 Response Actions via Classic/TAC anger Sophos inget Microsoft-licenskrav, men en Microsoft 365-administratör och de Graph-behörigheter som uttryckligen anges som Classic nedan krävs. För Actions i den utökade lösningen gäller i stället förutsättningarna ovan och de rättigheter som faktiskt begärs vid auktoriseringens två steg; Classic-listan definierar inte det nya samtycket.

Cloud Optix efter End of Life: behandla telemetri och CSPM separat

Sophos Cloud Optix nådde End of Life den 30 september 2026. Därefter samlar tjänsten inga nya data, skapar inga fynd och vidarebefordrar ingen telemetri till MDR eller XDR. Vid kontrolläget 11 oktober 2026 är den tidigare rekommendationen att exportera och växla parallellt före EOL inte längre ett genomförbart framtida steg.

Kontrollera nu vilka AWS-, Azure-, GCP- eller OCI-miljöer som tidigare var anslutna enbart via Cloud Optix och vilka som redan har en direkt anslutning till den utökade XDR-/MDR-lösningen. Dessa direkta molnintegreringar måste konfigureras per plattform; produktuppgraderingen gör inte detta automatiskt. Utan en verifierad ny anslutning får obruten telemetritäckning för tiden efter den 30 september inte hävdas. Klargör läget med Sophos kundansvariga eller partnerteamet om en tenant ännu inte är uppgraderad eller en produktruta saknas.

En direkt moln-API-integrering är inte samma sak som en Syslog Data Collector i AWS, Azure eller GCP. Välj integreringen för det molndataflöde som behövs i Marketplace, kontrollera de konkreta källbehörigheterna och verifiera därefter data samt förväntade Detections. Underlaget måste identifiera molnkonto, datakälla och tidsfönster; en grön anslutning räcker inte.

Cloud Security Posture Management (CSPM) följer inte med: bedömning av molnkonfigurationer, rapporter mot efterlevnadsriktmärken och fynd om konfigurationsavvikelser ingår inte i något funktionslöfte för de nya telemetriintegreringarna. Dokumentera detta behov separat och klargör ersättningslösning och kvarvarande avtalsrättigheter med kundteamet. Inte heller Cloud Optix-rapporter, fyndhistorik, efterlevnadsunderlag eller inventariedata migreras till det nya systemet. Säkra befintliga exporter och kontrollera att de är fullständiga; någon möjlighet till export i efterhand eller återställning är inte bekräftad här.

Integreringstyper och nödvändiga autentiseringsuppgifter

REST API

En API-integrering hämtar data från tillverkarens molntjänst eller skickar en Response Action dit. Beroende på produkt frågar konfigurationsguiden efter exempelvis tenant- eller organisations-ID, API-URL, Client ID, Client Secret, token eller certifikat. API-integreringar kräver ingen Sophos-appliance.

Vissa integreringar tar emot autentiseringsuppgifterna direkt i guiden. Andra begär en återanvändbar Integration Credential. Alternativet att välja en befintlig eller skapa en ny uppgift i konfigurationsguiden visar om anslutningen stöder funktionen. Integration Credential Manager är bara tillgänglig för ett begränsat antal API-integreringar; alla hemligheter kan därför inte återanvändas centralt.

Log collector

Beskrivningen av appliance nedan gäller Classic-SVA-vägen. I den utökade XDR-lösningen samlar XDR Data Collectors in Syslog-data; de har egna resurs- och nätverkskrav. De gamla SVA-minimikraven får inte överföras till den nya virtuella datorn. Migreringen provisionerar konfigurationer men startar ingen driftklar ersättare. SVA-Syslog-övergång och drift av XDR Data Collector förklarar adressalternativen, undantagna inställningar och säker övergång. NDR migreras inte automatiskt i detta steg.

I en Log Collector-integrering exporterar källsystemet händelser via Syslog till en Sophos appliance. Log Collector bearbetar data och laddar upp dem till Sophos Data Lake. Appliance körs på ESXi, Hyper-V, AWS eller Nutanix, eller på lämplig Dell-, NUC- eller OnLogic-maskinvara. Tilldela minst 4 CPU:er, 16 GB RAM och 160 GB lagring för ESXi eller Hyper-V; ESXi 6.7 Update 3 med VM-maskinvaruversion 11 eller senare samt Hyper-V på Windows Server 2016 eller senare stöds. Sophos hanterar operativsystems- och säkerhetsuppdateringar; installera ingen annan Sophos- eller antimalwareagent. Skala upp för stora datamängder eller flera integreringar och validera DNS, proxy samt nödvändiga port- och domänundantag före godkännande. Konfigurera tredjepartsprodukten att skicka till denna appliance, inte till en godtycklig Syslog-server.

Flera integreringar kan använda samma appliance. Protokoll, port, format och källa måste ändå konfigureras för varje produkt enligt respektive integreringsguide. En grön appliance bevisar inte i sig att rätt typ av händelse kommer fram.

Sophos-produkter

Produkter som Sophos Firewall och Sophos NDR har produktspecifika konfigurationsvägar. Sophos NDR- och Log Collector-integreringar kräver en Integration Appliance, men inte nödvändigtvis en traditionell VM. En ren REST API-integrering kräver ingen appliance. Använd den berörda klientorganisationens Marketplace som tillgänglighetskontroll: varje produktpanel visar erbjudna metoder och öppnar rätt guide.

Avgränsa NDR-arbetslasten och en delad appliance säkert

Den delade appliance-topologin nedan gäller Classic SVA/TAC, inte den nya XDR Data Collector. Den senare ersätter Syslog-delen; NDR förblir en separat driven appliance-arbetslast och överförs inte till den nya collectorn.

Endast en Sophos NDR-integrering är tillåten per appliance. Samma appliance kan dessutom vara värd för flera appliance-baserade tredjepartsintegreringar som Log Collectors. Fäll därför ut posten för appliance under Configured > Integration Appliances före varje ändring och kontrollera alla tilldelade integreringar. Varken värdet Integrations eller grön appliance-status ersätter denna kontroll.

En riktad NDR-omstart avbryter NDR-sensorn medan Log Collectors fortsätter att köras. Restart eller Shutdown av hela den virtuella datorn avbryter däremot NDR och samtliga Log Collectors på denna appliance. Planera sådana åtgärder i ett underhållsfönster, dokumentera status för alla arbetslaster i förväg och kontrollera dem separat efteråt. Förloppet beskrivs i Hantera Sophos NDR Appliance och sensor säkert.

Delete i appliance-menyn tar inte bara bort en enskild integrering. Ta inte bort en appliance så länge NDR eller en Log Collector är tilldelad till den. Menyposten anger inte heller att den driftsatta virtuella datorn tas bort eller att data som redan har samlats in i Data Lake raderas. Före avveckling måste du klargöra tilldelningar, datalagring, nedmontering av plattformsresurser, återställningsväg och slutkontroll. Fram till dess ska appliance finnas kvar.

Före konfigurationen

1. Logga in i Sophos Fusion som Admin eller Super Admin. Sophos anger dessa roller som förutsättning för allmän konfiguration.
2. Kontrollera vilken licens, administratörsroll, API-funktion eller Syslog-export som krävs i tredjepartsprodukten.
3. Bestäm om du behöver Data Ingest, Response Action eller båda. En Response-integrering levererar inte automatiskt den telemetri som en undersökning bygger på.
4. Skapa om möjligt en särskild app eller ett särskilt tjänstekonto för API-åtkomst. Tilldela endast rättigheterna som produktguiden kräver och dokumentera ägare, utgångsdatum och rotationsväg för hemligheten.
5. Om tredjepartsprodukten kräver en allowlist med käll-IP-adresser för administrativa API-anrop ska du först identifiera Central-regionen under My Environment > Installers: håll pekaren över en nedladdningslänk under Endpoint Protection eller Server Protection och läs regionen i den visade URL:en, till exempel eu-central-1. Tillåt sedan endast adresserna för den regionen i tabellen nedan. De är källor för Sophos API-anrop, inte utgående destinationer för Integration Appliance.
6. Kontrollera integreringsappliancens egen utgående nätverksväg, DNS och vid behov proxy enligt kraven för denna appliance.
7. Planera en reproducerbar och ofarlig testhändelse. En inloggnings- eller audithändelse är bättre än ett verkligt försök med skadlig programvara.

Käll-IP-adresser för API-allowlisting

Den här tabellen visar Classic-IP-uppsättningen som kontrollerades den 14 september 2026. Den ska skiljas från den aktuella XDR-allowlisten ovan och är inte ensam tillräckligt underlag för en allowliständring i produktion.

Kontrollera före en ändring integrationsgenerationen, tenantregionen och hela den nödvändiga IP-uppsättningen mot Sophos aktuella information. Använd inga gamla värden vid avvikelser och kombinera inte regioner. Låt regionmappningen och ändringen kontrolleras enligt den egna godkännandeprocessen, tillåt endast nödvändig omfattning och validera därefter den berörda integreringen med en ofarlig API-synkronisering eller testhändelse. Dokumentera utgångsläge, godkännande, resultat och återställningsväg i ändringen.

Sophos märker för närvarande både raden São Paulo och raden Dubai som sa-east-1. Skilj dem åt med klientorganisationens plats och IP-uppsättningen; kombinera aldrig regioner. Dokumentera den godkända listan i ändringen.

Lägg till en integrering från Marketplace

1. Öppna Threat Analysis Center > Integrations > Marketplace.
2. Sök efter tillverkare eller produkt. Om liknande poster finns, öppna produktsidan och kontrollera kategori, produktnamn, integreringstyp och syfte. Cisco Meraki och Fortinet FortiAnalyzer erbjuds exempelvis både som API- och Log Collector-varianter.
3. Öppna önskad integrering.
4. Välj den typ som behövs, till exempel Data Ingest, och klicka på Add Configuration.
5. Följ stegen under Integration setup. För API-integreringar anger du uppgifterna från källsystemet eller beviljar OAuth-consent. För Log Collector-integreringar skapar eller väljer du en appliance och riktar sedan källsystemets Syslog-export till denna appliance.
6. Om Sophos vid den första integreringen frågar efter interna domäner och IP-intervall ska endast de egna interna intervallen registreras. Uppgifterna identifierar egna adresser, grupperar relaterade Alerts och undviker uppslagningar hos tredje part; de är inte samma sak som allowlist för Sophos källadresser.
7. Spara konfigurationen och slutför alla externa consent-dialoger. Notera integreringsnamn, käll-tenant, ansvarig person och datum för nästa rotation av autentiseringsuppgifter.
8. Öppna Threat Analysis Center > Integrations > Configured. Den nya konfigurationen måste visas där. Här kan den senare övervakas eller redigeras. Under Connection Method framgår också om felsökningen ska följa API- eller Log Collector-spåret.

FortiAnalyzer: API-Alerts omfattar inte alla mottagna Syslog-händelser

För Fortinet FortiAnalyzer stöder API-anslutningen Appliance och VM Subscription, inte FortiAnalyzer Cloud. Den läser endast Alerts som genererats av FortiAnalyzer från /eventmgmt/adom/<ADOM>/alerts; <ADOM> anger rätt administrativ domän i källsystemet. En Syslog-händelse som FortiAnalyzer enbart har tagit emot blir inte automatiskt en sådan Alert. Om Syslog-händelser ska läsas in utvärderas i stället FortiAnalyzer Log Collector-integreringen eller Fortinet Fortigate-integreringen för den konkreta källan. Beslutet fattas före konfigurationen av anslutningen, inte först vid en förmodad datalucka.

API-anslutningen tar bort data som inte följer formatet och filtrerar därefter bort vissa Alert-typer: VPN-tunnelmeddelanden (vpntunnel), blockerade webbförfrågningar till ej bedömda mål, meddelanden om IP-/portskanning, anslutningar som undantas från SSL-inspektion på grund av allowlist eller adress, Link Monitor-meddelanden om gränssnitt som har gått ned eller upp, varningar om full Memory Log samt Disk Quota Alert/Warning och blockerade osäkra SSL-anslutningar. Att en sådan Alert saknas är därför inte automatiskt ett autentiserings- eller transportfel. Typmappningen använder mönstermatchning när message inte är tomt, annars fälten FTNTFGTattack, ad.subtype och cat; utan träff rensas fältet message. En mottagen Alert-titel innebär inte automatiskt en fullständig MITRE-mappning.

Välj för godkännandet en ofarlig, godkänd händelse som bevisligen genererar en FortiAnalyzer-Alert, till exempel en konfigurationsändring som den egna Event Handler är inställd att generera en sådan Alert för. Verifiera först Alert, ADOM och tidpunkt i FortiAnalyzer och säkerställ att formatet och Alert-typen inte filtreras bort. Verifiera därefter samma Alert i rätt tenant via den Sophos-sökmetod som har bekräftats för denna anslutning. En godtycklig testinloggning eller en skickad Syslog-rad utan FortiAnalyzer-Alert är inget giltigt test av API-inläsningen. Om den förväntade Alert saknas kontrollerar du först Alert-generering, ADOM, format och typfilter, därefter autentiseringsuppgifter och anslutning; en Sophos Detection eller ett Case garanteras inte heller vid lyckad inläsning.

Kontrollera och testa funktionen

En sparad konfiguration bevisar ännu inte att funktionen fungerar. Kontrollera anslutning, dataflöde och innehåll i denna ordning:

1. Anslutningsstatus: Öppna posten under Configured, eller statusen för en appliance. För Log Collectors betyder rött att integreringen inte fungerar, gult att den fungerar med fel och grönt att händelser tas emot och bearbetas utan synliga problem.
2. Definierad testhändelse: Skapa en ofarlig händelse i källsystemet som säkert registreras av den aktuella API- eller Syslog-kategorin, till exempel en administrativ ändring eller testinloggning. Anteckna tid, användare och källa.
3. Bevis i Data Lake: När den produktspecifika fördröjningen löpt ut söker du under Threat Analysis Center > Live Discover. Använd Live Discover-kategorin eller frågan som dokumenteras i den produktspecifika guiden; om Sophos inte dokumenterar någon sådan fråga för anslutningen får detta generella flöde inte utlova ett universellt frågebaserat test. Runbooken för Live Discover förklarar frågor, Data Lake-gränser och resultatkontroll. Kontrollera tidsstämpel, tenant, användare och händelsetyp. En enskild datapost bevisar anslutningen; flera aktuella poster under en rimlig period bekräftar ett fortlöpande dataflöde.
4. Gräns för Detection: Alla inlästa händelser skapar inte en Detection eller ett Case. Data Ingest gör data tillgängliga för analys, men en Detection uppstår endast när en passande detektionslogik aktiveras. Testa därför först dataupptagningen i Data Lake och förvänta dig inte nödvändigtvis en Alert.
5. Response Action: Använd ett godkänt testkonto och dokumentera utgångsläget. För Microsoft 365 är Block user sign-in följt av Allow user sign-in ett lämpligt reversibelt test. Revoke all current sessions är inte reversibelt. Observera också att Entra Connect Sync senare kan återaktivera ett blockerat hybridkonto, att MDR Response-inställningen begränsar Sophos-analytikernas åtgärder och att namn på vissa Inbox Rules är skiftlägeskänsliga vid Response Actions.

Health Alerts är inget omedelbart test. 24-timmarsperioden börjar vid det första felmeddelandet och skapar endast en Alert med medelhög Severity om felet kvarstår utan avbrott. En grön status eller en bekräftelse av Alert återställer nedräkningen. Om problemet kvarstår visas Alert därefter på nytt en gång var 30:e dag.

Microsoft 365: tre separata integreringar

Att ”ansluta Microsoft 365” är inte ett enda reglage. Tabellen nedan beskriver de separata uppgifterna i Classic/TAC-Marketplace, inklusive begränsningen för Response Actions där. För den utökade lösningen gäller Microsoft Graph API Actions-flödet ovan med egna anslutningar och nytt samtycke; Classic-begränsningen till en miljö gäller inte detta nya flöde.

För Response Actions via Classic/TAC anger Sophos Microsoft Graph-behörigheterna User.ManageIdentities.All, User.EnableDisableAccount.All, User.RevokeSessions.All, MailboxSettings.Readwrite och User.Read. Vid MDR begränsar det valda MDR-svarsalternativet fortfarande om analytiker får agera utan godkännande. I en hybridmiljö med Entra ID kan Microsoft Entra Connect Sync senare aktivera en inloggning som blockerats i Central.

Exempel: anslut Management Activity säkert

1. Säkerställ i Microsoft 365 att Auditing är aktiverad. En Microsoft 365-administratör måste auktorisera anslutningen.
2. Öppna Threat Analysis Center > Integrations > Marketplace och välj Microsoft - Office 365 Management Activity API.
3. Klicka på Add Configuration under Data Ingest (Security Alerts).
4. Kontrollera Auditing-meddelandet, klicka på Save and continue och sedan på Proceed under Connect to Microsoft 365.
5. Logga in med det avsedda Microsoft-administratörskontot, kontrollera de begärda behörigheterna och bekräfta med Accept. Avsluta bekräftelsen med Close.
6. Kontrollera posten i Sophos Fusion. Kategorin Microsoft 365 audit data måste visas under Live Discover > Query. Skapa därefter en spårbar audithändelse och sök efter den med en tillhandahållen fråga.

Microsoft garanterar ingen bestämd tid för när enskilda händelser visas i auditloggen. En fördröjd rad är därför inte automatiskt ett integreringsfel. Efter att Auditing aktiverats för första gången kan det ta upp till 12 timmar innan data visas.

För Graph Security V2 sker den första synkroniseringen cirka fem minuter efter att data blivit tillgängliga i Microsoft Defender Security Center. Om tjänsten Alerts and Incidents först måste provisioneras kan detta Microsoft-steg i sig ta ungefär en timme.

Inaktivera eller avveckla integreringen

Det finns inget gemensamt Disable-reglage för alla integreringstyper. Tillgängliga åtgärder varierar beroende på produkt och Connection Method. Utgå därför inte från att det finns en universell knapp:

1. Öppna Threat Analysis Center > Integrations > Configured, välj konfigurationen och dokumentera status, namn, käll-tenant, appliance och autentiseringsuppgifter.
2. För en API-integrering stoppar du först dataupptagningen kontrollerat eller använder en tillgänglig Disable- eller Delete-åtgärd om den konkreta produktsidan erbjuder den. Återkalla därefter OAuth-consent i källsystemet eller inaktivera den dedikerade appen eller token. För Response Actions förhindrar detta ytterligare åtgärder från Central.
3. För en Log Collector-integrering tar du bort Syslog-målkonfigurationen i källsystemet. Ta inte bort en delad Sophos-appliance så länge andra integreringar använder den.
4. Ta endast bort konfigurationen i Central när krav på lagring, audit och ändringshantering är uppfyllda. Borttagning av en konfiguration garanterar inte att data som redan lagrats i Data Lake raderas. Klargör därför lagring och radering i förväg utifrån tenantens Data Lake- och efterlevnadskrav.
5. Kontrollera att inga nya händelser tas emot och att inga oväntade Response Actions längre kan utföras. Ta därefter bort hemligheter, certifikat, tjänstekonton och allowlist-poster som inte längre behövs.

Vid ett kort underhållsavbrott för en Log Collector-integrering stoppar du Syslog-exporten utan att ta bort en delad appliance. För API- och Response-integreringar får en autentiseringsuppgift spärras som underhållspaus endast om det i förväg har verifierats att samma konfiguration kan återaktiveras. Använd annars endast den vägen som erbjuds för anslutningen för Disable, Delete eller Reconnect. En spärrad eller utgången autentiseringsuppgift är ingen universell rollback och skapar synkroniseringsfel.

Avgränsa vanliga fel systematiskt

API-integreringen synkroniserar inte

Öppna Configured, kontrollera Connection Method och läs det konkreta felet. Åtgärda först Invalid credentials, insufficient permission och expired credentials i tredjepartsprodukten: kontrollera ID:n, hemligheter, tokens giltighetstid, certifikat och API-rättigheter. Network not reachable och invalid domain kräver även kontroll av DNS, proxy, brandvägg och tjänststatus. Vid request throttling har leverantören begränsat API:t; upprepade omedelbara sparningar kan förvärra problemet. För Microsoft betyder HTTP 401 ogiltig autentisering; 429 och 509 anger begränsning.

Log Collector förblir röd eller gul

Rött betyder ur funktion, gult betyder i drift med fel. Kontrollera VM-resurser, nätverk och DNS, utgående åtkomst samt Syslog-vägen från källsystemet till appliance. Meddelandet no events received since last container restart betyder att inga Syslog-händelser har tagits emot sedan containerstarten. no received events in last 10 mins kan tyda på avbruten export eller en källa som sällan skickar data. Vid uppladdningsfel buffrar appliance data på disk. Om uppladdningen förblir blockerad och disken blir full kan äldre data tas bort.

Microsoft 365 levererar inga data

För Management Activity måste Microsoft 365 Auditing vara aktiverad och egenskapen Enabled for users to sign-in? = Yes vara inställd under Office 365 Management APIs. Ta hänsyn till starttiden på upp till 12 timmar efter att Auditing aktiverats. För Graph Security V2 kontrollerar du åtkomst till Defender XDR, consent, provisionering av Alerts-tjänsten och Microsoft-licensens tillgängliga omfattning. Det gamla Graph Security API:t är inte längre ett reservalternativ.

Ingen Health Alert trots avbrott

Kontrollera först att det är en Data Ingest-integrering och att felet har kvarstått oavbrutet i 24 timmar sedan det första felmeddelandet. En tillfälligt grön status eller en bekräftelse av Alert återställer nedräkningen. Som standard får alla Central-administratörer e-postmeddelandet; egna Notification Rules kan ändra distributionen.

Säkerhets- och driftregler

• Använd särskilda appar och hemligheter i stället för personliga administratörskonton.
• Bevilja endast API-rättigheterna som den aktuella integreringen kräver. Response-integreringar behöver normalt skrivrättigheter och kräver striktare godkännande än ren dataupptagning.
• Lagra inte hemligheter i ärenden, skärmbilder eller KB-artiklar. Dokumentera ägare och utgångsdatum i lösenords- eller hemlighetshanteringen.
• Planera rotation av autentiseringsuppgifter före utgångsdatumet. Sophos rapporterar utgångna uppgifter som synkroniseringsfel.
• Tillåt endast Sophos IP-adresser när leverantören kräver en allowlist med källadresser, och använd listan för den faktiska Central-regionen.
• Aktivera Health-aviseringar för ett ansvarigt team. När en Custom Notification Rule skapas stängs standardutskicket av alla e-postalerts till alla administratörer av, och nödvändiga regler måste återskapas separat.
• Dokumentera datakälla, syfte, dataklassificering, lagring, rättigheter, test, Owner och avvecklingsväg för varje integrering.

Acceptanskriterier

Integreringen är inte klar förrän den visas under Configured med förväntad metod, en definierad testhändelse kan verifieras i avsett mål, tidsstämpel och käll-tenant stämmer och en Owner ansvarar för rotation av autentiseringsuppgifter och Health Alerts. För Response Actions krävs dessutom ett godkänt och dokumenterat test. Endast reversibla åtgärder återställs till utgångsläget; irreversibla åtgärder som sessionsåterkallelse får inte användas som rollback-test. Dokumentera oundvikliga fördröjningar, exempelvis för Microsoft 365 Auditing, i driftprotokollet.

Vanliga frågor

Skickar varje integrering data till Sophos Data Lake?

Nej. Data Ingest skickar data till Data Lake. Response Action gör det möjligt att utföra en åtgärd i tredjepartsprodukten. Vissa produkter erbjuder bara en typ, andra separata konfigurationer för båda riktningarna.

Är tredjepartsintegreringar kostnadsfria med XDR?

Inte generellt. För MSP Flex anger Sophos vissa integreringar i kategorin Sophos XDR som kan användas med XDR utan ett extra Integration License Pack. Andra kategorier kräver rätt pack i Flex. Dessutom kan licenser från tredjepartsleverantören krävas.

Varför ser jag data men ingen Detection?

Upptagning och detektering är två olika steg. En Data Ingest-anslutning kan skriva händelser korrekt till Data Lake utan att varje händelse skapar en Sophos Detection eller ett Case. Kontrollera först rådataflödet med den avsedda Live Discover-frågan.

Kan samma appliance användas för flera Syslog-integreringar?

Ja, via Classic-SVA tillåter Sophos flera tredjepartsintegreringar och en Sophos NDR-integrering på samma appliance. Varje källa måste ändå konfigureras med rätt anslutnings- och formatinställningar. Den nya XDR Data Collector är däremot Syslog-ersättaren och varken övertar eller kör denna NDR-arbetslast. För bytet gäller collector-migreringsflödet som länkas ovan; NDR drivs separat enligt NDR-runbooken.

Varför räcker inte Microsoft 365 Response-integreringen?

Den tillhandahåller åtgärder men hämtar inte automatiskt Audit- eller Defender-alerts. Lägg därför till Microsoft 365 Management Activity och Microsoft Graph Security API V2, så att Detections och undersökningskontext blir tillgängliga.

Tar borttagning av en integrering bort historiska Data Lake-data?

Borttagning garanterar inte att redan inlästa data raderas omedelbart. Behandla därför borttagningen som ett stopp av framtida dataflöde och klargör krav på lagring och radering separat innan en bindande raderingstid utlovas.