Apresentamos o IdM. Vista do engenheiro de implementação

Anteriormente, falamos sobre o que é o IdM, por que é necessário , como fundamentar financeiramente sua implementação etc. Hoje falaremos sobre quais armadilhas podem surgir durante a implementação do sistema e como contorná-las e não obter muitos cones. Suponha que saibamos que em nossa empresa existem alguns problemas que poderíamos e gostaríamos de resolver usando o IdM. A solução para esses problemas em nossa empresa é economicamente justificada, pois aliviará seriamente o departamento de TI, aumentará os indicadores de desempenho da empresa, economizando tempo e recursos necessários para preparar o espaço de trabalho para novos funcionários e coordenando e gerenciando os poderes dos antigos. E os funcionários da IS após a implementação do IdM estarão no sétimo céu, gerando uma tonelada de vários relatórios no botão, o que simplifica bastante suas vidas ao realizar auditorias de segurança, para deleite e gerenciamento. E a decisão foi tomada - "Pegue!".

Formulamos requisitos funcionais

A primeira coisa a fazer é elaborar um documento chamado "Requisitos funcionais". Penso que a importância da disponibilidade e alfabetização do conteúdo deste documento está fora de dúvida. Idealmente, ele deve estar pronto antes de escolher uma solução específica. É claro que, durante os testes-piloto e durante os eventos de pré-venda, muitas pessoas foram discutidas e explicaram o que precisava ser feito. No entanto, o escopo do projeto deve ser claramente definido e fixado no papel. Requisitos funcionais são um tipo de ponto de partida a partir do qual a compreensão mútua será construída entre todos os participantes do processo, tanto por parte do cliente quanto do contratado.

A funcionalidade necessária do sistema deve ser lógica e financeiramente justificada, implementada e consistente com seus recursos. Essa é essencialmente uma descrição de nível superior dos processos de negócios que precisam ser automatizados usando a implementação do IdM.

Considere um exemplo simples para maior clareza. Imagine que você precisa automatizar os seguintes processos de pessoal:

• Admissão de um novo funcionário (criação de contas com direitos primários, de acordo com o cargo e a unidade).
• Solicitação de novas credenciais para funcionários (coordenação, execução automática e semi-automática de aplicativos).
• Transferência de um funcionário para um cargo (emissão de poderes correspondentes a um novo cargo, confirmação ou revogação de poderes antigos).
• Demissão de um funcionário (bloqueando todas as suas contas com a retirada de todas as funções).

No processo Requisitos funcionais para o processo de aceitação de novos funcionários , vale a pena escrever o seguinte: o sistema lê informações sobre o novo funcionário do sistema de pessoal, cria uma conta no Active Directory (AD), atribui os grupos necessários por posição, cria uma conta no CRM, atribui um perfil e funções de acordo com os deveres oficiais.

Não há necessidade de inserir lá o requisito de preparar café ao CEO quando ele entrar no escritório. Este não é um recurso do IdM, embora, com uma API, a cafeteira também seja realizável :)

Desenhamos um diagrama da interação dos componentes do sistema

Nesse estágio, além dos processos realmente automatizados, os principais sistemas integráveis ​​são identificados, os departamentos interessados ​​e o local global do IDM no ambiente de informações internas da empresa. Os recursos necessários para dar suporte ao IDM também são determinados, o escopo do projeto fica visível, os estágios e as datas de implementação são aproximadamente determinados.

Portanto, percebemos que, para a implementação desses processos automatizados no primeiro estágio, você precisa se integrar com apenas três sistemas:

• com o sistema de pessoal 1C: ZUP,
• com o Microsoft Active Directory como o principal provedor de privilégios de usuário na infraestrutura corporativa,
• com o principal sistema comercial de CRM gravado e mantido por um fornecedor terceirizado sob o pedido.

Você precisa imaginar imediatamente o esquema de interação dos componentes do sistema futuro.

