Prezados Mafra, Daniel, Ricardo e demais amigos da Lista. Tenho acompanhado esta saud�vel discuss�o sobre defini��es de Ativos (Assets). E muito me alegrei ao ver o site do RFC (http://rfc.sunsite.dk) meu conhecido de longa data.
Atentando ao inicio da discuss�o, sugiro a leitura da RFC 1244 (http://rfc.sunsite.dk/rfc/rfc1244.html). No item 2.2.2 detalha-se a defini��o do que � necess�rio identificar e compor em CI (Assets) e a abordagem que deve se ter aos itens. Os nomes de servidores s�o um destes alertas e recomenda��es na RFC 1178 (http://rfc.sunsite.dk/rfc/rfc1178.html). Sugiro verificar no Complemento da RFC 1244 � a RFC 2196 (http://rfc.sunsite.dk/rfc/rfc2196.html). No item 3 temos a arquitetura a ser adotada e uma seq��ncia de sugest�es e alertas do que se deve fazer e o que evitar. Sugiro criar um Hand Book para os usu�rios internos como o sugerido no RFC 2504 (http://rfc.sunsite.dk/rfc/rfc2504.html). Quanto aos Ativos, provavelmente estariam sendo referenciados a um banco de dados contendo as informa��es a serem monitoradas e mantidas em atualiza��o. Sugiro a leitura do conceito de MIBs (Management Information Base) para servidores RFC 2790 (http://rfc.sunsite.dk/rfc/rfc2790.html). E o entendimento dos SNMPs v3 para Networks e Devices RFC 3512 (http://rfc.sunsite.dk/rfc/rfc3512.html) para entender como funciona os processos automatizados de monitora��o e obten��o de informa��es de forma remota, automatizada e sist�mica para atualiza��o do banco de dados (CMDB). Espero ter ajudado e colocado mais informa��es a disposi��o dos colegas de lista. Espero com isso aumentar as discuss�es de forma construtiva. Abra�os Nysten Andrade de Macedo -----Mensagem original----- De: [email protected] [mailto:[EMAIL PROTECTED] Em nome de Ricardo Mansur Enviada em: quarta-feira, 18 de maio de 2005 21:30 Para: [email protected] Assunto: Re: [itsm_br] Ativos Prezado Daniel, Quando me referi a informa��es p�blicas estava falando da rede privada de uma empresa e n�o sobre informa��es sobre invas�es, que vc est� absolutamente certo em falar que elas est�o disponiveis em varios lugares. Em particular em todas as implanta��es que participei tanto o firewall como os roteadores de borda bloqueavam protocolos de respostas � requisi��es de nomes e ips da rede interna, ou seja para o mundo exterior a �nica m�quina visivel da rede era o firewall e roteadores que tinham ips de internet v�lido. O segundo n�vel de firewall, em geral chamado de bastian ( ou algo pareceido, n�o me lembro do nome de cabe�a ), que faz a interface entre uma rede do tipo 192, 168 ou 172 ou outras ( redes que n�o roteaveis pela internet ) e a rede intena, impedia com mecanismos de regras, filtros, etc que os ips e nomes internos sejam visiveis em quaisquer redes p�blicas como internet, mpls, frame relay, etc. Na minha opini�o a melhor solu��o � aquela que resolve o seu problema, e se a RFC + CMDB resolveu o do seu banco e muito provavelmente de outros bancos e outras empresas eu n�o d�vidas que � uma caso que deve ser publicado dentro do poss�vel, como vc fez, e estar � disposi��o de todos n�s. Na realidade o modelo que eu proponho e uso na maioria dos casos n�o � uma verdade absoluta, mas sim um modelo para ser conhecido ( alias n�o � cria��o minha ) por todos n�s e quem sabe podendo resolver um ou outro problema do mercado. Abaixo segue um trecho da RFC que vc usou e eu tb em diversos momentos, no que se refere ao que eu considero � ess�ncia dela, apenas lembrando o que � um nome f�cil para a minha empresa pode n�o ser para a sua e assim sucessivamente. Na minha vis�o mais do que falamos que a solu��o A, B ou C � a melhor devemos assumir que todas elas resolvem os problemas de uma forma ou de outra e que a oportunidade de conhecer o seu modelo para mim � uma oportunidade �nica e importante. _______________________________________________________________ RFC 1178 http://rfc.sunsite.dk Most people don't have the opportunity to name more than one or two computers, while site administrators name large numbers of them. By choosing a name wisely, both user and administrator will have an easier time of remembering, discussing and typing the names of their computers. Ricardo Mansur Gestor Tecnologia Carreira desenvolvida na gest�o das �reas de TI / Telecom. MBA em TI / Telecom e Neg�cios da Era Digital, mestrado em Finan�as e Administra��o e Engenheiro Eletr�nico. Ingles, Franc�s e Espanhol. [EMAIL PROTECTED] ----- Original Message ----- From: Daniel Checchia To: [email protected] Sent: Wednesday, May 18, 2005 10:33 AM Subject: Re: [itsm_br] Ativos Neste ponto sou obrigado a discordar parcialmente :-) Hoje o acesso � informa��o est� em v�rias revistas e na internet, possibilitando que um usu�rio de sua rede interna explore vulnerabilidades e o padr�o de nomes adotado facilita a identifica��o do servi�o que est� rodando no equipamento. Atuo em uma Institui��o financeira como coordenador de infra-estrutura e redes, sendo o respons�vel pela seguran�a de meus ativos. Para solucionar o problema de identifica��o de servidores, partimos para a montagem de um CMDB via WEB, com v�rios �ndices de busca poss�vel e padronizamos os nomes das m�quinas seguindo a RFC 1178. Esta RFC � usada, hoje, por muitas empresas, provedores de internet e Bancos, sendo (no meu ponto de vista) a solu��o ideal (RFC + CMDB). A segunda atua��o foi a segrega��o da rede com firewall interno, segregando fisicamente os ambientes de produ��o, homologa��o, desenvolvimento e os usu�rios. Cada um com seu pr�prio barramento de rede no firewall. Cordialmente, Daniel Checchia Em 16/05/05, Ricardo Mansur <[EMAIL PROTECTED]> escreveu: > > Prezado Wagner Elias, > > Em particular eu n�o creio que os nomes de servidores sejam uma > vulnerabilidade releveante, uma que que as informa��es n�o s�o publicas e > portanto os filtros nos roteadores de borda seriam os meios eficientes para > n�o divulgar os pacotes com nomes em redes p�blicas, alias qualquer que seja > o nome estes filtros devem existir. > > Se por ventura um hacker invadir uma rede � porque existem falhas de > vulnerabilidade muito maiores e graves do que nomenclaturas de nomes, > quaisquer que elas sejam. > [Non-text portions of this message have been removed] ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++ Lista ITSM_BR - Gest�o de TI - Mantida e moderada por Gilberto Biasoto - IT Designers - http://www.ITdesigners.com.br - ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++ Para de descadastrar envie email para: [EMAIL PROTECTED] --- ---------------------------------------------------------------------------- -- Yahoo! Groups Links a.. To visit your group on the web, go to: http://groups.yahoo.com/group/itsm_br/ b.. To unsubscribe from this group, send an email to: [EMAIL PROTECTED] c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. [Non-text portions of this message have been removed] ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++ Lista ITSM_BR - Gest�o de TI - Mantida e moderada por Gilberto Biasoto - IT Designers - http://www.ITdesigners.com.br - ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++ Para de descadastrar envie email para: [EMAIL PROTECTED] --- Yahoo! Groups Links [Non-text portions of this message have been removed] ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Lista ITSM_BR - Gest�o de TI - Mantida e moderada por Gilberto Biasoto - IT Designers - http://www.ITdesigners.com.br - ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Para de descadastrar envie email para: [EMAIL PROTECTED] --- Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/itsm_br/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
