Marco Carnut: A Primeira das Quatro Grandes Tribos em SSI - Tempest Blog
Por Marco Carnut em 2010-08-12 15:26:38 4 comentários
Se houvesse uma única grande feira que reunisse todo mundo que já vi em segurança de sistemas de informação, eu poderia mais ou menos agrupá-los em quatro grandes "tribos": os que tratam segurança contra indisponibilidade, os que lidam com segurança contra acesso indevido, os que abordam segurança contra omissões técnicas e os enfurnados em segurança jurídica. Nesta série, vou tentar descrever um pouco do que aprendi com essas várias tribos, algumas sub-tribos e sub-culturas, alguns agregados e, quem sabe, algumas lições, na esperança que isso possa ajudar o leitor a navegar por entre as tribos e quem sabe melhorar a comunicação entre elas e com aqueles fora delas, sobretudo os usuários.
A Tribo da Segurança Contra Indisponibilidade
A obsessão dessa tribo é fazer com que os sistemas não parem de funcionar e permaneçam operando ininterruptamente a maior quantidade de tempo possível. Aqui se vê gente tratando de coisas como (a lista abaixo nem de longe pretende ser exaustiva):
Soluções para cópias sobressalentes ("backups"): robôs de fitas, discos óticos de alta densidade, softwares para realização e gerenciamento automático de back-ups, essas coisas;
Sistemas de alimentação elétrica de emergência: grupos geradores, "no-breaks" (entre aspas porque o termo, apesar de em inglês, só é usado assim aqui no Brasil; o termo correto em inglês é "UPS", sigla de "Uninterruptible Power Supply"), geradores, etc.
Salas-cofre com climatização, extinção automática de incêndios, resistência a água e, alguns dizem, até mesmo contra bombas eletromagnéticas.
Aglomeração ("clusters") de computadores, onde a idéia é ter vários computadores prontos para realizar uma tarefa, de sorte que se um pifar, os outros compensam;
Nessa tribo também se inclui a "turma da papelada", cuja função é escrever documentos longos, tediosos e deliciosamente paranóicos chamados Planos de Recuperação de Desastres ("DR plans") e Planos de Continuidades de Negócios ("BCPs", na sigla em inglês). Eles tentam traçar no papel cursos de ação para situações relativamente comuns ("E se o diretor financeiro da empresa morrer amanhã"?) até algumas raríssimas, como "E se o data center for inundado?", "Que faremos se houver um terremoto?", "E se jogarem uma avião aqui no prédio do escritório?". Antes de 2001, havia quem considerasse esta última contingência fantasiosa demais para ser levada a sério. Hoje em dia até as mais impensáveis das catástrofes costumam ser pelo menos contempladas – tem gente colocando coisas como "O que fazer se a Terra for atingida por um asteróide".
De longe, essa é a tribo mais numerosa e mais rica. Para o usuário que não consegue tirar dinheiro do caixa eletrônico, ser atendido no balcão ou ligar do seu celular porque o sistema está "fora do ar", sei que talvez não pareça, mas gasta-se milhões para garantir que os sistemas, caixas eletrônicos, websites e celulares de fato cumpram aquilo a que se propõem.
É fácil ver por que tanto investimento é feito nessa área: é porque quantificar a perda é especialmente fácil. Toda instituição tem algum tipo de estatística sobre quanto ela realiza (financeiramente ou por outros critérios) por hora, por dia, por mês e por ano; basta multiplicar a fração de tempo indisponível pela média de realização para se ter o "prejuízo". Exemplo: se uma instituição X fatura um milhão de reais por dia, uma parada a fará deixar de faturar R$ 1.000.000/dia dividido por 24 horas por dia, o que dá quase 42 mil reais por hora.
Se é fácil calcular a perda, fica mais fácil saber se algum investimento em segurança contra indisponibilidade faz sentido econômico ou não. Suponha que nossa instituição X está tendo nove horas por mês "fora do ar" devido a faltas de luz. Se um "no-break" custar menos do que os 375 mil reais por mês que ela está deixando de ganhar (excluindo, naturalmente, as perdas indiretas com reputação, etc), então faz sentido investir nele, pois provavelmente diminuirá o tempo fora do ar. Note, aqui, que a segurança contra indisponibilidade é uma questão secundária, subordinada à suprema prioridade primária: custo.
Surpreendentemente, se você for na seção de informática de uma boa livraria brasileira, achará poucos títulos como "Projetos de Sistemas de Informação com Alta Disponibilidade" ou algo parecido. Se você for nos catálogos online, sobretudo nas livrarias estrangeiras, tais como a Amazon.com, achará alguns títulos sobre "high availability", "dependable systems" ou "survivable systems", mas bem menos do que se você pesquisar por outros tópicos de informática.
Pelejei para tentar citar de memória algum curso universitário cujo currículo tenha disciplinas sobre esse assunto, mas nada me veio à mente. Catando no Google por "Disciplina Alta Disponibilidade", tive a grata surpresa de ver pelo menos alguns casos desse assunto sendo abordado em cursos universitários – há meros dois anos atrás eu tinha feito a mesma consulta no Google e não tinha achado nada. Mas sei que o tema é abordado em outras engenharias, tais como elétrica e aeronáutica.
Mas, se você procurar no Google por "Currículo Alta Disponibilidade", vai achar currículos de um bom punhado de gente que afirma ter trabalhado em projetos de alta disponibilidade. Não é acidente: a missão maior de praticamente todo operador de sistemas de informação é manter o sistema funcionando, então a maior parte deles acredita piamente que provê alta disponibilidade, independente do que, exatamente, "alta disponibilidade" signifique.
Não obstante, há várias normas técnicas que exigem medidas para garantir a disponibilidade dos sistemas de informação e continuidade dos negócios em geral. A NBR17799 aborda vários quesitos sobre disponibilidade; a ISO15999 trata especificamente de "continuidade dos negócios". Quatro empresas conhecidas como as "Big Four" ganham bastante dinheiro auditando instituições para ver se estão aderentes a essas normas. Eu também os agrupo na "turma da papelada": seus insumos e resultados são, essencialmente, documentos em papel. Quem costuma gostar dessas coisas são as altas gerências; a maioria dos técnicos que efetivamente operam os sistemas no dia-a-dia costuma encarar essas normas e essas auditorias com franco ceticismo, para dizer o mínimo, mas são forçados a cooperar com elas.
A despeito disso, não conheço alguma lei que exija requisitos mínimos de disponibilidade para sistemas de informação. Talvez o único tipo de formalização jurídica de requisitos de disponibilidade que eu já vi são os chamados "Service Level Agreements" que certos provedores de acesso à Internet ou provedores de hospedagem de sites oferecem a seus clientes. Basicamente são contratos dizendo que se eles não cumprirem X% de disponibilidade (especificando bem direitinho como se mede e calcula), eles te darão uma série de descontos. Detalhe: é o provedor que mede, não o cliente.
Essa, como todas as tribos, tem uma certa dose de insensatez. É engraçado ouvir um "especialista" falar sobre "alta disponibilidade" e não ser capaz de responder, exatamente, como foi que ele mediu os 99,999% e qual é a disponibilidade do sistema que mediu os 99,999% (para a medida ter algum sentido, a disponibilidade do sistema que mede tem de ser maior do que a disponibilidade do sistema medido). Nessa, como em várias outras tribos, é triste ver gente inventando lorota ao invés de ter a humildade de admitir que não sabe. Essa é a tribo que dá um significado todo especial àquelas velhas piadas que "43% das estatísticas são inúteis" e que "existem três tipos de mentiras: as mentiras, as mentiras deslavadas e as estatísticas".
Mas aqui, como nas demais tribos, também há muita gente competente e comprometida, que vive realizando um trabalho inglório: só costumamos lembrar dos membros dessa tribo quando os sitemas "saem do ar". Raramente lembramos o esforço que esses profissionais dispendem em manter as coisas funcionando, para que tenhamos a agilidade e conveniência da vida moderna. Pois quero fazer diferente: membros essa tribo, saibam que vocês têm o meu mais profundo respeito e admiração.
Marco Carnut | 2010-08-13 11:54:37 | permalink | topo
Sem sombra de dúvida, qualquer esforço no sentido de criar uma disciplina univesitária nessas linhas seria muito melhor do que não ter nada. E já tem gente tentando – se você catar no Google, achará alguns trabalhos sobre HA. Vou coletar alguns deles na página do post sobre minha palestra sobre HA no FISL11 (já teve até um visitante que colocou um trabalho desses lá).
O fato da escala do problema não encaixar bem com a escala de tempo e recursos tipicamente dispendidos em preparar e ministrar disciplinas universitárias não quer dizer que o problema não pode ser resolvido; antes, quer dizer que precisamos bolar um outro jeito de resolvê-lo.
Ricardo Ulisses | 2010-08-13 11:46:11 | permalink | topo
Eu enxergo uma abordagem anterior à medição da disponibilidade anual dos sistemas. Acho que primeiro é preciso se concentrar nos fundamentos. Estudar mais a questão dos componentes e protocolos usados para criar ambientes com alta disponibilidade. RAID, clusters, grids, estratégias de backup, redundância de componentes de rede, para citar alguns exemplos.
E na questão dos laboratórios imagino algo como as cadeiras de física experimental, na qual o aluno efetivamente "põe as mãos na massa" para testar situações variadas, monitorá-las, efetuar ajustes e retestá-las.
É claro que aí esbarramos nas limitações de infra-estrutura computacional. A realidade dos cursos de computação, principalmente no nordeste, é que faltam recursos para explorar melhor alguns viéses da área.
Talvez essa abordagem ou parte dela caiba suficientemente bem num curso de um ou dois semestres. Talvez um curso inteiro possa ser feito com esse foco, principalmente nessa época de cursos específicos de computação ou sistemas de informação com ênfase nisso ou naquilo.
Estou certo de que essa disciplina seria, sem sombra de dúvida, uma de minhas prediletas :)
Marco Carnut | 2010-08-13 10:42:27 | permalink | topo
A dificuldade que eu vejo é que não há tempo suficiente em uma disciplina de universidade. Exemplo (simplista, eu sei): como medir 99,99% de disponibilidade anual em um sistema desenvolvido em uma cadeira de universidade, se ela só dura seis meses (nem isso – na prática, pouco mais de três meses)?
Conseguir 99,99% de disponibilidade mensal em um sistema pouco atualizado é fácil – e isso é o que me pareceria realista fazer em uma disciplina universitária. A verdadeira bronca é conseguir >99,99% de disponibilidade anual em um sistema que sofre upgrades de hardware e software o tempo todo, durante vários anos seguidos, tendo que cooperar com desenvolvedores que em geral não estão muito aí pra nada disso. Aí é que o bicho pega.
Em outras palavras, não há, em uma disciplina universitária, nem tempo hábil nem diversidade de pessoal o bastante, para tornar o desafio remotamente realista.
Ricardo Ulisses | 2010-08-13 09:46:01 | permalink | topo
Concordo com suas colocações lúcidas e abrangentes sobre o tema.
Sobre a formação de profissionais, penso que a maioria das universidades brasileiras ainda não dá a atenção merecida ao quesito "Alta Disponibilidade" como um fim; quando muito, o tratam como um acessório.
Por exemplo, percebo que disciplinas que abordam clusters ou grids – como "Sistemas Distribuídos" ou "Arquitetura Avançada de Computadores" – dão mais ênfase ao uso de tais arranjos para melhorar o desempenho de programas – finalidade não menos nobre, diga-se de passagem.
Quando a disciplina exige a confecção de projetos, a montagem da estrutura sobre a qual a computação distribuída será realizada normalmente é relegada a segundo plano e mencionada apenas na teoria; o importante é fazer o programa funcionar.
Imagino como seria divertido, desafiador e útil para a vida profissional de muitos graduandos ter uma experiência hands-on em projetos de alta disponibilidade em uma ou mais disciplinas exclusivas, com boa fundamentação téorica e laboratórios simulando problemas reais, nos quais os alunos terão a oportunidade de elaborar e testar soluções para eles. Torço para que isso se concretize.