Ayant combiné mon expérience acquise chez le client avec les connaissances et les compétences des fournisseurs, je souhaite partager avec vous des instructions essentiellement é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 à la fin. Mon instruction se compose de deux parties: premièrement - nous nous préparons à construire un modèle, deuxièmement - nous construisons réellement. Voici la première partie, préparatoire.
NB Construire un modèle de rôle n'est malheureusement pas un résultat, mais un processus. Ou plutôt, même partie du processus de création d'un écosystème de contrôle d'accès dans l'entreprise. Alors restez connecté pour le long terme.
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), dont chacun dispose de dizaines de droits d'accès à des centaines de systèmes d'information (objets) intra-bancaires. Maintenant, multipliez le nombre d'objets par le nombre de sujets - c'est le nombre minimum de connexions que vous devez d'abord créer, puis contrôler. Est-il réaliste 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 d'une à plusieurs autorisations accordées à un utilisateur au sein de ce rôle. Les rôles peuvent être liés à des postes, des services ou des tâches fonctionnelles spécifiques 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. Ensuite, les rôles commerciaux mondiaux sont formés à partir des rôles de chaque système. Par exemple, un rôle commercial de gestionnaire de crédit comprendrait plusieurs rôles distincts dans les systèmes d'information utilisés dans le bureau client d'une banque. Par exemple, dans le système bancaire automatisé principal, le module de caisse, le système de gestion électronique de documents, le gestionnaire de services et autres. Les rôles d'entreprise, en règle générale, sont liés à la structure organisationnelle et du personnel - en d'autres termes, à l'ensemble des services de l'entreprise et des postes qu'ils occupent. C'est ainsi que se forme la matrice de rôle globale (je donne un exemple dans le tableau ci-dessous).
Il est à noter qu'il est tout simplement impossible de construire un modèle à 100%, offrant tous les droits nécessaires aux employés de chaque poste dans une structure commerciale. Oui, ce n'est pas nécessaire. Après tout, un modèle de rôle ne peut pas être statique, car il dépend d'un environnement en constante évolution. Et du changement dans les activités commerciales de l'entreprise, qui, en conséquence, affecte le changement dans la structure organisationnelle et la fonctionnalité. Et du manque de mise à disposition complète des ressources, et du non-respect des descriptions de poste, et du désir de profit au détriment de la sécurité, et de nombreux autres facteurs. Par conséquent, il est nécessaire de construire un modèle de rôle pouvant couvrir jusqu'à 80% des besoins des utilisateurs pour les droits de base nécessaires lorsqu'ils sont nommés à un poste. Et ils pourront, si nécessaire, demander les 20% restants plus tard sur des demandes distinctes.
Bien sûr, vous pouvez demander: "Quoi, il n'y a pas de modèles à 100%?" Eh bien, pourquoi cela se produit-il, par exemple, dans des structures à but non lucratif qui ne sont pas soumises à de fréquents changements - 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 passe également dans une structure commerciale, mais dans le cadre d'une unité distincte, dont le travail est un processus assez statique et prévisible.
Le principal avantage de la gestion des rôles est la simplification de l'octroi des droits, car le nombre de rôles est nettement inférieur à celui des utilisateurs du système d'information. Et cela est vrai pour n'importe quel secteur.
Prenons une entreprise de vente au détail: elle emploie des milliers de vendeurs, mais ils ont le même ensemble de droits dans le système N, et un seul rôle sera créé pour eux. Un nouveau vendeur est venu dans l'entreprise - on lui a automatiquement attribué le rôle nécessaire dans le système, qui dispose déjà de tous les pouvoirs nécessaires. Vous pouvez également modifier les droits de milliers de vendeurs en un seul clic, par exemple, ajouter une nouvelle option pour générer un rapport. Vous n'avez pas besoin de faire mille opérations, en associant un nouveau droit à chaque compte - il vous suffit d'ajouter 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 l'élimination de la délivrance de pouvoirs incompatibles. Autrement dit, un employé qui a un certain rôle dans le système ne peut pas simultanément avoir un autre rôle, dont les droits ne devraient 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.
Toute personne intéressée par la manière dont le contrôle d'accès basé sur les rôles est né peut
plongez dans l'histoire
, - 70- XX . , , , . , – , . , , .
, . , .
, , – () (DAC – Discretionary access control). . . . : .
– (MAC — Mandatory access control). . . , , , . , : , , .
- , - . ! , , .
1992 . RBAC (Role-based access control). , INCITS 359-2012, (INCITS).
« , , ». RBAC – , , , , , .
– . , . , , . , , .. «», . «».
, . . ( , ). , , (/ ), (/) ..
(ABAC — Attribute-based access control). . , : , , . , , , , .
, , . . , , . , - .
ABAC « ». . , . – , ! , , . , .
, . , .
, , – () (DAC – Discretionary access control). . . . : .
– (MAC — Mandatory access control). . . , , , . , : , , .
- , - . ! , , .
1992 . RBAC (Role-based access control). , INCITS 359-2012, (INCITS).
« , , ». RBAC – , , , , , .
– . , . , , . , , .. «», . «».
, . . ( , ). , , (/ ), (/) ..
(ABAC — Attribute-based access control). . , : , , . , , , , .
, , . . , , . , - .
ABAC « ». . , . – , ! , , . , .
Parlons maintenant des étapes préparatoires nécessaires, sans lesquelles il est tout simplement impossible de construire un modèle de rôle fonctionnel.
Étape 1. Créez 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 service et de chaque poste. En règle générale, les informations y parviennent à partir de divers documents: descriptions de poste et règlements pour les divisions individuelles - départements, départements, départements. Le modèle fonctionnel doit être convenu avec tous les services intéressés (affaires, 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 créer un modèle de rôle basé sur les droits des employés existants - déchargés du système et «amenés à un dénominateur commun». Ensuite, lors de la coordination des rôles reçus avec le responsable métier 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.
2. -
La deuxième étape consiste à réaliser un audit des systèmes informatiques pour comprendre comment leur accès est organisé. Par exemple, ma société financière exploitait plusieurs centaines de systèmes d'information. Tous les systèmes avaient quelques rudiments de gestion basée sur les rôles, la plupart d'entre eux avaient une sorte de rôle, mais principalement sur papier ou dans le manuel du système - ils étaient obsolètes il y a longtemps et leur accès était distribué sur la base des 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 procédé à un examen approfondi du processus de contrôle d'accès pour déterminer son niveau de maturité. Au cours de l'analyse, des critères de hiérarchisation des systèmes d'information ont été élaborés - criticité, disponibilité, plans de déclassement, etc.Avec leur aide, nous avons construit une séquence pour le développement / la mise à jour de modèles de rôle pour ces systèmes. Ensuite, nous avons inclus des modèles de rôle dans notre plan d'intégration de gestion des identités pour automatiser le contrôle d'accès.
Alors, comment déterminez-vous la criticité d'un système? Répondez 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 maximal autorisé du système, après lequel 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 avoir des conséquences irréversibles, tant financières que réputationnelles?
- Criticité de la fraude. Disponibilité de fonctionnalités, dont le contrôle est insuffisant, il est possible de mener des actions frauduleuses internes / externes;
- Quelles sont les exigences légales, ainsi que les règles et procédures internes pour ces systèmes? Y aura-t-il des amendes de la part des régulateurs pour non-conformité?
Dans notre société financière, nous avons effectué un audit comme suit. La direction a développé un processus 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 les plus prioritaires. L'unité de sécurité a été désignée 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 commerciaux dans le processus. Et puis des disputes, des malentendus, et parfois même des sabotages ont commencé: personne ne veut rompre avec ses fonctions actuelles et s'impliquer dans des activités incompréhensibles à première vue.
NB - - – IT general controls (ITG), - , best practice (ITIL, COBIT, IT Governance .) , , , .
Un des domaines d'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 avons obtenu 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 de la ligne métier a été identifié, dans l'intérêt duquel il était opéré: c'était lui qui était responsable des processus métiers que servait ce système. 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 conditions de mise en service et de démantèlement, etc. ont été enregistrés.Ces paramètres ont été très utiles pour préparer la construction du modèle de rôle.
Étape 3 Créer une méthodologie
La clé du succès de toute entreprise est la bonne méthode. Par conséquent, à la fois pour construire un modèle de rôle et pour mener un audit, nous devons créer une méthodologie dans laquelle nous décrivons l'interaction entre les services, fixons la responsabilité dans les règlements de l'entreprise, etc.
Tout d'abord, vous devez examiner tous les documents disponibles établissant la procédure d'octroi d'accès et de droits. De manière amiable, les processus doivent être documentés à plusieurs niveaux:
- les exigences générales de l'entreprise;
- les exigences relatives aux domaines de la sécurité de l'information (en fonction des domaines d'activité de l'organisation);
- les exigences des processus technologiques (instructions, matrices d'accès, directives, exigences pour les configurations).
Dans notre société financière, nous avons trouvé de nombreux documents périmés - nous avons dû les apporter conformément aux 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'ordre décrivait les objectifs de création du groupe, la direction de l'activité, la période d'existence et les personnes responsables de chaque côté. De plus, nous avons développé une méthodologie pour réaliser un audit et une procédure de construction d'un modèle: elles ont été approuvées 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 modalités, la responsabilité, etc. - une garantie que sur le chemin de l'objectif chéri, qui au début n'est pas évident pour tout le monde, personne n'aura 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. Fixez les paramètres du modèle de contrôle d'accès existant
Nous élaborons le soi-disant «passeport système» en termes de contrôle d'accès. En fait, il s'agit d'un questionnaire pour un système d'information spécifique, dans lequel tous les algorithmes de contrôle d'accès à celui-ci sont enregistrés. Les entreprises qui ont déjà implémenté des solutions IdM sont probablement familières avec un tel questionnaire, car c'est avec lui que commence la recherche sur les systèmes.
Certains des paramètres concernant le système et les propriétaires ont été intégrés au questionnaire à partir du registre informatique (voir étape 2, audit), mais de nouveaux ont également été ajoutés:
- comment les comptes sont gérés (directement dans la base de données ou via des interfaces logicielles);
- comment les utilisateurs se connectent au système (en utilisant un compte séparé ou en utilisant un compte AD, LDAP, etc.);
- quels niveaux d'accès au système sont utilisés (niveau d'application, niveau système, utilisation par le système des ressources de fichiers réseau);
- , ;
- (, ..);
- ;
- (, .);
- ;
- (, , ., );
- ( , , .);
- (SOD – Segregation of Duties), ;
- , , , ..
La liste s'allonge encore et encore, détaillant les différents paramètres et autres objets impliqués dans le processus de contrôle d'accès.
Étape 5. Créez une description d'autorisation orientée métier
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 fournis aux utilisateurs dans le système d'information avec une description détaillée de la fonction commerciale qui le sous-tend. Souvent, l'autorité dans le système est cryptée 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 symboles. Ensuite, ils vont 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 effectuer des tests supplémentaires.
C'est bien si la description de l'entreprise existe déjà ou même s'il existe une combinaison de ces droits en groupes et en rôles. Pour certaines applications, il est recommandé de créer une telle référence au stade de la conception. Mais cela arrive rarement, alors nous nous adressons à nouveau au service informatique pour collecter des informations sur tous les droits possibles et les décrire. Notre guide contiendra éventuellement 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 de faire avec l'objet (visualisation, modification, etc., possibilité de restriction, par exemple, par une base territoriale ou par un groupe de clients);
- code d'autorisation (code et nom de la fonction / demande système qui peut être exécutée à l'aide de l'autorisation);
- description de l'autorité (description détaillée des actions dans le SI lors de l'application de l'autorité et de leurs conséquences pour le processus;
- : «» ( ) « » ( ).
6
Au stade final de la préparation, vous devez télécharger des données des systèmes d'information sur tous les utilisateurs et les droits dont ils disposent actuellement. Deux scénarios sont possibles ici. Premièrement, le service de sécurité a un accès direct au système et dispose d'un moyen 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 le service informatique et d'obtenir les données nécessaires du premier coup. Plusieurs approches doivent être adoptées jusqu'à ce que les informations soient reçues sous la forme et le format souhaités.
Quelles données doivent être téléchargées:
- Nom du compte
- Nom complet de l'employé à qui il est affecté
- Statut (actif ou verrouillé)
- Date de création du compte
- Date de la dernière utilisation
- Liste des droits / groupes / rôles disponibles
Ainsi, nous avons reçu des déchargements du système avec tous les utilisateurs et avec tous les droits qui leur ont été accordés. Et mettez immédiatement de côté tous les comptes bloqués, car le travail de création d'un modèle de rô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 employés licenciés (c'est souvent le cas) ou s'il existe une automatisation patchwork 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 ne sont pas bloqués pour une raison quelconque - 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é qui dirige la base du personnel.
Séparément, il est nécessaire de reporter les comptes, dont les propriétaires n'ont pas été trouvés dans la base du personnel, ni attribués à personne - c'est-à-dire sans propriétaire. Selon cette liste, nous avons besoin de la date de la dernière utilisation: si elle est assez récente, nous devons 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 connaître la propriété des comptes, vous pouvez envoyer des lettres à tous les départements 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 existants sont identifiés et les autres sont bloqués.
Dès que nos téléchargements sont effacés des enregistrements inutiles et qu'il ne reste plus que des comptes actifs, vous pouvez commencer à créer un modèle de rôle pour un système d'information spécifique. Mais j'en parlerai dans le prochain article.
Auteur: Lyudmila Sevastyanova, Responsable de la promotion, Solar inRights