exemplo de plano de continuidade de ti

Plano de Continuidade de Negócios para a TI do

Aeroporto Internacional de Florianópolis

Rodrigo Fernando Martins1, Michelle S. Wangham

2, Fábio Favarim

3

¹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

3Coordenação de Informática (COINF) - UTFPR - Campus Pato Branco

[email protected], [email protected], [email protected]

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é

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

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

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

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

Hardware

Estrutura de

Telecomunicações

Tempo para

migração

Local

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:

número de operadores envolvidos: dez;

número de clientes envolvidos (direta e indiretamente): média de quatrocentas pessoas a cada quatro horas;

ativos de rede envolvidos: dois switches e um roteador com circuito de dados;

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

Am

eaça

s C

on

sid

era

da

s

Processos de Negócios Probabilidade

FIP

S

FID

S

SIM

S

PA

DS

SM

AP

ST

AF

F

TA

FS

SC

AS

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 (cabeamento)

Dependendo do ponto físico do cabeamento não, haverá comunicação entre as estações de trabalho dos operadores ou telas LCD inteligentes com o servidor SISO.

FIPS, FIDS, SIMS, PADS, SMAP, STAFF, TAFS e SCAS.

Estações Operacionais Caso as duas estações do Centro de Operações e Controle não estejam funcionando os operadores não podem acessar o sistema e inserir dados.

FIPS, PADS, SMAP, STAFF e TAFS.

Estação STAFF As companhias aéreas não farão os cadastros e consultas referentes aos vôos desta.

STAFF e FIDS.

Monitores de TV Parcial indisponibilidade das informações visuais, podendo ser supridas pelas Telas LCD inteligentes, se essas estiverem disponíveis, caso não estejam, a indisponibilidade do informativo visual é total.

FIDS.

Telas LCD Inteligentes Parcial indisponibilidade das informações visuais, podendo ser suprida pelos Monitores de TV, se esses estiverem disponíveis, caso não estejam a indisponibilidade do informativo visual é total.

FIDS.

Servidor Banco de Dados Caso o servidor esteja indisponível, as estações não conseguirão conectar ao serviço do banco, conseqüentemente, todos os processos do sistema estão indisponíveis, isso porque o servidor de reserva fica ativo, porém é 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,

conseqüentemente todos os processos do sistema ficarão indisponíveis. FIPS, FIDS, SIMS, PADS, SMAP, STAFF, TAFS e SCAS.

Servidor Reserva Caso precise ativar o plano de contingência no local alternativo, o servidor reserva não estará disponível, conseqüentemente, todos os demais serviços do sistema SISO estarão indisponíveis.


Energia Elétrica As estações de operação, telas inteligentes, sistema de anúncio de mensagens audíveis e máquinas STAFF não funcionarão até que o gerador do aeroporto entre em operação, podem demorar de um (1) até (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

Documents