Exemplo de plano de continuidade de ti

Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 323

Plano de Continuidade de Negócios para a TI do
Aeroporto Internacional de Florianópolis
Rodrigo Fernando Martins1, Michelle S. Wangham2, Fábio Favarim3

¹Faculdades Barddal – Curso de Sistemas de Informação
Florianópolis, SC – Brasil

²Grupo de Sistemas Embarcados e Distribuídos – GSED
CTTMAR – Universidade do Vale do Itajaí (UNIVALI) - São José, SC – Brasil
3
Coordenação de Informática (COINF) - UTFPR - Campus Pato Branco

rodrigo.rodrigo@gmail.com, wangham@univali.br, favarim@utfpr.edu.br

Abstract. Currently, companies have their business processes in some way dependent
on information technology (IT). Consequently, any services that IT team provides are
critical for companies in order to allow them to continue offering their services to its
clients. The continuity of IT services is a very important issue and has contributed a
lot allowing companies to behave competitive. This work is intended to describe the
development of a BCP to the International Airport of the Florianópolis.

Resumo. Atualmente, as empresas têm seus processos de negócio de algum modo
dependente da tecnologia da informação (TI). Conseqüentemente, os serviços que a
equipe de TI provê são críticos para que as empresas continuem oferecendo seus
serviços a seus clientes. A continuidade dos serviços de TI é um fator muito
importante e tem contribuído muito para que as empresas continuem competitivas.
Este trabalho tem como objetivo descrever o desenvolvimento de um Plano de
Continuidade de Negócios para a TI do Aeroporto Internacional de Florianópolis.
Mais especificamente, o plano está focado nos três principais sistemas deste
aeroporto.

1. Introdução
Nos dias atuais, o volume de clientes que usufruem de serviços oferecidos nos
aeroportos tem crescido muito, conseqüentemente, junto com estes usuários cresce
também o número de empresas que oferecem serviços como transportes de cargas, de
passageiros e de valores e serviços de conveniência, tais como lojas, operadoras de
câmbio, instituições bancárias, praça de alimentação, entre outros. Os serviços
oferecidos estão tão ligados aos computadores e máquinas informatizadas que a falta
destes pode causar inúmeros problemas.
Um Plano de Continuidade de Negócios vem auxiliar as empresas a manter seus
sistemas em funcionamento, ou seja, garantir a disponibilidade dos sistemas. Segundo
Sêmola (2003), o propósito do Plano de Continuidade de Negócios (PCN) é minimizar
os impactos de desastre, no menor tempo possível, garantindo a continuidade de
processos e as informações vitais à sobrevivência da empresa. Laureano (2005) afirma
que se não houver planejamento para segurança e contingência adequados, alguns ou até

324 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais

todos os requisitos estão ameaçados e, conseqüentemente, a empresa está ameaçada
devido às vulnerabilidades na sua estrutura de Tecnologia da Informação (TI).
Diante de vários modelos e metodologias propostas para o desenvolvimento de
um plano de continuidade de negócios, o NIST (National Institude of Standards and
Technology) definiu uma recomendação (SP 800-34) que estabelece alguns parâmetros
para definição de um PCN. Esta recomendação é um guia de plano de continuidade para
tecnologia da informação que provê instruções, recomendações e considerações para
administração do plano de contingência no ambiente de TI.
O objetivo deste artigo é apresentar os resultados da elaboração de um PCN que
visa manter a continuidade dos serviços (três processos de negócios) em operação no
Aeroporto Internacional Hercílio Luz em Florianópolis. O processo de planejamento de
contingências realizado foi orientado pelas recomendações do NIST (2002).
Casos de catástrofes e acidentes causados por agentes externos como fenômenos
da natureza, incêndios e atentados são cada vez mais freqüentes (Magalhães e Pinheiro,
20007). Diante da existência de muitas vulnerabilidades que podem comprometer a
integridade dos sistemas informatizados, a elaboração de um plano de continuidade de
serviços de TI para o Aeroporto Internacional de Florianópolis se mostra necessário
tendo em vista a importância destes serviços. O objetivo deste plano é manter a
integridade de dados e dos equipamentos da organização, manter operacionais os
serviços de processamento de dados e prover, se necessário, serviços temporários ou
com certas restrições até que os serviços normais sejam restaurados.
Na Seção 2 são apresentados os principais conceitos e as fases para implantação
de um plano de continuidade de negócios. Na Seção 3 são descritas as fases executadas
para a elaboração do PCN. Através da aplicação de um questionário, o PCN foi avaliado
e os resultados desta avaliação são descritos na Seção 4. Por fim, na Seção 5 são
apresentadas a conclusão e algumas sugestões de trabalhos futuros.

