Plano de Contingência – ITIL V2 e ISO NBR 17799

AGRADEÇA AO AUTOR COMPARTILHE!

O plano de contingência é produto gerado pelo gerenciamento de continuidade proposto pelo framework ITIL V2. Segundo a norma NBR ISO/IEC 17799 (2005, p. 104): “Convém que os planos sejam desenvolvidos e implementados para a manutenção ou recuperação das operações e para assegurar a disponibilidade da informação no nível requerido e na escala de tempo requerida, após a ocorrência de interrupções ou falhas dos processos críticos do negócio.”

O plano deve esquematizar as ações que serão tomadas para propiciar a continuidade dos serviços essenciais de TI em casos onde as políticas de segurança não foram suficientes para evitar o dano, de forma que a empresa mantenha o mínimo de suas operações em funcionamento. SÊMOLA (2003) afirma que a maioria das empresas entra em colapso muito rapidamente após um desastre no seu ambiente de processamento de dados. Daí a necessidade de manter-se preparado para uma emergência.

CARUSO & STEFFEN apud WEIGHTS (2006) recomenda a adoção de alguns passos para a elaboração do plano de contingência:

  1. Formação da equipe de planejamento: Deve-se montar uma equipe com representantes das áreas críticas da empresa, as quais não poderiam deixar de funcionar em caso de desastre.
  2. Avaliação das atividades críticas: Fazendo uso da análise de impactos, a equipe irá fazer um levantamento dos processos críticos do negócio. Neste ponto, podem-se fazer acordos administrativos entre os departamentos da empresa para que facilite o processo de contingência e menos recursos sejam gastos.
  3. Lista do pessoal necessário: É elaborada uma relação com os nomes, endereços e telefones de todo o pessoal essencial para a execução do plano.
  4. Equipamentos necessários: Com base nos processos prioritários deve-se dimensionar os equipamentos necessários.
  5. Dados, Software e documentação: Deve-se tomar providências para manter disponível em caso de emergência, toda a documentação e softwares necessários para a restauração dos sistemas.
  6. Alternativas de coleta de dados e distribuição de saídas: Em caso de emergência a emissão de relatórios e outras saídas podem ser alteradas devido as condições do processamento dos dados. Por isso, deve-se criar alternativas para essas ações.
  7. Acordos de backup em locais alternativos: Nesta etapa será escolhido o local alternativo para a restauração de toda a estrutura física de processamento. Muitas empresas criam acordos de reciprocidade com outras empresas, ou optam por ter sua própria área de restauração alternativa.
  8. Manuais de contingência: Todos os procedimentos devem ser registrados rigorosamente e mantidos ao alcance das pessoas responsáveis. Deve-se tomar cuidado com a confidencialidade desse material, pois como conta com informações críticas, este pode servir de guia para sabotagens.
  9. Testes de contingência periódicos: Na realização dos testes de contingência todos os procedimentos são executados a fim de verificar a sua eficácia. CARUSO & STEFFEN (2006) afirmam que é na realização dos testes que costuma-se encontrar os pontos fracos do plano de contingência.

De nada valem os conceitos contidos no plano de contingência, se a empresa não souber identificar corretamente as suas necessidades. (SÊMOLA, 2003). E acima de tudo, saber prever formas de contornar os possíveis problemas. Para CARUSO & STEFFEN (2006, p. 334) “a vulnerabilidade do centro de processamento de dados pode ser a vulnerabilidade da própria empresa e a sua destruição pode equivaler ao fim da própria organização”.

Abraços! Até a próxima…

Referência: http://julianrigo.spaces.live.com/blog/cns!80EC9EC681FB1D0F!1602.entry

AGRADEÇA AO AUTOR COMPARTILHE!

Julian Rigo

Mais artigos deste autor »

Analista de TI, Professor, Bacharel em Ciência da Computação, MBA em Gestão de Redes, ITIL Foundation V2, Microsoft Certified Professional em Windows Server 2003.
Blog: http://julianrigo.spaces.live.com/


3 Comentários

Luiz Agostinho
1

Ótimo artigo! Tratando a contingência com a importância que deve ser exigida em casos de desastre. Em muitos casos o plano só é discutido após um desastre e, em vários casos, esquecido logo após a recuperação do ambiente!

Abraço!

Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">