ISMS Copilot Docs

Comment implémenter le contrôle d'accès et la gestion des identités à l'aide de l'IA

Le contrôle d'accès et la gestion des identités se situent à l'intersection des exigences de conformité et de l'ingénierie de la sécurité au quotidien. Chaque cadre majeur impose des contrôles sur qui peut accéder à quoi, dans quelles conditions, et comment cet accès est gouverné au fil du temps. La norme ISO 27001 consacre les annexes A.5.15 à A.5.18 (politique de contrôle d'accès, gestion des identités, authentification, droits d'accès) et A.8.2 à A.8.5 (accès privilégié, restriction d'accès, authentification sécurisée, accès au code source) à ce sujet. Les critères de services de confiance SOC 2 CC6.1 à CC6.3 exigent des contrôles d'accès logiques et physiques, et le cadre NIST CSF PR.AC couvre la gestion des identités, l'authentification et le contrôle d'accès pour toutes les catégories d'actifs.

Vue d'ensemble

Le contrôle d'accès et la gestion des identités se situent à l'intersection des exigences de conformité et de l'ingénierie de la sécurité au quotidien. Chaque cadre majeur impose des contrôles sur qui peut accéder à quoi, dans quelles conditions, et comment cet accès est gouverné au fil du temps. La norme ISO 27001 consacre les annexes A.5.15 à A.5.18 (politique de contrôle d'accès, gestion des identités, authentification, droits d'accès) et A.8.2 à A.8.5 (accès privilégié, restriction d'accès, authentification sécurisée, accès au code source) à ce sujet. Les critères de services de confiance SOC 2 CC6.1 à CC6.3 exigent des contrôles d'accès logiques et physiques, et le cadre NIST CSF PR.AC couvre la gestion des identités, l'authentification et le contrôle d'accès pour toutes les catégories d'actifs.

Malgré l'étendue de ces exigences, c'est au niveau de la mise en œuvre que la plupart des organisations rencontrent des difficultés. Concevoir des hiérarchies de rôles, automatiser les événements du cycle de vie des identités, déployer l'authentification multifacteur, gérer les comptes privilégiés et effectuer des revues d'accès demandent à la fois des connaissances en conformité et une exécution technique. Ce guide vous montre comment utiliser l'IA pour combler cet écart -- en générant des conceptions, procédures et modèles conformes que vous pouvez adapter à votre environnement spécifique.

À qui s'adresse ce guide

  • Les ingénieurs en sécurité concevant et déployant une infrastructure IAM
  • Les responsables informatiques chargés du contrôle d'accès dans toute l'organisation
  • Les professionnels GRC traduisant les exigences des cadres en contrôles techniques
  • Les consultants mettant en œuvre des programmes de contrôle d'accès pour plusieurs clients