Como você pode ver, o IdM está no centro, e isso não é coincidência. Após a implementação, o IdM será o "alfa e ômega" que contém todas as informações relevantes sobre os funcionários da empresa, todas as suas contas em sistemas integrados ao IdM e quais funções, grupos e autoridades os funcionários devem ter nesses sistemas. É graças aos "tentáculos" do IdM que penetram em todos os sistemas conectados a ele que a transferência de Ivanov Sergey Petrovich do departamento de contabilidade para o departamento jurídico da empresa automaticamente registrado no sistema de informações pessoais mudará automaticamente os grupos e atributos de sua conta no AD e alterará suas funções e perfis em outros sistemas da empresa, com o lançamento automático de todos os processos necessários de aprovação e notificação. Mas tudo isso funcionará apenas quando todos os componentes do sistema estiverem bem e corretamente integrados entre si. E, para que isso aconteça, repito, é preciso pensar cuidadosamente e projetar tudo.

Com esta bagagem, saímos para uma compra.

Assim, a solução IdM é selecionada, o contratante de implementação é definido, as licenças são adquiridas, o trabalho é pago, é hora de implementá-lo. Falaremos mais sobre como garantir que todas as boas empresas não morram sem realmente nascer.

Criamos uma equipe de projeto e fazemos uma pesquisa pré-projeto

A primeira coisa a fazer imediatamente após a compra do IdM (sem contar o levantamento solene do copo para o acordo) é criar uma equipe de projeto. Sim, a equipe do projeto por parte do cliente deve ser. O sucesso de todo o evento depende de sua composição. Deve incluir representantes de todos os departamentos interessados ​​que possuam os poderes necessários e suficientes para resolver rapidamente vários problemas de natureza predominantemente técnica que surgem durante a implementação.

A seguir, chega o momento da pesquisa pré-design - a etapa mais importante, exigindo uma grande imersão nas atividades de design, principalmente do cliente.

Aqui, os poderes muito necessários e suficientes dos participantes da equipe de projeto do cliente serão solicitados a coletar e fornecer ao contratante todas as informações necessárias sobre a estrutura interna dos processos da empresa. É sobre a estrutura interna dos processos da empresa! Cada processo automatizado descrito nos Requisitos Funcionais precisa ser minuciosamente investigado do início ao fim. Quem realiza a coleta inicial de informações, sua composição e formato, em que sistema as informações são inseridas, em que são transmitidas, como, por quais protocolos, usando qual software? Quem precisa dessas informações para outras atividades, e de que forma elas precisam, onde deve haver vestígios das operações executadas ... Em uma palavra, tudo, tudo, tudo que diz respeito a cada processo investigado.

Nós escrevemos TK

Na saída da pesquisa pré-projeto, um documento mais importante do ponto de vista da implementação (ainda mais importante que os requisitos funcionais) deve ser obtido - os Termos de Referência (TOR). O que deveria estar nele? É importante não perder nada e pensar cuidadosamente em tudo. Porque a omissão de pequenas e aparentemente insignificantes nuances pode resultar em grandes problemas durante a implementação.

Nesse sentido, ao projetar uma solução de implementação no TK, a primeira coisa a fazer é elaborar minuciosamente os processos automatizados. Quase o mesmo que nos requisitos funcionais, mas com mais detalhes, com detalhes, cobrindo todo o ciclo de vida das informações que entram na entrada de cada processo até que sejam publicadas.

Por exemplo, o processo de pessoal.A admissão de um novo funcionário no ToR terá a seguinte aparência:

1. Um funcionário de RH insere informações sobre um novo funcionário no sistema de RH 1C: ZUP. Obrigatório preenche os seguintes campos: ... (é listado quais).
2. O IdM recebe dados sobre um novo funcionário do sistema de pessoal 1C: ZUP, determina a posição e a unidade do novo funcionário. Cria um novo perfil de funcionário no IdM. O login é formado de acordo com tais e tais regras, a senha de acordo com tais e tais. As informações de login da senha do novo funcionário são enviadas para lá e para cá através desses canais de comunicação (indicam de onde o IdM obtém o endereço).
3. O IdM cria automaticamente uma conta no AD com os atributos (lista) no diretório (OU - Unidade organizacional) correspondente à unidade do novo funcionário. O login é formado de acordo com tais e tais regras, a senha de acordo com tais e tais. Os dados sobre o login e a senha do novo funcionário são enviados para lá e para cá através desses canais de comunicação (indique de onde o IdM obtém o destinatário e os parâmetros do canal de comunicação).
4. A conta do AD criada é colocada em grupos (listamos ou indicamos "de acordo com o modelo"). O modelo também precisará ser pensado e descrito em um sumário em um capítulo separado. A nomeação de tais grupos é realizada de acordo com essas pessoas (listamos). O sistema gera notificações sobre a atribuição de autoridade a um novo funcionário (especifique o algoritmo de identificação do destinatário; descreva separadamente as rotas de aprovação), bem como lembretes ao coordenador sobre a necessidade de coordenar o aplicativo (especifique os algoritmos de identificação do destinatário, início, fim e frequência dos lembretes).
5. Depois de criar uma conta no AD, o IdM inicia a criação de uma caixa de correio do Exchange para o novo funcionário. As informações sobre a nova caixa de correio são armazenadas no IdM e exibidas no cartão do funcionário.

Aproximadamente na mesma linha, descrevemos a interação do sistema com o CRM ...

Assim, durante a consideração de processos automatizados dessa maneira, o modelo de objeto de cada sistema, a composição dos atributos de cada tipo de objeto fica clara, é formada uma imagem do movimento e transformação dos dados entre os atributos de vários objetos. Além disso, as conexões entre os objetos se tornam visíveis, processos adicionais são revelados, como a manutenção da consistência dos dados em todos os sistemas.

Um exemplo simples: ao alterar o nome do funcionário no sistema de pessoal, o nome dele deve ser alterado nos perfis de todos os outros sistemas conectados ao IdM. Mas isso pode não mudar, porque em alguns sistemas o nome simplesmente não é armazenado.

Um exemplo é mais complicado: o requisito é que a conta do AD de um novo funcionário seja criada na UO correspondente à sua unidade. Surge a questão: o que fazer se uma nova unidade for estabelecida no sistema de pessoal, mas ainda não foi criada no AD? Assim, é revelado um processo separado de reprodução da estrutura organizacional armazenada no sistema de pessoal no AD, que também vale a pena descrever no ToR.

Integra-se com sistemas

Como você pode ver, a formação de TK é um processo iterativo. Depois de identificar os objetos e ações que precisam ser executados com eles, fica claro o conjunto de funções que devem ser implementadas no conector do sistema integrado. E aqui abordamos sem problemas outro estágio importante da implementação do IdM - a integração real com os sistemas . Na verdade, esse estágio pode ser muito doloroso para o integrador do IdM e a empresa em cuja infraestrutura o IdM está sendo implementado.

Para que nada de ruim aconteça, você precisa entender alguns princípios gerais que se aplicam ao integrar vários produtos de software. Primeiro, você precisa entender a importância de ter uma API em um sistema integrado para integrar-se ao IdM. Conector e API são duas coisas diferentes. Se o integrador diz que possui conectores para vários sistemas ou está pronto para gravar um conector em qualquer sistema, isso não significa que o problema de integração esteja completamente resolvido e a empresa cliente não precisará fazer nada a respeito.

Vou explicar com um exemplo. Para conectar uma usina a ferro, a fim de aquecê-la, a fim de desempenhar suas funções conhecidas, é necessário que a central tenha uma tomada e o ferro, um plugue. Tomada e ficha. 2 coisas. Nem um. Usando uma tomada na lateral da estação de energia e um plugue na lateral do ferro, o ferro é integrado ao sistema de energia. No caso da integração do IdM com qualquer outro sistema, também são necessárias duas coisas: um conector no lado do IdM e uma API no lado do sistema. Isso é importante! Caso contrário, vários incidentes desagradáveis ​​podem ocorrer. O objetivo do conector é apenas receber os dados necessários do sistema no formato em que os envia e transferi-los para o IdM no formato em que o IdM pode recebê-los. O mesmo conector faz na direção oposta: recebe um comando e um conjunto de dados do IdM no formato em que o IdM os emite e transfere tudo isso para o sistema na forma em que o sistema entende o que precisa fazer. MAS! O sistema deve, em princípio, ser capaz de produzir os dados necessários para o IdM e executar os comandos necessários para trabalhar em conjunto com o IdM. Esse é o principal objetivo da API - fornecer uma interface na qual o IdM possa atuar com um conector para executar várias operações no sistema.

