Organigramme du processus de provisionnement des utilisateurs (rejoindre,…
Organigramme du processus de provisionnement des utilisateurs : événement RH, identité créée dans l'annuaire, informations d'identification et MFA, ensemble de droits de rôle, approbation du propriétaire pour l'accès privilégié, comptes…
Qu'est-ce que le processus organigramme du processus de provisionnement des utilisateurs (rejoindre,… ?
Le provisionnement des utilisateurs échoue discrètement, c’est pourquoi il est généralement corrigé après un audit plutôt qu’avant. La moitié du menuisier est visible : un nouveau démarreur sans boîte aux lettres se plaint dès le premier jour et quelqu'un s'occupe du problème. Tout le reste est invisible. L'accès est copié par celui qui a occupé le fauteuil en dernier, de sorte qu'un compte surprovisionné devient la référence du département. Les entrepreneurs arrivent sans dossier RH, sans date d'expiration et avec un sponsor qui est parti depuis. La moitié du parc se trouve derrière une authentification unique et est provisionnée automatiquement, tandis que l'autre moitié (le package financier, l'outil qu'une équipe a acheté sur une carte, le portail des fournisseurs) est une file d'attente manuelle que personne ne mesure. Et un mouvement interne ajoute sans jamais soustraire, car rien nulle part ne signale un accès devenu simplement inutile. Rien de tout cela ne produit un incident. Cela produit une lente accumulation qui fait surface des années plus tard sous la forme d'un résultat d'examen d'accès, d'un test de contrôle échoué ou du compte d'un ancien employé toujours en cours d'authentification.
Ce tableau est le mécanisme d'identité et de compte, pas le formulaire de demande ni la chaîne d'approbation. Une seule personne déjà en poste demandant un droit supplémentaire, avec les approbations et le cycle de recertification qui l'entoure, est le processus de demande d'accès chez /fr/templates/organigramme-processus-demande-acces ; la même demande déclenchée par un événement de rejoint ou de déménagement RH et limitée à un profil de rôle se trouve sur /fr/templates/organigramme-du-processus-de-demande-d-acces-des-employes-menuisier-et-demenageur. L'accès à un ensemble de données, dans lequel un propriétaire de données décide de la classification et de l'objectif plutôt que du rôle professionnel, se fait sur /fr/templates/organigramme-du-processus-de-demande-d-acces-aux-donnees-demande-de-revocation. Le chemin de sortie ici est délibérément court, puis passe le relais : le flux complet de déprovisionnement, avec les comptes partagés et de service, la désactivation ou la suppression et la capture de preuves, se trouve à /fr/templates/organigramme-du-processus-de-suppression-de-l-acces-des-utilisateurs-deprovisionnement. Les contrats, le dépistage, l'équipement et le premier jour appartiennent à /fr/templates/organigramme-du-processus-d-integration-des-employes. Ce qui reste, c'est tout ce qui se trouve entre l'événement et un ensemble de comptes fonctionnels, vérifiés et enregistrés (l'identité, les informations d'identification, l'ensemble des droits, la succession en aval) plus la seule population qu'aucune de ces pages ne contient : le non-employé qui arrive sans aucun dossier RH. En termes de contrôle, il s'agit de la moitié de l'identité de l'ISO/IEC 27001:2022 Annexe A (A.5.16 gestion de l'identité, qui régit toute la vie d'une identité, et A.5.17 informations d'authentification, qui régissent les informations d'identification délivrées contre celle-ci) plutôt que A.5.15 et A.5.18, qui régissent ce que cette identité est ensuite autorisée à atteindre.
Trois décisions sont ici tirées que la plupart des procédures de provisionnement laissent implicites. "Salarié ou non-salarié ?" vient avant que l'identité n'existe, car un entrepreneur a besoin d'un sponsor nommé et d'une date d'expiration qu'un flux RH ne fournira jamais, et une identité créée sans eux est l'orpheline qu'un examen d'accès trouve deux ans plus tard. "Dans le *lot de droits standard* ?" divise le flux en deux : tout ce qui se trouve dans le bundle du rôle est automatiquement provisionné sans personne sur le chemin, et seuls les droits privilégiés ou hors bundle vont à un propriétaire, ce qui empêche l'approbation de dégénérer en un tampon en caoutchouc appliqué aux boîtes aux lettres. Et "L'accès provisionné **correspond à la demande** ?" est une porte plutôt qu'une formalité de clôture, car elle relit ce que les systèmes cibles accordent réellement et compare cela avec ce qui a été demandé ; les droits reçus sans approbation ne sont jamais déclarés par la personne qui les a reçus. La branche de déménagement en ajoute un quatrième, « Anciens droits en dehors du nouveau bundle ? », et la recertification un cinquième, « Les droits correspondent toujours au rôle ? », et les deux répondent à la même étape de révocation, il existe donc un moyen de sortir d'un droit, quelle que soit la nécessité de le supprimer.
Ce que couvre cet organigramme
Dans ce modèle
- Six phases (déclencheur, identité, droits, approvisionnement, vérification, modification et examen) réparties en cinq couloirs : RH ou sponsor, équipe d'identité, responsable hiérarchique, propriétaire des droits et sécurité.
- Un point d'entrée pour cinq événements. "Quel événement identitaire ?" achemine un menuisier, un déménageur, un sortant, une demande de bris de vitre et une recertification programmée selon le même tableau, de sorte que les machines sont partagées plutôt que réinventées pour chaque cas.
- La phase identitaire en intégralité : « Salarié ou non-salarié ? achemine les sous-traitants, le personnel de l'agence et les partenaires de service via « Enregistrer le sponsor et la date d'expiration » (la seule étape qui leur donne un propriétaire responsable et une date de fin) avant que les deux itinéraires ne se rejoignent dans « Créer l'identité dans l'annuaire » et « Émettre les informations d'identification et inscrire MFA ».
- "Dans le *lot de droits standard* ?" : la branche standard va directement vers "Provisionner automatiquement le bundle standard" sans aucun approbateur dans le chemin, tandis que les droits privilégiés et hors bundle vont vers "Le propriétaire du droit **approuve** ?", dont la branche refusée se termine par "Droit refusé et fermé".
- Provisionnement dans l'ordre dans lequel le graphique l'exécute : "Provisionner automatiquement le bundle standard", puis "Créer des comptes dans les systèmes en aval" dans le domaine automatisé et manuel, puis "L'accès provisionné **correspond à la demande** ?", dont la branche de non-concordance passe par "Corriger l'octroi excédentaire ou insuffisant" et revérifie plutôt que de fermer le ticket.
- La moitié du changement : on demande à un déménageur "Anciens droits en dehors du nouveau forfait ?" et tout ce qui est trouvé va dans « Révoquer les droits remplacés » avant de rejoindre « À l'intérieur du forfait standard ? » ; un sortant atteint « Remis au processus de suppression d'accès » ; et "Les droits correspondent-ils toujours au rôle ?" envoie une réponse dérivée à cette même étape de révocation.
Quand utiliser ce modèle
- Vous rédigez la section sur l'identité et l'accès d'un manuel d'exploitation informatique et vous avez besoin d'une image de ce qui se passe entre un événement RH et un ensemble de comptes professionnels.
- Vous êtes sur le point d'acheter ou de configurer un outil de gouvernance des identités et souhaitez que les branches soient réglées (quels provisionnements automatiques, ce qui nécessite un propriétaire, ce qui reste une file d'attente manuelle) avant que le flux de travail par défaut d'un fournisseur ne les règle pour vous.
- Les examens d'accès continuent de révéler les droits des emplois que les gens ont quittés il y a des années, et vous avez besoin de l'étape de suppression du déménageur établie avec un propriétaire et d'un délai pour cela.
- Votre patrimoine regorge de non-salariés (entrepreneurs, personnel d'agence, auditeurs, associés, comptes de services) et aucun d'entre eux ne provient du flux RH dont dépend le reste du processus.
- Un auditeur, un questionnaire de sécurité client ou un évaluateur ISO 27001 a demandé comment les identités sont créées, comment les droits sont accordés et comment vous savez que l'accès existant est celui qui a été approuvé.
Comment cela fonctionne
Renommez les voies selon vos propres rôles
Remplacez les RH ou le sponsor, l'équipe d'identité, le responsable hiérarchique, le propriétaire des droits et la sécurité par les rôles que vous avez réellement. Gardez volontairement les RH et les sponsors sur une seule voie : il s'agit du même travail effectué pour différentes populations, et leur séparation est la façon dont les non-employés se retrouvent sans personne responsable d'eux. La voie des propriétaires de droits est celle que la plupart des organisations estiment ne pas avoir remplie. Si vous ne pouvez pas nommer aujourd’hui un propriétaire pour vos droits privilégiés, cette lacune est une constatation plutôt qu’un problème de rédaction, et la voie devrait rester dans le tableau, visiblement vide, jusqu’à ce qu’elle soit fermée.
Déclarez votre source d'enregistrement et ce qu'elle n'est pas
Le graphique suppose un flux faisant autorité des nouveaux arrivants, des personnes qui ont déménagé et des sortants. Notez de quel système il s'agit, quels champs il contient (fonction, responsable, date de début, date d'entrée en vigueur d'un changement, dernier jour) et à quelle vitesse un changement y apparaît. Ensuite, notez qui n'y est pas. Les entrepreneurs, les membres du conseil d'administration, le personnel de l'agence, les stagiaires et les identités de machines ne le sont généralement pas, et chacun d'entre eux a besoin d'un registre et d'un sponsor qui lui est propre avant que le reste du processus puisse se dérouler.
Rédigez les ensembles de droits avant de publier
« Dériver le bundle de droits de rôle » est inerte jusqu'à ce que les bundles existent. Commencez par les dix postes que vous occupez le plus souvent et notez ce dont chacun a réellement besoin dès le premier jour. Lorsque vous disposez de données de connexion ou de dernière utilisation, construisez-vous à partir de ce que les détenteurs actuels utilisent réellement plutôt que de ce qu'ils détiennent ; l'écart entre les deux est généralement large, et c'est la seule raison pour laquelle l'ensemble vaut la peine d'être écrit. Gardez chacun un sol plutôt qu'un plafond, afin que tout ce qui se trouve à l'extérieur reste suffisamment visible pour valoir la peine d'être demandé.
Fixez la barre pour l’approbation du propriétaire
"Dans le forfait standard ?" ne fonctionne que si les critères se trouvent à côté. Les déclencheurs typiques pour la branche d'approbation sont les droits d'administrateur et root, l'accès à la production, les systèmes de paiement ou de paie, les données personnelles et de santé et tout ce qui peut modifier l'accès d'une autre personne. Testez cette liste par rapport aux subventions du dernier trimestre avant de la publier : un critère qui en capture la plupart n'est pas un critère. Si tout est acheminé vers un propriétaire de droits, les approbations arrivent plus rapidement que quiconque ne peut les lire et le contrôle devient une file d'attente sur laquelle les gens apprennent à cliquer.
Faire du déménagement une obligation suivie
« Révoquer les droits remplacés » est l'étape qui décide si l'accès s'accumule dans votre organisation. Donnez-lui le même ticket, le même propriétaire et la même date limite que l'octroi, et clôturez l'événement de déménagement uniquement lorsque les deux moitiés sont terminées : un ticket qui se ferme sur la moitié qui rejoint est le mécanisme par lequel le retrait n'a jamais lieu. Le graphique fait volontairement la comparaison avec le supérieur hiérarchique plutôt qu'avec l'équipe chargée de l'identité : l'équipe peut établir la liste des différences, mais seul le manager sait si un droit est véritablement remplacé ou s'il est toujours nécessaire pour un transfert.
Parcourez-le avec les personnes qui le gèrent, puis publiez une version
Réglez les deux branches que personne ne possède par défaut avant de publier. Décidez qui peut invoquer le bris de glace en dehors des heures d'ouverture et qui lit le journal de session par la suite, et décidez qui agit sur une réponse « à la dérive » lors de la recertification et à quel moment, car un avis qui produit une liste dont personne ne révoque est pire que pas d'avis du tout. Ensuite, apportez le graphique à un ingénieur du centre de services, à un responsable hiérarchique qui a récemment recruté et à la dernière personne qui a effectué une vérification des accès, et corrigez-le en fonction de ce qui se passe réellement. Publiez la version corrigée, gardez ses prédécesseurs lisibles et citez-la à partir de votre politique de contrôle d'accès.
Questions fréquentes
Quelles sont les étapes d’un processus de provisionnement d’utilisateurs ?
Extraire un événement d'arrivée, de déménagement ou de départ du système d'enregistrement ; décider si la personne est un employé ou un non-employé et donner aux non-employés un parrain et une date d'expiration ; créer ou faire correspondre une identité dans l'annuaire avec un identifiant qui n'est jamais réutilisé ; émettre des informations d'identification et enregistrer une authentification multifacteur pour cette identité ; dériver l'ensemble des droits pour le rôle professionnel ; provisionner automatiquement tout ce qui se trouve à l'intérieur de cet ensemble et acheminer les droits privilégiés ou hors ensemble au propriétaire des droits pour approbation ; créer des comptes dans les systèmes en aval, à la fois les systèmes automatisés et la file d'attente manuelle ; vérifier que ce que les systèmes accordent réellement correspond à ce qui a été demandé ; faites-le confirmer par le supérieur hiérarchique ; et enregistrez les droits par rapport à l'identité. Après cela, le processus continue de fonctionner : un déplacement redirige le bundle et révoque ce que l'ancien rôle ne justifie plus, un sortant est désactivé et remis au retrait, et une recertification vérifie périodiquement que les droits et le rôle concordent toujours.
Qu'est-ce qu'un ensemble de droits de naissance ou de droits basés sur les rôles ?
Il s'agit de l'ensemble des accès dont un poste a besoin dès son premier jour, attachés au rôle plutôt qu'à la personne : la messagerie et le calendrier, l'intranet, les systèmes métier de base pour cette fonction, les disques partagés pour cette équipe. Parce qu'il est dérivé du rôle professionnel, il peut être accordé sans approbateur dans le chemin, ce qui est le point important : il supprime les autorisations de routine de la file d'attente d'approbation afin que les exceptions soient lues correctement. Deux règles garantissent l’honnêteté des paquets. Construisez-les à partir de ce que nécessite le travail, jamais en exportant l'accès de la dernière personne qui l'a détenu, car cela copie tous les extras accumulés ainsi que les nécessités. Et attribuez à chaque bundle un propriétaire nommé et une date de révision, car un bundle sans propriétaire ne fait que croître : chaque demande qui ne peut pas être refusée y est ajoutée, et en deux ans, il accorde bien plus que n'importe quel besoin d'un emploi.
En quoi un processus de provisionnement d’utilisateurs est-il différent d’un processus de demande d’accès ?
Ils se rencontrent au milieu et possèdent des moitiés différentes. Le processus de demande d'accès chez /fr/templates/organigramme-processus-demande-acces commence avec une personne déjà en poste qui a besoin d'un système supplémentaire : elle soumet une demande, le supérieur hiérarchique et le propriétaire du système l'approuvent, et il est provisionné puis recertifié. Le processus de demande d'accès des employés chez /fr/templates/organigramme-du-processus-de-demande-d-acces-des-employes-menuisier-et-demenageur couvre la même demande lorsqu'un événement RH d'adhésion ou de déménagement la déclenche et qu'un profil de rôle l'étend. Dans les deux cas, il s’agit de décider. Cette page concerne les tâches suivantes : créer l'identité, émettre les informations d'identification et enregistrer l'authentification multifacteur, dériver l'ensemble, créer des comptes dans chaque système en aval et relire les droits des systèmes cibles pour vérifier qu'ils sont bien ceux qui ont été approuvés. Si vous concevez un formulaire de demande ou une chaîne d'approbation, utilisez ces deux-là. Si vous construisez ou documentez les machines d'approvisionnement derrière elles, y compris les identités des entrepreneurs et la moitié du déménagement d'un déménagement interne, utilisez celle-ci. Si la question est l'accès à un ensemble de données plutôt qu'à un système, voir /fr/templates/organigramme-du-processus-de-demande-d-acces-aux-donnees-demande-de-revocation.
Dans quelle mesure le provisionnement des utilisateurs peut-il réellement être automatisé ?
Plus que ce que la plupart des organisations ont automatisé, et jamais tout. Les systèmes derrière l'authentification unique peuvent fonctionner sans ticket : l'identité de l'annuaire est créée à partir du dossier RH, l'ensemble des rôles est appliqué, l'appartenance au groupe suit. Ce qui fait obstacle à une couverture complète, c'est le domaine que personne n'avait prévu : le système de paie sans API, l'instrument de laboratoire qui conserve sa propre liste d'utilisateurs locaux, l'extranet partenaire où un compte est créé en répondant à un e-mail. Ceux-ci ont besoin d'une file d'attente avec un propriétaire nommé et une heure cible, et ils doivent être répertoriés, car un système manuel qui ne figure pas sur la liste est provisionné tardivement pour un entrant et complètement manqué pour un sortant. Tenez un registre des systèmes connectés et de ceux qui ne le sont pas, revisitez-le chaque fois que quelque chose est acheté et considérez le raccourcissement de la liste manuelle comme le véritable programme de travail. Automatiser l'octroi sans automatiser la relecture est son propre piège : les connecteurs échouent silencieusement, c'est pourquoi l'étape de vérification lit les droits à partir du système cible plutôt qu'à partir du ticket.
Comment approvisionnez-vous les sous-traitants et autres non-employés ?
De la même manière que les salariés, sauf que rien en amont ne vous dit qu'ils existent. Les identités des sous-traitants, du personnel de l'agence, des auditeurs, des ingénieurs partenaires, des stagiaires et des machines apparaissent rarement dans le système RH, de sorte que les deux attributs qui rendent une identité gérable doivent être délibérément capturés : un sponsor interne nommé qui en est responsable, et une date d'expiration tirée du contrat ou de la mission plutôt que laissée ouverte. Rendre l'expiration automatique : le compte se désactive à la date, et le renouvellement est un acte explicite du sponsor avec une nouvelle date de fin. Réaffectez le parrainage lorsqu'un parrain part, car une identité parrainée dont le parrain est parti est exactement le compte que personne n'examine. Les non-salariés méritent généralement des conditions plus strictes et un intervalle de recertification plus court que le personnel, car leur travail est plus restreint et leur rotation est plus rapide. La plupart des comptes orphelins révélés par un examen des accès appartiennent à une personne que l'organisation n'a jamais employée.
Où ce processus s'inscrit
Dans la plupart des opérations, ce processus suit Organigramme du processus d'accréditation des fournisseurs et passe le relais à Organigramme du processus de suppression de l'accès des utilisateurs….
C'est une étape de Gouvernance d’accès.
Étape 1: Organigramme du processus de provisionnement des utilisateurs (rejoindre,… Vous êtes ici
Organigramme du processus de provisionnement des utilisateurs : événement RH, identité créée dans l'annuaire, informations d'identification et MFA, ensemble de droits de rôle, approbation du propriétaire pour l'accès privilégié, comptes…
Étape 2: Organigramme du processus de demande d’accès
Organigramme du processus de demande d’accès : demande basée sur un rôle, approbation du responsable hiérarchique et du propriétaire du système, contrôle de séparation des tâches, attribution et recertification.
Étape 3: Organigramme du processus de demande d'accès des employés (menuisier et…
Étape 4: Organigramme du processus de suppression de l'accès des utilisateurs…