Prérequis

  • Un espace de travail actif ISMS Copilot dédié à votre projet IAM
  • Une évaluation des risques complétée identifiant les risques liés à l'accès (ou l'accès à votre registre des risques)
  • Une compréhension de votre infrastructure d'identité actuelle (services d'annuaire, IdP, fournisseur SSO)
  • Une familiarité avec le périmètre de conformité de votre organisation (quels cadres s'appliquent)

Conception des modèles RBAC/ABAC

Le contrôle d'accès basé sur les rôles (RBAC) et le contrôle d'accès basé sur les attributs (ABAC) sont les deux modèles dominants pour appliquer le principe du moindre privilège à grande échelle. La norme ISO 27001 A.5.15 exige que les règles de contrôle d'accès soient établies en fonction des exigences métier et de sécurité de l'information. Le critère SOC 2 CC6.1 exige que la sécurité de l'accès logique soit mise en œuvre selon le principe du moindre privilège. Bien concevoir le modèle dès l'étape de conception évite l'accumulation de privilèges et simplifie la collecte des preuves d'audit par la suite.

Utiliser l'IA pour concevoir votre modèle RBAC

Commencez par faire analyser votre structure organisationnelle par ISMS Copilot et la faire correspondre à des rôles :

"Nous sommes une entreprise [taille] du secteur [industrie] utilisant [fournisseur d'identité]. Nos départements incluent [liste des départements]. Concevez un modèle RBAC qui applique le principe du moindre privilège. Pour chaque département, définissez : les rôles de base, les rôles élevés, la hiérarchie des rôles et les règles d'héritage, les contraintes de séparation des tâches (combinaisons de rôles incompatibles), et les permissions par défaut en mode refus. Mappez le modèle aux exigences ISO 27001 A.5.15 et SOC 2 CC6.2."

Pour les organisations ayant des exigences d'accès plus complexes, l'ABAC ajoute une prise de décision contextuelle en plus des rôles :

"Nous devons étendre notre modèle RBAC avec un contrôle d'accès basé sur les attributs pour [cas d'usage, par exemple, accès aux données multi-locataires, restrictions géographiques, accès basé sur la classification]. Définissez : les attributs des utilisateurs (département, niveau d'habilitation, localisation, posture de l'appareil), les attributs des ressources (classification des données, propriétaire, niveau de sensibilité), les attributs environnementaux (heure de la journée, zone réseau, niveau de menace), et la logique d'évaluation des politiques. Mappez aux normes NIST SP 800-162 et ISO 27001 A.5.15."

Téléchargez votre organigramme actuel, les descriptions de poste ou votre matrice d'accès existante sur ISMS Copilot avant de concevoir les rôles. L'IA produit des définitions de rôles beaucoup plus précises lorsqu'elle peut se référer à votre structure réelle plutôt que de travailler à partir d'hypothèses génériques.

Matrice de séparation des tâches

Un résultat critique de la conception RBAC est la matrice de séparation des tâches (SoD), qui empêche toute personne seule de contrôler toutes les phases d'un processus critique. Demandez à ISMS Copilot :

"Générez une matrice de séparation des tâches pour notre [système/environnement]. Identifiez les paires de rôles qui créent un conflit (par exemple, approbation des paiements et exécution des paiements, provisionnement des utilisateurs et revue d'accès, déploiement de code et accès à la base de données de production). Pour chaque paire en conflit, spécifiez : le risque en cas de combinaison, le contrôle compensatoire si la séparation n'est pas réalisable, et la référence au contrôle ISO 27001/SOC 2."

Gestion du cycle de vie des identités

La gestion du cycle de vie des identités -- le processus d'arrivée, de mutation et de départ -- est l'endroit où la politique de contrôle d'accès rencontre la réalité opérationnelle. La norme ISO 27001 A.5.16 (gestion des identités) et A.5.18 (droits d'accès) exigent des processus formels pour le provisionnement, la modification et la révocation des accès. Le critère SOC 2 CC6.2 exige que le nouvel accès logique soit autorisé, que l'accès existant soit modifié lorsque les rôles changent, et que l'accès soit supprimé lorsqu'il n'est plus nécessaire. La norme NIST PR.AC-1 exige que les identités et les justificatifs soient émis, gérés, vérifiés, révoqués et audités.

Processus d'arrivée

Utilisez l'IA pour concevoir des workflows d'intégration automatisés qui s'intègrent à votre système RH :

"Concevez un processus d'arrivée automatisé pour notre organisation. Nous utilisons [SIRH, par exemple, Workday/BambooHR] comme source de vérité et [IdP, par exemple, Okta/Azure AD/Google Workspace] pour la gestion des identités. Incluez : les événements déclencheurs du SIRH, le mappage rôle-accès par département et intitulé de poste, la création automatique de comptes sur [liste des systèmes], les exigences d'inscription à la MFA, les paramètres de sécurité par défaut, les étapes de notification et de vérification par le manager, et la piste d'audit capturée à chaque étape. Alignez avec les exigences ISO 27001 A.5.16 et SOC 2 CC6.2."

Processus de mutation