2. Plano de Continuidade de Negócios (PCN)

Devido à grande concorrência, a maioria das empresas de hoje não pode mais ficar sem
os seus serviços de TI. Segundo NIST (2002), os recursos de TI são tão essenciais ao
sucesso de uma organização, que os serviços providos por estes sistemas informatizados
devem operar efetivamente sem interrupções. Para isso, recorre-se ao plano de
continuidade de negócios (PCN), que estabelece planos completos, procedimentos e
medidas técnicas que podem permitir que um sistema seja recuperado sem que haja a
interrupção de um serviço ou que este serviço seja recuperado o mais rápido possível.
Segundo Martins e Leamaro (1999), o Plano de Continuidade de Negócios é um
processo proativo de planejamento que assegura que uma organização possa sobreviver
a uma crise organizacional, com identificação das funções chave e das possíveis
ameaças que estas possam sofrer. De acordo com Campos (2005), o objetivo do PCN é
garantir que os sistemas críticos para o negócio sejam retornados a sua condição
operacional normal em um prazo aceitável, por ocasião da ocorrência de um incidente.
O PCN trata do incidente que já aconteceu. Então, o objetivo passa a ser minimizar o
quanto possível os prejuízos decorrentes desse incidente.
O plano de contingência deve ser constituído por uma série de ações
determinadas, relacionadas com o sistema a ser recuperado em caso de falha. A sua
complexidade e profundidade deve ser necessária e suficiente para atender as


necessidades dos sistemas da organização, sem desperdícios ou excesso de informação
que pode ser prejudicial numa situação crítica. Portanto, o plano de contingência deve
concentrar-se nos acidentes de maior probabilidade e menos catastróficos e não nos
acidentes mais catastróficos que são menos prováveis de acontecer, ou seja, o plano
deve ser construído a partir de cenários prováveis (Martins e Leamaro, 1999).
Conforme as recomendações do NIST (2002), os sistemas de TI são vulneráveis
a uma série de fatores, que podem ser uma curta interrupção de energia, um dano ao
disco rígido ou até mesmo a destruição do equipamento no caso de incêndios e
catástrofes naturais. Estas ameaças estão presentes na maioria das organizações, porém
podem ser minimizadas, ou podem ser subtraídas através de uma boa gestão da área de
TI, através de uma administração de riscos ou de soluções operacionais.
NIST (2002) revela ainda que a administração de riscos envolve uma grande
quantidade de atividades, desta forma deve-se identificar e controlar os riscos eminentes
em um ambiente de TI. A administração de riscos identifica as ameaças e as
vulnerabilidades de modo que se tenha o controle no caso de um incidente. Estes
controles protegem um sistema de TI contra três classificações de ameaças: natural
(furacão, tornado, inundação, fogo, etc), humana (erro de operação, sabotagem,
instalação de código malicioso, ataques terroristas, etc), ambiental (problemas de
hardware, erro de software, telecomunicações inoperante, falta de energia elétrica, etc).
Segundo NIST (2002), a administração de riscos deve identificar os riscos mais
evidentes para poder definir um plano de contingência específico.
De acordo com Dias (2000), o impacto é o dano potencial que uma ameaça pode
causar ao ser concretizada. Cada sistema ou recurso é afetado por ameaças e em
diferentes níveis de exposição. É conveniente determinar até que ponto a organização
pode ficar sem determinado sistema ou recurso e por quanto tempo. Conforme Sêmola
(2003), a análise de impacto fornece informações para o dimensionamento das demais
fases de construção do plano de continuidade. Seu objetivo é levantar o grau de
relevância entre os processos ou atividades que fazem parte do escopo da contingência
em função da continuidade do negócio. Em seguida, são mapeados os ativos físicos,
tecnológicos e humanos que suportam cada um destes, para então apurar os impactos
quantitativos que poderiam ser gerados com a sua paralisação total ou parcial. Através
da análise de impacto, é possível definir as prioridades de contingência, os níveis de
tolerância à disponibilidade de cada processo e ainda agrupar as atividades em função
de sua natureza e a relação de dependência que estas mantêm com os processos. Sêmola
(2003) enfatiza que a escolha das ameaças para cada processo está diretamente ligada à
probabilidade e severidade de um incidente. A partir dos processos de negócios da
empresa, é desejável montar uma tabela de ameaças, resumindo e qualificando os
impactos e ameaças consideradas pelo PCN.
Dias (2000) considera que antes de iniciar o planejamento de contingências em
si, é importante definir alguns aspectos administrativos e operacionais, tais como
objetivos, orçamento, prazos, recursos humanos, materiais e equipamentos necessários,
responsabilidades da equipe e escolha do coordenador ou gerente do planejamento de
contingências, como se fosse um projeto da organização. Conforme Dias (2000), o
comprometimento da alta gerência é de fundamental importância, pois para que o plano
seja exeqüível haverá custos financeiros e estes devem ser aprovados pelos grandes
responsáveis pela empresa. A identificação dos recursos, funções e sistemas críticos
deve estar pautada no grau de importância, sendo que os recursos podem ser
classificados como: importante ou essencial; média importância; baixa importância.


