Nous introduisons IdM. Vue de l'ingénieur d'implémentation

Plus tôt, nous avons parlé de ce qu'est l'IdM, pourquoi il est nécessaire , comment justifier financièrement sa mise en œuvre , etc. Aujourd'hui, nous allons parler des pièges qui peuvent survenir lors de la mise en œuvre du système, et comment les contourner et ne pas vous procurer beaucoup de cônes. Supposons que nous sachions que dans notre entreprise il y a des problèmes que nous pourrions et voudrions résoudre en utilisant IdM. La solution à ces problèmes dans notre entreprise est économiquement justifiée, car elle soulagera sérieusement le service informatique, augmentera les indicateurs de performance de l'entreprise dans son ensemble en économisant le temps et les ressources nécessaires pour préparer l'espace de travail pour les nouveaux employés, et en coordonnant et en gérant les pouvoirs des anciens. Et les employés du SI après l'introduction d'IdM seront au septième ciel, générant une masse de divers rapports sur le bouton, ce qui simplifiera grandement leur vie lors des audits de sécurité, pour le plus grand plaisir d'eux-mêmes et de la direction. Et la décision a été prise - "Prenez!".

Nous formulons des exigences fonctionnelles

La première chose à faire est de rédiger un document intitulé «Exigences fonctionnelles». Je pense que l'importance de la disponibilité et de l'alphabétisation du contenu de ce document ne fait aucun doute. Idéalement, il doit être prêt avant de choisir une solution spécifique. Il est clair que lors des tests pilotes et lors des événements de prévente à plusieurs reprises, différentes personnes ont été discutées et ont expliqué ce qui devait être fait. Néanmoins, la portée du projet doit être clairement définie et fixée sur papier. Les exigences fonctionnelles sont une sorte de point de départ à partir duquel une compréhension mutuelle sera établie entre tous les participants au processus, à la fois de la part du client et de l'entrepreneur.

La fonctionnalité requise du système doit être justifiée logiquement et financièrement, mise en œuvre et cohérente avec ses capacités. Il s'agit essentiellement d'une description de haut niveau des processus métier qui doivent être automatisés à l'aide de l'implémentation IdM.

Prenons un exemple simple pour plus de clarté. Imaginez que vous ayez besoin d'automatiser les processus de personnel suivants:

• Admission d'un nouvel employé (création de comptes avec droits principaux, selon le poste et l'unité).
• Demande de nouveaux justificatifs d'identité pour les salariés (coordination, exécution automatique et semi-automatique des candidatures).
• Transfert d'un salarié à un poste (attribution de pouvoirs correspondant à un nouveau poste, confirmation ou révocation d'anciens pouvoirs).
• Licenciement d'un employé (blocage de tous ses comptes avec rappel de tous les rôles).

Dans le processus Exigences fonctionnelles pour le processus d' acceptation des nouveaux employés , il convient d'écrire ce qui suit: le système lit les informations sur le nouvel employé dans le système du personnel, crée un compte dans Active Directory (AD), attribue les groupes requis par poste, crée un compte dans CRM, attribue un profil et des rôles conformément aux fonctions officielles.

Il n'est pas nécessaire d'y entrer l'obligation de préparer du café au PDG lorsqu'il entre dans le bureau. Ce n'est pas une fonctionnalité IdM, bien qu'avec une API, la cafetière soit également réalisable :)

Nous dessinons un diagramme de l'interaction des composants du système

À ce stade, en plus des processus réellement automatisés, les principaux systèmes intégrables sont identifiés, les départements intéressés sont identifiés et la place globale de l'IdM dans l'environnement d'information interne de l'entreprise est estimée. Les ressources nécessaires pour soutenir IdM sont également déterminées, la portée du projet devient visible, les étapes et les dates de mise en œuvre sont approximativement déterminées.

Nous avons donc réalisé que pour la mise en œuvre de ces processus automatisés dans la première étape, vous devez vous intégrer à seulement trois systèmes:

• avec le système du personnel 1C: ZUP,
• avec Microsoft Active Directory en tant que principal fournisseur de privilèges utilisateur dans l'infrastructure d'entreprise,
• avec le principal système d'affaires CRM écrit et maintenu par un fournisseur tiers dans le cadre de la commande.

Vous devez immédiatement imaginer le schéma d'interaction des composants du futur système.