Les changements de rôle sont les événements du cycle de vie les plus souvent négligés, et le principal facteur d'accumulation de privilèges :

"Concevez un processus de mutation déclenché lorsqu'un employé change de département, d'intitulé de poste ou de manager. Incluez : la détection automatique de l'événement de changement, la comparaison de l'ancien accès requis par rapport au nouveau, la révocation de l'accès qui n'est plus nécessaire, le provisionnement du nouvel accès pour le nouveau rôle, le workflow d'approbation par le manager pour le changement net, et une fenêtre de transition de 30 jours avec surveillance. Référencez les exigences ISO 27001 A.5.18 et SOC 2 CC6.2."

Le processus de mutation est la lacune la plus couramment identifiée par les auditeurs. De nombreuses organisations disposent de workflows solides pour l'arrivée et le départ, mais aucun processus pour révoquer l'ancien accès lorsqu'une personne est mutée en interne. Cela entraîne une accumulation de privilèges qui viole les exigences de moindre privilège selon la norme ISO 27001 A.5.15 et le critère SOC 2 CC6.1.

Processus de départ

La révocation rapide de l'accès lors d'un départ est un contrôle critique et une constatation fréquente lors des audits :

"Créez un processus de départ complet couvrant les départs volontaires et involontaires. Incluez : les actions immédiates dans un délai de [période] après notification, la séquence de désactivation des comptes sur tous les systèmes (SSO, VPN, cloud, SaaS, accès physique, email), la sauvegarde des données et leur transfert au manager, les procédures de retour d'équipement et de nettoyage des appareils, la rotation des justificatifs partagés, la suppression des listes de distribution et des appartenances aux groupes, la résiliation de l'accès des sous-traitants et des tiers, et les étapes de vérification post-révocation. Mappez aux exigences ISO 27001 A.5.10, A.5.18 et SOC 2 CC6.2."

Stratégie d'authentification multifacteur

La MFA est l'un des contrôles ayant le plus d'impact pour prévenir les accès non autorisés. La norme ISO 27001 A.8.5 (authentification sécurisée) exige que la force de l'authentification soit proportionnelle à la classification des informations auxquelles on accède. Le critère SOC 2 CC6.1 exige une authentification multifacteur pour l'accès à distance et les comptes privilégiés. La norme NIST PR.AC-7 spécifie que les mécanismes d'authentification doivent être proportionnels au risque.

Planification du déploiement de la MFA

Un déploiement progressif évite la charge de support et la résistance des utilisateurs d'une approche big-bang :

"Concevez un plan de déploiement progressif de la MFA pour notre organisation de [taille]. Nous utilisons actuellement [méthode d'authentification actuelle] et notre IdP est [fournisseur]. Incluez : le périmètre de la Phase 1 (comptes privilégiés, personnel informatique), le périmètre de la Phase 2 (tout accès à distance, applications cloud), le périmètre de la Phase 3 (tous les utilisateurs, toutes les applications), les méthodes MFA recommandées par population d'utilisateurs (application d'authentification, jetons matériels, clés d'accès), le workflow d'inscription et les modèles de communication utilisateur, les procédures d'escalade du support, la période de grâce et le calendrier d'application par phase, et le processus de gestion des exceptions avec documentation d'acceptation des risques. Mappez chaque phase aux exigences ISO 27001 A.8.5 et SOC 2 CC6.1."

Évaluation des méthodes d'authentification

Toutes les méthodes MFA n'offrent pas le même niveau de sécurité. Utilisez l'IA pour évaluer les options en fonction de votre profil de risque :

"Comparez les méthodes MFA pour notre organisation : applications d'authentification TOTP, clés matérielles FIDO2/WebAuthn, notifications push, SMS OTP et authentification basée sur certificat. Pour chaque méthode, évaluez : la résistance au phishing (critique pour notre modèle de menace), la facilité d'utilisation et les frictions d'adoption par les utilisateurs, le coût par utilisateur à [échelle], les exigences matérielles, les options de récupération et de secours, et l'alignement avec les niveaux AAL de la norme NIST SP 800-63B. Recommandez quelle méthode utiliser pour quelle population."

