Feuille de route de mise en œuvre.

Disposer de comptes individuels

Chaque compte doit pouvoir être relié sans ambiguïté à une personne ou à un processus. Plusieurs comptes restent possibles, par exemple pour séparer un usage courant d’un usage d’administration.

Créer les identités depuis la source autoritaire et rattacher chaque compte à son propriétaire.

Par quoi commencerRaccorder la source des identités et l’annuaire principal.Étape suivanteÉtendre le rattachement aux applications raccordées.

Annuaire, application cible ou autre système portant effectivement le compte.

• Identité propriétaire
• Comptes associés
• Historique de provisioning
• État de synchronisation

Réserver un compte individuel à son titulaire

Un compte nominatif ne doit pas devenir, dans les faits, un compte partagé entre plusieurs personnes.

Maintenir un propriétaire unique par compte et qualifier les comptes dont le propriétaire est inconnu.

Par quoi commencerLister les comptes sans propriétaire connu sur l’annuaire principal.Étape suivanteRemplacer par des comptes individuels les usages partagés non justifiés.

Annuaire, IdP, MFA et politique d’authentification.

• Propriétaire déclaré
• Historique d’attribution
• Modifications du compte
• Résultats de rapprochement

Encadrer les comptes partagés

Si plusieurs personnes doivent utiliser le même compte, il faut savoir qui en est responsable, qui est autorisé à l’utiliser et comment retrouver les usages réels.

Recenser les comptes partagés, leur désigner un propriétaire et gouverner la liste des personnes autorisées.

PAM, coffre-fort, journaux de connexion, SIEM ou procédure organisationnelle.

• Responsable du compte
• Population autorisée
• Demandes et validations
• Historique des retraits d’autorisation

Ne pas créer inutilement de comptes pour l’accès public

Tout accès n’a pas vocation à devenir une identité gouvernée. Consulter une information publique ne justifie pas, à lui seul, la création d’un compte.

Délimiter les identités réellement gouvernées et écarter les accès publics sans compte.

Gouvernance de la ressource et configuration du système qui diffuse l’information.

• Périmètre des comptes gouvernés
• Catégories d’identités intégrées
• Comptes des contributeurs ou administrateurs rattachés à leur propriétaire

Désactiver les comptes devenus inutiles

Un départ, une absence prolongée ou la fin d’un service doit produire une action maîtrisée sur les comptes, dans un délai connu, sans dépendre d’une succession de messages manuels.

Déclencher un workflow de désactivation à partir de l’événement de départ, puis contrôler son exécution.

Par quoi commencerConnecter la source qui connaît les départs et l’annuaire principal.Étape suivanteÉtendre le déprovisioning aux applications prioritaires.

SIRH ou référentiel fiable, annuaires et applications cibles, connecteurs ou procédure manuelle définie.

• Événement source
• Date du workflow
• Comptes concernés
• Ordres de déprovisioning
• Résultat du traitement
• Droits retirés

Revoir les comptes au moins annuellement

Il faut régulièrement comparer les comptes qui existent vraiment avec les personnes, processus et usages qui devraient encore les justifier.

Réconcilier les comptes observés avec les identités connues et traiter les anomalies détectées.

Par quoi commencerRapprocher les comptes de l’annuaire avec les identités connues.Étape suivanteÉtendre la réconciliation aux applications.

Responsables des comptes et systèmes cibles pour appliquer les corrections qui ne peuvent pas être provisionnées automatiquement.

• Périmètre et date de revue
• Comptes rapprochés ou sans propriétaire
• Décisions de conservation, correction ou désactivation
• Suivi des traitements
• Rapports et exports

Protéger l’accès par authentification

Avant d’accéder à une ressource, une personne ou un processus doit prouver son identité avec un mécanisme prévu à cet effet.

Garantir que chaque compte gouverné est rattaché à une identité ; l’authentification reste portée par l’annuaire ou l’IdP.

Annuaire, IdP, MFA ou mécanisme d’authentification de la ressource.

• Identité et compte rattachés
• Historique de création et de désactivation
• État de synchronisation
• Droits associés au compte

Changer les secrets configurés par défaut

Un mot de passe ou autre secret livré avec un équipement ou une application ne doit pas rester celui d’origine quand la ressource entre en service.

Traiter le changement des secrets par défaut au niveau de la ressource, de l’annuaire ou du PAM.

Ressource cible, annuaire ou PAM chargé de modifier et protéger le secret.

• Propriétaire du compte lorsqu’il est gouverné
• Présence du compte dans le périmètre IAG
• Historique de son cycle de vie — sans contenu du secret

Renouveler le secret d’un compte partagé après le retrait d’un utilisateur

Retirer une personne de la liste ne suffit pas si elle connaît encore le secret commun : ce secret doit être changé.