No desenvolvimento de um PCN, um documento que apresenta alternativas de
recuperação na forma analítica, descrevendo as diversas alternativas, vantagens e
desvantagens em relação às demais opções necessita ser elaborado. Neste relatório,
devem ser discriminadas as pessoas envolvidas e essas deverão ter a qualificação
técnica para exercer a atividade designada, já a organização tem que oferecer os
recursos financeiros necessários.

Tabela 1: Alternativas de acordos comerciais
Site Custo Equipamentos Estrutura de Tempo para Local
Hardware Telecomunicações migração

Cold-site Baixo Nenhum Nenhuma Longo Fixo

Warm-site Médio Parcial Parcial/Completo Médio Fixo
Hot-site Baixo/Médio Completo Completo Curto Fixo
Mobile-site Alto Depende Depende Depende Móvel
Mirrored-site Alto Completo Completo Nenhum Fixo

Fonte: NIST (2002).

A Tabela 1 apresenta uma comparação dos cinco principais acordos comerciais
utilizados como estratégia de recuperação. Segundo NIST (2002), o mirrored-site é a
escolha mais cara, porém a mais segura, apresentando disponibilidade de 100%. Cold-
site é a solução menos cara para se manter, porém, pode requerer muito mais tempo
para a migração em caso de ativação do PCN. Locais parcialmente equipados, como
warm-site, são menos caros. Mobile-site podem ser entregues em até 24 horas, porém, o
tempo necessário para instalação pode aumentar este prazo de conclusão. A tabela
resume ainda os critérios que podem ser empregados para determinar qual tipo de local
deve-se escolher para atender as exigências da empresa.
Conforme Dias (2000), quando um desastre acontece é preciso saber exatamente
o que fazer, para isso todos os passos a serem seguidos precisam ser descritos, a fim de
causar o mínimo de confusão e hesitação na hora do incidente (plano de contingência).
Esta fase do plano, então, deve definir as condições que constituem um desastre, os
indivíduos designados para iniciar os procedimentos de contingências e o que se deve
fazer imediatamente após a ocorrência do desastre. Após um incidente sério, a equipe de
resposta imediata deverá decidir que linha de ação seguir e como limitar os danos. Isso
depende basicamente do prazo de tempo estimado para a duração do desastre, da
importância dos sistemas afetados, da gravidade do dano ocorrido e do nível de prejuízo
provável para a organização, se uma ação imediata não for adotada.

3. PCN Para TI do Aeroporto Internacional de Florianópolis
O Plano de Continuidade de Negócios para TI do Aeroporto Internacional de
Florianópolis (SBFL1) foi realizado através do levantamento de informações obtidas
através dos colaboradores que trabalham na TI do aeroporto e dos colaboradores que
fazem parte da TI dos aeroportos envolvidos nos sistemas contingenciados. Os objetivos
estabelecidos para este plano foram (1) maximizar a eficácia das ações de emergência
através de um plano estabelecido que consiste nas fases de notificação/ativação, de
recuperação e de reconstrução; (2) identificar as atividades, recursos e procedimentos

