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

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 :

1. Vérifier quel système a besoin d’un accès API.
2. Sous Hosts and services > IP host, créer un objet IP Host explicite pour ce système.
3. Si plusieurs sources sont nécessaires, nommer proprement les IP Hosts, IP ranges ou réseaux.
4. Sous Administration > API access, activer API access.
5. Sous Allowed IP hosts, autoriser uniquement ces objets.
6. Cliquer sur Apply.
7. Ne pas ajouter de grands réseaux clients ou serveurs.
8. Tester l’accès depuis le véritable hôte d’automatisation ou de monitoring, pas depuis le notebook admin.
9. Supprimer les sources qui ne sont plus nécessaires.
10. 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.

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

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

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

Sophos prend en charge les API officielles et les scripts d’exemple non modifiés. Les intégrations, wrappers et automatisations propres ont tout de même 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 documente un cas particulier de SFOS 22 : après une mise à niveau, les changements de configuration via API peuvent échouer pour des utilisateurs migrés lorsque la MFA est active et qu’aucun one-time token n’est transmis. Les utilisateurs non migrés peuvent se comporter différemment dans certains cas. Pour l’exploitation, l’important n’est pas de désactiver la MFA partout, mais de séparer proprement les comptes API.

Approche recommandée :

1. Utiliser un compte de service dédié pour les processus API.
2. N’accorder à ce compte que les droits nécessaires.
3. Limiter en plus API access à des IP Hosts fixes ou à des réseaux de management.
4. Vérifier si la MFA est techniquement et opérationnellement pertinente pour ce compte.
5. 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.
6. 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.

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

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

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.

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.

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