Sécuriser l'accès à l'API XML de Sophos Firewall

L’API XML de Sophos Firewall est pratique pour l’automatisation, la surveillance, les sauvegardes, les analyses et les intégrations. Elle permet aussi d’appliquer de manière reproductible la même configuration à plusieurs pare-feu lorsque le processus est strictement délimité et testé. C’est pourquoi elle fait partie de la surface d’attaque de gestion. Autoriser l’accès à l’API donne à un système la possibilité de lire des données de configuration ou, selon les autorisations, d’effectuer des modifications.

L’accès à l’API ne doit donc pas être largement autorisé depuis les réseaux internes ou des sources quelconques. Il est préférable d’avoir un ensemble restreint et documenté de réseaux de gestion, d’hôtes d’automatisation ou d’accès partenaires fixes.

Depuis SFOS 22, Sophos a étendu le contrôle d’accès à l’API. Les paramètres d’accès à l’API se trouvent dans Administration > API access, et les sources autorisées peuvent être définies en tant qu’hôtes IP. Cela permet de modéliser proprement non seulement des adresses IP individuelles, mais aussi des plages IP et des réseaux.

Dans les anciennes versions de SFOS, la configuration de l’API se trouvait sous Backup and firmware > API. Il faut tenir compte de ce changement de chemin de menu lors de la comparaison avec d’anciennes instructions.

Quand l’accès à l’API XML est-il pertinent ?

L’API XML n’est pas un accès standard pour le travail administratif normal. Son utilisation est pertinente lorsqu’un processus technique concret est en jeu.

Cas d’utilisation typiques :

Surveillance ou inventaire.
Vérifications de configuration automatisées.
Processus de sauvegarde ou de documentation.
Plateformes MSP ou d’intégration.
Scripts pour des tâches administratives récurrentes.
Modifications préparées à partir d’outils comme Sophos Firewall Config Studio.

Si un processus peut se passer de l’API, l’accès à l’API ne doit pas rester activé par précaution. Chaque interface supplémentaire nécessite un propriétaire, une source, un concept d’accès et un contrôle.

Ce qui a changé avec SFOS 22

Avec SFOS 22, le contrôle d’accès à l’API XML est devenu beaucoup plus facile à gérer en fonctionnement :

Les paramètres d’accès à l’API ont été déplacés dans le menu Administration > API access.
L’accès à l’API est désactivé par défaut et doit être activé volontairement.
L’accès à l’API peut être limité aux hôtes IP.
Les sources peuvent ainsi être des adresses IP, des plages IP et des réseaux.
Jusqu’à 64 hôtes IP peuvent être autorisés.
Lors de la mise à niveau, les adresses IP autorisées précédemment sont automatiquement converties en objets hôtes IP.
Les objets migrés reçoivent le préfixe apiconfig.

Cela est utile pour le fonctionnement, car les sources API n’ont plus besoin d’être maintenues uniquement sous forme d’adresses individuelles lâches. On peut nommer proprement un réseau de gestion, un hôte d’automatisation ou un groupe d’hôtes dédié et les reconnaître plus tard lors des revues.

Règle de base : n’autoriser l’API qu’à partir de sources définies

L’accès API doit être traité comme WebAdmin ou SSH : aussi restreint que possible, aussi large que nécessaire.

Les sources pertinentes sont par exemple :

un serveur d’automatisation dédié,
un système de monitoring,
un hôte de gestion de configuration,
un réseau de management interne,
un réseau VPN ou admin,
une adresse source partenaire ou MSP clairement définie.

Les sources suivantes ne sont pas pertinentes :

des réseaux clients complets,
des réseaux invités ou IoT,
Any,
des autorisations floues de type “tout le réseau serveur”,
des adresses IP de test temporaires qui seront oubliées ensuite.

Si des prestataires externes ont besoin d’un accès API, la source doit être définie de manière aussi précise que possible. Il faut également documenter l’usage de cet accès et la date à laquelle il sera supprimé.

Procédure recommandée

Le chemin exact dans l’interface peut varier légèrement selon la version de SFOS. Dans SFOS 22, la configuration API se trouve sous Administration > API access.

Procédure pratique :

Vérifier quel système a besoin d’un accès API.
Sous Hosts and services > IP host, créer un objet IP Host explicite pour ce système.
Si plusieurs sources sont nécessaires, nommer proprement les IP Hosts, IP ranges ou réseaux.
Sous Administration > API access, activer API access.
Sous Allowed IP hosts, autoriser uniquement ces objets.
Cliquer sur Apply.
Ne pas ajouter de grands réseaux clients ou serveurs.
Tester l’accès depuis le véritable hôte d’automatisation ou de monitoring, pas depuis le notebook admin.
Supprimer les sources qui ne sont plus nécessaires.
Documenter le changement dans le processus de change.

