Pourquoi la gestion des identités est devenue existentielle pour les MSP
La gestion des identités est devenue cruciale pour les fournisseurs de services gérés (MSP), car un petit nombre d'identités d'ingénieurs et d'outils permettent désormais d'accéder simultanément à de nombreux comptes clients. Chaque compte mal géré représente ainsi un risque potentiel d'incident multi-clients. Si vous ne pouvez pas démontrer que chaque identité et privilège est justifié, approprié et facile à révoquer, vos clients, vos auditeurs et votre propre direction considéreront cela comme un risque systémique critique plutôt que comme un simple détail opérationnel.
Ces informations sont de nature générale et ne constituent pas un avis juridique ou réglementaire.
L'identité est désormais la porte d'entrée de chaque client locataire.
L'identité est désormais la porte d'entrée de chaque client, car presque toutes les actions de vos ingénieurs ou de vos outils passent par un compte, un rôle ou un jeton. Lorsque ces identités sont partagées par plusieurs clients, une conception inadéquate ou une gouvernance insuffisante transforment chacune d'elles en un point d'entrée potentiel vers de nombreux environnements clients simultanément.
Pour un fournisseur de services gérés (MSP), l'identité a de facto remplacé le périmètre réseau traditionnel, car la quasi-totalité des actions chez un client transite désormais par un compte, un rôle ou un jeton pouvant franchir les limites des locataires. Les analyses indépendantes des risques liés au cloud et aux fournisseurs, telles que les recommandations européennes en matière de sécurité des réseaux et de l'information concernant les menaces « inside the cloud », soulignent également comment l'identité et les chemins d'accès sont devenus la principale surface de contrôle dans les environnements mutualisés.
Dans les anciens modèles, davantage axés sur le périmètre, on pouvait se rassurer en se disant qu'un VPN, une règle de pare-feu et une petite équipe d'ingénieurs « de confiance » garantissaient la sécurité. Aujourd'hui, les plateformes cloud, le télétravail et les plans de gestion partagés facilitent le déploiement à grande échelle, mais impliquent également que chaque privilège supplémentaire détenu par une équipe dans un environnement donné peut accroître l'exposition aux risques dans plusieurs autres. L'ajout de l'annexe A.5.16 de la norme ISO 27001:2022, qui érige la gestion des identités en contrôle explicite, accentue encore ce changement : la norme associée ISO/IEC 27002:2022 introduit A.5.16 comme un contrôle de gestion des identités autonome, soulignant explicitement la nécessité de traiter les identités et leur cycle de vie comme des éléments de sécurité à part entière, et non comme de simples détails d'implémentation.
Lorsque la conception de l'identité visuelle est en retard par rapport à la croissance, le risque se développe en catimini.
Les clients ont également constaté cette évolution. Les acheteurs soucieux de la sécurité posent désormais des questions précises sur les membres du personnel des fournisseurs de services gérés (MSP) qui peuvent accéder à leurs systèmes, sur la manière dont ces comptes sont créés et supprimés, et sur les mesures prises pour éviter qu'un incident survenant chez un client ne se propage à d'autres. Le contrôle des identités n'est plus une simple question de bonnes pratiques ; il devient rapidement un prérequis pour conquérir et fidéliser les clients sensibles à la norme ISO 27001 ou à des référentiels similaires.
Pourquoi les clients et les auditeurs ont commencé à s'en préoccuper
Les clients et les auditeurs accordent une grande importance à la gestion des identités, car les comptes de vos ingénieurs sont essentiels à leur chaîne d'approvisionnement et peuvent impacter directement la confidentialité, l'intégrité et la disponibilité de leurs systèmes et données. Si ces identités sont mal contrôlées, tout incident survenant dans votre environnement peut rapidement devenir un incident pour eux, quel que soit le lieu de la compromission initiale.
Du point de vue de votre client, vous faites partie intégrante de son environnement étendu. Si un attaquant compromet l'un de vos comptes d'ingénieur et l'utilise pour manipuler son locataire, l'impact est très concret pour lui, même si la première intrusion a eu lieu dans vos systèmes. C'est pourquoi de nombreux régulateurs et assureurs considèrent désormais l'accès des fournisseurs de services gérés (MSP) comme un risque majeur plutôt que comme un simple détail technique. Par exemple, les recommandations relatives aux tiers et à l'externalisation dans le secteur financier, telles que les lignes directrices de l'Autorité bancaire européenne (ABE), définissent explicitement l'accès et la gouvernance des fournisseurs comme un risque opérationnel important nécessitant l'attention du conseil d'administration.
Dans l'enquête 2025 d'ISMS.online sur l'état de la sécurité de l'information, environ 41 % des organisations ont cité la gestion des risques liés aux tiers et le suivi de la conformité des fournisseurs comme un défi majeur en matière de sécurité.
Les équipes d'audit ont suivi la même voie. Alors que les audits ISO 27001 précédents se concentraient principalement sur les listes d'utilisateurs internes et quelques revues d'accès, la section A.5.16 encourage les auditeurs à poser des questions plus précises. Ils souhaitent savoir si chaque identité de fournisseur de services gérés (MSP) est unique, si vous pouvez retracer qui a approuvé son accès à chaque locataire, à quelle vitesse vous supprimez les accès lorsque des utilisateurs quittent l'entreprise et si vous révisez périodiquement les privilèges par rapport aux rôles actuels. Les guides d'accréditation et de certification pour la norme ISO/IEC 27001, tels que les documents de l'IAF sur les audits ISO/IEC 27001, renforcent cette priorité accordée à la traçabilité, à l'unicité et à la solidité des preuves concernant les contrôles d'identité.
C’est pourquoi la question de l’identité est devenue un sujet de discussion incontournable lors des ventes et des renouvellements de contrats. Les grands comptes potentiels demandent souvent une description détaillée de votre modèle de gouvernance des identités avant de signer. Les clients existants peuvent exiger des garanties quant à la suppression des comptes d’administration partagés ou au renforcement des contrôles d’accès existants. Si vous pouvez répondre avec assurance et fournir des preuves structurées, l’identité devient un gage de confiance. Dans le cas contraire, elle devient une source récurrente de tensions et de retards.
Les avantages commerciaux d'une identité bien définie
Bien gérer l'identité ne se contente pas de réduire les risques ; cela crée également des avantages commerciaux en rendant votre service plus fiable, plus facile à déployer et plus facile à expliquer aux décideurs non techniques. Lorsque l'identité est un outil de contrôle dynamique plutôt qu'un enchevêtrement opaque de comptes, vous pouvez l'intégrer à votre proposition de valeur au lieu de compter sur le fait que vous espérez que les clients ne poseront pas de questions à ce sujet.
L'enquête 2025 d'ISMS.online indique que les clients attendent de plus en plus des fournisseurs qu'ils s'alignent sur des cadres formels tels que l'ISO 27001, l'ISO 27701, le RGPD, Cyber Essentials, SOC 2 et les normes émergentes en matière d'IA.
Il est facile de considérer tout cela comme une simple contrainte de conformité, mais les fournisseurs de services gérés (MSP) qui intègrent la norme A.5.16 comme un défi de conception plutôt que comme une simple exigence d'audit sont mieux placés pour en tirer des avantages concrets. Un modèle d'identité clair et standardisé pour l'ensemble des utilisateurs facilite l'intégration des nouveaux techniciens, réduit le temps consacré à la résolution des problèmes d'accès et fournit aux équipes commerciales des arguments solides lorsqu'on leur demande pourquoi elles devraient être autorisées à gérer des systèmes critiques, même si les gains précis varient d'une organisation à l'autre.
Lorsque vous pouvez présenter votre catalogue de rôles, expliquer comment nous l'attribuons aux différents locataires, comment nous gérons les accès en cas de changement de rôle et comment nous procédons aux contrôles, vous ne vous contentez plus de négocier sur le prix. Vous offrez une garantie. Une plateforme comme ISMS.online vous permet de présenter et de démontrer ce modèle de manière compréhensible par vos clients et auditeurs, sans pour autant vous contraindre à devenir un expert en normes à temps plein. L'identité devient alors un sujet que vous pouvez aborder avec sérénité et confiance.
Demander demoCe que la norme ISO 27001:2022 A.5.16 exige réellement
La norme ISO 27001:2022 A.5.16 exige que vous démontriez que chaque identité concernée est créée intentionnellement, se voit attribuer les droits appropriés, est régulièrement vérifiée et supprimée sans délai lorsqu'elle n'est plus nécessaire, et non pas créée par habitude ou par commodité. Pour les fournisseurs de services gérés (MSP), cette rigueur doit s'appliquer de manière cohérente à l'ensemble de leurs systèmes internes et à tous les comptes clients pertinents accessibles par leur personnel ou leurs outils, et non pas seulement aux systèmes dont ils sont propriétaires. Le texte de contrôle associé à la norme ISO/IEC 27002:2022 A.5.16 le précise en exigeant des politiques et des processus régissant l'identification, l'attribution et la gestion du cycle de vie des identités utilisées pour accéder aux informations et aux services.
Au fond, la norme A.5.16 vous demande de prouver que les identités et leurs droits d'accès associés sont gérés de manière systématique tout au long de leur cycle de vie. Pour un fournisseur de services gérés (MSP), cela signifie dépasser la création de comptes ad hoc ou les approches du type « donnez-leur ce dont ils ont besoin pour le moment » et définir des règles claires concernant la création, la modification, la vérification et la suppression des identités dans tous les environnements utilisés. Inutile d'être un expert ISO : il vous suffit d'une méthode de gestion des identités reproductible et compréhensible par les auditeurs et les clients.
Dans le sondage 2025 d'ISMS.online, la quasi-totalité des organisations ont déclaré que l'obtention ou le maintien de certifications de sécurité telles que l'ISO 27001 ou le SOC 2 constituait une priorité absolue.
Les obligations fondamentales énoncées au point A.5.16
L'article A.5.16 se traduit par un ensemble restreint d'obligations concrètes, simples à décrire mais exigeantes à mettre en œuvre de manière cohérente auprès de plusieurs clients. Pour les fournisseurs de services gérés (MSP), ces obligations doivent s'étendre au-delà des systèmes internes et englober tous les points d'accès de leurs équipes et outils aux environnements clients, y compris les consoles cloud et les plateformes de gestion.
Si l'on réduit l'article A.5.16 à l'essentiel, quatre obligations se dégagent :
- Veillez à ce que chaque identité pouvant accéder aux informations ou systèmes concernés soit unique et puisse être rattachée à une personne ou une fonction réelle.
- Chaque identité doit être enregistrée, approuvée et créée selon un processus défini avant que l'accès ne soit accordé pour la première fois.
- Attribuer les droits d'accès en fonction des rôles documentés ou des besoins de l'entreprise, plutôt que des habitudes ou des préférences individuelles.
- Réviser les identités et les droits selon un cycle planifié, en les ajustant ou en les révoquant lorsqu'ils ne sont plus appropriés.
Pour un fournisseur de services gérés (MSP), cela ne se limite pas à votre environnement Microsoft 365 interne ni à votre système de gestion des tickets. Cela inclut les comptes et les rôles utilisés par votre personnel au sein de chaque environnement client, les comptes de service dont dépendent vos outils, et même les identités génériques ou partagées que vous pourriez encore utiliser pour des raisons historiques. La norme A.5.16 n'interdit pas nécessairement les comptes non personnels, mais elle exige que, lorsqu'ils existent, leur utilisation soit minimisée, strictement contrôlée et entièrement traçable. Les commentaires pratiques de la norme ISO 27002, tels que les recommandations communautaires sur l'ISO/IEC 27002, soulignent que les comptes de service ou partagés sont acceptables lorsqu'ils sont clairement justifiés, encadrés et auditables.
D'un point de vue pratique, vous devez pouvoir répondre à des questions telles que : « Qui a demandé cet accès ? Qui l'a approuvé ? Quand a-t-il été accordé ? Qu'autorise-t-il ? Et quand a-t-il été révisé pour la dernière fois ? » C'est un critère plus exigeant que « nous avons une liste d'utilisateurs », mais c'est aussi le genre de critère qui permet à vos clients de dormir sur leurs deux oreilles.
Comment le point A.5.16 se rapporte aux autres contrôles de la norme ISO 27001
Comprendre le lien entre la section A.5.16 et les contrôles connexes facilite grandement la conception d'un système cohérent conforme aux exigences des auditeurs, sans duplication des efforts. Pour les fournisseurs de services gérés (MSP), les liens les plus importants concernent les sections A.5.17, A.5.18 et A.8.2, qui traitent respectivement des informations d'authentification, des droits d'accès et des comptes à privilèges.
La gestion des identités ne peut être traitée isolément. Le point A.5.16 est étroitement lié à plusieurs autres contrôles de la révision 2022 de la norme ISO 27001, et les auditeurs les examinent souvent conjointement. Le point A.5.17 (informations d'authentification) porte sur la protection des mots de passe, jetons, clés et autres authentificateurs. Le point A.5.18 (droits d'accès) traite de l'octroi, de la modification et de la révocation des droits d'accès. Le point A.8.2 s'intéresse plus particulièrement aux droits d'accès privilégiés, tels que les comptes d'administrateur ou les comptes racine. Les recommandations de correspondance et les descriptions des contrôles de la norme ISO 27002, y compris celles résumées dans les recueils indépendants de la norme ISO 27002, considèrent ces domaines comme des aspects distincts mais coordonnés du contrôle d'accès.
On peut considérer ce groupe de contrôles comme suit : A.5.16 répond à la question « Qui est présent dans le système et quelles sont les actions autorisées ? », A.5.17 à la question « Comment vérifier l’identité de l’utilisateur lors de sa connexion ? », et A.8.2 à la question « Comment assurer une protection particulière aux comptes les plus puissants ? ». Concevoir un modèle d’identité mutualisé revient à définir concrètement le fonctionnement de ces trois mécanismes de contrôle pour vos ingénieurs et vos outils.
Comprendre ces relations vous permet d'éviter les doublons et les lacunes. Par exemple, si vous adoptez un accès privilégié juste-à-temps pour les ingénieurs, vous gérez simultanément le cycle de vie des identités (A.5.16), l'octroi des accès (A.5.18), les droits d'accès privilégiés (A.8.2) et la protection par authentificateur (A.5.17). Plus vous démontrerez clairement comment vos pratiques répondent à ces exigences, plus les audits et les échanges avec les clients seront facilités.
Qui et quoi est concerné par la gestion des identités
La section A.5.16 s'applique à toute identité susceptible d'influencer les informations ou les services concernés, que le compte appartienne techniquement à votre organisation ou à un client. Pour les fournisseurs de services gérés (MSP), le périmètre doit couvrir le personnel interne, les outils et l'automatisation de tous les locataires concernés, et non se limiter à une poignée d'« utilisateurs internes ».
Une erreur fréquente consiste à croire que la section A.5.16 ne concerne que les comptes employés dans les systèmes dont vous êtes propriétaire. Pour un fournisseur de services gérés (MSP), cette définition est bien trop restrictive. Toute identité utilisée par votre organisation et susceptible d'influencer les informations ou les services au sein de votre système de gestion de la sécurité de l'information doit être prise en compte, que le compte vous appartienne techniquement ou non, ou qu'il appartienne à un client.
Cela inclut les comptes d'ingénieurs nommés au sein des environnements cloud clients, les rôles délégués attribués à vos identités d'entreprise, les comptes de service utilisés par les outils de sauvegarde ou de surveillance, ainsi que les identités d'automatisation utilisées par les scripts ou les plateformes d'intégration. Cela inclut également les comptes partagés ou génériques qui peuvent encore exister dans les configurations existantes. Même si vous prévoyez de les supprimer progressivement, vous devez les considérer comme faisant partie du périmètre jusqu'à leur suppression définitive.
Plus vous définirez précisément ce périmètre en amont, moins vous risquerez d'être surpris ultérieurement lorsqu'un auditeur ou un client vous interrogera sur une catégorie de comptes que vous n'aviez pas envisagée. Un périmètre clairement défini facilite également le choix des domaines où investir dans l'automatisation et de ceux où vous pouvez vous appuyer en toute sécurité sur des processus manuels bien maîtrisés.
La norme ISO 27001 simplifiée
Une avance de 81 % dès le premier jour
Nous avons fait le plus gros du travail pour vous, en vous offrant une avance de 81 % dès votre connexion. Il ne vous reste plus qu'à remplir les champs.
Repenser l'application de la norme A.5.16 à la réalité des MSP multi-locataires
Repenser le point A.5.16 pour l'adapter à la réalité des MSP mutualisés implique de considérer les risques liés à l'impact inter-locataires et à la chaîne d'approvisionnement partagée comme des problèmes de conception majeurs. Votre interprétation de ce contrôle doit tenir compte du fait qu'une seule identité peut s'étendre à plusieurs environnements clients et, par conséquent, présenter un risque systémique plus important que dans une entreprise mono-locataire.
Une fois la formulation officielle de la section A.5.16 comprise, l'étape suivante consiste à la réinterpréter dans le contexte d'un fournisseur intervenant dans de nombreux environnements clients. Les risques et les responsabilités diffèrent lorsqu'une seule de vos identités vous permet d'accéder à plusieurs clients en un seul clic, et votre modèle d'identité doit refléter cette différence d'échelle et d'impact.
Comprendre le profil de risque multi-locataires des fournisseurs de services gérés
Le profil de risque d'un fournisseur de services gérés (MSP) est défini par la possibilité qu'une seule identité d'ingénieur ou un seul compte d'outil soit utilisé à mauvais escient pour accéder simultanément à de nombreux comptes clients, et non pas seulement pour nuire à une organisation à la fois. De ce fait, la portée de l'attaque et l'exposition partagée constituent les questions fondamentales auxquelles votre conception d'identité doit répondre, et non une préoccupation secondaire.
La plupart des organisations interrogées dans le cadre de l'enquête 2025 d'ISMS.online ont déclaré avoir déjà été touchées par au moins un incident de sécurité lié à un tiers ou à un fournisseur au cours de l'année écoulée.
Dans une entreprise traditionnelle mono-locataire, l'impact d'un compte administrateur compromis reste généralement limité à une seule organisation. Chez un fournisseur de services gérés (MSP), l'identité d'un ingénieur compromise peut, dans certains modèles de service, conférer des droits à des dizaines, voire plus, de clients, notamment si l'on a toujours privilégié la simplicité d'utilisation à une séparation stricte des comptes. Les analyses d'attaques ciblant la chaîne d'approvisionnement des MSP, telles que les études de cas publiées sur les compromissions visant les MSP, montrent comment l'utilisation abusive des identifiants d'un fournisseur peut se propager simultanément à de nombreux environnements clients.
Repenser la norme A.5.16 dans ce contexte implique de raisonner en termes de portée des dégâts et d'exposition partagée. Il est essentiel de savoir quelles identités peuvent franchir les limites des locataires, quels sont leurs droits d'accès dans chaque environnement et comment empêcher qu'une défaillance locale ne se propage. Cela inclut d'examiner comment vos propres locataires cloud, outils de gestion et infrastructure sur site pourraient servir de tremplin vers les clients si un attaquant prenait le contrôle.
Cela vous oblige également à revoir vos pratiques informelles. Les comptes « administrateur MSP » partagés, les profils VPN obsolètes réutilisés entre clients ou les exceptions non documentées pour certains ingénieurs peuvent tous compromettre l’identité claire exigée par la norme A.5.16. Mettre au jour ces problèmes sans chercher de coupable est la première étape vers la conception d’un système plus robuste.
Clarification de la propriété des identités entre les fournisseurs de services gérés, les clients et les fournisseurs de services.
Il est essentiel de clarifier la propriété des identités entre les fournisseurs de services gérés (MSP), les clients et les fournisseurs, car la norme A.5.16 exige que vous sachiez qui approuve les accès, qui gère les comptes et qui est responsable en cas d'utilisation abusive de ces identités. Sans cette clarté, vous courez des risques plus importants que vous ne le pensez et vous avez du mal à répondre aux questions de diligence raisonnable de base.
Dans un environnement mutualisé, la frontière entre la propriété des identités s'estompe. Certains comptes sont clairement sous votre contrôle, comme ceux de votre fournisseur d'identité d'entreprise et les rôles qu'ils occupent dans les environnements clients. D'autres peuvent être créés et gérés par les clients, mais utilisés par vos collaborateurs. D'autres encore peuvent être gérés par des fournisseurs tiers dont vous revendez ou intégrez les outils.
Pour une interprétation pertinente de l'article A.5.16 applicable aux fournisseurs de services gérés (MSP), il est indispensable de définir clairement les responsabilités et les droits de propriété pour chaque catégorie d'accès. Il convient de préciser qui approuve les nouveaux accès, qui crée et configure l'identité, qui la vérifie régulièrement et qui est responsable en cas d'utilisation abusive. Ces réponses doivent être conformes aux contrats, aux attentes des clients et aux évaluations des risques.
Rédiger ces informations dans un langage simple, accompagnées de schémas illustrant la répartition des identités et leur parcours au sein des systèmes, peut s'avérer étonnamment efficace. Cela permet à vos équipes de se forger une représentation mentale commune et offre aux clients et aux auditeurs un moyen de comprendre un sujet complexe sans se perdre dans les détails techniques.
Les aspects réglementaires et juridictionnels que vous ne pouvez ignorer
Les aspects réglementaires et juridictionnels sont importants car les identités peuvent faire le lien entre des régions et des ensembles de données soumis à des règles de confidentialité et d'accès différentes. Les autorités de réglementation exigent de plus en plus des fournisseurs de services gérés (MSP) qu'ils démontrent que l'accès transfrontalier ou sensible est justifié, consigné et encadré ; par conséquent, une conception d'identité qui ignore ces limites engendre des problèmes évitables.
De nombreux fournisseurs de services gérés (MSP) travaillent avec des clients opérant dans des secteurs réglementés ou dans plusieurs pays, où la gestion des identités se conjugue aux exigences en matière de protection de la vie privée, de résidence des données et d'accès transfrontalier. Si du personnel situé dans une juridiction peut se connecter à des systèmes contenant des données provenant d'une autre juridiction, les autorités de réglementation peuvent exiger de vous que vous démontriez comment vous contrôlez et justifiez cet accès, notamment lorsque les législations locales limitent les personnes autorisées à consulter quelles données et depuis quelle source. Les lignes directrices européennes en matière de protection des données, telles que celles du Contrôleur européen de la protection des données (CEPD), insistent sur la gouvernance, la journalisation et la clarté contractuelle pour les sous-traitants qui traitent des données transfrontalières ou sensibles pour le compte des responsables du traitement.
Selon l'enquête 2025 d'ISMS.online, environ deux tiers des organisations affirment que la rapidité et l'ampleur des changements réglementaires rendent la conformité plus difficile à maintenir.
Lors de la refonte de l'identité des utilisateurs conformément à la section A.5.16, il est utile de se poser les questions suivantes : quels ingénieurs, et dans quels lieux, peuvent accéder à quelles catégories de données, dans quelles conditions, et comment cela est-il documenté ? Cette question est particulièrement pertinente lorsque les contrats clients ou la législation locale exigent que certaines données ne soient jamais consultées depuis certaines régions, ou que l'accès soit limité à des personnes nommément désignées et disposant d'habilitations spécifiques.
Réunir vos équipes chargées de la protection des données, des affaires juridiques et de la sécurité pour examiner ces questions sous l'angle de l'identité peut vous éviter de mauvaises surprises par la suite. Cela vous permet également d'éviter de concevoir une architecture d'identité théoriquement solide, mais qui s'avérerait inadaptée aux réalités réglementaires, notamment pour les services transfrontaliers.
Conception d'un modèle de gestion des identités multi-locataires
Concevoir un modèle de gestion des identités mutualisé implique de choisir une architecture, des outils et des mécanismes de gestion des pannes qui garantissent des identités uniques, basées sur le principe du moindre privilège, pour chaque client, sans surcharger les équipes d'ingénierie. Ce modèle doit être réfléchi, documenté et facile à gérer pour accompagner la croissance et l'évolution de votre fournisseur de services gérés.
Une fois les risques et les responsabilités clarifiés, vous pouvez commencer à concevoir un modèle d'identité multi-locataire à la fois pratique et conforme à la norme A.5.16. C'est à ce stade que vous décidez comment les identités circulent de votre propre annuaire vers les locataires clients, quels outils sont au centre de votre environnement et comment vous gérez les situations exceptionnelles sans compromettre l'ensemble de la conception.
Choisir une architecture d'identité multi-locataire
Votre architecture d'identité doit clairement indiquer où résident les identités, comment elles assument des rôles dans les environnements clients et comment révoquer facilement les accès dans tous ces environnements en cas de changement de personnel. La plupart des fournisseurs de services gérés (MSP) optent pour un modèle en étoile, un modèle de compte par client ou un modèle hybride combinant des éléments des deux.
De manière générale, les fournisseurs de services gérés (MSP) optent pour l'un des trois modèles suivants. Dans un modèle en étoile, votre fournisseur d'identité centralise les informations et les ingénieurs utilisent les identités de ce répertoire pour accéder aux rôles au sein de plusieurs environnements clients. Dans un modèle par client, chaque environnement client dispose de ses propres comptes pour son personnel, parfois associés à des répertoires locaux. Les modèles hybrides combinent un contrôle centralisé pour certains aspects et une isolation par client pour d'autres.
Une simple comparaison peut aider à cadrer la décision :
Approche | Principal avantage | Principal risque
—|—|—
Architecture en étoile | Politiques centralisées et départ simplifié | Impact accru sur les locataires multiples en cas de faille dans la sécurité de l'architecture centrale
Par locataire | Isolation renforcée entre les clients | Gestion plus complexe et difficile à maintenir à grande échelle
Hybride | Équilibre le contrôle centralisé et les limites locales | Nécessite un effort de conception et de documentation plus important
En résumé, l'architecture en étoile optimise le contrôle centralisé, l'architecture par locataire maximise l'isolation, et l'architecture hybride offre un équilibre entre les deux, au prix d'un effort de conception et de documentation plus important. Les recommandations d'audit informatique professionnel, telles que celles publiées par l'ISACA et d'organismes similaires, insistent généralement sur le fait que les auditeurs s'intéressent moins au modèle choisi qu'à votre capacité à l'expliquer clairement, à démontrer comment il réduit les risques et à prouver son application cohérente.
Votre choix doit être guidé par la taille de votre entreprise, les attentes de vos clients, les plateformes que vous prenez en charge et votre tolérance à la complexité. Quelle que soit l'architecture choisie, la norme A.5.16 exige qu'elle soit réfléchie et documentée. Vous devez être en mesure de justifier ce choix, d'expliquer comment elle garantit l'unicité et la traçabilité des identités, et de décrire le déroulement des événements liés au cycle de vie des comptes. Cette documentation ne doit pas nécessairement être exhaustive, mais elle doit être cohérente.
Placer les bons outils au centre
Placer les outils adéquats au cœur de votre modèle garantit une chaîne unique et fiable, depuis les événements de l'entreprise (arrivées, mutations, départs et nouveaux clients) jusqu'aux modifications de comptes, de rôles et de justificatifs. Sans cela, l'identité devient rapidement un mélange opaque d'habitudes et d'exceptions, difficile à justifier lors d'un audit.
Une fois l'architecture conceptuelle définie, il convient de déterminer quels outils feront office de source de référence pour l'identité et les accès. Pour certains fournisseurs de services gérés (MSP), il s'agira du fournisseur d'identité de l'entreprise. Pour d'autres, ce sera une plateforme de gouvernance des identités, une solution de gestion des accès privilégiés, voire un système de gestion des tickets faisant office de registre officiel des demandes et des approbations.
L'essentiel est d'établir une chaîne claire entre les événements opérationnels (arrivée, changement de poste ou départ d'un collaborateur, intégration d'un nouveau client, modification d'un contrat) et les changements d'identité dans vos différents systèmes et environnements. Si votre système RH ou votre plateforme de services professionnels est le lieu de création des nouveaux rôles, vous devez comprendre comment ces changements sont intégrés à votre fournisseur d'identité, aux environnements clients et à votre système de traçabilité.
C’est là qu’une plateforme de gestion de la sécurité de l’information comme ISMS.online peut s’avérer utile. En reliant vos politiques, vos catalogues de rôles, vos diagrammes et vos registres d’approbation à des contrôles spécifiques tels que A.5.16, elle vous offre un point d’accès unique pour vérifier si le modèle que vous avez conçu est effectivement appliqué et pour démontrer ce lien lorsque des auditeurs ou des clients en font la demande.
Concevoir pour la défaillance et la continuité
Concevoir pour la continuité des opérations et la gestion des pannes implique de prévoir le comportement des identités lorsque des outils, des personnes ou des infrastructures clés sont indisponibles, afin de protéger les clients même en situation de crise. Cela nécessite des procédures de reprise d'activité et de secours maîtrisées, conformes à l'esprit de la norme A.5.16 et non contournables.
Aucun modèle d'identité n'est complet s'il ne fonctionne que lorsque tout le reste est opérationnel. Il est également indispensable d'anticiper les situations où votre fournisseur d'identité est indisponible, une plateforme de gestion des clés est hors service ou un ingénieur possédant des connaissances essentielles est soudainement absent. Ces scénarios sont certes problématiques, mais les ignorer conduit souvent à des solutions de contournement improvisées qui fragilisent vos contrôles.
Une conception résiliente comprendra des voies d'accès d'urgence clairement définies, tout en respectant le principe du moindre privilège. Cela peut impliquer un nombre restreint de comptes d'accès prioritaires dotés de protections renforcées et de procédures strictes, ou des processus hors ligne pré-approuvés pour des scénarios spécifiques. Il est essentiel que leur existence et leur utilisation soient documentées, surveillées et évaluées afin d'éviter tout détournement discret.
Anticiper ces défaillances et les intégrer à votre système de gestion de la sécurité de l'information facilite grandement la communication avec vos clients et auditeurs quant à la gestion d'une crise, sans pour autant contourner vos contrôles d'identité soigneusement conçus. Cela renforce également la confiance de votre équipe, qui sait ainsi agir sous pression sans avoir à recourir à des solutions de facilité risquées.
Libérez-vous d'une montagne de feuilles de calcul
Intégrez, développez et faites évoluer votre conformité, sans complications. IO vous offre la résilience et la confiance nécessaires pour croître en toute sécurité.
Modèles de contrôle d'accès basé sur les rôles (RBAC), de moindre privilège et de séparation des comptes d'administrateur
Le contrôle d'accès basé sur les rôles, le principe du moindre privilège et une séparation claire entre les comptes standard, privilégiés et d'urgence transforment votre architecture d'identité de haut niveau en comportements concrets au quotidien, limitant ainsi l'impact des incidents sur les environnements mutualisés. C'est dans ces conditions que la norme A.5.16 devient un outil de contrôle opérationnel pour les fournisseurs de services gérés (MSP), et non une simple déclaration de politique.
Une fois votre modèle de haut niveau clairement défini, vous pouvez passer au niveau inférieur et vous intéresser aux schémas qui régissent l'accès au quotidien. Le contrôle d'accès basé sur les rôles, le principe du moindre privilège et une séparation rigoureuse entre les comptes standard, privilégiés et d'urgence sont les outils qui permettent de transformer les principes de la norme A.5.16 en une conception pratique que les ingénieurs peuvent suivre et que les auditeurs peuvent tester.
Création d'un catalogue de rôles à l'échelle de l'entreprise MSP
Un catalogue de rôles à l'échelle de l'entreprise MSP devrait vous fournir un ensemble restreint et bien défini de rôles, dont les permissions sont cohérentes entre les plateformes et les locataires. Ainsi, les ingénieurs obtiennent l'accès en fonction de leurs responsabilités plutôt que de leur expérience personnelle ou d'exceptions informelles. Cela facilite également la communication de votre modèle aux non-spécialistes.
Un catalogue de rôles est une liste de rôles définis, chacun ayant un objectif précis et des droits associés. Pour un fournisseur de services gérés (MSP), les rôles typiques peuvent inclure le support de premier niveau, l'ingénieur senior, l'analyste de sécurité, l'ingénieur de projet et le gestionnaire de compte. Chaque rôle doit être décrit en termes compréhensibles par les équipes techniques et commerciales, avec des exemples de tâches associées.
L'intérêt d'un catalogue réside dans le fait qu'il offre un point de départ standardisé. Au lieu de gérer les accès locataire par locataire et personne par personne, la décision est prise une seule fois, au niveau des rôles, puis ces rôles sont associés à des permissions spécifiques à chaque plateforme et environnement. Il devient ainsi beaucoup plus facile de démontrer que les accès sont liés aux responsabilités, et non à des relations personnelles ou à des cas particuliers.
Lors de la création d'un tel catalogue, il est conseillé de commencer modestement. Identifiez les quelques rôles qui couvrent la majeure partie de votre personnel, définissez-les précisément, intégrez-les à une ou deux plateformes principales, puis affinez-les. Vous pourrez ainsi gérer les exceptions comme des variations documentées, plutôt que de créer un nouveau rôle pour chaque cas particulier. Au fil du temps, vous pourrez ajouter des rôles ou affiner ceux existants à mesure que vos services se développent.
Séparation des accès standard, privilégiés et d'urgence
La séparation des accès standard, privilégiés et d'urgence permet d'appliquer différents cycles de contrôle, de surveillance et d'examen aux tâches quotidiennes, aux activités administratives et aux situations d'urgence réelles. Cette séparation claire aide également les ingénieurs à comprendre quelle identité utiliser dans chaque situation et à quel niveau de contrôle s'attendre.
Dans de nombreux fournisseurs de services gérés (MSP), le même compte d'ingénieur est utilisé pour les tâches quotidiennes et les actions à privilèges élevés chez les clients. Si cela peut sembler pratique, cette approche brouille les responsabilités et complique la mise en place de mesures de sécurité supplémentaires pour les opérations sensibles. La norme A.5.16 et les contrôles associés vous incitent à définir des limites plus claires afin de mieux protéger les environnements clients.
Voici un modèle pratique que de nombreux fournisseurs de services gérés adoptent :
- Identités standard pour le travail quotidien et les tâches de soutien à faible risque.
- Identités ou rôles privilégiés pour les tâches administratives, idéalement avec une élévation au moment opportun.
- Les comptes « bris de verre » sont réservés strictement aux urgences et bénéficient d'une protection et d'une surveillance renforcées.
Les identités standard gèrent les tickets de routine et les modifications à faible risque, et font l'objet d'un suivi via la journalisation classique. Les identités privilégiées ne sont utilisées qu'en cas de nécessité, bénéficient d'une élévation de privilèges temporaire et sont soumises à un examen plus approfondi. Les comptes d'urgence sont strictement contrôlés, utilisés rarement et dans des conditions définies, et font systématiquement l'objet d'un audit après utilisation afin de garantir que les situations d'urgence ne se transforment pas en failles de sécurité.
Vérifier que votre conception contient bien un rayon d'explosion
Vous ne pouvez vérifier l'efficacité de vos modèles de contrôle d'accès et de séparation des rôles qu'après avoir testé leur comportement dans des scénarios de défaillance réalistes, tels que des appareils compromis ou des identifiants divulgués. Sans ces tests, vous risquez de vous fier à une conception qui paraît solide sur le papier, mais qui s'avère peu efficace pour contenir les incidents réels.
Les schémas de rôles et de séparation peuvent paraître excellents sur les diagrammes, mais se révéler inefficaces en situation de crise. Pour éviter un faux sentiment de sécurité, il est essentiel de vérifier régulièrement, par des tests techniques et organisationnels, si votre conception limite réellement l'impact d'un compte compromis ou d'une utilisation abusive comme prévu.
Cela pourrait impliquer des exercices de simulation où l'on analyse des incidents hypothétiques : le vol d'un appareil appartenant à un ingénieur ; l'accès d'un attaquant à un coffre-fort de mots de passe ; la fuite d'un jeton privilégié. Cela pourrait également impliquer des simulations techniques, utilisant des outils ou une analyse manuelle pour déterminer les environnements et les systèmes auxquels une identité donnée peut accéder et les actions qu'elle peut y effectuer.
L'objectif n'est pas de « casser » votre système pour le plaisir, mais de déceler les failles avant qu'un attaquant ne les exploite. Lorsque vous modifiez les rôles, les privilèges ou les modèles en conséquence, documentez ces changements et leurs raisons. Avec le temps, cela constitue une preuve convaincante que vous gérez la gestion des identités comme un système dynamique, et non comme une configuration statique figée le jour de la certification.
Accès en flux tendu entre locataires
Les processus d'intégration, de mobilité et de départ, ainsi que les processus juste-à-temps, sont les points de rencontre entre votre modèle d'identité et les changements quotidiens. Ils doivent donc garantir l'alignement des comptes avec la réalité pour tous les locataires, sans engendrer de frictions insupportables. L'évaluation de la conformité à la norme A.5.16 repose souvent sur l'efficacité de ces flux dans la pratique, et non uniquement sur leur description dans les politiques ou les schémas.
Un modèle d'identité, aussi bien conçu soit-il, reste inefficace s'il n'est pas mis à jour régulièrement en fonction des arrivées, des changements de poste et des départs. Pour les fournisseurs de services gérés (MSP), ce processus de mobilité interne est le point de rencontre entre la théorie et la réalité : roulement du personnel, changements organisationnels, nouveaux clients et projets urgents qui mobilisent les équipes dans de nouveaux environnements à court terme.
Conception de flux robustes de type « joineur-déménageur-levier ».
Des flux robustes d'arrivée, de mobilité et de départ s'appuient sur des événements métier fiables et les traduisent de manière cohérente en modifications d'identité dans chaque environnement concerné, plutôt que de laisser aux ingénieurs le soin de se souvenir de mises à jour ponctuelles. Cela implique de définir les actions à entreprendre pour les nouveaux arrivants, les personnes qui changent d'environnement ou qui quittent l'entreprise, et de rendre ces étapes aussi automatiques et reproductibles que possible.
Un processus JML robuste repose sur l'ancrage des changements d'identité dans des événements fiables. Les arrivées doivent être signalées par les RH ou l'intégration contractuelle, les mutations par des changements de rôle ou de responsabilités approuvés, et les départs par des procédures de sortie formelles ou des résiliations de contrat. Chaque type d'événement doit correspondre à des actions claires dans vos systèmes et chez chaque client concerné par l'intervention de l'ingénieur ou de l'outil.
Une façon simple de rendre cela concret est de définir une séquence courte et répétable pour chaque étape :
Menuisiers
- Créer des identités dans l'annuaire de l'entreprise.
- Attribuer des rôles standard et des accès de base.
- Accorder un accès spécifique au locataire lorsque les contrats le permettent.
- Consignez les approbations et enregistrez les dates d'effet.
Déménageurs
- Examiner les rôles actuels et les accès des locataires.
- Ajoutez les rôles requis et supprimez ceux qui ne sont plus nécessaires.
- Mettre à jour les appartenances aux groupes et les autorisations d'utilisation des outils.
- Consigner les approbations et la justification des modifications.
Les sortants
- Révoquez immédiatement tous les accès locataires et outils.
- Désactiver ou supprimer les comptes dans l'annuaire de l'entreprise.
- Retirer des groupes privilégiés et des rôles d'administrateur.
- Confirmer l'exécution des travaux et conserver les preuves pour l'audit.
La difficulté liée au multi-tenant réside dans la nécessité de répéter ces étapes dans de nombreux environnements et outils. L'automatisation des tâches prévisibles, telles que la mise à jour des appartenances à des groupes ou l'approbation des flux de travail, et la limitation de l'intervention humaine aux cas exceptionnels, permettent de garantir la cohérence sans surcharger les équipes ni dépendre de la mémoire individuelle. La documentation sur la gouvernance des identités, notamment les guides sur le cycle de vie et les modèles de gouvernance des identités, insiste sur cette approche de cycle de vie complet (enregistrement, modification et révocation), ce qui correspond parfaitement aux exigences de la section A.5.16.
Utilisation de l'élévation juste à temps sans ralentir les ingénieurs
L'utilisation de l'élévation juste-à-temps sans ralentir les ingénieurs exige la conception de trajectoires d'élévation qui minimisent les risques en réduisant les périodes d'intervention prioritaires, tout en permettant une réponse rapide. Si les ingénieurs sont impliqués dans la conception, l'élévation juste-à-temps peut devenir une pratique courante plutôt qu'un obstacle à contourner.
L'accès en temps réel peut être perçu comme une contrainte supplémentaire pour les ingénieurs habitués à des droits d'administration permanents. Mal géré, il ralentit les temps de réponse et encourage les raccourcis. Bien géré, il peut réduire considérablement les risques tout en permettant à vos équipes de travailler avec un minimum de contraintes.
En pratique, le JIT (Just-In-Time) pour les MSP (Managed Service Providers) signifie généralement que les ingénieurs travaillent la plupart du temps avec des droits d'accès standard, puis demandent une élévation de privilèges temporaire pour les tâches spécifiques qui le requièrent réellement. Ces demandes peuvent être déclenchées automatiquement par des tickets, des changements ou des flux de travail de gestion des incidents, et peuvent nécessiter une approbation en fonction du risque encouru. L'élévation de privilèges est limitée dans le temps et consignée, et l'accès est rétabli à la normale par la suite sans intervention manuelle.
Pour que cela fonctionne, il est essentiel de concevoir le processus avec les ingénieurs, et non pas seulement pour eux. Cela implique de choisir des durées par défaut raisonnables, d'éviter les approbations inutiles pour les tâches à faible risque et de simplifier et d'accélérer le parcours de demande. Si le processus est clairement intégré à votre stratégie de gouvernance des identités et que les clients en perçoivent la valeur, il devient plus facile de susciter l'adhésion et d'éviter les solutions de contournement.
Automatisez ce que vous pouvez, examinez ce que vous devez faire.
L’automatisation des tâches possibles et la vérification des tâches essentielles permettent de gérer à grande échelle les changements d’identité fréquents et à faible risque, tout en réservant l’intervention humaine aux cas plus complexes ou inhabituels. La conformité à la norme A.5.16 est plus facile à prouver lorsque les opérations de routine (arrivée, départ, mutation) et les actions en temps réel sont cohérentes, bien documentées et reproductibles.
Tous les aspects de JML et JIT ne peuvent ni ne doivent être automatisés. Les modifications fréquentes et à faible risque, comme l'ajout d'un rôle standard pour un nouvel ingénieur ou la mise à jour des appartenances aux groupes, sont de bons candidats à l'automatisation, notamment dans les outils mutualisés où les erreurs peuvent se propager rapidement. Il en va de même pour les procédures de désactivation de compte courantes qui peuvent être déclenchées de manière fiable depuis les systèmes RH ou de gestion des contrats.
En revanche, les demandes d'accès inhabituelles, les dérogations entre locataires et l'utilisation d'un dispositif d'ouverture de porte d'urgence doivent toujours faire l'objet d'un examen humain. Dans ces cas précis, le jugement est essentiel et il est important de pouvoir démontrer qu'une personne a évalué le risque et pris une décision réfléchie, plutôt que de se contenter de cocher une case.
La dernière étape consiste à effectuer une réconciliation régulière entre les informations que vos systèmes d'identité considèrent comme exactes, celles figurant dans vos dossiers RH et contractuels, et la réalité de chaque compte client. Lorsque vous constatez des incohérences (comptes inactifs, privilèges persistants, identités non documentées), considérez-les comme des occasions d'apprentissage. Corrigez le problème spécifique, puis réfléchissez à la manière d'ajuster vos processus ou votre automatisation afin d'éviter des écarts similaires à l'avenir. Cette réconciliation constitue une preuve tangible que vous respectez les exigences du cycle de vie de la norme A.5.16, et pas seulement ses exigences de documentation.
Si vous ressentez déjà la pression de maintenir l'alignement des accès « joiner-mover-leave » et « just-in-time » entre de nombreux locataires à l'aide de feuilles de calcul et de mémoire, il peut être judicieux d'explorer comment une plateforme structurée de gestion de la sécurité de l'information pourrait prendre en charge une partie de ce poids et aider à transformer A.5.16 en un contrôle vivant et durable plutôt qu'en une série de solutions ad hoc.
Gérez toute votre conformité, en un seul endroit
ISMS.online prend en charge plus de 100 normes et réglementations, vous offrant une plate-forme unique pour tous vos besoins de conformité.
Preuve de conformité à la section A.5.16 : documentation, preuves et audits
Prouver la conformité à la norme A.5.16 implique de pouvoir démontrer à tout moment comment vous envisagez de gérer les identités, comment elles se comportent réellement en pratique et comment vous tirez les enseignements des audits et des incidents. Pour les fournisseurs de services gérés (MSP), ces preuves doivent couvrir les réalités des environnements mutualisés ainsi que les systèmes internes, afin de rassurer clients et auditeurs en situation de crise.
La conception et l'exploitation ne représentent que les deux tiers de l'histoire. L'article A.5.16 suppose également que vous puissiez démontrer, sur demande, le fonctionnement concret de votre gestion des identités. Cela implique de disposer des documents adéquats, de les tenir à jour conformément aux pratiques établies et de transformer vos activités quotidiennes en preuves tangibles à présenter aux auditeurs, aux clients et aux organismes de réglementation, sans avoir à déployer des efforts de dernière minute.
Documents minimum requis pour A.5.16
Le cahier des charges minimal requis pour l'article A.5.16 est un ensemble restreint de politiques et de procédures claires et à jour décrivant votre identité, vos intentions et vos responsabilités. Ces documents doivent refléter la réalité de votre environnement mutualisé actuel, et non une vision théorique servant uniquement aux audits.
Vous n'avez pas besoin de centaines de pages, mais d'un petit ensemble de documents qui exprime clairement votre intention. Au minimum, cela comprend généralement une politique de gestion des identités, une norme pour les rôles et les attributions d'accès, des procédures pour les arrivées, les mutations, les départs et les processus de gestion des effectifs en temps réel, ainsi qu'une norme pour les comptes d'administrateur et les comptes d'urgence.
Chacune de ces procédures doit décrire non seulement vos activités, mais aussi les personnes qui les réalisent et comment vous vous assurez de leur exécution. Elles doivent être conformes à votre évaluation des risques et aux autres politiques pertinentes, telles que le contrôle d'accès, la gestion des fournisseurs et la continuité d'activité. Pour les fournisseurs de services gérés (MSP), elles doivent également aborder explicitement les aspects liés au multi-tenant : administration déléguée, rôles inter-tenants, comptes de service dans les environnements clients et anciens comptes partagés.
Rédiger ces documents dans un langage clair et compréhensible s'avère rapidement payant. Ils deviennent des références utiles pour les ingénieurs et le personnel d'exploitation, et non de simples formalités pour les auditeurs. ISMS.online vous aide à maintenir ces documents liés aux contrôles tels que A.5.16, aux registres des risques et aux actions d'amélioration, afin qu'ils restent à jour et ne soient pas mis à jour uniquement à l'approche du prochain audit.
Constituer un registre de preuves qui fonctionne sous pression
Constituer un registre de preuves fonctionnel sous pression implique d'associer chaque exigence A.5.16 à des artefacts spécifiques et reproductibles, pouvant être produits rapidement. L'objectif est de faciliter la réutilisation des tâches courantes comme preuves d'audit, plutôt que de transformer chaque demande en une course contre la montre.
À l'approche de la période d'audit ou lorsqu'un client potentiel important demande des preuves, le pire moment pour rassembler ces éléments est la semaine précédant l'entretien. Il est plutôt judicieux de constituer un registre de preuves simple qui associe chaque exigence de la section A.5.16 à des artefacts spécifiques et reproductibles : rapports, extraits de configuration, exemples de tickets, enregistrements de revues d'accès et journaux que vous pouvez produire de manière fiable.
Par exemple, vous pourriez lier l'exigence d'identités uniques aux exportations de votre fournisseur d'identité qui indiquent les conventions d'appellation et les types de comptes, ainsi qu'aux procédures de création de nouveaux comptes. Vous pourriez également lier les exigences relatives au cycle de vie aux enregistrements de modifications montrant comment un nouvel employé a été intégré et comment un employé a quitté l'entreprise au sein de plusieurs locataires, en les combinant avec une exportation du fournisseur d'identité pour la même période. Enfin, vous pourriez lier les attentes en matière d'examens périodiques aux campagnes d'examen des accès documentées et à leurs résultats.
En tenant ce registre de manière structurée, vous transformez les tâches quotidiennes en éléments facilement assemblables en un dossier de preuves cohérent. Ainsi, lorsqu'on vous demande « comment savez-vous que vos identités sont correctement gérées ? », vous n'êtes pas pris au dépourvu ; vous pouvez sélectionner des éléments parmi un ensemble convenu et facile à produire. Tout fournisseur de services gérés (MSP) peut concevoir un tel registre ; une plateforme de gestion de la sécurité de l'information (SGSI) dédiée est simplement un moyen de centraliser et de rendre visible cette cartographie.
Utiliser les audits et les incidents pour renforcer votre récit
Utiliser les audits et les incidents pour renforcer votre référentiel A.5.16 implique de les considérer comme des boucles de rétroaction structurées plutôt que comme des événements ponctuels de mise en conformité. Chaque constatation ou incident évité de justesse est une occasion d'améliorer la conception de votre identité, vos processus et vos preuves, de manière à pouvoir le démontrer ultérieurement.
Les audits internes et externes peuvent parfois sembler conflictuels, mais ils offrent également l'opportunité de valider et d'améliorer votre gestion des identités. Lors de la planification d'un audit interne, veillez à sélectionner un échantillon représentatif de locataires, de types d'identités et de rôles. Assurez-vous de la cohérence entre votre plan d'audit et vos observations, et identifiez les points forts et les points faibles afin de les intégrer à vos évaluations des risques et à vos politiques.
De même, lorsqu'un incident touche à l'identité (qu'il s'agisse d'une véritable violation, d'un incident évité de justesse ou simplement d'une demande d'accès confuse), prenez le temps d'analyser ensuite ce qu'il révèle sur votre conception et vos processus. Votre documentation a-t-elle facilité ou entravé l'enquête ? Les journaux étaient-ils disponibles et exploitables ? Les utilisateurs ont-ils bien compris quelles identités étaient concernées et lesquelles ne l'étaient pas ?
L’enregistrement des résultats de ces analyses et leur intégration à votre système de gestion de la sécurité de l’information permettent de boucler la boucle. Cela démontre aux auditeurs et aux clients que vous considérez la norme A.5.16 comme un contrôle évolutif, et cela rassure votre direction quant au fait que la gestion des identités n’est pas un projet ponctuel, mais une pratique continue qui s’améliore au fil des enseignements tirés.
Réservez une démo avec ISMS.online dès aujourd'hui
ISMS.online vous aide à transformer un environnement d'identité complexe et mutualisé en un système cohérent et prêt pour l'audit, conforme à la norme ISO 27001 A.5.16 et rassurant vos clients quant à votre engagement en matière de gestion des accès. En centralisant vos politiques, vos modèles de bonnes pratiques, vos processus de gestion des arrivées, des départs et des mouvements de personnel, ainsi que vos justificatifs, dans un espace structuré unique, vous identifiez plus facilement vos points forts, vos points faibles et l'impact des modifications dans un domaine sur les autres.
Ce que vous gagnez en centralisant vos preuves d'identité
La centralisation des preuves relatives à l'identité dans un environnement unique et structuré vous offre une vision constamment mise à jour de la conformité à la norme A.5.16 au sein de votre organisation et chez vos clients, vous évitant ainsi de devoir effectuer des recherches documentaires ponctuelles avant chaque audit ou revue client. L'expérience acquise en matière de systèmes de gestion de la sécurité de l'information (SGSI) et de gouvernance des identités, reflétée dans des guides d'intégration indépendants tels que les livres blancs sectoriels sur l'articulation des SGSI et des contrôles d'identité, suggère qu'une gestion centralisée des contrôles et des preuves peut améliorer sensiblement la visibilité de l'état des contrôles au fil du temps.
Lorsque la gestion des identités est dispersée entre des feuilles de calcul, des commentaires de tickets et la mémoire individuelle, chaque audit ou demande de vérification préalable se transforme en mini-projet. En centralisant la conception de vos contrôles et les preuves, vous créez un espace unique où votre équipe peut consulter la manière dont les identités sont censées être gérées, les contrôles qui la soutiennent et les enregistrements qui le démontrent.
Cela facilite grandement la réponse aux questions des clients, telles que « Qui, au sein de votre entreprise, peut accéder à nos locataires ? », en évitant une vague assurance. Vous pouvez vous appuyer sur des rôles clairement définis, des processus documentés et des résultats concrets de contrôles d'accès. Cela réduit également votre dépendance à l'égard de quelques personnes qui « savent comment tout fonctionne », ce qui est crucial à mesure que votre entreprise se développe et que votre personnel évolue ou quitte l'entreprise.
D'un point de vue opérationnel, la centralisation réduit les doublons et les risques de confusion. Lorsque vos politiques évoluent, vous les mettez à jour une seule fois et les liez aux contrôles, tâches et enregistrements pertinents. Une fois un examen terminé ou une constatation d'audit résolue, les éléments justificatifs sont joints dans leur contexte. Au fil du temps, cela permet de constituer un historique complet et consultable de la manière dont vous avez renforcé la gestion des identités pour votre organisation et pour les clients que vous prenez en charge.
Une façon peu risquée de se familiariser avec ISMS.online
En commençant modestement par une portion ciblée du point A.5.16 sur ISMS.online, vous pouvez démontrer l'intérêt de la centralisation sans vous engager dans une refonte complète des processus dès le premier jour. Vous pouvez débuter par une politique d'identité et un flux unique de gestion des arrivées, des mutations et des départs, puis l'étendre à mesure que votre équipe se familiarise avec le processus et en constate les avantages concrets.
Si la gestion des identités multi-locataires vous pèse déjà sans système structuré de gestion de la sécurité de l'information, l'idée d'ajouter une plateforme supplémentaire peut paraître intimidante. Pourtant, la réalité est souvent bien plus simple. De nombreux fournisseurs de services gérés (MSP) commencent par intégrer une petite partie ciblée de la norme A.5.16 à ISMS.online et tirent des enseignements de cette expérience avant d'étendre leur action à d'autres contrôles et cadres de référence.
Par exemple, vous pourriez commencer par votre politique d'identité, votre catalogue de rôles et un processus unique de gestion des arrivées, des mutations et des départs, en les reliant à la norme A.5.16 et aux contrôles associés, et en y joignant quelques éléments de preuve récents. À partir de là, vous pourrez expérimenter la planification des revues, l'attribution de tâches d'amélioration et l'intégration d'autres éléments de votre modèle d'identité dans le système, au fur et à mesure que vous gagnez en confiance.
Un bref échange avec l'équipe ISMS.online vous permettra de déterminer si cette approche correspond à votre culture d'entreprise, à votre envergure et à vos outils existants. Vous découvrirez comment d'autres fournisseurs de services gérés (MSP) ont utilisé la plateforme pour mettre en œuvre des modèles d'identité mutualisés, les réactions habituelles des auditeurs et un aperçu réaliste de la marche à suivre. Optez pour ISMS.online si vous souhaitez une gestion des identités mutualisées maîtrisée, documentée et transparente ; si vous accordez une grande importance à la crédibilité de la solution pour vos clients, vos auditeurs et les organismes de réglementation, la prochaine étape sera simple.
Demander demoFoire aux questions
Comment la norme ISO 27001:2022 A.5.16 change-t-elle réellement la façon dont un fournisseur de services gérés (MSP) doit traiter les identités des clients locataires ?
La norme ISO 27001:2022, paragraphe 5.16, vous fait passer d'une simple gestion des accès (« nous avons accès ») à une capacité totale de prouver précisément qui a accès à quoi, pourquoi et pendant combien de temps » pour chaque client. Pour un fournisseur de services gérés, cela inclut votre propre infrastructure et chaque identité déléguée ou intégrée au sein des environnements clients.
Que signifie l’expression « absence d’interventions anonymes » dans un fournisseur de services gérés multi-locataires ?
A.5.16 vous demande de traiter l'identité comme un actif géré, et non comme un ensemble dispersé d'identifiants de connexion :
- Toute identité humaine et non humaine pouvant atteindre un locataire est répertorié, détenu et justifié.
- Chaque identité est liée à un rôle, contrat ou service, et non un accès « administrateur » vague.
- Évolution au fil du temps – intégration, accès aux projets, remontée des incidents, désactivation – à suivre étapes définies.
- Les approbations, les examens et les suppressions sont enregistré et échantillonnable des mois plus tard.
Cette discipline doit traverser plusieurs niveaux :
- Rôles de partenaire/administrateur délégué chez les hyperscalers.
- Comptes d'administrateur direct hérités dans les anciens locataires.
- Comptes de service pour les outils RMM, de sauvegarde, de surveillance et de sécurité.
- Identités de rupture de vitre pour les travaux de continuité ou d'intervention en cas d'incident.
Du point de vue d'un acheteur ou d'un auditeur, un chemin d'administration contrôlé par un fournisseur de services gérés (MSP) représente désormais une faille de sécurité majeure. Lorsque vous pouvez identifier précisément un ingénieur ou un service, indiquer son emplacement, les rôles qu'il assume dans chaque environnement et comment les approbations et les revues sont intégrées à votre système de gestion de la sécurité de l'information (SGSI), la clause A.5.16 cesse d'être une simple formalité et devient un gage de confiance. ISMS.online vous aide à construire cette documentation en reliant directement les politiques, les schémas, les enregistrements des risques et les preuves du cycle de vie au contrôle, garantissant ainsi la cohérence entre vos paroles et vos actes.
Comment un MSP peut-il concevoir une architecture d'identité multi-locataire qui résiste à la norme A.5.16 et à la diligence raisonnable de l'entreprise ?
Une architecture d'identité mutualisée robuste vous offre un ensemble restreint de modèles standard pour la manière dont vos collaborateurs et vos outils accèdent à n'importe quel environnement client et y fonctionnent, avec un confinement clair en cas d'incident. La norme A.5.16 ne prescrit pas de technologie ; elle vérifie simplement si votre modèle est intentionnel, documenté et reproductible.
Quelles décisions en matière d'architecture d'identité devez-vous finaliser une fois pour toutes ?
Vous réduisez les risques et les difficultés liées aux audits lorsque vous cessez de débattre des points fondamentaux au cas par cas et que vous établissez quelques règles internes :
- Là où vivent les identités :
Déterminez si les comptes d'ingénieur sont centralisés (par exemple, dans Entra ID) et associés à des rôles au sein des locataires, s'ils sont créés dans chaque locataire selon des règles strictes, ou si vous optez pour un modèle hybride. Quel que soit votre choix, documentez-le et respectez-le.
- Quel système est la « source de vérité » pour le changement :
Choisissez un système maître unique (RH, ITSM, IdP, outil de gouvernance) pour la gestion des arrivées, des mutations et des départs, et assurez-vous que toutes les autres opérations, y compris l'accès des locataires, soient gérées en conséquence. La condition A.5.16 est remplie lorsqu'un signal unique et clair détermine toutes les modifications d'accès.
- Voies d'accès autorisées aux locataires :
Standardisez les pratiques selon une liste restreinte : groupes d’administrateurs délégués, accès bastion, élévation de privilèges à la demande, postes de travail à accès privilégié, etc. Les solutions ponctuelles non prises en charge sont souvent source de surprises et de problèmes lors des audits.
- Modes de rupture et de défaillance prévus :
Définissez les procédures en cas de défaillance de votre fournisseur d'identité (IdP), de votre système de gestion des accès professionnels (PAM) ou du plan de contrôle client. Un accès d'urgence temporaire et journalisé, associé à un système de tickets, est bien plus facile à justifier qu'un mot de passe d'administrateur global mémorisé.
Un simple schéma visuel illustrant « Plan d'identité MSP → modèles d'accès → plans locataires » peut s'avérer plus utile lors d'un audit préalable qu'une politique de dix pages. Lorsque ce schéma, les politiques associées et les évaluations des risques sont intégrés à ISMS.online et liés à la section A.5.16, vous ne produisez pas seulement un document pour un audit ; vous maintenez une architecture évolutive dans laquelle de nouveaux ingénieurs, locataires et plateformes peuvent s'intégrer sans difficulté.
À quoi ressemble un contrôle d'accès basé sur les rôles et le principe du moindre privilège pour les ingénieurs MSP travaillant chez de nombreux clients ?
Pour un fournisseur de services gérés (MSP), le principe du moindre privilège crédible signifie que les droits de chaque ingénieur dans chaque locataire sont un expression actuelle de leur rôleIl ne s'agit pas d'un historique exhaustif de chaque incident et de chaque faveur qu'ils ont pu accorder. La preuve de l'article 5.16 devient nettement plus simple lorsque les droits suivent un modèle clair et que l'élévation est manifestement exceptionnelle.
Comment structurer le RBAC de manière à pouvoir le défendre sous pression ?
Les fournisseurs qui répondent aux questionnaires de sécurité de leurs clients sans paniquer présentent généralement quelques points communs :
- Un catalogue de rôles précis et tenu à jour :
Au lieu de dizaines de rôles « presque identiques », ils définissent un ensemble ciblé – par exemple, service d'assistance, ingénieur senior, spécialiste de la sécurité, ingénieur de projet, responsable de permanence – et associent chacun à des droits par plateforme et par niveau de locataire (par exemple, réglementation élevée vs standard).
- Séparation stricte entre travail normal et travail privilégié :
Les ingénieurs utilisent une identité pour leurs activités quotidiennes et, pour les opérations à haut risque, ils élèvent les privilèges de cette identité ou passent à un compte sécurisé. L'authentification multifacteur et la journalisation sont indispensables lors de l'élévation des privilèges.
- Définition du périmètre spécifique au locataire :
Les groupes et les rôles reflètent les ventes et les accords conclus avec chaque client. Être ingénieur senior ne confère pas automatiquement de larges droits d'accès à chaque environnement client.
- Exceptions visibles et limitées dans le temps :
Les rôles transversaux ou d'urgence généraux n'existent que dans des scénarios clairement définis tels que la réponse aux incidents, avec des propriétaires explicites, des dates d'expiration et des preuves d'examen.
Un test simple mais efficace consiste à désigner un ingénieur senior et à lui demander : « Si cette identité était compromise aujourd’hui, quels locataires seraient touchés et dans quelle mesure ? » Si vous ne pouvez pas répondre depuis vos systèmes en quelques minutes, votre modèle RBAC est plus fragile qu’il n’y paraît. Centraliser les définitions de rôles, les correspondances et les preuves de revue d’accès dans ISMS.online vous offre un point d’accès unique pour affiner ce modèle et démontrer aux auditeurs et aux clients que votre niveau de risque diminue, au lieu d’augmenter.
Comment un fournisseur de services gérés (MSP) peut-il garantir la fiabilité des accès « arrivée, départ, migration » et « juste-à-temps » lorsque son personnel travaille chez des dizaines de locataires ?
Lorsqu'une personne rejoint l'entreprise, change de rôle ou la quitte, ses accès dans chaque tenant concerné doivent évoluer de manière prévisible, et non par des modifications ponctuelles impossibles à reconstituer six mois plus tard. L'article A.5.16 s'intéresse moins aux outils spécifiques qu'à la conformité des changements d'identité aux flux définis et reproductibles, laissant des traces.
Les fournisseurs de services gérés qui ne craignent pas d'être échantillonnés lors des modifications d'accès ont généralement simplifié la réalité en quelques habitudes fiables :
- Commencez par un événement impliquant une seule personne :
Capturez les nouvelles embauches, les mouvements internes, les promotions, les changements de contrat et les départs une fois dans les RH ou votre outil ITSM, puis laissez cela piloter chaque changement d'identité en aval : création de compte, appartenance à un groupe, accès au locataire et désactivation.
- Standardiser les actions d'accès récurrentes :
L'intégration des ingénieurs dans les groupes de locataires, la modification des équipes chargées de certaines heures ou la révocation des accès des prestataires aux outils partagés suivent des procédures simples, sans avoir à se fier à la mémoire. Ces procédures précisent qui approuve quoi, dans quel délai et quelles preuves sont conservées.
- Automatisez les tâches routinières, conservez le jugement humain pour l'évaluation des risques :
Lorsque les tâches sont répétitives – comme l'ajout d'un rôle standard à dix locataires ou la suppression d'une identité des outils partagés – l'automatisation fonctionne bien, à condition qu'elle génère des journaux d'activité consultables. Les modifications exceptionnelles, telles que l'octroi de droits particulièrement étendus à un locataire soumis à réglementation, font toujours l'objet d'une approbation explicite et d'une validation consignée.
- Considérez la promotion JIT comme un événement contrôlé, et non comme une faveur :
Lorsque les ingénieurs ont besoin de droits d'accès plus élevés, ils en font la demande pour une période définie, associée à un ticket. L'octroi, le début et la fin de l'élévation de privilèges sont consignés dans des enregistrements consultables ultérieurement.
Les membres de votre équipe acceptent souvent plus facilement ces contrôles s'ils constatent qu'ils ne concernent pas uniquement les auditeurs : bien mis en œuvre, ils permettent de réduire les relances, les interventions manuelles et les discussions délicates concernant les droits oubliés. L'utilisation d'ISMS.online pour associer les procédures JML et JIT aux tickets réels, aux événements RH et au contrôle A.5.16 facilite grandement la démonstration, auprès de votre direction et de vos clients, que la gestion des risques liés à l'identité fait partie intégrante de votre fonctionnement quotidien et n'est pas une simple formalité annuelle.
Quelles preuves d'identité rassurent réellement les clients et les auditeurs quant au respect de la norme A.5.16 par un fournisseur de services gérés (MSP) pour l'ensemble de ses locataires ?
Les auditeurs et les acheteurs d'entreprises exigent rarement la perfection, mais ils s'attendent à ce que votre récit, vos processus et vos documents soient cohérents. Les preuves d'identité les plus convaincantes concernent généralement davantage… cohésion que le volume.
Quels artefacts A.5.16 contribuent à instaurer la confiance au lieu de noyer les gens sous un flot de détails ?
Pour un fournisseur de services gérés multi-locataires, un ensemble de preuves convaincantes comprend souvent les éléments suivants :
- Documents de politique et de procédure : rédigé dans un langage clair qui mentionne explicitement les locataires externes, les principales plateformes que vous prenez en charge et le fonctionnement des mécanismes d'arrivée, de déplacement et de départ, d'attribution des rôles et d'accès élevé.
- Catalogue des rôles et correspondances à jour : qui montrent comment les rôles internes se traduisent en droits spécifiques dans des systèmes tels que l'administration déléguée de Microsoft 365, RMM, la sauvegarde, les outils de sécurité et l'infrastructure sur site.
- Quelques exemples concrets de JML : où vous pouvez afficher les processus d'intégration, de modification et de désintégration, y compris les accès des locataires ajoutés ou supprimés et les approbations enregistrées.
- Comptes rendus des examens d'accès programmés : – par exemple, trimestriellement ou semestriellement – cette liste indique quelles identités MSP peuvent joindre chaque locataire, ce qui a changé depuis la dernière révision et quelles mesures correctives vous avez prises.
- Registres des changements et des incidents : traçabilité des événements d'accès à risque élevé, de la demande à l'approbation jusqu'à la mise en œuvre, avec des notes de test ou de restauration le cas échéant.
- Preuves d'apprentissage au fil du temps : – les conclusions des audits internes, les tests d’intrusion ou les incidents dans lesquels l’accès a joué un rôle, ainsi que les actions de suivi consignées et clôturées.
La plupart des fournisseurs de services gérés (MSP) rencontrent des difficultés pour constituer ce dossier à la demande à partir de leurs boîtes mail personnelles, de feuilles de calcul exportées et de fichiers épars. En revanche, le fait de le conserver dans un système de gestion de la sécurité de l'information structuré et de lier chaque élément à la norme A.5.16 permet de répondre aux questions difficiles avec une argumentation claire et cohérente. Grâce à ISMS.online, votre équipe peut se préparer une seule fois et réutiliser ensuite cette vue contrôlée pour les audits ISO, les appels d'offres importants et les questionnaires des assureurs, au lieu de devoir reconstituer son dossier de preuves à chaque fois.
Comment un MSP peut-il utiliser ISMS.online pour transformer A.5.16 en une pratique d'identité multi-locataire reproductible au lieu d'un projet ponctuel ?
La plupart des fournisseurs de services gérés savent déjà à quoi ressemble une « bonne » gestion des identités ; la difficulté réside dans sa mise en œuvre. fiable Tout en prenant en charge de nombreux locataires, différentes plateformes et une équipe très occupée, ISMS.online vous offre un espace unique pour décrire le fonctionnement idéal de la gestion des identités, ancrer cette description dans des activités concrètes et démontrer son amélioration.
Comment intégrer l'identité multi-locataire dans votre SMSI pour qu'elle soit réellement adoptée ?
Les équipes qui maîtrisent A.5.16 avec assurance, sans exercices d'incendie constants, ont tendance à utiliser la plateforme de plusieurs manières concrètes :
- Documentez et appropriez-vous le plan d'identité :
Centralisez vos diagrammes d'architecture d'identité, votre catalogue de rôles et vos modèles d'administration standard dans un espace de travail unique, lié à A.5.16 et aux contrôles associés tels que la restriction d'accès, la journalisation et l'accès fournisseur. Lors de l'adaptation du modèle à une nouvelle plateforme, un nouveau secteur ou une nouvelle tolérance au risque, la modification est versionnée, examinée et clairement attribuée.
- Lier directement les procédures à la pratique vécue :
Liez les procédures JML/JIT et les étapes de revue d'accès aux tickets, exportations, journaux et rapports qui attestent de leur exécution. Ce lien permet de transformer la procédure A.5.16, qui repose sur nos déclarations, en une démonstration concrète de notre efficacité, à chaque demande.
- Transformer les constats en améliorations visibles :
Lorsque des audits internes, des incidents ou des questions de clients révèlent des failles dans la sécurité des identités, il convient de les consigner comme des actions, en précisant les responsables et les dates, plutôt que de les considérer comme de simples inquiétudes. Au fil du temps, votre vision de la directive A.5.16 au sein de votre système de gestion de la sécurité de l'information (SGSI) se transformera en une chronologie des décisions de renforcement de la sécurité, et non plus en un énoncé de contrôle statique.
- Répondre systématiquement aux mêmes questions difficiles :
Adoptez la même approche de contrôle lorsqu'un auditeur ISO vérifie l'échantillon A.5.16, lorsque l'équipe de sécurité d'un client important vous demande quelles personnes peuvent accéder à son locataire, ou lorsque votre assureur souhaite comprendre votre modèle d'identité. Vous adaptez le niveau de détail des informations partagées, mais pas les données sous-jacentes.
Si votre système d'identité actuel repose en grande partie sur quelques personnes qui « savent comment ça fonctionne », commencez par un petit projet plutôt que d'essayer de tout cartographier d'un coup. Choisissez un flux critique – par exemple, la manière dont les accès privilégiés des locataires réglementés sont accordés, examinés et supprimés – et modélisez-le clairement dans ISMS.online conformément à la norme A.5.16. Une fois que vous pourrez expliquer ce flux en réunion sans notes ni recherche frénétique de preuves, vous disposerez d'un modèle que vous pourrez appliquer à l'ensemble de vos identités et locataires, et vous serez bien mieux placé pour présenter votre service géré comme non seulement fonctionnel, mais aussi digne de confiance.