1
SBFL – Código aeroportuário definido pela International Civil Aviation Organization (ICAO), que no
caso SBFL é o Aeroporto de Internacional de Florianópolis.


necessários para manter os sistemas e garantir o processo de negócios durante uma
interrupção prolongada; (3) atribuir responsabilidades designadas pela Infraero que
forneçam orientações para a recuperação do sistema durante os períodos de interrupção
prolongados; e por fim, (4) firmar contatos e contratos externos que possibilitam apoio
técnico ou estratégia de recuperação.
Especificamente foram escolhidos dentre os sistemas informatizados, os três
considerados mais importantes e robustos que estão situados nas dependências do
SBFL: o Sistema Integrado de Solução Operacional e Banco de Dados Operacional
(SISO/BDO), o Sistema Gestor de Estacionamentos (GEST) e o Sistema Gerenciador
de Torre de Controle (SGTC). A seguir, as principais fases executadas na elaboração do
PCN serão descritas tendo como base o sistema SISO/BDO.

3.1 – Identificação dos Sistemas
Nesta fase, os três sistemas foram devidamente analisados e um documento
descrevendo em detalhes as suas características técnicas foi elaborado2. A seguir tem-se
uma breve descrição dos sistemas.
O Sistema Integrado de Solução Operacional e Banco de Dados Operacional
(SISO/BDO) consiste em um sistema modular e integrado para apoiar a gestão
operacional do aeroporto, visando um controle mais eficiente em todo o ciclo dos
processos operacionais, registrando as suas ocorrências em uma única base de dados. O
sistema como um todo possibilita manipular as informações de vôo, exibir estas nos
diversos dispositivos de visualização, anunciar as mensagens de vôo, controlar a
movimentação das aeronaves, gerar estatísticas, efetuar a alocação dos recursos
aeroportuários, tudo isso mediante um ambiente de controle de acesso para assegurar a
integridade das informações. Algumas informações técnicas:
x número de operadores envolvidos: dez;
x número de clientes envolvidos (direta e indiretamente): média de quatrocentas
pessoas a cada quatro horas;
x ativos de rede envolvidos: dois switches e um roteador com circuito de dados;
x equipamentos: dois servidores (principal e reserva), dez estações de trabalho
para os operadores, vinte e oito televisores para a projeção das telas de
chegada e partida, duas estações de trabalho para interligar ao sistema de
projeção das telas de chegada e partida, vinte e oito monitores LCD e
estações para os terminais inteligentes.
O Sistema Gestor de Estacionamentos (GEST) é o sistema desenvolvido pela
INFRAERO para o controle operacional e financeiro do fluxo e permanência de
veículos nos estacionamentos comerciais da empresa, registrando e arquivando os dados
dessa movimentação de forma segura e pelos prazos legais previstos. O sistema
apresenta três modalidades, a informatizada, automatizada e semi-automatizada, porém
no Aeroporto Internacional de Florianópolis é utilizada somente a modalidade
automatizada. Nessa opção, tanto o processo de entrada quanto o de saída utilizam
recursos de automação, eliminando a necessidade de participação ou interferência
humana na passagem do veículo.

2
Este documento está disponível em: http://sites.google.com/site/sbflpcn/Home/plano-de-contingencia


O sistema de gerenciamento da torre de controle (SGTC) é um software
desenvolvido pela empresa Saipher ATC Ltda que atende as necessidades dos
operadores da torre de controle. Este software está instalado em noventa e quatro (94)
aeródromos espalhados por todo o território nacional. O STMS (Saipher Tower
Management System) ou SGTC como é conhecido no Brasil é um sistema
computadorizado para Torres de Controle que permite aos controladores visualizar,
manipular e gerenciar o tráfego aéreo. Saipher (2005) explica que para o gerenciamento
o SGTC automatiza uma série de funções, inclusive a substituição das strip de papel por
strip eletrônica (e-strip), que contêm os campos operacionais de um plano de vôo e são
transferidas eletronicamente entre as posições operacionais, propiciando um ambiente
silencioso e completamente livre de papéis.