Après une mise à niveau vers SFOS 22, il faut aussi rechercher les objets avec le préfixe apiconfig dans les installations existantes. Ces objets ont été créés à partir d’anciennes entrées d’autorisation API et doivent être vérifiés, renommés ou nettoyés.

Tester l’accès de façon ciblée

L’endpoint API se trouve généralement ici :

https://<IP-ou-nom-de-la-firewall>:<Port>/webconsole/APIController

Le port est le port HTTPS de la WebAdmin Console. Si le port admin a été adapté sous Administration > Admin settings, l’outil API doit utiliser le même port. L’API fonctionne avec des payloads XML via HTTP POST, pas comme une API REST classique avec des endpoints GET, POST, PUT et DELETE séparés.

HTTPS ne protège efficacement les identifiants contre l’interception et la modification que si le client valide le certificat de la firewall. Le système d’automatisation doit donc utiliser le nom figurant dans le certificat, faire confiance à la CA émettrice et s’arrêter en cas d’erreur de certificat ou de nom d’hôte. Les options comme curl -k contournent ce contrôle et n’ont pas leur place dans les tâches de production.

Un test utile ne répond pas seulement à la question de savoir si une connexion est possible. Il doit montrer si la bonne source est autorisée, si le compte peut exécuter l’opération nécessaire et si le résultat reste traçable dans le processus d’audit ou de change.

Pour la validation, vérifier ces points séparément :

Source : Le test est exécuté depuis le véritable hôte d’automatisation, de monitoring ou d’intégration, pas depuis le notebook admin.
Accès : La firewall accepte l’IP source uniquement si l’objet IP Host correspondant est autorisé dans API access.
Test négatif : Depuis un hôte de test contrôlé, volontairement absent de Allowed IP hosts, envoyer la même requête de lecture sans effet et vérifier que l’API la refuse sans renvoyer de données de configuration. Ne pas assouplir ni supprimer une autorisation de production uniquement pour créer ce cas de test.
Compte : Le compte API ou service utilisé dispose uniquement des droits nécessaires.
Secret : Les noms d’utilisateur, mots de passe ou tokens ne finissent pas dans l’historique shell, les tickets, les chats ou les captures d’écran.
Audit : L’accès ou le changement reste traçable dans le processus d’audit ou de change.
Rollback : Avant les opérations d’écriture, il existe une sauvegarde, un point de rollback et un test de lecture sans risque.

Les exemples curl avec nom d’utilisateur et mot de passe dans l’URL sont vite copiés et difficiles à retirer ensuite des journaux. Il vaut mieux faire un court test avec un compte de service dédié, un secret de test temporaire, un stockage sûr et une rotation ultérieure si un secret a été utilisé dans un contexte non sûr.

Pour les tests structurés, une collection Postman est souvent plus propre qu’une commande shell copiée rapidement. Là aussi, l’adresse de la firewall, le port, le nom d’utilisateur, le mot de passe et les valeurs d’objets doivent être gérés comme variables ou secrets, et non codés en dur dans les requêtes, captures d’écran ou tickets. La collection n’est pas un concept de sécurité, mais elle aide à tester les opérations de lecture et d’écriture de manière plus reproductible.

Une API joignable ne prouve pas encore que le changement prévu est techniquement sûr. Avant les opérations d’écriture en production, une requête de lecture sans risque doit donc fonctionner, puis un petit changement contrôlé doit être testé.

Construire et évaluer consciemment les requêtes XML

Limite de version : Les instructions SFOS 22 citent les navigateurs comme clients XML possibles. À partir de SFOS 23.0, la procédure spécifique d’envoi de requêtes XML exclut explicitement les navigateurs ; utiliser Postman ou une ligne de commande Linux contrôlée pour ces POST. Le résumé XML général mentionne encore les navigateurs, sans autoriser les POST par navigateur sous SFOS 23.0. L’API REST locale avec clés administrateur est une interface distincte, pas une autre authentification de ces payloads XML.

Les requêtes et modifications présentées ici utilisent HTTP POST vers le même APIController. Lecture, création, mise à jour ou suppression sont définies dans le payload XML, non par la méthode HTTP. XML <Get> signifie lecture, pas automatiquement HTTP GET ; la requête Object Usage nommée « API GET request » est aussi envoyée par HTTP POST. L’export des certificats ci-dessous est une exception HTTP GET documentée séparément. La structure externe comprend <Request>, <Login> et exactement l’opération requise :