Comme vous pouvez le voir, IdM est au centre, et ce n'est pas un hasard. Après la mise en œuvre, IdM sera «l'alpha et l'oméga» qui contiennent toutes les informations pertinentes sur les employés de l'entreprise, tous leurs comptes dans les systèmes intégrés IdM et quels rôles, groupes et autorités les employés devraient avoir dans ces systèmes. C'est grâce aux «tentacules» de l'IdM qui pénètrent dans tous les systèmes qui lui sont liés que le transfert d'Ivanov Sergey Petrovich du service comptable au service juridique de l'entreprise automatiquement enregistré dans le système d'information du personnel changera automatiquement les groupes et les attributs de son compte dans AD et changera ses rôles et profils dans d'autres systèmes d'entreprise, avec le lancement automatique de tous les processus d'approbation et de notification nécessaires. Mais tout cela ne fonctionnera que lorsque tous les composants du système seront bien et correctement intégrés les uns aux autres. Et pour que cela se produise, je le répète, vous devez bien réfléchir et tout concevoir.

Avec ce bagage, nous sortons pour un achat.

Ainsi, la solution IdM est sélectionnée, l'entrepreneur de mise en œuvre est défini, les licences sont achetées, le travail est payé, il est temps de la mettre en œuvre. Nous verrons plus loin comment faire en sorte que toutes les bonnes entreprises ne meurent pas sans vraiment naître.

Nous créons une équipe de projet et réalisons une enquête d'avant-projet

La première chose à faire immédiatement après l'achat d'IdM (sans compter la levée solennelle du verre pour la transaction) est de créer une équipe de projet. Oui, l' équipe de projet de la part du client doit l'être. Le succès de l'ensemble de l'événement dépend de sa composition. Il devrait comprendre des représentants de tous les départements intéressés qui ont les pouvoirs nécessaires et suffisants pour résoudre rapidement divers problèmes de nature principalement technique qui surviennent pendant la mise en œuvre.

Vient ensuite le temps de l'enquête de pré-conception - l'étape la plus importante, nécessitant une grande immersion dans les activités de conception principalement du client.

Ici, les pouvoirs très nécessaires et suffisants des participants de l'équipe de projet du client seront nécessaires pour collecter et fournir au contractant toutes les informations nécessaires sur la structure interne des processus de l'entreprise. Il s'agit de la structure interne des processus de l'entreprise! Chaque processus automatisé décrit dans les exigences fonctionnelles doit faire l'objet d'une enquête approfondie du début à la fin. Qui effectue la collecte initiale des informations, leur composition et leur format, dans quel système les informations sont-elles entrées, dans lesquelles elles sont transmises, comment, par quels protocoles, avec quel logiciel? Qui a besoin de ces informations pour d'autres activités, et sous quelle forme en a-t-il besoin, où il devrait y avoir des traces des opérations effectuées ... En un mot, tout, tout, tout ce qui concerne chaque processus enquêté.

Nous écrivons TK

À la sortie de l'enquête d'avant-projet, un document plus important du point de vue de la mise en œuvre (encore plus important que les exigences fonctionnelles) devrait être obtenu - les Termes de Référence (TDR). Que devrait-il contenir? Il est important de ne rien manquer et de bien réfléchir à tout. Parce que l'omission de petites nuances apparemment insignifiantes peut entraîner de gros problèmes lors de la mise en œuvre.

À cet égard, lors de la conception d'une solution d'implémentation en savoirs traditionnels, la première chose à faire est de bien analyser les processus automatisés eux-mêmes. Presque les mêmes que dans les exigences fonctionnelles, mais plus en détail, avec des détails, couvrant tout le cycle de vie des informations entrant dans l'entrée de chaque processus jusqu'à leur sortie.

Par exemple, le processus du personnel. L'admission d'un nouvel employé dans les TdR ressemblera à ceci:

1. Un employé des RH saisit des informations sur un nouvel employé dans le système 1C: ZUP HR. Obligatoire remplit les champs suivants: ... (il est répertorié lesquels).
2. IdM reçoit des données sur un nouvel employé du système personnel 1C: ZUP, détermine le poste et l'unité du nouvel employé. Crée un nouveau profil d'employé dans IdM. L'identifiant est formé selon telle ou telle règle, le mot de passe selon telle et telle. Les informations de connexion pour le mot de passe du nouvel employé sont envoyées ici et là via ces canaux de communication (indiquez d'où IdM obtient l'adresse).
3. IdM crée automatiquement un compte dans AD avec les attributs (liste) dans le répertoire (OU - Unité d'organisation) correspondant à l'unité du nouvel employé. L'identifiant est formé selon telle ou telle règle, le mot de passe selon telle et telle. Les données sur le login et le mot de passe du nouvel employé sont envoyées ici et là via ces canaux de communication (indiquer d'où IdM obtient le destinataire et les paramètres du canal de communication).
4. Le compte AD créé est placé dans des groupes (nous listons ou indiquons «selon le modèle de rôle»). Le modèle de rôle devra également être pensé et décrit dans un mandat dans un chapitre distinct. La nomination de ces groupes se fait en accord avec ces personnes (nous listons). Le système génère des notifications sur l'attribution des pouvoirs à un nouvel employé (spécifiez l'algorithme d'identification du destinataire; décrivez séparément les itinéraires d'approbation), ainsi que des rappels au coordinateur sur la nécessité de coordonner l'application (spécifiez les algorithmes d'identification du destinataire, le début, la fin et la fréquence des rappels).
5. Après avoir créé un compte dans AD, IdM lance la création d'une boîte aux lettres Exchange pour le nouvel employé. Les informations sur la nouvelle boîte aux lettres sont stockées dans IdM et affichées sur la carte de l'employé.