3.1- Análise de Impacto

A análise de impacto foi desenvolvida separadamente para cada sistema. Desta
forma, o nível de abstração foi menor e a representação foi mais próxima da realidade.
O administrador responsável pela rede detalhou quais os equipamentos devem ser
contingenciados caso ocorra uma emergência, foi realizado o levantamento dos
equipamentos envolvidos. Durante a análise de impacto, foram considerados os
processos de negócios envolvidos para casa sistema. A Tabela 2 apresenta os níveis de
criticidade de cada processo de negócio do sistema SISO/BDO.

Tabela 2: Criticidade dos Processos para o Sistema SISO/BDO
Processo de Negócios FIPS FIDS SIMS PADS SMAP STAFF TAFS SCAS
1 Não considerável
2 Relevante X X
3 Importante X
4 Crítico X X X X X
5 Vital

Após a identificação do nível de relevância de cada processo foram analisadas as
ameaças que podem afetar cada processo. A Tabela 3 apresenta os processos de
negócios do sistema SISO/BDO e as ameaças mais consideradas. Após o cruzamento
das ameaças com os processos, tem-se para cada processo a percepção de tolerância,
que significa o tempo que este pode ficar indisponível. A coluna mais a direita apresenta
a probabilidade dessa ameaça afetar o processo de negócio deste sistema.
Tabela 3: Ameaças Consideradas para o Sistema SISO/BDO
Processos de Negócios Probabilidade
STAFF
Ameaças Consideradas

SMAP
PADS

TAFS

SCAS
SIMS
FIDS
FIPS

Falta de Hardware X X X X X X 0,3
Vendaval X X X X X X X 0,2
Aplicativos Maliciosos X X X X X X X 0,4
Ataques externos (Crackers) X X X X X X X X 0,01
Usuário Desinformado X X X X X X X 0,2
Umidade/ Vazamento X X X X X X X 0,2
Incêndio X X X X X X X 0,1
Indisponibilidade da Rede X X X X X X X 0,3
Interrupção de Energia X X X X X X X 0,4
Ataque negação de serviço X X X X X X 0,1
Ataques Internos/ funcionários insatisfeitos X X X X X X X 0,05
Tolerância 2h 15’ 24h 15’ 1h 15’ 30’ 48 h


Na Tabela 4, tem-se todos os recursos necessários para que os processos do
sistema SISO/BDO funcionem, caso ocorra uma indisponibilidade de um destes
recursos ocorrerá uma reação e, conforme for esta reação, o impacto pode paralisar
totalmente o sistema SISO/BDO.

Tabela 4: Impacto da Indisponibilidade para o Sistema SISO/BDO.
Recurso Impacto da Indisponibilidade Processos Envolvidos3
Rede de Computadores Dependendo do ponto físico do cabeamento não, haverá comunicação FIPS, FIDS, SIMS,
(cabeamento) entre as estações de trabalho dos operadores ou telas LCD inteligentes PADS, SMAP, STAFF,
com o servidor SISO. TAFS e SCAS.
Estações Operacionais Caso as duas estações do Centro de Operações e Controle não estejam FIPS, PADS, SMAP,
funcionando os operadores não podem acessar o sistema e inserir dados. STAFF e TAFS.
Estação STAFF As companhias aéreas não farão os cadastros e consultas referentes aos STAFF e FIDS.
vôos desta.
Monitores de TV Parcial indisponibilidade das informações visuais, podendo ser supridas FIDS.
pelas Telas LCD inteligentes, se essas estiverem disponíveis, caso não
estejam, a indisponibilidade do informativo visual é total.
Telas LCD Inteligentes Parcial indisponibilidade das informações visuais, podendo ser suprida FIDS.
pelos Monitores de TV, se esses estiverem disponíveis, caso não estejam
a indisponibilidade do informativo visual é total.
Servidor Banco de Dados Caso o servidor esteja indisponível, as estações não conseguirão conectar FIPS, FIDS, SIMS,
ao serviço do banco, conseqüentemente, todos os processos do sistema PADS, SMAP, STAFF,
estão indisponíveis, isso porque o servidor de reserva fica ativo, porém é TAFS e SCAS.
necessário mudar o caminho para o servidor ativo em todas as estações
clientes.
Servidor Distribuição Telas As Telas LCD inteligentes não funcionarão. FIDS.
Switch de Rede As estações não conseguirão conectar ao serviço do banco, FIPS, FIDS, SIMS,
conseqüentemente todos os processos do sistema ficarão indisponíveis. PADS, SMAP, STAFF,
TAFS e SCAS.
Servidor Reserva Caso precise ativar o plano de contingência no local alternativo, o FIPS, FIDS, SIMS,
servidor reserva não estará disponível, conseqüentemente, todos os PADS, SMAP, STAFF,
demais serviços do sistema SISO estarão indisponíveis. TAFS e SCAS.
Energia Elétrica As estações de operação, telas inteligentes, sistema de anúncio de FIPS, FIDS, SIMS,
mensagens audíveis e máquinas STAFF não funcionarão até que o PADS, SMAP, STAFF,
gerador do aeroporto entre em operação, podem demorar de um (1) até TAFS e SCAS.
(5) minutos.

