Proteggere l'accesso all'API XML di Sophos Firewall

L’API XML di Sophos Firewall è utile per automazione, monitoraggio, backup, analisi e integrazioni. Proprio per questo fa parte della superficie di attacco di gestione. Consentire l’accesso all’API significa dare a un sistema la possibilità di leggere dati di configurazione o, a seconda delle autorizzazioni, apportare modifiche.

L’accesso all’API non dovrebbe quindi essere ampiamente consentito da reti interne o fonti arbitrarie. È meglio avere un piccolo set documentato di reti di gestione, host di automazione o accessi partner fissi.

Dalla versione SFOS 22, Sophos ha ampliato il controllo dell’accesso all’API. Le impostazioni di accesso all’API si trovano in Administration > API access, e le fonti consentite possono essere definite come host IP. In questo modo è possibile modellare correttamente non solo singoli indirizzi IP, ma anche intervalli IP e reti.

Quando l’accesso all’API XML è utile

L’API XML non è un accesso standard per il lavoro amministrativo normale. È utile quando c’è un processo tecnico concreto dietro.

Casi d’uso tipici:

Monitoraggio o inventario.
Controlli di configurazione automatizzati.
Processi di backup o documentazione.
Piattaforme MSP o di integrazione.
Script per compiti amministrativi ricorrenti.
Modifiche preparate da strumenti come Sophos Firewall Config Studio.

Se un processo può funzionare anche senza API, l’accesso all’API non dovrebbe rimanere attivato preventivamente. Ogni interfaccia aggiuntiva necessita di un proprietario, una fonte, un concetto di accesso e un controllo.

Cosa è cambiato con SFOS 22

Con SFOS 22, il controllo dell’accesso all’API XML è diventato molto più gestibile:

Le impostazioni di accesso all’API sono state spostate nel menu Administration > API access.
L’accesso all’API è disattivato per impostazione predefinita e deve essere abilitato consapevolmente.
L’accesso all’API può essere limitato agli host IP.
Come fonti sono possibili indirizzi IP, intervalli IP e reti.
Possono essere consentiti fino a 64 host IP.
Durante l’aggiornamento, gli indirizzi IP precedentemente consentiti vengono automaticamente convertiti in oggetti host IP.
Gli oggetti migrati ricevono il prefisso apiconfig.

Questo è utile per l’operatività, poiché le fonti API non devono più essere gestite solo come singoli indirizzi sciolti. È possibile nominare correttamente una rete di gestione, un host di automazione o un gruppo di host dedicato e riconoscerli successivamente nelle revisioni.

Regola di base: consentire l’API solo da sorgenti definite

L’accesso API deve essere trattato come WebAdmin o SSH: il più ristretto possibile, ampio solo quanto necessario.

Sorgenti sensate sono ad esempio:

un server di automazione dedicato,
un sistema di monitoraggio,
un host di configuration management,
una rete interna di management,
una rete VPN o amministrativa,
un indirizzo sorgente partner o MSP chiaramente definito.

Non sono sensate:

intere reti client,
reti guest o IoT,
Any,
autorizzazioni vaghe del tipo “tutta la rete server”,
indirizzi IP di test temporanei che poi vengono dimenticati.

Se fornitori esterni hanno bisogno di accesso API, la sorgente deve essere definita nel modo più specifico possibile. Inoltre deve essere documentato a cosa serve l’accesso e quando verrà rimosso.

Procedura consigliata

Il percorso esatto nell’interfaccia può variare leggermente in base alla versione SFOS. In SFOS 22 la configurazione API si trova in Administration > API access.

Procedura pratica:

Verificare quale sistema necessita dell’accesso API.
In Hosts and services > IP host, creare un oggetto IP Host chiaro per questo sistema.
Se servono più sorgenti, nominare in modo pulito IP Hosts, IP ranges o reti.
In Administration > API access, abilitare API access.
In Allowed IP hosts, consentire solo questi oggetti.
Fare clic su Apply.
Non inserire reti client o server ampie.
Testare l’accesso dal vero host di automazione o monitoraggio, non dal notebook admin.
Rimuovere le sorgenti non più necessarie.
Documentare la modifica nel processo di change.

Nelle installazioni esistenti, dopo un upgrade a SFOS 22, è opportuno cercare anche oggetti con il prefisso apiconfig. Questi oggetti sono stati creati da vecchie autorizzazioni API e devono essere verificati, rinominati o ripuliti.

Testare l’accesso in modo mirato

L’endpoint API si trova di solito qui:

https://<IP-o-hostname-firewall>:<Port>/webconsole/APIController

La porta è la porta HTTPS della WebAdmin Console. Se la porta admin è stata modificata in Administration > Admin settings, lo strumento API deve usare la stessa porta. L’API lavora con payload XML tramite HTTP POST, non come una classica API REST con endpoint GET, POST, PUT e DELETE separati.

Un test sensato non deve solo verificare se il login è possibile. Deve mostrare se la sorgente corretta è autorizzata, se l’account può eseguire l’operazione richiesta e se il risultato resta tracciabile nel processo di audit o change.

Per l’accettazione, verificare separatamente questi punti:

Sorgente: Il test viene eseguito dal vero host di automazione, monitoraggio o integrazione, non dal notebook admin.
Accesso: Il firewall accetta l’IP sorgente solo se l’oggetto IP Host corrispondente è autorizzato in API access.
Account: L’account API o di servizio usato ha solo i diritti necessari.
Secret: Nome utente, password o token non finiscono nella shell history, nei ticket, nelle chat o negli screenshot.
Audit: L’accesso o la modifica è tracciabile nel processo di audit o change.
Rollback: Prima delle operazioni di scrittura esistono un backup, un punto di rollback e un test di lettura innocuo.

Gli esempi curl con nome utente e password nell’URL vengono copiati rapidamente e poi sono difficili da rimuovere dai log. È meglio eseguire un breve test con un account di servizio dedicato, un secret temporaneo, archiviazione sicura e successiva rotazione se un secret è stato usato in un contesto non sicuro.

Per test strutturati, una collection Postman è spesso più pulita di un comando shell copiato al volo. Anche lì indirizzo del firewall, porta, nome utente, password e valori degli oggetti devono essere gestiti come variabili o secret, non inseriti direttamente in request, screenshot o ticket. La collection non è un concetto di sicurezza, ma aiuta a testare operazioni di lettura e scrittura in modo più riproducibile.

Un’API raggiungibile non dimostra ancora che la modifica pianificata sia tecnicamente sicura. Prima di operazioni di scrittura in produzione deve quindi funzionare prima una query di lettura innocua, seguita da una piccola modifica controllata.

Accesso all’API e diritti utente

Un indirizzo IP di origine da solo non è un concetto di sicurezza completo. La restrizione limita solo da dove l’API è raggiungibile. Inoltre, deve essere chiaro con quale account viene effettuato l’accesso all’API e quali diritti ha questo account.

Per ambienti produttivi si dovrebbe verificare:

Viene utilizzato un account API o di servizio dedicato?
L’account ha solo le autorizzazioni necessarie?
È chiaramente documentato quale persona o team è responsabile dell’account?
La password o il segreto sono conservati in modo sicuro?
L’accesso viene rimosso quando l’integrazione non è più utilizzata?
Le modifiche sono tracciabili tramite log di audit?

Gli account amministrativi condivisi sono problematici per i processi API. Se più sistemi o persone utilizzano lo stesso account, la tracciabilità si indebolisce. Per le analisi dei cambiamenti è rilevante verificare i log di audit di Sophos Firewall.

Per un account API dedicato, un processo ristretto è meglio di un full admin copiato rapidamente. Nella documentazione Sophos questo blocco compare come Allow API access to administrators: non viene autorizzata solo la sorgente, anche l’amministratore o il profilo deve avere l’accesso corretto.

Creare un profilo amministratore con i diritti necessari in Profiles > Device access.
Creare un utente amministratore per il processo API in Authentication > Users.
Assegnare il profilo amministratore corretto.
Se l’accesso serve solo temporaneamente, limitare Access time.
Se possibile, limitare Login restriction for device access alle sorgenti previste.
Poi consentire API access e Device Access per la sorgente corretta.

Sophos supporta le API ufficiali e gli script di esempio non modificati. Integrazioni, wrapper e automazioni proprie richiedono comunque un responsabile interno, test e un concetto di rollback. “Funziona in laboratorio” non è sufficiente per operazioni di scrittura in produzione.

MFA e utenti API dopo SFOS 22

La MFA è importante per gli accessi amministrativi interattivi. Per processi API e di automazione, però, bisogna pianificare consapevolmente come deve funzionare l’autenticazione. Uno script, uno strumento di monitoraggio o un sistema di integrazione non può semplicemente inserire un codice OTP se l’utente impone la MFA.