<Set operation="add"> crée les objets, règles ou stratégies pris en charge.
<Set operation="update"> modifie les paramètres qui ne peuvent pas être créés comme de nouveaux objets.
<Get> lit les configurations ou les données d’état.
<Remove> supprime les objets pris en charge. Les paramètres fixes, comme la configuration SSL/TLS Inspection, ne peuvent pas être supprimés, mais seulement mis à jour.
<Filter> limite une requête de lecture. Les critères généraux sont =, != et like ; certaines requêtes statistiques prennent en charge des critères supplémentaires.

Si operation est omis dans <Set>, SFOS traite la requête comme add. Ce n’est pas une valeur par défaut anodine : une requête prévue pour une mise à jour peut échouer ou agir sur le mauvais objet. APIXMLTags documente l’attribut alphanumérique facultatif transactionid sur <Set> ; il facilite la corrélation entre la requête et sa réponse. Pour les opérations spécialisées, il faut suivre l’exemple de l’objet dans API help du build SFOS installé. L’exemple de certificat place transactionid sur <Certificate> ; cette exception ne constitue pas une règle générale de placement sur les balises d’entité à l’intérieur de <Set>.

L’attribut facultatif APIVersion dans <Request> utilise une syntaxe propre à la version. Les balises d’objet, attributs, codes d’état et exemples de configuration exacts doivent donc provenir de l’API help du build SFOS installé ; les payloads ne sont pas repris d’une version à l’autre sans vérification.

Une petite requête de lecture présente cette structure :

<Request>
  <Login>
    <Username>api-reader</Username>
    <Password>SECRET</Password>
  </Login>
  <Get>
    <IPHost></IPHost>
  </Get>
</Request>

api-reader et SECRET sont des valeurs de remplacement. Le véritable secret doit être conservé dans le coffre de secrets protégé de l’outil, et non dans un fichier XML du dépôt. Le test n’est réussi que si la réponse contient le résultat attendu sous <Response> et un état approprié sous <Status>. Un succès HTTP ou Send successful dans Postman ne prouve pas à lui seul que SFOS a exécuté l’opération souhaitée. Pour les opérations d’écriture, vérifier également l’objet cible dans WebAdmin et la modification dans l’Audit Trail.

Utiliser en toute sécurité la collection Postman officielle

Télécharger et importer la collection Postman actuelle. La collection ne couvre qu’une partie des requêtes prises en charge ; l’API help locale du pare-feu présente l’ensemble des opérations ainsi que les exemples de configuration et définitions d’entités propres au build. Avant la première requête, remplacer dans Collection Variables les quatre valeurs d’exemple fournies apiadmin, Admin@12345, 172.16.16.16 et 4444 par les valeurs username, password, firewall-ip et firewall-port de l’environnement. Les valeurs d’objets incluses sont également des exemples et ne doivent pas être envoyées sans vérification.

Pour une requête personnalisée, utiliser la méthode POST, l’endpoint indiqué ci-dessus et la clé reqxml sous Body > form-data. Tester d’abord Authenticate > Sign in, puis une requête <Get> sans risque. Une petite opération d’écriture avec rollback préparé ne doit suivre que lorsque la source, le compte, la réponse et l’audit sont corrects.

Imports XML sensibles : Avant d’importer des mots de passe ou d’autres valeurs sensibles, vérifier dans API help du build installé si l’opération concernée exige SecureStorageMasterKey et l’attribut Token sur <Request>, et quelles entrées sont valides. Dans l’exemple POST de SFOS 23, SecureStorageMasterKey est une entrée distincte du corps ; Token figure sur <Request> dans le XML du champ reqxml du corps. Transmettre uniquement les entrées confirmées pour cette opération aux emplacements POST/XML validés. Dans ce processus, ne laisser aucune clé, aucun mot de passe ni jeton dans les URL, l’historique du shell ou les journaux ; cela n’impose pas un jeton pour chaque requête XML.

La documentation conserve également un exemple contradictoire d’URL contenant la clé principale. Tant qu’un conflit entre sources, une entrée requise ou son interprétation reste sans réponse pour le build installé, ne pas effectuer l’import sensible et demander une clarification au Support. L’export de certificats par HTTP GET décrit ci-dessous, avec ses précautions spécifiques, reste une exception distincte.