3.2- Estratégia de Recuperação

A estratégia de recuperação está focada na lista de avaliação de danos, pois é
esta lista que fornece as informações que serão analisadas logo que acontecer um
desastre, para que o técnico responsável pela execução da função atinja o objetivo de
recuperação.
A atuação do técnico foi descrita em uma lista que detalha as instruções
necessárias para a recuperação e os respectivos procedimentos de cada sistema, esta
lista está no documento chamado plano de contingência4. Serão periodicamente
realizadas cópias de segurança dos arquivos dos servidores envolvidos e como medida
de recuperação será utilizada uma estratégia interna de espelhamento do sistema. A
descrição detalhada de como são realizadas as rotinas de backup, bem como a
restauração destes está descrita no documento.
No local alternativo que manterá a estratégia de espelhamento dos servidores dos
sistemas SISO/BDO, GEST e SGTC, haverá três servidores, sendo que cada um destes
é destinado para um sistema específico. Os servidores deverão ter seus sistemas
operacionais e banco de dados idênticos aos do sistema original. A rede local chegará ao
local alternativo através de um par de fibras óticas partindo da sala técnica próxima ao

3
Os processos envolvidos tanto podem ser para apenas um processo quanto para um grupo de processos e
dependendo do caso todos os processos.
4
Disponível em http://sites.google.com/site/sbflpcn/Home/plano-de-contingencia.


desembarque doméstico RACK C, interligando com outro par de fibra que segue até o
RACK A. Também terá mais dois pares de fibras partindo do RACK A e chegando
direto ao local alternativo. Esta fibra ótica seguirá pela galeria sob o TPS do aeroporto,
desta forma a rede será em forma de anel.
A Infraero disponibilizou um local alternativo e este fica localizado no antigo
prédio da VASP, toda a infra-estrutura foi adequada para um ambiente de TI para
contingenciar os sistemas SISO/BDO, GEST e SGTC e manter em paralelo um sistema
idêntico processando a aplicação simultaneamente. Este local alternativo fica a menos
de duzentos metros da sala técnica principal que está situada no TPS na área de
administração da Infraero. O ambiente alternativo oferece suporte de telecomunicações,
redes, ambiente climatizado, sistema ininterrupto de energia, sistema de controle de
acesso físico, sistemas de vigilância e sensores de fumaça. O lugar alternativo que
mantém os sistemas espelhados só será usado em caso de um ou mais sistemas ficarem
indisponíveis e todas as medidas de contingência citadas no documento não sejam
suficientes para o retorno das operações normais.
Os sistemas que estão nos servidores espelhados estão totalmente disponíveis
para o momento da interrupção do sistema principal. O lugar alternativo será usado para
os sistemas, enquanto a recuperação do local afetado seja realizada ou até o regresso das
operações para o local original. O local alternativo que manterá os sistemas será
chamado de Site B para facilitar e melhorar as orientações registradas no documento.
Contratos de serviço são mantidos com os provedores de hardware e
comunicações para os sistemas, isso deve servir de apoio em caso de recuperação do
sistema de emergência. No caso das estações de usuários, tem-se garantia on-site para
atender as máquinas da HP e Positivo, para os switchs de rede tem-se a garantia de
substituição dos equipamentos da empresa Redesul. O link de dados é provido pela
Embratel, que oferece um serviço cuja disponibilidade é de 24 horas por dia. A lista de
contatos para essas empresas é apresentada no documento do plano de contingência. Os
sistemas mantidos pela Infraero têm o suporte realizado pelas equipes que
desenvolveram ou mantém um contrato para suporte com o fabricante, no caso do
sistema SISO/BDO, o contato é feito com a equipe de TI do aeroporto do Galeão
(TIGL), já o sistema GEST o contato é com a equipe de TI do aeroporto de Recife
(TIRF), já o sistema SGTC por ser um sistema de terceiros, este é parcialmente mantido
pelo HELP-DESK da equipe de TI do aeroporto de Porto Alegre (TIPA) e a navegação
aérea (NAPA).