Normalmente, mesmo antes da venda do IdM, um integrador consciente concentra-se na necessidade de o cliente fornecer uma API para todos os sistemas conectados ao IdM e relata os requisitos para a implementação dessas APIs. Isso é essencialmente uma enumeração de funções com parâmetros de entrada e saída. Por exemplo:

• Pesquise todas as contas do sistema. Não há parâmetros de entrada. A saída é uma lista de todas as contas com todos os seus atributos.
• Pesquise uma conta por ID. O parâmetro de entrada é o identificador do ultrassom. Logout - uma conta que atenda aos critérios de pesquisa, com todos os atributos.
• Crie uma conta. Parâmetros de entrada - login, senha, nome completo ... Saída - identificador do novo ultrassom.
• Bloqueio de conta. Parâmetros de entrada - identificador do ultrassom. Não há parâmetros de saída.
• E assim por diante ...

Ou seja, uma API é um conjunto de funções necessárias para interagir com o IdM. O problema é que parte dessas funções no sistema pode não ser implementada da forma correta. Só porque isso ainda não era necessário. Parte pode ser implementada, mas como um processo complexo, multinível, passo a passo. Por exemplo, em um sistema automatizado bancário doméstico, a criação de uma conta de usuário é precedida pelo preenchimento de três diretórios diferentes com vários atributos e sinalizadores auxiliares. Ou, algumas funções podem ser implementadas de forma simples, mas não publicadas, ou seja, funções não podem ser usadas externamente. Portanto, a API foi projetada para resolver todos esses problemas. APIs são funções que executam as operações necessárias para a integração de um sistema integrado ao IdM, na forma correta e funcionando corretamente, publicada para sua chamada externa. Para que qualquer engenheiro de software que não conheça a cozinha interna do sistema possa usá-los e fazer o que for necessário com facilidade.

Então, como regra, surge a pergunta para os clientes, o que causa uma dor de dente incômoda para um engenheiro de implementação do IdM: por que um integrador de API não pode implementar um integrador de IdM em um sistema?

Imagine um sistema de gerenciamento corporativo complexo no qual o gerenciamento de direitos do usuário agora deve ser implementado usando o IdM. O fornecedor escreveu esse sistema desde os anos 90. Durante uma vida longa, sua arquitetura mudou quatro vezes. O subsistema de gerenciamento de direitos do usuário não conseguiu acompanhar o rápido desenvolvimento da funcionalidade do sistema em si e foi implementado por várias gerações de programadores de acordo com seu entendimento nem sempre lógico e razoável, de acordo com o princípio de "como eu mesmo descobri", ou seja, de uma maneira muleta. Não há necessidade de falar sobre a documentação de toda essa ação. No momento, tudo está de alguma forma funcionando. Os funcionários do fornecedor entram no código antigo de seu sistema com relutância e apreensão apenas em caso de necessidade urgente de corrigir algum bug terrível, batizando três vezes e borrifando o monitor com água benta, revestida com pandeiros, para que Deus não proíba quebrar nenhuma muleta, para que tudo não caia .



E agora, a empresa cliente que utiliza este produto mágico chegou na hora certa para implementar o IdM. Requisitos de API fornecidos, sem API. O cliente não se importa com quem gravará a API. Ele bateu o punho na mesa com as palavras "Estou chorando milhões, faça isso" e saiu da reunião, batendo a porta deliberadamente. O fornecedor de software mágico também não se importa. Ele não fará nada de graça, mas eles esqueceram de colocar dinheiro no orçamento para a implementação da API para sonhos vívidos do arco-íris sobre como tudo ficará bem após a introdução do IdM. Ao mesmo tempo, o contrato é assinado, "o dinheiro foi pago" e o salto selvagem começa.