Une collection exportée peut contenir des identifiants ou des valeurs d’environnement. Nettoyer les collections avant de les partager, ne pas stocker de secrets en clair dans les Initial Values et renouveler les mots de passe de test après une fuite.

Interroger Object Usage avant les modifications

L’API peut renvoyer le nom et le Usage Count des objets pris en charge. Pour cela, utiliser des tags statistiques tels que <IPHostStatistics> à la place du tag d’objet normal. Un filtre sur les noms d’IP Host se présente ainsi :

<Request>
  <Login>
    <Username>api-reader</Username>
    <Password>SECRET</Password>
  </Login>
  <Get>
    <IPHostStatistics>
      <Filter>
        <key name="Name" criteria="like">branch</key>
      </Filter>
    </IPHostStatistics>
  </Get>
</Request>

SFOS 22 prend en charge cette requête d’utilisation pour les IP Hosts, IP Host Groups, MAC Hosts, FQDN Hosts et leurs groupes, Country Groups, Services et Service Groups, ainsi que les Interfaces, Zones, Gateways et SD-WAN Profiles. Les filtres de nom comprennent like, not like, startswith, in, = et != ; le Usage Count prend en plus en charge >, >= et les listes de nombres avec in.

La réponse ne contient actuellement que le nom de l’objet et le nombre d’utilisations, pas les configurations dépendantes. Un Usage Count de 3 n’indique donc pas les trois règles ou profils concernés. Avant une opération update ou remove, vérifier aussi Object usage dans WebAdmin ou Config Studio. Une valeur de 0 n’autorise pas non plus une suppression incontrôlée : sauvegarde, contrôle des dépendances et test limité restent obligatoires.

Connecter et déconnecter des Live Users via l’API

SFOS peut connecter ou déconnecter un utilisateur en tant que Live User via l’API. Cette fonction convient à une intégration clairement attribuée avec un système d’authentification externe, mais elle ne constitue pas un raccourci général permettant de contourner l’authentification normale. Une connexion incorrecte associe le trafic à une identité et peut ainsi influencer les règles firewall ou web basées sur les utilisateurs.

Pour l’administrateur qui exécute l’opération, Manage live users doit être défini sur Read-write sous Profiles > Device access > Identity. L’endpoint prévu est le suivant :

https://<Firewall-IP-ou-FQDN>:<Port>/xmlapi/v1/authentication/networkuser

Cet endpoint traite les connexions et déconnexions en parallèle. L’APIController général peut traiter les mêmes opérations en série. Une intégration existante ne doit donc pas être migrée sans test uniquement en raison de cette différence de comportement.

Un payload de connexion peut être structuré ainsi :

<Request>
  <LiveUserLogin>
    <Admin>
      <UserName>api-liveusers</UserName>
      <Password>ADMIN_SECRET</Password>
    </Admin>
    <UserName>testuser</UserName>
    <IPAddress>192.0.2.25</IPAddress>
    <MacAddress>AA-BB-CC-DD-EE-FF</MacAddress>
  </LiveUserLogin>
</Request>

Pour déconnecter l’utilisateur, envoyer le même utilisateur logique avec LiveUserLogout :

<Request>
  <LiveUserLogout>
    <Admin>
      <UserName>api-liveusers</UserName>
      <Password>ADMIN_SECRET</Password>
    </Admin>
    <UserName>testuser</UserName>
    <IPAddress>192.0.2.25</IPAddress>
    <MacAddress>AA-BB-CC-DD-EE-FF</MacAddress>
  </LiveUserLogout>
</Request>

api-liveusers, ADMIN_SECRET, testuser, 192.0.2.25 et l’adresse MAC sont des exemples. Le nom d’utilisateur, l’adresse IP et l’adresse MAC doivent correspondre à la session réelle. Le secret d’administration doit être conservé dans le coffre de secrets protégé de l’outil et envoyé dans le corps HTTP POST, jamais dans une URL, l’historique du shell, un fichier journal ou une collection partagée.

Après la connexion, l’utilisateur doit apparaître sous Current activities > Live users avec Client type API client. Un test contrôlé vérifie ensuite la décision attendue de la règle basée sur les utilisateurs. Après la déconnexion, la session ne doit plus être répertoriée comme client API actif. Si l’utilisateur reste visible, contrôler d’abord le payload, le nom d’utilisateur, l’adresse IP, l’adresse MAC et la réponse de l’API ; ne pas déconnecter par supposition une autre session Live User.

Transférer ou exporter des certificats via l’API

