.leg.br

Assim que decidi que iria para a Câmara dos Deputados, entrei em contato com algumas pessoas que eu conhecia e que já trabalhavam no centro de Informática. Esses contatos me ajudaram a conseguir uma conversa com a coordenadora da área de infraestrutura, que era onde ficava a área de segurança. Essa foi a minha forma de tentar garantir que eu seria alocado nesse time. Não sei dizer se isso fez diferença, mas o resultado foi exatamente o que eu queria: já no primeiro dia eu fazia parte do time de segurança do Centro de Informática.

As atribuições desse time eram bem tradicionais para uma área de segurança dentro de infraestrutura: cuidávamos de firewall, antivírus e de qualquer outro projeto que envolvesse aspectos de segurança. Ou seja, o escopo do trabalho era bastante familiar para mim.

Logo que eu cheguei, ainda não estava alocado em nenhum projeto específico, então acabei tendo algum tempo livre. Eu estava no processo de montar o curso de segurança em desenvolvimento que mencionei no capítulo “AppSec Brasil 2009”. Mostrei o material para o meu chefe, ele gostou e sugeriu que criássemos um curso interno para os desenvolvedores da Câmara. Assim nasceu meu primeiro projeto na instituição: um curso de segurança no desenvolvimento de software em Java.

Eu colaborei com o centro de treinamento da Câmara e estruturamos o curso formalmente. Durante esse processo, pedi feedback a um colega que também tinha acabado de entrar no time de segurança e que tinha bastante experiência com desenvolvimento de software. Com as sugestões dele, acabei ajustando e reorganizando parte do conteúdo.

Eu já comentei também sobre minha participação no Summit da OWASP. Lá eu aprendi mais sobre o ModSecurity, uma ferramenta open source da OWASP para implementação de WAF (Web Application Firewall). Um dos sistemas mais importantes da Câmara era o seu site institucional, que funcionava como uma ferramenta essencial de comunicação com os cidadãos. Naquela época, ele concentrava a maior parte das informações públicas sobre o que acontecia na Câmara.

Dada a importância do site, achei que seria interessante implementar uma solução de WAF de baixo custo usando software open source. Levei essa ideia para o meu chefe e para a coordenadora da área, e eles disseram que iriam avaliar. Enquanto isso não se transformava em um projeto oficial, comecei a montar um ambiente de demonstração para mostrar como a solução poderia funcionar.

O WAF que montei era basicamente um cluster de máquinas Linux utilizando Linux-HA, com o qual eu já tinha experiência, rodando o servidor web Apache com suporte a HTTPS e o módulo ModSecurity, usando as regras mantidas pela OWASP. Também preparei um mecanismo para facilitar a atualização dessas regras, embora ainda houvesse bastante trabalho manual envolvido. Durante a montagem desse ambiente, acabei aprendendo mais sobre o Apache, especialmente algumas funcionalidades de monitoramento que se mostrariam importantes quando o sistema fosse para produção.

Embora tenhamos conseguido demonstrar que a arquitetura funcionava bem e oferecia boas garantias de disponibilidade, a aprovação para colocar o sistema em produção demorava a sair. Enquanto isso, continuávamos tocando outras atividades do dia a dia e projetos menores, mas eu não entendia muito bem o motivo da hesitação.

Com o passar do tempo, meu foco acabou se voltando para a organização do AppSec Brasil 2009, como já contei em um capítulo anterior. Em uma das reuniões do time de infraestrutura, surgiu a preocupação de que hospedar um congresso de segurança poderia atrair a atenção de hackers e aumentar o volume de ataques aos sistemas da Câmara, especialmente ao site principal. Nessa reunião, eu sugeri que a implantação do WAF seria uma boa forma de aumentar a proteção do site e comentei que já estávamos praticamente prontos para entrar em produção. Saí dessa reunião com a aprovação que estava esperando há bastante tempo.

A implementação foi feita de forma faseada. Na primeira fase, o WAF operava apenas em modo de registro (log only), permitindo observar o comportamento das regras e fazer ajustes sem impactar os usuários. Na segunda fase, ativamos o bloqueio e ajustamos os níveis de risco considerados aceitáveis. As regras da OWASP utilizavam um modelo baseado em pontuação, em que cada regra atribuía um score e a decisão final de bloquear ou permitir uma requisição dependia da soma desses valores. O ajuste consistia em definir a partir de qual valor o bloqueio seria aplicado.

Depois desses ajustes, a solução entrou em produção. Nos primeiros dias, começamos a enfrentar alguns problemas de acesso ao site. Foi nesse momento que precisei estudar mais a fundo o modelo de multithreading do Apache e aprender a ajustar a quantidade de workers disponíveis. Descobri também ferramentas que permitiam visualizar o estado de carga do servidor, mostrando quantos workers estavam em uso e quantos ainda estavam disponíveis. Se todos estivessem ocupados, novas requisições seriam recusadas. Por outro lado, se mantivéssemos muitos workers, poderíamos esgotar a memória disponível e comprometer o desempenho. Depois de alguns ajustes, encontramos uma configuração equilibrada e o sistema passou a operar de forma estável por um bom tempo, sem causar problemas significativos.

Nessa época, meu irmão trabalhava na Câmara Legislativa do Distrito Federal e me contou sobre um incidente em que o site deles ficou fora do ar por um período prolongado. O problema havia sido causado por uma alteração no DNS do domínio do governo do Distrito Federal (df.gov.br), que acabou removendo o subdomínio da Câmara Legislativa (cl.df.gov.br). Isso me fez perceber que, apesar da Constituição estabelecer a independência entre os poderes Executivo, Legislativo e Judiciário, na prática, na internet, essa independência não existia. Em geral, o Executivo controlava os domínios principais e, consequentemente, tinha poder sobre a presença digital dos outros poderes.

Naquela época, o Comitê Gestor da Internet no Brasil começou a anunciar a criação de novos domínios sob o .br. Pouco tempo depois surgiu o domínio .jus.br, voltado ao Judiciário. Foi então que tive a ideia de propor a criação do domínio .leg.br.

Sempre houve uma certa rivalidade entre os departamentos de informática da Câmara dos Deputados e do Senado Federal. Em geral, o Prodasen levava vantagem por ser mais antigo, mais estruturado e contar com mais recursos. Se a Câmara tomasse a iniciativa de criar o domínio .leg.br, isso poderia dar mais visibilidade à nossa área de informática. Conversei sobre a ideia com meu chefe, que me incentivou a levar essa ideia ao diretor do Centro de Informática. No entanto, o diretor não se interessou pela proposta e o assunto acabou sendo deixado de lado. Anos depois, já fora da Câmara, recebi uma mensagem do Olival, que era o chefe que havia apoiado a ideia, com um link para uma notícia anunciando a criação do domínio .leg.br. E, como era de se esperar, quem ficou responsável por ele foi o Prodasen.

Tivemos outros projetos e ideias interessantes durante esse período na Câmara, mas isso vai ficar para um próximo capítulo.