Acho que um site que pode agregar, principalmente no quesito documenta��o (um passo depois da defini��o do CI) � o www.NetworkDNA.org<http://www.NetworkDNA.org> .
Este pessoal est� criando um Framework para documenta��o, com uma estrutura de dados e todos modelos em .DOC para o trabalho. SDS Em 19/05/05, Nysten Andrade de Macedo <[EMAIL PROTECTED]> escreveu: > > 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 > > > > > [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/