Les certificats constituent un cas particulier, car des fichiers sont transférés en plus du XML. Pour créer ou mettre à jour un certificat, utiliser dans l’application de bureau Postman une requête form-data en trois parties : fichier de certificat, fichier de Private Key et reqxml contenant un payload <Set><Certificate>...</Certificate></Set>. Les noms de fichiers, le format, l’action et le nom du certificat dans le XML doivent correspondre aux fichiers uploadés.

Les Private Keys doivent rester uniquement sur le poste d’administration protégé et ne jamais être placées dans une collection cloud, un ticket ou un dépôt. Après Send, évaluer d’abord <Response> et <Status>, puis vérifier sous Certificates > Certificates que le certificat attendu, la clé correspondante et la chaîne correcte sont présents. L’attribution et le test du service suivent la procédure Importer et attribuer des certificats sur Sophos Firewall. L’automatisation complète, depuis la CA publique et l’upload propre au build jusqu’à l’attribution au service et la vérification externe, est décrite dans Renouveler un certificat Sophos Firewall via l’API XML et vérifier les services.

Une requête <Get><Certificate/></Get> renvoie une archive .tar avec certificats, Private Keys et Entities.xml, pas un résultat XML normal. Elle ne fonctionne donc pas comme une réponse Postman normale. La procédure spécifique documente HTTP GET depuis Linux ou un navigateur ; les deux variantes placent les identifiants dans le reqxml de l’URL.

SFOS 23.0 : Cette procédure GET mentionne encore les navigateurs, alors que la procédure POST les exclut. Cela ne démontre ni une interdiction de tous les HTTP GET ni un export navigateur testé sur ce firmware. Ne pas reprendre une procédure navigateur ancienne ni supposer que POST fournit le même téléchargement. Avant l’export, vérifier avec Support ou dans un environnement de test autorisé le chemin CLI GET et la protection des identifiants pour le build installé ; sans vérification, ne pas exécuter l’export.

Pour un export vérifié, utiliser uniquement un compte temporaire aux droits limités sur un hôte protégé, ne journaliser ni URL ni commande et renouveler ensuite le secret. Valider certificat TLS et nom d’hôte ; ne pas reprendre -k des exemples du fabricant en production. L’archive est hautement sensible : stockage chiffré à accès restreint, extraction contrôlée et suppression sûre des copies inutiles.

Accès à l’API et droits des utilisateurs

Une IP source seule n’est pas un concept de sécurité complet. La restriction ne limite que l’endroit d’où l’API est accessible. Il doit également être clair avec quel compte l’accès à l’API est effectué et quels droits ce compte possède.

Pour les environnements de production, il convient de vérifier :

Un compte API ou de service dédié est-il utilisé ?
Le compte a-t-il uniquement les autorisations nécessaires ?
Est-il clairement documenté quelle personne ou quelle équipe est responsable du compte ?
Le mot de passe ou le secret est-il stocké en toute sécurité ?
L’accès est-il retiré lorsque l’intégration n’est plus utilisée ?
Les modifications sont-elles traçables via les journaux d’audit ?

Les comptes administratifs partagés posent problème pour les processus API. Si plusieurs systèmes ou personnes utilisent le même compte, la traçabilité est affaiblie. Pour les analyses de changement, il est pertinent de vérifier les journaux de piste d’audit de Sophos Firewall.

Pour un compte API dédié, un processus restreint vaut mieux qu’un administrateur complet copié rapidement. Configurer les administrateurs et profils Sophos Firewall en toute sécurité explique la planification générale des comptes personnels et des profils restreints ; pour les automatisations, le compte de service séparé décrit ici reste déterminant. Dans la documentation Sophos, ce bloc apparaît sous Allow API access to administrators : il ne suffit pas d’autoriser la source, l’administrateur ou le profil doit aussi disposer de l’accès approprié.

Créer un profil administrateur avec les droits nécessaires sous Profiles > Device access.
Créer un utilisateur administrateur pour le processus API sous Authentication > Users.
Assigner le profil administrateur approprié.
Si l’accès n’est nécessaire que temporairement, limiter Access time.
Si possible, limiter Login restriction for device access aux sources prévues.
Autoriser ensuite API access et Device Access pour la source correspondante.

Dans l’exemple officiel, le profil reçoit Read-write pour Objects et Network. Il ne s’agit pas d’une recommandation générale : pour les intégrations en lecture seule et les autres tâches API, les zones inutiles restent sur None ou Read-only ; le droit d’écriture n’est accordé qu’après un test de lecture contrôlé.

