Construção automática de CMDB

Universidade do Minho Escola de Engenharia Departamento de Inform´ atica Joana Catarina Maciel Pereira Construc¸ ˜ ao Autom´ atica de CMDB Maio 2021 Universidade do Minho Escola de Engenharia Departamento de Inform´ atica Joana Catarina Maciel Pereira Construc¸ ˜ ao Autom´ atica de CMDB Master dissertation Integrated Master’s in Informatics Engineering Dissertation supervised by Professor Ant´ onio Lu´ıs Pinto Ferreira de Sousa Maio 2021 DIREITOS DE AUTOR E CONDIC¸ ˜ OES DE UTILIZAC¸ ˜ A O D O TRABALHO POR TERCEIROS Este ´ e um trabalho acad ´ emico que pode ser utilizado por terceiros desde que respeitadas as regras e boas pr ´ aticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licen c¸ a abaixo indicada. Caso o utilizador necessite de permiss ˜ ao para poder fazer um uso do trabalho em condi c¸ ˜ oes n ˜ ao previstas no licenciamento indicado, dever ´ a contactar o autor, atrav ´ es do Reposit ´ oriUM da Universidade do Minho. licenc¸a concedida aos utilizadores deste trabalho: CC BY https://creativecommons.org/licenses/by/4.0/ i DECLARAC¸ ˜ AO DE INTEGRIDADE Declaro ter atuado com integridade na elabora c¸˜ ao do presente trabalho acad ´ emico e confirmo que n ˜ ao recorri ` a pr ´ atica de pl ´ agio nem a qualquer forma de utiliza c¸˜ ao indevida ou falsifica c¸˜ ao de informa c¸ ˜ oes ou resultados em nenhuma das etapas conducente ` a sua elaborac¸˜ ao. Mais declaro que conhe c¸ o e que respeitei o C ´ odigo de Conduta ´ Etica da Universidade do Minho. ii AGRADECIMENTOS Em primeiro lugar tenho de agradecer aos meus pais, que sempre acreditaram em mim e me deram a oportunidade de chegar at ´ e aqui. Que fizeram todos os sacrif ´ ıcios por mim para eu ter sempre o melhor. Que todos os dias s ˜ ao uma inspira c¸˜ ao e me incentivaram sempre a dar o meu melhor. Ao meu av ˆ o, a pessoa mais querida e a estrela mais bonita do c ´ eu. Que me faz querer ser uma pessoa melhor todos os dias. ` A minha sobrinha, que me ensinou a olhar para a vida de outra forma. Que com o seu sorriso contagiante se tornou a minha maior motivac¸˜ ao. Aos amigos que fiz ao longo destes anos. Quero agradecer por todas as experi ˆ encias que vivemos. Por me ensinarem tanto. Por estarem sempre l´ a. A toda a gente, que me ensinou e acreditou em mim. Finalmente, um obrigada ao Professor Ant ´ onio Lu ´ ıs Sousa, cuja orienta c¸˜ ao e disponibilidade tornaram este projeto poss´ ıvel. iii ABSTRACT Computing infrastructure management is increasingly demanding and has to comply with regulatory requirements. To comply with these requirements, the existence of a Configuration Management Database (CMDB) is fundamental. One of the challenges that any team has when starting IT Service Management (ITSM) is to create the organization’s CMDB. CMDB is a database that stores information about the components, usually called Configuration Items (CIs), of the infrastructure and the relationships between them. Thus, the CMDB creation implies discovering information about the infrastructure, saving it in the CMDB chosen by the organization. This dissertation presents a tool for the automatic creation of a CMDB that uses automatic discovery, mapping, and population mechanisms, to find information about the infrastructure components and store these results in the CMDB. It was also necessary to adapt the populate operation according to the database structure of the selected CMDB. This tool uses several discovery mechanisms to explore different types of Configuration Items (CIs), discovering information about them and their dependencies. It also uses an automatic mapping mechanism to adapt the types of discovered data with the CMDB structure where they will be stored. Finally, it populates the CMDB using its Application Programming Interface (API) to create the CIs and relationships. Keywords: CMDB,CI, automatic discovery, mapping, API. iv RESUMO A gest ˜ ao de infraestruturas computacionais ´ e cada vez mais exigente e tem de cumprir cada vez mais com requisitos normativos. Para estar de acordo com estes requisitos, a exist ˆ encia de uma CMDB ´ e fundamental. Um dos desafios que qualquer equipa tem ao iniciar a gest˜ ao de uma infraestrutura ´ e a criac¸˜ ao da sua CMDB. Uma CMDB ´ e uma base de dados que guarda informa c¸˜ ao acerca dos componentes, usualmente denominados de itens de configura c¸˜ ao (CIs), de uma infraestrutura computacional e dos relacionamentos entre si. Assim, a cria c¸˜ ao de uma CMDB implica descobrir informa c¸˜ ao acerca dos componentes que fazem parte da infraestrutura e armazenar esta na CMDB escolhida pela organizac¸˜ ao. Nesta disserta c¸˜ ao ´ e apresentada uma ferramenta de cria c¸˜ ao autom ´ atica de uma CMDB que recorre a mecanismos autom ´ aticos de descoberta, mapeamento e povoamento, de forma a encontrar informa c¸˜ ao acerca da infraestrutura, e armazenar estes resultados na CMDB. Tendo em conta que existem produtos de software distintos que implementam CMDBs, foi necess ´ ario adaptar o povoamento de acordo com a estrutura da base de dados selecionada. Esta ferramenta recorre a diversos mecanismos de descoberta de forma a explorar diferentes tipos de componentes, com a finalidade de descobrir informa c¸˜ ao acerca destes e das depend ˆ encias entre estes. Recorre tamb ´ em a um mecanismo de mapeamento autom ´ atico entre modelos de dados, de forma a adaptar os tipos de dados descobertos com a estrutura da CMDB onde estes v ˜ ao ser armazenados. Finalmente, utiliza um mecanismo para efetuar o povoamento da CMDB que utiliza a API desta para efetuar a cria c¸˜ ao dos componentes e dos relacionamentos. Palavras-chave: CMDB,CI, descoberta autom´ atica, mapeamento, API. v CONTE ´ UDO 1 introduc¸˜ ao 1 1.1Contextualizac¸˜ ao 1 1.2Motivac¸˜ ao 2 1.3Objetivos 3 1.4Organizac¸˜ ao do documento 4 2 estado da arte 5 2.1ITIL 5 2.2ISO/IEC 20000 6 2.3Infraestrutura de TI 7 2.4Configuration Management Database 9 2.4.1Conceitos 9 2.4.2Vantagens 11 2.4.3Dificuldades 11 2.4.4O que guardar na CMDB 12 2.4.5Ferramentas 13 2.5Descoberta Autom´ atica 19 2.5.1Processo 19 2.5.2Protocolos 20 2.5.3Arquiteturas 22 2.5.4Ferramentas 22 2.5.5Processamento dos Dados Recolhidos 25 2.6Modelos de Dados 26 2.6.1Noc¸ ˜ oes e conceitos 26 2.6.2Mapeamento dos modelos de dados 26 2.7Trabalho Relacionado 28 2.7.1Ferramentas 28 2.7.2Sum´ ario 32 3 problema e desafios 34 3.1Problema 34 3.2Abordagem Proposta 34 3.3Arquitetura do sistema 35 3.3.1Fase de Descoberta 35 3.3.2Fase de Mapeamento 38 vi conte´ udo vii 3.3.3Fase de Povoamento 40 3.4Desafios 40 4 desenvolvimento 42 4.1Decis˜ oes 42 4.2Implementac¸˜ ao 43 4.2.1Esquema da base de dados 43 4.2.2Gest˜ ao de palavras-passe 48 4.2.3Normalizac¸˜ ao 49 4.2.4Reconciliac¸˜ ao 51 4.2.5Descoberta 52 4.2.6Povoamento da base de dados 58 4.2.7Processamento do modelo de dados da base de dados 60 4.2.8Processamento do modelo de dados da CMDB 61 4.2.9C´ alculo de similaridade 65 4.2.10 Mapeamento 67 4.2.11 Povoamento da CMDB 69 4.3Sum´ ario 73 5 avaliac¸˜ ao 76 5.1Caso de Teste 176 5.1.1Descoberta 77 5.1.2Mapeamento 78 5.1.3Povoamento 79 5.2Caso de Teste 283 5.2.1Descoberta 84 5.2.2Mapeamento 85 5.2.3Povoamento 85 5.3Caso de Teste 386 5.3.1Descoberta 87 5.3.2Mapeamento 89 5.3.3Povoamento 91 5.4Caso de Teste 496 5.5Sum´ ario 98 6 conclus ˜ oes e trabalho futuro 100 6.1Conclus˜ ao 100 6.2Trabalho Futuro 102 a resultados do processamento de modelos de dados 111 b execuc¸˜ ao da ferramenta 121 SIGLAS ACI Application Centric Infrastructure. AP Access Point. API Application Programming Interface. ARP Address Resolution Protocol. BD Bases de Dados. BGP Border Gateway Protocol. BIOS Basic Input/Output System. CDM Common Data Model. CDP Cisco Discovery Protocol. CI Configuration Item. CIDR Classless Inter-Domain Routing. CIM Common Information Model. CLI Command Line Interface. CMDB Configuration Management Database. CMS Configuration Management System. CPU Central Processing Unit. CSV Comma-separated values. DAS Direct Attached Storage. DMTF Distributed Management Task Force. DNS Domain Name System. FDB Forwarding Database. FDP Foundry Discovery Protocol. FTP File Transfer Protocol. GB Gigabyte. GHz Gigahertz. GPU Graphics Processing Unit. HDD Hard Disk Drive. HTTP HyperText Transfer Protocol. HTTPS HyperText Transfer Protocol Secure. xiv Siglas xv ICMP Internet Control Message Protocol. IEC International Electrotechnical Commission. IP Internet Protocol. IPMI Intelligent Platform Management Interface. ISO International Organization for Standardization. ITIL Information Technology Infrastructure Library. ITSM IT Service Management. JSON JavaScript Object Notation. LAN Local Area Network. LLDP Link Layer Discovery Protocol. MAC Media Access Control. MIB Management Information Base. MID Management, Instrumentation, and Discovery. MIEI Mestrado Integrado em Engenharia Inform´ atica. NAS Network Attached Storage. NDP Neighbor Discovery Protocol. OSI Open System Interconnection. OSPF Open Shortest Path First. PHP Hypertext Preprocessor. RAM Random-access memory. RDF Resource Description Framework. REST Representational State Transfer. RPC Remote Procedure Call. SAN Storage Area Network. SCCM System Center Configuration Manager. SGBD Sistemas de Gest˜ ao de Base de Dados. SNMP Simple Network Management Protocol. SPARQL SPARQL Protocol and RDF Query Language. SQL Structured Query Language. SSD Solid-State Drive. SSH Secure Shell. STP Spanning Tree Protocol. SVS Service Value System. TCP Transmission Control Protocol. Siglas xvi TI Tecnologias da Informac¸˜ ao. TTL Time to Live. UCS Unified Computing System. UDP User Datagram Protocol. UM Universidade do Minho. UML Unified Modeling Language. UPS Uninterruptible Power Source. URL Uniform Resource Locator. UUID Universally Unique Identifier. VLAN Virtual Local Area Network. VPN Virtual Private Network. WAN Wide Area Netwok. WinRM Windows Remote Management. WMI Windows Management Instrumentation. XML eXtensible Markup Language. 1 INTRODUC¸ ˜ A O Este documento descreve o projeto de disserta c¸˜ ao desenvolvido no contexto do Mestrado Integrado em Engenharia Inform ´ atica (MIEI) da Universidade do Minho (UM), baseando-se na criac¸˜ ao, de forma autom´ atica, de uma Configuration Management Database (CMDB). Neste cap ´ ıtulo v ˜ ao ser apresentados o contexto, motiva c¸˜ ao e principais objetivos do problema enunciado, assim como a organizac¸˜ ao do restante documento. 1.1 contextualizac¸˜ ao Os departamentos de Tecnologias da Informa c¸˜ ao (TI) das organiza c¸ ˜ oes enfrentam v ´ arios desafios na entrega de servi c¸ os confi ´ aveis que suportam os objetivos de neg ´ ocio das organiza c¸ ˜ oes. Os desafios de gest ˜ ao dos servi c¸ os de TI podem envolver, por exemplo, o desempenho da rede e dos sistemas, a gest ˜ ao do ciclo de vida das aplica c¸ ˜ oes, a gest ˜ ao de ativos e mudan c¸ as, a otimizac¸˜ ao financeira e a seguranc¸a dos sistemas [66]. O processo de gest ˜ ao de configura c¸ ˜ oes procura, de uma forma compreensiva e sistem ´ atica, especificar, controlar e fazer o rastreio dos componentes da infraestrutura computacional e todas as altera c¸ ˜ oes feitas a estes. De acordo com a Information Technology Infrastructure Library (ITIL) [ 83 ], a gest ˜ ao de configura c¸ ˜ oes cria um modelo da infraestrutura e dos servi c¸ os dispon ´ ıveis, identificando, controlando, guardando e verificando toda a informa c¸˜ ao relativa aos componentes existentes nessa infraestrutura [92]. AITIL ´ e uma framework que descreve um conjunto de pr ´ aticas, instru c¸ ˜ oes e recomenda c¸ ˜ oes que explica processos, procedimentos e tarefas para gerir os servi c¸ os de uma organiza c¸˜ ao [ 56 ]. Estes elementos n ˜ ao s ˜ ao espec ´ ıficos de nenhuma organiza c¸˜ ao e podem ser aplicados por qualquer uma. A ITIL n ˜ ao ´ e um standard, ou seja, n ˜ ao prescreve as pr ´ aticas que descreve. As organiza c¸ ˜ oes n ˜ ao precisam de implementar cada processo ou seguir a framework de forma rigorosa. Cada empresa pode escolher as ´ areas do seu neg ´ ocio mais apropriadas para implementar os processos. O foco da ITIL ´ e garantir que os servi c¸ os consigam acompanhar as necessidades do neg ´ ocio, oferecendo ` as organiza c¸ ˜ oes uma oportunidade de aumentar a eficiˆ encia, melhorar a produtividade e aumentar o valor comercial. 1 1.2. Motivac¸˜ ao 2 Enquanto que as pr ´ aticas ITIL representam apenas recomenda c¸ ˜ oes, existe, desde 2005, o standard ISO 20000 [ 15 ], definido pela International Organization for Standardization (ISO), que especifica os requisitos necess ´ arios para a gest ˜ ao de servi c¸ os de uma organiza c¸˜ ao. O ISO 20000 ´ e uma evoluc¸˜ ao das pr´ aticas ITIL e tem a intenc¸˜ ao de ser compat´ ıvel com estas [92]. Entre outras coisas, este standard implica a utiliza c¸˜ ao de uma CMDB que guarde todos os itens de configurac¸˜ ao, assim como o seu hist´ orico de alterac¸ ˜ oes e problemas. CMDB ´ e, ent ˜ ao, uma base de dados, que segue as normas definidas pela ITIL, usada por uma organizac¸˜ ao para guardar informac¸˜ ao sobre a sua infraestrutura computacional. Uma das maiores tarefas da gest ˜ ao de configura c¸ ˜ oes passa pela identifica c¸˜ ao dos itens de configura c¸˜ ao a guardar na CMDB. Um dos seus principais objetivos passa por fornecer informa c¸˜ ao sobre os itens e configura c¸ ˜ oes na infraestrutura da empresa e os seus servi c¸ os. 1.2 motivac¸˜ ao Os ambientes empresariais possuem infraestruturas computacionais complexas que s ˜ ao compostas por diversos componentes, que podem incluir elementos de hardware, software, documenta c¸˜ ao ou pessoal, e que dependem entre si de v ´ arias formas. Tendo em conta a grande complexidade da infraestrutura de uma empresa, esta necessita de ferramentas de gest ˜ ao mais sofisticadas, tal como uma CMDB [ 78 ]. Sendo uma ferramenta que permite a uma organiza c¸˜ ao ter conhecimento de todos os seus ativos e dos relacionamentos entre estes, ´ e descrita em [ 54 ] como ”um dos recursos mais valiosos que uma organiza c¸˜ ao tem ` a sua disposic¸˜ ao, se for executada corretamente”. ACMDB torna-se uma ferramenta mais relevante ` a medida que s ˜ ao adicionados mais itens de configura c¸˜ ao ao sistema, porque permite manter informa c¸˜ ao sobre estes e perceber como altera c¸ ˜ oes aos mesmos podem afetar os restantes componentes da infraestrutura. Para al ´ em disto, ` a medida que a infraestrutura se torna mais complexa, aumenta, tamb ´ em, a import ˆ ancia de manter informa c¸˜ ao sobre os seus componentes, de forma a facilitar a sua gest˜ ao. Existem diversas raz ˜ oes pelas quais ´ e relevante ter informa c¸˜ ao sobre a infraestrutura da organiza c¸˜ ao. Por exemplo, conhecer todos as m ´ aquinas existentes facilita a preven c¸˜ ao da entrada de intrusos na rede da empresa; conhecer as depend ˆ encias entre os v ´ arios componentes permite saber quais destes possuem acesso a informa c¸˜ ao sens ´ ıvel; saber de todas as inst ˆ ancias instaladas de um software permite fazer uma melhor gest ˜ ao do licenciamento do mesmo; conhecer todos os ativos envolvidos numa tarefa e todos os seus relacionamentos, fornece um melhor planeamento de a c¸ ˜ oes de recupera c¸˜ ao e de an ´ alise relacionadas com a disponibilidade de servi c¸ os; o conhecimento detalhado dos componentes de software e de hardware, assim como as depend ˆ encias entre si, permitem a virtualiza c¸˜ ao e migrac¸˜ ao de servic¸os e m´ aquinas; entre outros [78]. 1.3. Objetivos 3 No entanto, obter toda esta informa c¸˜ ao sobre os componentes da infraestrutura implica custos, principalmente se tiver de ser efetuada manualmente. Considerando as empresas j ´ a existentes, que j ´ a possuem uma estrutura mais complexa e desenvolvida, este processo torna-se ainda mais dif´ ıcil. Desta forma foi observado em [73] que das v´ arias organizac¸ ˜ oes que a cada ano tentam construir a sua CMDB, cerca de 85% falham nesta tarefa. Para al ´ em disto, ´ e tamb ´ em constatado em [ 66 ] que mais de 75% de todas as iniciativas estrat ´ egicas, sendo estas a implementa c¸˜ ao de uma CMDB ou outras, falham, pelo menos, na resposta ` as expetativas iniciais das organiza c¸ ˜ oes. Uma das maiores raz ˜ oes pela qual isto acontece recai no facto de ser uma abordagem excessivamente manual e, sem as ferramentas apropriadas, as organiza c¸ ˜ oes consideram que este trabalho ´ e demasiado minucioso e demorado [ 73 ]. Adicionalmente, a tentativa de modelar manualmente os diferentes relacionamentos entre os CIs, ´ e uma atividade propensa a erros. Uma boa abordagem para resolver este problema passa por obter um m´ etodo que recolha informac¸˜ ao sobre os componentes. As ferramentas de descoberta autom ´ atica s ˜ ao essenciais para a automatiza c¸˜ ao do processo de recolha de informa c¸˜ ao para uma CMDB. Por ´ em, usualmente, estas ferramentas s ˜ ao dif ´ ıceis de implementar e executar e n ˜ ao recolhem a quantidade e tipo de dados pretendidos [ 78 ]. Assim, quem precisa destas informa c¸ ˜ oes acaba por implementar as suas pr ´ oprias ferramentas ou realizar a descoberta manualmente. Al ´ em disto, a descoberta das depend ˆ encias relacionadas com pessoas e de informa c¸˜ ao relacionada com software ` a medida torna-se uma etapa cr ´ ıtica, devido ` a especificidade deste tipo de dados. A precis ˜ ao da informa c¸˜ ao obtida ´ e tamb ´ em um fator essencial, pois n ˜ ao devem existir ativos ou depend ˆ encias n ˜ ao descobertas. A falta de informa c¸˜ ao pode levar a que, por exemplo, processos de recupera c¸˜ ao ou de migrac¸˜ ao acabem por falhar [78]. Assim, o processo de descoberta deve ser o mais simples, abrangente e preciso poss ´ ıvel, de forma a que a informa c¸˜ ao obtida seja o mais ´ util poss ´ ıvel na tomada de decis ˜ oes acerca da infraestrutura, uma vez que estas influenciam os resultados da organizac¸˜ ao. 1.3 objetivos Com este projeto, ´ e esperado que seja poss ´ ıvel fazer a cria c¸˜ ao de uma CMDB automaticamente, ou seja, com o m´ ınimo de trabalho desempenhado por parte do utilizador. Desta forma, e de um modo geral, os principais objetivos deste projeto passam ent ˜ ao por: • Perceber como funcionam as tecnologias que implementam CMDBs e como ´ e que os dados recolhidos podem ser armazenados; • Desenvolver uma arquitetura para a automatiza c¸˜ ao do processo de cria c¸˜ ao de uma CMDB; 1.4. Organizac¸˜ ao do documento 4 • Implementar um processo de descoberta autom ´ atica dos componentes computacionais de uma organiza c¸˜ ao recorrendo a ferramentas de an ´ alise de redes e invent ´ ario de sistemas; • Fazer o povoamento da CMDB, adaptando-o ` a ferramenta escolhida pelo utilizador; • Minimizar o esforc¸o do utilizador na tarefa de criac¸˜ ao da CMDB. 1.4 organizac¸˜ ao do documento Al ´ em deste cap ´ ıtulo de introdu c¸˜ ao, este documento encontra-se estruturado em mais 5 cap´ ıtulos: •Cap´ ıtulo 2Estado da Arte: s ˜ ao expostos os conceitos e implementa c¸ ˜ oes mais relevantes acerca do tema. •Cap´ ıtulo 3Problema e Desafios: ´ e apresentada a solu c¸˜ ao proposta para o problema identificado, assim como os desafios que possam surgir. •Cap´ ıtulo 4Desenvolvimento: aborda o desenvolvimento e implementa c¸˜ ao da soluc¸˜ ao, expondo as decis˜ oes tomadas. •Cap´ ıtulo 5Testes: apresenta os testes efetuados ` a ferramenta desenvolvida, assim como os resultados obtidos nestes. •Cap´ ıtulo 6Conclus˜ oes e Trabalho Futuro: conclui a disserta c¸˜ ao, apresentando um resumo dos resultados obtidos, assim como uma perspetiva de melhoramento do projeto a abordar num poss´ ıvel trabalho futuro. 2 ESTADO DA ARTE Neste cap ´ ıtulo v ˜ ao ser apresentados os conceitos e implementa c¸ ˜ oes existentes relevantes para a documenta c¸˜ ao e gest ˜ ao de infraestruturas computacionais. Isto inclui a apresenta c¸˜ ao de conceitos, tais como ITIL,ISO 20000, infraestrutura computacional, CMDB, descoberta autom ´ atica e mapeamento entre modelos de dados, assim como experi ˆ encias e conhecimentos j ´ a fundamentados acerca destes. Finalmente, ser ´ a apresentado algum do trabalho relacionado analisado. 2.1 itil ` A medida que as infraestruturas se foram tornando mais complexas, durante os anos 80, o governo brit ˆ anico examinou a sua infraestrutura de TI com o objetivo de encontrar melhores formas de usar os seus servi c¸ os e recursos. Surgiu ent ˜ ao um conjunto de padr ˜ oes e melhores pr ´ aticas para melhorar o desempenho das TI que evoluiu para uma framework composta por um conjunto de livros [66]-aITIL [83] - que se encontra, actualmente, na vers˜ ao 4. Um dos componentes chave da ITIL 4 ´ e o Service Value System (SVS). Neste, ´ e representada a forma como componentes e atividades diferentes podem trabalhar em conjunto, em qualquer tipo de organiza c¸˜ ao, com o objetivo de facilitar a cria c¸˜ ao de valor atrav ´ es de servic¸os de TI. Os componentes do SVS s˜ ao: •Cadeia de valor de servic¸o: Conjunto de atividades realizadas por uma organiza c¸˜ ao para entregar produtos ou servic¸os com valor aos seus clientes; •Pr´ aticas: Conjunto de recursos organizacionais desenhados para executar um trabalho ou atingir um objetivo; •Princ´ ıpios orientadores: Recomenda c¸ ˜ oes capazes de orientar uma organiza c¸˜ ao em todas as circunst ˆ ancias, independentemente dos seus objetivos, estrat ´ egias, tipo de trabalho ou estrutura de gest˜ ao; •Governac¸ ˜ ao: Sistema que que orienta e controla a organizac¸˜ ao; 5 2.2. ISO/IEC 20000 6 •Melhoria cont´ ınua: Atividade organizacional recorrente que garante que o desempenho da organizac¸˜ ao continua a responder ` as expectativas das partes interessadas. As pr ´ aticas de gest ˜ ao definidas no SVS incluem pr ´ aticas gerais de gest ˜ ao, pr ´ aticas de gest ˜ ao de servi c¸ os e pr ´ aticas de gest ˜ ao t ´ ecnica. De todas as pr ´ aticas definidas, a relevante para este projeto ´ e a pr ´ atica de gest ˜ ao de configura c¸ ˜ oes de servi c¸ os, inserida nas pr ´ aticas de gest ˜ ao de servi c¸ os. A pr ´ atica de gest ˜ ao configura c¸ ˜ oes de servi c¸ os garante que a informa c¸˜ ao sobre os servi c¸ oseosCIs que os suportam ´ e exata, confi ´ avel e est ´ a dispon ´ ıvel quando e onde for precisa. Isto inclui informac¸ ˜ ao sobre como os CIs est˜ ao configurados e como se relacionam entre si. Recolhe e gere informa c¸˜ ao sobre uma grande variedade de CIs, que usualmente incluem hardware, software, redes, edif ´ ıcios, pessoas, fornecedores, documenta c¸˜ ao e servi c¸ os. Esta informa c¸˜ ao pode ser guardada numa ´ unica fonte de dados, ou pode ser distribu ´ ıda entre v ´ arias fontes. Inicialmente, a ITIL come c¸ ou por descrever uma CMDB como uma base de dados ´ unica, mas a partir da ´ ultima vers ˜ ao, come c¸ ou a utilizar o conceito de Configuration Management System (CMS) para descrever uma ferramenta que recolhe, armazena, gere, atualiza, analisa e apresenta toda a informac¸˜ ao sobre os CIs e os seus relacionamentos. Ainda assim, ITIL define uma CMDB como “uma base de dados utilizada para guardar os detalhes dos CIs durante o seu ciclo de vida e os relacionamentos entre estes.” Outros conceitos relevantes no contexto de uma CMDB s ˜ ao infraestrutura de TI, gest ˜ ao de configura c¸ ˜ oes, item de configura c¸˜ ao (CI), atributo e tipo de CI. A infraestrutura de TI ´ e descrita pela ITIL como “todo o hardware, software, redes e instala c¸ ˜ oes necess ´ arias para desenvolver, testar, entregar, monitorizar, gerir e suportar servi c¸ os”. A gest ˜ ao de configura c¸ ˜ oes “fornece informa c¸˜ ao sobre os CIs (...) e os seus relacionamentos: como interagem, se relacionam, e dependem uns dos outros (...). Isto inclui informa c¸˜ ao sobre as depend ˆ encias entre servi c¸ os”. Um CI ´ e “qualquer componente que necessita de ser gerido para fornecer servi c¸ os aos clientes” e pode abranger elementos de software, hardware, servi c¸ os, processos ou pessoas [ 83 ]. O atributo de um CI ´ e essencialmente informa c¸˜ ao sobre este, tal como, pre c¸ o, vers ˜ ao, nome ou n ´ umero de s ´ erie [ 66 ]. J ´ a o tipo de um CI corresponde a “uma categoria usada para classificar CIs. Os tipos de CIs identificam os atributos e relacionamentos desse registo”. Definir, gerir e otimizar os CIs e as suas dependˆ encias ´ e o foco da CMDB. 2.2 iso/iec 20000 AInternational Organization for Standardization (ISO)[ 3 ] ´ e uma organiza c¸˜ ao internacional de defini c¸˜ ao de standards fundada em 1947 que j ´ a desenvolveu mais de 20000 standards internacionais. OISO/IEC 20000 [ 15 ] ´ e um standard cujos processos est ˜ ao alinhados com as pr ´ aticas descritas na ITIL [ 83 ]. Define os requisitos de gest ˜ ao dos servi c¸ os de TI necess ´ arios para que as organizac¸ ˜ oes prestem servic¸os de qualidade aos seus clientes. 2.3. Infraestrutura de TI 7 OISO/IEC 20000 possui 5grupos de processos que garantem a qualidade da presta c¸˜ ao dos servic¸os por parte das organizac¸ ˜ oes [88]: • Concec¸˜ ao e transic¸˜ ao de servic¸os novos ou alterados; • Processos de entrega de servic¸os; • Processos de relacionamento; • Processos de resoluc¸˜ ao; • Processos de controlo. Inclu ´ ıdo no grupo de processos de controlo, a gest ˜ ao de configura c¸ ˜ oes relata que, para cada servi c¸ o, devem ser identificados os CIs relevantes, os seus atributos e os seus relacionamentos e depend ˆ encias [ 88 ]. Neste contexto, s ˜ ao relevantes os conceitos item de configura c¸˜ ao e CMDB.CI ´ e descrito pelo ISO/IEC 20000 como um “elemento que necessita de ser controlado para entregar servi c¸ os” e CMDB ´ e especificada como uma base de dados que “guarda informa c¸˜ ao sobre os atributos dos itens de configura c¸˜ ao e dos relacionamentos entre estes, controlando os componentes durante o seu ciclo de vida” [15]. Devido ao foco na qualidade e efici ˆ encia dos servi c¸ os prestados, as organiza c¸ ˜ oes que seguem os princ ´ ıpios e pr ´ aticas de gest ˜ ao de servi c¸ os do ISO/IEC 20000 tiram partido de benef ´ ıcios tanto a n ´ ıvel interno como a n ´ ıvel competitivo, visto que uma certifica c¸˜ ao deste tipo n˜ ao ´ e algo simples e comum. 2.3 infraestrutura de ti O modelo de uma infraestrutura pode englobar v ´ arios conceitos dependendo do contexto da situa c¸˜ ao. No entanto, de uma forma generalizada, o modelo descrito em [ 82 ] parece adequado neste contexto em espec ´ ıfico. Segundo este, a infraestrutura computacional de uma organizac¸˜ ao pode ser agrupada nas seguintes categorias: • dispositivos dos utilizadores finais; • sistemas operativos; • armazenamento; • computacional; • rede; • centros de dados. 2.4. Configuration Management Database 14 Relativamente ao modelo de dados do sistema, existe uma hierarquia definida entre diversos tipos de dados, que ´ e poss ´ ıvel observar na Figura 2.2. Tipos de grupos de objetos compreendem tipos de objetos; tipos de objetos herdam categorias; tipos de objetos instanciam objetos, que herdam as categorias do seu tipo de objeto; e categorias incluem atributos e podem ser caracterizadas como globais, espec´ ıficas ou personalizadas [12]. Figura 2.2: Hierarquia do modelo de dados do sistema do i-doit (inspirado no esquema presente em https://kb.i-doit.com/display/en/Structure+of+the+IT+Documentation). Aqui, o termo objeto refere-se ao termo CI da ITIL, e o termo tipo de objeto refere-se a tipo de CI. Al ´ em disto, o i-doit possui tamb ´ em v ´ arios relacionamentos definidos, que podem ser ajustados e modificados. Um relacionamento estabelece um dos objetos como master e outro como slave sendo que o segundo est´ a dependente do primeiro. Em termos de base de dados relacional, estes tipos, categorias e relacionamentos representam tabelas. Os v ´ arios tipos de grupos de objetos encontram-se definidos na tabela “isys obj type group”, os tipos de objetos est ˜ ao definidos na tabela “isys obj type”, e cada objeto da CMDB ´ e um registo na tabela “isys obj”. Um relacionamento ´ e representado por um objeto do tipo “relation”. Para al ´ em disto, cada categoria est ´ a refletida na base de dados como uma tabela. Em termos de nomenclatura, existem prefixos e sufixos que identificam categorias e atributos. Por exemplo, todas as tabelas possuem o prefixo “isys ”. O estado de vida de um componente ´ e documentado na CMDB e ´ e guardado como um atributo de um objeto. Existem estados j´ a definidos, mas ´ e tamb´ em poss´ ıvel definir outros estados [12]. O i-doit tamb ´ em permite acesso externo atrav ´ es de uma API, que oferece funcionalidades semelhantes ` as oferecidas pela interface gr ´ afica, com a vantagem de poderem ser automatizadas. Atrav ´ es desta ´ e poss ´ ıvel fazer pedidos ao servidor de forma a executar determinados m ´ etodos seguindo uma abordagem Remote Procedure Call (RPC) [ 110 ], sendo utilizados pedidos HyperText Transfer Protocol (HTTP) [ 68 ] POST e JSON [ 5 ] como formato de troca de informac¸˜ ao [12]. 2.4. Configuration Management Database 15 Dos v ´ arios m ´ etodos que podem ser utilizados atrav ´ es da API, os mais relevantes neste contexto s˜ ao: •cmdb.object.create: permite a criac¸˜ ao de objetos; •cmdb.object types.read: interroga os tipos de objetos; •idoit.constants : devolve os tipos de objetos e categorias, globais e espec ´ ıficas, existentes na base de dados; •cmdb.category info: devolve os atributos de uma categoria; •cmdb.object type groups.read : devolve os tipos de objetos que est ˜ ao associados aos tipos de grupos de objetos; •cmdb.object type categories.read : devolve as categorias associadas aos tipos de objetos. iTop O iTop [ 4 ] ´ e uma solu c¸˜ ao open source que permite que os CIs e os seus relacionamentos sejam geridos numa CMDB sendo a informa c¸˜ ao acerca destes armazenada numa base de dados MySQL ou MariaDB. Existem v ´ arias classes definidas para os CIs da CMDB que est ˜ ao agrupadas por m ´ odulos, sendo que a utiliza c¸˜ ao de mais m ´ odulos significa a exist ˆ encia de mais tipos de CIs na CMDB. Ao n ´ ıvel do modelo de dados, estas classes s ˜ ao representadas por tabelas e os atributos de cada CI s ˜ ao atribu ´ ıdos dependendo da sua classe, ou seja, s ˜ ao representados pelas colunas da tabela. Os relacionamentos entre os CIs s ˜ ao tamb ´ em representados por tabelas que s ˜ ao identificadas pelo prefixo “lnk”. Possui uma interface Representational State Transfer (REST) [ 69 , Cap ´ ıtulo 5] que permite uma intera c¸˜ ao remota com a CMDB. Esta interface utiliza o protocolo HTTP e o formato JSON para a troca de informa c¸˜ ao. Dos m ´ etodos existentes o mais relevante neste contexto ´ e o m´ etodo core/create que permite a criac¸˜ ao de novos objetos na CMDB [27]. Device42 O Device42 [ 24 ] ´ e uma solu c¸˜ ao de software para gest ˜ ao de infraestruturas de TI. De entre os v ´ arios mecanismos que disponibiliza, o mais pertinente neste contexto ´ easuaCMDB. Esta fornece uma vista centralizada do ambiente computacional, mantendo informa c¸˜ ao acerca de todos os CIs. Possui um esquema dos CIs e relacionamentos j ´ a definido que pode ser extendido pelo utilizador. No topo da hierarquia encontram-se os edif ´ ıcios, que alojam uma ou mais salas de computadores. Cada sala pode conter um ou mais racks ou outros objetos, que s ˜ ao ativos ou dispositivos. Estes dispositivos incluem dispositivos f ´ ısicos, como servidores ou switches, m ´ aquinas virtuais, clusters, entre outros. Os ativos podem 2.4. Configuration Management Database 16 incluir cabos, faxes, monitores, scanners, produtos de software, entre outros. Est ˜ ao tamb ´ em definidos como tipos de CIs permiss ˜ oes, clientes, vendedores, palavras-passe, modelos de hardware, sistemas operativos, contratos e aplicac¸ ˜ oes. Possui uma API REST que permite a manipula c¸˜ ao dos CIs na CMDB. No entanto, o Uniform Resource Locator (URL) [ 59 ] de cada pedido varia dependendo do tipo de CI envolvido [ 19 ]. BMC CMDB A BMC CMDB [ 21 ] ´ e um dos componentes do BMC Atrium Core e permite a gest ˜ ao, armazenamento e monitoriza c¸˜ ao da informa c¸˜ ao relacionada com os componentes da infraestrutura computacional. A informa c¸˜ ao acerca dos CIs e dos seus relacionamentos est ´ a organizada em datasets, que passam por um processo de reconcilia c¸˜ ao. Quando os CIs e os seus relacionamentos s ˜ ao adicionados ` aCMDB, cada entrada ´ e atribu ´ ıda a um dataset, que identifica a origem da informa c¸˜ ao. O cat ´ alogo de produtos inclui os nomes e defini c¸ ˜ oes normalizados dos produtos de software, hardware e servi c¸ os dispon ´ ıveis na organiza c¸˜ ao. O motor de normaliza c¸˜ ao garante a coer ˆ encia da informa c¸˜ ao proveniente de diversas fontes, aplicando a nomenclatura especificada e eliminando CIs duplicados. O motor de reconcilia c¸˜ ao combina a informa c¸˜ ao dos v´ arios datasets num ´ unico, que ´ e depois utilizado pelos consumidores. A informa c¸˜ ao est ´ a organizada de acordo com o Common Data Model (CDM), que consiste no conjunto de classes de CIs e relacionamentos presentes na CMDB. Cada classe representa uma tabela na base de dados. Este modelo j ´ a est ´ a pr ´ e-definido na CMDB mas pode ser estendido, permitindo a cria c¸˜ ao de novas classes e atributos destas. Estas classes representam os diferentes tipos de CIs e relacionamentos. Uma inst ˆ ancia de um relacionamento relaciona duas inst ˆ ancias de CIs, podendo tamb ´ em ter atributos associados. Para al ´ em disto, um dos CIs ´ e considerado a origem do relacionamento e o outro o destino. Existem diferentes tipos de classes no CDM: •Regulares: t ˆ em a sua pr ´ opria tabela definida com os seus atributos espec ´ ıficos, podendo ser superclasses ou subclasses, sendo que estas ´ ultimas combinam os seus atributos espec´ ıficos aos da sua superclasse; •Categorizac¸˜ ao: n ˜ ao t ˆ em a sua pr ´ opria tabela definida, sendo que os atributos espec ´ ıficos de uma classe de categoriza c¸˜ ao s ˜ ao adicionados ` a estrutura da sua superclasse, sendo estes apenas preenchidos pelas inst ˆ ancias da classe de categoriza c¸˜ ao, tornando-se opcionais; •Abstratas: n ˜ ao t ˆ em a sua pr ´ opria tabela definida nem atributos, funcionando apenas para organizar subclasses; •Abstratas com replicac¸˜ ao de dados: novas tabelas que agregam toda a informa c¸˜ ao acerca das subclasses de uma classe abstrata. 2.4. Configuration Management Database 17 De forma a manter a consist ˆ encia com os standards definidos neste contexto, o CDM foi baseado no CIM [ 23 ] e no Windows Management Instrumentation (WMI) [ 18 ], tendo sido adotados os componentes b ´ asicos destes. O CIM ´ e um modelo de dados orientado a objetos que cont ´ em informa c¸˜ ao sobre diferentes partes de uma empresa e foi definido pela Distributed Management Task Force (DMTF) [ 25 ]. O WMI [ 18 ] ´ e a infraestrutura para a gest ˜ ao de dados e opera c¸ ˜ oes em sistemas operativos baseados em Windows [ 53 ], que utiliza tamb ´ emoCIM para representar sistemas, aplicac¸ ˜ oes, redes, dispositivos e outros componentes. A BMC CMDB [ 21 ] possui uma API REST que utiliza o protocolo HTTP e o formato JSON para a troca informa c¸˜ ao. Dos v ´ arios pedidos que podem ser feitos atrav ´ es da API, os mais relevantes neste contexto s˜ ao: • GET /cmdb/v1.0/classes: retorna a lista das classes do CDM; • GET /cmdb/v1.0/attributes/namespace/className : retorna os atributos de uma determinada classe; • POST /cmdb/v1.0/instances: suporta a criac¸˜ ao de m´ ultiplas instˆ ancias. ServiceNow CMDB A solu c¸˜ ao proposta pela ServiceNow [ 34 ] permite o armazenamento de informa c¸˜ ao acerca dos componentes da infraestrutura, construindo uma representa c¸˜ ao l ´ ogica dos ativos e relacionamentos entre estes. O modelo de dados da CMDB consiste num conjunto de tabelas ligadas que cont ˆ em todos os ativos e servic¸os controlados pela organizac¸˜ ao, assim como as suas configurac¸ ˜ oes [34]. Existem trˆ es tabelas chave na CMDB [34]: •cmdb:tabela base para armazenar CIs n˜ ao tecnol´ ogicos; •cmdb ci:tabela base para armazenar CIs; •cmdb rel ci:tabela que define os relacionamentos entre CIs. As tabelas podem ser estendidas para outras, atribuindo uma hierarquia de classificac¸˜ ao aos v ´ arios CIs. ´ E ent ˜ ao poss ´ ıvel ter tipos de CIs que descendem de outros tipos na hierarquia. Todos os CIs no sistema t ˆ em um tipo (classe), que se refere ao nome da tabela em que s ˜ ao armazenados. Tamb ´ em ´ e poss ´ ıvel definir novas classes de CIs e relacionamentos. Um relacionamento na CMDB consiste em dois CIs, o “pai” e o “filho”, e o tipo do relacionamento. Al ´ em disto, o sistema mant ´ em a tabela cmdb rel type suggest que cont ´ em os tipos de relacionamentos apropriados para um tipo de CI, com base na sua classe. Os relacionamentos s ˜ ao definidos aos pares, ou seja, o relacionamento existe da perspetiva do CI “pai” e o relacionamento contr´ ario existe da perspetiva do CI “filho” [34]. 2.4. Configuration Management Database 18 ´ E poss ´ ıvel tamb ´ em aceder aos dados presentes na CMDB atrav ´ es da sua API REST, que utiliza o protocolo HTTP e os formatos JSON ou eXtensible Markup Language (XML) [ 75 ] para troca de informac¸˜ ao, e suporta os seguintes m´ etodos [34]: • POST /now/cmdb/instance/{classname} : cria c¸˜ ao de um CI, que pode ter relacionamentos associados, sendo que {classname}se refere ao nome da classe na CMDB; • GET /now/cmdb/meta/{classname} : para uma determinada classe da CMDB, definida no par ˆ ametro {classname} , retorna a classe que estende, as classes que a estendem, os seus atributos e os relacionamentos que pode integrar. Comparac¸˜ ao das ferramentas ´ E poss ´ ıvel observar na Tabela 2.2uma compara c¸˜ ao entre as ferramentas descritas anteriormente. Esta teve como principais par ˆ ametros de compara c¸˜ ao, a forma como as CMDBs armazenam os CIs, relacionamentos e informa c¸˜ ao acerca destes, as capacidades fornecidas pelas suas APIs eosSGBDs suportados por estas. Tabela 2.2: Comparac¸˜ ao das CMDBs analisadas. Caracter´ ısticas i-doit iTop Device42 BMC CMDB ServiceNow CMDB CIs Representac¸˜ ao Registo na tabela isys obj Registo na tabela do seu tipo ?Registo na tabela do seu tipo Registo na tabela do seu tipo Tipo Definidos na tabela isys obj type Diferentes tabelas representam tipos de CIs diferentes ? Diferentes tabelas representam tipos de CIs diferentes Diferentes tabelas representam tipos de CIs diferentes Hierarquia Tipos de grupos de CIs compreendem tipos de CIs, que tˆ em categorias associadas N˜ ao existe ? Existem sub-tipos que herdam as caracter´ ısticas do seu super-tipo Tabelas estendem outras tabelas e herdam as suas caracter´ ısticas Atributos Categorias incluem atributos Colunas da tabela ? Colunas da tabela Colunas da tabela Relacionamentos Representac¸˜ ao CI do tipo relation Tabela com o prefixo lnk ? Tabela do seu tipo Tabela do seu tipo API Protocolo HTTP HTTP HTTP HTTP HTTP Formato troca JSON JSON JSON JSON JSON XML Criar CI Permite Permite Permite Permite Permite Obter tipos de CIs Permite N˜ ao permite N˜ ao permite Permite N˜ ao permite Obter atributos de um tipo Permite N˜ ao permite N˜ ao permite Permite Permite SGBD Sistemas suportados MySQL MariaDB MySQL MariaDB PostgreSQL Microsoft SQL Server Oracle MariaDB Microsoft SQL Server Oracle ? - significa que n˜ ao foi poss´ ıvel obter informac¸ ˜ ao concreta 2.5. Descoberta Autom´ atica 19 Tendo em conta os parˆ ametros analisados, ´ e poss´ ıvel verificar a existˆ encia de algumas semelhanc¸as e diferenc¸as entre as v´ arias CMDBs. As principais semelhanc¸as detetadas foram: • Base nas normas da ITIL; • Acesso ` aCMDB atrav´ es de uma API que utiliza o protocolo HTTP eJSON como formato de troca de informac¸˜ ao; • Possibilidade de criac¸˜ ao de novos CIs atrav´ es da API. As principais diferenc¸as detetadas foram: • Existˆ encia de uma tabela com a definic¸˜ ao dos v´ arios tipos de CIs e relacionamentos em oposic¸˜ ao ` a existˆ encia de uma tabela para cada tipo existente; • Existˆ encia, ou n˜ ao, de uma hierarquia entre os diversos tipos existentes; • Colunas da tabela representam atributos em oposic¸˜ ao ` a existˆ encia de categorias de atributos associadas a tipos; • Obtenc¸˜ ao da informac¸˜ ao acerca do modelo de dados da CMDB atrav´ es da API em oposic¸˜ ao a acessos diretos ` a base de dados; • Diferentes SGBDs suportados. 2.5 descoberta autom ´ atica Nesta secc¸˜ ao v˜ ao ser abordadas ideias, conceitos e implementac¸ ˜ oes relativos ` a descoberta autom´ atica de componentes de uma infraestrutura de TI. Este processo mostra-se particularmente relevante devido ` a capacidade de automatizar o processo de recolha de informac¸˜ ao acerca da infraestrutura, visto que efetuar este processo manualmente implica um trabalho bastante minucioso, demorado e propenso a erros. 2.5.1Processo Atualmente, as empresas possuem infraestruturas computacionais complexas, que compreendem uma enorme variedade de componentes e dependˆ encias entre si [78], apresentando diferentes tipos de arquiteturas dependendo dos seus requisitos [109]. Os seus componentes est˜ ao conectados de forma a executar todas as tarefas que suportam os servic¸os da organizac¸˜ ao, estando habitualmente tamb´ em ligados ` a rede, que permite a comunicac¸˜ ao de dados entre os v´ arios dispositivos [107]. Neste contexto, o conceito de “rede” pode ser definido como um conjunto de dispositivos ligados que trocam informac¸˜ ao uns com os outros, podendo utilizar diversos protocolos de comunicac¸˜ ao [109]. Estes dispositivos podem tamb´ em estar localizados numa ´ area comum, ou em localizac¸ ˜ oes geogr´ aficas distintas, podendo estar v´ arias redes e sub-redes conectadas umas com as outras [109]. Assim, de modo a fazer a criac¸˜ ao autom´ atica da CMDB,´ e necess´ ario descobrir os CIs que existem na infraestrutura e os relacionamentos entre estes. A descoberta da infraestrutura da rede envolve a recolha de dados dos v´ arios dispositivos que existem nessa rede, sendo que cada dispositivo possui um conjunto de informac¸˜ ao que o caracteriza [84]. 2.5. Descoberta Autom´ atica 20 Ao longo do processo de descoberta, e ` a medida que ´ e obtida nova informac¸˜ ao, esta pode ser necess´ aria para obter dados mais espec´ ıficos [78] [84], ou seja, pode ser necess´ ario saber algo sobre uma m´ aquina para a poder explorar mais detalhadamente. Para al´ em disto, pode tamb´ em ser necess´ ario fornecer credenciais para aceder a mais informac¸˜ ao acerca dos CIs, assim como iniciar as comunicac¸ ˜ oes dentro da firewall da empresa [94] de forma a poder comunicar com os diversos componentes. 2.5.2Protocolos Atualmente, existem ferramentas no mercado que implementam diversos m´ etodos relacionados com a descoberta de componentes numa infraestrutura. No entanto, a utilizac¸˜ ao de um ´ unico m´ etodo de descoberta n˜ ao ´ e suficiente, porque v´ arias ferramentas descobrem conjuntos diferentes de informac¸˜ ao [78]. ´ E ent˜ ao necess´ ario perceber como funcionam, que protocolos e m´ etodos utilizam e que tipo de dados ´ e poss´ ıvel obter atrav´ es destas ferramentas. Outra quest˜ ao iminente neste processo passa por perceber como ´ e que estes podem ser utilizados e se s˜ ao suportados pelos dispositivos. O protocolo Internet Control Message Protocol (ICMP) [99] permite descobrir os enderec¸os IP das m´ aquinas ativas na rede. Atrav´ es do comando ping ´ e poss´ ıvel testar a conetividade entre dispositivos. J´ a o comando traceroute, permite descobrir o caminho ente dois nodos [57]. Desta forma ´ e poss´ ıvel perceber como est˜ ao conectados os v´ arios dispositivos de rede da infraestrutura. Como necessita do enderec¸o IP,´ e apenas suportado por dispositivos que implementem a camada 3do modelo OSI. Em muitas redes, apenas uma pequena percentagem dos enderec¸os IP est˜ ao ativos num determinado momento, sendo que este intervalo de enderec¸os pode ser cont´ ınuo ou n˜ ao [109]. As tabelas de routing s˜ ao outro mecanismo que permite obter informac¸˜ ao sobre a rede, porque guardam informac¸˜ ao sobre a topologia desta. Estas est˜ ao guardadas em dispositivos de rede, como por exemplo, routers. Fornecem informac¸˜ ao referente aos enderec¸os associados ao dispositivo; as sub-redes a que estes se encontram diretamente conetados; o conjunto de enderec¸os utilizado pelos dispositivos na sua vizinhanc¸a; e a explicac¸˜ ao de como os pacotes devem ser encaminhados na rede [57]. Tamb´ em o protocolo Address Resolution Protocol (ARP) [98] pode ser utilizado para obter informac¸˜ ao acerca do enderec¸amento na rede. Este mapeia enderec¸os IPv4em enderec¸os MAC, associando enderec¸os de rede a enderec¸os f´ ısicos. Esta informac¸˜ ao, quando obtida, ´ e armazenada na cache ARP dos dispositivos. Ao n´ ıvel dos enderec¸os IPv6´ e utilizado o protocolo Neighbor Discovery Protocol (NDP) [93], que permite que sejam encontrados outros dispositivos na sua vizinhanc¸a. Cada dispositivo que implemente este protocolo possui a sua neighbor cache, que possui informac¸˜ ao acerca da resoluc¸˜ ao de enderec¸os IPv6 em enderec¸os MAC e se estes correspondem a um host ou a um router [72]. Outro recurso que pode ser utilizado para obter informac¸˜ ao sobre a rede ´ e a tabela Forwarding Database (FDB). Esta tabela ´ e utilizada por dispositivos layer 2[57] e mapeia os enderec¸os MAC nas portas em que foram descobertos. Usualmente os switches s˜ ao descobertos atrav´ es da tabela FDB, pois podem n˜ ao reconhecer IP. Para al´ em destes, existe tamb´ em o protocolo Link Layer Discovery Protocol (LLDP) [63] que, ao n´ ıvel da camada de ligac¸˜ ao de dados, facilita a troca de informac¸˜ ao entre dispositivos. ´ E utilizado pelos dispositivos de rede para anunciarem a sua identidade, capacidades e os seus vizinhos mais pr´ oximos numa LAN [64]. A informac¸˜ ao sobre os dispositivos ´ e armazenada em Management Information Bases (MIBs) [63], que s˜ ao conjuntos organizados 2.5. Descoberta Autom´ atica 21 de informac¸˜ ao que podem ser acedidos utilizando o protocolo Simple Network Management Protocol (SNMP) [60]. Tamb´ em o protocolo Spanning Tree Protocol (STP) [97] permite obter informac¸˜ ao sobre a topologia da rede [109]. Este protocolo constr´ oi uma spanning tree que caracteriza o relacionamento entre os nodos da rede, conectada com pontes. Para obter a topologia da rede na camada de ligac¸˜ ao de dados, ´ e necess´ ario analisar os dados da spanning tree de cada ponte, usando, por exemplo, o protocolo SNMP [57]. O protocolo SNMP utiliza pedidos User Datagram Protocol (UDP) para aceder aos dados armazenados nas MIBs [57] dos dispositivos, tais como routers, switches, servidores, impressoras, workstations, entre outros. A informac¸˜ ao ´ e tratada na forma de vari´ aveis e descreve o estado do sistema e a sua configurac¸˜ ao. Existem pedidos definidos exclusivamente para obter informac¸˜ ao sobre os dispositivos: •GetRequest:pedido feito para obter o valor de uma vari´ avel ou de uma lista de vari´ aveis; •GetNextRequest:tem como objetivo descobrir as vari´ aveis existentes e os seus valores, sendo poss´ ıvel percorrer toda a MIB; •GetBulkRequest:pedido de m´ ultiplas iterac¸ ˜ oes de GetNextRequest. Existem trˆ es vers˜ oes principais deste protocolo: SNMPv1[61], SNMPv2c [101]eSNMPv3 [62]. Nas vers˜ oes SNMPv1eSNMPv2c a autenticac¸˜ ao ´ e feita recorrendo a uma community string, que representa uma palavra-passe necess´ aria para a troca de informac¸˜ ao entre os dispositivos. Na vers˜ ao SNMPv3, os dispositivos s˜ ao configurados com um nome de utilizador e com uma palavra-passe, sendo que, para os pedidos serem autenticados ´ e necess´ ario que os dispositivos tenham conhecimento das palavras-passe associadas aos nomes de utilizador. Para al´ em disto, para a encriptac¸˜ ao dos pedidos, ´ e tamb´ em necess´ ario que os dispositivos tenham conhecimento da palavra-passe associada ao nome de utilizador. No entanto, este protocolo tamb´ em apresenta algumas desvantagens. Este implica a configurac¸˜ ao de um agente SNMP na m´ aquina; est´ a suscet´ ıvel ` a perda de informac¸˜ ao devido ` a utilizac¸˜ ao do protocolo UDP; e implica a transferˆ encia de grandes quantidades de dados entre m´ aquinas [60]. ´ E apresentado em [95] uma proposta de descoberta da topologia da rede utilizando o protocolo SNMP. O termo topologia ´ e definido como “a combinac¸˜ ao de ligac¸ ˜ oes e nodos numa rede e as interconex˜ oes entre os nodos”. O processo de descoberta descrito est´ a dividido em trˆ es m´ odulos, sendo estes a descoberta de dispositivos, a descoberta do tipo de dispositivos e a descoberta de conetividade entre estes. Inicialmente, com base num conjunto de enderec¸os IP e uma ou mais community strings,´ e utilizada a tabela de roteamento, a cache ARP e o protocolo ICMP para encontrar dispositivos na rede, tornando o mecanismo de descoberta num processo recursivo. Para cada dispositivo encontrado, ´ e descoberto o seu tipo, que ´ e obtido tendo em conta o valor guardado em sysServices1. O algoritmo de descoberta do tipo de dispositivo verifica que camadas do modelo OSI s˜ ao suportadas pela m´ aquina, determinando de que tipo de dispositivo se trata. Finalmente, dependendo do tipo, ´ e recolhida informac¸˜ ao espec´ ıfica de forma a encontrar conetividade entre os v´ arios dispositivos. O protocolo Secure Shell (SSH) [113] permite estabelecer uma conex˜ ao com um sistema. A partir deste tipo de conex˜ ao ´ e poss´ ıvel ter acesso ` a m´ aquina e obter informac¸˜ ao mais 1http://oid-info.com/get/1.3.6.1.2.1.1.7 2.5. Descoberta Autom´ atica 22 espec´ ıfica sobre a mesma [94]. No caso de sistemas Microsoft Windows, pode ser utilizado oWMI, que permite a gest˜ ao e acesso de dados nestes sistemas. Permite tamb´ em que este acesso seja feito de forma remota recorrendo ao Windows Remote Management (WinRM) [17]. Tanto o protocolo SSH como o WinRM necessitam das credenciais das m´ aquinas para acederem a estas. 2.5.3Arquiteturas Alguns autores publicaram as suas implementac¸ ˜ oes de processos de descoberta autom´ atica num ambiente de rede [109] [107] [94]. ´ E disso exemplo o sistema apresentado em [109], que tem como prop´ osito descobrir v´ arios dispositivos num ambiente de rede e as ligac¸ ˜ oes entre si. Este ´ e composto por: •Mecanismo de descoberta: descobre os dispositivos presentes na rede e as ligac¸ ˜ oes entre estes, determinando a topologia da infraestrutura de rede (atrav´ es do comando ping, da consulta da informac¸ ˜ ao das MIBs, via protocolo SNMP, e do protocolo STP); •Monitor de rede: monitoriza os dispositivos para detetar alterac¸ ˜ oes na rede; •Interface de rede: permite ao mecanismo de descoberta comunicar com os dispositivos dentro da rede; •Base de dados da rede: armazena a informac¸˜ ao recolhida pelo mecanismo de descoberta; •Dispositivo de entrada: permite que o utilizador envie informac¸˜ ao ao sistema; •Dispositivo de exibic¸˜ ao: permite ao utilizador uma visualizac¸˜ ao da topologia da rede. Este sistema apresenta tamb´ em uma interface com o utilizador que o permite configurar a descoberta, inici´ a-la, apresentar resultados e informac¸˜ ao sobre o estado da mesma e filtrar resultados indesejados. Outro exemplo ´ e o processo de descoberta apresentado em [107]. Este ´ e composto por: •Unidade de descoberta: respons´ avel por descobrir os componentes do sistema e a sua informac¸˜ ao de configurac¸ ˜ ao (utiliza o comando ping para detetar que enderec¸os IP est˜ ao ativos na rede); •Base de dados: mant´ em um reposit´ orio central dos componentes do sistema descobertos; •Mapa da rede: fornece uma vista hier´ arquica do sistema e das propriedades dos componentes que fazem parte deste. 2.5.4Ferramentas Atualmente, existem ferramentas de descoberta que utilizam alguns dos protocolos descritos anteriormente para fazer a descoberta e explorac¸ ˜ ao dos componentes da rede. No entanto, estas podem n˜ ao responder ` as necessidades dos utilizadores, sendo muitas vezes necess´ ario utilizar v´ arias ferramentas ou proceder ` a descoberta manual para obter os dados pretendidos [78]. 2.5. Descoberta Autom´ atica 23 Nmap O Nmap [86]´ e uma ferramenta open source que permite a explorac¸˜ ao e invent´ ario da rede, sendo suportado pela maioria dos sistemas operativos. Esta n˜ ao necessita das credenciais de acesso de cada m´ aquina para efetuar a descoberta destas na rede [94]. Permite fazer o scan de uma rede inteira ou de apenas um host [86]. Oscan efetuado comec¸a por explorar os hosts especificados pelo utilizador, que podem ser uma combinac¸˜ ao de nomes Domain Name System (DNS) [90], enderec¸os IP ou notac¸ ˜ oes de rede Classless Inter-Domain Routing (CIDR) [70], verificando se estes se encontram ativos na rede, recorrendo a pedidos ARP,Transmission Control Protocol (TCP) ou ICMP. Depois de saber que hosts se encontram ativos, ´ e efetuada a resoluc¸˜ ao de nomes DNS.´ E tamb´ em verificado o estado das portas do host, se estas se encontram abertas, fechadas, filtradas e n˜ ao-filtradas e que software, e respetivas vers˜ oes, est´ a a ser executado nestas. Al´ em disto, oscan ´ e tamb´ em capaz de descobrir o sistema operativo que est´ a a ser executado no host e, atrav´ es do comando traceroute permite tamb´ em descobrir os caminhos na rede entre v´ arios hosts. Adicionalmente, ´ e poss´ ıvel recorrer a scripts para obter ainda mais informac¸˜ ao sobre os hosts (detec¸˜ ao de vers˜ oes avanc¸ada, notificac¸˜ ao de vulnerabilidades de servic¸os, descoberta de backdoors e outro malware, entre outras coisas) [86]. Assim, o Nmap ´ e capaz de [76]: • detetar os hosts ativos na rede; • detetar o nome e tipo do host; • identificar os enderec¸os IP eMAC; • explorar as portas abertas, fechadas, filtradas e n˜ ao-filtradas no host; • detetar servic¸os (protocolos utilizados, nome da aplicac¸ ˜ ao e vers˜ ao) a correr nas portas abertas; • detetar sistemas operativos e respetivas vers˜ oes. Angry IP Scanner O Angry IP Scanner [79]´ e uma ferramenta open-source que funciona em sistemas operativos Windows, macOS [42] e Linux [41], e permite fazer o scan da rede. Usualmente, o utilizador fornece o intervalo de enderec¸os IP com o objetivo de o scan verificar se cada um destes se trata de um host ativo e obt´ em informac¸˜ ao sobre os mesmos. A informac¸˜ ao recolhida pode incluir: • se o host est´ a ativo; • nome do host e do dom´ ınio; • enderec¸os IP eMAC; • portas TCP eUDP abertas e filtradas; • servic¸os a correr e respetivas vers˜ oes; • o valor m´ edio do roundtrip time; 2.7. Trabalho Relacionado 30 BMC Discovery O BMC Discovery [22]´ e uma ferramenta capaz de automatizar o processo de descoberta de ativos e mapeamento de dependˆ encias entre aplicac¸ ˜ oes, sendo constitu´ ıda por v´ arios componentes. O BMC Discovery Outpost ´ e uma aplicac¸ ˜ ao que obt´ em a informac¸˜ ao acerca dos produtos de hardware e sofware da organizac¸˜ ao. ´ E executada numa m´ aquina com um sistema operativo Microsoft Windows e conecta-se aos dispositivos atrav´ es do protocolo HyperText Transfer Protocol Secure (HTTPS) [103]. O BMC Discovery envia um pedido ao BMC Discovery Outpost para explorar os enderec¸os IP fornecidos, e o BMC Discovery Outpost acede aos alvos recorrendo a credenciais especificadas previamente. Uma vez conectado ` a m´ aquina alvo, executa comandos para aceder a informac¸˜ ao acerca deste, cifrando os resultados obtidos e enviando-os para o BMC Discovery. Quando o BMC Discovery recebe os dados armazena-os no Datastore. Podem ser executados v´ arios BMC Discovery Outpost em simultˆ aneo para lidarem com v´ arios segmentos de rede, sendo que todos comunicam com a mesma instˆ ancia do BMC Discovery. O Discovery Service desempenha um trabalho semelhante ao Discovery Outpost, mas ´ e executado na mesma m´ aquina do BMC Discovery. Como ´ e baseado em Linux, necessita de um ou mais proxies Windows para a descoberta de sistemas baseados em Microsoft Windows. A Discovery Queue consiste numa fila de espera que possui tarefas a ser executadas. O Discovery service e o BMC Discovery Outpost interrogam a fila de espera por tarefas a executar. Quando estas s˜ ao finalizadas, o seu resultado ´ e enviado para a fila, sendo que depois o Reasoning interroga a fila de espera por estes resultados. O Reasoning utiliza padr˜ oes para inferir informac¸˜ ao acerca de hosts e programas com base na informac¸˜ ao descoberta. Cada padr˜ ao representa conhecimento particular acerca de um produto de hardware ou software, sendo este conhecimento utilizado para gerar informac¸˜ ao mais detalhada acerca dos elementos descobertos. A informac¸˜ ao ´ e depois armazenada na Datastore. A Datastore ´ e a base de dados onde a informac¸˜ ao descoberta e inferida ´ e armazenada. O Cluster consiste em duas ou mais m´ aquinas BMC Discovery, em que uma delas coordena as outras, sendo que podem ser adicionadas mais m´ aquinas ao Cluster em qualquer altura. Quando isto acontece a informac¸˜ ao ´ e separada em partes iguais pelas m´ aquinas do Cluster, para que a sua utilizac¸˜ ao e desempenho sejam o mais otimizados poss´ ıvel [22]. A descoberta tem por base uma lista de enderec¸os IP da rede a descobrir, assim como os enderec¸os que n˜ ao devem ser explorados. Para efetuar a descoberta, o BMC Discovery utiliza diferentes m´ etodos dependendo do tipo de alvos a explorar [22]: •SNMP; •SSH; •WMI; •HTTPS; • proxies Windows; • acesso recorrendo ` as credenciais; • scripts; •APIs REST. 2.7. Trabalho Relacionado 31 Cada m´ etodo permite a descoberta de determinados tipos de informac¸˜ ao. Na Tabela 2.4 s˜ ao apresentados os dispositivos poss´ ıveis de explorar pelos diferentes m´ etodos disponibilizados pela ferramenta. Tabela 2.4: Dispositivos explorados pela ferramenta de descoberta BMC Discovery. Sistemas Operativos Fontes de Dados Rede Dispositivos Virtualizac¸˜ ao Armazenamento Microsoft Windows Linux Unix IBM z/OS Bases de dados APIs REST Switches Cisco Nexus IBM I/AS400 Balanceador de Carga Management Controllers Oracle WebLogic Tomcat Mainframe WebSphere Clusters Dispositivos empilhados (Cisco) Plataformas Cloud ESX ESXi EMC VPLEX Containers Entidades de armazenamento O BMC Discovery permite a integrac¸˜ ao da informac¸˜ ao com a CMDB atrav´ es do mecanismo de sincronizac¸˜ ao. Relativamente ` a BMC CMDB, este mecanismo permite que os dados presentes na CMDB sejam sincronizados com a informac¸˜ ao descoberta pelo BMC Discovery. No entanto, o modelo de dados do BMC Discovery ´ e diferente do CDM usado pela CMDB, sendo que o mecanismo de sincronizac¸˜ ao ´ e respons´ avel por transformar a informac¸˜ ao de um modelo para o outro. O mapeamento padr˜ ao fornece a correspondˆ encia para o CDM, no entanto, quando s˜ ao adicionados nodos personalizados, ´ e necess´ ario efetuar o mapeamento destes manualmente. Para al´ em disto, ´ e tamb´ em poss´ ıvel integrar a informac¸˜ ao descoberta com a ServiceNow CMDB, cujo mapeamento padr˜ ao tamb´ em j´ a se encontra definido [22]. ServiceNow Discovery O ServiceNow Discovery [48] encontra aplicac¸ ˜ oes e dispositivos na rede e atualiza a ServiceNow CMDB com a informac¸˜ ao descoberta. Podem ser efetuados dois tipos de descoberta distintos. A descoberta horizontal permite encontrar os dispositivos ativos na rede e recolhe informac¸˜ ao acerca destes, podendo tamb´ em criar relacionamentos entre os dispositivos e as aplicac¸ ˜ oes que comunicam entre si. No entanto, n˜ ao est´ a ciente da existˆ encia de servic¸os. A descoberta de cima para baixo ´ e utilizada para mapear as dependˆ encias entre as aplicac¸ ˜ oes e dispositivos que comp˜ oem um servic¸o. Usualmente, s˜ ao utilizadas em conjunto, sendo que ´ e inicialmente executada a descoberta horizontal para encontrar as m´ aquinas, e posteriormente ´ e executada a descoberta de cima para baixo para estabelecer os relacionamentos entre servic¸os. O processo de descoberta utiliza scripts que recolhem e fazem o processamento da informac¸˜ ao. Os scripts de descoberta s˜ ao executados por um servidor Management, Instrumentation, and Discovery (MID), que pode ser executado numa m´ aquina da rede ou na cloud, que, ap´ os a execuc¸˜ ao, retorna os resultados para serem processados [48]. A descoberta horizontal ´ e composta por um conjunto de etapas [94]: •An´ alise: descobre portas abertas nas m´ aquinas e alguma informac¸˜ ao sobre estas; 2.7. Trabalho Relacionado 32 •Classificac¸˜ ao: tendo em conta o tipo do dispositivo, executa pedidos espec´ ıficos para o explorar; •Identificac¸ ˜ ao: tenta obter mais informac¸˜ ao sobre o dispositivo e determina se este j´ a se encontra na CMDB, fazendo a reconciliac¸˜ ao da informac¸˜ ao, caso exista, ou criando oCI, caso contr´ ario; •Explorac¸˜ ao: obt´ em mais informac¸˜ ao sobre o dispositivo, como aplicac¸ ˜ oes a correr, e outros atributos. Os tipos de descoberta horizontal que podem ser utilizados pela aplicac¸˜ ao s˜ ao [48]: •Descoberta da rede: deteta os enderec¸os IP utilizados pela rede da organizac¸ ˜ ao; •Descoberta de CIs:encontra dispositivos e aplicac¸ ˜ oes na rede; •Descoberta de cloud: encontra recursos cloud da organizac¸˜ ao; •Descoberta sem servidor: descobre aplicac¸ ˜ oes em hosts. Para obter informac¸˜ ao sobre as m´ aquinas utiliza diferentes m´ etodos dependendo do tipo de m´ aquina a ser explorado. Recorre ao protocolo SSH para se conectar a uma m´ aquina e executar comandos para recolher informac¸˜ ao sobre esta; ao protocolo SNMP para recolher informac¸˜ ao armazenada nas MIBs dos dispositivos; e ao WMI, PowerShell e WinRM para recolher informac¸˜ ao sobre sistemas Microsoft Windows. Esta ferramenta ´ e ent˜ ao capaz de descobrir sistemas e workstations Windows, sistemas Unix e Linux, dispositivos de rede, servidores, bases de dados, impressoras, plataformas cloud, m´ aquinas virtuais, clusters, relacionamentos entre processos a correr e servidores, entre outros. 2.7.2Sum´ ario Ap´ os a an´ alise das ferramentas ´ e poss´ ıvel tirar algumas conclus˜ oes acerca dos m´ etodos de descoberta utilizados, assim como da forma como a informac¸ ˜ ao recolhida ´ e integrada com as CMDBs. ´ E poss´ ıvel verificar que, em geral, os m´ etodos de descoberta mais utilizados s˜ ao: •Ping; • Nmap; • Captura de pacotes; •SNMP; • Conex˜ ao com a m´ aquina a ser explorada via WinRM eSSH, recorrendo ` as suas credenciais de acesso, executando comandos ou scripts; • Instalac¸ ˜ ao de ferramentas de software nas m´ aquinas a ser exploradas. 2.7. Trabalho Relacionado 33 Relativamente ` a integrac¸ ˜ ao com as CMDBs,´ e verificado que, usualmente, as ferramentas de descoberta de um determinado fornecedor permitem apenas a integrac¸˜ ao com a CMDB deste. Foi apenas poss´ ıvel perceber que o mecanismo BMC Discovery permite, n˜ ao s´ o a integrac¸˜ ao com a BMC CMDB, como tamb´ em com a ServiceNow CMDB, recorrendo a mapeamentos j´ a configurados. No entanto, geralmente, as CMDBs permitem a personalizac¸˜ ao dos tipos de CIs, relacionamentos e atributos que utilizam. Neste caso, o mapeamento destes nodos personalizados tem de ser feito manualmente. 3 PROBLEMA E DESAFIOS Neste cap´ ıtulo vai ser apresentada a soluc¸˜ ao proposta para o problema que o projeto tenta solucionar, assim como os principais desafios que podem surgir no desenvolvimento desta. 3.1 problema Analisando o resultado final em iniciativas de criac¸˜ ao de uma CMDB,´ e estimado que cerca de 75% destas falham em comparac¸˜ ao com as expetativas iniciais [66]. Assim, ´ e poss´ ıvel afirmar que existe a necessidade de facilitar o processo de criac¸˜ ao de uma CMDB. No entanto, construir uma CMDB implica a utilizac¸˜ ao de mecanismos autom´ aticos de descoberta e de integrac¸˜ ao com a CMDB, visto que a criac¸˜ ao manual ´ e um processo minucioso e propenso a erros. Assim, existem alguns problemas derivados do facto de este processo ter de ser praticamente todo implementado pelas organizac¸ ˜ oes. Um desses problemas deriva de invent´ arios incompletos e falta de capacidades de descoberta. Esta informac¸˜ ao incompleta pode levar a m´ as decis˜ oes e, consequentemente, maus resultados. Assim, o prop´ osito deste projeto, passa pelo desenvolvimento de uma plataforma capaz de fazer a descoberta autom´ atica dos componentes da infraestrutura computacional da organizac¸˜ ao e o posterior povoamento da sua CMDB. Isto, tendo sempre em conta um processo autom´ atico com o m´ ınimo esforc¸o por parte do utilizador. 3.2 abordagem proposta Existem quatro elementos necess´ arios para o funcionamento do projeto: a infraestrutura computacional da organizac¸˜ ao; o administrador que vai interagir com a plataforma; a plataforma de criac¸˜ ao autom´ atica a ser desenvolvida; e a CMDB utilizada pela organizac¸˜ ao. Estes quatro elementos necessitam de interagir entre si para o envio e recec¸˜ ao de informac¸˜ ao fundamental para a correta execuc¸˜ ao do processo. As tarefas a serem realizadas pela plataforma podem ser divididas em trˆ es fases: • fase de descoberta; • fase de mapeamento; • fase de povoamento. 34 3.3. Arquitetura do sistema 35 3.3 arquitetura do sistema A Figura 3.1apresenta a arquitetura proposta para o sistema, realc¸ando a interac¸˜ ao entre todos os elementos e as diversas fases do processo. Administrador Infraestrutura computacional CMDB guarda acede acede acede guarda Figura 3.1: Arquitetura do sistema proposta. 3.3.1Fase de Descoberta A fase de descoberta dever´ a ser capaz de encontrar os componentes que fazem parte da infraestrutura a ser analisada e armazenar a informac¸˜ ao recolhida acerca destes. Deve recorrer a mecanismos de descoberta distintos, que permitam recolher diferentes tipos de informac¸˜ ao acerca de diversos dispositivos. A fase de descoberta deve ter como base um conjunto definido de enderec¸os que deve ser explorado. Deve ser capaz de efetuar uma descoberta b´ asica nestes enderec¸os, recolhendo informac¸˜ ao acerca das m´ aquinas ativas e informac¸˜ ao essencial acerca destas, podendo ser composta por um ou mais mecanismos diferentes. Um mecanismo de descoberta consiste num m´ etodo que ´ e executado, recolhe informac¸˜ ao acerca da infraestrutura, e envia essa informac¸˜ ao para a ferramenta. De cada vez que um mecanismo ´ e executado, deve ser realizado o processo de reconciliac¸˜ ao com base na informac¸˜ ao recolhida, porque ´ e importante eliminar qualquer tipo de dados duplicados. Para al´ em disto, estes mecanismos podem recolher o mesmo tipo de informac¸˜ ao e obter valores diferentes. Desta forma, ´ e necess´ ario perceber qual a informac¸˜ ao efetivamente v´ alida. Uma das soluc¸ ˜ oes passa pela execuc¸˜ ao destes mecanismos de acordo com a sua prioridade. Ou seja, devem ser executados primeiro os mecanismos de menor prioridade, porque desta forma, quando os mecanismos seguintes s˜ ao executados e encontram um valor diferente para algum parˆ ametro j´ a recolhido, como s˜ ao considerados mais confi´ aveis, podem substituir esta informac¸ ˜ ao, n˜ ao sendo necess´ ario um processo manual de selec¸˜ ao da informac¸˜ ao mais vi´ avel. Um mecanismo de descoberta pode tamb´ em precisar das credenciais de acesso da m´ aquina para recolher de- 3.3. Arquitetura do sistema 36 terminado tipo de informac¸˜ ao, sendo necess´ ario manter registadas estas credenciais de forma segura. Posteriormente, deve ser efetuada uma descoberta mais detalhada, com base num conjunto de categorias de informac¸˜ ao e nos tipos de m´ aquinas descobertos na fase anterior, sendo executados os mecanismos de descoberta que se enquadram nestes parˆ ametros. Estes mecanismos devem estar associados a uma categoria e a um tipo de CI espec´ ıfico. Assim como na descoberta b´ asica, estes mecanismos devem estar ordenados crescentemente de acordo com a sua prioridade de forma a facilitar o processo de reconciliac¸˜ ao. Estes mecanismos espec´ ıficos s˜ ao ent˜ ao componentes independentes, que s˜ ao utilizados de acordo com as necessidades do processo espec´ ıfico. ´ E tamb´ em relevante permitir a recolha de informac¸˜ ao de outras ferramentas de descoberta j´ a existentes. Desta forma, ´ e poss´ ıvel tirar partido de ferramentas j´ a utilizadas e que possuem informac¸˜ ao relevante acerca da infraestrutura. No final, toda a informac¸˜ ao recolhida e processada deve ser armazenada numa base de dados. ´ E apresentado na Figura 3.2o diagrama de atividades do processo de descoberta da infraestrutura. 3.3. Arquitetura do sistema 37 Administrador Criação automática de CMDB Criar password vault Definir endereços a explorar Descoberta básica Selecionar categorias a explorar Descoberta detalhada Povomento da base de dados Definir palavra-passe do password vault Definir fonte externa a utilizar Processamento da informação recebida Verificar acesso à fonte externa conexão válida? utilizar fonte externa? palavra-passe válida? password vault já existe? endereços corretos? definir mais endereços? [não] [não] [sim] [não] [sim] [sim] [corretos] [incorretos] [palavra-passe inválida] [palavra-passe válida] [sim] [não] Figura 3.2: Diagrama de atividades da fase de descoberta. 3.3. Arquitetura do sistema 38 3.3.2Fase de Mapeamento Esta fase consiste no mapeamento do modelo da base de dados do sistema de criac¸˜ ao autom´ atica para o modelo da CMDB a ser utilizada pela organizac¸˜ ao. Devem ser definidas as regras de transformac¸˜ ao entre os modelos que permitam associar os CIs da base de dados aos CIs da CMDB. Inicialmente, ´ e necess´ ario obter informac¸˜ ao acerca do modelo de dados da ferramenta, ou seja, da base de dados onde est˜ ao armazenados os dados obtidos na fase de descoberta. Posto isto, ´ e necess´ ario aceder ` a base de dados e perceber que tipos de CIs est˜ ao definidos, quais os seus atributos, que tipos de relacionamentos est˜ ao definidos entre estes componentes, e que atributos est˜ ao associados a estes relacionamentos. Pode ser ent˜ ao definido o modelo de dados da base de dados utilizada. ´ E apresentado na Figura 3.3o diagrama de atividades que descreve o processamento do modelo de dados da BD da ferramenta. Efetuar conexão com a base e dados Obter tipos de CIs na base de dados Obter tipos de relacionamentos na base de dados Obter atributos dos CIs na base de dados Obter atributos dos relacionamentos na base de dados Definir o modelo de dados da base de dados Introduzir informação acerca da base de dados Verificar informação informação válida? conexão efetuada? [não] [sim] [sim] [não] Figura 3.3: Diagrama de atividades do processamento do modelo de dados da base de dados. De seguida, ´ e necess´ ario perceber como est´ a estruturado o modelo de dados da CMDB. Tal como para a base de dados, ´ e necess´ ario perceber que tipos de CIs est˜ ao definidos, quais os seus atributos, que tipos de relacionamentos podem ser definidos entre estes componentes, e que atributos est˜ ao associados a estes relacionamentos. ´ E necess´ ario tamb´ em perceber como s˜ ao guardados os atributos na CMDB, nomeadamente que tipos de dados s˜ ao utilizados. Este processo pode ser executado de duas formas. A primeira, passa por analisar a estrutura da base de dados utilizada pela CMDB. A segunda passa por efetuar pedidos ` a API da CMDB para obter esta informac¸˜ ao. Depois de obter toda a informac¸˜ ao necess´ aria da CMDB,´ e poss´ ıvel definir o modelo de dados da mesma. Na Figura 3.4´ e poss´ ıvel observar o diagrama de atividades que descreve o processamento do modelo de dados de uma CMDB. 3.3. Arquitetura do sistema 39 Administrador Criação automática de CMDB Selecionar método de conexão à CMDB Selecionar software da CMDB Introduzir informação acerca da CMDB Verificar informação Verificar conexão com a CMDB Efetuar pedido à CMDB Processar e normalizar informação recolhida Definir o modelo de dados da CMDB informação válida? conexão efetuada? mais pedidos? [sim] [não] [sim] [não] [sim] [não] Figura 3.4: Diagrama de atividades do processamento do modelo de dados da CMDB. Finalmente, ´ e necess´ ario fazer o mapeamento entre os modelos de dados da CMDB e da base de dados, ou seja, ´ e necess´ ario estabelecer correspondˆ encias entre os tipos de CIs, relacionamentos e atributos dos dois modelos. Para isto, ´ e necess´ ario calcular a semelhanc¸a entre todos os elementos de cada modelo, e selecionar os mais semelhantes, atribuindo a um elemento do modelo da base de dados uma correspondˆ encia com um elemento do modelo da CMDB. Assim, no final, ´ e obtido um conjunto de regras de transformac¸˜ ao que associam os elementos mais semelhantes dos dois modelos. Na Figura 3.5´ e poss´ ıvel observar o processo de definic¸˜ ao das regras de transformac¸˜ ao entre os dois modelos de dados. Obter modelo de dados da CMDB Obter modelo de dados da base de dados Calcular grau de semelhança entre os tipos de CIs dos modelos Calcular grau de semelhança entre os tipos de relacionamentos dos modelos Calcular grau de semelhança entre os atributos dos tipos de relacionamentos dos modelos Calcular grau de semelhança entre os atributos dos tipos de CIs dos modelos Selecionar elementos mais semelhantes Definir regras de transformação Figura 3.5: Diagrama de atividades da defini c¸˜ ao das regras de transforma c¸˜ ao entre os modelos de dados. 4.2. Implementac¸˜ ao 46 -id : int -title : string -description : string -uuid : string -status : string -serial_number : string -mac_address : string -ipv4_address : string[] -ipv6_address : string[] -os_family : string Configuration Item -id : int -title : string Configuration Item Type -id : int -title : string Relationship -id : int -title : string Relationship Type -id : int -title : string -value : string Attribute attributes * source/target 2 0..* type 1 type 1 attributes * Figura 4.4: Diagrama de classes da base de dados. Tendo em conta que o GraphDB [26] permite a importac¸ ˜ ao dos dados no formato Resource Description Framework (RDF) [14], ou seja, a express˜ ao da informac¸˜ ao e do esquema de dados ´ e feita recorrendo a triplos, ´ e necess´ ario efetuar a definic¸˜ ao deste esquema. Em RDF um triplo representa uma relac¸˜ ao de recursos e propriedades. Existem diversas sintaxes RDF, mas a selecionada foi Turtle [58]. Assim, para definir o esquema de dados, ´ e necess´ ario definir as classes e propriedades da ontologia. Na Listagem 4.1´ e poss´ ıvel observar a definic¸˜ ao das classes em Turtle. Na Listagem 4.2s˜ ao apresentadas as propriedades dos dados, que correspondem aos atributos das classes no esquema da Figura 4.4. Por fim, na Listagem 4.3, est˜ ao definidas as propriedades dos objetos que correspondem ` as associac¸ ˜ oes entre as classes. Listagem 4.1: Classes da ontologia definidas em Turtle. :ConfigurationItem rdf:type owl:Class ; rdfs:label "Configuration Item" ; rdfs:comment "Represents an organization's infrastructure component.". :Relationship rdf:type owl:Class ; rdfs:label "Relationship" ; rdfs:comment "Represents the relationship between two organization's infrastructure components.". :ConfigurationItemType rdf:type owl:Class ; rdfs:label "Configuration Item Type" ; rdfs:comment "Represents the type of a configuration item.". :RelationshipType rdf:type owl:Class ; rdfs:label "Relationship Type" ; rdfs:comment "Represents the type of a relationship.". :Attribute rdf:type owl:Class ; rdfs:label "Attribute" ; 4.2. Implementac¸˜ ao 47 rdfs:comment "Represents an attribute of a configuration item or relationship.". Listagem 4.2: Propriedades dos dados da ontologia definidas em Turtle. :uuid rdf:type owl:DatatypeProperty ; rdfs:domain :ConfigurationItem ; rdfs:range xsd:string ; rdfs:comment "The universally unique identifier (128-bit number) assigned to the item.". :serial_number rdf:type owl:DatatypeProperty ; rdfs:domain :ConfigurationItem ; rdfs:range xsd:string ; rdfs:comment "The manufacturer-allocated number used to identify the item.". :title rdf:type owl:DatatypeProperty ; rdfs:domain :ConfigurationItem , :Relationship , :ConfigurationItemType , :RelationshipType , :Attribute ; rdfs:range xsd:string ; rdfs:comment "The label by which the item is known.". :description rdf:type owl:DatatypeProperty ; rdfs:domain :ConfigurationItem ; rdfs:range xsd:string ; rdfs:comment "The textual description of the item.". :status rdf:type owl:DatatypeProperty ; rdfs:domain :ConfigurationItem ; rdfs:range xsd:string ; rdfs:comment "The current status value for the operational condition of the item.". :mac_address rdf:type owl:DatatypeProperty ; rdfs:domain :ConfigurationItem ; rdfs:range xsd:string ; rdfs:comment "The media access control address assigned to the item.". :value rdf:type owl:DatatypeProperty ; rdfs:domain :Attribute ; rdfs:range xsd:string ; rdfs:comment "The value of the attribute.". :has_ipv4 rdf:type owl:DatatypeProperty ; rdfs:domain :ConfigurationItem ; rdfs:range xsd:string ; 4.2. Implementac¸˜ ao 48 rdfs:comment "The associated IPv4 address.". :has_ipv6 rdf:type owl:DatatypeProperty ; rdfs:domain :ConfigurationItem ; rdfs:range xsd:string ; rdfs:comment "The associated IPv6 address.". :os_family rdf:type owl:DatatypeProperty ; rdfs:domain :ConfigurationItem ; rdfs:range xsd:string ; rdfs:comment "The associated operating system family.". Listagem 4.3: Propriedades dos objetos da ontologia definidas em Turtle. :has_ci_type rdf:type owl:ObjectProperty ; rdfs:domain :ConfigurationItem ; rdfs:range :ConfigurationItemType . :has_rel_type rdf:type owl:ObjectProperty ; rdfs:domain :Relationship ; rdfs:range :RelationshipType . :has_source rdf:type owl:ObjectProperty ; rdfs:domain :Relationship ; rdfs:range [rdf:type owl:Restriction; owl:onProperty :has_source; owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger; owl:onClass :ConfigurationItem ] . :has_target rdf:type owl:ObjectProperty ; rdfs:domain :Relationship ; rdfs:range [rdf:type owl:Restriction; owl:onProperty :has_target; owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger; owl:onClass :ConfigurationItem ] . :has_attribute rdf:type owl:ObjectProperty ; rdfs:domain :Relationship , :ConfigurationItem ; rdfs:range :Attribute . 4.2.2Gest˜ ao de palavras-passe Tendo em conta que alguns mecanismos de descoberta precisam das credenciais das m´ aquinas para as explorar, surge a necessidade de utilizar uma ferramenta capaz de as 4.2. Implementac¸˜ ao 49 armazenar de forma segura. Desta forma, foi adotada a utilizac¸˜ ao de um password vault, capaz de armazenar e cifrar v´ arias palavras-passe, sendo que o utilizador necessita apenas de memorizar a palavra-passe do password vault de forma a aceder a estas. Considerando que j´ a existem ferramentas deste g´ enero implementadas, recorreu-se ` a adaptac¸˜ ao do projeto PasswordVault [55]. Para a utilizac¸˜ ao deste foi necess´ ario implementar o processo de uma forma diferente, de forma a que este se enquadrasse no projeto descrito neste documento. Essencialmente, este mecanismo permite ao programa: • criar um novo password vault caso este ainda n˜ ao exista; • definir a sua palavra-passe; • desbloquear ou bloquear o password vault; • armazenar uma nova palavra-passe, associando-a a um nome de utilizador e a um dom´ ınio; • aceder a uma palavra-passe previamente armazenada; • eliminar o password vault. Na Figura 4.5s˜ ao apresentados alguns exemplos de utilizac¸˜ ao das funcionalidades do password vault descrito. Figura 4.5: Exemplo de utilizac¸˜ ao do password vault. 4.2.3Normalizac¸˜ ao Este mecanismo tem como objetivo a imposic¸˜ ao de um formato global para a informac¸˜ ao, de forma a tornar esta coerente. Para atingir este objetivo, foi necess´ ario efetuar determinadas transformac¸ ˜ oes no texto a ser processado, nomeadamente: 4.2. Implementac¸˜ ao 50 • remover formatac¸ ˜ oes do texto (snake, kebab, pascal ou camel case); • separar palavras concatenadas; • remover m´ ultiplos caracteres especiais, como por exemplo, espac¸os, par´ agrafos ou tabs; • ignorar mai´ usculas e min´ usculas; • expandir siglas e acr´ onimos; • remover palavras vazias, como por exemplo artigos, preposic¸ ˜ oes e conjunc¸ ˜ oes; • remover sinais de pontuac¸˜ ao. O Algoritmo 1apresenta o processo de normalizac¸˜ ao aplicado ao texto, com o objetivo de remover ao m´ aximo o conte´ udo desnecess´ ario deste. Este ´ e utilizado para o processamento de texto que vai ser comparado com outro, que deve tamb´ em ser normalizado. Algoritmo 1Processamento de texto a ser comparado. Require: txt 6=None res1←remover formatac¸˜ ao snake, kebab, pascal ou camel case de txt res2←remover m´ ultiplos caracteres especiais de res1 res3←remover sinais de pontuac¸˜ ao de res2 res4←converter res3 para min´ usculas res5←expandir siglas e acr´ onimos presentes em res4 res6←separar palavras concatenadas de res5 res7←remover palavras vazias de res6 return res7 A Figura 4.6apresenta alguns exemplos de utilizac¸˜ ao do mecanismo de normalizac¸˜ ao. ´ E poss´ ıvel perceber que o mecanismo ´ e capaz de efetuar as transformac¸ ˜ oes descritas anteriormente. Desta forma, e tendo em conta que a informac¸ ˜ ao ´ e proveniente de fontes diferentes, o processamento permite uma posterior comparac¸˜ ao entre texto com o mesmo formato. Figura 4.6: Exemplo de utilizac¸˜ ao do mecanismo de normalizac¸˜ ao. 4.2. Implementac¸˜ ao 51 4.2.4Reconciliac¸˜ ao O mecanismo de reconciliac¸˜ ao ´ e um componente fundamental deste processo, visto que assegura que n˜ ao existem dados duplicados e que a informac¸ ˜ ao referente ` a mesma entidade ´ e combinada no mesmo objeto. O primeiro passo deste processo passa pela identificac¸˜ ao de objetos que correspondam ` a mesma entidade. Para isto ´ e necess´ ario verificar se um objeto j´ a existe antes de criar um novo. Este processo apresenta diferenc¸as entre itens de configurac¸˜ ao e relacionamentos. Para verificar se um CI j´ a existe s˜ ao inicialmente comparados alguns dos seus atributos, sendo que estes s˜ ao verificados de forma ordenada de acordo com a sua prioridade. O primeiro a ser comparado ´ e o atributo que guarda o valor do UUID. Se este valor existir e for igual nos dois objetos, ´ e conclu´ ıdo que estes correspondem ` a mesma entidade. Caso isto n˜ ao se verifique, ´ e utilizada a mesma metodologia para o atributo que representa o n´ umero de s´ erie. Caso esta verificac¸ ˜ ao tamb´ em n˜ ao corresponda, ´ e verificado o atributo que guarda o valor do enderec¸o MAC do objeto. Se nenhum destes valores estiver associado ao objeto que est´ a a ser verificado, a comparac¸˜ ao ´ e direcionada para os seus enderec¸os IP e para os seus atributos. Ap´ os efetuada a comparac¸ ˜ ao entre todos os atributos e os seus valores, ´ e conclu´ ıdo que os componentes correspondem ` a mesma entidade se mais de 80% dos seus atributos for semelhante. Para verificar se um relacionamento j´ a existe ´ e necess´ ario comparar este com todos os j´ a existentes. Inicialmente s˜ ao verificados os componentes fonte e alvo envolvidos no relacionamento. Se estes forem iguais, ´ e comparado o tipo do relacionamento. Ap´ os efetuada a comparac¸˜ ao entre todos os relacionamentos, ´ e conclu´ ıdo que os relacionamentos correspondem ` a mesma entidade se envolverem os mesmos componentes e o coeficiente de similaridade calculado entre os seus tipos for o m´ aximo valor encontrado superior a 0.90 (zero ponto noventa). Caso seja encontrado um CI ou um relacionamento que j´ a existe, ´ e necess´ ario seguir para o processo de reconciliac¸˜ ao. Assim como para a identificac¸˜ ao, tamb´ em a reconciliac¸˜ ao ´ e diferente entre itens de configurac¸˜ ao e relacionamentos. Para a reconciliac¸˜ ao de dois itens de configurac¸ ˜ ao ´ e inicialmente combinada a informac¸˜ ao dos atributos. Para os atributos que n˜ ao apresentem um valor no novo objeto, ´ e adquirida a informac¸˜ ao do objeto j´ a existente, sendo que os atributos do novo objeto s˜ ao mantidos, assumindo que a execuc¸˜ ao dos mecanismos de descoberta ´ e feita de forma crescente de acordo com a sua fiabilidade. Apenas para os atributos relativos ` a descric¸˜ ao e aos enderec¸os IP ´ e combinada a informac¸˜ ao dos dois componentes. Finalmente ´ e necess´ ario fazer a combinac¸ ˜ ao dos relacionamentos. Para todos os relacionamentos em que o objeto j´ a existente esteja envolvido, ´ e necess´ ario substituir pelo novo objeto. Na reconciliac¸˜ ao entre dois relacionamentos ´ e necess´ ario combinar os seus atributos. Para os atributos que n˜ ao apresentem um valor no novo relacionamento, ´ e adquirida a informac¸˜ ao do relacionamento j´ a existente, sendo que os atributos do novo relacionamento s˜ ao mantidos. Em ambos os processos de reconciliac¸˜ ao, ´ e utilizado o c´ alculo de similaridade, descrito na Secc¸˜ ao 4.2.9, para perceber se um atributo do novo objeto possui algum atributo correspondente no objeto j´ a existente. Este processo ´ e tamb´ em utilizado ao longo da descoberta, ou seja, antes de definir um atributo de um objeto, ´ e verificado se este j´ a existe. Al´ em disto, seguindo a mesma metodologia, antes de criar um tipo de CI ou de relacionamento ´ e tamb´ em verificado se este j´ a existe. 4.2. Implementac¸˜ ao 52 Figura 4.7: Exemplo de utilizac¸˜ ao do mecanismo de reconciliac¸˜ ao. Como ´ e poss´ ıvel observar na Figura 4.7, foram criados dois componentes com o mesmo n´ umero de s´ erie, um deles com um atributo relativo ao nome e outro ` a unidade de frequˆ encia do CPU, e o outro com um enderec¸o IP associado. Quando o segundo elemento ´ e guardado, como o valor do atributo referente ao n´ umero de s´ erie ´ e o mesmo do primeiro, ´ e combinada a informac¸˜ ao dos dois objetos num ´ unico. No final ´ e poss´ ıvel verificar a existˆ encia de um ´ unico objeto com atributos relativos ao nome, ` a unidade de frequˆ encia do CPU, ao n´ umero de s´ erie e ao enderec¸o IP.´ E tamb´ em poss´ ıvel observar que, quando ´ e adicionado outro atributo referente ` a unidade de frequˆ encia do CPU, como este j´ a existe, n˜ ao ´ e criado um novo, mas ´ e atualizado o valor desse atributo. 4.2.5Descoberta A descoberta da infraestrutura computacional implica a utilizac¸˜ ao de diferentes mecanismos que permitam a recolha de informac¸˜ ao variada. Tendo em conta que a descoberta tem como ponto inicial um conjunto de enderec¸os, durante este processo ´ e mantida informac¸˜ ao acerca dos enderec¸os descobertos, assim como das redes a que pertencem. O Algoritmo 2apresenta o processo de descoberta implementado, sendo que as v´ arias fases deste s˜ ao descritas de seguida. 4.2. Implementac¸˜ ao 53 Algoritmo 2Processo de descoberta if utilizac¸˜ ao de fonte externa then for objeto da fonte do guardar enderec¸o processar informac¸˜ ao do objeto end for end if if utilizador introduz enderec¸os then guardar enderec¸os end if basic discovery ←descoberta b´ asica nos enderec¸os definidos categories ←selec¸˜ ao das categorias a explorar detailed discovery ←descoberta detalhada com base nas categorias selecionadas Fonte externa O primeiro mecanismo, de uso opcional, que pode ser utilizado neste processo ´ e a utilizac¸˜ ao de uma fonte externa. O uso de um mecanismo deste g´ enero permite que o utilizador execute processos de descoberta com que j´ a est´ a familiarizado. Neste caso em espec´ ıfico, como exemplo, foi implementado um mecanismo capaz de processar os resultados obtidos atrav´ es da ferramenta Angry IP Scanner [79], j´ a abordada na Secc¸˜ ao 2.5.4. Como esta ferramenta permite a exportac¸˜ ao dos resultados em formato CSV, o mecanismo necessita apenas de ler este ficheiro e, tendo em conta a nomenclatura dada ` as colunas, criar os objetos e atributos existentes e guardar a informac¸˜ ao referente aos enderec¸os, sendo que estes v˜ ao ser posteriormente utilizados no processo de descoberta. ´ E poss´ ıvel observar na figura 4.8, que a informac¸˜ ao proveniente do ficheiro CSV apresentada na Tabela 4.1foi processada, e foram criados os CIs com esses dados. Tabela 4.1: Exemplo de um ficheiro CSV exportado da ferramenta Angry IP Scanner. IP 192.168.1.69 192.168.1.254 192.168.1.64 192.168.1.71 192.168.1.83 Ping 1ms 2ms 3ms 5ms 19 ms Hostname macbookprojoana.local [n/a] DESKTOP-DPANURS [n/a] [n/a] NetBIOS Info [n/a] [n/a] WORKGROUP\DESKTOP-DPANURS [48-4D-7E-A7-D6-5B] [n/a] [n/a] MAC Address C4:B3:01:C0:1A:D4CC:19:A8:62:4B:1G48:4D:7E:A7:D6:5B9E:DE:D0:7D:DB:E2 20:7C:8F:D8:26:9B MAC Vendor Apple PT Inovac¸ ˜ ao e Sistemas SA Dell [n/a] Quanta Microsystems 4.2. Implementac¸˜ ao 54 Figura 4.8: Exemplo de execuc¸˜ ao da descoberta recorrendo ` a ferramenta Angry IP Scanner. Descoberta b´ asica A descoberta b´ asica procura encontrar as m´ aquinas de acordo com um conjunto de enderec¸os, adquiridos atrav´ es da ferramenta externa e/ou definidos pelo utilizador. A primeira etapa passa pela an´ alise de pacotes LLDP. Tendo em conta que este protocolo, executado na camada de ligac¸ ˜ ao de dados, ´ e usado pelos dispositivos para comunicar informac¸˜ ao com outros na rede, s˜ ao filtrados os pacotes LLDP na m´ aquina que est´ a a executar a descoberta, como forma de descobrir outras m´ aquinas. Para que esta an´ alise seja realizada, ´ e necess´ ario que a m´ aquina que est´ a a executar o processo de descoberta possua o protocolo LLDP configurado para a recec¸˜ ao de pacotes. Desta forma, se existirem dispositivos na rede a enviar pacotes LLDP, estes v˜ ao ser captados. De seguida, para cada enderec¸o encontrado, s˜ ao executados mecanismos baseados nos protocolos ICMP eSNMP, abordados na Secc¸˜ ao 2.5.2, e na ferramenta Nmap, abordada na Secc¸˜ ao 2.5.4. Inicialmente, ´ e efetuado um pedido do tipo ping, para verificar se existe uma m´ aquina ativa nesse enderec¸o. Neste caso, ´ e necess´ ario que a m´ aquina consiga responder ao pedido, ou seja, esta pode estar ativa mas n˜ ao ser capaz de responder, por exemplo devido a configurac¸ ˜ oes da firewall. Em qualquer caso, se a m´ aquina n˜ ao responder, o enderec¸o n˜ ao ´ e mais considerado para explorac¸˜ ao, porque n˜ ao ´ e poss´ ıvel aceder a esta. Depois ´ e utilizada a ferramenta Nmap, que recolhe informac¸˜ ao acerca das m´ aquinas, nomeadamente: 4.2. Implementac¸˜ ao 55 • detec¸ ˜ ao do nome e tipo da m´ aquina; • identificac¸ ˜ ao dos enderec¸os IP eMAC associados a esta; • explorac¸ ˜ ao das portas abertas, fechadas, filtradas e n˜ ao-filtradas da m´ aquina; • detec¸ ˜ ao de servic¸os (protocolos utilizados, nome da aplicac¸˜ ao e vers˜ ao) a correr nas portas abertas; • detec¸ ˜ ao da fam´ ılia do sistema operativo associado ` a m´ aquina. Foi tamb´ em utilizado o protocolo SNMP de forma a obter mais informac¸˜ ao acerca das m´ aquinas anteriormente exploradas, nomeadamente os enderec¸os associados a estas e os seus tipos. Recorreu-se ` as tabelas de routing eARP das m´ aquinas para encontrar outras m´ aquinas na rede e para fazer o mapeamento entre enderec¸os IP eMAC. Aqui, ´ e tamb´ em descoberto o tipo de dispositivo que est´ a a ser explorado tendo em conta o valor armazenado em sysServices. O diagrama apresentado na Figura 4.9foi baseado no diagrama apresentado em [95], que descreve a forma de inferir o tipo do dispositivo tendo por base o valor guardado em sysServices. Impressora Host Switch L2 Switch L4 Router Switch L7 Switch L3 Suporta L2? Suporta L3? Suporta L3? Suporta L4? Suporta L7? Bridge MIB? Bridge MIB? Printer MIB? [não] [sim] [sim] [não] [não] [sim] [sim] [sim] [sim] [sim] [sim] [não] [não] [não] [não] [não] Figura 4.9: Algoritmo de descoberta do tipo de dispositivo. Para obter esta informac¸˜ ao ´ e necess´ ario que o utilizador fornec¸a a community string que permite o acesso do dispositivo via SNMP, sendo que esta vai ser armazenada no password vault. A informac¸˜ ao recolhida utilizando o protocolo SNMP est´ a dependente dos dados que as m´ aquinas possam fornecer. Assim como para o protocolo LLDP, tamb´ em neste caso ´ e 4.2. Implementac¸˜ ao 62 • dos valores poss´ ıveis para os atributos cujo valor est´ a pr´ e-definido. i-doit Para o caso espec´ ıfico do i-doit, foi definido um mecanismo de processamento que utiliza a sua API e a sua base de dados para obter informac¸˜ ao sobre o seu modelo de dados. No caso da API, o utilizador necessita de fornecer informac¸˜ ao acerca do servidor onde a CMDB est´ a a ser executada, do nome de utilizador, da palavra-passe e da chave associada ` aAPI. Para a base de dados, ´ e necess´ ario que o utilizador indique o servidor onde est´ a a ser executada, o nome da base de dados, o nome de utilizador e a palavra-passe. Para obter maior parte da informac¸˜ ao o mecanismo recorre ` aAPI, no entanto, necessita de aceder tamb´ em a informac¸˜ ao presente na base de dados no caso em que atributos referenciam outras instˆ ancias de outras tabelas. Para obter a informac¸˜ ao necess´ aria para capturar o modelo de dados, foram utilizados os seguintes m´ etodos da API: •idoit.constants: devolve os tipos de objetos e categorias, globais e espec´ ıficas, existentes na CMDB; •cmdb.category info: devolve os atributos de uma categoria, assim como os seus tipos de dados; •cmdb.dialog.read: devolve os valores poss´ ıveis para um determinado atributo de uma determinada categoria, cujos valores poss´ ıveis s˜ ao pr´ e-definidos na CMDB; •cmdb.object type categories.read: devolve as categorias associadas a um tipo de objeto. Na Listagem 4.6´ e apresentado o c´ odigo implementado para o envio de um pedido do tipo idoit.constants, sendo que as vari´ aveis identificadas pelos nomes “server”, “username”, “password” e “apikey” correspondem, respetivamente, ao enderec¸o do servidor onde a CMDB est´ a a ser executada, ao nome de utilizador, ` a palavra-passe e ` a chave associada ` a API, fornecidos pelo utilizador. Listagem 4.6: Exemplo de execuc¸˜ ao do m´ etodo idoit.constants ` aAPI do i-doit. import requests api_url = "http://" + server + "/i-doit/src/jsonrpc.php" headers = {} headers["Content-Type"] = "application/json" headers["X-RPC-Auth-Username"] = username headers["X-RPC-Auth-Password"] = password body = {} body["version"] = "2.0" body["method"] = "idoit.constants" body["params"] = {} 4.2. Implementac¸˜ ao 63 body["params"]["apikey"] = apikey body["params"]["language"] = "en" body["id"] = 1 try: s = requests.Session() constants_request = s.post(api_url, json=body, headers=headers) constants = constants_request.json() except requests.exceptions.RequestException: print("Unable to connect to the API. Please verify the connection information.") Apesar de atrav´ es da API ser poss´ ıvel obter os valores pr´ e-definidos de alguns atributos, isto n˜ ao ´ e poss´ ıvel para todos os casos. Isto porque existem atributos que fazem referˆ encia a instˆ ancias de outras tabelas. Desta forma, foi necess´ ario recorrer a interrogac¸ ˜ oes Structured Query Language (SQL) para obter este tipo de informac¸˜ ao. Sabendo que a nomenclatura das colunas das tabelas segue o mesmo esquema em toda a base de dados, ´ e poss´ ıvel inferir o nome das colunas das quais ´ e necess´ ario obter informac¸˜ ao, tendo apenas o nome da tabela. ´ E ent˜ ao apresentado na Listagem 4.7o c´ odigo implementado para recolher informac¸˜ ao da base de dados do i-doit, onde as vari´ aveis identificadas pelos nomes “server”, “db - name”, “username” e “password” correspondem, respetivamente, ao servidor onde est´ a a ser executada a base de dados, ao nome da base de dados, ao nome de utilizador e ` a palavra-passe. A vari´ avel identificada pelo nome “table” corresponde ao nome da tabela de onde vai ser recolhida a informac¸˜ ao, referente ao identificador e nome das instˆ ancias nela presentes. Listagem 4.7: C ´ odigo implementado para recolha de informa c¸ ˜ ao de tabelas da base de dados do i-doit. import mysql.connector from mysql.connector import errorcode try: connection = mysql.connector.connect(user=username, password=passwd, host=server, database= db_name) print(green + "\n>>> " + reset + "Successfully connected to the i-doit database.") except mysql.connector.Error as err: if err.errno == errorcode.ER_ACCESS_DENIED_ERROR: print(red + "\n>>> " + reset + "Something is wrong with your username or password.") elif err.errno == errorcode.ER_BAD_DB_ERROR: print(red + "\n>>> " + reset + "Database does not exist.") else: print(red + "\n>>> " + reset + str(err)) if connection != None: cursor = connection.cursor() 4.2. Implementac¸˜ ao 64 values = {} if table != None: name = str(table) + "__id" desc = str(table) + "__title" query = ("SELECT " + name + ", " + desc + " FROM " + db_name + "." + table + ";") cursor.execute(query) for tin cursor: name, value = t values[name] = value O resultado parcial do processamento do modelo de dados da CMDB i-doit pode ser consultado na Listagem A.1do Anexo A. Devido ` a enorme extens˜ ao do modelo, ´ e apenas poss´ ıvel apresentar uma parte do resultado do processamento do mesmo. iTop Para o caso espec´ ıfico do iTop, foi definido um mecanismo de processamento que recorre a interrogac¸ ˜ oes ` a sua base de dados para obter informac¸ ˜ ao acerca do seu modelo de dados. Tendo em conta que o SGBD utilizado pelo iTop ´ e o MySQL, o utilizador necessita de fornecer informac¸˜ ao acerca do servidor onde a base de dados est´ a a ser executada, do nome de utilizador, da palavra-passe e do nome da base de dados, sendo que ´ e tamb´ em necess´ ario que a m´ aquina a executar o processo possa aceder a esta. Para al´ em disto, o utilizador precisa tamb´ em de fornecer informac¸˜ ao acerca da API da CMDB, porque o posterior povoamento desta deve ser efetuado atrav´ es da API e n˜ ao da base de dados, para evitar poss´ ıveis erros e incoerˆ encias no povoamento. Para tal, o utilizador deve indicar o servidor onde a CMDB est´ a a ser executada, assim como, o nome de utilizador e palavrapasse para aceder a esta. Para obter a informac¸˜ ao necess´ aria para capturar o modelo de dados, foram utilizadas interrogac¸ ˜ oes SQL ` a base de dados de forma a: • obter as tabelas existentes na base de dados; • obter os atributos associados a cada tabela; • obter os tipos dos atributos associados a cada tabela. Depois de obter as tabelas existentes na base de dados e, sabendo que as tabelas identificadas com o prefixo “lnk” correspondem a relacionamentos, ´ e poss´ ıvel inferir que estas correspondem aos tipos de relacionamentos existentes no modelo de dados e que as restantes correspondem aos tipos de CIs. Al´ em disto, os relacionamentos presentes no iTop apresentam restric¸ ˜ oes ao n´ ıvel dos tipos de CIs envolvidos. Nas tabelas correspondentes aos relacionamentos ´ e poss´ ıvel verificar que existem dois atributos que possuem o sufixo “ - id”, que identificam os CIs envolvidos no relacionamento. O restante nome destes atributos corresponde ao tipo do CI, sendo poss´ ıvel inferir as restric¸ ˜ oes dos tipos de CIs envolvidos em cada relacionamento. 4.2. Implementac¸˜ ao 65 4.2.9C´ alculo de similaridade O coeficiente de similaridade mede a semelhanc¸a entre dois termos baseando-se na comparac¸˜ ao sint´ atica e semˆ antica entre estes. No Algoritmo 5´ e apresentado o processo implementado para o c´ alculo do coeficiente de similaridade entre dois termos. No final ´ e obtido um valor entre zero e um, sendo que quanto maior for esse valor, maior ´ e a semelhanc¸a entre os termos comparados. Este c´ alculo n˜ ao atribui um peso ` as medidas de similaridade sint´ atica e semˆ antica, sendo que apenas devolve o maior valor calculado entre estes. Assim, o valor do coeficiente de similaridade poderia apresentar valores diferentes no caso de serem atribu´ ıdos diferentes pesos a estas medidas. Algoritmo 5C´ alculo da similaridade entre dois termos Require: txt16=None ∧txt26=None Ensure: res ≥0∧res ≤1 syn ←calcular similaridade sint´ atica entre txt1 e txt2 if syn == 1then res ←syn return res else sem ←calcular similaridade semˆ antica entre txt1 e txt2 if sem >syn then res ←sem return res else res ←syn return res end if end if Similaridade sint´ atica O c´ alculo da similaridade sint´ atica ´ e especificado num coeficiente entre zero e um e mede a distˆ ancia, com base na ocorrˆ encia de caracteres, entre dois termos. Quanto maior este valor, mais semelhantes s˜ ao os termos a ser comparados. Inicialmente, para calcular este coeficiente, ´ e feito o tratamento do texto, ou seja, a sua normalizac¸˜ ao, como descrito na Secc¸˜ ao 4.2.3. Como a informac¸˜ ao ´ e recolhida de v´ arias fontes, possui formatos diferentes, sendo necess´ ario coloc´ a-la toda no mesmo formato de forma a poder compar´ a-la. Depois, ´ e necess´ ario converter a informac¸˜ ao num formato num´ erico, isto ´ e, calcular os vetores dos dados a serem comparados. De seguida, ´ e poss´ ıvel obter a semelhanc¸a entre os vetores calculados. A t´ ecnica utilizada para este efeito foi a similaridade por cosseno, visto ser uma t´ ecnica comummente utilizada [77]. Esta comparac¸˜ ao retorna um valor entre zero e um, sendo que o valor um representa que os termos que est˜ ao a ser comparados s˜ ao 4.2. Implementac¸˜ ao 66 exatamente iguais, e o valor zero implica que n˜ ao apresentam nenhuma semelhanc¸a entre si. Definic¸˜ ao 4.2.1“A similaridade por cosseno mede a semelhanc¸a entre dois vetores de um espac¸o interno de produto. ´ E medido pelo cosseno do ˆ angulo entre dois vetores e determina se esses vetores apontam aproximadamente na mesma direc¸˜ ao. ´ E usualmente utilizado para medir a similaridade entre documentos em an´ alise de texto [74].” O Algoritmo 6apresenta o processo implementado para o c´ alculo da similaridade sint´ atica entre dois termos. Algoritmo 6C´ alculo da similaridade sint´ atica Require: txt16=None ∧txt26=None Ensure: res ≥0∧res ≤1 t1←normalizar txt1 t2←normalizar txt2 vetores ←calcular vetores de t1 e t2 res ←calcular similaridade por cosseno de vetores return res Similaridade semˆ antica O c´ alculo da similaridade semˆ antica ´ e especificado num coeficiente entre zero e um e mede a distˆ ancia, ao n´ ıvel do significado, entre dois termos. Tal como para o c´ alculo da similaridade sint´ atica, tamb´ em aqui ´ e necess´ ario fazer o tratamento do texto, ou seja, a sua normalizac¸ ˜ ao, como descrito na Secc¸˜ ao 4.2.3. Para o c´ alculo da similaridade semˆ antica foi utilizada a medida proposta por Zhibiao Wu e Martha Palmer [112], implementada na biblioteca nltk [31], e apresentada na Definic¸˜ ao 4.2.2. Esta medida devolve um valor que representa o qu˜ ao semelhantes s˜ ao os sentidos das palavras comparadas. Poderia ser utilizada outra medida para o c´ alculo da similaridade semˆ antica, sendo que isso levaria ` a obtenc¸ ˜ ao resultados diferentes. Definic¸˜ ao 4.2.2“A semelhanc¸a conceitual entre C1e C2´ e: ConSim(C1, C2) = 2∗N3 N1+N2+2∗N3 C3´ e o conceito comum mais espec´ ıfico de C1e C2. N1´ eon´ umero de n´ os no caminho de C1a C3. N2´ e o n´ umero de n´ os no caminho de C2a C3. N3´ e o n´ umero de n´ os no caminho de C3at´ e a raiz [112].” O Algoritmo 7apresenta o processo implementado para o c´ alculo da similaridade semˆ antica entre dois termos. 4.2. Implementac¸˜ ao 67 Algoritmo 7C´ alculo da similaridade semˆ antica Require: txt16=None ∧txt26=None Ensure: res ≥0∧res ≤1 t1←normalizar txt1 t2←normalizar txt2 max ←0 signi f icados1←calcular sentidos poss´ ıveis de t1 signi f icados2←calcular sentidos poss´ ıveis de t2 for sig1em significados1do for sig2em significados2do sem ←calcular similaridade semˆ antica entre sig1 e sig2 if sem >max then max ←sem end if end for end for res ←max return res Na Figura 4.10 s˜ ao apresentados alguns exemplos do c´ alculo do coeficiente de similaridade entre termos. Figura 4.10: Exemplos de utilizac¸˜ ao do mecanismo que calcula a similaridade entre dois termos. 4.2.10 Mapeamento Neste passo devem ser geradas as regras de transformac¸ ˜ ao que descrevem o mapeamento do modelo da base de dados no modelo da CMDB a utilizar. Tendo em conta que o mapeamento dos modelos de forma manual ´ e um processo complexo, devido ` a grande dimens˜ ao e complexidade destes, foi necess´ ario desenvolver um mecanismo que executasse esta tarefa automaticamente. Este mecanismo recorre ao c´ alculo de similaridade descrito na Secc¸˜ ao 4.2.9e aos modelos de dados obtidos nas fases de processamento dos mesmos. Inicialmente s˜ ao calculados os coeficientes de similaridade entre todos os tipos de CIs e relacionamentos existentes nos dois modelos. Depois de obter todos os valores e de 4.2. Implementac¸˜ ao 68 os ordenar de forma decrescente, s˜ ao selecionadas as combinac¸ ˜ oes mais semelhantes, ou seja, as que apresentam um maior valor do coeficiente calculado. Para o caso em que s˜ ao encontradas combinac¸ ˜ oes com o mesmo valor de semelhanc¸a, foi dada a opc¸˜ ao de escolha ao utilizador. As selec¸ ˜ oes efetuadas implicam o mapeamento ´ unico entre os elementos dos dois modelos, ou seja, um elemento de um modelo, mapeia apenas no elemento do outro modelo cujo valor do coeficiente de similaridade ´ eom´ aximo calculado. A mesma metodologia ´ e depois aplicada aos atributos de cada tipo de componente e relacionamento. No final ´ e apresentado o mapeamento constru´ ıdo, assim como o valor de similaridade calculado. Nesta fase o utilizador deve definir um valor limite para selec¸˜ ao final das regras de transformac¸˜ ao. Para todos os coeficientes com valor inferior ao limite definido pelo utilizador, os mapeamentos v˜ ao ser descartados. Assim, um maior valor do limite garante a selec¸˜ ao de elementos mais semelhantes. Na Figura 4.11 ´ e poss´ ıvel observar o processo de mapeamento realizado entre o modelo da base de dados presente na Listagem 4.5e o modelo da CMDB presente na Listagem A.1 do Anexo A. Na Listagem 4.8´ e poss´ ıvel observar as regras de transformac¸ ˜ ao geradas neste mapeamento, considerando que o valor limite escolhido foi 0.80 (zero ponto oitenta). Figura 4.11: Exemplo de execuc¸˜ ao do mecanismo de mapeamento entre dois modelos. Listagem 4.8: Regras de transformac¸˜ ao entre modelos. 4.2. Implementac¸˜ ao 69 { "ci_types":{ "host":"C__OBJTYPE__HOST", "layer 3 network":"C__OBJTYPE__LAYER3_NET" }, "rel_types":{ "part of network":"C__RELATION_TYPE__NET_CONNECTIONS" }, "ci_attributes":{ "host":{ "status":"status", "mac_address":"mac", "operating system":"application" }, "layer 3 network":{ "title":"title" } }, "rel_attributes":{ "part of network":{ "title":"title" } } } 4.2.11 Povoamento da CMDB O objetivo desta etapa consiste em enviar ` aCMDB a informac¸˜ ao recolhida acerca da infraestrutura durante o processo de descoberta. Para isto ´ e necess´ ario aceder ` a base de dados para obter esta informac¸˜ ao e, recorrendo ` as regras de transformac¸˜ ao calculadas no processo de mapeamento, povoar a CMDB.´ E preciso tamb´ em ter em considerac¸ ˜ ao que este povoamento deve ser efetuado atrav´ es da API da CMDB para evitar erros e incoerˆ encias nos dados. Tendo em conta as diferenc¸as entre as v´ arias CMDBs identificadas na Secc¸˜ ao 2.4.5e o qu˜ ao distintas podem ser as APIs, foi desenvolvido um mecanismo espec´ ıfico para cada software. Desta forma, o custo de desenho da soluc¸˜ ao de povoamento depende apenas da implementac¸˜ ao do processo uma vez para cada tipo de software. Durante este processo ´ e relevante ter em atenc¸˜ ao que os CIs devem ser os primeiros a ser criados, visto que estes est˜ ao envolvidos nos relacionamentos. Ou seja, para criar um relacionamento ´ e necess´ ario que os CIs neste envolvidos sejam previamente criados na CMDB, assim como ´ e preciso ter informac¸˜ ao acerca do seu identificador na CMDB. Este processo ´ e apresentado no Algoritmo 8. 4.2. Implementac¸˜ ao 70 Algoritmo 8Povoamento da CMDB cis ids ←obter CIs existentes na base de dados for ci em cis ids do cis types[ci]←obter o tipo do ci cis attributes[ci]←obter os atributos do ci end for rels ids ←obter relacionamentos existentes na base de dados for rel em rels ids do rels types[rel]←obter o tipo do rel rels attributes[rel]←obter os atributos do rel sources[rel]←obter o CI fonte do rel targets[rel]←obter o CI alvo do rel end for for ci em cis types do ci id ←criar ci na CMDB end for for rel em rels types do rel id ←criar rel na CMDB end for i-doit No caso espec´ ıfico do i-doit, foi utilizado o m´ etodo cmdb.object.create que permite a criac¸˜ ao de componentes e relacionamentos atrav´ es da sua API. O povoamento ´ e iniciado com a criac¸ ˜ ao dos CIs existentes na base de dados. Para cada CI descoberto, ´ e verificado o seu tipo. Caso n˜ ao exista uma correspondˆ encia do seu tipo nas regras de mapeamento, este n˜ ao ´ e criado. Se existir, s˜ ao definidos os seus atributos. Para cada um destes ´ e verificado o seu tipo nas regras de transformac¸˜ ao. Se estes corresponderem a um atributo que permite apenas determinados valores pr´ e-definidos, ´ e necess´ ario fazer a correspondˆ encia entre o valor descoberto e os valores permitidos. Noutro caso, ´ e apenas necess´ ario converter o valor do atributo no tipo que ´ e utilizado pela CMDB. No entanto, pode acontecer de n˜ ao ser poss´ ıvel converter o valor do atributo para o tipo utilizado pela CMDB, n˜ ao sendo poss´ ıvel enviar esta informac¸˜ ao no pedido. Quando o CI ´ e finalmente definido, segue-se o envio de um pedido para a sua criac¸˜ ao. Para cada CI criado, ´ e guardado o seu identificador na CMDB para utilizar como referˆ encia nos relacionamentos. Depois de todos os CIs criados, segue-se a criac¸˜ ao dos relacionamentos. Tal como para os CIs, para cada relacionamento ´ e inicialmente verificada a existˆ encia do seu tipo nas regras de transformac¸˜ ao. Caso exista uma correspondˆ encia s˜ ao depois verificados os CIs envolvidos no relacionamento. ´ E necess´ ario que estes tenham sido previamente criados na CMDB. Novamente, para cada atributo ´ e verificado o seu tipo nas regras de transformac¸˜ ao. Se estes corresponderem a um atributo que permite apenas determinados valores pr´ e-definidos, ´ e necess´ ario fazer a correspondˆ encia entre o valor descoberto e os valores permitidos. Caso contr´ ario, ´ e apenas necess´ ario converter o valor do atributo no tipo que ´ e utilizado pela 4.2. Implementac¸˜ ao 71 CMDB, sendo que nos casos em que isto n˜ ao ´ e poss´ ıvel, a informac¸˜ ao n˜ ao ´ e enviada. Quando o relacionamento ´ e definido, segue-se o envio de um pedido para a sua criac¸ ˜ ao. De salientar que o m´ etodo cmdb.object.create n˜ ao permite que o valor do parˆ ametro referente ao nome seja enviado a vazio. Por isso, tanto na criac¸ ˜ ao dos CIs como dos relacionamentos, ´ e utilizado o nome do tipo do objeto como nome padr˜ ao. No entanto, caso o objeto apresente um atributo na BD associado ao nome, este valor substitui o definido anteriormente. Desta forma, ´ e garantido que o pedido ´ e enviado. Para al´ em disto, os atributos tˆ em de ser enviados de acordo com a categoria a que pertencem, sendo no momento da definic¸˜ ao do pedido necess´ ario associar os atributos ` as categorias a que pertencem. Na Listagem 4.9´ e apresentado um exemplo da estrutura, em JSON, de um pedido do tipo cmdb.object.create para a criac¸˜ ao de um objeto. Listagem 4.9: Exemplo da estrutura JSON de um m ´ etodo cmdb.object.create para a cria c¸ ˜ ao de um objeto no i-doit. { "version": "2.0", "method": "cmdb.object.create", "params": { "type": "C__OBJTYPE__HOST", "title": "Host example", "apikey": "xxx", "language": "en", "categories": { "C__CATG__CPU": [{ "frequency": "2.0", 'cores': 4 }], "C__CATG__NETWORK": [{ "serial": "abcde" }], "C__CATG__GLOBAL": [{ "description": "Description of host example.", 'status': 7 }] } }, 'id': 1 } Recorrendo ` as regras de transformac¸˜ ao presentes na Listagem 4.8, e aos dados presentes na Listagem 4.4, foi executado o povoamento da CMDB.´ E poss´ ıvel observar a execuc¸˜ ao deste na Figura 4.12 e o resultado na CMDB na Figura 4.13. 5.1. Caso de Teste 1 78 Na Tabela 5.3´ e poss´ ıvel observar os atributos do CI que representa a m´ aquina descrita na Tabela 5.1que foram recolhidos na fase de descoberta. Tabela 5.3: Informa c¸ ˜ ao recolhida sobre a m ´ aquina explorada na fase de descoberta no primeiro caso de teste. Atributo Valor title macbookprojoana hostname macbookprojoana.local status up uuid 0B793129-B10E-5C77-89DD-4529FEF05AD6 serial number C02S80K6G8WN description MacBook Pro MacBook ProMacBook Pro mac address c4:b3:01:c0:1a:d3 ipv4 192.168.1.73 ipv6 2001:8a0:f576:7000:1cac:32c1:d287:1804 ipv6 2001:8a0:f576:7000:19c8:36e6:6c25:e634 os family macOS os name Mac OS X os version 10.15.7 os macOS 10.15.7(19H15) kernel version Darwin 19.6.0 boot mode normal boot time since boot up 1:8:11:46 CPU Quad-Core Intel Core i7 CPU cores 4 CPU speed 2,2GHz CPU frequency 2,2 CPU frequency unit GHz physical memory 16 GB memory ram 16 physical memory unit GB GPU kHW IntelIrisProItem battery bq20z451 display Color LCD Tamb´ em na fase de descoberta foi poss´ ıvel encontrar relacionamentos entre os CIs. Na Tabela 5.4´ e poss´ ıvel observar alguns dos relacionamentos presentes na base de dados, sendo exibidos os nomes dos CIs envolvidos no relacionamento e o nome e tipo do relacionamento. 5.1.2Mapeamento Na fase de mapeamento foram analisados os modelos de dados da CMDB e da base de dados gerada no processo de descoberta, tendo sido produzidos potenciais mapeamentos entre estes modelos. Tendo em conta que neste caso foi utilizado o i-doit, ´ e poss´ ıvel consultar na Listagem A.1do Anexo Ao resultado parcial do processamento do seu modelo de dados. Considerando que o valor limite escolhido para a selec¸˜ ao das regras de transformac¸ ˜ ao foi 0.85 (zero ponto oitenta e cinco), ´ e poss´ ıvel observar na Tabela 5.5as regras de transformac¸˜ ao geradas. 5.1. Caso de Teste 1 79 Tabela 5.4: Alguns dos relacionamentos encontrados na fase de descoberta no primeiro caso de teste. Nome do CI Fonte Nome do CI Alvo Tipo do Relacionamento Nome do Relacionamento macOS 10.15.7 19H15 macbookprojoana running os macOS 10.15.7 19H15 running os macbookprojoana macbookprojoana macOS 10.15.7 19H15 installed os macbookprojoana installed os macOS 10.15.7 19H15 macbookprojoana Quad-Core Intel Core i7associated processor macbookprojoana associated processor Quad-Core Intel Core i7 ssh 22 is running on port ssh is running on port 22 APPLE SSD SM0256G macbookprojoana has storage APPLE SSD SM0256G is storage of macbookprojoana Visual Studio Code macbookprojoana has installed Visual Studio Code installed on macbookprojoana Color LCD macbookprojoana display of Color LCD display of macbookprojoana Built-in Microphone Apple Inc. has manufacturer Built-in Microphone has manufacturer Apple Inc. macbookprojoana PT located macbookprojoana located PT PT macbookprojoana location of PT location of macbookprojoana Tabela 5.5: Regras de transformac¸˜ ao geradas no primeiro caso de teste. CMDB Base de dados Coeficiente de similaridadeNome Descric¸ ˜ ao Nome Descric¸ ˜ ao CIs C OBJTYPE APPLICATION Application Application application 1 C OBJTYPE HOST Host Host host 1 C OBJTYPE OPERATING SYSTEM Operating System Operating System operating system 1 C OBJTYPE MONITOR Monitor Display display 0.947368 C OBJTYPE WORKSTATION Workplace Location location 0.933333 C OBJTYPE AMPLIFIER Amplifier CPU central processing unit 0.888889 C OBJTYPE CONVERTER Converter Charger charger 0.875 Atributos dos CIs C OBJTYPE APPLICATION title Title title title 1 description Description description description 1 C OBJTYPE HOST frequency CPU frequency CPU frequency central processing unit frequency 1 cores CPU cores CPU cores central processing unit cores 1 title Title title title 1 description Description description description 1 status Condition status status 1 frequency unit CPU frequency unit CPU frequency unit central processing unit frequency unit 1 serial Serial number serial number serial number 1 unit Memory unit physical memory unit physical memory unit 0.928369 memory Memory memory ram memory random access memory 0.893177 plug type Plug battery battery 0.888889 speed unit Speed unit CPU speed central processing unit speed 0.877123 device On device display display 0.875 mac MAC mac address media access control address 0.866025 C OBJTYPE OPERATING SYSTEM assigned version Version number version number version number 1 title Title title title 1 C OBJTYPE MONITOR resolution Resolution resolution resolution 1 depth Depth depth depth 1 title Title title title 1 connection type Connection type connection type connection type 1 date Date year year 0.857143 size Display display type display type 0.851235 C OBJTYPE WORKSTATION latitude Latitude latitude latitude 1 longitude Longitude longitude longitude 1 title Title title title 1 parent Location region region 0.888889 C OBJTYPE AMPLIFIER title Title title title 1 changes Changes Speed speed 0.875 C OBJTYPE CONVERTER assigned connector Connected to connected connected 1 image File charging charging 1 Relacionamentos C RELATION TYPE NETWORK PORT Ports port from port 1 C RELATION TYPE LOCATION Location location of location 1 C RELATION TYPE OPERATION SYSTEM Operating system running os running operating system 0.942343 Atributos dos Relacionamentos C RELATION TYPE NETWORK PORT title Title title title 1 C RELATION TYPE LOCATION C RELATION TYPE OPERATION SYSTEM 5.1.3Povoamento Tendo em conta os itens descobertos e as regras de transformac¸˜ ao geradas, foi poss´ ıvel comprovar a criac¸˜ ao dos objetos que corresponderam a esses requisitos. ´ E poss´ ıvel observar 5.1. Caso de Teste 1 80 na Tabela 5.6, as instˆ ancias criadas na CMDB e os seus tipos associados. No caso dos relacionamentos, s´ o s˜ ao criados se os CIs neles envolvidos tenham tamb´ em sido criados. Desta forma, mesmo que exista um mapeamento para um tipo de relacionamento, este n˜ ao vai ser criado na CMDB se n˜ ao houver um mapeamento poss´ ıvel para os tipos de CIs envolvidos neste. Para al´ em disto, quando n˜ ao ´ e poss´ ıvel converter os tipos de dados dos atributos para os utilizados pela CMDB, tamb´ em n˜ ao ´ e poss´ ıvel enviar essa informac¸˜ ao. Por exemplo, no caso do CI que corresponde ao sistema operativo macOS 10.15.7, na base de dados este possui o atributo ”version number“ com o valor ”10.15.7“. O mapeamento deste atributo ´ e feito com o atributo ”assigned version“ na CMDB, que corresponde a um valor inteiro. Desta forma, esta informac¸˜ ao n˜ ao ´ e enviada no pedido ` aAPI visto n˜ ao ser poss´ ıvel converter este valor para um valor inteiro. Tabela 5.6: Elementos criados na CMDB no primeiro caso de teste. Tipo na CMDB Tipo na Base de Dados Nome dos objetos CIs C OBJTYPE APPLICATION Application Firefox Postman Slack zoom Adobe Acrobat Reader DC iMovie PyCharm Visual Studio Code Spotify Google Chrome FileZilla MRT C OBJTYPE HOST Host macbookprojoana C OBJTYPE OPERATING SYSTEM Operating System macOS 10.15.7 19H15 C OBJTYPE MONITOR Display Color LCD C OBJTYPE WORKSTATION Location PT C OBJTYPE AMPLIFIER CPU Quad-Core Intel Core i7 C OBJTYPE CONVERTER Charger C OBJTYPE CONVERTER Relacionamentos C RELATION TYPE OPERATION SYSTEM running operating system macOS 10.15.7 19H15 running os macbookprojoana C RELATION TYPE LOCATION location of PT location of macbookprojoana Na Listagem 5.1´ e poss´ ıvel observar a informac¸˜ ao em JSON do pedido gerado para a criac¸˜ ao do CI correspondente ` a m´ aquina descrita na Tabela 5.1. Este foi gerado tendo por base a informac¸˜ ao acerca do CI presente na base de dados, que pode ser consultada na Tabela 5.3, e as regras de transformac¸˜ ao presentes na Tabela 5.5. Na Figura 5.1´ e poss´ ıvel verificar a criac¸˜ ao deste CI na CMDB. Listagem 5.1: Informa c¸ ˜ ao JSON do m ´ etodo cmdb.object.create gerado para a cria c¸ ˜ ao do CI correspondente ` a m´ aquina descrita na Tabela 5.1. { 'version':'2.0', 'method':'cmdb.object.create', 'params': { 'apikey':'cmdb-auto', 5.1. Caso de Teste 1 81 'language':'en', 'type':'C__OBJTYPE__HOST', 'title':'C__OBJTYPE__HOST', 'categories': { 'C__CATG__CONTROLLER_FC_PORT': [{ 'speed_unit':1 }], 'C__CATG__CPU': [{ 'frequency':2.0, 'cores':4, 'frequency_unit':3 }], 'C__CATG__GRAPHIC': [{ 'memory':16.0 }], 'C__CATG__NETWORK_PORT': [{}], 'C__CATG__DRIVE': [{}], 'C__CATG__MEMORY': [{ 'unit':3 }], 'C__CATG__NETWORK': [{ 'serial':'C02S80K6G8WN' }], 'C__CATG__GLOBAL': [{ 'title':'macbookprojoana', 'description':'MacBook Pro MacBook ProMacBook Pro', 'status':7 }], 'C__CATG__NETWORK_LOG_PORT': [{ 'mac':'c4:b3:01:c0:1a:d3' }] } }, 'id':1 } 5.1. Caso de Teste 1 82 Figura 5.1: Objeto referente ` a m ´ aquina descrita na Tabela 5.1criado na CMDB no primeiro caso de teste. Na Figura 5.2´ e tamb´ em poss´ ıvel observar os restantes CIs criados na CMDB. Figura 5.2: Objetos, e seus atributos, criados na CMDB no primeiro caso de teste. Finalmente, na Figura 5.3, s˜ ao apresentados os relacionamentos presentes na CMDB ap´ os o povoamento. ´ E poss´ ıvel verificar a criac¸˜ ao dos relacionamentos e a associac¸˜ ao destes com os CIs envolvidos nos mesmos. 5.2. Caso de Teste 2 83 Figura 5.3: Relacionamentos criados na CMDB no primeiro caso de teste. 5.2 caso de teste 2 No segundo caso de teste, a ferramenta vai ser novamente executada de forma a recolher informac¸˜ ao de apenas uma m´ aquina f´ ısica. As caracter´ ısticas da m´ aquina a ser explorada podem ser consultadas na Tabela 5.7. A ferramenta ´ e executada na m´ aquina descrita na Tabela 5.1, mas a base de dados e a CMDB utilizada, que neste caso ser´ a o iTop, s˜ ao executadas na m´ aquina a ser explorada. 5.2. Caso de Teste 2 84 Tabela 5.7: Caracter´ ısticas da m´ aquina para o segundo caso de teste. M´ aquina Dell OptiPlex 7010 Sistema Operativo Ubuntu 18.04.5LTS Enderec¸o IP 192.168.1.88 RAM 8GB CPU 2,9GHz Intel Core i5-3470S GraphDB 9.3.1 i-doit 1.14 Open iTop 2.7.3-6624 Virtualbox 5.2.42 Ubuntur137960 Vagrant 2.2.14 SNMP 5.7.3 5.2.1Descoberta A descoberta teve por base o enderec¸o IP referente ` a m´ aquina descrita na Tabela 5.7. Na descoberta b´ asica, foi poss´ ıvel obter informac¸˜ ao da m´ aquina atrav´ es da ferramenta Nmap e do protocolo SNMP. Na descoberta detalhada foram selecionadas as categorias referentes ao sistema operativo, processamento, armazenamento e software, sendo que as credenciais da m´ aquina foram necess´ arias para a obtenc¸˜ ao deste tipo de informac¸˜ ao. Devido ` a grande extens˜ ao dos dados recolhidos, v˜ ao ser apenas apresentados resultados parciais. Tendo em conta a m´ aquina explorada e as categorias selecionadas, ´ e poss´ ıvel observar na Tabela 5.8os CIs que seria de esperar que fossem descobertos, e aqueles que foram efetivamente criados. Aqui s˜ ao apenas apresentados os nomes associados ` as instˆ ancias armazenadas na base de dados, sendo que os seus atributos n˜ ao est˜ ao representados. Tamb´ em para o tipo de cada CI ´ e apenas apresentado o seu nome. Na Tabela C.2 do Anexo C´ e poss´ ıvel observar alguns atributos de alguns dos CIs descobertos. Tabela 5.8: Alguns dos CIs encontrados na fase de descoberta do segundo caso de teste. Esperado Categoria Encontrado Nome do tipo de CI Nome dos CIs M´ aquina descrita na Tabela 5.7— Host ubuntu-pc Sistema Operativo Ubuntu Sistema Operativo Operating System Ubuntu 18.04.5LTS CPU Processamento CPU IntelR CoreTM i5-3470S CPU 2.90GHz Discos Armazenamento SSD sda4 Aplicac¸ ˜ oes (apenas as que est˜ ao a utilizar mais mem´ oria virtual) Software Application graphdb-free gnome-shell firefox snapd evolution-data-server Tamb´ em na fase de descoberta foi poss´ ıvel encontrar relacionamentos entre os CIs. Na Tabela 5.9´ e poss´ ıvel observar alguns dos relacionamentos encontrados nesta fase, sendo exibido o nome, o nome do tipo e o nome dos CIs envolvidos no relacionamento. 5.2. Caso de Teste 2 85 Tabela 5.9: Alguns dos relacionamentos encontrados na fase de descoberta do segundo caso de teste. Nome do CI Fonte Nome do CI Alvo Tipo do Relacionamento Nome do Relacionamento ubuntu-pc IntelR CoreTM i5-3470S CPU 2.90GHz associated processor ubuntu-pc associated processor IntelR CoreTM i5-3470S CPU 2.90GHz graphdb-free cumulus linux has installed ubuntu-pc has installed graphdb-free ubuntu-pc Dell has vendor has vendor Dell ubuntu-pc Ubuntu 18.04.5LTS installed os ubuntu-pc installed os Ubuntu 18.04.5LTS Ubuntu 18.04.5LTS ubuntu-pc running os Ubuntu 18.04.5LTS running os ubuntu-pc mysql 3306 is running on port mysql is running on port 3306 5.2.2Mapeamento Na fase de mapeamento foram analisados os modelos de dados da CMDB, que neste caso foi o iTop, e da base de dados gerada no processo de descoberta, tendo sido produzidos os potenciais mapeamentos entre estes modelos. Considerando que o valor limite escolhido para a selec¸˜ ao das regras de transformac¸˜ ao foi 0.80 (zero ponto oitenta), ´ e poss´ ıvel observar na Tabela 5.10 as regras de transformac¸˜ ao geradas. ´ E relevante referir que, no caso dos atributos, podem existir, para um mesmo atributo, mapeamentos diferentes entre diferentes tipos de CIs visto que, diferentes tipos de CIs podem apresentar o mesmo atributo. Tabela 5.10: Regras de transformac¸˜ ao geradas no segundo caso de teste. CMDB Base de Dados Coeficiente de SimilaridadeNome Descric¸˜ ao Nome Descric¸˜ ao CIs server server Host host 1 software software Operating System operating system 0.941176 peripheral peripheral CPU central processing unit 0.888889 applicationsolution application solution Application application 0.871378 Atributos dos CIs server cpu cpu CPU central processing unit 1 id id Machine ID machine id 0.880476 software id id ID id 1 vendor vendor vendor vendor 1 type type description description 0.9 name name title title 0.923077 version version version number version number 0.819853 peripheral id id Vendor ID vendor id 0.876197 applicationsolution status status title title 0.833333 5.2.3Povoamento Tendo em conta os itens descobertos e as regras de transformac¸˜ ao geradas, ´ e poss´ ıvel verificar na Figura 5.4a criac¸˜ ao dos CIs que corresponderam a esses requisitos. Na Listagem 5.2´ e poss´ ıvel observar a informac¸˜ ao em JSON do pedido gerado para a criac¸˜ ao do CI correspondente ao sistema operativo Ubuntu da m´ aquina descrita na Tabela 5.1. Este foi gerado tendo por base a informac¸˜ ao armazenada na base de dados, e as regras de transformac¸˜ ao presentes na Tabela 5.5. 5.3. Caso de Teste 3 86 Figura 5.4:CIs criados no iTop no segundo caso de teste. Listagem 5.2: Informa c¸˜ ao JSON da opera c¸˜ ao core/create gerado para a cria c¸˜ ao do CI correspondente ao sistema operativo da m´ aquina descrita na Tabela 5.7. { 'operation':'core/create', 'comment':'Synchronization from CMDB automatic creation...', 'user':'itop', 'password':'itop-WebServices1', 'class':'Software', 'fields': { 'vendor':'Ubuntu', 'version':'18.04', 'name':'Ubuntu 18.04.5 LTS', 'type':'Middleware' } } 5.3 caso de teste 3 No terceiro caso de teste, a ferramenta vai ser executada de forma a recolher informac¸˜ ao de uma infraestrutura computacional. Esta ´ e constitu´ ıda por 7m´ aquinas virtuais, tendo sido utilizado VirtualBox [52] e Vagrant [51] para a virtualizac¸˜ ao e administrac¸˜ ao destas. Estas m´ aquinas s˜ ao executadas na m´ aquina f´ ısica apresentada na Tabela 5.7. As caracter´ ısticas das m´ aquinas virtuais que comp˜ oem a infraestrutura podem ser consultadas na Tabela 5.11. A ferramenta de criac¸˜ ao autom´ atica de CMDB vai ser executada na m´ aquina identificada pelo nome ”ubuntu“. A base de dados e a CMDB utilizada - i-doit 1.14 Open - s˜ ao executadas na m´ aquina descrita na Tabela 5.7. 5.3. Caso de Teste 3 87 Tabela 5.11: Caracter ´ ısticas das m ´ aquinas que comp ˜ oe a infraestrutura computacional para o terceiro caso de teste. M´ aquina Vagrant Box Sistema Operativo Enderec¸o IP LLDP SNMP SSH Python Nmap Wireshark router CumulusCommunity/VX-3.0Cumulus Linux 3.3.0 192.168.10.10 0.7.16-430-g9ed8a25 5.7.3OpenSSH 6.7p1Debian-5+deb8u3, OpenSSL 1.0.1t — — — sw1CumulusCommunity/VX-3.0Cumulus Linux 3.3.0 192.168.10.20 0.7.16-430-g9ed8a25 5.7.3OpenSSH 6.7p1Debian-5+deb8u3, OpenSSL 1.0.1t — — — sw2CumulusCommunity/VX-3.0Cumulus Linux 3.3.0 192.168.10.30 0.7.16-430-g9ed8a25 5.7.3OpenSSH 6.7p1Debian-5+deb8u3, OpenSSL 1.0.1t — — — ubuntu generic/ubuntu1804 Ubuntu 18.04.5LTS 192.168.10.22 0.9.9 5.7.3OpenSSH 7.6p1Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 3.9.1 7.60 2.6.10 windows gusztavvargadr/windows-10 Microsoft Windows 10 Enterprise Evaluation 10.0.19042 192.168.10.21 N˜ ao instalado N˜ ao instalado — — — — dbs ubuntu/xenial64 Ubuntu 16.04.7LTS 192.168.10.31 N˜ ao instalado 5.7.3OpenSSH 7.2p2Ubuntu-4ubuntu2.10, OpenSSL 1.0.2g — — — wbs ubuntu/xenial64 Ubuntu 16.04.7LTS 192.168.10.32 N˜ ao instalado 5.7.3OpenSSH 7.2p2Ubuntu-4ubuntu2.10 OpenSSL 1.0.2g — — — 5.3.1Descoberta A descoberta teve por base a informac¸˜ ao exportada da ferramenta Angry IP Scanner, que cont´ em informac¸˜ ao acerca de trˆ es das m´ aquinas que comp˜ oem a infraestrutura. Os dados exportados podem ser consultados na Tabela 5.12. Tabela 5.12: Ficheiro CSV exportado da ferramenta Angry IP Scanner para o terceiro caso de teste. IP Ping MAC Address Hostname Ports NetBIOS Info MAC Vendor 192.168.10.10 0 ms 08:00:27:12:F6:B5[n/a] [n/a] [n/a] PCS Systemtechnik 192.168.10.20 0 ms 08:00:27:C7:45:8C [n/a] [n/a] [n/a] PCS Systemtechnik 192.168.10.30 0 ms 08:00:27:9C:71:2B [n/a] [n/a] [n/a] PCS Systemtechnik Na descoberta b´ asica, foi poss´ ıvel recolher informac¸˜ ao atrav´ es dos protocolos LLDP e SNMP e da ferramenta Nmap, devido ao facto de estes protocolos estarem configurados nas m´ aquinas que comp˜ oem a infraestrutura, e a ferramenta estar instalada na m´ aquina a executar a descoberta. Desta forma, foi poss´ ıvel aceder ` as tabelas de roteamento e tabelas ARP dos dispositivos, o que permitiu, tendo apenas conhecimento de trˆ es das m´ aquinas, descobrir as restantes. Na descoberta detalhada foram selecionadas as categorias referentes ao sistema operativo, processamento, armazenamento, software e servic¸os, sendo que as credenciais das m´ aquinas foram necess´ arias para a obtenc¸˜ ao deste tipo de informac¸˜ ao. Neste caso em espec´ ıfico, ´ e poss´ ıvel verificar que apesar de pelo menos duas m´ aquinas apresentarem o mesmo sistema operativo na mesma vers˜ ao - Cumulus Linux 3.3.0, por exemplo - foi apenas criada uma instˆ ancia deste sistema operativo na base de dados, provando as capacidades do mecanismo de reconciliac¸˜ ao. ´ E tamb´ em relevante referir que foram criados dois CIs referentes ao CPU da m´ aquina descrita na Tabela 5.7. Isto aconteceu porque as configurac¸ ˜ oes do CPU nas m´ aquinas virtuais s˜ ao diferentes. Devido ` a grande extens˜ ao dos dados recolhidos, v˜ ao ser apenas apresentados resultados parciais, sendo poss´ ıvel observar na Tabela 5.13 os componentes que seria de esperar que fossem descobertos, e aqueles que foram efetivamente criados. Aqui s˜ ao apenas apresentados os nomes associados ` as instˆ ancias armazenadas na base de dados, sendo que 5.3. Caso de Teste 3 94 a mais correta - o valor ”MHz“ da base de dados foi mapeado com o valor ”2“ na CMDB, que efetivamente corresponde ` a unidade ”MHz“. Listagem 5.4: Resultado da execu c¸ ˜ ao do m ´ etodo cmdb.dialog.read para o atributo ”frequency unit“ do i-doit. "result": [ { "id":"1", "const":"C__FREQUENCY_UNIT__KHZ", "title":"KHz" }, { "id":"2", "const":"C__FREQUENCY_UNIT__MHZ", "title":"MHz" }, { "id":"3", "const":"C__FREQUENCY_UNIT__GHZ", "title":"GHz" }, { "id":"4", "const":"C__FREQUENCY_UNIT__THZ", "title":"THz" } ] Figura 5.6: Objeto, e atributos correspondentes, referente ` a m ´ aquina virtual descoberta, criado na CMDB no terceiro caso de teste. 5.3. Caso de Teste 3 95 Na Figura 5.7´ e tamb´ em poss´ ıvel observar os restantes CIs, e seus atributos, criados na CMDB. Figura 5.7: Objetos, e seus atributos, criados na CMDB no terceiro caso de teste. Finalmente, na Figura 5.8, s˜ ao apresentados os relacionamentos presentes na CMDB ap´ os o povoamento. Os relacionamentos do tipo ”Host address“ foram gerados automaticamente no momento da criac¸˜ ao das m´ aquinas virtuais, porque estas foram associadas a um enderec¸o IPv4. 5.4. Caso de Teste 4 96 Figura 5.8: Relacionamentos criados na CMDB no terceiro caso de teste. 5.4 caso de teste 4 No quarto caso de teste foi avaliado o mecanismo de mapeamento implementado. Este, descrito na Secc¸˜ ao 4.2.10, evita a repetic¸˜ ao entre conceitos mapeados, ou seja, um elemento de um modelo, mapeia apenas num elemento do outro modelo cujo valor do coeficiente de similaridade ´ e o m´ aximo calculado. Desta forma, n˜ ao h´ a dois elementos de um modelo a mapear no mesmo elemento do outro modelo. Neste caso de teste, foi executado o mapeamento entre modelos que permite a repetic¸˜ ao entre elementos mapeados selecionando apenas o maior valor do coeficiente de similaridade calculado, de forma a ser poss´ ıvel comparar com o mecanismo implementado. Esta comparac¸˜ ao foi efetuada quer para o mapeamento da base de dados com o i-doit, quer com o iTop. Os testes efetuados tiveram em considerac¸˜ ao a base de dados obtida da combinac¸˜ ao dos resultados das descobertas dos casos de teste 1,2e3. O primeiro caso apresentado ´ e referente ao mapeamento com o i-doit. A Tabela 5.18 apresentada o n´ umero de mapeamentos, corretos e errados, obtidos ao executar os dois mecanismos de mapeamento para diferentes valores de limite. ´ E poss´ ıvel observar que ` a medida que o valor limite aumenta, aumenta tamb´ em a percentagem de mapeamentos corretos. Na Figura 5.9´ e poss´ ıvel observar que para valores limite superiores, a percentagem de mapeamentos corretos aumenta. Isto acontece porque ao limitar a repetic¸˜ ao, o 5.4. Caso de Teste 4 97 Tabela 5.18: N ´ umero de mapeamentos, corretos e errados, selecionados para o i-doit considerando diferentes valores limite. Com repetic¸˜ ao Sem repetic¸˜ ao Valor limite 0.5 0.7 0.8 0.9 1 0.5 0.7 0.8 0.9 1 CIs Corretos 6 6 6 6 5 6 6 6 6 5 Errados 23 13 6 2 1 22 12 6 2 1 Percentagem 20,68965517 31,57894737 50 75 83,3333333 21,4285714 33,3333333 50 75 83,3333333 Relacionamentos Corretos 8 7 5 4 2 3 3 3 3 2 Errados 27 16 5 1 0 26 9 5 1 0 Percentagem 22,85714286 30,43478261 50 80 100 10,3448276 25 37,5 75 100 Total Corretos 14 13 11 10 7 9 9 9 9 7 Errados 50 29 11 3 1 48 21 11 3 1 Percentagem 21,875 30,95238095 50 76,9230769 87,5 15,7894737 30 45 75 87,5 Figura 5.9: Compara c¸˜ ao de mapeamentos corretos entre os dois mecanismos de mapeamento para diferentes valores limite no caso do i-doit. valor geral do coeficiente de similaridade selecionado vai diminuir, porque n˜ ao vai ser o m´ aximo calculado entre todos os mapeamentos nos casos em que o elemento j´ a tenha sido mapeado. O segundo caso apresentado ´ e referente ao mapeamento com o iTop. A Tabela 5.19 apresentada o n´ umero de mapeamentos, corretos e errados, obtidos ao executar os dois mecanismos de mapeamento para diferentes valores limite. ´ E poss´ ıvel observar que ` a medida que o valor limite aumenta, aumenta tamb´ em a percentagem de mapeamentos corretos. Na Figura 5.10 ´ e poss´ ıvel observar que, no caso do iTop, a percentagem de mapeamentos corretos para o mecanismo que evita repetic¸ ˜ oes, ´ e sempre superior. Isto acontece porque ao limitar a repetic¸˜ ao, o valor dos coeficientes de similaridade selecionados vai diminuir, porque n˜ ao v˜ ao corresponder ao valor m´ aximo calculado nos mapeamentos em que os elementos tenham sido j´ a mapeados. 5.5. Sum´ ario 98 Tabela 5.19: N ´ umero de mapeamentos, corretos e errados, selecionados para o iTop considerando diferentes valores limite.. Com repetic¸ ˜ ao Sem repetic¸ ˜ ao Valor limite 0.5 0.7 0.8 0.9 1 0.5 0.7 0.8 0.9 1 CIs Corretos 5 4 3 3 3 6 5 4 3 3 Errados 21 14 8 2 0 20 13 6 2 0 Percentagem 19,23076923 22,22222222 27,27272727 60 100 23,07692308 27,7777778 40 60 100 Relacionamentos Corretos 3 1 0 0 0 3 1 0 0 0 Errados 22 5 0 0 0 12 5 0 0 0 Percentagem 12 16,66666667 0 0 0 20 16,6666667 0 0 0 Total Corretos 8 5 3 3 3 9 6 4 3 3 Errados 43 19 8 2 0 32 18 6 2 0 Percentagem 15,68627451 20,83333333 27,27272727 60 100 21,95121951 25 40 60 100 Figura 5.10: Comparac¸ ˜ ao de mapeamentos corretos entre os dois mecanismos de mapeamento para diferentes valores limite no caso do iTop. ´ E ent˜ ao poss´ ıvel perceber, que, tendo em conta os valores de limite selecionados nos trˆ es casos de teste apresentados anteriormente, o mecanismo que evita repetic¸ ˜ oes permite a selec¸˜ ao de um maior n´ umero de mapeamentos corretos. 5.5 sum ´ ario Depois de executados os testes, ´ e poss´ ıvel responder ` as quest˜ oes levantadas no in´ ıcio deste Cap´ ıtulo. O processo de descoberta ´ e capaz de recolher a informac¸ ˜ ao requerida pelo utilizador? Observando os resultados dos testes, ´ e poss´ ıvel afirmar que a ferramenta ´ e capaz de recolher informac¸˜ ao de acordo com o solicitado, sendo que os dados que se esperam recolher s˜ ao efetivamente descobertos. No entanto, ´ e poss´ ıvel melhorar os mecanismos de descoberta implementados, de forma a que estes recolham informac¸ ˜ ao mais detalhada. Para al´ em disto, tendo em conta que a ferramenta permite que sejam integrados quaisquer outros mecanismos de descoberta, ´ e tamb´ em poss´ ıvel desenvolver outros mecanismos e utiliz´ a-los de forma a descobrir outros tipos de informac¸˜ ao. Adicionalmente, seria tamb´ em 5.5. Sum´ ario 99 relevante inferir mais informac¸˜ ao tendo em conta os dados descobertos. Os resultados do mapeamento retratam a correspondˆ encia entre os elementos mais semelhantes dos dois modelos? O mapeamento entre os modelos est´ a sempre dependente do valor limite escolhido, ou seja, se o valor escolhido, que pode variar entre zero e um, for um, ´ e verificado que os mapeamentos est˜ ao efetivamente corretos. Nos testes realizados foram escolhidos valores de limite que variaram entre 0.8(zero ponto oitenta) e 0.86 (zero ponto oitenta e seis), e ´ e poss´ ıvel constatar que a maior parte dos mapeamentos representam efetivamente a correspondˆ encia entre os elementos mais semelhantes dos dois modelos. No entanto, ´ e poss´ ıvel observar tamb´ em alguns mapeamentos menos corretos. ´ E disso exemplo, no segundo caso de teste, o mapeamento entre o tipo de CI que representa um perif´ erico com um tipo que representa um CPU. Desta forma, ´ e poss´ ıvel concluir que o mecanismo de mapeamento pode ser melhorado, de forma a fornecer regras de transformac¸˜ ao mais exatas. Isto pode ser conseguido com a utilizac¸ ˜ ao de, por exemplo, uma comparac¸˜ ao entre termos mais espec´ ıfica e baseada apenas no dom´ ınio da linguagem a ser utilizado. Outro aspeto que pode melhorar o mapeamento entre os modelos, passa pelo aperfeic¸oamento da terminologia utilizada no momento da descoberta. Para al´ em disto, este mecanismo considerou apenas o mapeamento ´ unico de elementos, isto ´ e, foi apenas permitido que um elemento de um modelo fosse mapeado com apenas um elemento do outro modelo. Desta forma, n˜ ao foi tido em considerac¸˜ ao que dois ou mais elementos de um modelo podem mapear num mesmo elemento do outro modelo. Estes casos podem acontecer quando existem modelos de dados que possuem elementos mais abrangentes, e ´ e sem d´ uvida um caso que pode ajudar na gerac¸˜ ao de regras de transformac¸˜ ao mais corretas. Apesar de o quarto caso de teste apresentar melhores resultados para o mecanismo que evita a repetic¸˜ ao, ´ e tamb´ em poss´ ıvel observar que o mecanismo que permite a repetic¸˜ ao, apesar de apresentar mais mapeamentos errados, tamb´ em apresenta mais mapeamentos corretos. A informac¸ ˜ ao ´ e enviada para a CMDB? Foi poss´ ıvel constatar que os CIs e relacionamentos descobertos e que se enquadram nas regras de transformac¸˜ ao geradas s˜ ao efetivamente criados na CMDB. 6 CONCLUS ˜ OES E TRABALHO FUTURO Neste ´ ultimo Cap´ ıtulo ´ e feita uma apreciac¸˜ ao global do trabalho desenvolvido ao longo desta dissertac¸˜ ao, assim como uma abordagem do trabalho futuro. 6.1 conclus ˜ ao Nesta dissertac¸ ˜ ao foi apresentada uma ferramenta de criac¸˜ ao autom´ atica de uma CMDB, que executa a descoberta e explorac¸ ˜ ao de uma infraestrutura, armazenando a informac¸˜ ao recolhida numa base de dados, e faz o povoamento de uma CMDB. Nesta fase, ´ e poss´ ıvel fazer uma comparac¸˜ ao entre os resultados obtidos e os objetivos levantados na fase inicial do projeto. Perceber como funcionam as tecnologias que implementam CMDBs e como ´ e que os dados recolhidos podem ser armazenados. Foram analisadas cinco ferramentas de software, tendo sido poss´ ıvel perceber como ´ e que a ferramenta desenvolvida poderia ser integrada com estas. Foi necess´ ario, essencialmente, perceber como era poss´ ıvel obter o modelo de dados das CMDBs, assim como o povoamento destas poderia ser efetuado. Foi verificado que ´ e poss´ ıvel obter o modelo de dados atrav´ es das APIs das CMDBs ou atrav´ es da an´ alise das suas bases de dados. Relativamente ao povoamento, este pode ser efetuado atrav´ es das APIs destas. Desenvolver uma arquitetura para a automatizac¸ ˜ ao do processo de criac¸˜ ao de uma CMDB. Durante o desenvolvimento de todas as fases, procurou-se implementar o maior n´ umero poss´ ıvel de mecanismos autom´ aticos, de forma a automatizar todo o processo. Na fase de descoberta, foi implementada a descoberta autom´ atica da infraestrutura, que ´ e capaz de explorar as m´ aquinas encontradas de acordo com o seu tipo. Na fase de mapeamento, foram implementados processos que captassem os modelos de dados da base de dados gerada pelos dados recolhidos e da CMDB a utilizar, definindo automaticamente correspondˆ encias entre os elementos dos dois modelos. Na fase de povoamento foram definidos processos capazes de transformar a informac¸ ˜ ao descoberta, recorrendo ` as regras de transformac¸˜ ao calculadas na fase de mapeamento, em pedidos ` as APIs das CMDBs. Implementar um processo de descoberta autom´ atica dos elementos computacionais de uma organizac¸˜ ao recorrendo a ferramentas de an´ alise de redes e invent´ ario de sistemas. 100 6.1. Conclus˜ ao 101 Com este objetivo em mente, a fase de descoberta da infraestrutura foi desenvolvida de modo a que: • seja poss´ ıvel personalizar o detalhe da descoberta; • seja poss´ ıvel integrar qualquer mecanismo de descoberta; • os mecanismos de descoberta sejam capazes de ser executados de acordo com os dispositivos encontrados. Fazer o povoamento da CMDB, adaptando-o ` a ferramenta escolhida pelo utilizador. Inicialmente, foi necess´ ario desenvolver um mecanismo capaz de processar o modelo de dados da CMDB. Este recorreu ` aAPI da CMDB ou a acessos diretos ` a sua base de dados para obter esta informac¸˜ ao. Foi tamb´ em necess´ ario desenvolver um mecanismo capaz de adaptar o povoamento de acordo com a API da CMDB escolhida. Ter um mecanismo de processamento e outro de povoamento para cada software n˜ ao ´ e o mesmo que definir um mapeamento padr˜ ao para cada um. Como os modelos das CMDBs podem ser personalizados, n˜ ao ´ e poss´ ıvel ter um mapeamento padr˜ ao para cada soluc¸˜ ao, porque, para o mesmo software, os modelos de dados podem ser diferentes em diferentes organizac¸ ˜ oes. Desta forma, os mecanismos desenvolvidos indicam apenas como os modelos de dados podem ser obtidos e como a CMDB pode ser povoada, ou seja, apesar de serem dependentes do software, s˜ ao independentes do modelo de dados da CMDB. Minimizar o esforc¸o do utilizador na tarefa de criac¸˜ ao da CMDB. Ao longo de todo o processo as interac¸ ˜ oes com o utilizador foram reduzidas apenas ao necess´ ario. Este s´ o interage com a ferramenta para: • indicar a utilizac¸˜ ao, ou n˜ ao, de ferramentas externas; • definir os enderec¸os a explorar; • especificar as credenciais dos dispositivos; • especificar a base de dados a utilizar; • especificar a CMDB a ser utilizada; • selecionar os mapeamentos a adotar quando estes apresentam o mesmo valor entre diferentes elementos; • escolher o valor limite das regras de transformac¸˜ ao a considerar. Al´ em disto, ´ e tamb´ em poss´ ıvel verificar como a ferramenta desenvolvida responde a alguns dos problemas encontrados no processo de criac¸˜ ao de uma CMDB, enunciados na Secc¸˜ ao 2.4.3. Recursos humanos e financeiros limitados. Tendo isto em conta, a implementac¸˜ ao da ferramenta foi simplificada, resultando no desenvolvimento de uma aplicac¸˜ ao Command Line Interface (CLI). Como a interface com o utilizador n˜ ao era t˜ ao relevante neste processo, foi dada uma maior importˆ ancia ` a 6.2. Trabalho Futuro 102 implementac¸˜ ao do processo em si. Foi tamb´ em utilizada a linguagem Python, assim como c´ odigo open-source, que ´ e facilmente executado. N˜ ao planeamento dos tipos, atributos e relacionamentos que se quer manter, leva ` a tentativa insustent´ avel de manter demasiada informac¸˜ ao. Neste caso, o facto de ser poss´ ıvel personalizar o n´ ıvel do detalhe da descoberta, garante que seja apenas recolhida informac¸˜ ao de acordo com os objetivos do utilizador. Utilizac¸˜ ao de uma abordagem maioritariamente manual acaba por ser insustent´ avel tendo em conta todo o processo de criac¸˜ ao e manutenc¸ ˜ ao da CMDB. O processo desenvolvido ´ e autom´ atico e tenta diminuir ao m´ aximo o esforc¸o desempenhado pelo utilizador. Informac¸ ˜ ao desatualizada ou incorreta leva ` a inconsistˆ encia da CMDB. A combinac¸˜ ao de v´ arios mecanismos de descoberta para a recolha de informac¸ ˜ ao garante que os dados recolhidos s˜ ao o mais atualizados ou exatos poss´ ıveis. Falta de capacidade de integrac¸˜ ao com outras ferramentas. Possibilidade de integrac¸˜ ao de qualquer mecanismo de descoberta e com qualquer CMDB. Capacidades de reconciliac¸˜ ao e normalizac¸ ˜ ao fracas, que levam ` a inconsistˆ encia da informac¸ ˜ ao. Foram implementados mecanismos de normalizac¸˜ ao e reconciliac¸˜ ao capazes de minimizar a ocorrˆ encia de incoerˆ encias nos dados. Finalmente, ´ e poss´ ıvel tamb´ em comparar a ferramenta desenvolvida com as ferramentas abordadas na Secc¸˜ ao 2.7. A ferramenta desenvolvida ´ e capaz de oferecer capacidades de descoberta semelhantes, com a vantagem de n˜ ao necessitar da definic¸˜ ao de v´ arias tarefas - apenas uma com definic¸˜ ao do n´ ıvel de detalhe e explorac¸˜ ao autom´ atica de acordo com os dispositivos descobertos. Para al´ em disso, ´ e uma soluc¸˜ ao open-source em oposic¸˜ ao ao software propriet´ ario, e usualmente pago, destas ferramentas. Finalmente, oferece a capacidade de integrac¸ ˜ ao com qualquer CMDB em oposic¸ ˜ ao ` a integrac¸˜ ao com apenas a CMDB do mesmo fornecedor de software da ferramenta de descoberta. 6.2 trabalho futuro O trabalho apresentado nesta dissertac¸˜ ao implementa os processos essenciais da criac¸˜ ao de uma CMDB. No entanto, este processo pode ser melhorado e at´ e desenvolvido de forma a executar outras func¸ ˜ oes. Em vez de fazer apenas a criac¸˜ ao da CMDB, a ferramenta poderia tamb´ em ser adaptada para fazer a atualizac¸˜ ao desta. Isto poderia ser conseguido comec¸ando por processar os dados j´ a armazenados na CMDB. Depois, a descoberta poderia ser baseada nesta informac¸˜ ao, e o mecanismo de reconciliac¸˜ ao poderia ser utilizado de forma a conciliar a nova informac¸˜ ao descoberta com aquela que j´ a se encontrava na CMDB. Em vez enviar pedidos de criac¸˜ ao ` aAPI, seria necess´ ario adaptar estes para fazer a atualizac¸˜ ao dos CIs e relacionamentos. Neste caso, tamb´ em a forma como o utilizador interage com a ferra- 6.2. Trabalho Futuro 103 menta pode ser modificada. No caso da criac¸˜ ao da CMDB,´ e esperado que o processo seja realizado apenas uma vez. Assim, a introduc¸˜ ao dos dados ao longo da execuc¸˜ ao do processo n˜ ao apresenta qualquer desvantagem. No entanto, no caso da atualizac¸˜ ao da CMDB,´ e esperado que o processo seja executado v´ arias vezes. Assim, a utilizac¸˜ ao de um ficheiro de configurac¸˜ ao seria mais conveniente, uma vez que a informac¸˜ ao n˜ ao iria variar, ou seja, o processo em princ´ ıpio iria ser executado sempre com base no mesmo ficheiro de configurac¸ ˜ ao, fazendo com que o utilizador n˜ ao tenha de introduzir manualmente a mesma informac¸˜ ao. Al´ em disto, a ferramenta poderia tamb´ em ser aperfeic¸oada, tendo tamb´ em j´ a sido enunciadas algumas destas melhorias na Secc¸˜ ao 5.5: • ser pos´ ıvel o utilizador n˜ ao s´ o selecionar as categorias, como tamb´ em os mecanismos de descoberta a serem efetivamente executados; • implementar outros mecanismos de descoberta de modo a explorar outros tipos de dispositivos e recolher outros tipos de dados; • ser capaz de inferir informac¸˜ ao com base nos dados recolhidos; • fazer a integrac¸˜ ao com outras ferramentas externas de descoberta; • basear o c´ alculo de similaridade apenas no dom´ ınio de linguagem das TIs; • ser poss´ ıvel efetuar o mapeamento entre m´ ultiplos elementos; • fazer a integrac¸˜ ao com outras CMDBs. bibliografia 110 [105] G. O. Santos and J. C. Reis. Identificac¸˜ ao de mapeamentos entre ontologias em diferentes l´ ınguas. Technical report, Universidade Estadual de Campinas - Instituto de Computac¸ ˜ ao, 2018. [106] T. Schaaf and B. G¨ ogetap. Requirements and Recommendations for the Realization of a Configuration Management Database. Service Management,2011. [107] T. A. Singer, S. L. Christenson, and B. Beheshti. System and method for network auto-discovery and configuration, Dec. 2004. US Patent 6,834,298. [108] B. Srinivasa-Desikan. Natural Language Processing and Computational Linguistics: A practical guide to text analysis with Python, Gensim, spaCy, and Keras. Packt Publishing Ltd, 2018. [109] B. Tabbara. Method and apparatus for discovering network devices, July 2014. US Patent 8,775,584. [110] R. Thurlow. RFC 5531 - RPC: Remote Procedure Call Protocol Specification Version 2.https://tools.ietf.org/html/rfc5531,2009. Acedido: 23-12-2020. [111] T. Wang, S. Truptil, and F. B´ enaben. An automatic model-to-model mapping and transformation methodology to serve model-based systems engineering. Information Systems and e-Business Management,15,05 2017. [112] Z. Wu and M. Palmer. Verbs semantics and lexical selection. Association for Computational Linguistics, 1994. doi: 10.3115/981732.981751. [113] T. Ylonen and C. Lonvick. RFC 4252 - The Secure Shell (SSH) Authentication Protocol. https://tools.ietf.org/html/rfc4252,2006. Acedido: 30-12-2020. A RESULTADOS DO PROCESSAMENTO DE MODELOS DE DADOS Listagem A.1: Resultado (parcial) do processamento do modelo de dados do i-doit. { "ci_types": { "C__OBJTYPE__APPLICATION": "Application", "C__OBJTYPE__SERVER": "Server", "C__OBJTYPE__SWITCH": "Switch", "C__OBJTYPE__ROUTER": "Router", "C__OBJTYPE__ACCESS_POINT": "Wireless Access Point", "C__OBJTYPE__LAYER3_NET": "Layer 3-net", "C__OBJTYPE__CONTAINER": "Container", "C__OBJTYPE__OPERATING_SYSTEM": "Operating System", "C__OBJTYPE__HOST": "Host", "C__OBJTYPE__IT_SERVICE": "Service", "C__OBJTYPE__DBMS": "Dbms", [...] }, "rel_types": { "C__RELATION_TYPE__SOFTWARE": "Software assignment", "C__RELATION_TYPE__NETWORK_PORT": "Ports", "C__RELATION_TYPE__LOCATION": "Location", "C__RELATION_TYPE__IP_ADDRESS": "Host address", "C__RELATION_TYPE__DEFAULT": "Dependency", "C__RELATION_TYPE__DATABASE_INSTANCE": "Database instance", "C__RELATION_TYPE__NET_CONNECTIONS": "Network connections", "C__RELATION_TYPE__OPERATION_SYSTEM": "Operating system", [...] }, "ci_attributes": { "C__OBJTYPE__APPLICATION": { "description": "Description", "price": "Investment costs", "order_date": "Order date", "guarantee_date": "Guarantee date", "title": "Title", "id": "ID", 111 112 "created": "Creation date", "changed": "Last change", "cmdb_status": "CMDB status", "type": "Type", "application_type": "Type", "assigned_license": "Assigned license", [...] }, "C__OBJTYPE__SERVER": { "mount_point": "Drive letter", "title": "Title", "filesystem": "Filesystem", "serial": "Serial number", "free_space": "Free Diskspace", "used_space": "Used Diskspace", "description": "Description", "manufacturer": "Manufacturer", "price": "Investment costs", "ip_address": "(Source) ip address", "id": "ID", "status": "Condition", [...] }, "C__OBJTYPE__SWITCH": { "title": "Title", "description": "Description", "acquirementdate": "Date of invoice", "price": "Investment costs", "id": "ID", "status": "Condition", "created": "Creation date", "created_by": "Created by", "changed": "Last change", "changed_by": "Last change by", "latitude": "Latitude", "longitude": "Longitude", "manufacturer": "Manufacturer", "serial": "Serial number", "width": "Width", "height": "Height", "depth": "Depth", "weight": "Weight", "ipv6_address": "IPv6 address", [...] }, "C__OBJTYPE__ROUTER": { "title": "Title", 113 "description": "Description", "id": "ID", "status": "Condition", "manufacturer": "Manufacturer", "mac": "MAC", "layer2_assignment": "Layer 2 Net", "ipv4_address": "IPv4 address", "ipv6_address": "IPv6 address", "hostname": "Hostname", "domain": "Domain", "routing_protocol": "Routing protocol", "gateway_address": "Gateway address" [...] }, "C__OBJTYPE__ACCESS_POINT": { "description": "Description", "inventory_no": "Inventory number", "title": "Title", "status": "Condition", "manufacturer": "Manufacturer", "serial": "Serial number", "firmware": "Firmware", "interface": "Connected interface", "ssid": "SSID", [...] }, "C__OBJTYPE__LAYER3_NET": { "description": "Description", "title": "Title", "status": "Condition", "netmask": "Netmask", "gateway": "Default Gateway", "range_from": "DHCP from", "range_to": "DHCP to", "dns_server": "DNS server", "dns_domain": "DNS domain", "cidr_suffix": "CIDR-Suffix", "reverse_dns": "Reverse DNS", "address_range": "Address range", [...] }, "C__OBJTYPE__CONTAINER": { "description": "Description", "id": "ID", "title": "Title", "status": "Condition", "created": "Creation date", 114 "created_by": "Created by", [...] }, "C__OBJTYPE__OPERATING_SYSTEM": { "title": "Title", "kernel": "Kernel", "ram": "RAM", "cpu": "CPU frequency", "disc_space": "Disc space", "status": "Condition", "common_name": "Common Name", "assigned_version": "Version number", "specification": "Specification", "manufacturer": "Manufacturer", "install_path": "Install path", [...] }, "C__OBJTYPE__HOST": { "mount_point": "Drive letter", "title": "Title", "filesystem": "Filesystem", "serial": "Serial number", "free_space": "Free Diskspace", "used_space": "Used Diskspace", "description": "Description", "manufacturer": "Manufacturer", "model": "Model", "firmware": "Firmware", "price": "Investment costs", "storage_type": "Storage type", "network_type": "Network type", "cores": "CPU cores", [...] }, "C__OBJTYPE__IT_SERVICE": { "service_id": "Service-ID", "service_level": "SLA service level", "reaction_time": "Reaction time", "recovery_time": "Recovery time", "description": "Description", "alert_level": "Alarm level", "comment": "Comment", "service_number": "Service number", "service_description_intern": "Service description internal", "service_description_extern": "Service description external", "service_alias": "Aliases", "title": "Title", 115 "status": "Condition", [...] }, "C__OBJTYPE__DBMS": { "title": "Title", "status": "Condition", "assigned_database_schema": "Database schema", "dbms": "DBMS", "variant": "Variant", "application_type": "Type", "application_priority": "Priority", "assigned_license": "Assigned license", "assigned_license_key": "Assigned license key", "assigned_version": "Version number", [...] }, [...] }, "rel_attributes": { "C__RELATION_TYPE__SOFTWARE": { "object1": "Object1", "object2": "Object2", "relation_type": "Relation type", "weighting": "Weighting", "description": "Description", "title": "Title", "status": "Condition", [...] }, "C__RELATION_TYPE__NETWORK_PORT": { "object1": "Object1", "object2": "Object2", "relation_type": "Relation type", "weighting": "Weighting", "description": "Description", "title": "Title", "status": "Condition", "created": "Creation date", "created_by": "Created by", "net_type": "Type", "net": "Net", "zone": "Net zone", [...] }, "C__RELATION_TYPE__LOCATION": { "object1": "Object1", "object2": "Object2", 116 "relation_type": "Relation type", "weighting": "Weighting", "description": "Description", [...] }, "C__RELATION_TYPE__IP_ADDRESS": { "object1": "Object1", "object2": "Object2", "relation_type": "Relation type", "weighting": "Weighting", "description": "Description", "application": "Application", "title": "Title", "status": "Condition", "primary_layer3_net": "Primary layer3 net", "primary_hostaddress": "Primary hostaddress", "primary_hostname": "Primary hostname", "net_type": "Type", "ipv4_address": "IPv4 address", "dns_server": "DNS Server", "dns_server_address": "DNS Server address", [...] }, "C__RELATION_TYPE__DEFAULT": { "object1": "Object1", "object2": "Object2", "relation_type": "Relation type", "weighting": "Weighting", "description": "Description", "title": "Title", "status": "Condition", "created": "Creation date", "created_by": "Created by", [...] }, "C__RELATION_TYPE__DATABASE_INSTANCE": { "object1": "Object1", "object2": "Object2", "relation_type": "Relation type", "weighting": "Weighting", "description": "Description", "assigned_databases": "Used databases", "id": "ID", "title": "Title", "status": "Condition", [...] }, 117 "C__RELATION_TYPE__NET_CONNECTIONS": { "object1": "Object1", "object2": "Object2", "relation_type": "Relation type", "weighting": "Weighting", "description": "Description", "id": "ID", "title": "Title", "status": "Condition", "net_type": "Type", "zone": "Net zone", "assigned_logical_port": "Assigned port", [...] }, "C__RELATION_TYPE__OPERATION_SYSTEM": { "object1": "Object1", "object2": "Object2", "relation_type": "Relation type", "weighting": "Weighting", "description": "Description", "title": "Title", "status": "Condition", "user_name_static": "User", [...] }, [...] }, "ci_attributes_data_types": { "C__OBJTYPE__SERVER": { "mount_point": "text", "title": "text", "filesystem": "int", "serial": "text", "free_space": "float", "used_space": "float", "description": "text_area", "manufacturer": "int", "price": "double", "ip_address": "int", "id": "int", "status": "int", [...] }, [...] }, "rel_attributes_data_types": { "C__RELATION_TYPE__NETWORK_PORT": { 118 "object1": "int", "object2": "int", "relation_type": "int", "weighting": "int", "description": "text_area", "title": "text", "status": "int", "created": "text", "created_by": "text", "net_type": "int", "net": "int", "zone": "int", [...] }, [...] "rel_restrictions": {}, "ci_dialog_attributes": { "C__OBJTYPE__SERVER": { "status": { "3": "Archived", "1": "Unready", "4": "Deleted", "2": "Normal", "6": "Template", "7": "Mass change template" }, "cmdb_status": { "1": "planned", "2": "ordered", "3": "delivered", "4": "assembled", "5": "tested", "6": "in operation", "7": "defect", "8": "under repair", "9": "delivered from repair", "10": "inoperative", "11": "stored", "12": "scrapped" }, "net_type": { "1": "IPv4 (Internet Protocol v4)", "2": "IPX (Internet Packet Exchange)", "3": "AT (AppleTalk)", "1000": "IPv6 (Internet Protocol v6)" }, [...] 119 }, [...] }, "rel_dialog_attributes": {} } 126 Tabela C.1: Exemplo de alguns atributos de CIs descobertos no primeiro caso de teste. Identificador Nome Tipo Atributo Valor 110macbookprojoana macbookprojoana Host os version 10.15.7 kernel version Darwin 19.6.0 battery bq20z451 os macOS 10.15.7(19H15) boot mode normal boot time since boot up 1:8:11:46 CPU Quad-Core Intel Core i7 CPU speed 2;2GHz display Color LCD CPU frequency 2;2 CPU frequency unit GHz CPU cores 4 physical memory 16 GB memory ram 16 physical memory unit GB GPU kHW IntelIrisProItem hostname macbookprojoana.local os name Mac OS X description MacBook Pro MacBook ProMacBook Pro has ipv4 192.168.1.73 has ipv6 2001:8a0:f576:7000:19c8:36e6:6c25:e634 has ipv6 2001:8a0:f576:7000:1cac:32c1:d287:1804 mac address c4:b3:01:c0:1a:d3 os family macOS serial number C02S80K6G8WN status up uuid 0B793129-B10E-5C77-89DD-4529FEF05AD6 1211mac o s 10 15 7 19 h15 macOS 10.15.7 19H15 Operating System os family Mac OS X version number 10.15.7 build version 19H15 3021py charm PyCharm Application arch kind arch i32 i64 info PyCharm 2020.3.4; build PY-203.7717.65. Copyright JetBrains s.r.o.; (c) 2000-2021 last modified 2021-03-16T10:52:36Z path /Applications/PyCharm.app obtained from identified developer description 2020.3.4 1312quad core intel core i7Quad-Core Intel Core i7CPU Speed 2;2GHz Number of Cores 4 L2Cache 256 KB L3Cache 6MB SMC Version 2.29f24 1615p t PT Location country Portugal region Braga city Barcelos zip code 4750-106 time zone Europe/Lisbon latitude 41.5388 longitude -8.6171 1816b a n k 1d i m m0BANK 1DIMM0RAM manufacturer 0x802C part number 0x31364B544631473634485A2D314736453120 size 8GB speed 1600 MHz architecture DDR3 serial number - status ok 1917a p p l e s s d s m0256 g APPLE SSD SM0256G SSD Controller bsd name disk0 detachable drive no device model APPLE SSD SM0256G device revision BXZ13A0Q partition map type guid partition map type removable media no size 251 GB medium type Solid State ncq Yes ncq depth 32 link speed 8.0GT/s link width x4 physical interconnect PCI port description AHCI Version 1.30 Supported product SSD Controller vendor Apple serial number S2Z5NY0H811261 127 Tabela C.2: Exemplo de alguns atributos de CIs descobertos no segundo caso de teste. Identificador Nome Tipo Atributo Valor 1817ubuntu pc ubuntu-pc Host Icon name computer-desktop Chassis desktop Machine ID 93b6da13546247df9c2c4e89abccfea3 Boot ID d17d71c7440943af87c6abc7a6db7822 Operating System Ubuntu 18.04.5LTS vendor Dell Kernel Linux 5.4.0-70-generic Architecture x86-64 os family Ubuntu os name Ubuntu 18.04.5LTS os version 18.04 CPU cores 4 CPU Intel(R) Core(TM) i5-3470S CPU @ 2.90GHz CPU frequency unit MHz CPU frequency 1596.396 CPU speed 1596.396 MHz has ipv4 192.168.1.88 mac address F8:B1:56:AD:16:2F os family Linux status up 2019ubuntu 18 04 5 l t s Ubuntu 18.04.5LTS Operating System vendor Ubuntu DISTRIB RELEASE 18.04 DISTRIB CODENAME bionic DISTRIB DESCRIPTION Ubuntu 18.04.5LTS ID ubuntu ID LIKE debian version number 18.04 HOME URL https://www.ubuntu.com/ SUPPORT URL https://help.ubuntu.com/ BUG REPORT URL https://bugs.launchpad.net/ubuntu/ PRIVACY POLICY URL https://www.ubuntu.com/legal/terms-and-policies/privacy-policy VERSION CODENAME bionic UBUNTU CODENAME bionic description 18.04.5LTS (Bionic Beaver) 2120intel r core t m i5 3470 s c p u 2 90 g hz IntelR CoreTM i5-3470S CPU 2.90GHz CPU Architecture x86 64 CPU op-modes 32-bit; 64-bit Byte Order Little Endian CPUs 1 On-line CPUs list 0-3 Threads per core 1 Cores per socket 4 NUMA nodes 0-3 Vendor ID GenuineIntel CPU family 6 Stepping 9 CPU frequency unit MHz CPU frequency 1596.396 CPU speed 1596.396 MHz CPU max MHz 3600;0000 CPU min MHz 1600;0000 BogoMIPS 5787.05 Virtualization VT-x L1d cache 6144K Flags fpu vme de pse tsc msr pae mce cx8apic sep mtrr pge mca... description 58 2521sda4sda4SSD PARTUUID 0780dcb0-04 Filesystem /dev/sda4 1K-blocks 177521492 Used 96% Available 7430508 Mounted on / NAME sda4 MAJ:MIN 08:04 RM 0 SIZE 173G RO 0 MOUNTPOINT / description part partpart partpart partpart uuid 57170c8d-8978-48f5-8c8e-ed4e1f32f182 2625graphdb free graphdb-free Application Architecture amd64 description GraphDB 9.3.1 2725gnome shell gnome-shell Architecture amd64 description graphical 3.28.4-0ubuntu18.04.3 2825firefox firefox Architecture amd64 description Safe 87.0+build3-0ubuntu0.18.04.2 2925snapd snapd Architecture amd64 description Daemon 2.48.3+18.04 3025evolution data server evolution-data-server Architecture amd64 description evolution 3.28.5-0ubuntu0.18.04.3 This work is financed by National Funds through the Portuguese funding agency, Fundac¸ ˜ ao para a Ciˆ encia e a Tecnologia (FCT), within project UIDB/50014/2020.