O pobre programador Pasha, um funcionário do integrador da IdM, está tentando entender convulsivamente o que agachamentos devem ser feitos para obter reações normais do sistema. Ele estuda fontes públicas, documentação mesquinha e desatualizada, entende o código-fonte de um sistema desconhecido e interrompe os telefones do fornecedor. Depois de algumas semanas de provações, ele percebe que agachamentos não são suficientes, é necessário pular e até dar alguns pulos, e não o fato de que isso ajudará ... E depois de um mês, um conector aparece, algum tipo de um, mais ou menos funcionando. Ligeiras avarias, bem, como aconteceu. O pobre programador Pasha da equipe do integrador ficou cinza enquanto escrevia. O sistema mágico está integrado, mas o problema é que as contas não são criadas muito corretamente e o administrador do sistema deve "reverter" manualmente a conta para o estado de funcionamento. As senhas são alteradas a qualquer momento, e a “sortuda” Marina Ivanovna da contabilidade continua bloqueando sua conta. Os funcionários do "negócio" inundam o suporte técnico com reclamações cruéis: "Quanto tempo ???", "Impossível trabalhar!", "Faça como era ..." No início, o cliente exige que tudo seja corrigido e atinja a mesa com um chinelo, para que ele alcance o já careca programador de Pasha. Então, devido a falhas freqüentes e crescente descontentamento entre as unidades de negócios, a integração do IdM com o sistema mágico é interrompida.

E o que você vai fazer aqui? Quem é o culpado? Se não for um fornecedor de sistemas, quem deve resolver todo o caos que ele causou nos diretórios, funções, placas, gatilhos, bandeiras e muletas? Integrador IdM? Como ele sabe como implementar corretamente uma função em um sistema que um fornecedor não pode descobrir? E se puder, então por algum dinheiro considerável? Sim, agora estou muito mais espessa; há exceções quando o sistema não é muito complexo e você pode integrar-se a ele sem uma API especial. Mas seja razoável. Se o objetivo é evitar problemas desnecessários, ajudar os negócios a crescer e obter lucro (que, na minha opinião, é o principal objetivo do departamento de TI de qualquer empresa) e aproveitar o bom funcionamento de todos os sistemas, pense em maneiras de se integrar aos sistemas. Colocar no orçamento os custos necessários para o estudo das oportunidades de integração e a implementação competente dos componentes ausentes. Avarento paga duas vezes, ou até três vezes. Salve no final o programador Pasha: D. Ele é quase careca. E não se esqueça de corrigir os métodos de integração no TK!

Construímos um modelo da empresa

Eu também gostaria de chamar atenção especial para a formação do modelo da empresa . O fato é que cada sistema possui seu próprio conjunto exclusivo das chamadas entidades "autoritativas" - objetos que fornecem privilégios de usuário no sistema. Todos os tipos de grupos, funções, perfis, propósitos, diretórios, privilégios, tipos de operações etc. podem ser atribuídos a essa categoria de objetos ... A granulação de direitos pode ser muito profunda, como resultado, obtemos um número imensamente grande de objetos gerenciados. Por exemplo, alguns grupos de segurança no AD podem ter várias centenas ou até milhares. Em alguns sistemas de gerenciamento financeiro, cada usuário pode receber direitos exclusivos para cada conta dentre um milhão contido no plano de contas. E se nos integrarmos à SAP? O número de direitos atômicos pode ser medido em centenas de milhares e até milhões.

Além disso, o sistema pode suportar aninhamento hierárquico e relacionamentos complexos entre diferentes tipos de entidades autorizadas. Isso, por si só, baseia-se em um estudo separado das possibilidades de gerenciamento dos direitos do usuário no sistema. IdM, , , , IdM. . . , .

:

• IdM , . .
• . IdM , « ».
• . .

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

. .

, Solar inRights