Sophos prend en charge les API officielles et les scripts d’exemple non modifiés. Le support technique Sophos ne fournit ni conseil ni dépannage pour les intégrations personnalisées ; Sophos renvoie ce travail au Sophos Partner responsable ou à Sophos Professional Services. Les intégrations, wrappers et automatisations propres ont donc besoin d’un responsable interne, de tests et d’un concept de rollback. « Fonctionne en labo » ne suffit pas pour des opérations d’écriture en production.

MFA et utilisateurs API après SFOS 22

La MFA est importante pour les accès administrateur interactifs. Pour les processus API et d’automatisation, il faut toutefois planifier consciemment le mode d’authentification. Un script, un outil de monitoring ou un système d’intégration ne peut pas simplement saisir un code OTP si l’utilisateur impose la MFA.

La liste Known Issues actuelle documente NC-177609 pour SFOS 22.0.0 GA Respin Build 411 : après une mise à niveau, les changements de configuration via API peuvent échouer pour les utilisateurs migrés lorsque la MFA est active et qu’aucun one-time token n’est transmis. Les utilisateurs non migrés conservent le comportement antérieur jusqu’à l’onboarding MFA. Le workaround officiel consiste à utiliser un compte API distinct sans MFA ou à l’exclure de la MFA. Ce n’est pas une raison de désactiver la MFA des administrateurs interactifs ; pour les builds plus récents, vérifier d’abord les Release Notes et Known Issues.

Approche recommandée :

Utiliser un compte de service dédié pour les processus API.
N’accorder à ce compte que les droits nécessaires.
Limiter en plus API access à des IP Hosts fixes ou à des réseaux de management.
Vérifier si la MFA est techniquement et opérationnellement pertinente pour ce compte.
Si la MFA n’est pas praticable pour le compte API, contrôler ce compte plus strictement par la source, les droits, le stockage du secret et l’audit trail.
Après une mise à niveau vers SFOS 22, tester tous les processus API avec des opérations de lecture et d’écriture.

⚠️ Les utilisateurs API sans MFA ne sont pas une autorisation pour des droits larges. Si un compte API doit fonctionner sans MFA pour des raisons techniques, l’IP source, les droits, le stockage du mot de passe, la responsabilité et l’auditabilité doivent être contrôlés plus strictement.

Ce point est particulièrement important pour les automatisations qui ne font pas que lire, mais modifient aussi la configuration.

Avant des changements API en production, vérifier au minimum trois choses :

Une sauvegarde Sophos Firewall actuelle est disponible.
Le compte API prévu peut exécuter avec succès une requête de lecture sans risque.
Pour les changements de masse préparés avec Sophos Firewall Config Studio, les appels API ou curl générés fonctionnent avec le compte prévu.

Distinction avec Device Access

Le contrôle d’accès à l’API n’est pas la même chose que Device Access, mais les deux contrôles se complètent. Device Access contrôle les services locaux de la firewall comme WebAdmin, SSH, User Portal, VPN Portal, DNS ou Ping. Les paramètres d’accès à l’API contrôlent en plus quels hôtes IP peuvent utiliser l’API XML. Important : les autorisations Device Access pour la WebAdmin Console s’appliquent aussi aux accès API.

En pratique, cela signifie que l’accès à l’API doit être autorisé, que la source doit être admise dans les paramètres d’accès à l’API et que l’accès local de gestion à la firewall ne doit pas être bloqué par Device Access. Chaque couche limite une partie différente de la surface d’attaque :

Configurer correctement Device Access: services locaux de la firewall comme WebAdmin, SSH, User Portal, VPN Portal, DNS ou Ping
Contrôle d’accès à l’API: hôtes IP qui peuvent utiliser en plus l’API XML
Activer le MFA pour Sophos Firewall WebAdmin, VPN Portal et Remote Access: Connexions interactives pour WebAdmin, VPN Portal et Remote Access
Administrateurs nommés et rôles clairs: Traçabilité et rayon d’action des comptes administratifs et de service

Si un réseau d’administration est autorisé à utiliser WebAdmin, SSH et l’API, ce réseau doit être particulièrement bien protégé. Un client compromis dans le réseau de gestion est sinon une entrée directe dans la gestion de la firewall.

Pour un accès depuis le WAN, il ne faut pas activer HTTPS/WebAdmin pour toute la zone WAN. Si un accès externe à l’API ou à l’administration est réellement nécessaire, il doit passer par une Local service ACL exception rule avec une Source strictement limitée, le Service HTTPS approprié, une position de règle définie et une durée documentée.