Gestion des exceptions

Chaque déploiement de MFA rencontre des cas particuliers -- comptes de service, systèmes hérités, exigences d'accessibilité. Documentez-les avant qu'ils ne deviennent des constatations d'audit :

"Créez une procédure de gestion des exceptions pour la MFA. Définissez : les catégories d'exceptions valides (incompatibilité avec les systèmes hérités, exigence d'accessibilité, compte de service, accès de secours), la documentation requise pour chaque type d'exception, les contrôles compensatoires lorsque la MFA ne peut pas être appliquée (restriction IP, surveillance renforcée, limites de durée de session), l'autorité d'approbation et l'escalade, la fréquence de révision des exceptions (trimestrielle), et les critères de suppression des exceptions. Alignez avec les exigences ISO 27001 A.5.1 et SOC 2 CC6.1."

Gestion des accès privilégiés

Les comptes privilégiés représentent le risque le plus élevé dans tout programme de contrôle d'accès. Un seul justificatif d'administrateur compromis peut contourner tous les autres contrôles de sécurité. La norme ISO 27001 A.8.2 aborde spécifiquement les droits d'accès privilégiés avec des exigences pour une allocation restreinte, une autorisation formelle et la journalisation des activités. Le critère SOC 2 CC6.3 exige que l'accès aux ressources du système soit géré par des contrôles d'accès basés sur les rôles. La norme NIST PR.AC-4 exige que les permissions d'accès soient gérées selon le principe du moindre privilège.

Conception de la politique PAM

Utilisez l'IA pour créer une politique PAM complète adaptée à votre environnement :

"Concevez une politique de gestion des accès privilégiés pour notre organisation. Nous avons environ [nombre] comptes administrateurs sur [liste des systèmes : cloud, sur site, SaaS]. Incluez : la définition et l'inventaire des comptes privilégiés (root, administrateur de domaine, administrateur de base de données, administrateur IAM cloud, comptes de service avec permissions élevées), le workflow d'approbation pour l'octroi d'un accès privilégié, la durée maximale des privilèges et l'expiration automatique, les exigences d'enregistrement et de surveillance des sessions, le coffre-fort de justificatifs et le calendrier de rotation, la séparation des comptes administrateurs des comptes d'utilisation quotidienne, et les exigences de journalisation d'audit. Mappez aux exigences ISO 27001 A.8.2, SOC 2 CC6.3 et NIST AC-6."

Accès juste-à-temps

Les privilèges permanents -- l'accès administrateur toujours activé -- créent une exposition inutile. L'accès juste-à-temps (JIT) réduit la surface d'attaque en accordant des privilèges élevés uniquement lorsque nécessaire et pour une durée définie :

"Concevez un modèle d'accès privilégié juste-à-temps pour notre [environnement]. Incluez : le workflow de demande et de justification (lié à un ticket de changement ou à un incident), les règles d'approbation automatisées (par exemple, pré-approuvé pour les ingénieurs d'astreinte pendant un incident), la durée maximale de session par niveau de privilège (par exemple, 4 heures pour l'administrateur cloud, 1 heure pour l'administrateur de base de données), la révocation automatique des privilèges à la fin de la session, la journalisation des activités pendant les sessions élevées, l'intégration avec [outil PAM ou IdP, par exemple, Azure PIM, CyberArk, HashiCorp Boundary], et les métriques de reporting (durée moyenne des sessions, temps d'approbation, fréquence d'utilisation). Référencez les exigences ISO 27001 A.8.2 et NIST SP 800-53 AC-2(5)."

Procédures de secours

Des procédures d'accès d'urgence doivent exister pour les situations où les canaux d'accès normaux sont indisponibles :

