Hantera Sophos Central API-autentiseringsuppgifter säkert
Sophos Central kan automatiseras via API:er och anslutas till SIEM-, RMM-, rapporterings- eller försäkringsplattformar. För detta används inte personliga administratörskonton, utan separata API Credentials som består av Client ID och Client Secret.
Dessa autentiseringsuppgifter är maskinidentiteter. Den som har tillgång till ett secret kan utföra alla API-åtgärder som den tilldelade Service Principal-rollen tillåter. Ett secret ska därför hanteras som ett privilegierat lösenord och får inte hamna i skript, ärenden, e-post eller Git-arkiv.
Skilja mellan API Credentials och Integration Credential Manager
Under Global Settings > Access Control finns två områden med liknande namn:
| Område | Uppgift |
|---|---|
| API Credentials | Teknisk identitet som en applikation använder för att anropa Sophos Central-API:erna |
| Integration Credential Manager | Autentiseringsuppgifter för externa produkter som Sophos använder för integrationer som Data Ingestion eller Response Actions |
För ett eget skript, en SIEM-fråga eller en API-klient skapas API Credentials. Autentiseringsuppgifter för en tredjepartsprodukt som Sophos Central självt ska använda hör i stället hemma i Integration Credential Manager.
Alla automatiseringar kräver inte allmänna API Credentials: användare och grupper synkroniseras via en katalogtjänst och programvara kan distribueras med ett installationsskript som körs lokalt på varje enhet. Skapa bara en API-identitet för AD Sync om det planerade synkroniseringsflödet kräver det och tilldela uteslutande rollen Service Principal Directory Sync.
Förutsättningar och ansvar
Endast en Super Admin kan skapa och hantera API Credentials. Applikationen autentiserar sig med sitt eget Client ID och Client Secret, inte med administratörens personliga konto.
Före skapandet dokumenteras syfte, ägare, målsystem, nödvändig roll, utgångsdatum och nödkontakt. En separat autentiseringsuppgift används för varje applikation och miljö. Ett gemensamt secret för säkerhetskopieringsskript, SIEM och externa tjänsteleverantörer förhindrar riktad spärrning och försvårar orsaksanalysen.
Välja lämplig Service Principal-roll
Sophos tillhandahåller flera roller:
- Service Principal Read-Only läser klientorganisationsdata men får inte ändra dem eller köra Live Discover-frågor.
- Service Principal Management kan läsa, skapa, ändra och ta bort användare och användargrupper, läsa och hantera Alerts, läsa Endpoints och utlösa åtgärder som en genomsökning samt visa och ändra globala inställningar för Endpoint Protection. Rollen hanterar dessutom administratörer, roller och Security Policies, men har ingen åtkomst till Live Discover-frågor.
- Service Principal Forensics skapar, visar, kör och tar bort Live Discover-frågor.
- Service Principal Directory Sync är endast avsedd för Active Directory-synkronisering och får inte utföra andra API-uppgifter.
- Service Principal Firewall begränsar identiteten till Firewall-hantering och tillåter inga Central API-uppgifter utanför detta område.
- Service Principal Audit Log ger externa applikationer, SIEM-verktyg och integrationsskript skrivskyddad frågeåtkomst för att hämta Audit Log-händelser.
- Service Principal Super Admin har omfattande läs-, skriv- och borttagningsbehörigheter samt åtkomst till frågor.
Valet börjar alltid med den minsta rollen. En rapporterings- eller cyberförsäkringsintegration får Read-Only. AD Sync får den särskilt avsedda rollen. Super Admin används endast när dokumenterade API-endpoints faktiskt kräver omfattande skrivbehörigheter och ingen snävare roll fungerar.
Skapa en autentiseringsuppgift
Sökvägen är Global Settings > Access Control > API Credentials. Vid första öppningen måste användningsvillkoren godkännas.
- Öppna Add Credential.
- Ange ett unikt namn och en beskrivning med applikation, miljö och ägare.
- Välj den minsta nödvändiga Service Principal-rollen.
- Skapa autentiseringsuppgiften och kopiera omedelbart Client ID och Client Secret.
- Spara secret i organisationens secret store och rensa den tillfälliga lagringen.
Client Secret visas endast en gång. Det kan inte visas igen senare. Om det går förlorat återställs inget befintligt secret. I stället skapas en ny autentiseringsuppgift och den gamla tas bort efter en lyckad övergång.
Testa autentiseringen kontrollerat
Det första testet ska inte vara en produktiv skrivåtgärd. Först hämtas en OAuth-access-token via Sophos Identity-endpoint. Därefter returnerar endpointen whoami klientorganisations-ID, API-host och kontots datatyp. Först därefter görs ett riskfritt läsanrop mot den API-host som returnerades för klientorganisationen.
En API-host kopieras inte från ett exempel. Sophos driver flera dataregioner och därför måste URL:en som returneras av whoami användas. Klientorganisations-ID och organisations-ID är inte heller utbytbara.
Minst följande fall dokumenteras för testet:
- Autentisering med den nya identiteten fungerar.
- Den förväntade klientorganisationen returneras.
- Tillåtna läsåtgärder fungerar.
- En otillåten åtgärd nekas med
403 Forbidden. - Målsystemet loggar testet på ett spårbart sätt utan att registrera Client Secret.
Hantera utgångsdatum och rotation
Sophos skickar ingen varning när en API-autentiseringsuppgift går ut. Efter utgångsdatumet kan den inte längre användas för autentisering och tas automatiskt bort från Central. Övervakningen måste därför ske utanför Central.
En korrekt rotationsprocess använder en kort överlappning:
- Skapa en ny autentiseringsuppgift med samma eller en snävare roll.
- Ställ om applikationen till den nya autentiseringsuppgiftens Client ID och secret.
- Testa autentisering och verksamhetsfunktion.
- Ta bort den gamla autentiseringsuppgiften.
- Kontrollera ändringen i secret-registret och driftdokumentationen.
Den gamla autentiseringsuppgiften lämnas inte aktiv i flera månader för säkerhets skull. Om en applikation bara stöder en uppsättning autentiseringsuppgifter planeras ett underhållsfönster.
Ersätta gamla SIEM API-tokens
API Token Management är den tidigare autentiseringsmetoden för SIEM Integration API. Sophos utfärdar inte längre nya tokens där och förlänger inte heller befintliga giltighetstider. Befintliga tokens fungerar endast fram till sitt utgångsdatum.
En integration som fortfarande använder dem lämnas därför inte orörd till sista dagen. Inventera token, målsystem, utgångsdatum och använda endpoints, skapa en lämplig API-autentiseringsuppgift, ställ om applikationen och kontrollera hela dataflödet. Den gamla token tas bort först efter en lyckad parallellkontroll.
Bytet från en äldre token till API Credentials är inte bara ett namnbyte. OAuth-autentisering, whoami, regional host och rollmodell måste stödjas av integrationen. En SIEM-connector konfigureras därför enligt tillverkarens aktuella instruktioner och inte med ett gammalt token-exempel.
Externa tjänsteleverantörer och tredjepartsåtkomst
För en extern part skapas en separat identitet med rollen Service Principal Read-Only, förutsatt att rena läsbehörigheter räcker. Client ID och secret överförs via separata, krypterade kanaler. Åtkomsten får ett dokumenterat slutdatum och tas bort när projektet är avslutat.
En sådan tredjepartsåtkomst kan via API:et bland annat läsa Alerts and Events, resultat från Account Health Check, enhetsinformation och Policy-konfigurationer. Read-Only förhindrar att något läggs till, ändras eller tas bort i Central, men begränsar inte automatiskt vilka läsbara data tredjepartsplattformen faktiskt hämtar eller lagrar. Före aktiveringen regleras därför datamängd, användningssyfte, lagringsplats, lagringstid och radering i avtal.
Skapandet följer den normala sökvägen Global Settings > Access Control > API Credentials > Add Credential. Vid första öppningen godkänns användnings- och dataskyddsvillkoren, rollen Service Principal Read-Only väljs och Client ID samt det endast en gång synliga Client Secret kopieras omedelbart på ett säkert sätt. Överföringen sker via en godkänd krypterad kanal, till exempel leverantörens HTTPS-portal, inte via e-post eller ärendetext.
API-hosten kopieras inte från en statisk regiontabell. Applikationen hämtar via whoami den API-host som gäller för just denna klientorganisation. Därmed förblir integrationen korrekt dokumenterad även om Sophos ändrar regioner eller endpoints. Så snart tredjepartsleverantören inte längre behöver åtkomst tas autentiseringsuppgiften bort. API-behörigheten återkallas då omedelbart.
En export av det personliga Super Admin-kontot, en gemensam API-identitet för flera kunder eller ett secret i ett supportärende är inte acceptabelt. Tjänsteleverantören måste dessutom redovisa var secret lagras, hur det skyddas och när det raderas.
Felsöka målinriktat
401 Unauthorized
Vanligen är Client ID, secret, token-endpoint eller OAuth-request felaktig. Även en utgången och redan borttagen autentiseringsuppgift leder till detta fel. Kontrollera först om autentiseringsuppgiften fortfarande finns i Central och om applikationen verkligen använder den senaste secret-uppsättningen.
403 Forbidden
Autentiseringen lyckades, men rollen tillåter inte åtgärden. Tilldela inte omedelbart Super Admin. Matcha i stället den nödvändiga API-endpointen mot rätt Service Principal-roll.
Rätt token, fel dataregion
Enbart access-token avgör inte vilken API-host som ska användas. Applikationen måste använda den regionala host som returneras av whoami. En fast angiven host från en annan region orsakar fel eller frågor mot fel plattformsgräns.
Integrationen slutar fungera utan varning
Om Central inte visar någon aktiv Alert kontrolleras utgångsdatum, senaste lyckade API-anrop och secret-version i målsystemet. Övervakning av utgångsdatum hör hemma i den externa övervakningen.
Regelbunden kontroll
Minst varje kvartal kontrolleras namn, ägare, roll, senaste användning, utgångsdatum och målsystem för varje autentiseringsuppgift. Identiteter som inte kan kopplas till en ägare eller inte används tas bort. Vid misstanke om att ett secret har läckt tas den berörda autentiseringsuppgiften omedelbart bort och ersätts med en ny. Därefter granskas målsystemets och integrationens loggar efter ovanliga API-anrop.
Personliga administratörsbehörigheter kontrolleras separat enligt Tilldela rätt Sophos Central-administratörsroller. API Credentials ersätter varken MFA eller personlig, spårbar administratörsåtkomst.