Dans la même veine, nous décrivons l'interaction du système avec CRM ...

Ainsi, lors de l'examen des processus automatisés de cette manière, le modèle d'objet de chaque système, la composition des attributs de chaque type d'objets devient claire, une image du mouvement et de la transformation des données entre les attributs de divers objets est formée. De plus, les connexions entre les objets deviennent visibles, des processus supplémentaires sont révélés, tels que le maintien de la cohérence des données dans tous les systèmes.

Un exemple simple: lors du changement du nom de l'employé dans le système du personnel, son nom doit changer dans les profils de tous les autres systèmes connectés à IdM. Mais cela peut ne pas changer, car dans certains systèmes, le nom n'est tout simplement pas enregistré.

Un exemple est plus compliqué: l'exigence est que le compte AD d'un nouvel employé soit créé dans l'OU correspondant à son unité. La question se pose, que faire si une nouvelle unité est établie dans le système du personnel, mais qu'elle n'a pas encore été créée en AD? Ainsi, un processus distinct de reproduction de la structure organisationnelle stockée dans le système du personnel dans AD est révélé, ce qui mérite également d'être décrit dans les TdR.

S'intègre aux systèmes

Comme vous pouvez le voir, la formation des savoirs traditionnels est un processus itératif. Après avoir identifié les objets et les actions qui doivent être exécutés avec eux, il devient clair l'ensemble des fonctions qui doivent être implémentées dans le connecteur du système intégré. Et ici, nous avons abordé en douceur une autre étape importante de la mise en œuvre d'IdM - l' intégration réelle avec les systèmes . En vérité, cette étape peut être très pénible à la fois pour l'intégrateur IdM et pour l'entreprise dans laquelle l'infrastructure IdM est en cours de mise en œuvre.

Pour qu'il ne se passe rien de mal, vous devez comprendre quelques principes généraux qui s'appliquent lors de l'intégration de divers produits logiciels. Tout d'abord, vous devez comprendre l'importance d'avoir une API dans un système intégré pour s'intégrer à IdM. Le connecteur et l'API sont deux choses différentes. Si l'intégrateur dit qu'il a des connecteurs sur divers systèmes ou qu'il est prêt à écrire un connecteur sur n'importe quel système, cela ne signifie pas que le problème d'intégration est complètement résolu et que l'entreprise cliente n'a rien à faire à ce sujet.

Je vais vous expliquer avec un exemple. Afin de connecter une centrale électrique à un fer à repasser afin de chauffer ce dernier dans le but de remplir ses fonctions connues, il est nécessaire que la centrale électrique dispose d'une prise et le fer à repasser d'une fiche. Prise et fiche. 2 choses. Pas un. À l'aide d'une prise sur le côté de la centrale et d'une prise sur le côté du fer, le fer est intégré au système d'alimentation. Dans le cas d'une intégration IdM avec n'importe quel autre système, 2 choses sont également nécessaires: un connecteur côté IdM et une API côté système. C'est important! Sinon, divers incidents désagréables peuvent se produire. Le connecteur a uniquement pour objet de recevoir les données nécessaires du système sous la forme dans laquelle il les envoie et de les transférer vers IdM sous la forme dans laquelle IdM peut les recevoir. Le même connecteur fait dans le sens opposé: il reçoit une commande et un ensemble de données d'IdM sous la forme dans laquelle IdM les émet et transfère tout cela au système sous la forme dans laquelle le système comprend ce qu'il doit faire. MAIS! Le système devrait, en principe, être capable de produire les données nécessaires à IdM et d'exécuter les commandes nécessaires pour travailler en tandem avec IdM. C'est le but principal de l'API - fournir une interface sur laquelle IdM peut agir avec un connecteur pour effectuer diverses opérations sur le système.

