Gérer en toute sécurité les identifiants API Sophos Central
Sophos Central peut être automatisé par API et intégré à des plateformes SIEM, RMM, de reporting ou d’assurance. On n’utilise pas de compte administrateur personnel à cette fin, mais des API Credentials constitués d’un Client ID et d’un Client Secret.
Ces identifiants sont des identités de machine. Toute personne qui possède le secret peut exécuter les actions API autorisées par le rôle de service principal attribué. Un secret doit donc être traité comme un mot de passe privilégié et ne doit jamais se trouver dans un script, un ticket, un e-mail ou un dépôt Git.
Distinguer API Credentials et Integration Credential Manager
Sous Global Settings > Access Control, deux sections portent des noms proches :
| Section | Fonction |
|---|---|
| API Credentials | Identité technique avec laquelle une application appelle les API Sophos Central |
| Integration Credential Manager | Identifiants de produits tiers utilisés par Sophos pour des intégrations telles que Data Ingestion ou Response Actions |
Pour un script interne, une requête SIEM ou un client API, on crée des API Credentials. Les identifiants d’un produit tiers que Sophos Central doit lui-même utiliser appartiennent en revanche à l’Integration Credential Manager.
Conditions préalables et responsabilité
Seul un Super Admin peut créer et gérer des API Credentials. L’application s’authentifie ensuite indépendamment de cet administrateur personnel. Si l’administrateur est désactivé, l’identité technique subsiste jusqu’à son expiration ou sa suppression.
Avant la création, on documente la finalité, le propriétaire, le système cible, le rôle requis, la date d’expiration et le contact d’urgence. Chaque application et chaque environnement disposent de leur propre identifiant. Un secret partagé entre un script de sauvegarde, un SIEM et un prestataire externe empêche une révocation ciblée et complique l’analyse des causes.
Choisir le rôle de service principal approprié
Sophos propose plusieurs rôles :
- Service Principal Read-Only lit les données du tenant, mais ne peut ni les modifier ni exécuter de requêtes Live Discover.
- Service Principal Management peut consulter, créer, modifier et supprimer des utilisateurs et groupes d’utilisateurs, consulter et traiter des alertes, interroger les endpoints et déclencher des actions telles qu’une analyse, ainsi qu’afficher et modifier les paramètres globaux d’Endpoint Protection. Ce rôle gère aussi les administrateurs, les rôles et les Security Policies, mais n’a pas accès aux requêtes Live Discover.
- Service Principal Forensics crée, lance et supprime des requêtes Live Discover.
- Service Principal Active Directory Sync est exclusivement destiné à la synchronisation AD et ne peut effectuer aucune autre tâche API.
- Service Principal Firewall limite l’identité à l’administration des firewalls et n’autorise aucune autre tâche de l’API Central.
- Service Principal Super Admin possède des droits étendus de lecture, d’écriture et de suppression ainsi que l’accès aux requêtes.
On commence toujours par le rôle le plus limité. Une intégration de reporting ou de cyberassurance reçoit Read-Only. AD Sync reçoit le rôle prévu à cet effet. Super Admin ne s’utilise que lorsque les endpoints API documentés exigent réellement des droits d’écriture étendus et qu’aucun rôle plus restreint ne convient.
Créer un identifiant
Le chemin est Global Settings > Access Control > API Credentials. Lors du premier accès, il faut accepter les conditions d’utilisation.
- Ouvrir Add Credential.
- Saisir un nom explicite et une description indiquant l’application, l’environnement et le propriétaire.
- Sélectionner le rôle de service principal minimal nécessaire.
- Créer l’identifiant et récupérer immédiatement le Client ID et le Client Secret.
- Déposer le secret dans le coffre-fort de secrets de l’entreprise et effacer les copies temporaires.
Le Client Secret n’est affiché qu’une seule fois. Il est impossible de le révéler à nouveau par la suite. S’il est perdu, on ne restaure pas le secret existant : on crée un nouvel identifiant, puis on supprime l’ancien après une migration réussie.
Tester l’authentification de manière contrôlée
Le premier test ne doit pas être une opération d’écriture en production. On obtient d’abord un jeton d’accès OAuth auprès de l’endpoint Sophos Identity. L’endpoint whoami fournit ensuite l’ID du tenant, l’hôte API et le type de données du compte. Ce n’est qu’alors que l’on exécute une requête de lecture sans risque vers l’hôte API indiqué pour ce tenant.
L’hôte API ne doit pas être copié depuis un exemple. Sophos exploite plusieurs régions de données, il faut donc utiliser l’URL retournée par whoami. L’ID du tenant et l’ID de l’organisation ne sont pas non plus interchangeables.
Le test doit documenter au minimum les points suivants :
- l’authentification avec la nouvelle identité fonctionne ;
- le tenant attendu est retourné ;
- les opérations de lecture autorisées fonctionnent ;
- une opération interdite est rejetée avec
403 Forbidden; - les Audit Logs ou journaux d’intégration rendent le test traçable.
Gérer l’expiration et la rotation
Sophos n’envoie aucun avertissement lorsqu’un API Credential expire. Après expiration, il ne peut plus servir à l’authentification et est automatiquement supprimé de Central. La surveillance doit donc être assurée en dehors de Central.
Une rotation propre utilise une courte période de chevauchement :
- Créer un nouvel identifiant avec un rôle identique ou plus limité.
- Configurer l’application avec le Client ID et le secret du nouvel identifiant.
- Tester l’authentification et le fonctionnement métier.
- Supprimer l’ancien identifiant.
- Vérifier la modification dans l’Audit Log, le registre des secrets et la documentation d’exploitation.
L’ancien identifiant ne reste pas actif pendant des mois « par précaution ». Si une application ne prend en charge qu’un seul jeu de secrets, on planifie une fenêtre de maintenance.
Remplacer les anciens jetons de l’API SIEM
API Token Management est l’ancien mécanisme d’authentification de la SIEM Integration API. Sophos n’y délivre plus de nouveaux jetons et ne prolonge plus leur durée de validité. Les jetons existants ne fonctionnent que jusqu’à leur expiration.
Une intégration qui les utilise encore ne doit donc pas attendre le dernier jour. On inventorie le jeton, le système cible, la date d’expiration et les endpoints utilisés, puis on crée un API Credential approprié, on migre l’application et on vérifie l’ensemble du flux de données. L’ancien jeton n’est supprimé qu’après un contrôle parallèle concluant.
Le passage d’un jeton historique à des API Credentials ne constitue pas un simple changement de nom. L’intégration doit prendre en charge l’authentification OAuth, whoami, l’hôte régional et le modèle de rôles. Un connecteur SIEM se configure donc selon la documentation actuelle de son éditeur et non à l’aide d’un ancien exemple de jeton.
Prestataires externes et accès tiers
Pour un tiers, on crée une identité Service Principal Read-Only distincte lorsque des droits de lecture suffisent. Client ID et secret sont transmis par des canaux chiffrés séparés. Une date de fin est définie et l’accès est supprimé à la fin du projet.
Par API, un tel tiers peut notamment lire les alertes et événements, les résultats de l’Account Health Check, les détails des appareils et les configurations de stratégies. Read-Only empêche l’ajout, la modification et la suppression dans Central, mais ne limite pas automatiquement les données que la plateforme tierce consulte ou conserve. Avant l’autorisation, il faut donc régler contractuellement le périmètre des données, leur finalité, leur lieu de stockage, leur conservation et leur suppression.
La création suit le chemin habituel Global Settings > Access Control > API Credentials > Add Credential. Lors du premier accès, les conditions d’utilisation et de confidentialité sont acceptées. On choisit Service Principal Read-Only, puis on récupère immédiatement le Client ID et le Client Secret qui ne s’affiche qu’une seule fois. Le transfert passe par un canal chiffré approuvé, par exemple le portail HTTPS du fournisseur, jamais par e-mail ou dans le texte d’un ticket.
L’hôte API n’est pas copié d’un tableau régional statique. L’application utilise whoami pour déterminer l’hôte API valable pour ce tenant précis. L’intégration reste ainsi correctement documentée même si Sophos modifie ses régions ou endpoints. Dès que le prestataire n’a plus besoin de l’accès, l’identifiant est supprimé et l’autorisation API immédiatement révoquée.
Il est inacceptable d’exporter le compte Super Admin personnel, d’utiliser une identité API commune pour plusieurs clients ou de placer un secret dans un ticket de support. Le prestataire doit aussi indiquer où le secret est stocké, comment il est protégé et quand il sera supprimé.
Cibler la recherche d’erreurs
401 Unauthorized
Le Client ID, le secret, l’endpoint de jeton ou la requête OAuth sont généralement incorrects. Un identifiant expiré et déjà supprimé provoque aussi cette erreur. On vérifie d’abord si l’identifiant existe encore dans Central et si l’application utilise réellement le dernier jeu de secrets.
403 Forbidden
L’authentification a réussi, mais le rôle n’autorise pas l’action. Au lieu d’accorder immédiatement Super Admin, on associe l’endpoint API requis au rôle de service principal approprié.
Jeton correct, mauvaise région de données
Le jeton d’accès ne détermine pas à lui seul l’hôte API métier. L’application doit utiliser l’hôte régional retourné par whoami. Un hôte fixe d’une autre région provoque des erreurs ou des requêtes vers une mauvaise frontière de plateforme.
L’intégration tombe en panne sans avertissement
Si Central ne présente aucune alerte ouverte, on contrôle la date d’expiration, le dernier appel API réussi et la version du secret dans le système cible. La surveillance de l’expiration appartient au monitoring externe.
Contrôle régulier
Au moins chaque trimestre, on contrôle le nom, le propriétaire, le rôle, la dernière utilisation, l’expiration et le système cible de chaque identifiant. Les identités inutilisées ou sans propriétaire sont supprimées. En cas de suspicion de fuite, l’identifiant est immédiatement bloqué et remplacé, puis l’Audit Log est examiné à la recherche d’actions inhabituelles.
Les droits des administrateurs personnels sont contrôlés séparément selon Attribuer correctement les rôles d’administration Sophos Central. Les API Credentials ne remplacent ni la MFA ni un accès administrateur personnel et traçable.