Exploiter Sophos Central Integration Credential Manager
L’Integration Credential Manager gère les identifiants de produits tiers que Sophos Central utilise pour ses intégrations. Il peut par exemple s’agir de jetons API ou de comptes pour Data Ingestion et Response Actions.
Il ne faut pas le confondre avec les API Credentials. Les API Credentials permettent à une application externe d’accéder à Sophos Central. Dans Credential Manager, Sophos Central stocke au contraire des identifiants lui permettant d’accéder à un produit tiers.
Quand utiliser Credential Manager
Un identifiant y est créé lorsqu’une intégration Sophos prise en charge doit accéder à un produit externe et que ce type d’identifiant est disponible dans Central. Le gestionnaire peut réutiliser les identifiants dans plusieurs intégrations du même type et affiche leur état, leur dernière utilisation, leurs autorisations et les fonctions d’intégration ayant accès.
Il n’est pas possible d’y stocker n’importe quel type de secret. Pour les intégrations non prises en charge, le coffre-fort central de secrets de l’entreprise reste la référence.
Planifier les autorisations au préalable
Avant la création, il faut définir :
- le produit tiers et l’instance cible,
- les actions de lecture ou d’écriture autorisées,
- les fonctions Sophos pouvant accéder à l’identifiant,
- le responsable technique et le contact d’urgence,
- la date d’expiration et la procédure de renouvellement,
- la limite d’inactivité,
- le test et le retour arrière.
L’accès en écriture n’est accordé que si des Response Actions sont réellement nécessaires et également limitées dans le produit tiers. Une intégration qui ne fait que lire la télémétrie ne reçoit aucun droit de modification.
Créer un identifiant
Le chemin est Global Settings > Access Control > Integration Credential Manager. Add ouvre d’abord la page Type. Sous Credential Type, il faut sélectionner un type pris en charge, par exemple Okta API Token, puis confirmer avec Next.
Sur la page Details, il faut saisir le nom et la description, sélectionner l’autorisation Read ou Write, puis choisir sous Integrations with Access uniquement les fonctions Sophos nécessaires, par exemple Data Ingestion ou Response Action. Il est ensuite possible de définir Inactivity limit et, si ce type le permet, Expiration date. À droite, il faut confirmer l’indication sous Vendor and Product documentation and disclaimer après avoir vérifié les conséquences en matière de sécurité.
Si la case de confirmation de la clause de non-responsabilité n’a pas encore été cochée sur la page Details, Central la propose de nouveau sur la page suivante. Sans confirmation explicite, l’identifiant n’est pas autorisé pour la production ; cette boîte de dialogue supplémentaire ne remplace pas l’examen interne de l’accès au produit tiers.
Sur la page Credential, il faut saisir les valeurs demandées par le produit tiers, à savoir l’URL et l’API Token dans l’exemple Okta. Ces valeurs proviennent de la configuration du produit concerné et non d’un exemple externe. Save crée l’identifiant ; il faut ensuite contrôler l’intégration prévue, l’état et l’utilisation, puis tester le fonctionnement de l’intégration. Une intégration prise en charge peut également créer pendant sa configuration un identifiant avec des autorisations par défaut, qui sera ensuite restreint dans le gestionnaire.
Le compte externe doit lui aussi respecter le principe du moindre privilège. Une configuration restrictive dans Central ne compense pas un compte doté de privilèges excessifs dans le produit tiers.
Surveiller l’état et l’utilisation
La vue en liste affiche :
- Healthy, Partially healthy ou Unhealthy,
- un tiret à la place du symbole d’état et Awaiting usage au survol lorsqu’il n’a encore jamais été utilisé,
- Last accessed, avec la dernière utilisation et les éventuels avertissements d’inactivité,
- Used by, avec les fonctions d’intégration pouvant utiliser l’identifiant,
- le Credential type,
- les avertissements avant suspension ou purge.
Un statut vert atteste uniquement que l’utilisation technique fonctionne. Il ne confirme pas que les données arrivent intégralement ou qu’une Response Action produit le résultat fonctionnel attendu. Il faut donc vérifier l’événement de test, son horodatage et le résultat dans le système cible.
La page de détails affiche également Vendor, Vendor Identifier, Permissions et Integration Access. Usage indique le nombre de requêtes et l’heure de la dernière requête. Logs ne contient que les 250 événements les plus récents et peut être filtré par statut, type d’intégration et période. Pour assurer une traçabilité plus longue, les erreurs pertinentes doivent donc être transférées au monitoring opérationnel ou à un dossier de support avant d’être écrasées.
Modifier, suspendre ou supprimer un identifiant
Pour effectuer une modification, il faut ouvrir le nom de l’identifiant sous Global Settings > Access Control > Integration Credential Manager, puis sélectionner Actions > Edit. Central affiche les mêmes pages de configuration que lors de la création. Sur Details, il est possible de modifier le nom, la description, les autorisations, l’accès des intégrations, la limite d’inactivité et, le cas échéant, la date d’expiration ; sur Credential, les valeurs du fournisseur tiers sont remplacées. Après l’enregistrement, il faut tester l’état, l’utilisation et le fonctionnement. Used by et Integration Access indiquent des fonctions d’intégration, mais ne remplacent pas l’inventaire interne des instances concrètes à vérifier avant une modification.
Pour procéder à une suspension manuelle, il faut sélectionner l’identifiant, choisir Actions > Suspend, puis confirmer une nouvelle fois l’avertissement relatif à son utilisation. Cette opération est utile en cas de suspicion de compromission ou pour une analyse contrôlée des erreurs, mais elle interrompt l’utilisation des données et des réponses par toutes les intégrations dépendantes. Actions > Unsuspend réactive l’identifiant et réinitialise sa période d’inactivité à six mois ou à la valeur configurée individuellement.
Pour les identifiants qui ne sont plus nécessaires, il faut d’abord migrer chaque dépendance. Il faut ensuite sélectionner l’identifiant, choisir Actions > Delete et confirmer l’avertissement. La suppression ne révoque pas automatiquement le compte ou le jeton correspondant dans le produit tiers ; l’accès doit également y être supprimé ou renouvelé.
Inactivité, suspension et purge
Par défaut, un identifiant est suspendu après six mois, soit 180 jours, d’inactivité, puis définitivement purgé après un an. Sous Actions > Edit > Inactivity limit, il est par exemple possible de définir une suspension après un an et une purge après deux ans. Une modification lance immédiatement le nouveau délai et supprime les avertissements existants.
Avant de prolonger une limite d’inactivité, il faut déterminer si l’intégration est encore nécessaire. Une action d’urgence rarement déclenchée nécessite un test fonctionnel documenté, et non un secret simplement illimité.
Central avertit 90 jours avant la suspension. Avant une purge, des avertissements sont envoyés 90, 60, 30 et 7 jours à l’avance. Des règles d’alerte par e-mail pour Credential Manager doivent être configurées. Un Super Admin ouvre Global Settings > Platform > Notification Settings > Configure Email Alerts et vérifie les destinataires, la fréquence et les types d’alerte. L’activation de la première Custom Rule désactive les paramètres de destinataires existants ; les administrateurs et listes de diffusion nécessaires doivent donc figurer explicitement dans une règle adaptée.
Actions > Reset inactivity limit réinitialise la période d’inactivité restante à six mois ou à la valeur configurée. Actions > Unsuspend réactive un identifiant suspendu et réinitialise la même période. Il faut auparavant vérifier le secret externe, les autorisations et les intégrations dépendantes ; une réactivation ne répare pas un jeton expiré ou révoqué.
Une suspension manuelle interrompt le transfert de données de toutes les intégrations utilisatrices. Une purge ou une suppression peut interrompre durablement plusieurs intégrations si l’identifiant est réutilisé.
Remplacer les valeurs d’un identifiant de manière contrôlée
Credential Manager ne renouvelle pas lui-même un secret dans le produit tiers. Si le fournisseur permet son remplacement, il faut coordonner sa procédure documentée avec la mise à jour dans Central pendant une fenêtre de maintenance :
- Recenser les instances d’intégration concrètes, Used by, Integration Access et la dernière utilisation.
- Préparer une valeur de remplacement conformément à la documentation du produit tiers.
- Mettre à jour l’identifiant dans Central via Actions > Edit.
- Vérifier l’état, l’utilisation et les fonctions d’intégration concernées.
- Ne révoquer l’ancienne valeur qu’après une vérification réussie et conformément à la procédure du fournisseur.
- Contrôler les journaux d’audit et d’intégration.
Seul le produit tiers détermine si l’ancienne et la nouvelle valeur peuvent coexister. Si ce chevauchement n’est pas documenté, il ne faut pas promettre un changement sans interruption, mais planifier et surveiller une éventuelle coupure.
Problèmes courants
Le statut reste Awaiting usage
L’identifiant n’est encore attribué à aucune intégration active, l’intégration n’a encore exécuté aucune opération ou le mauvais jeu d’identifiants a été sélectionné. Il faut vérifier l’attribution et l’événement de test.
L’identifiant est sain, mais des données manquent
Il faut contrôler la période, la source de données, l’intégration, les filtres et les autorisations dans le produit tiers. L’état ne confirme pas chaque volume de données attendu.
Une modification interrompt plusieurs intégrations
L’identifiant est réutilisé. Used by fournit une première indication du périmètre ; il faut aussi recenser dans l’inventaire interne toutes les instances d’intégration concrètes et les tester ensemble.
La suppression signale une utilisation possible
L’avertissement ne doit pas être ignoré. Il faut d’abord migrer ou supprimer toutes les intégrations associées, puis supprimer l’identifiant.