Habituellement, avant même la vente d'IdM, un intégrateur consciencieux se concentre sur la nécessité pour le client de fournir une API pour tous les systèmes connectés à IdM et signale les exigences pour la mise en œuvre de ces API. Il s'agit essentiellement d'une énumération de fonctions avec des paramètres d'entrée et de sortie. Par exemple:

• Recherchez tous les comptes système. Il n'y a pas de paramètres d'entrée. Le résultat est une liste de tous les comptes avec tous leurs attributs.
• Recherchez un compte par ID. Le paramètre d'entrée est l'identifiant de l'échographie. Déconnexion - un compte qui répond aux critères de recherche, avec tous les attributs.
• Créez un compte. Paramètres d'entrée - login, mot de passe, nom complet ... Quitter - identifiant de la nouvelle échographie.
• Verrouillage du compte. Paramètres d'entrée - identifiant de l'échographie. Il n'y a pas de paramètres de sortie.
• Et ainsi de suite ...

En d'autres termes, une API est un ensemble de fonctions nécessaires pour interagir avec IdM. Le problème est qu'une partie de ces fonctions dans le système peut ne pas être implémentée du tout sous la bonne forme. Tout simplement parce que ce n'était pas encore nécessaire. Une partie peut être implémentée, mais comme un processus complexe, à plusieurs niveaux, étape par étape. Par exemple, dans un système bancaire national automatisé, la création d'un compte utilisateur est précédée par le remplissage de trois répertoires différents avec un tas d'attributs et d'indicateurs auxiliaires. Ou, certaines fonctions peuvent être implémentées sous une forme simple, mais non publiées, c'est-à-dire que les fonctions ne peuvent pas être utilisées de l'extérieur. L'API est donc conçue pour résoudre tous ces problèmes. Les API sont des fonctions qui effectuent les opérations nécessaires à l'intégration d'un système intégré avec IdM, sous la forme correcte et fonctionnant correctement, publiées pour leur appel externe. Pour que tout ingénieur logiciel qui ne connaît pas la cuisine interne du système lui-même puisse les utiliser et faire facilement ce qui est nécessaire.

Ensuite, en règle générale, la question se pose pour les clients, ce qui provoque un mal de dents tenace pour un ingénieur d'implémentation IdM: pourquoi un intégrateur d'API ne peut-il pas implémenter un intégrateur IdM sur un système?

Imaginez un système de gestion d'entreprise complexe dans lequel la gestion des droits des utilisateurs doit maintenant être implémentée à l'aide d'IdM. Le vendeur a écrit ce système depuis les années 90. Au cours d'une longue vie, son architecture a changé quatre fois. Le sous-système de gestion des droits des utilisateurs n'a pas pu suivre le développement rapide de la fonctionnalité du système lui-même et a été mis en œuvre par plusieurs générations de programmeurs selon leur compréhension pas toujours logique et raisonnable selon le principe de «comment je l'ai compris moi-même», c'est-à-dire de manière béquille. Il n'est pas nécessaire de parler de documenter toute cette action. Pour le moment, tout fonctionne d'une manière ou d'une autre. Les employés du vendeur montent dans l'ancien code de leur système avec réticence et appréhension uniquement en cas de besoin urgent de corriger un bug terrible, baptisant trois fois et arrosant le moniteur avec de l'eau bénite, recouvert de tambourins, alors Dieu interdit de ne casser aucune béquille, afin que tout ne tombe pas .



Et maintenant, la société cliente utilisant ce produit magique est venue le temps d'or pour implémenter IdM. Exigences API fournies, pas d'API. Le client se fiche de savoir qui écrira l'API. Il a frappé son poing sur la table avec les mots "Je pleure d’énormes millions, faites-le" et a quitté la réunion en claquant délibérément la porte. Le vendeur de logiciels magiques ne s'en soucie pas non plus. Il ne fera rien gratuitement, mais ils ont oublié de mettre de l'argent dans le budget pour la mise en œuvre de l'API pour des rêves arc-en-ciel vifs sur la façon dont tout sera cool après l'introduction d'IdM. En même temps, le contrat est signé, «l'argent a été payé», et le saut sauvage commence.

