Je travaille désormais pour une société d'édition de logiciels, notamment de solutions de contrôle d'accès. Et mon expérience « d'une vie passée » est liée au côté client - une grande institution financière. À cette époque, notre groupe de contrôle d'accès au sein du département de sécurité de l'information ne pouvait pas se vanter de grandes compétences en matière d'IdM. Nous avons beaucoup appris au cours du processus, nous avons dû combler de nombreuses difficultés afin de construire un mécanisme fonctionnel de gestion des droits d'utilisation dans les systèmes d'information de l'entreprise.
En combinant mon expérience acquise chez le client avec les connaissances et les compétences du fournisseur, je souhaite partager avec vous essentiellement une instruction étape par étape : comment créer un modèle de contrôle d'accès basé sur les rôles dans une grande entreprise et ce qu'il donnera dans le fin. Mon enseignement se compose de deux parties : la première - nous nous préparons à construire un modèle, la seconde - nous le construisons réellement. Avant de commencer la première partie, préparatoire.
NB La construction d’un modèle n’est malheureusement pas un résultat, mais un processus. Ou plutôt, même une partie du processus de création d’un écosystème de contrôle d’accès dans l’entreprise. Alors restez longtemps à l’écoute du jeu.
Tout d’abord, définissons : qu’est-ce que le contrôle d’accès basé sur les rôles ? Supposons que vous ayez une grande banque avec des dizaines, voire des centaines de milliers d'employés (sujets), chacun disposant de dizaines de droits d'accès à des centaines de systèmes d'information intra-bancaires (objets). Et maintenant, multipliez le nombre d'objets par le nombre de sujets - c'est le nombre de connexions que vous devez au moins établir en premier, puis contrôler. Est-il vraiment possible de le faire manuellement ? Bien sûr que non : les rôles semblaient résoudre ce problème.
Un rôle est un ensemble d'autorisations dont un utilisateur ou un groupe d'utilisateurs a besoin pour effectuer certaines tâches de travail. Chaque employé peut avoir un ou plusieurs rôles, et chaque rôle peut contenir une ou plusieurs autorisations accordées à un utilisateur au sein de ce rôle. Les rôles peuvent être liés à certains postes, départements ou tâches fonctionnelles des employés.
Les rôles sont généralement créés à partir des autorisations individuelles des employés dans chaque système d'information. Les rôles métier globaux sont ensuite formés à partir des rôles de chaque système. Par exemple, le rôle commercial « gestionnaire de prêts » comprendra plusieurs rôles distincts dans les systèmes d'information utilisés dans le bureau client de la banque. Par exemple, comme le principal système bancaire automatisé, la caisse enregistreuse, le système de gestion électronique de documents, le gestionnaire de services et autres. En règle générale, les rôles dans l'entreprise sont liés à la structure organisationnelle, c'est-à-dire à un ensemble de départements de l'entreprise et à leurs postes. C'est ainsi que se forme la matrice globale des rôles (je donne un exemple dans le tableau ci-dessous).
Il convient de noter qu'il est tout simplement impossible de construire un modèle à 100 %, offrant tous les droits nécessaires aux salariés de chaque poste dans une structure commerciale. Oui, ce n'est pas nécessaire. Après tout, le modèle ne peut pas être statique, car il dépend d’un environnement en constante évolution. Et d'un changement dans les activités commerciales de l'entreprise, qui, par conséquent, affecte le changement dans la structure organisationnelle et les fonctionnalités. Et du manque de ressources complètes, du non-respect des descriptions de poste, du désir de profit au détriment de la sécurité, et de nombreux autres facteurs. Il est donc nécessaire de construire un modèle qui puisse couvrir jusqu'à 80 % des besoins des utilisateurs en matière de droits fondamentaux nécessaires lors de leur nomination à un poste. Et les 20 % restants pourront, si nécessaire, être interrogés ultérieurement sur des candidatures distinctes.
Bien sûr, vous pouvez demander : « Quoi, il n’y a pas de modèles à 100 % ? Eh bien, cela se produit, par exemple, dans des structures à but non lucratif qui ne sont pas soumises à des changements fréquents - dans certains instituts de recherche. Ou dans des organisations complexes militaro-industrielles avec un haut niveau de sécurité, où la sécurité passe avant tout. Cela se produit, et dans une structure commerciale, mais dans le cadre d'une seule unité, dont le travail est un processus assez statique et prévisible.
Le principal avantage de la gestion des rôles est la simplification de la délivrance des droits, car le nombre de rôles est nettement inférieur au nombre d'utilisateurs du système d'information. Et cela est vrai pour n’importe quelle industrie.
Prenons une entreprise de vente au détail : elle emploie des milliers de vendeurs, mais ils disposent du même ensemble de droits dans le système N, et un seul rôle leur sera créé. Un nouveau vendeur est arrivé dans l'entreprise - il s'est automatiquement vu attribuer le rôle nécessaire dans le système, qui dispose déjà de tous les pouvoirs nécessaires. De plus, en un clic, vous pouvez modifier les droits de milliers de vendeurs à la fois, par exemple ajouter une nouvelle option pour générer un rapport. Vous n'avez pas besoin de faire mille opérations pour associer un nouveau droit à chaque compte - ajoutez simplement cette option au rôle et elle apparaîtra pour tous les vendeurs en même temps.
Un autre avantage de la gestion basée sur les rôles est d'éviter les autorisations incompatibles. C'est-à-dire qu'un employé qui a un certain rôle dans le système ne peut pas avoir simultanément un autre rôle dont les droits ne doivent pas être combinés avec les droits du premier. Un exemple frappant est l'interdiction de combiner les fonctions de saisie et de contrôle d'une transaction financière.
Quiconque s'intéresse à la manière dont le contrôle d'accès basé sur les rôles est né peut
plonger dans l'histoire
Si nous nous tournons vers l'histoire, la communauté informatique a réfléchi pour la première fois aux méthodes de contrôle d'accès dans les années 70 du XXe siècle. Même si les applications étaient alors assez simples, comme aujourd'hui, tout le monde voulait vraiment gérer facilement leur accès. Accordez, modifiez et contrôlez les droits des utilisateurs, simplement pour qu'il soit plus facile de comprendre de quel accès dispose chacun d'eux. Mais à cette époque, il n’existait pas de normes communes, les premiers systèmes de contrôle d’accès étaient en cours de développement et chaque entreprise se basait sur ses propres idées et règles.
De nombreux modèles de contrôle d’accès sont aujourd’hui connus, mais ils ne sont pas apparus immédiatement. Arrêtons-nous sur ceux qui ont apporté une contribution tangible au développement de cette direction.
Le premier modèle, et probablement le plus simple, est Contrôle d'accès discrétionnaire (sélectif) (DAC - Contrôle d'accès discrétionnaire). Ce modèle implique le partage des droits par tous les participants au processus d'accès. Chaque utilisateur a accès à des objets ou des opérations spécifiques. En fait, ici l'ensemble des sujets de droits correspond à l'ensemble des objets. Ce modèle s'est avéré trop flexible et trop difficile à maintenir : les listes d'accès deviennent énormes et difficiles à contrôler au fil du temps.
Le deuxième modèle est Contrôle d'accès obligatoire (MAC). Selon ce modèle, chaque utilisateur accède à l'objet conformément à l'accès délivré à un niveau particulier de confidentialité des données. En conséquence, les objets doivent être classés selon le niveau de confidentialité. Contrairement au premier modèle flexible, celui-ci s’est au contraire révélé trop strict et restrictif. Son utilisation ne se justifie pas lorsque l'entreprise dispose de nombreuses ressources d'information diverses : afin de délimiter l'accès aux différentes ressources, il faudra introduire de nombreuses catégories qui ne se chevaucheront pas.
En raison de l'imperfection évidente de ces deux méthodes, la communauté informatique a continué à développer des modèles à la fois plus flexibles et plus ou moins universels pour prendre en charge différents types de politiques de contrôle d'accès organisationnel. Et c'est à ce moment-là qu'il est apparu le troisième modèle de contrôle d'accès basé sur les rôles ! Cette approche s'est avérée la plus prometteuse, car elle nécessite non seulement l'autorisation de l'identité de l'utilisateur, mais également de ses fonctions de travail dans les systèmes.
La première structure de modèle de rôle bien décrite a été proposée par les scientifiques américains David Ferrailo et Richard Kuhn du National Institute of Standards and Technology des États-Unis en 1992. Puis le terme est apparu pour la première fois RBAC (Contrôle d'accès basé sur les rôles). Ces études et descriptions des principaux composants, ainsi que leurs relations, ont constitué la base de la norme INCITS 359-2012, en vigueur à ce jour, approuvée par le Comité international des normes des technologies de l'information (INCITS).
La norme définit un rôle comme « une fonction professionnelle dans le contexte d'une organisation avec une sémantique associée concernant l'autorité et la responsabilité attribuées à l'utilisateur affecté au rôle ». Le document établit les éléments de base du RBAC - utilisateurs, sessions, rôles, autorisations, opérations et objets, ainsi que les relations et relations entre eux.
La norme fournit la structure minimale nécessaire pour construire un modèle de rôle - combinant les droits dans les rôles, puis accordant l'accès aux utilisateurs via ces rôles. Les mécanismes de composition des rôles à partir des objets et des opérations sont décrits, la hiérarchie des rôles et l'héritage des pouvoirs sont décrits. En effet, dans toute entreprise il existe des rôles qui regroupent des pouvoirs élémentaires qui sont nécessaires à tous les salariés de l’entreprise. Il peut s'agir d'un accès au courrier électronique, à l'EDMS, au portail d'entreprise, etc. Ces autorisations peuvent être incluses dans un rôle général appelé « employé », et il ne sera pas nécessaire dans chacun des rôles de niveau supérieur de lister encore et encore tous les droits élémentaires. Il suffit simplement d'indiquer le signe d'héritage du rôle « d'employé ».
Plus tard, la norme a été complétée par de nouveaux attributs d'accès liés à un environnement en constante évolution. Ajout de la possibilité d'introduire des restrictions statiques et dynamiques. Les statiques impliquent l'impossibilité de combiner les rôles (la même saisie et le même contrôle des opérations mentionnés ci-dessus). Les limites dynamiques peuvent être définies en modifiant des paramètres tels que le temps (heures ou jours de travail/chômage), l'emplacement (bureau/domicile), etc.
Séparément, il faut dire à propos de Contrôle d'accès basé sur les attributs (ABAC). L'approche est basée sur l'octroi d'accès à l'aide de règles de partage d'attributs. Ce modèle peut être utilisé séparément, mais il complète bien souvent activement le modèle de rôle classique : vous pouvez ajouter des attributs d'utilisateurs, de ressources et d'appareils, ainsi que l'heure ou le lieu à un rôle spécifique. Cela vous permet d'utiliser moins de rôles, d'introduire des restrictions supplémentaires et de rendre l'accès minimalement suffisant et, par conséquent, d'augmenter la sécurité.
Par exemple, un comptable peut être autorisé à accéder aux comptes s'il travaille dans une certaine région. Ensuite, la localisation du spécialiste sera comparée à une certaine valeur de référence. Ou vous pouvez donner accès aux comptes uniquement si l'utilisateur se connecte à partir d'un appareil inscrit dans le registre des appareils autorisés. Un bon complément au modèle de rôle, mais rarement utilisé seul en raison de la nécessité de créer de nombreuses règles et tableaux d'autorisations ou de restrictions.
Je vais donner un exemple d'utilisation de l'ABAC de ma "vie antérieure". Notre banque avait plusieurs succursales. Les employés des bureaux clients de ces succursales effectuaient exactement les mêmes opérations, mais devaient travailler dans le système principal uniquement avec les comptes de leur région. Tout d’abord, nous avons commencé à créer des rôles distincts pour chaque région – et il y avait tellement de rôles de ce type avec des fonctionnalités répétitives, mais avec accès à différents comptes ! Ensuite, en utilisant un attribut de localisation pour un utilisateur et en le liant à une plage spécifique de comptes à vérifier, nous avons considérablement réduit le nombre de rôles dans le système. En conséquence, les rôles sont restés pour une seule succursale, qui ont été répliqués pour les postes correspondants dans toutes les autres divisions territoriales de la banque.
Parlons maintenant des étapes préparatoires nécessaires, sans lesquelles il est tout simplement impossible de construire un modèle fonctionnel.
Étape 1. Créer un modèle fonctionnel
Cela vaut la peine de commencer par la création d'un modèle fonctionnel - un document de haut niveau qui décrit en détail la fonctionnalité de chaque unité et de chaque poste. En règle générale, les informations y proviennent de divers documents : descriptions de poste et règlements pour les divisions individuelles - divisions, départements, départements. Le modèle fonctionnel doit être convenu avec tous les services intéressés (métier, contrôle interne, sécurité) et approuvé par la direction de l'entreprise. A quoi sert ce document ? Pour que le modèle puisse s’y référer. Par exemple, vous allez construire un modèle basé sur les droits existants des salariés - déchargés du système et « réduits à un dénominateur commun ». Ensuite, en convenant des rôles reçus avec le propriétaire commercial du système, vous pouvez vous référer à un élément spécifique du modèle fonctionnel, sur la base duquel tel ou tel droit est inclus dans le rôle.
Étape 2. Nous auditons les systèmes informatiques et établissons un plan de priorisation
Dans un deuxième temps, un audit des systèmes informatiques doit être réalisé afin de comprendre comment s'organise l'accès à ceux-ci. Par exemple, ma société financière exploitait plusieurs centaines de systèmes d’information. Dans tous les systèmes, il y avait quelques rudiments de gestion des rôles, dans la plupart - certains rôles, mais principalement sur papier ou dans le répertoire système - ils sont obsolètes depuis longtemps et l'accès à ceux-ci était distribué selon les demandes réelles des utilisateurs. Naturellement, il est tout simplement impossible de construire un modèle dans plusieurs centaines de systèmes à la fois, il faut commencer quelque part. Nous avons mené une analyse approfondie du processus de contrôle d’accès afin de déterminer son niveau de maturité. Au cours du processus d'analyse, des critères de priorisation des systèmes d'information ont été élaborés - criticité, état de préparation, plans de démantèlement, etc. Avec leur aide, nous avons construit une séquence de développement/mise à jour de modèles de rôle pour ces systèmes. Et puis - inclus des modèles de rôle dans le plan d'intégration avec la solution de gestion des identités pour automatiser le contrôle d'accès.
Alors, comment déterminer la criticité du système ? Répondez-vous aux questions suivantes :
- Le système est-il lié aux processus opérationnels dont dépend le cœur de métier de l’entreprise ?
- La perturbation du système affectera-t-elle l’intégrité des actifs de l’entreprise ?
- Quel est le temps d'arrêt maximum autorisé du système, au-delà duquel il est impossible de restaurer l'activité après une interruption ?
- Une violation de l’intégrité des informations dans le système peut-elle entraîner des conséquences irréversibles, tant financières que réputationnelles ?
- Criticité de la fraude. La présence de fonctionnalités, avec un contrôle insuffisant dont il est possible de réaliser des actions frauduleuses internes/externes ;
- Quelles sont les exigences légales, ainsi que les règles et procédures internes de ces systèmes ? Y aura-t-il des sanctions de la part des régulateurs en cas de non-conformité ?
Dans notre société financière, nous avons réalisé un audit comme celui-ci. La direction a développé une procédure d'audit de révision des droits d'accès pour traiter en priorité les utilisateurs existants et les droits sur les systèmes d'information qui figurent sur la liste des priorités absolues. Le service de sécurité a été désigné comme propriétaire de ce processus. Mais pour avoir une vision complète des droits d’accès dans l’entreprise, il était nécessaire d’impliquer les services informatiques et métiers dans le processus. Et ici ont commencé des disputes, des malentendus et parfois même des sabotages : personne ne veut rompre avec ses fonctions actuelles et s'impliquer dans des activités, à première vue, incompréhensibles.
NB Les grandes entreprises disposant de processus informatiques développés connaissent probablement la procédure d'audit informatique - Contrôles généraux informatiques (ITGC), qui permet d'identifier les lacunes des processus informatiques et d'établir un contrôle afin d'améliorer les processus conformément aux meilleures pratiques (ITIL, COBIT, IT Gouvernance, etc.) Un tel audit permet à l'informatique et aux entreprises de mieux se comprendre et de développer une stratégie de développement commune, d'analyser les risques, d'optimiser les coûts et de développer des approches de travail plus efficaces.
L'un des domaines de l'audit est de déterminer les paramètres d'accès logique et physique aux systèmes d'information. Nous avons pris les données obtenues comme base pour une utilisation ultérieure dans la construction d'un modèle de rôle. À la suite d'un tel audit, nous disposons d'un registre des systèmes informatiques dans lequel leurs paramètres techniques ont été déterminés et des descriptions ont été données. De plus, pour chaque système, un propriétaire était déterminé à partir de la direction commerciale dans laquelle il était exploité : c'était lui qui était responsable des processus commerciaux que ce système servait. Un responsable du service informatique a également été nommé, chargé de la mise en œuvre technique des besoins métiers dans un SI spécifique. Les systèmes les plus critiques pour l'entreprise et leurs paramètres techniques, les dates de mise en service et de mise hors service, etc. ont été enregistrés. Ces paramètres ont beaucoup aidé dans le processus de préparation à la construction d'un modèle.
Étape 3 Créer une méthodologie
La clé du succès de toute entreprise réside dans la bonne méthode. Par conséquent, tant pour construire un modèle que pour réaliser un audit, nous devons créer une méthodologie dans laquelle nous décrirons l'interaction entre les départements, fixerons les responsabilités dans les réglementations de l'entreprise, etc.
Vous devez d'abord examiner tous les documents disponibles qui établissent la procédure d'octroi de l'accès et des droits. Dans le bon sens, les processus doivent être documentés à plusieurs niveaux :
- exigences générales de l'entreprise ;
- exigences pour les domaines de la sécurité de l'information (dépend des activités de l'organisation);
- exigences relatives aux processus technologiques (instructions, matrices d'accès, lignes directrices, exigences de configuration).
Dans notre société financière, nous avons trouvé de nombreux documents obsolètes - nous avons dû les mettre en conformité avec les nouveaux processus mis en place.
Sur ordre de la direction, un groupe de travail a été créé, qui comprenait des représentants des domaines de la sécurité, de l'informatique, des affaires et du contrôle interne. L'arrêté décrivait les objectifs de création du groupe, la direction de l'activité, la durée d'existence et les responsabilités de chacun. De plus, nous avons développé une méthodologie d'audit et une procédure de construction d'un modèle : elles ont été convenues par tous les représentants responsables des domaines et approuvées par la direction de l'entreprise.
Documents décrivant la procédure d'exécution des travaux, les délais, les responsabilités, etc. - une garantie que sur le chemin vers l'objectif chéri, qui au début n'est pas évident pour tout le monde, personne ne se posera de questions « pourquoi faisons-nous cela, pourquoi en avons-nous besoin, etc. » et il n’y aura aucune possibilité de « sauter » ou de ralentir le processus.
Étape 4. Correction des paramètres du modèle de contrôle d'accès existant
Nous élaborons ce que l'on appelle le « passeport système » en matière de contrôle d'accès. Il s'agit en fait d'un questionnaire sur un système d'information spécifique, dans lequel sont enregistrés tous les algorithmes de gestion des accès à celui-ci. Les entreprises qui ont déjà mis en œuvre des solutions de classe IdM connaissent probablement un tel questionnaire, puisque c'est par lui que commence l'étude des systèmes.
Certains paramètres concernant le système et les propriétaires ont été intégrés au questionnaire du registre informatique (voir étape 2, audit), mais de nouveaux ont été ajoutés :
- comment les comptes sont gérés (directement dans la base de données ou via les interfaces du programme) ;
- comment les utilisateurs se connectent au système (en utilisant un compte distinct ou en utilisant un compte AD, LDAP, etc.) ;
- quels niveaux d'accès au système sont utilisés (niveau application, niveau système, utilisation des ressources de fichiers réseau par le système) ;
- description et paramètres des serveurs sur lesquels le système fonctionne ;
- quelles opérations de gestion de compte sont prises en charge (blocage, renommage, etc.) ;
- quels algorithmes ou règles sont utilisés pour former l'identifiant de l'utilisateur du système ;
- quel attribut peut être utilisé pour établir un lien avec un enregistrement concernant un employé dans le système du personnel (nom complet, matricule, etc.) ;
- tous les attributs de compte possibles et les règles pour les remplir ;
- quels droits d'accès existent dans le système (rôles, groupes, droits atomiques, etc., existe-t-il des droits imbriqués ou hiérarchiques) ;
- des mécanismes de séparation des droits d'accès (par postes, divisions, fonctionnalités, etc.) ;
- si le système comporte des règles de séparation des droits (SOD - Ségrégation des tâches) et comment elles fonctionnent ;
- comment les événements d'absence, de transfert, de licenciement, de mise à jour des données des employés, etc. sont traités dans le système.
La liste pourrait être longue, détaillant les différents paramètres et autres entités impliqués dans le processus de contrôle d'accès.
Étape 5 : Créer une description d'autorisation orientée entreprise
Un autre document dont nous aurons besoin lors de la construction d'un modèle de rôle est un guide de tous les pouvoirs (droits) possibles qui peuvent être accordés aux utilisateurs d'un système d'information avec une description détaillée de la fonction commerciale qui le sous-tend. Souvent, les pouvoirs du système sont cryptés avec certains noms, composés de lettres et de chiffres, et les employés de l'entreprise ne peuvent pas comprendre ce qui se cache derrière ces caractères. Ensuite, ils se rendent au service informatique, et là... ils ne peuvent pas non plus répondre à la question, par exemple, sur les droits rarement utilisés. Ensuite, vous devez faire plus de tests.
C'est bien s'il existe déjà une description d'entreprise ou même s'il existe une association de ces droits en groupes et rôles. Pour certaines applications, la meilleure pratique consiste à créer un tel guide au stade du développement. Mais cela n'arrive pas souvent, alors encore une fois nous nous tournons vers le service informatique pour collecter des informations sur tous les droits possibles et les décrire. Notre guide contiendra à terme les éléments suivants :
- le nom de l'autorité, y compris l'objet auquel s'applique le droit d'accès ;
- l'action qu'il est permis d'effectuer avec l'objet (visualisation, modification, etc., possibilité de restriction, par exemple, sur une base territoriale ou sur un groupe de clients) ;
- code d'autorité (code et nom de la fonction/demande système qui peut être exécutée à l'aide de l'autorité) ;
- description de l'autorité (une description détaillée des actions dans le SI lors de l'application de l'autorité et de leurs conséquences sur le processus ;
- statut de l'autorisation : "Active" (si l'autorisation est attribuée à au moins un utilisateur) ou "Non actif" (si l'autorisation n'est pas utilisée).
Étape 6 Nous déchargeons les données sur les utilisateurs et les droits des systèmes et les comparons avec la source du personnel
Au stade final de la préparation, vous devez télécharger les données des systèmes d'information sur tous les utilisateurs et les droits dont ils disposent actuellement. Deux scénarios sont ici possibles. Premièrement, le service de sécurité a un accès direct au système et dispose des moyens de télécharger les rapports pertinents, ce qui est rare, mais très pratique. Deuxièmement : nous envoyons une demande au service informatique pour recevoir des rapports dans le format requis. La pratique montre qu'il n'est pas possible de négocier avec l'informatique et d'obtenir les données nécessaires du premier coup. Il est nécessaire de procéder à plusieurs démarches jusqu'à ce que l'information soit reçue sous la forme et le format souhaités.
Quelles données doivent être téléchargées :
- Nom du compte
- Nom du salarié à qui il est attribué
- Statut (actif ou désactivé)
- Date de création du compte
- Date de la dernière utilisation
- Liste des droits/groupes/rôles disponibles
Nous avons donc reçu des déchargements du système avec tous les utilisateurs et avec tous les droits qui leur sont accordés. Et ils ont immédiatement mis de côté tous les comptes bloqués, puisque le travail de construction d'un modèle ne sera effectué que pour les utilisateurs actifs.
Ensuite, si votre entreprise ne dispose pas de moyens automatisés de fermeture d'accès aux salariés licenciés (ce qui n'est pas rare) ou s'il existe une automatisation disparate qui ne fonctionne pas toujours correctement, vous devez identifier toutes les « âmes mortes ». Nous parlons des comptes d'employés déjà licenciés, dont les droits, pour une raison quelconque, ne sont pas bloqués - ils doivent être bloqués. Pour ce faire, nous comparons les données téléchargées avec la source du personnel. Le déchargement du personnel doit également être obtenu au préalable auprès de l'unité dirigeant la base du personnel.
Séparément, il est nécessaire de mettre de côté les comptes dont les propriétaires n'ont pas été trouvés dans la base du personnel, qui ne sont attribués à personne, c'est-à-dire sans propriétaire. Pour cette liste, nous avons besoin de la date de la dernière utilisation : si elle est assez récente, alors il faut encore rechercher les propriétaires. Cela peut inclure des comptes de sous-traitants externes ou des comptes de service qui ne sont attribués à personne, mais qui sont associés à des processus. Pour clarifier la propriété du compte, vous pouvez envoyer des lettres à tous les services avec une demande de réponse. Lorsque les propriétaires sont trouvés, nous saisissons les données les concernant dans le système : de cette manière, tous les comptes actifs sont identifiés et les autres sont bloqués.
Dès que nos téléchargements sont débarrassés des enregistrements inutiles et qu'il ne reste que des comptes actifs, nous pouvons commencer à construire un modèle pour un système d'information spécifique. Mais j'en parlerai dans le prochain article.
Auteur : Lyudmila Sevastyanova, responsable de la promotion de Solar inRights
Source: habr.com