Connecteurs IA du SOC : vérifier quelle identité agit vraiment
Auditez les identités et permissions effectives des connecteurs IA : accès délégué, compte de service, périmètre utilisateur et révocation.
Périmètre des intégrations : Seculogik utilise une architecture indépendante des sources pour ingérer les alertes et événements de sécurité via son propre modèle de données. Wazuh et OpenSearch sont les premières intégrations. Les autres sources citées correspondent à des connecteurs prévus ; leur disponibilité doit être confirmée pour chaque évaluation.
Un connecteur disponible dans l’interface d’un assistant ne décrit pas, à lui seul, les données accessibles. Pour comprendre son périmètre réel, il faut identifier l’identité présentée au système cible et les règles que ce dernier applique à chaque demande.
La documentation de Microsoft Security Copilot fournit un exemple concret : ses intégrations Microsoft utilisent un mécanisme d’authentification pour le compte de l’utilisateur. D’autres architectures peuvent s’appuyer sur une identité applicative ou un compte de service.
Chaque scénario demande une vérification spécifique. Source : Microsoft, Plugins overview.
La revue commence avec quatre questions : qui installe le connecteur, qui peut l’utiliser, sous quelle identité il fonctionne et quels objets cette identité peut consulter ou modifier ? Les réponses peuvent relever de consoles différentes.
Un contrôle dans l’assistant ne remplace pas la vérification des droits dans la plateforme source.
Construisez ensuite une matrice de test à partir des rôles réels du SOC. Un analyste junior, un responsable d’incident et un prestataire externe ne doivent pas nécessairement obtenir les mêmes résultats.
Testez les objets permis, mais aussi un dossier hors périmètre et un objet dont l’accès vient d’être retiré.
Les environnements multi-clients demandent une vigilance supplémentaire. L’identifiant d’organisation doit être attaché au parcours et contrôlé au niveau approprié. Une sélection dans l’interface ne devrait pas être la seule barrière entre les données de deux clients.
Il faut également vérifier la révocation. Après un retrait de droits, que devient une session déjà ouverte ? Les résultats précédemment mis en cache restent-ils visibles ? Une tâche en cours poursuit-elle ses appels ?
Les réponses dépendent de l’architecture et doivent être établies par des tests documentés.
La gestion du catalogue compte aussi. Un connecteur ajouté pour un essai peut rester activé après la fin du besoin. Associez chaque intégration à un propriétaire, un usage approuvé et une date de revue.
Lorsqu’une mise à jour apporte de nouvelles fonctions, examinez leur portée avant de les rendre disponibles largement.
Enfin, consignez les limitations constatées. Si un connecteur ne permet pas le niveau de séparation attendu, l’équipe doit pouvoir choisir un périmètre réduit ou reporter l’usage. Une contrainte connue est plus facile à gérer qu’une permission supposée.
Un atelier avec Seculogik peut se concentrer sur un connecteur critique et deux profils utilisateurs. Cette approche permet de vérifier les droits effectifs, les frontières entre environnements et le retrait d’accès avant d’étendre le dispositif.