Prezado Nysten Andrade de Macedo,

Achei bem interessante ter condensado varias informa��es em um un�co e-mail



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: Nysten Andrade de Macedo 
  To: [email protected] 
  Sent: Thursday, May 19, 2005 11:43 AM
  Subject: RES: [itsm_br] Ativos


  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

    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

<*> 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/
 


Responder a