"Créez des procédures d'accès de secours pour [systèmes critiques]. Incluez : l'inventaire des comptes de secours et leur stockage sécurisé (enveloppe scellée dans un coffre, division des justificatifs entre deux personnes, jeton matériel dans un meuble verrouillé), les critères d'activation (panne du système affectant [seuil], défaillance de l'IdP, incident de sécurité critique), le processus d'autorisation (qui peut approuver l'activation et par quel canal), la surveillance et les alertes (notification immédiate à l'équipe de sécurité lors de l'utilisation d'un compte de secours), les actions post-utilisation (revue complète des activités dans les 24 heures, rotation des justificatifs, documentation de l'incident), le calendrier de test (exercice annuel de secours), et la documentation de conformité. Mappez aux exigences ISO 27001 A.8.2 et SOC 2 A1.2."

Demandez à ISMS Copilot de générer un modèle d'inventaire des comptes privilégiés avant de concevoir votre politique PAM. Comprendre l'étendue complète des comptes administrateurs -- y compris les comptes de service et les clés API avec des permissions élevées -- est essentiel pour un programme PAM complet. De nombreuses organisations découvrent deux à trois fois plus de comptes privilégiés qu'elles ne le pensaient.

Revue et recertification des accès

Les revues d'accès périodiques vérifient que les droits d'accès restent appropriés au fil du temps. La norme ISO 27001 A.5.18 exige que les droits d'accès soient revus à intervalles définis. Le critère SOC 2 CC6.2 exige que l'accès soit périodiquement revu et validé. Sans revues régulières, l'accumulation de privilèges, les comptes orphelins et les permissions obsolètes s'accumulent, créant à la fois des écarts de conformité et des risques de sécurité.

Conception de votre programme de revue d'accès

Utilisez l'IA pour créer un programme de revue adapté à la sensibilité de l'accès examiné :

"Concevez un programme de revue d'accès périodique pour notre organisation. Nous avons [nombre] employés sur [nombre] systèmes. Incluez : la fréquence de revue par type d'accès (trimestrielle pour les accès privilégiés et aux données sensibles, semestrielle pour les accès standard, mensuelle pour les accès des tiers/fournisseurs), la logique d'affectation des réviseurs (le manager direct révise les accès standard, le propriétaire de la ressource révise les accès spécifiques à une application, l'équipe de sécurité révise les accès privilégiés), le workflow de revue avec escalade en cas de non-réponse, le périmètre par cycle de revue (tous les utilisateurs et permissions vs. approche par échantillonnage), et l'intégration avec [outil IGA ou processus manuel]. Mappez aux exigences ISO 27001 A.5.18 et SOC 2 CC6.2."

Modèles de revue et preuves

Les auditeurs doivent voir que les revues ont été effectuées, quelles décisions ont été prises, et que les mesures correctives ont été appliquées :

"Générez un modèle de revue d'accès qui capture : le nom et l'identifiant de l'utilisateur, le système ou l'application, les permissions et rôles actuels, la justification métier pour chaque permission, la décision du réviseur (confirmer, modifier, révoquer), le nom et la date du réviseur, et le suivi des mesures correctives pour les accès révoqués. Créez également un modèle de rapport de synthèse de revue qui montre : le nombre total de comptes revus, le pourcentage confirmé vs. modifié vs. révoqué, le temps moyen pour compléter la revue, les éléments de remédiation en suspens, et les données de tendance par rapport aux cycles de revue précédents."

Workflows de remédiation

La revue elle-même ne représente que la moitié du processus. Les accès révoqués doivent effectivement être supprimés, et cette suppression doit être vérifiée :

"Concevez un workflow de remédiation pour les constatations des revues d'accès. Incluez : la création automatique de tickets pour chaque décision de révocation, l'affectation à l'équipe de provisionnement appropriée, le SLA pour la remédiation (par exemple, 5 jours ouvrés pour les accès standard, 24 heures pour les accès privilégiés), l'étape de vérification confirmant que l'accès a bien été supprimé, le chemin d'escalade pour les SLA non respectés, le processus d'exception pour les accès qui ne peuvent pas être immédiatement révoqués (avec des contrôles compensatoires), et la documentation de clôture pour les preuves d'audit. Référencez les exigences ISO 27001 A.5.18 et SOC 2 CC6.2."