HA : vérifier l’accès après un failover

Dans un cluster HA, la configuration de la firewall est synchronisée du Primary vers l’Auxiliary ; le lien HA dédié et les Administration Ports ne le sont pas. Les clients API doivent donc utiliser le nom de cluster ou l’adresse d’interface partagée prévus, et ne pas dépendre sans le savoir d’une adresse d’administration propre à un nœud.

Après la configuration HA, un changement de certificat ou un failover, répéter un test de lecture et un test négatif. Contrôler la résolution DNS, le nom du certificat, l’IP source, le port admin, API access et Device Access. Un objet hôte synchronisé ne prouve pas à lui seul que l’ensemble du chemin réseau et TLS fonctionne après le changement de rôle.

Exploitation et revue

L’accès à l’API doit être régulièrement vérifié. Surtout après des migrations, des changements de prestataires, des projets d’automatisation ou des mises à niveau de la firewall, des sources anciennes restent souvent en place.

Questions de revue pertinentes :

Quels hôtes IP sont actuellement autorisés à utiliser l’accès à l’API ?
Y a-t-il des objets avec le préfixe apiconfig ?
Ces objets sont-ils encore nécessaires ?
Les noms et descriptions correspondent-ils à l’objectif réel ?
Y a-t-il des responsables documentés ?
Les accès API sont-ils pris en compte dans un processus de changement ou d’audit ?
Y a-t-il une sauvegarde actuelle avant des modifications importantes basées sur l’API ?

Avant les modifications basées sur l’API, une sauvegarde doit toujours être disponible. L’article Créer ou restaurer une sauvegarde de Sophos Firewall décrit ce à quoi il faut faire attention en matière de sauvegarde, de restauration et de compatibilité.

Erreurs typiques

API access autorisé pour tout un réseau client : Chaque client compromis dans ce réseau peut atteindre l’API.
Anciens objets apiconfig non vérifiés : Des autorisations migrées restent actives sans être remarquées.
Le compte de service utilise des droits admin complets : Un secret compromis a un rayon d’impact inutilement grand.
L’automatisation API utilise un admin soumis à MFA : Le script ou l’outil peut échouer lors d’opérations d’écriture après une mise à niveau SFOS.
Mauvais port dans l’outil : Le port HTTPS admin a été modifié, mais l’outil utilise toujours l’ancien port.
Logique REST attendue : L’outil envoie des méthodes REST au lieu d’un payload XML via HTTP POST vers APIController.
Seul le statut HTTP a été contrôlé : L’opération API réelle a échoué malgré un transport réussi. Évaluer <Response> et <Status>.
Set envoyé sans opération : SFOS traite la requête comme add alors qu’une mise à jour était prévue.
Impossible d’importer les paramètres ou jetons MFA : Le payload doit contenir l’élément vide <tokenid/>.
Impossible de supprimer un utilisateur : Dans le payload <Remove>, indiquer le nom d’utilisateur exact sous la forme <Name>username</Name>. Vérifier le compte, les dépendances, la sauvegarde et le rollback avant d’envoyer la requête.
Usage Count interprété comme une liste complète des dépendances : La statistique fournit le nombre et le nom, mais pas les règles ou profils concernés.
Live User connecté sans corrélation de session : Le nom d’utilisateur, l’adresse IP et l’adresse MAC ne correspondent pas à la session réelle, ce qui peut fausser les décisions des règles basées sur les utilisateurs.
Archive de certificats stockée sans protection : L’export API peut contenir des Private Keys et ne doit pas être placé dans Téléchargements, des tickets ou un stockage partagé.
IP temporaire d’un prestataire laissée active : L’accès externe reste possible plus longtemps que prévu.
Aucune documentation sur l’objectif : Les administrateurs suivants ne savent pas si une autorisation est encore nécessaire.
Changements API sans sauvegarde : Une automatisation défectueuse est plus difficile à annuler.

Dépannage

Si un outil n’atteint pas l’API XML, il convient de vérifier de manière structurée :