Nella lista Known Issues è documentato un caso particolare di SFOS 22: dopo un upgrade, le modifiche di configurazione basate su API possono fallire per utenti migrati se la MFA è attiva e non viene fornito un one-time token. Gli utenti non migrati possono comportarsi diversamente in alcuni casi. Per l’esercizio è importante non disattivare la MFA ovunque, ma separare correttamente gli account API.

Approccio consigliato:

Usare un account di servizio dedicato per i processi API.
Assegnare all’account solo i diritti necessari.
Limitare inoltre API access a IP Hosts fissi o reti di management.
Verificare se la MFA è tecnicamente e operativamente sensata per questo account.
Se la MFA non è praticabile per l’account API, controllarlo in modo particolarmente stretto tramite sorgente, diritti, archiviazione dei secret e audit trail.
Dopo un upgrade a SFOS 22, testare tutti i processi API con operazioni di lettura e scrittura.

⚠️ Gli utenti API senza MFA non sono un lasciapassare per diritti ampi. Se per motivi tecnici un account API deve funzionare senza MFA, IP sorgente, diritti, archiviazione password, responsabilità e auditabilità devono essere controllati più rigorosamente.

Questo punto è particolarmente importante per automazioni che non leggono soltanto, ma modificano anche la configurazione.

Prima di modifiche API in produzione, verificare almeno tre aspetti:

È disponibile un backup Sophos Firewall aggiornato.
L’account API previsto può eseguire correttamente una query di lettura innocua.
Per modifiche massive preparate con Sophos Firewall Config Studio, le chiamate API o curl generate funzionano con l’account previsto.

Distinzione da Device Access

Il controllo dell’accesso all’API non è lo stesso di Device Access, ma i due controlli interagiscono. Device Access controlla i servizi firewall locali come WebAdmin, SSH, User Portal, VPN Portal, DNS o Ping. Le impostazioni di accesso all’API controllano inoltre quali host IP possono usare l’API XML. Importante: le autorizzazioni Device Access per la WebAdmin Console valgono anche per gli accessi API.

In pratica significa che l’accesso all’API deve essere consentito, la fonte deve essere ammessa nelle impostazioni di accesso all’API e l’accesso locale di gestione alla firewall non deve essere bloccato da Device Access. Ogni livello limita una parte diversa della superficie di attacco:

Configurare correttamente Device Access: servizi firewall locali come WebAdmin, SSH, User Portal, VPN Portal, DNS o Ping
Controllo dell’accesso all’API: host IP che possono usare anche l’API XML
Attivare MFA per Sophos Firewall WebAdmin, VPN Portal e Remote Access: accessi interattivi per WebAdmin, VPN Portal e Remote Access
Amministratori nominati e ruoli chiari: Tracciabilità e raggio di danno di account amministrativi e di servizio

Se una rete amministrativa può utilizzare WebAdmin, SSH e API, questa rete dovrebbe essere particolarmente ben protetta. Un client compromesso nella rete di gestione è altrimenti un ingresso diretto nella gestione del firewall.

Operatività e revisione

L’accesso all’API dovrebbe essere regolarmente verificato. Soprattutto dopo migrazioni, cambi di fornitori, progetti di automazione o aggiornamenti del firewall, spesso rimangono fonti vecchie.

Domande di revisione sensate:

Quali host IP possono attualmente utilizzare l’accesso all’API?
Ci sono oggetti con il prefisso apiconfig?
Questi oggetti sono ancora necessari?
I nomi e le descrizioni corrispondono allo scopo effettivo?
Ci sono responsabili documentati?
Gli accessi API sono considerati in un processo di cambiamento o audit?
C’è un backup aggiornato prima di modifiche basate su API più grandi?

Prima delle modifiche basate su API, dovrebbe sempre essere disponibile un backup. L’articolo Creare o ripristinare un backup di Sophos Firewall descrive a cosa prestare attenzione per backup, ripristino e compatibilità.

Errori tipici

API access consentito per un’intera rete client: Ogni client compromesso in quella rete può raggiungere l’API.
Vecchi oggetti apiconfig non verificati: Le autorizzazioni legacy migrate restano attive senza essere notate.
L’account di servizio usa pieni diritti admin: Un secret compromesso ha un raggio d’impatto inutilmente ampio.
L’automazione API usa un admin con MFA obbligatoria: Script o strumento possono fallire nelle operazioni di scrittura dopo un upgrade SFOS.
Porta errata nello strumento: La porta HTTPS admin è stata cambiata, ma lo strumento continua a usare la vecchia porta.
Ci si aspetta logica REST: Lo strumento invia metodi REST invece di payload XML tramite HTTP POST a APIController.
IP temporaneo del fornitore resta attivo: L’accesso esterno rimane possibile più a lungo del previsto.
Nessuna documentazione dello scopo: Gli amministratori successivi non sanno se l’autorizzazione serve ancora.
Modifiche API senza backup: Un’automazione errata è più difficile da annullare.

Risoluzione dei problemi

Se uno strumento non riesce a raggiungere l’API XML, si dovrebbe verificare in modo strutturato:

L’indirizzo IP di origine è corretto dal punto di vista del firewall?
La fonte è consentita come host IP, intervallo IP o rete?
Dopo un aggiornamento è stato creato un oggetto apiconfig, ma non è stato adattato correttamente?
Device Access consente l’accesso locale WebAdmin/API da questa zona?
Lo strumento usa l’indirizzo firewall corretto e la porta HTTPS di amministrazione corretta?
Nome utente, password o segreto sono corretti?
L’account ha i diritti necessari?
L’account impone MFA, anche se lo strumento non può fornire un token monouso?
Ci sono effetti di routing, NAT o proxy tra lo strumento e il firewall?
L’accesso è stato rimosso intenzionalmente tramite una misura di indurimento?
Il test è stato eseguito dal sistema sorgente corretto o solo dal client admin?

Se una modifica API ha effetti imprevisti, prima di tutto salvare l’ultimo backup e poi controllare il trail di audit, il confronto di Config Studio e gli oggetti del firewall interessati. In caso di problemi di traffico live, Log Viewer e Packet Capture sono più utili dell’API stessa.

Lista di controllo

Prima dell’attivazione:

Documentare lo scopo dell’accesso all’API.
Determinare chiaramente il sistema di origine.
Creare un oggetto host IP con un nome significativo.
Verificare l’account di servizio e le autorizzazioni.
Stabilire consapevolmente il comportamento MFA dell’account API.
Stabilire un processo di backup e rollback.
Definire un metodo di test senza perdita di segreti.

Durante l’operatività:

Consentire l’accesso all’API solo per fonti definite.
Non consentire reti client, ospiti o IoT ampie.
Controllare gli oggetti apiconfig dopo gli aggiornamenti.
Controllare gli accessi dei fornitori nel tempo e nel contesto.
Conservare i segreti in modo protetto e rinnovarli in caso di cambiamento di personale o strumento.
Ruotare i segreti se sono finiti nella cronologia della shell, nei ticket o in archivi non sicuri.
Testare operazioni di lettura e scrittura API dopo aggiornamenti SFOS.

Durante la revisione:

Verificare regolarmente le fonti API consentite.
Rimuovere gli host IP non più necessari.
Confrontare le modifiche con il trail di audit e i ticket di cambiamento.
Testare i processi di automazione dopo gli aggiornamenti del firmware.

FAQ

Cos'è l'API XML di Sophos Firewall?

L’API XML è un’interfaccia di gestione di Sophos Firewall. Gli ambiti di utilizzo tipici sono automazione, integrazioni, monitoraggio o richieste di configurazione. L’interfaccia dovrebbe essere raggiungibile solo da fonti di gestione o automazione definite.

Dove si configura l'accesso all'API in SFOS 22?

Sophos ha spostato le impostazioni di accesso all’API con SFOS 22 nella sezione Administration. Lì è possibile stabilire quali host IP ricevono l’accesso all’API.

Cosa significa il prefisso apiconfig?

Durante l’aggiornamento a SFOS 22, il firewall converte gli indirizzi IP API precedentemente consentiti in oggetti host IP. Questi oggetti migrati vengono nominati con il prefisso apiconfig e dovrebbero essere controllati dopo l’aggiornamento.

Una restrizione IP di origine è sufficiente come protezione API?

No. La restrizione IP di origine riduce le fonti raggiungibili, ma non sostituisce account puliti, autorizzazioni adeguate, archiviazione sicura dei segreti, backup e auditabilità.

Un utente API dovrebbe utilizzare MFA?

Per gli amministratori interattivi, MFA è utile. Nell’automazione API, è necessario verificare se lo strumento può supportare un token monouso. Se non è praticabile, dovrebbe essere utilizzato un account API dedicato con diritti minimi, restrizione IP di origine stretta e audit pulito.

L'accesso all'API dovrebbe rimanere attivato permanentemente?

Solo se un processo concreto necessita regolarmente dell’API. Gli accessi temporanei di test o fornitori dovrebbero essere rimossi o disattivati dopo il completamento.