universidade candido mendes pÓs-graduaÇÃo … · 2001 as torres gêmeas do world trade center de...
TRANSCRIPT
UNIVERSIDADE CANDIDO MENDES
PÓS-GRADUAÇÃO “LATO SENSU”
PROJETO A VEZ DO MESTRE
RECUPERAÇÃO DE DADOS DE TI APÓS GRANDES
CATÁSTROFES
Por: Claudio Roberto de Oliveira França
Orientador
Professora Fabiane Muniz Silva
Rio de Janeiro
2008
2
UNIVERSIDADE CANDIDO MENDES
PÓS-GRADUAÇÃO “LATO SENSU”
PROJETO A VEZ DO MESTRE
RECUPERAÇÃO DE DADOS DE TI APÓS GRANDES
CATÁSTROFES
Este trabalho tem por finalidade mostrar a
importância de um Plano de Recuperação de
Desastres em Tecnologia da Informação
envolvendo: Alta Disponibilidade, tornando-se
essencial a utilização de uma boa política com
QUALIDADE. O seu impacto na esfera social,
econômica e cultural, tem envolvido situações sem
precedentes e que serão discutidas nesse projeto.
Por: Claudio Roberto de Oliveira França.
3
AGRADECIMENTOS
A Minha esposa filhos e aos amigos
que incentivaram e apoiaram minha
jornada durante este último ano e
também a todos os Inkíces que sempre
iluminaram o meu caminho.
4
DEDICATÓRIA
A minha Esposa que abriu mão das noites
de aula para que eu alcançasse o meu
objetivo, um enorme abraço nos meus
filhos: Felipe, Jessyca e Vini.
5
RESUMO
No mundo digital dos dias atuais, a tecnologia de informação (TI) adquiriu
status de componente essencial para prover produtividade no desempenho
das funções cotidianas executadas em uma organização. A informação, em si,
constitui valioso patrimônio e sua integridade e disponibilidade são fatores
cada vez mais críticos (ISO9001: 2000) que determinam a sobrevivência de
uma empresa em um ambiente de alta produtividade e competitividade.
Devemos refletir sobre o grau de prontidão existente em suas organizações
para situações de contingência, considerando-se o nível de dependência por
elas apresentado em relação a sistemas de informação como componentes
requeridos para a plena consecução de sua missão ou atividade-fim. Com
respeito a aspectos de segurança da informação relacionado ao planejamento
de contingências e procedimentos de recuperação dos sistemas para a
continuidade dos negócios. A diversidade de soluções para suporte aos
sistemas de informação requer o adequado planejamento das atividades de
proteção e recuperação dos recursos identificados como vitais para a
organização e os resultados de tal tarefa dependem da eficiência do trabalho
cooperativo de Executivos, Gerentes de Informação, Desenvolvedores de
Aplicação, Administradores de Rede e de Base de Dados.
6
METODOLOGIA
O procedimento metodológico foi elaborado a partir de pesquisa bibliográfica
pertinente ao tema, sendo consultados os principais livros sobre Disaster
Recovery e Planos de Continuidade de Negócios disponíveis no mundo
tecnológico, foram coletadas informações sobre o atentado de 11 de Setembro
de 2001, onde sem sombra de dúvida foi um marco para toda comunidade de
TI, a idéia desta pesquisa nasceu durante as aulas de ISO-9001, onde
comecei a vislumbrar que toda aquela metodologia de revisão de normas e
modelos, sistemas de arquivamento, documentação etc.; onde a ISO-9001
está fundamentada, serviu de exemplo para elaboração desta monografia.
7
SUMÁRIO
INTRODUÇÃO 08
CAPÍTULO I - Objetivos de um DRP 09
CAPÍTULO II - Estrutura Organizacional de um DRP 21
CAPÍTULO III - Recursos necessários a um DRP 24
CHECKLIST BASICO 32
CONCLUSÃO 34
BIBLIOGRAFIA CONSULTADA 36
BIBLIOGRAFIA CITADA 37
ÍNDICE 38
FOLHA DE AVALIAÇÃO 39
8
INTRODUÇÃO
O principal objetivo de um plano de continuidade de negócios (BCP – Business
Continuity Plan) é garantir a operação da empresa com o mínimo impacto aos
clientes em situações de contingência. No atentado de 11 de setembro de
2001 as Torres Gêmeas do World Trade Center de Nova Iorque, as empresas
que tinham BCPs bem estruturados reiniciaram suas operações poucas horas
depois do atentado terrorista.
Algumas empresas subestimam os riscos de um desastre e não investem em
BCPs. Os planos de continuidade de negócios podem ser classificados em
dois tipos: os Planos de Continuidade das áreas de negócios e os Planos de
Recuperação de Desastres (DRP – Disaster Recovery Plan) do Centro de
Processamento de Dados.
Em muitos casos as áreas de negócios das empresas dependem fortemente
do processamento de dados para suas atividades e uma paralisação do
processamento pára o negócio da empresa. Um exemplo foi a paralisação do
serviço de e-mail do provedor de Internet Terra por dois dias devido a um
problema no subsistema de armazenamento de dados, em abril de 2003. O
site Terra teve que abonar dois dias da mensalidade dos seus 800 mil
assinantes com um prejuízo de mais de R$400 mil.
Por essa razão as empresas investem em planos de recuperação de desastre
(DRP) e não em planos de continuidade em suas áreas de negócios. Talvez,
as exceções sejam as instituições financeiras que são mais sensíveis às
paralisações de negócios motivadas por greves e blecautes de energia.
9
CAPÍTULO I
OBJETIVOS DO DISASTER RECOVERY PLAN
(PLANO DE RECUPERAÇÃO DO NEGÓCIO)
Passado o ataque terrorista de 11 de setembro, pode-se dizer com certeza que
a tragédia mudou não apenas a vida dos norte-americanos, a economia
mundial e o próprio caminho da história, como também a forma como as
empresas passaram a lidar com a segurança de suas informações
estratégicas.
Logo após o atentado, vimos, lemos e ouvimos dezenas de histórias sobre
empresas que mantinham matrizes ou escritórios no World Trade Center e
simplesmente desapareceram. Na verdade, mais do que desaparecer
fisicamente, algumas companhias perderam sua identidade intelectual, uma
vez que concentravam todos os dados na estrutura que foi destruída no
atentado. Isso ocorreu porque muitas delas não tinham políticas de segurança
ou back-up implementadas. Por outro lado, boa parte das empresas sediadas
no local continuou suas operações, suportada por planos de contingência e
estratégias eficazes de ‘disaster recovery’, ou recuperação de desastres.
Desta forma, nos dias de hoje discutir e programar políticas de segurança das
informações se tornou fundamental para garantir a própria sobrevivência das
companhias. Afinal, ter um plano de continuidade de negócios para os
acidentes ou incidentes de percurso, passou a figurar como uma prioridade na
agenda dos executivos de tecnologia. Um bom exemplo desta mudança de
comportamento foi constatado em pesquisa recentemente divulgada pela
publicação norte-americana Information Week, realizada em parceria com a
consultoria Price Waterhouse Coppers junto a empresas em todo o mundo.
Após o ataque terrorista, cerca de 60% delas criaram ou atualizaram seus
planos de recuperação de desastres e continuidade dos negócios. A pesquisa
envolveu mais de oito mil empresas no mundo inteiro, sendo que 134 delas
com operações no Brasil.
10
O estudo deixa claro que na atualidade segurança de sistemas e informações
se tornou um business issue, isto é, um assunto estratégico para as
companhias, por meio do estabelecimento de políticas de controle de acesso,
redução de vulnerabilidades, tolerância a falhas, armazenamento de dados e
back-up. E as cifras previstas de investimentos corroboram a tendência. De
acordo com o Instituto Dataquest, somente o mercado de soluções de storage,
ou armazenamento e back-up de dados, deve pular de US$ 6,6 bilhões, em
2001, para 16,7 bilhões, em 2005. O instituto norte-americano Giga Group
segue pela mesma linha e aponta que os investimentos das companhias em
segurança de informações devem crescer entre 50% e 60% em todo o mundo
nos próximos três anos.
Um desafio para as organizações é unir a segurança física com a denominada
segurança lógica, ou seja, não só a segurança dos ativos físicos e humanos,
mas a integração aos projetos de segurança do capital intelectual, que é o
verdadeiro diferencial competitivo. Para isso, há um caminho que já está sendo
trilhado, inclusive por setores que não demonstravam preocupações com
planos de continuidade de negócios, mas que após o desastre de 11 de
setembro, “acordaram” para uma nova realidade. Este complicado cenário
serviu como catalisador para novos investimentos em infra-estrutura de
contingência entre companhias dos segmentos de Telecomunicações,
Finanças e Governo, principalmente.
É claro que a implantação de uma política de segurança não é realizada da
noite para o dia e é fundamental que ela esteja alinhada a um plano de
contingência. Começar pelos maiores riscos é o primeiro passo, verificando
onde estão as brechas e onde os prejuízos podem ser maiores. Uma dica é
avaliar os processos críticos e os ativos internos, que podem sanar grande
parte das dúvidas sobre o que realmente deve ser feito e onde devem se
alocar os recursos.
Tendo listado os problemas e prioridades, o próximo passo é a aquisição de
ferramentas, que envolvem hardware e software. A política de segurança deve
ser avaliada continuamente em busca dos pontos ainda vulneráveis, por meio
de soluções de monitoramento e desempenho. Esta é uma boa dica para evitar
11
dores de cabeça na hora da real necessidade, afinal a maioria das empresas
hoje necessita de disponibilidade total de seus sistemas e acesso direto aos
seus dados. Imagine, por exemplo, uma empresa de Call Center que fique
“fora do ar” por um período, por falta de um plano de continuidade de negócios.
Isto afetará o principal ativo da companhia, que é a sua credibilidade, sem
contar a má – impressão causada aos clientes irritados com a indisponibilidade
do serviço. O efeito disso para qualquer empresa é péssimo.
Na verdade, a eficácia de uma política de segurança de informações e
sistemas está diretamente atrelada ao nível de conscientização de cada
funcionário da organização. Afinal, felizmente, os atentados mais comuns às
empresas em nosso dia a dia são os vírus, os cavalos de tróia, as invasões de
hackers e o acesso de pessoas não habilitadas a dados estratégicos, e não
semelhantes ao que marcou o fatídico dia 11 de setembro de 2001(Mattos,
Marcio – 2003).
De acordo com as boas praticas informadas no DRII (2003) “Professional
Practices for Business Continuity Planners”, Disaster Recovery International
Institute.
O objetivo preliminar de um plano de recuperação de desastre (DRP) é permitir
que uma organização sobreviva a um desastre e que possa restabelecer as
operações dos negócios. A fim de sobreviver as empresas devem assegurar
que as operações críticas possam recomeçar o processamento normal dentro
de um espaço de tempo razoável. Para atingir esses objetivos o DRP deve
atender os seguintes requisitos:
• Prover um ambiente seguro e pessoas preparadas para um desastre;
• Reduzir as perdas financeiras em casos de desastres;
• Identificar linhas de negócios críticas que requeiram suporte em situações
de desastres;
• Identificar as fraquezas e executar um programa da prevenção de desastre;
• Minimizar a duração de uma paralisação das operações de negócio;
• Facilitar a coordenação eficaz de tarefas da recuperação; e,
• Reduzir a complexidade do esforço de recuperação.
12
Para se alcançar o nível pretendido de proteção à informação – entendida
como um patrimônio ativo da organização torna-se imprescindível estabelecer
uma política organizacional de segurança. Mesmo em pequenas empresas,
onde a complexidade sistêmica pode, às vezes, induzir à equivocada
conclusão de que o planejamento é desnecessário, é fundamental definir
procedimentos de segurança (aí incluídos aqueles relativos à contingência e
recuperação) que, uma vez estabelecidos, sejam divulgados para todos os
integrantes da organização. A tarefa de definição da política de segurança
organizacional constitui uma das principais etapas do chamado ciclo de
segurança, como ilustrado pela Figura 1 fonte DRII (2003).
O desenvolvimento de um DRP envolve a criação de uma "planta de
recuperação" para restaurar os recursos computacionais com as funções vitais
de processamento de dados para atender as necessidades dos negócios da
empresa. O plano deve procurar restabelecer o ambiente de processamento
no menor tempo possível a fim de evitar um efeito catastrófico nos negócios. O
desenvolvimento de uma estratégia viável de recuperação não deve ser uma
iniciativa exclusiva da área de processamento de dados, mas de toda a
organização para proteger os interesses da empresa.
Para atender esse objetivo deve se adotar uma metodologia que enfatize os
seguintes pontos chaves:
13
Fornecer a gerência uma compreensão detalhada do esforço total requerido
para tornar e manter uma planta de recuperação eficaz;
Obter o compromisso da gerência apropriada para suportar e participar no
esforço de recuperação;
Definir as exigências de recuperação na perspectiva do negócio;
Documentar o impacto de uma perda prolongada às operações e ao negócio;
Selecionar as equipes do DRP para testes, atualizar e assegurar uma
execução eficaz do plano;
Desenvolver uma "planta de recuperação" que seja compreensível, fácil de
usar e manter;
Definir como as premissas do DRP devem ser integradas aos processos de
negócio para uma recuperação no tempo necessário para não haver ruptura
nos processos de negócios
Para se atingir um planejamento eficaz é necessário que o pessoal sênior de
sistemas de informação e das áreas de negócios esteja envolvido durante todo
o projeto para o beneficio da organização.
O planejamento do DRP deve prever as seguintes etapas:
Fase 1 – Pré-planejamento das atividades
Fase 2 – Avaliação da vulnerabilidade e definição das exigências do projeto
Fase 3 – Avaliação de impacto no negócio
Fase 4 – Definição detalhada das exigências
Fase 5 – Desenvolvimento do plano
Fase 6 – Plano de teste / simulação
Fase 7 – Programa de manutenção
Fase 8 – Testes iniciais e implementação
1) Fase 1 – Pré-planejamento das atividades
Essa fase determina as necessidades iniciais do projeto com base em
informações sobre os requerimentos de processamento de dados para as
14
funções criticas da empresa. Isso permite a equipe refinar o escopo de
trabalho e identificar os aspectos críticos para o sucesso do projeto.
Durante esta fase o comitê executivo do projeto (Steering Committee) deve ser
estabelecido. O comitê tem a responsabilidade total para fornecer o sentido e a
orientação à equipe do projeto. O comitê deve também tomar todas as
decisões relacionadas ao esforço de planejamento do DRP. O gerente de
projeto deve trabalhar com o comitê para finalizar o planejamento detalhado e
desenvolver entrevistas para avaliar a segurança e elaborar a análise de
impacto no negócio.
Outros dois aspectos chaves desta fase são: o desenvolvimento de uma
política para suportar os programas da recuperação; e um programa para
educar a gerência e as pessoas-chave do projeto nas atividades que lhes
serão atribuídas.
2) Fase 2 – Avaliação da vulnerabilidade e definição das
exigências do projeto
Como diz o ditado é melhor evitar que remediar. Essa fase analisa as
vulnerabilidades do ambiente de processamento e avalia as possibilidades de
ocorrência de um desastre. Essa análise deve conduzir medidas para reduzir a
probabilidade de desastre.
Esta fase incluirá as seguintes tarefas chaves:
Uma avaliação completa da segurança do ambiente de processamento de
dados e do ambiente das comunicações, incluindo:
Pessoal;
Segurança física;
Procedimentos operacionais;
Planejamento de apoio e de contingência;
Desenvolvimento e manutenção dos sistemas;
Segurança das bases de dados;
Segurança de comunicações dos dados e voz;
15
Sistemas e segurança do software de controle do acesso;
Apólices de seguro;
Planejamento e administração da segurança;
Controles da aplicação;
Computadores pessoais.
A avaliação da segurança permitirá a equipe de projeto melhorar os
procedimentos de emergência existentes e medidas de prevenção de
desastres.
Recomendações de atividades sobre a segurança devem ser encaminhadas
ao comitê executivo de modo que as ações corretivas possam ser iniciadas em
um momento oportuno.
Definição do esforço do planejamento.
Análise, recomendação e compra de um software para a manutenção e
controle permanente do DRP.
Desenvolvimento da estrutura da "planta de recuperação".
Montagem da equipe do projeto.
3) Fase 3 – Avaliação de Impacto no Negócio
Nessa fase é realizada uma avaliação de impacto nos negócios de todas as
unidades da empresa para identificar os sistemas, processos e funções
críticas. Essa análise de impacto econômico deve avaliar a negação de acesso
aos serviços de sistemas e outros serviços e facilidades. Deve-se definir
também qual o máximo tempo de sobrevivência do negócio sem acesso aos
sistemas.
O relatório de avaliação de impacto deve ser apresentado ao comitê executivo.
Esse relatório identifica as funções críticas dos serviços e os tempos que
devem ser recuperados os sistemas em caso de desastre. As informações são
usadas como base para definir os recursos necessários para suportar os
serviços críticos.
A etapa inicial do ciclo corresponde a uma análise de riscos e ameaças
(usualmente, denominada Business Impact Analysis – BIA), onde são
16
estudadas criteriosamente as potenciais exposições às quais a informação
pode estar submetida, considerando-se a probabilidade de ocorrência de
situações de prejuízo. Deve-se determinar o nível aceitável para os controles
de segurança, custos de implantação e também o risco admitido para as
condições que não forem completamente cobertas, procurando-se avaliar o
impacto da perda de informações classificadas como sensíveis e quantificá-lo,
quando possível, em termos de dias de paralisação e prejuízo financeiro total.
Antes do surgimento da Internet e da tecnologia de redes, a questão da
administração da segurança e proteção da informação apresentava um perfil
notadamente centralizado, focado em programas normalmente executados em
mainframes e instalações com arranjo típico de CPD (centro de processamento
de dados), onde se localizavam todos – ou, pelo menos, os mais críticos – os
recursos de TI necessários à atividade da organização. Os planos de
contingência surgiram para a proteção deste ambiente e tinham seu foco
direcionado particularmente às atividades de TI.
Com as facilidades de rede, os recursos disponibilizados pela Web e a quase
ubiqüidade de acessos remotos determinada pelas necessidades de certos
tipos de negócio, as organizações passaram a ser submetidas a um universo
de ameaças mais diversificado e a abordagem de segurança precisou de uma
abrangência mais ampla, de modo a dotar as empresas de mecanismos de
segurança capazes de identificar, proteger e recuperar dados vitais para o
domínio do negócio considerado, mantendo-os acessíveis para os sistemas de
informação. Os planos de contingência passaram, então, a abordar as tarefas
de recuperação tendo como foco não apenas as atividades de TI, mas também
variáveis diretamente associadas ao negócio da organização e aos requisitos
de continuidade necessários para sua sobrevivência em situação de desastre.
Pela definição do [DRII2003], um desastre é um evento que ocorre repentina e
inesperadamente, com significativas conseqüências de danos e perdas para
uma organização.
A Figura 2, fonte DRII (2003) mostra o relacionamento entre os principais
fatores de segurança que devem ser considerados em uma abordagem de TI.
17
Como se pode ver, os diferentes fatores estão ligados tanto a componentes de
hardware e software como a aspectos organizacionais e de recursos humanos.
Às ameaças, internas e externas, associadas aos fatores considerados na
Figura 2, fonte DRII (2003), podemos ainda acrescentar incidentes de
segurança como incêndios, alagamentos, interrupções no fornecimento de
energia e pane em serviços de comunicação e ar condicionado. Em função do
negócio da organização e do necessário suporte por parte do ambiente de TI,
as ameaças devem ser analisadas de forma conjugada com os riscos relativos
aos sistemas de informação, que podem resultar na perda ou adulteração da
informação e/ou indisponibilidade do serviço ou negócio.
O objetivo da análise de ameaças e riscos é buscar o equilíbrio inteligente
entre risco, eficiência e custo. E, por este motivo, a política e a cultura de
segurança é o ponto central para o desenho de qualquer solução, pois para
manter a segurança de uma organização e o grau de prontidão necessário
para reação em situação de real contingência é fundamental que seus
18
componentes estejam treinados e alinhados com os corretos procedimentos a
serem observados no trabalho diário.
4) Fase 4 – Definição detalhada das exigências
Durante essa fase o perfil das exigências do plano de recuperação é
desenvolvido usando como base o relatório de impacto no negócio. Devem ser
desenvolvidas estratégias alternativas de recuperação com o auxilio de uma
ferramenta para estruturar as informações, como a técnica da matriz de
alternativas. O planejamento deve contemplar:
Hardware (mainframe, servidores, comunicação de dados e voz, computadores
pessoais, impressoras, etc.)
Software (pacotes, desenvolvimentos in-house e desenvolvimento externo)
Documentação (processamento de dados, sistemas e usuários)
Provedores de serviços externos (telecomunicações, telefonia, web hosting,
etc.)
Facilidades (energia, escritórios, equipamentos de escritórios, etc.)
Pessoal.
As estratégias de recuperação devem completar planos de curto, médio e
longo prazo.
5) Fase 5 – Desenvolvimento do Plano
Nesta fase, os componentes das plantas de recuperação são definidos e as
plantas são documentadas. Esta fase inclui também a execução das
mudanças nos procedimentos dos usuários e a implementação de processos
para suportar as estratégias selecionadas para a recuperação e as alternativas
identificadas.
Devem ser formalizados os acordos contratuais com os fornecedores de
hardware, software e serviços para suportar o plano de recuperação. As
equipes de apoio ao plano de recuperação devem ser formadas e definidas
19
suas responsabilidades no plano. Os padrões de recuperação devem ser
consolidados nessa fase.
6) Fase 6 – Plano de Teste/Simulação
O programa de teste/simulação do DRP deve ser desenvolvido nessa fase. O
objetivo dos testes/simulações é validar o plano de recuperação e fazer os
ajustes necessários. Lembrando que os ambientes de negócios e
processamento de dados são dinâmicos, os planos de recuperação devem ser
constantemente revistos, atualizados e testados.
7) Fase 7 – Programa de Manutenção
A manutenção das plantas é fator critico de sucesso de uma recuperação real.
As plantas de recuperação devem refletir as mudanças nos ambientes reais. É
crítico que os processos existentes sejam revisados para fazer a manutenção
da planta de recuperação do cliente através do processo de gerência de
mudanças. Nas áreas onde a gerência de mudanças não existe, esse
procedimento deve ser implementado. Muitos produtos de software de
recuperação possuem a facilidade de gerência de mudanças.
8) Fase 8 – Testes Iniciais e Implementação
Uma vez o plano desenvolvido inicia-se a fase de implementação e testes.
Essa fase deve ser repetida no mínimo duas vezes por ano ou quando ocorrer
uma mudança significativa no ambiente de processamento de dados ou de
negócios.
As seguintes atividades devem ser realizadas:
Definição do escopo do teste;
Identificação das equipes de teste;
Estruturação do teste;
Condução do teste;
20
Análise dos resultados do teste; e,
Modificação dos planos de recuperação, se necessário.
O escopo do teste depende da estratégia de recuperação selecionada, o que
reflete os requerimentos de negócio da empresa. O plano de recuperação
desenvolvido deve ser escrito de forma que seja compreensível e fiel a
realidade da organização.
21
CAPITULO II
ESTRUTURA ORGANIZACIONAL DE UM DRP
A organização da equipe do projeto de recuperação deve ser flexível para
atender os requisitos desse tipo de atividade. A implementação, manutenção e
execução de um plano de recuperação exigem dedicação do pessoal e
trabalho sob pressão. Um fator crítico de sucesso é a criação de uma
organização dedicada para essa finalidade.
Os planos de recuperação devem ser tratados como documentos vivos. As
informações estão em constante processo de mudança e a cada dia tornam-se
mais integradas e complexas. Os planos de recuperação devem acompanhar
essas mudanças. Os planos de testes/simulações devem assegurar a
capacidade de recuperação do ambiente considerando as constantes
mudanças dos processos. A organização deve assegurar que a equipe do DRP
esteja sempre atualizada sobre as mudanças nos negócios.
A seguir é apresentado um modelo de organização para conduzir o plano de
recuperação, Buttler, Janet (1994):
1) Comitê Executivo
O comitê executivo deve incluir representantes das áreas chaves da
organização:
Sistemas de Informação;
Infra-estrutura de tecnologia da informação;
Desenvolvimento de Sistemas;
Redes de Comunicações de Dados;
Comunicação de Voz;
Unidades de Negócios.
22
2) Equipe do Projeto
Segundo Buttler, Janet (1994): A composição da equipe do projeto varia de
acordo com o ambiente tecnológico e de negócios onde os planos foram
desenvolvidos é importante notar que os gerentes dos ambientes tecnológicos
e das unidades de negócios são responsáveis pela manutenção e teste de
seus respectivos planos. Entretanto, o pessoal responsável pelo planejamento
da estratégia de recuperação deve ser o coordenador das atividades de teste,
revisão dos planos e manutenção do plano principal.
A Auditoria Interna deve ser convidada a fazer parte de todas as equipes. Os
gerentes representados nas diversas equipes devem recomendar pessoas
seniores para representá-los ou eles próprios participarem das equipes
contribuindo com sua experiência no desenvolvimento dos planos de
recuperação.
(2.1) Equipe Principal
Gerente do Projeto;
Especialista em operação de computadores e redes de dados;
Especialista em suporte de sistemas;
Especialista em suporte de voz, redes e telecomunicações.
(2.2) Equipe Técnica
Analista de redes;
Analista de infra-estrutura física;
Analista de banco de dados;
Analista de segurança;
Analista de operação;
§ Analista de suporte de rede;
23
(2.3) Equipe de Negócios
• Membros das diversas áreas de negócios que fazem parte do plano de recuperação.
24
CAPITULO III
RECURSOS NECESSÁRIOS PARA UM DRP
As empresas devem evitar implementar planos de recuperação sem uma
equipe e recursos dedicados para essa finalidade sob o risco de falharem após
altos investimentos. Uma das razões do fracasso de alguns planos é a falta de
comprometimento das equipes na manutenção e testes do plano de forma
continua o que resulta na perda da compatibilidade do plano de recuperação
com a realidade da empresa. Wold, G. H. (1997).
Para garantir o sucesso do plano de recuperação deve se investir em três
categorias:
(1) Pessoal
Os gerentes devem alocar profissionais experientes e competentes para
participar das equipes de recuperação.
(2) Investimento inicial
A empresa deve investir na compra de equipamentos redundantes nas áreas
de voz e comunicação de dados, processamento de dados (incluindo
servidores e subsistemas de armazenamento de dados), equipamentos
redundantes de geração de energia (UPS, geradores a diesel, etc.) e
equipamentos de apoio (fax, PCs, scanner, copiadoras, etc.).
(3) Despesas recorrentes
As despesas recorrentes incluem o aluguel de espaço para instalar os
computadores e outros equipamentos, contratos de serviços e manutenção.
Uma alternativa eficaz e que exige menos investimentos é a contratação de
uma empresa especializada em DRP, onde é possível contratar todos os
serviços de recuperação, desde o planejamento, manutenção e equipamentos.
25
PLANO DE CONTINGÊNCIA E RECUPERAÇÃO DE NEGÓCIOS
Segundo o ABNT NBR ISO/IEC 27001:2006, o plano de contingência e
recuperação de negócios para sistemas de informação insere-se na política de
segurança como instrumento de planejamento estratégico, constituindo o
documento que especifica procedimentos pré-estabelecidos, a serem
observados nas tarefas de recuperação do ambiente de sistemas e negócios,
de modo a minimizar o impacto nas atividades da organização ocasionado por
dano ou desastre que não puderam ser evitados pelas medidas de segurança
em vigor.
A fim de evitar esforços desnecessários, reduzir custos e tornar exeqüível um
plano de contingência, geralmente é contemplados pelo planejamento somente
os recursos identificados como essenciais para a continuidade da missão da
organização.
1. O Plano de Contingência e Recuperação de Negócios
1.1. Estrutura do Documento
O Plano de Contingência e Recuperação de Negócios (PCRN) deve ser
elaborado como um documento normativo, formalmente aprovado pela direção
da organização e amplamente divulgado, de modo que todos os funcionários e
integrantes da empresa estejam cientes dos procedimentos por ele
estabelecidos. Recomenda-se que o documento correspondente ao ato de
aprovação do plano seja inserido logo após a folha de rosto.
O PCRN descreve os procedimentos relativos ao ambiente de TI e à área de
negócios que devem ser adotados no caso de ocorrência de sinistro ou
impedimento relevante que venha a comprometer o funcionamento normal da
organização. As ações a serem encetadas para a recuperação das instalações
e sistemas e para a redução do impacto sobre as atividades da organização
têm como premissa a ocorrência de um dano ou desastre que comprometa a
execução dos serviços essenciais à sua missão.
26
Em uma situação real de contingência, convém ressaltar que todas as ações
decorrentes devem, em primeiro lugar, preservar a vida e a segurança dos
integrantes da organização e demais pessoas expostas a risco. Os
procedimentos descritos no plano compreendem ações a serem executadas
em três diferentes fases da situação de contingência:
• Ativação (deflagração) da contingência;
• Restauração das condições operacionais em ambiente alternativo; e
• Retorno à normalidade.
A estrutura desse documento deve contemplar os itens básicos a seguir
descritos.
a) Propósito do plano:
Este item deve estabelecer de forma clara qual o objetivo do documento e a
quem ele se destina.
b) Definições conceituais: como o documento não é restrito a profissional de
TI, é recomendável incluir um pequeno glossário com definições da
terminologia usualmente empregada em contingências (sinistro, desastre,
backup site, centro de operações, restauração etc).
c) Escopo: o plano deve definir com objetividade a abrangência da
contingência planejada e quais recursos estão cobertos pelos procedimentos
definidos no documento.
d) Equipes de trabalho: é importante registrar no plano como será efetuada a
divisão do trabalho em situação de contingência, observando-se as três fases
anteriormente citadas (ativação, restauração e retorno). Neste bloco, devem
constar os elementos e unidades organizacionais envolvidos na consecução do
plano e suas respectivas atribuições em cada fase.
e) Descrição do ambiente alternativo: dependendo da análise dos riscos e
ameaças, a solução de contingência adotada pode se resumir a procedimentos
de mirroring, com duplicação de dados, mas pode também definir o uso de um
27
CPD - alternativo em ambiente situado e configurado em alguma unidade
dentro da própria organização, mas normalmente fisicamente dela separada ou
ainda definir soluções hot ou cold-site, que utilizam recursos e ambientes
externos às instalações da organização, contratados especificamente para
este fim. A solução adotada deve ser detalhadamente descrita, incluindo-se
mapa de localização da instalação alternativa e eventuais contatos externos
contratuais, requeridos para a deflagração da contingência.
f) Planos decorrentes: em situações de contingência, um pequeno detalhe
pode, muitas vezes, transformar-se em óbice intransponível, se não tiver sido
devidamente contemplado no planejamento. Como subsídios para o Plano de
Contingência e Recuperação de Negócios, devem ser elaborados planos
decorrentes, contendo informações suficientemente detalhadas com relação a
aspectos específicos, como os mencionados na seção 1.2 deste artigo.
g) Informações complementares:
Devem ser anexadas ao plano todas as informações consideradas úteis para a
consecução dos procedimentos descritos. Como exemplo, podemos citar
algumas informações básicas, que, em um momento de desastre, tornam se
críticas caso não sejam localizadas a tempo: identificação e localização de
mídias para instalação de algum software que deva ser executado em
servidores de rede e/ou estações de trabalho; instruções específicas para a
ativação da contingência, que devem incluir, entre outras informações, a
indicação de um local de concentração para reunir as pessoas convocadas a
agir em qualquer uma das fases previstas no plano; e telefones de contato de
seguradoras e órgãos que devam ser acionados no momento seguinte à
ativação da contingência.
28
1.2. Planos Decorrentes
Como exemplos típicos de planos decorrentes, podemos mencionar os
documentos a seguir descritos, que podem compor o Plano de Contingência e
Recuperação de Negócios sob a forma de anexos.
Plano de Backups: deve fornecer a identificação e localização das cópias de
segurança, indicando os volumes e mídias a serem utilizados para a
restauração de arquivos e/ou bases de dados e a referência temporal
correspondente à informação assim recuperada.
Plano de Busca: provê, basicamente, a identificação das pessoas que devem
ser acionadas em situação de contingência, o grupo de contingência ao qual
pertencem e as formas de contato para sua localização.
Plano de Recuperação de Aplicativo: deve descrever procedimentos
específicos necessários para a recuperação de aplicativos residentes na
instalação da organização, enfatizando possíveis detalhes não incluídos na
recuperação global relativa ao ambiente operacional.
Plano Logístico: deve prever as providências necessárias para assegurar a
consecução do plano de contingência no que se refere à viabilização de
atividades não técnicas como, por exemplo: deslocamento do pessoal
convocado para as atividades de recuperação, tanto do ambiente de TI como
das instalações danificadas; atendimento a público externo (quando aplicável);
condições para alimentação e repouso das equipes envolvidas na recuperação
- que muitas vezes trabalharão em regime excepcional de horário -, guarda e
movimentação para instalação provisória de mobiliário, equipamentos e
documentação resgatados da instalação sinistrada.
29
1.3. Distribuição, Revisão e Arquivamento do PCRN
Todas as unidades organizacionais diretamente envolvidas nas atividades
descritas no Plano de Contingência e Recuperação de Negócios precisam
receber uma cópia do documento produzido.
Conforme novos recursos sejam incorporados à realidade operacional da
organização e à medida que funcionalidades sejam alteradas ou introduzidas
no ambiente de aplicação, o PCRN deve ser atualizado pelo setor associado a
tais mudanças, de modo a refletir a nova realidade. O componente da
organização responsável pelo planejamento global da contingência deve estar
atento ao grau de evolução dos ambientes, a fim de programar situações
significativas a serem testadas em exercícios de contingência periodicamente
executados.
Por medida de prevenção, pelo menos uma cópia do PCRN deve ser mantida
arquivada fora das dependências da organização, em local divulgado para as
equipes de contingência.
2. Estrutura Organizacional de Contingência
De acordo com Wickens, John (1989) - Contingency Planning: Anticipating
Disaster – V.3 existe uma subdivisão das responsabilidades, para a
consecução das atividades de planejamento, execução e manutenção do
Plano de Contingência, propõe-se uma estrutura que organiza indivíduos de
diferentes equipes em células denominadas Grupos de Contingência (GC),
responsáveis por atividades específicas. Esta estrutura é ativada apenas em
situações de contingência, inserindo-se no organograma da organização, de
modo que cada GC assim constituído fica subordinado a uma unidade
organizacional permanente.
2.1. Dividindo Responsabilidades
O PCRN deve explicitar as responsabilidades de cada Grupo de Contingência,
bem como aquelas atribuídas aos elementos que responderão pela
Coordenação Executiva e à Direção da organização. As responsabilidades são
categorizadas em responsabilidades permanentes (obrigatórias mesmo em
situação normal de operação, a fim de assegurar a prontidão) e
30
responsabilidades decorrentes de uma situação real de contingência
(aplicáveis a necessidades evidenciadas imediatamente após a ativação da
contingência, durante o período de recuperação dos danos provocados pelo
desastre e na fase de retorno à normalidade).
Como exemplo é relacionado a baixo algumas das responsabilidades
atribuídas ao GC de Suporte a Hardware e Software.
2.2 Responsabilidades do GC de Suporte a Hardware e Software
Responsabilidades Permanentes:
Participar ao GC de Logística e Apoio Administrativo as alterações relativas ao
Anexo I - Relação do Hardware sob Seguro, bem como manter atualizados os
dados cadastrais das empresas prestadoras de suporte técnico para sua
Manutenção;
Analisar e propor alternativas para a solução de contingência, recomendando,
se julgada conveniente, a redefinição dos requisitos relativos ao CPD
alternativo a ser utilizado;
Fazer refletir nos recursos definidos para contingência as atualizações de
software e hardware operacional eventualmente ocorridas nas instalações do
CPD e necessárias em situação de contingência;
Executar regularmente os procedimentos de salvaguarda para as cópias de
segurança de todos os softwares e arquivos componentes do Plano de
Recuperação, controlando e mantendo e estes backups de contingência fora
do CPD;
Manter a salvo, fora do CPD, documentação completa da configuração do
ambiente instalado (estrutura de catálogos, bancos de dados, bibliotecas,
recursos da rede de teleprocessamento, etc.);
Responsabilidades após a Ativação da Contingência:
Assim que informado da situação de contingência e acionado pelo Grupo de
COORDENAÇÃO EXECUTIVA, cada membro deste GC deverá comparecer
ao Centro de Operações para receber as instruções iniciais;
Executar as atividades definidas para restauração do ambiente operacional.
31
Responsabilidades durante o Período de Recuperação:
Executar os procedimentos para retirada das cópias de segurança
correspondentes à posição mais recente de todos os softwares e arquivos
componentes do Plano de Recuperação, armazenados fora do CPD;
Ativar o sistema operacional e os softwares de apoio no CPD alternativo;
Restaurar todos os arquivos e bases de dados e validar o acesso a eles;
Disponibilizar aos usuários o acesso, remoto e local, para utilização dos
aplicativos recuperados; Interagir com o GC de OPERAÇÕES DE RESCALDO
E SALVAMENTO na avaliação dos danos e possibilidade de recuperação dos
equipamentos danificados; Manter o GC de COORDENAÇÃO EXECUTIVA
informado do andamento das ações.
Responsabilidades no Retorno à Normalidade: Concluir todas as correções
e atividades programadas para execução dos processos vitais e comunicara
todos os envolvidos o início dos procedimentos de retorno; Providenciar as
cópias backup dos dados atualizados no CPD alternativo durante a
contingência e seu retorno ao site, nas novas instalações.
Apagar todos os registros e dados armazenados em discos, estações de
trabalho ou servidores utilizados no CPD alternativo como recurso de
processamento.
32
Checklist Básico
As perguntas elaboradas neste checklist foram elaboradas a partir de
[DRII2003], [ISO2000] e [IBM1999], com o propósito de auxiliar gestores e
profissionais de TI na avaliação preliminar do grau de prontidão de suas
organizações, com referência a situações de contingência.
1. Na hipótese de ocorrência de algum tipo de desastre ou interrupção
significativa na condição de funcionamento de sua organização (por exemplo,
incêndio ou interrupção continuada de energia), existem procedimentos
documentados na forma de planos de contingência e recuperação ? <SIM>
<NÃO>
2. Se a resposta para a questão 1 foi positiva, que tipos de cenários de
contingência estão previstos ?
3. Se a resposta para a questão 1 foi positiva, qual o limite máximo de tempo
(em termos de horas, dias, semanas, meses) admitido para inoperância de sua
organização em cada cenário previsto?
4. Se a resposta para a questão 1 foi positiva, o plano de contingência
estabelece prioridades distintas para atividades críticas, vitais à organização?
<SIM> <NÃO>
5. Se a resposta para a questão 4 foi positiva, qual o tempo máximo admitido
de inoperância para atividades classificadas como vitais?
<até 04 horas> <04-08 horas> <até 01 dia> <01-02 dias> <mais de 02 dias>
6. Se a resposta para a questão 1 foi positiva, o plano de sua organização
cobre alguns ou todos os locais onde são disponibilizados serviços (CPD, setor
de atendimento ao público externo, sala de servidores, etc)? <ALGUNS>
<TODOS>
7. O CPD ou sala de servidores de sua organização está localizado no mesmo
edifício ou complexo onde são realizadas as atividades de negócio? <SIM>
<NÃO>
33
8. Na hipótese de contingência, sua organização possui cópias de segurança
recentes salvas em um edifício diferente do complexo onde são realizadas as
atividades de negócios? <SIM> <NÃO>
9. Na hipótese de contingência, existem meios eficientes de localizar e
contactar as equipes a serem acionadas para recuperação do ambiente de
sistemas? <SIM> <NÃO>
10. Sua organização dispõe de um local alternativo previsto para fins de
recuperação dos sistemas de TI? <SIM> <NÃO>
11. Se a resposta para a questão 1 foi positiva, quantos testes do plano de
contingência sua organização efetuou até a presente data?
<nenhum> <apenas 01> <02-04> <05-10> <mais de 10>
12. Se a resposta para a questão 1 foi positiva, o plano prevê a participação de
integrantes das áreas de negócio de sua organização ou apenas dos
profissionais de TI?
<apenas TI> <TI e negócios>
13. Qual valor se aproximaria do prejuízo financeiro estimado para sua
organização caso fossem perdidos ou corrompidos os dados mantidos pelos
sistemas de informação?
<menos de 200K> <201-500K> <501-1000K> <mais de 1000K> <inestimável> K= R$
1.000,00
34
CONCLUSÕES
A tecnologia de informação se incorporou à rotina diária das organizações,
que, cada vez mais, exigem qualidade, integridade e disponibilidade de seus
dados. Para o quesito qualidade, a conduta normalmente observada para
assegurar a correta distribuição de tarefas consiste em conscientizar o usuário
(proprietário dos dados) - ou, ainda, o profissional nomeado como analista de
negócios – de que pertence a ele a parcela principal de responsabilidade pela
definição da informação com o grau de qualidade esperado. Contudo, quanto
aos aspectos integridade e disponibilidade, existem ainda algumas lacunas de
responsabilidade, com contornos indefinidos entre usuários e profissionais da
área de TI.
Independente do porte de uma aplicação é essencial que se tenha sempre em
mente a relevância da informação por ela mantida e os requisitos de
segurança que devem ser atendidos. Observa-se um impasse para definições
de segurança quando os proprietários dos dados – elementos normalmente
mais afetos às funções da camada de negócios - não são requisitados a
identificar quais informações são vitais para a atividade da empresa ou então
delegam tal responsabilidade para o setor de TI, que, geralmente, não se
encontra devidamente estruturado para responder por ela. A experiência
acumulada ao longo dos mais de quinze anos de profissão tem resultado em
crescente grau de refinamento e exatidão na análise das vulnerabilidades dos
sistemas de contingência. Podemos resumir as lições aprendidas até o
momento na forma das seguintes mensagens, destinadas a futuros
planejadores de contingência:
-A segurança e integridade das pessoas devem estar em primeiro lugar; sem o
conhecimento que elas possuem, a recuperação de todo o software ou
hardware de sua organização será inútil.
-O Plano de Contingência e Recuperação de Negócios (PCRN) deve ser
redigido e forma clara e objetiva e seu conteúdo devem ser amplamente
disseminados pela organização.
Obtenha o comprometimento da Direção e setores da área de negócios.
35
-Além das equipes de TI, obtenha a participação de integrantes dos setores de
negócios durante os exercícios de contingência.
-Reserve tempo suficiente para o planejamento das atividades relativas a cada
novo exercício, a fim de explorar a oportunidade e testar novas funcionalidades
ou atualizações ocorridas no ambiente operacional de sua organização.
-Divulgue os resultados dos exercícios de contingência realizados e demonstre
a evolução alcançada com cada teste, quanto à segurança e qualidade da
informação sob custódia.
-Assegure-se de que suas cópias de segurança (backups) para as informações
vitais estão sendo regularmente produzidas: programe um ou mais testes da
operação de restauração de arquivos ou bases de dados, de modo a evitar
surpresas desagradáveis.
-Estimule o trabalho cooperativo entre os integrantes dos Grupos de
Contingência e mantenha-os atualizados sobre as versões do PCRN.
36
BIBLIOGRAFIA CONSULTADA
ABNT NBR ISO/IEC 27002:2005 - Código de Prática para a Gestão da
Segurança da Informação
ABNT NBR ISO/IEC 27001:2006 Sistemas de Gestão de Segurança da
Informação - Requisitos
Serrano, Antônio (2001) - Disaster Recovery - Um Paradigma na Gestão da
Continuidade.
Buttler, Janet (1994) – Contingency Planning and Disaster Recovery Strategies
COBIT – Control Objectives for Information Technology, disponível em
http://www.isaca.org
Disaster Recovery Journal. IBM (1999) “Business Continuity: New Risks, New
Imperatives and a New Approach”, Report G510-1135-00.
DRII (2003) “Professional Practices for Business Continuity Planners”, Disaster
Recovery International Institute.
ITIL – Information Technology Infrastructure Library, disponível em
http://www.itsmf.org/qualifications.
PMP – Project Management Professional Certificate, disponível em
http://www.pmi.org/info/PDC_Cert_PMPCAPM.asp.
Wickens, John (1989) - Contingency Planning: Anticipating Disaster – V.3
Wold, G. H. (1997) “Disaster Recovery Plan Process”, Disaster Recovery
Journal.
37
BIBLIOGRAFIA CITADA
ABNT NBR ISO 9001:2000: Especifica requisitos para um Sistema de Gestão
da Qualidade, onde uma organização precisa demonstrar sua capacidade para
fornecer produtos que atendam aos requisitos do cliente e aos requisitos
regulamentares aplicáveis, e objetiva aumentar a satisfação do cliente.
Information Week - http://www.informationweek.com/ - Revista especializada
em TI tendo inclusive sua versão em Português.
Instituto DataQuest - unidade do Gartner Group
Price Waterhouse Coppers - © 2008 PRICEWATERHOUSECOPPERS.
38
ÍNDICE
FOLHA DE ROSTO 02
AGRADECIMENTO 03
DEDICATÓRIA 04
RESUMO 05
METODOLOGIA 06
SUMÁRIO 07
INTRODUÇÃO 08
CAPÍTULO I - Objetivos de um DRP 09
CAPÍTULO II - Estrutura Organizacional de um DRP 21
CAPÍTULO III - Recursos necessários a um DRP 24
CHECKLIST BASICO 32
CONCLUSÃO 34
BIBLIOGRAFIA CONSULTADA 36
BIBLIOGRAFIA CITADA 37
FOLHA DE AVALIAÇÃO 39
39
FOLHA DE AVALIAÇÃO
Nome da Instituição: Instituto a Vez do Mestre
Título da Monografia:
RECUPERAÇÃO DE DADOS DE TI APÓS GRANDES CATÁSTROFES
Autor: Claudio Roberto de Oliveira França
Data da entrega:
Avaliado por: Fabiane Muniz da Silva Conceito: