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 nella sezione Administration, 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.
• 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 fondamentale: consentire l’API solo da fonti definite

L’accesso all’API dovrebbe essere trattato secondo lo stesso principio di WebAdmin o SSH: il più stretto possibile, il più ampio necessario.

Fonti sensate sono ad esempio:

• un server di automazione dedicato,
• un sistema di monitoraggio,
• un host di gestione della configurazione,
• una rete di gestione interna,
• una rete VPN o amministrativa,
• un indirizzo di origine partner o MSP chiaramente definito.

Non sono sensate:

• intere reti client,
• reti ospiti o IoT,
• Any,
• autorizzazioni “rete server completa” poco chiare,
• indirizzi IP di test temporanei che vengono dimenticati successivamente.

Se i fornitori esterni necessitano di accesso all’API, la fonte dovrebbe essere definita il più specificamente possibile. Inoltre, dovrebbe essere documentato per cosa viene utilizzato l’accesso e quando verrà rimosso.

Procedura consigliata

Il percorso UI esatto può variare leggermente a seconda della versione SFOS. In SFOS 22, la configurazione dell’API si trova sotto Administration.

Procedura pratica:

1. Verificare quale sistema necessita di accesso all’API.
2. Creare un oggetto host IP univoco per questo sistema.
3. Se sono necessarie più fonti, nominare correttamente host IP o reti.
4. Consentire l’accesso all’API solo per questi oggetti.
5. Non inserire reti client o server ampie.
6. Testare l’accesso con lo strumento interessato.
7. Rimuovere le fonti non più necessarie.
8. Documentare la modifica nel processo di cambiamento.

Per le installazioni esistenti dopo un aggiornamento a SFOS 22, si dovrebbe anche cercare oggetti con il prefisso apiconfig. Questi oggetti sono stati generati da voci di autorizzazione API più vecchie e dovrebbero essere controllati, nominati o ripuliti.

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.

MFA e utenti API dopo SFOS 22

MFA è importante per gli accessi amministrativi interattivi. Per i processi API e di automazione, tuttavia, è necessario pianificare consapevolmente come dovrebbe funzionare l’autenticazione. Uno script, uno strumento di monitoraggio o un sistema di integrazione non può inserire facilmente un codice OTP se l’utente utilizzato impone MFA.

Nella lista dei problemi noti è documentato un caso particolare di SFOS 22: dopo un aggiornamento, le modifiche di configurazione basate su API possono fallire per utenti migrati se MFA è attivo e non viene fornito un token monouso. Gli utenti non migrati possono comportarsi diversamente in determinati casi. Per l’operatività è importante non trasformare questo in un “MFA ovunque disattivato” non pulito, ma separare correttamente gli account API.

Approccio consigliato:

1. Utilizzare un account di servizio dedicato per i processi API.
2. Dotare l’account solo dei diritti necessari.
3. Limitare l’accesso all’API ulteriormente a host IP fissi o reti di gestione.
4. Verificare se MFA è tecnicamente e operativamente sensato per questo account.
5. Se MFA non è praticabile per l’account API, controllare l’account in modo particolarmente stretto tramite fonte, diritti, archiviazione dei segreti e audit trail.
6. Dopo un aggiornamento a SFOS 22, testare tutti i processi API con operazioni di lettura e scrittura.

⚠️ Gli utenti API senza MFA non sono un lasciapassare per ampi diritti. Se un account API viene gestito senza MFA per motivi tecnici, devono essere controllati più strettamente l’IP di origine, i diritti, l’archiviazione delle password, la responsabilità e l’auditabilità.

Questo punto è particolarmente importante per le automazioni che non solo leggono, ma modificano la configurazione. Prima delle modifiche API produttive, dovrebbe essere disponibile un backup aggiornato di Sophos Firewall. Per le modifiche di massa preparate da Sophos Firewall Config Studio, si dovrebbe inoltre verificare se le chiamate API o curl generate funzionano con l’account pianificato.

Distinzione da Device Access

Il controllo dell’accesso all’API non è lo stesso di Device Access. Device Access controlla i servizi firewall locali come WebAdmin, SSH, User Portal, VPN Portal, DNS o Ping. Le impostazioni di accesso all’API controllano invece l’accesso all’interfaccia di gestione dell’API XML.

Tuttavia, entrambi gli argomenti fanno parte dell’indurimento della gestione. Ogni livello limita una parte diversa della superficie di attacco:

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

Risoluzione dei problemi

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

1. L’indirizzo IP di origine è corretto dal punto di vista del firewall?
2. La fonte è consentita come host IP, intervallo IP o rete?
3. Dopo un aggiornamento è stato creato un oggetto apiconfig, ma non è stato adattato correttamente?
4. Lo strumento utilizza l’indirizzo e la porta del firewall corretti?
5. Nome utente, password o segreto sono corretti?
6. L’account ha i diritti necessari?
7. L’account impone MFA, anche se lo strumento non può fornire un token monouso?
8. Ci sono effetti di routing, NAT o proxy tra lo strumento e il firewall?
9. L’accesso è stato rimosso intenzionalmente tramite una misura di indurimento?

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.

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.
• 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