3.3- Testes, Treinamento e Atualizações

Durante o procedimento de testes, no caso do sistema SISO/BDO, é escolhida
aleatoriamente uma máquina do centro de operações aeroportuária e alterado o atalho
que aponta para o servidor em atividade S-FLBN07 para o servidor de contingência S-
FLBN10. Durante a operação de teste, é necessário observar se ocorre alguma demora
no estabelecimento da conexão com servidor e se apresenta algum erro.
Para o sistema GEST a rotina de teste é bem semelhante ao SISO/BDO, porém
independente da máquina escolhida seja um totem de entrada ou saída ou o caixa de
pagamento, o teste será apenas uma simulação, pois se este for executado com um
cliente a informação de entrada no estacionamento no servidor reserva não será
replicada para o servidor principal, podendo assim causar uma confusão. A modificação
realizada para teste consistiu na alteração do arquivo gest.ini, localizado no


diretório c:gest. Na linha do arquivo onde é indicado o servidor principal S-FLBN03
deve-se alterar para S-FLBN04, que é o servidor de contingência. Após o teste de
conexão, é importante que a aplicação faça algumas consultas ao sistema e simulações
de entrada ao estacionamento.
Por fim, para o sistema SGTC, os testes também consistem de apenas
simulações de consultas através de algum módulo do sistema. Deve-se alterar o
parâmetro na aplicação do usuário que informa o servidor de conexão mudando do
servidor principal S_FLBN50 para o servidor de contingência S-FLBN51. A equipe
técnica precisa estar bem treinada para seguir as regras de recuperação para a ativação
do sistema espelhado. Mensalmente, os técnicos devem discutir os problemas ocorridos
durante o mês e em caso de modificações do plano, estas precisam ser registradas no
documento Registros de Alterações. Sempre que houver modificação no plano, desde a
última impressão, esta deve ser registrada. As alterações somente serão realizadas caso
seja encontrado algo não coerente aos procedimentos já adotados e a revisão do plano
deve ocorrer uma vez por mês.

4. Avaliação dos Resultados Obtidos

Para avaliar o PCN destinado aos sistemas SISO/BDO, SGTC e GEST do Aeroporto
Internacional de Florianópolis, foi aplicado um questionário aos membros da tecnologia
da informação do Aeroporto de Florianópolis e da regional em Porto Alegre. Este
questionário teve o objetivo de verificar se o PCN e suas etapas que o constituem estão
bem elaboradas e realmente condizem com a realidade do aeroporto. Este questionário
foi respondido por oito profissionais da área da tecnologia da informação, sendo estes
representados da seguinte forma: um gerente de TI, um analista de redes, um analista de
suporte, um analista de sistemas e quatro técnicos de suporte.
O questionário procurou avaliar: os níveis de criticidade que foram definidos
para cada processo; as ameaças identificadas para cada sistema; os impactos causados
com a indisponibilidade do sistema ou parte deste; as medidas para recuperação dos
sistemas e as prioridades de recuperação identificadas; e, por fim, se é necessário
aumentar o número de técnicos para efetivar o PCN no Aeroporto de Florianópolis. Os
resultados obtidos apresentam que o PCN e suas etapas foram bem definidas para os
sistemas SISO/BDO, GEST e SGTG e ainda revela que apesar de não existir um PCN
implantado e o assunto não ser de pleno conhecimento dos integrantes da área de TI,
empiricamente, os entrevistados conhecem os processos de negócios e como proceder
para contingência-los no caso de uma situação de crise. Os resultados obtidos em cada
questão estão disponíveis no documento de avaliação do questionário5.

