Sécurité externe multi-entités : comment structurer le pilotage à l’échelle d’un groupe

Dans un grand groupe, la sécurité externe ne se pilote pas toujours à l’échelle du groupe.

Filiales, business units, acquisitions, directions régionales : chaque entité dispose souvent de son propre périmètre, de ses propres utilisateurs et de ses propres ressources de sécurité. L’équipe cybersécurité centrale, elle, reste responsable de la vision globale, mais dépend encore largement des équipes locales pour faire évoluer les configurations et les droits.

Cette organisation fonctionne tant que le groupe reste stable. Elle devient beaucoup plus complexe dès qu'il faut réorganiser, intégrer une nouvelle entité ou redistribuer des ressources.

Prenons un groupe qui vient d’acquérir une nouvelle société.

Il faut intégrer ses actifs dans le dispositif de sécurité externe, créer les comptes des équipes concernées, définir leur périmètre d'accès et s'assurer que les données de cette nouvelle organisation restent isolées de celles des autres filiales.

Sur le papier, rien de complexe. Dans la pratique, lorsque l'administration est entièrement décentralisée, chaque étape peut nécessiter des demandes spécifiques, des validations et des interventions manuelles.

Même problème lorsqu'une ressource de Pentest doit être réaffectée.

Une filiale n'utilise plus une partie de son quota tandis qu'une autre doit lancer une nouvelle campagne. Si les ressources sont cloisonnées sans mécanisme de redistribution, l'équipe centrale doit arbitrer entre des enveloppes qui ne reflètent plus les besoins réels du groupe.

Autre cas fréquent : un utilisateur change de périmètre. Il passe d'une filiale à une autre, rejoint une équipe transverse ou prend des responsabilités au niveau groupe. Ses droits doivent alors évoluer avec son rôle, sans lui donner accès aux données des organisations qui ne relèvent plus de son périmètre.

Ces situations sont banales. C'est leur répétition qui devient problématique.

Le principal problème n'est pas nécessairement technique. Il est organisationnel.

À chaque décision prise par l'équipe centrale correspond une série d'actions à exécuter dans les différents périmètres. Le délai entre « nous avons décidé » et « c'est effectivement configuré » peut alors s'allonger.

Pour l'équipe centrale, cela représente aussi une charge cognitive importante : suivre les demandes, vérifier les droits, contrôler les ressources disponibles, relancer les équipes locales et s'assurer que la configuration correspond toujours à l'organisation réelle du groupe.

À mesure que le nombre d'entités augmente, le risque de désalignement augmente lui aussi.

Une acquisition peut être opérationnelle depuis plusieurs mois sans que son périmètre de sécurité externe soit correctement intégré. Un collaborateur peut conserver des droits devenus inutiles. Une ressource peut rester inutilisée dans une organisation alors qu'une autre en aurait besoin.

La difficulté n'est donc plus seulement de sécuriser chaque entité, mais de maintenir une gouvernance cohérente entre toutes.

Une administration centralisée permet de déplacer le point de contrôle au niveau du groupe, sans supprimer l'autonomie des différentes organisations.

Lorsqu'une nouvelle filiale rejoint le périmètre, l'administrateur central peut structurer son environnement, gérer ses utilisateurs et définir les accès associés, sans multiplier les interventions externes.

Lorsqu'un utilisateur change d'organisation, son périmètre peut être réaffecté directement. L'objectif est simple : ses droits suivent son rôle et son organisation, plutôt que de rester attachés à une ancienne configuration.

La gestion des ressources peut également être pensée à l'échelle du groupe. Lorsqu'une organisation ne consomme pas l'intégralité de ses ressources, celles-ci peuvent être redistribuées selon les règles définies au niveau central. Le groupe gagne ainsi en flexibilité sans perdre sa capacité de contrôle.

Mais centraliser ne signifie pas tout rendre visible à tout le monde.

C'est même l'un des points essentiels d'une architecture adaptée aux grands comptes : l'isolation stricte des données par entité.

Chaque organisation doit conserver son propre périmètre, ses actifs, ses utilisateurs et ses résultats, tandis que l'administration centrale dispose de la visibilité et des capacités de pilotage nécessaires à l'échelle du groupe.

Cette séparation répond également à un enjeu de conformité. Dans un contexte NIS2 ou DORA, les organisations doivent pouvoir démontrer qu'elles maîtrisent leurs actifs, leurs accès et leurs responsabilités. Une isolation claire entre entités permet notamment de mieux matérialiser cette gouvernance lors d'un audit.

À l'échelle d'un grand groupe, la question n'est finalement pas de choisir entre centralisation et autonomie.

Il s'agit de construire un modèle où les deux peuvent fonctionner ensemble.

Les équipes locales conservent leur périmètre opérationnel. L'équipe centrale dispose, elle, d'un niveau d'administration permettant de piloter les organisations, les utilisateurs et les ressources sans dépendre systématiquement d'interventions externes.

C'est précisément le rôle du Tenant Administrator de Patrowl : donner à l'organisation centrale les moyens de gérer son portefeuille d'entités tout en garantissant une isolation stricte des données et des périmètres.

L'enjeu dépasse donc la simple administration d'une plateforme. Il s'agit de passer d'une sécurité externe gérée entité par entité à un véritable pilotage centralisé de la surface d'attaque externe du groupe.

À mesure que les organisations grandissent, se transforment et acquièrent de nouvelles entités, cette capacité devient un levier essentiel pour conserver une vision cohérente de l'exposition externe, sans sacrifier la granularité nécessaire au terrain.