L’IP source est-elle correcte du point de vue de la firewall ?
La source est-elle autorisée en tant qu’hôte IP, plage IP ou réseau ?
Un objet apiconfig a-t-il été généré après une mise à niveau, mais non ajusté correctement ?
Device Access autorise-t-il l’accès local WebAdmin/API depuis cette zone ?
L’outil utilise-t-il la bonne adresse de firewall et le bon port HTTPS d’administration ?
Le nom d’utilisateur, le mot de passe ou le secret sont-ils corrects ?
Le compte a-t-il les droits nécessaires ?
Le compte impose-t-il le MFA, bien que l’outil ne puisse pas fournir de jeton à usage unique ?
Y a-t-il des effets de routage, NAT ou proxy entre l’outil et la firewall ?
L’accès a-t-il été intentionnellement retiré par une mesure de renforcement ?
Le test a-t-il été effectué depuis le bon système source ou seulement depuis le client d’administration ?

Si une modification de l’API a des effets inattendus, sauvegardez d’abord la dernière sauvegarde, puis vérifiez la piste d’audit, la comparaison Config Studio et les objets de la firewall concernés. En cas de problèmes de trafic en direct, le Log Viewer et le Packet Capture sont plus utiles que l’API elle-même.

Pour une opération XML refusée ou défaillante, enregistrer d’abord <Response> et <Status>. Vérifier ensuite apiparser.log, validation.log et validationError.log sous Diagnostics > Troubleshooting logs ; Sophos associe ces fichiers à la traduction et à la validation de l’API. Fichiers de service et journaux Sophos Firewall explique le filtrage et l’export. Retirer les secrets avant de partager un extrait de journal.

Liste de contrôle

Avant l’activation :

Documenter l’objectif de l’accès à l’API.
Déterminer clairement le système source.
Créer un objet hôte IP avec un nom explicite.
Vérifier le compte de service et les autorisations.
Définir consciemment le comportement MFA du compte API.
Définir le processus de sauvegarde et de retour en arrière.
Définir une méthode de test sans fuite de secret.
Documenter l’opération XML prévue et le <Status> attendu.

En fonctionnement :

Autoriser l’accès à l’API uniquement pour les sources définies.
Ne pas autoriser de réseaux clients, invités ou IoT larges.
Vérifier les objets apiconfig après les mises à niveau.
Contrôler les accès des prestataires en termes de temps et de spécialité.
Stocker les secrets de manière sécurisée et les renouveler lors de changements de personnel ou d’outils.
Effectuer une rotation des secrets s’ils ont fini dans l’historique du shell, des tickets ou des emplacements non sûrs.
Tester spécifiquement les opérations de lecture et d’écriture API après les mises à niveau SFOS.
Contrôler Object Usage et les configurations dépendantes avant les opérations update ou remove.
Valider les connexions Live User via API avec API client, la décision de règle et une déconnexion propre.
Traiter les fichiers de certificat, les Private Keys et les exports API uniquement dans des emplacements protégés.

Lors de la revue :

Vérifier régulièrement les sources API autorisées.
Retirer les hôtes IP qui ne sont plus nécessaires.
Aligner les modifications avec la piste d’audit et les tickets de changement.
Tester les processus d’automatisation après les mises à jour du firmware.

FAQ

Qu'est-ce que l'API XML de Sophos Firewall ?

L’API XML est une interface de gestion de Sophos Firewall. Les domaines d’application typiques sont l’automatisation, les intégrations, la surveillance ou les requêtes de configuration. L’interface ne doit être accessible que depuis des sources de gestion ou d’automatisation définies.

Où configure-t-on l'accès à l'API dans SFOS 22 ?

Sophos a déplacé les paramètres d’accès à l’API dans la section Administration avec SFOS 22. C’est là que l’on peut définir quels hôtes IP obtiennent l’accès à l’API.

Que signifie le préfixe apiconfig ?

Lors de la mise à niveau vers SFOS 22, la firewall convertit les adresses IP API autorisées précédemment en objets hôtes IP. Ces objets migrés sont nommés avec le préfixe apiconfig et doivent être vérifiés après la mise à niveau.

Une restriction d'IP source suffit-elle comme protection API ?

Non. La restriction d’IP source réduit les sources accessibles, mais ne remplace pas des comptes propres, des autorisations appropriées, un stockage sécurisé des secrets, des sauvegardes et une auditabilité.

Un utilisateur API devrait-il utiliser le MFA ?

Pour les administrateurs interactifs, le MFA est pertinent. Pour l’automatisation API, il faut vérifier si l’outil peut prendre en charge un jeton à usage unique. Si cela n’est pas praticable, un compte API dédié avec des droits minimaux, une restriction d’IP source stricte et un audit propre doit être utilisé.

Faut-il laisser l'accès à l'API activé en permanence ?

Seulement si un processus concret nécessite régulièrement l’API. Les accès temporaires de test ou de prestataires doivent être retirés ou désactivés après achèvement.