TURNO: noturno VERSÃO: 2 N o UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS DEPARTAMENTO DE SISTEMAS E COMPUTAÇÃO CURSO DE CIÊNCIAS DA COMPUTAÇÃO BACHARELADO COORDENAÇÃO DE TRABALHO DE CONCLUSÃO DE CURSO PROPOSTA PARA O TRABALHO DE CONCLUSÃO DE CURSO TÍTULO: SOFTWARE DE INVENTÁRIO DE SOFTWARE DE EQUIPAMENTOS DE REDE UTILIZANDO SESSION MESSAGE BLOCK ÁREA: Redes de Computadores Palavras-chave: Protocolo de rede. Inventário de computadores. Patrimônio. SMB. 1 IDENTIFICAÇÃO 1.1 ALUNO Nome: Josélio Kreuch Código/matrícula: 71621-9 Endereço residencial: Rua: Alida Pommerening n : 36 Complemento: Bairro: Itoupava Central CEP: 89062-040 Cidade: Blumenau UF: SC Telefone fixo: 3338-3842 Celular: 8826-1723 Endereço comercial: Empresa: Weg Equipamentos Elétricos S.A. Rua: Prefeito Waldemar Grubba n : 3000 Bairro: Vila Lalau CEP: 89256-900 Cidade: Jaraguá do Sul UF: SC Telefone: 47 3372-4629 E-Mail FURB: joseliok@inf.furb.br E-Mail alternativo: joseliokreuch@brturbo.com.br 1.2 ORIENTADOR Nome: Francisco Adell Péricas E-Mail FURB: pericas@furb.br E-Mail alternativo:
2 DECLARAÇÕES 2.1 DECLARAÇÃO DO ALUNO Declaro que estou ciente do Regulamento do Trabalho de Conclusão de Curso de Ciências da Computação e que a proposta em anexo, a qual concordo, foi por mim rubricada em todas as páginas. Ainda me comprometo pela obtenção de quaisquer recursos necessários para o desenvolvimento do trabalho, caso esses recursos não sejam disponibilizados pela Universidade Regional de Blumenau (FURB). Assinatura: Local/data: 2.2 DECLARAÇÃO DO ORIENTADOR Declaro que estou ciente do Regulamento do Trabalho de Conclusão do Curso de Ciências da Computação e que a proposta em anexo, a qual concordo, foi por mim rubricada em todas as páginas. Ainda me comprometo a orientar o aluno da melhor forma possível de acordo com o plano de trabalho explícito nessa proposta. Assinatura: Local/data:
3 AVALIAÇÃO DA PROPOSTA 3.1 AVALIAÇÃO DO(A) ORIENTADOR(A) Acadêmico(a): Orientador(a): Josélio Kreuch Francisco Adell Péricas ASPECTOS TÉCNICOS ASPECTOS METODOLÓGICOS ASPECTOS AVALIADOS 1. INTRODUÇÃO 1.1. O tema de pesquisa está devidamente contextualizado/delimitado? 1.2. O problema está claramente formulado? 2. OBJETIVOS 2.1. O objetivo geral está claramente definido e é passível de ser alcançado? 2.2. São apresentados objetivos específicos (opcionais) coerentes com o objetivo geral? Caso não sejam apresentados objetivos específicos, deixe esse item em branco. 3. RELEVÂNCIA 3.1. A proposta apresenta um grau de relevância em computação que justifique o desenvolvimento do TCC? 4. METODOLOGIA 4.1. Foram relacionadas todas as etapas necessárias para o desenvolvimento do TCC? 4.2. Os métodos e recursos estão devidamente descritos e são compatíveis com a metodologia proposta? 4.3. A proposta apresenta um cronograma físico (período de realização das etapas) de maneira a permitir a execução do TCC no prazo disponível? 5. REVISÃO BIBLIOGRÁFICA 5.1. As informações apresentadas são suficientes e têm relação com o tema do TCC? 5.2. São apresentados trabalhos correlatos, bem como comentadas as principais características dos mesmos? 6. REQUISITOS DO SISTEMA A SER DESENVOLVIDO 6.1. Os requisitos funcionais e não funcionais do sistema a ser desenvolvido foram claramente descritos? 7. CONSIDERAÇÕES FINAIS 7.1. As considerações finais relacionam os assuntos apresentados na revisão bibliográfica com a realização do TCC? 8. REFERÊNCIAS BIBLIOGRÁFICAS 8.1. As referências bibliográficas obedecem às normas da ABNT? 8.2. As referências bibliográficas contemplam adequadamente os assuntos abordados na proposta (são usadas obras atualizadas e/ou as mais importantes da área)? 9. CITAÇÕES 9.1. As citações obedecem às normas da ABNT? 9.2. As informações retiradas de outros autores estão devidamente citadas? 10. AVALIAÇÃO GERAL (organização e apresentação gráfica, linguagem usada) 10.1. O texto obedece ao formato estabelecido? 10.2. A exposição do assunto é ordenada (as idéias estão bem encadeadas e a linguagem utilizada é clara)? atende atende parcialmente A proposta de TCC deverá ser revisada, isto é, necessita de complementação, se: qualquer um dos itens tiver resposta NÃO ATENDE; pelo menos 4 (quatro) itens dos ASPECTOS TÉCNICOS tiverem resposta ATENDE PARCIALMENTE; ou pelo menos 4 (quatro) itens dos ASPECTOS METODOLÓGICOS tiverem resposta ATENDE PARCIALMENTE. PARECER: ( ) APROVADA ( ) NECESSITA DE COMPLEMENTAÇÃO não atende Assinatura do(a) avaliador(a): Local/data:
CONSIDERAÇÕES DO(A) ORIENTADOR(A): Caso o(a) orientador(a) tenha assinalado em sua avaliação algum item como atende parcialmente, devem ser relatos os problemas/melhorias a serem efetuadas. Na segunda versão, caso as alterações sugeridas pelos avaliadores não sejam efetuadas, deve-se incluir uma justificativa. Assinatura do(a) avaliador(a): Local/data:
3.2 AVALIAÇÃO DO(A) COORDENADOR DE TCC Acadêmico(a): Avaliador(a): Josélio Kreuch José Roque Voltolini da Silva ASPECTOS TÉCNICOS ASPECTOS METODOLÓGICOS ASPECTOS AVALIADOS 1. INTRODUÇÃO 1.1. O tema de pesquisa está devidamente contextualizado/delimitado? 1.2. O problema está claramente formulado? 2. OBJETIVOS 2.1. O objetivo geral está claramente definido e é passível de ser alcançado? 2.2. São apresentados objetivos específicos (opcionais) coerentes com o objetivo geral? Caso não sejam apresentados objetivos específicos, deixe esse item em branco. 3. RELEVÂNCIA 3.1. A proposta apresenta um grau de relevância em computação que justifique o desenvolvimento do TCC? 4. METODOLOGIA 4.1. Foram relacionadas todas as etapas necessárias para o desenvolvimento do TCC? 4.2. Os métodos e recursos estão devidamente descritos e são compatíveis com a metodologia proposta? 4.3. A proposta apresenta um cronograma físico (período de realização das etapas) de maneira a permitir a execução do TCC no prazo disponível? 5. REVISÃO BIBLIOGRÁFICA 5.1. As informações apresentadas são suficientes e têm relação com o tema do TCC? 5.2. São apresentados trabalhos correlatos, bem como comentadas as principais características dos mesmos? 6. REQUISITOS DO SISTEMA A SER DESENVOLVIDO 6.1. Os requisitos funcionais e não funcionais do sistema a ser desenvolvido foram claramente descritos? 7. CONSIDERAÇÕES FINAIS 7.1. As considerações finais relacionam os assuntos apresentados na revisão bibliográfica com a realização do TCC? 8. REFERÊNCIAS BIBLIOGRÁFICAS 8.1. As referências bibliográficas obedecem às normas da ABNT? 8.2. As referências bibliográficas contemplam adequadamente os assuntos abordados na proposta (são usadas obras atualizadas e/ou as mais importantes da área)? 9. CITAÇÕES 9.1. As citações obedecem às normas da ABNT? 9.2. As informações retiradas de outros autores estão devidamente citadas? 10. AVALIAÇÃO GERAL (organização e apresentação gráfica, linguagem usada) 10.1. O texto obedece ao formato estabelecido? 10.2. A exposição do assunto é ordenada (as idéias estão bem encadeadas e a linguagem utilizada é clara)? atende atende parcialmente A proposta de TCC deverá ser revisada, isto é, necessita de complementação, se: qualquer um dos itens tiver resposta NÃO ATENDE; pelo menos 4 (quatro) itens dos ASPECTOS TÉCNICOS tiverem resposta ATENDE PARCIALMENTE; ou pelo menos 4 (quatro) itens dos ASPECTOS METODOLÓGICOS tiverem resposta ATENDE PARCIALMENTE. PARECER: ( ) APROVADA ( ) NECESSITA DE COMPLEMENTAÇÃO OBSERVAÇÕES: não atende Assinatura do(a) avaliador(a): Local/data:
3.3 AVALIAÇÃO DO(A) PROFESSOR(A) DA DISCIPLINA DE TCCI Acadêmico(a): Avaliador(a): Josélio Kreuch Joyce Martins ASPECTOS TÉCNICOS ASPECTOS METODOLÓGICOS ASPECTOS AVALIADOS 1. INTRODUÇÃO 1.1. O tema de pesquisa está devidamente contextualizado/delimitado? 1.2. O problema está claramente formulado? 2. OBJETIVOS 2.1. O objetivo geral está claramente definido e é passível de ser alcançado? 2.2. São apresentados objetivos específicos (opcionais) coerentes com o objetivo geral? Caso não sejam apresentados objetivos específicos, deixe esse item em branco. 3. RELEVÂNCIA 3.1. A proposta apresenta um grau de relevância em computação que justifique o desenvolvimento do TCC? 4. METODOLOGIA 4.1. Foram relacionadas todas as etapas necessárias para o desenvolvimento do TCC? 4.2. Os métodos e recursos estão devidamente descritos e são compatíveis com a metodologia proposta? 4.3. A proposta apresenta um cronograma físico (período de realização das etapas) de maneira a permitir a execução do TCC no prazo disponível? 5. REVISÃO BIBLIOGRÁFICA 5.1. As informações apresentadas são suficientes e têm relação com o tema do TCC? 5.2. São apresentados trabalhos correlatos, bem como comentadas as principais características dos mesmos? 6. REQUISITOS DO SISTEMA A SER DESENVOLVIDO 6.1. Os requisitos funcionais e não funcionais do sistema a ser desenvolvido foram claramente descritos? 7. CONSIDERAÇÕES FINAIS 7.1. As considerações finais relacionam os assuntos apresentados na revisão bibliográfica com a realização do TCC? 8. REFERÊNCIAS BIBLIOGRÁFICAS 8.1. As referências bibliográficas obedecem às normas da ABNT? 8.2. As referências bibliográficas contemplam adequadamente os assuntos abordados na proposta (são usadas obras atualizadas e/ou as mais importantes da área)? 9. CITAÇÕES 9.1. As citações obedecem às normas da ABNT? 9.2. As informações retiradas de outros autores estão devidamente citadas? 10. AVALIAÇÃO GERAL (organização e apresentação gráfica, linguagem usada) 10.1. O texto obedece ao formato estabelecido? 10.2. A exposição do assunto é ordenada (as idéias estão bem encadeadas e a linguagem utilizada é clara)? PONTUALIDADE NA ENTREGA atende atende parcialmente não atende atraso de dias A proposta de TCC deverá ser revisada, isto é, necessita de complementação, se: qualquer um dos itens tiver resposta NÃO ATENDE; pelo menos 4 (quatro) itens dos ASPECTOS TÉCNICOS tiverem resposta ATENDE PARCIALMENTE; ou pelo menos 4 (quatro) itens dos ASPECTOS METODOLÓGICOS tiverem resposta ATENDE PARCIALMENTE. PARECER: ( ) APROVADA ( ) NECESSITA DE COMPLEMENTAÇÃO OBSERVAÇÕES: Assinatura do(a) avaliador(a): Local/data:
3.4 AVALIAÇÃO DO(A) PROFESSOR(A) ESPECIALISTA NA ÁREA Acadêmico(a): Avaliador(a): Josélio Kreuch ASPECTOS TÉCNICOS ASPECTOS METODOLÓGICOS ASPECTOS AVALIADOS 1. INTRODUÇÃO 1.1. O tema de pesquisa está devidamente contextualizado/delimitado? 1.2. O problema está claramente formulado? 2. OBJETIVOS 2.1. O objetivo geral está claramente definido e é passível de ser alcançado? 2.2. São apresentados objetivos específicos (opcionais) coerentes com o objetivo geral? Caso não sejam apresentados objetivos específicos, deixe esse item em branco. 3. RELEVÂNCIA 3.1. A proposta apresenta um grau de relevância em computação que justifique o desenvolvimento do TCC? 4. METODOLOGIA 4.1. Foram relacionadas todas as etapas necessárias para o desenvolvimento do TCC? 4.2. Os métodos e recursos estão devidamente descritos e são compatíveis com a metodologia proposta? 4.3. A proposta apresenta um cronograma físico (período de realização das etapas) de maneira a permitir a execução do TCC no prazo disponível? 5. REVISÃO BIBLIOGRÁFICA 5.1. As informações apresentadas são suficientes e têm relação com o tema do TCC? 5.2. São apresentados trabalhos correlatos, bem como comentadas as principais características dos mesmos? 6. REQUISITOS DO SISTEMA A SER DESENVOLVIDO 6.1. Os requisitos funcionais e não funcionais do sistema a ser desenvolvido foram claramente descritos? 7. CONSIDERAÇÕES FINAIS 7.1. As considerações finais relacionam os assuntos apresentados na revisão bibliográfica com a realização do TCC? 8. REFERÊNCIAS BIBLIOGRÁFICAS 8.1. As referências bibliográficas obedecem às normas da ABNT? 8.2. As referências bibliográficas contemplam adequadamente os assuntos abordados na proposta (são usadas obras atualizadas e/ou as mais importantes da área)? 9. CITAÇÕES 9.1. As citações obedecem às normas da ABNT? 9.2. As informações retiradas de outros autores estão devidamente citadas? 10. AVALIAÇÃO GERAL (organização e apresentação gráfica, linguagem usada) 10.1. O texto obedece ao formato estabelecido? 10.2. A exposição do assunto é ordenada (as idéias estão bem encadeadas e a linguagem utilizada é clara)? atende atende parcialmente A proposta de TCC deverá ser revisada, isto é, necessita de complementação, se: qualquer um dos itens tiver resposta NÃO ATENDE; pelo menos 4 (quatro) itens dos ASPECTOS TÉCNICOS tiverem resposta ATENDE PARCIALMENTE; ou pelo menos 4 (quatro) itens dos ASPECTOS METODOLÓGICOS tiverem resposta ATENDE PARCIALMENTE. PARECER: ( ) APROVADA ( ) NECESSITA DE COMPLEMENTAÇÃO OBSERVAÇÕES: não atende Assinatura do(a) avaliador(a): Local/data:
UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIAS DA COMPUTAÇÃO BACHARELADO SOFTWARE DE INVENTÁRIO DE SOFTWARE DE EQUIPAMENTOS DE REDE UTILIZANDO SESSION MESSAGE BLOCK JOSÉLIO KREUCH BLUMENAU 2006
JOSÉLIO KREUCH SOFTWARE DE INVENTÁRIO DE SOFTWARE DE EQUIPAMENTOS DE REDE UTILIZANDO SESSION MESSAGE BLOCK Proposta de Trabalho de Conclusão de Curso submetida à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso I do curso de Ciências da Computação Bacharelado. Prof. Francisco Adell Péricas - Orientador BLUMENAU 2006
2 1 INTRODUÇÃO Com a grande facilidade oferecida pelas redes de computadores e periféricos portáteis como pen driver, Compact Disc Recordable (CD-R), fica muito difícil para grandes empresas gerenciar e saber o que está instalado em cada uma das estações de trabalhos e servidores do seu parque de computadores. A utilização de Notebooks e outros portáteis utilizados em redes de computadores desprotegidas, sem a mínima segurança, são encontradas facilmente em aeroportos e hotéis, tornando muito mais fácil a invasão por softwares maliciosos com intuito de coletar informações sigilosas. Outro problema que grandes instituições vêm enfrentando é o de evitar o uso de softwares piratas. Sem um bom software para auxiliar, não se consegue avaliar se o número de licenças adquiridas é suficiente para atender a demanda da empresa, que em muitos casos é multada mesmo que a pirataria seja de forma não intencional. O gerenciamento de uma grande rede é sempre difícil e cara sem ajuda de um software que mostre a realidade dos equipamentos conectados na rede, principalmente na hora de tomar uma decisão estratégica quanto à substituição de computadores ou softwares em grande escala. Não tendo estas informações de uma forma fácil e imediata, pode-se atrasar um grande projeto coorporativo. Baseado nas dificuldades citadas acima, de gerenciar os softwares instalados nos computadores, o software proposto neste trabalho será desenvolvido como continuidade daquele descrito em Oliveira Junior (2005). O protocolo Session Message Block (SMB) será utilizado para prover a comunicação entre estação de gerência e estações gerenciadas, disponibilizando de forma rápida e eficiente para o administrador de rede um completo detalhamento de componentes de hardware (desenvolvido por Oliveira Junior) e de softwares (proposto neste trabalho) que compõem cada computador. As informações serão coletadas de forma automática na inicialização da estação.
3 1.1 OBJETIVOS DO TRABALHO O objetivo deste trabalho é desenvolver um software servidor 1 e um software cliente para levantamento de inventário de software nos computadores de uma rede empresarial. Os objetivos específicos do trabalho são: a) rastrear os softwares instalados nas estações através de um software servidor instalado nos computadores de rede; b) concentrar estas informações em um banco de dados centralizado para torná-las persistentes utilizando um software cliente; c) ter disponível a qualquer momento o inventário de software de cada estação da rede; d) disponibilizar relatórios dos softwares instalados em cada computador conectado a rede. 1.2 RELEVÂNCIA DO TRABALHO Atualmente muitas empresas não possuem nenhum controle relacionado a inventário de software e hardware de suas estações conectadas a rede. Seja pelo custo elevado de aquisição de uma ferramenta eficiente ou pela falta de ferramentas gratuitas. A utilização do protocolo SMB tornará a comunicação entre o servidor e o cliente muito simples e confiável, devido ser um protocolo novo e que já vem incorporado nos sistemas operacionais Windows. Com base nos fatores acima relacionados e visando continuar um trabalho acadêmico iniciado em 2005, o software proposto pretende ajudar os administradores de rede a avaliar de forma automática e rápida softwares instalados nos computadores da rede, trazendo benefícios para a segurança e combatendo a instalação de softwares não licenciados, evitando multas previstas em lei por esta prática ilegal. 1 Entende-se por software servidor o software instalado no computador que se quer extrair as informações e software cliente o software instalado na estação de gerência que recebe as informações dos softwares servidores.
4 1.3 METODOLOGIA O trabalho será desenvolvido observando as seguintes etapas: a) levantamento bibliográfico: entender o funcionamento do Registro do Windows, o protocolo SMB, os componentes necessários do Delphi ALMailSlot tregistry e trabalhos correlatos como o Configurador Automático e Coletor de Informações Computacionais(CACIC) (DATAPREV, 2005); b) estudo do trabalho do Oliveira Junior (2005): estudar, detalhar e reavaliar todo o trabalho desenvolvido por Oliveira Junior (2005); c) elicitação dos requisitos: reavaliar e detalhar os requisitos tendo como base o conteúdo levantado durante a revisão bibliográfica; d) especificação: a especificar a ferramenta com análise orientada a objeto utilizando a Unified Modeling Language (UML). Será usada a ferramenta Enterprise Architect para o desenvolvimento dos diagramas de caso de uso, de atividades, de seqüência e de classe; e) implementação: será utilizada a linguagem Delphi 7, a classe tregistry e o componente ALMailSlot. Como banco de dados será utilizado o MySQL; f) validação e testes: realizar testes instalando o software servidor e cliente em computadores diferentes conectados a mesma rede, verificando a consistência dos dados gerados pelo software desenvolvido; g) redação do volume final. As etapas serão realizadas nos períodos relacionados no Quadro 1. 2007 fev. mar. abr. maio jun. etapas / quinzenas 1 2 1 2 1 2 1 2 1 2 levantamento bibliográfico estudo do trabalho do Oliveira Junior (2005) elicitação dos requisitos especificação implementação validação e testes redação do volume final Quadro 1 - cronograma e
5 2 REVISÃO BIBLIOGRÁFICA Neste capítulo são apresentados aspectos teóricos relacionados ao trabalho, abordando gerenciamento de redes, protocolo SMB, Registro do Windows, componente ALMailSlot, a classe tregistry, protótipo de software para gerência de patrimônios dos equipamentos de uma rede utilizando Session Message Block e trabalhos correlatos. 2.1 GERENCIAMENTO DE REDES Com a grande necessidade de troca de informações entre computadores, as grandes empresas têm investido muito para integrar seus computadores mesmo que em regiões geográficas diferentes e distantes. Com isso tem-se a necessidade de centralizar informações comuns para uma melhor administração e compartilhamento de recursos, como sistemas de missão crítica que podem influenciar diretamente no objetivo da empresa. Estes recursos podem ser compartilhados por diversas pessoas em diversos lugares, tornando cada vez mais difícil de gerenciá-los e mantê-los seguros. Segundo Péricas (2003, p. 121 122), a gerência de redes é dividida em gerência de falhas, gerência de configuração, gerência de contabilização, gerência de desempenho e gerência de segurança. A gerência de segurança permite prevenir e detectar o uso impróprio ou não autorizado de recursos numa rede, assim como sua administração. Conforme descreve Péricas (2003, p. 125), a infra-estrutura de gerenciamento especificado pela International Organization for Standardization (ISO) define que gerente é uma aplicação de gerência que faz as requisições de operações, recebe notificações, enquanto que o agente é que recebe e processa estas operações e envia as respostas e emite as notificações. Na figura 1 pode-se ver um exemplo de comunicação entre as aplicações gerente e agente.
6 Software cliente Software servidor Fonte: Péricas (2003, p. 125). Figura 1 Comunicação entre entidades de gerência 2.2 PROTOCOLO SMB O SMB é um protocolo para compartilhamento de arquivos, impressoras, portas seriais e para abstração de comunicação entre computadores. O SMB é um protocolo cliente/servidor, conhecido também como request-response, onde o cliente faz uma requisição ao servidor e o servidor retorna uma resposta. Na figura 2 pode-se observar como funciona o SMB. Fonte: Samba (2002). Figura 2 Funcionamento do protocolo SMB Os clientes utilizam o NetBios over TCP/IP para se conectarem ao servidor. Depois de estabelecida a conexão, os clientes já podem utilizar os comandos SMB para compartilhar pastas, arquivos e impressoras (SAMBA, 2002).
7 2.3 REGISTRO DO WINDOWS O Microsoft Computer Dictionary (MICROSOFT CORPORATION, 2005) define o Registro como um banco de dados hierárquico central usado no Microsoft 9x, Windows CE, Windows NT e Windows 2000, usado para armazenar as informações necessárias à configuração do sistema para um ou mais usuários, aplicativos e dispositivos de hardware. O Registro contém informações que o Windows utiliza continuamente durante a operação, como os perfis de cada usuário, os aplicativos instalados no computador e os tipos de documentos que cada um pode criar, configurações de propriedades para ícones de pastas e aplicativos, o hardware existente no sistema e as portas que são usadas. Os dados do Registro são armazenados em arquivos binários. Resumindo, o Registro do Windows nada mais é que uma base de dados que guarda todas as informações do sistema. Quando um novo software é instalado em um sistema operacional Windows as mudanças são refletidas e armazenadas no seu Registro. Na Arquitetura Windows NT/2000/XP, o Registro fica armazenado dentro do diretório %SystemRoot% \ System32 \ Config. Não se consegue editar estes dados diretamente sem um editor de registro. Na figura 3 pode-se observar que o registro do Windows possui uma estrutura hierárquica como o gerenciador de arquivos Microsoft Windows Explorer (WINGUIDES NETWORK FOR WINDOWS, 2006). Fonte: Winguides Network for Windows (2006). Figura 3 Estrutura do Registro do Windows 2.4 COMPONENTE DELPHI ALMAILSLOT E CLASSE TREGISTRY O componente ALMailSlot, escrito para a linguagem de programação Delphi, permite
8 que as aplicações emitam mensagens através de uma rede usando mailslots através do protocolo SMB (DIGICRAFT, 2005). Mailslots são arquivos que residem na memória, e usam funções padrões do Windows para acessá-los. Um servidor de mailslot é um processo que cria e possui um mailslot. Quando o usuário cria um mailslot, recebe um handle que deve ser usado quando um processo lê mensagens do mailslot. Somente o processo que cria um mailslot ou obteve o handle por algum outro mecanismo pode ler do mailslot. Todos os mailslots são locais ao processo que os cria e ao contrário dos arquivos de disco, são provisórios e quando todos os handles de um mailslot forem fechados, o mailslot e todos os dados são perdidos. Resumo das operações: - Servidor cria um mailslot através de CreateMailslot() e obtém um handle. O mailslot possui um nome; - Servidor fica a espera de mensagens usando ReadFile(); - Cliente abre mailslot usando CreatFile(); - Cliente escreve mensagens usando o WriteFile(). Pode-se concluir que um mailslot nada mais é do que uma caixa postal que faz comunicação unidirecional entre o processo servidor e o processo cliente (MICROSOFT CORPORATION, 2001). A classe tregistry é declarada na unit Registry, e através dela é possível que uma aplicação efetue uma leitura ou gravação de dados no Registro do Windows. No quadro 1 pode-se ver um exemplo em Delphi utilizando a classe tregistry (BORLAND SOFTWARE CORPORATION, 2002). function GetRegistryValue(KeyName: string): string; var Registry: TRegistry; begin Registry := TRegistry.Create(KEY_READ); try Registry.RootKey = HKEY_LOCAL_MACHINE; // False because we do not want to create it if it doesn't exist Registry.OpenKey(KeyName, False); Result := Registry.ReadString('VALUE1'); finally Registry.Free; end; end; Quadro 1 Exemplo em Delphi utilizando a classe tregistry.
9 2.5 PROTÓTIPO DE SOFTWARE PARA GERÊNCIA DE PATRIMÔNIOS DOS EQUIPAMENTOS DE UMA REDE UTILIZANDO SESSION MESSAGE BLOCK O protótipo implementado por Oliveira Junior (2005) foi desenvolvido em Delphi 7 utilizando o protocolo SMB e tem como finalidade coletar dados de computadores conectados em uma rede, basicamente fazendo um inventário de hardware e disponibilizando-os em uma console de gerenciamento, onde um administrador de rede pode avaliar as configurações naquele momento e verificar se houve alguma alteração com um inventário feito anteriormente. Para a leitura do Registro do Windows no servidor, foi criado um componente (uinformacoes.pas) para ler as informações do Registro através de suas chaves específicas que guardam as informações desejadas para fazer o levantamento de patrimônio do computador. As informações lidas por este componente são armazenadas temporariamente em suas propriedades que em seguida, são armazenadas no próprio Registro do Windows numa chave específica de sua propriedade criada para armazenar persistentemente as informações colhidas. Estas informações armazenadas no Registro do Windows pelo componente, servem mais tarde para fazer a comparação entre as informações que estão sendo lidas e as informações lidas anteriormente, permitindo com que se possa efetuar uma comparação entre as duas e afirmar se houve ou não mudanças nos componentes instalados no computador. No cliente, o componente utilizado no servidor é utilizado para receber as informações e montar estas informações no mesmo formato em que o servidor as tratou, ou seja, o cliente enxerga as informações dos componentes da estação do mesmo modo que foi definido pelo servidor (OLIVEIRA JUNIOR, 2005). 2.6 TRABALHOS CORRELATOS A seguir estão descritos alguns softwares com características semelhantes ao proposto neste TCC. CACIC é o primeiro software público do governo federal desenvolvido em consórcio de cooperação entre a Secretaria de Logística Tecnológica de Informação (SLTI), do Ministério do Planejamento, Orçamento e Gestão (MPOG) e a Empresa de Tecnologia e Informação de Previdência Social (DATAPREV). CACIC é capaz de fornecer um diagnóstico
10 preciso do parque computacional e disponibilizar o número de equipamentos e sua distribuição nos mais diversos órgãos, os tipos de softwares utilizados e licenciados, configurações de hardwares, entre outras (DATAPREV, 2005). A Suite Trauma Zer0 é um software para gerenciamento de redes que dentre suas funcionalidades está o inventário de hardware e software, rastreamento de localização física, auditoria remota, distribuições de softwares, bloqueio de aplicações e outras funcionalidades mais. Possibilita a visualização em tempo real das alterações realizadas nos itens de configurações de hardware e softwares nos computadores. A Suíte Trauma Zer0 ainda exige que todos os softwares instalado sejam certificados, impedindo que softwares sem licença seja instalado (IVIRTUA SOLUTIONS, 2006). Trauma Zer0 é um software eficiente e completo, mas o custo para aquisição e implantação é muito elevado.
11 3 REQUISITOS DO SOFTWARE A SER DESENVOLVIDO Os requisitos funcionais são: a) coleta de informações: o software servidor instalado nos computadores de rede deverá coletar informações de softwares instalados e enviá-las ao software cliente instalado em uma estação de gerência; b) armazenamento dos dados: o software cliente instalado na estação de gerência deverá armazenar os dados coletados no Registro do Windows em um servidor para futuras consultas em caso de perdas de dados na estação; c) notificação ao administrador: o software cliente deverá notificar o administrador com uma mensagem de alerta no console de administração ou por correio eletrônico quando houver mudanças de software em alguma estação da rede; d) relatórios: a estação de gerência deverá permitir ao administrador de rede gerar relatórios diversos com as informações coletadas no inventário, sendo possível gerar relatório de softwares instalados por computador, relatório de computadores por softwares e relatório de alterações de softwares por computador. Os requisitos não funcionais são: a) usabilidade: o software servidor deverá ser de fácil instalação, apenas copiando um arquivo executável no computador. O software cliente deverá ter uma interface amigável e intuitiva ao usuário, deverão ser usados ícones e menus para acessar as funcionalidades; b) software: o software servidor quanto o cliente deverão se comunicar utilizando o protocolo SMB e deverão funcionar em sistemas operacionais Windows 2000 e Windows XP.
12 4 CONSIDERAÇÕES FINAIS Será desenvolvido um software para coletar e disponibilizar os dados que se referem a software de cada estação ligada à rede para fins de auditoria, tomadas de decisão ou simplesmente para se saber a real situação do parque de computadores de uma instituição. O software proposto terá como objetivo auxiliar o administrador de rede a gerenciar, auditar e manter seguro os computadores conectados a rede, evitando o uso indevido de softwares não licenciados. O protocolo SMB será utilizado para implementar a comunicação entre os softwares cliente e servidor por ser um protocolo específico para compartilhamento de arquivos e comunicação entre computadores que já esta incorporado aos sistemas operacionais Windows. Este protocolo é muito flexível, podendo-se executar com ele quase tudo em um gerenciador de arquivos, é muito rápido e dinâmico não comprometendo o desempenho dos computadores e da própria rede. Todas as informações serão extraídas de dentro do Registro do Windows utilizando a classe tregistry e enviadas a console de gerenciamento utilizando o componente ALMailSlot. Este componente utiliza o protocolo SMB. Tanto o software servidor quanto o software cliente somente funcionarão em sistemas operacionais Windows 2000 e XP, não sendo possível instalar em sistemas operacionais Windows inferiores e Linux. A instalação do software poderá ser feita manualmente ou através de uma implementação no login de rede do usuário utilizando um roteiro, que executará toda vez que o usuário acessar um computador, garantindo assim que todos os computadores conectados à rede estejam com o aplicativo servidor instalado. Mesmo que o usuário venha a desinstalar o software, no próximo login será instalado novamente. Em relação ao trabalho do Oliveira Junior (2005), o software proposto neste TCC deverá suprir a falta de inventários de softwares instalados, armazenamento de todas as informações coletadas nos computadores em um banco de dados MySQL e a falta de relatórios com as informações coletas. Já em relação aos trabalhos correlatos apresentados, pode-se afirmar que o software proposto irá possuir algumas características encontradas nos softwares citados. Como consulta de softwares instalados nos computadores em tempo real e relatório de softwares instalados por computadores. A principal diferença será a utilização de protocolo SMB para comunicação entre servidor e cliente e será um software livre sem custo de aquisição.
13 REFERÊNCIAS BIBLIOGRÁFICAS BORLAND SOFTWARE CORPORATION. Delphi enterprise: help Version 5.1. [S.l.], 2002. documento eletrônico disponibilizado com o Ambiente Delphi 7.0. DATAPREV. CACIC : Configurador Automático e Coletor de Informações Computacionais. [S.l.], [2005?]. Disponível em: <http://guialivre.governoeletronico.gov.br/cacic/sisp2>. Acesso em: 26 ago. 2006. DIGICRAGT SOFTWARE. Delphi components. [S.l.], 2005. Disponível em: http://www.digicraft.com.au/delphi>. Acesso em: 26 ago. 2006. IVIRTUA SOLUTIONS. Trauma zer0. Montenegro, [2006?]. Disponível em: <http://www.traumazero.com.br/index.php?conteudo=solutions&pg=dif>. Acesso em: 26 ago. 2006. MICROSOFT CORPORATION. About Mailslots. [S.l.], [2001?]. Disponível em: < http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/base/about_mailslots.asp >. Acesso em: 27 out. 2006. MICROSOFT CORPORATION. Descrição do Registro do Microsoft Windows. [S.l.], 2005. Disponível em: <http://support.microsoft.com/kb/256986 >. Acesso em: 26 ago. 2006. OLIVEIRA JUNIOR, E. N. Protótipo de software para gerência de patrimônios de equipamentos de uma rede utilizando session message block. 2005. 52 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau. PÉRICAS, F. A. Redes de computadores: conceitos e a arquitetura internet. Blumenau: EdiFURB, 2003. 158 p. SAMBA. Just what is SMB?. [S.l.], 2002. Disponível em: <http://samba.anu.edu.au/cifs/docs/what-is-smb.html>. Acesso em: 26 ago. 2006. WINGUIDES NETWORK FOR WINDOWS. Registry guide for Windows. [S.l.], 2006. Disponível em: <http://www.winguides.com/article.php?id=1&guide=registry>. Acesso em: 26 ago. 2006.