Retirer l’autorisation au compte partagé lors d’un départ, puis demander la rotation du secret à la brique qui le détient.

PAM, coffre-fort ou système cible capable d’effectuer la rotation.

• Population autorisée avant et après le retrait
• Événement déclencheur
• Décision ou workflow de retrait
• Demande de rotation et état de traitement

Ne rendre le secret accessible qu’aux personnes autorisées

La liste des personnes autorisées doit être maîtrisée, et le secret ne doit être remis qu’à cette population.

Tenir à jour la liste des personnes autorisées par demande et validation ; laisser la remise du secret au coffre-fort ou au PAM.

PAM ou coffre-fort pour le stockage, la protection et la remise du secret.

• Personnes autorisées
• Demandes et validations
• Dates d’attribution et de retrait
• Historique des décisions — sans contenu du secret

Respecter les recommandations relatives aux facteurs d’authentification

Les mots de passe et autres facteurs doivent être assez robustes et renouvelés selon les règles adaptées au système concerné.

Porter les exigences sur les facteurs d’authentification dans l’annuaire, l’IdP ou la politique d’authentification.

IdP, annuaire, MFA et système cible.

• Compte gouverné
• Système cible associé
• Historique du cycle de vie du compte — pas la valeur ni la robustesse du facteur

Traiter le cas exceptionnel d’un secret fixe

Si un secret doit exceptionnellement rester fixe, l’accès à la ressource doit être fortement limité et protégé par d’autres moyens.

Restreindre strictement les personnes autorisées sur la ressource concernée et tracer chaque autorisation.

Ressource cible, réseau, PAM, coffre-fort ou autre dispositif de sécurité adapté.

• Population autorisée
• Demandes et validations
• Historique des changements d’autorisation
• Résultats de revue de cette population

Tracer les accès dans ce cas d’exception

Pour une ressource protégée par un secret qui ne peut pas changer, il faut pouvoir retrouver les connexions et usages effectifs.

Conserver la trace des décisions d’autorisation ; mettre en place la journalisation technique des accès sur la ressource ou le SIEM.

Ressource cible, PAM, dispositif de journalisation et SIEM.

• Décisions d’autorisation
• Population autorisée dans le temps
• Historique des changements — à rapprocher des journaux techniques

N’attribuer des droits qu’à des utilisateurs ou processus authentifiés

Un droit ne doit pas être accordé à un bénéficiaire inconnu : il doit être relié à une identité, à un compte gouverné et à un mécanisme d’authentification.

Rattacher chaque droit gouverné à une identité et à un compte connu.

IdP, annuaire ou ressource cible assurant l’authentification.

• Identité propriétaire
• Compte gouverné
• Droits attribués
• Historique de provisioning et de retrait

Limiter les droits aux seules ressources nécessaires

Quand on regarde une personne ou un processus, il ne doit posséder que les accès utiles à son activité actuelle — ni davantage au départ, ni des droits accumulés avec le temps.

Attribuer les droits par rôles et groupes, recalculer le modèle attendu à chaque changement et retirer ce qui n’est plus justifié.

Par quoi commencerDéfinir quelques profils ou rôles sur un périmètre métier limité.Étape suivanteÉtendre progressivement le modèle et traiter les exceptions par workflow.

Source RH à jour, responsables métiers, propriétaires d’applications et systèmes cibles.

• Règles et rôles appliqués
• Demandes et validations
• Droits provisionnés ou retirés
• Écarts de réconciliation
• Historique des changements

N’autoriser sur une ressource que les personnes qui en ont besoin

Quand on part d’une application ou d’un droit donné, la liste de ses détenteurs doit correspondre à une population métier justifiée.

Partir de la ressource : définir les populations autorisées, comparer aux détenteurs réels et corriger les écarts.

Par quoi commencerDéfinir quelques profils ou rôles sur un périmètre métier limité.Étape suivanteÉtendre progressivement le modèle et traiter les exceptions par workflow.

Propriétaire de la ressource, responsables métiers et système cible.

• Modèle de rôles et politiques
• Population attendue par droit
• Détenteurs réellement observés
• Demandes et approbations
• Corrections et retraits

Revoir les droits au moins annuellement

Il faut régulièrement comparer les besoins théoriques, alimentés notamment par les processus RH, avec les accès réellement détenus, puis appliquer les décisions prises.

Lancer une campagne de certification, recueillir les décisions, appliquer les révocations et contrôler leur exécution.

Par quoi commencerFaire une première campagne sur une application ou une population clairement délimitée.Étape suivanteÉtendre les campagnes et automatiser davantage les révocations.

Processus RH, responsables métiers, propriétaires d’applications et systèmes cibles.

• Périmètre et dates de campagne
• Responsables affectés
• Droits présentés
• Décisions de conservation ou révocation
• Déprovisioning résultant
• Rapports et exports