5. Conclusão

O presente artigo tratou de um assunto que está sendo muito difundido dentro
das empresas que buscam garantir a disponibilidade de seus sistemas e serviços, o plano
de continuidade de negócios. Uma das motivações para o desenvolvimento deste
trabalho foi o fato de que a Infraero está cada vez mais dependente dos seus sistemas
informatizados e de toda a tecnologia que a rodeia.
O plano de continuidade de negócios desenvolvido neste trabalho foi
direcionado aos sistemas GEST, SGTC e SISO/BDO. O documento que está no site

5
Disponível em http://sites.google.com/site/sbflpcn/Home/plano-de-contingencia/questionário.pdf


http://sites.google.com/site/sbflpcn/Home/plano-de-contingencia, apresenta as medidas
para contingenciar os problemas para situação em específico para os sistemas GEST,
SGTC e SISO/BDO.
As etapas de desenvolvimento do PCN até a sua conclusão possibilitou
compreender que cada sistema é segmentado por inúmeros processos de negócios e que
estes são amplos e complexos. Isso ocorre porque os processos possuem ligações com
as demais atividades que independem da tecnologia da informação, ou que ainda
dependem, porém são outros sistemas independentes que apenas alimentam o sistema
em questão com dados que ainda serão processados. Com o desenvolvimento do plano,
também foi possível concluir que para o seu funcionamento correto este depende de
inúmeros comprometimentos, entre esses estão o investimento financeiro da empresa
com o desenvolvimento e manutenção do PCN, o comprometimento daqueles que irão
manter o PCN e daqueles que serão alvo do plano, os usuários dos sistemas. Não basta
ter um PCN, mas é preciso ter uma equipe bem treinada e preparada para atender as
diversas situações de emergência. Para trabalho futuros sugere-se a criação de um banco
de dados que acumule informações de sinistros ocorridos nos sistemas de cada
aeroporto e como este foi atendido e solucionado e aplicar/desenvolver políticas de
seguranças voltadas aos recursos de TI oferecidos, a fim de minimizar as ameaças aos
processos de negócios de cada sistema.

Referências

CAMPOS, André. Sistema de Segurança da Informação – Controlando o Risco; Editora
Visual Books, Brasil, 2005.

DIAS, Cláudia. Segurança e Auditoria da Tecnologia da Informação. Rio de Janeiro:
Axcel Books, 2000. 218 p.

LAUREANO, Marcos Aurelio Pchek. Gestão da Segurança da Informação. Relatório
Técnico. Pontifícia Universidade Católica do Paraná, Curitiba, 2007 (última revisão).

MAGALHÃES, Ivan Luizio; PINHEIRO, Walfrido Brito. Gerenciamento de Serviços
de TI na Prática: uma abordagem na prática: inclui ISO/IEC 20.000 E IT Flex. São
Paulo: Novatec, 2007. 667 p. (Gerenciamento de TI).

MARTINS, Eulália; LEAMARO, Manuela. Guia Técnico de Planos de Contingência:
Linhas de Orientação. Portugal: Instituto de Informática, 1999. 17 p.

NIST. Contingency Planning Guide for Information Technology Systems: The NIST
handbook; National Institute of Standards and Technology; Estados Unidos, Junho,
2002.

SÊMOLA, Marcos. Gestão da Segurança da Informação : Visão Executiva da segurança
da informação: aplicada ao Security Officer / Marcos Sêmola e Módulo Security
Solutions S.A.. Rio de Janeiro: Elsevier, 2003. 158 p. (4 ª Tiragem).

Exemplo de plano de continuidade de ti

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Exemplo de plano de continuidade de ti

Similar to Exemplo de plano de continuidade de ti (20)

More from Fernando Palma

More from Fernando Palma (20)

Exemplo de plano de continuidade de ti