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 la section Administration, 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.
• 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 à l’API doit être traité selon le même principe que WebAdmin ou SSH : aussi restreint que possible, aussi large que nécessaire.

Sources pertinentes, par exemple :

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

Sources non pertinentes :

• réseaux clients entiers,
• réseaux invités ou IoT,
• Any,
• autorisations “réseau serveur complet” peu claires,
• adresses IP de test temporaires qui sont ensuite oubliées.

Si des prestataires externes ont besoin d’un accès à l’API, la source doit être définie aussi spécifiquement que possible. De plus, il doit être documenté à quoi sert l’accès et quand il sera retiré.

Procédure recommandée

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

Procédure pratique :

1. Vérifier quel système a besoin d’un accès à l’API.
2. Créer un objet hôte IP unique pour ce système.
3. Si plusieurs sources sont nécessaires, nommer proprement les hôtes IP ou les réseaux.
4. Autoriser l’accès à l’API uniquement pour ces objets.
5. Ne pas inscrire de réseaux clients ou serveurs larges.
6. Tester l’accès avec l’outil concerné.
7. Retirer les sources qui ne sont plus nécessaires.
8. Documenter le changement dans le processus de changement.

Pour les installations existantes après une mise à niveau vers SFOS 22, il est également conseillé de rechercher des objets avec le préfixe apiconfig. Ces objets ont été générés à partir d’anciennes entrées d’autorisation API et doivent être vérifiés, nommés ou nettoyés.

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.

MFA et utilisateurs API après SFOS 22

Le MFA est important pour les accès administratifs interactifs. Pour les processus API et d’automatisation, il faut planifier consciemment comment l’authentification doit fonctionner. Un script, un outil de surveillance ou un système d’intégration ne peut pas facilement entrer un code OTP si l’utilisateur utilisé impose le MFA.

Un cas particulier de SFOS 22 est documenté dans la liste des problèmes connus : après une mise à niveau, les modifications de configuration basées sur l’API peuvent échouer pour les utilisateurs migrés si le MFA est actif et qu’aucun jeton à usage unique n’est fourni. Les utilisateurs non migrés peuvent se comporter différemment dans certains cas. Pour le fonctionnement, il est important de ne pas en faire un “MFA désactivé partout” désordonné, mais de séparer proprement les comptes API.

Approche recommandée :

1. Utiliser un compte de service dédié pour les processus API.
2. Doter le compte uniquement des droits nécessaires.
3. Limiter l’accès à l’API à des hôtes IP fixes ou des réseaux de gestion.
4. Vérifier si le MFA est techniquement et opérationnellement pertinent pour ce compte.
5. Si le MFA n’est pas praticable pour le compte API, contrôler particulièrement étroitement la source, les droits, le stockage des secrets et la piste d’audit.
6. Après une mise à niveau SFOS 22, tester tous les processus API avec des opérations de lecture et d’écriture.

⚠️ Les utilisateurs API sans MFA ne sont pas un laissez-passer pour des droits étendus. Si un compte API est exploité sans MFA pour des raisons techniques, la source IP, les droits, le stockage des mots de passe, la responsabilité et l’auditabilité doivent être contrôlés de manière plus stricte.

Ce point est particulièrement important pour les automatisations qui ne se contentent pas de lire, mais modifient la configuration. Avant les modifications API en production, une sauvegarde actuelle de Sophos Firewall doit être disponible. Pour les modifications de masse préparées à partir de Sophos Firewall Config Studio, il convient également de vérifier si 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. 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 quant à eux l’accès à l’interface de gestion de l’API XML.

Cependant, les deux sujets font partie du renforcement de la gestion. Chaque couche limite une partie différente de la surface d’attaque :

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

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. L’outil utilise-t-il la bonne adresse et le bon port de la firewall ?
5. Le nom d’utilisateur, le mot de passe ou le secret sont-ils corrects ?
6. Le compte a-t-il les droits nécessaires ?
7. Le compte impose-t-il le MFA, bien que l’outil ne puisse pas fournir de jeton à usage unique ?
8. Y a-t-il des effets de routage, NAT ou proxy entre l’outil et la firewall ?
9. L’accès a-t-il été intentionnellement retiré par une mesure de renforcement ?

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.

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