Les revues d'accès génèrent des constatations d'audit lorsque la boucle de remédiation n'est pas fermée. Un auditeur vérifiera non seulement que les revues ont eu lieu, mais aussi que les décisions de révocation ont été exécutées dans un délai raisonnable. Intégrez des SLA de remédiation et des étapes de vérification dans votre processus de revue dès le début.

Exemples de prompts

Les prompts suivants sont prêts à l'emploi dans ISMS Copilot. Remplacez les espaces réservés entre crochets par vos détails spécifiques.

Modèle RBAC pour une organisation cloud-native

Design an RBAC model for a cloud-native SaaS company with 200 employees across engineering, product, sales, customer success, and finance departments. We use Google Workspace for identity, AWS for infrastructure, and Okta for SSO. For each department, define: standard role, elevated role, admin role, permitted resources in AWS (using IAM policy patterns), and segregation of duties constraints. Ensure the model satisfies ISO 27001 A.5.15, SOC 2 CC6.1-CC6.2, and NIST PR.AC-4. Output as a role matrix with permission details.

Procédure complète d'arrivée/mutation/départ

Create a complete identity lifecycle management procedure covering joiner, mover, and leaver events. Our HRIS is BambooHR, IdP is Azure AD, and we use SCIM for automated provisioning to [list SaaS apps]. For each lifecycle event, define: trigger, automated actions, manual steps, approval requirements, SLA, audit trail captured, and compliance mapping to ISO 27001 A.5.16, A.5.18, SOC 2 CC6.2, and NIST PR.AC-1. Include a RACI matrix for each process.

Plan de déploiement de la MFA avec gestion des exceptions

Create a three-phase MFA rollout plan for a 500-person organization currently using password-only authentication. Phase 1: IT and privileged users (month 1-2). Phase 2: all remote and cloud access (month 3-4). Phase 3: all users and applications (month 5-6). For each phase, include: scope, recommended MFA methods, enrollment process, communication plan, support procedures, and success metrics. Also create an exception handling procedure with compensating controls for legacy systems that cannot support MFA. Map to ISO 27001 A.8.5 and NIST SP 800-63B.

Modèle d'accès privilégié juste-à-temps

Design a just-in-time privileged access model for our AWS and Azure environments. We have 15 infrastructure engineers who currently have standing admin access. Define: JIT request workflow integrated with ServiceNow, automated approval rules for common scenarios (on-call incident response, scheduled maintenance), maximum session durations by privilege level, session recording requirements, automatic revocation process, and monthly reporting metrics. Include a comparison of current state (standing access) versus target state (JIT) risk levels. Map to ISO 27001 A.8.2, SOC 2 CC6.3, and NIST AC-2(5).

Programme de revue d'accès trimestrielle

Design a quarterly access review program for an organization with 300 users across 25 SaaS applications, 3 cloud environments, and 2 on-premises systems. Define: review scope and scheduling, reviewer assignment by system type, review workflow with automated reminders and escalation, decision criteria (confirm, modify, revoke), remediation process with 5-day SLA, evidence collection for audit, and KPIs to track program effectiveness over time. Include templates for the review form and summary report. Map to ISO 27001 A.5.18 and SOC 2 CC6.2.

Gouvernance de l'accès des fournisseurs et tiers

Create a third-party access governance framework for managing vendor, contractor, and partner access. We have approximately 40 vendors with system access. Include: access request and risk assessment process, dedicated account requirements (no shared credentials), network segmentation for vendor access, MFA enforcement, time-limited access with automatic expiry, activity monitoring and logging, monthly access reviews, termination procedures at contract end, and annual vendor access audit process. Map to ISO 27001 A.5.19-A.5.22, SOC 2 CC6.2-CC6.3, and NIST PR.AC-3.

Ressources connexes

On this page