Le pauvre programmeur Pasha, un employé de l'intégrateur de l'IdM, essaie de comprendre convulsivement quels squats doivent être faits pour obtenir des réactions normales du système. Il étudie les sources publiques, la documentation avare et dépassée, comprend le code source d'un système inconnu et casse les téléphones du fournisseur. Après quelques semaines d'épreuves, il se rend compte que les squats ne suffisent pas, qu'il faut rebondir, et même des sauts périlleux, et non le fait que cela va aider non plus ... Et après un mois, un connecteur apparaît, une sorte de, plus ou moins fonctionnel. Légèrement dysfonctionnements, eh bien, comment c'est arrivé. Le pauvre programmeur Pacha du personnel de l'intégrateur est devenu gris en l'écrivant. Le système magique est intégré, mais le problème est que les comptes ne sont pas créés très correctement, et l'administrateur système doit manuellement «restaurer» le compte à l'état de fonctionnement. Les mots de passe changent une fois sur deux et la «chanceuse» Marina Ivanovna de la comptabilité continue de bloquer son compte. Les employés du "business" inondent le support technique de plaintes vicieuses: "Combien de temps ???", "Impossible de travailler!", "Faites comme ça ..." Au début, le client demande de tout réparer et frappe la table avec une pantoufle pour qu'elle atteigne le programmeur Pasha déjà chauve. Ensuite, en raison de défaillances fréquentes et d'un mécontentement croissant parmi les unités commerciales, l'intégration IdM avec le système magique est interrompue.

Et que ferez-vous ici? Qui est à blâmer? Si ce n'est pas un fournisseur de système, alors qui devrait trier tout le chaos qu'il a fait à partir des répertoires, des fonctions, des plaques, des déclencheurs, des drapeaux et des béquilles? Intégrateur IdM? Comment sait-il comment implémenter correctement une fonction dans un système qu'un fournisseur ne peut pas comprendre? Et si c'est le cas, alors pour de l'argent considérable? Oui, j'épaissis beaucoup mes couleurs maintenant; il existe des exceptions lorsque le système n'est pas très complexe et que vous pouvez l'intégrer sans API spéciale. Mais soyez raisonnable. Si l'objectif est d'éviter des problèmes inutiles, d'aider l'entreprise à croître et à réaliser des bénéfices (ce qui, à mon avis, est l'objectif principal du service informatique de toute entreprise) et de profiter du bon fonctionnement de tous les systèmes, réfléchissez aux moyens de s'intégrer aux systèmes. Mettre dans le budget les coûts nécessaires pour l'étude des opportunités d'intégration et la mise en œuvre compétente des composants manquants. Avaricious paie deux fois, voire trois fois. Enregistrer à la fin Programmateur Pasha: D. Il est presque chauve. Et n'oubliez pas de fixer les méthodes d'intégration dans TK!

Nous construisons un modèle de l'entreprise

Je voudrais également attirer une attention particulière sur la formation du modèle de rôle de l'entreprise . Le fait est que chaque système possède son propre ensemble exclusif d'entités dites "faisant autorité" - des objets qui fournissent des privilèges d'utilisateur dans le système. Toutes sortes de groupes, rôles, profils, objectifs, répertoires, privilèges, types d'opérations, etc. peuvent être attribués à cette catégorie d'objets ... La granulation des droits peut être très profonde, ce qui nous permet d'obtenir un très grand nombre d'objets gérés. Par exemple, certains groupes de sécurité dans AD peuvent être plusieurs centaines, voire des milliers. Dans certains systèmes de gestion financière, chaque utilisateur peut se voir attribuer des droits exclusifs sur chaque compte sur un million contenu dans le plan comptable. Et si nous nous intégrions à SAP? Le nombre de droits atomiques peut être mesuré en centaines de milliers voire en millions.

De plus, le système peut prendre en charge l'imbrication hiérarchique et les relations complexes entre différents types d'entités autorisées. Cela en soi s'appuie sur une étude distincte des possibilités de gestion des droits des utilisateurs dans le système. Par conséquent, avant de concevoir la mise en œuvre d'IdM dans votre maison, il est impératif, en fonction des objectifs du projet, de décider quels droits et à quel niveau de granularité vous allez gérer via IdM. L'essentiel est de s'arrêter à temps. Tout doit être nécessaire et suffisant. Si vous souhaitez gérer des droits d'utilisateur distincts pour chaque compte du système, préparez-vous à la quantité de travail appropriée pour coordonner et révoquer les droits d'utilisateur à chaque modification du plan comptable.

Lorsque vous travaillez sur un modèle de rôle, vous devez déterminer:

• D'où dans IdM les droits d'accès proviendront des objets, c'est-à-dire les rôles eux-mêmes. Le plus souvent, ils sont chargés à partir de systèmes gérés dans les étapes initiales de l'intégration.
• . IdM , « ».
• . .

, , . , : , , . : – 50% . , , , . IdM, .

. .

, Solar inRights