No início era o verbo…

A informação é o fomento do conhecimento; e quem a detém é capaz de planejar suas estratégias de modo a conseguir uma vantagem competitiva. Para ajudar você, desenvolvedor, nesse processo de planejamento, vamos fazer um breve histórico do desenvolvimento da segurança da informação, questionar a relação e a importância que a segurança tem hoje, e qual será seu papel em um futuro próximo.

Para iniciarmos, vamos dar um pulo ao passado e ver como surgiu a criptografia.

Passado

Dizem que a criptografia não é algo novo, mas, sim, uma técnica em constante aperfeiçoamento. Ela nasceu com o Hebreus, 600 anos antes de Cristo. Após este período, por volta de 800 anos depois de Cristo, nasceu a criptoanálise, que tinha o intuito de decifrar códigos baseados na criptografia hebraica. Depois disso, no início da I Guerra Mundial, Alexander´s Weekly escreveu um ensaio sobre métodos de criptografia que foi muito útil aos britânicos para quebrar os códigos dos alemães.

Um dos exemplos históricos mais capazes de demonstrar o poder que a segurança da informação possui é a máquina Enigma, desenvolvida e patenteada por Arthur Scherbius, em 1918. Naquela época, o seu potencial ainda era totalmente desconhecido. Em 1926, a Alemanha adaptou a máquina para o uso militar, dando-a o nome de Funkschlussel C. Já em

1928, os alemães a aperfeiçoaram, chamando-a de Enigma G, ou “A máquina M”, que tinha o intuito de codificar e decodificar mensagens. A ideia era que se algum soldado da Alemanha fosse pego com a mensagem, ou algum exército inimigo interceptasse o seu sinal, ela não serviria de nada, já que o inimigo não conseguiria ler a informação. A Enigma era, na época, um ícone da segurança da informação, principalmente no que se diz respeito a indecifrabilidade do código.

Entretanto, resumindo a história, alguns matemáticos e mestres em xadrez, como Newman e Turing, conseguiram quebrar o código. Dizem os historiadores que a Segunda Guerra Mundial terminou um ano antes do “previsto” por conta deste fato. Sendo assim, os alemães criaram a primeira máquina a utilizar a “one time pad” (cifra de chave única), e os ingleses criaram o primeiro computador digital programável, chamado de Colossus.

Presente

Agora, para falar um pouco do presente, é preciso dar vários pulos no tempo.

Nós, profissionais de TI, sabemos da necessidade da proteção da informação. Sempre que desenvolvemos uma aplicação, é preciso pensar em como proteger as informações que ali trafegam; e para que isso se desenvolva com sucesso, é necessário termos três itens em mente: confidencialidade, integridade e disponibilidade.

Além disso, é preciso também se preocupar com a proteção do código em si; em como o usuário vai interagir com o código e quais partes devem ser transparentes, ou as demais aplicações e APIs que também podem interagir com o nosso código.

Hoje, existe uma grande dificuldade em se proteger uma aplicação. Isso ocorre pela falta de conhecimento das tecnologias de segurança disponíveis, mas não só. Sempre que optamos por bloquear algo, proteger uma classe, um banco de dados ou um kernel, nós desenvolvedores engessamos a aplicação de alguma forma. E isso, normalmente, desencadeia uma diminuição de performance, queda da experiência do usuário, aumento de custos, problemas de usabilidade, dentre outros.

Possibilidades, provocações e tecnologias

Existem diversas maneiras de balancear estas preocupações. Os microsserviços, por exemplo, são uma maneira de proteger a sua aplicação e equilibrar a performance.

Estranho pensar assim, já que este não é o objetivo dos microsserviços, certo?! Mas pense no princípio dos microsserviços. Eles devem ser independentes, autônomos, de baixo acoplamento e de alta coesão. Fica fácil entender como esta infraestrutura em si só já é uma estrutura baseada em segurança. Faça um paralelo.

Imagine o seguinte: você faz a avaliação de riscos de segurança, identifica os requisitos de segurança e balanceia os gastos relativos aos danos causados por alguma quebra na segurança. Agora você pensa em microsserviços e separa as funcionalidades de negócio do cerne da aplicação. Você consegue enxergar que está protegendo a sua aplicação, impossibilitando que um requisito funcional quebre seu código? Quando um arquiteto opta por um sistema de microsserviços, uma escolha crucial a se fazer é o modelo de concorrência que será utilizado. Escolher este modelo e o modo como ele se conecta ao banco de dados é uma maneira inteligente de tratar os trade-offs de maneira arquitetural, levando em consideração a eficiência e a complexidade.

A maneira como você decompõe seu serviço em operações paralelas e com recursos compartilhados definirá a eficiência da aplicação. Aqui, a complexidade do seu código é fundamental para que a paralelização das operações e dos recursos seja capaz de manter a segurança do seu banco de dados e a performance da sua aplicação. Assim, com essa estratégia, é possível deixar a aplicação mais rápida, visto que fica mais fácil balancear servidores, acessos e processamento.

APIs também são um ótimo exemplo de como fazer sua aplicação conversar com outras sem abrir portas desnecessárias. Com as APIs, é possível facilitar a programação de uma aplicação, expondo uma série de ferramentas necessárias, métodos de programação e protocolos. Mas o importante aqui é não deixar o código e o backend vulneráveis. Como você abriu uma porta específica para a comunicação, fica claro que ela precisa de uma defesa bem estruturada, e isso vale não apenas para a sua API, mas para todo o caminho em que os dados trafegam. E muitas empresas e developers não estão se preocupando com isso como deveriam.

Ao desenvolver uma API para uso interno, tende-se a se preocupar menos com autenticações, acessos, dentre outros. Entretanto, muitas vezes acaba-se por reutilizar esta mesma API de uma maneira externa. Sendo assim, o importante é desenvolver mecanismos de segurança desde o início.

Se você optar por utilizar uma API privada, por exemplo, pensando que é preciso uma segurança mais parruda, dada a sensibilidade dos dados trafegados na rede, e utilizar comunicação via HTTPS, que é o básico da segurança, já é possível se proteger contra-ataques do tipo man in the middle, por exemplo, visto que temos uma criptografia bilateral entre cliente e servidor. Porém isto ainda não é suficiente. Além disso, é preciso ter cuidado para saber se a solução de gestão de API possui algum tipo de certificação como FIP 140-2 e Common Criteria, por exemplo. Também é necessário ficar atento à proteção contra ataques diretos e ameaças REST e SOAP. Ou seja, ao desenvolver uma API internamente, consegue-se manter o controle da segurança totalmente implementado pela infraestrutura, se assim o quiser.

Uma API mal desenhada pode expor todo o cerne da nossa aplicação e permitir acessos e ações maliciosos. Temos um exemplo de uma empresa nacional de anúncio de vagas que sofreu um ataque por deixar que os dados da sua API fossem visualizados e extraídos com facilidade. Por outro lado, mesmo que sua API esteja bem desenhada, é necessário que a integração com outros sistemas ou APIs sejam previstos afim de garantir a segurança da sua aplicação.

Por falar em tecnologias de segurança como HTTPS, existem muitas outras disponíveis atualmente no mercado: Token based authorization, criptografia, autorização HTTP basic, autenticação HTTP Digest, ssh, firewalls, sistemas de controle de acesso, sistemas UTM, OAuth, entre outros. O banco original, por exemplo, que está entrando fortemente no mercado das fintechs, trabalha uma de suas APIs utilizando uma solução OAuth, que permite aos desenvolvedores solicitarem autorização para acessar as informações disponíveis por outras APIs em seu nome, sem que os usuários precisem fornecer dados pessoais para darem estas permissões.

E aquela tal de criptografia dos tempos de Noé?

Embora seja um conceito antigo, como visto anteriormente, a criptografia ainda trabalha fortemente no mercado. Um bom exemplo é o processo transparente utilizado na criptografia fim a fim do WhatsApp. Agora as informações não podem ser interceptadas, lidas e nem modificadas enquanto estiverem em trânsito, é o que garante a empresa. E isto serve não apenas para mensagem de texto, mas também para vídeos e áudio. Essa tecnologia já é utilizada em serviços bancários, e agora foi adaptada ao serviço de comunicação, o que acabou popularizando o seu conhecimento.

Entretanto, a criptografia tem se desenvolvido muito com o passar dos tempos. E com base nesta visão evolucionária da tecnologia, atualmente os pesquisadores já pensam em um tipo de criptografia chamada pós quânticas – um ramo da criptografia que estuda classes de algoritmos criptográficos resistentes à criptoanálise quântica. Dentro desse contexto, temos os algoritmos baseados em hash, látice, código, entre outros.

O algoritmo baseado em hash é antigo e bem popular entre os desenvolvedores, entretanto são facilmente quebrados por força bruta com um custo de operação de O(n²), na qual n é o número de bits empregados pela função. Dentro deste modelo, temos dois algoritmos bem conhecidos como o algoritmo Lamport-Diffie e a árvore de Merkle.

O Lamport-Diffie usa duas funções básicas, uma função não-inversível f: {0,1}ⁿ → {0,1}ⁿ e uma função de resumo g: {0,1}^* → {0,1}ⁿ onde n é a robustez desejada. Além disso, o algoritmo também utiliza uma chave de assinatura de A de 2n² bits e uma chave de verificação B de mesmo tamanho. O problema deste tipo de criptografia é que a cada nova troca de mensagens, novas chaves precisam ser geradas e trocadas.

Outra aplicação da criptografia é o novo paradigma de banco de dados: o chamado blockchain, que é uma das plataformas mais seguras devido ao seu modelo descentralizado. Desenvolvido a princípio para ser utilizado em transações de criptomoedas, atualmente já é utilizado com outros objetivos, como visto nesta edição, no artigo do João Paulo Oliveira.

Parece estranho descentralizar a informação? Pensando bem, não é. Basicamente, nenhuma atitude contra o sistema pode ser tomada sem que a maioria dos nós concorde com ela. Assim, fraudes e ataques são menos efetivos, mas isso não garante 100% da sua defesa.

Deixando o presente…

Nessa breve passagem pelo presente, podemos ver que existem muitas tecnologias, novos paradigmas, novas maneiras de pensar sobre os conceitos antigos. Mas, principalmente, conseguimos identificar a evolução que tivemos. Antes, existia uma estrutura monolítica, que se desenvolveu para microsserviços; as APIs e APIs gateways que fornecem comunicação de modo a proteger a sua aplicação e também o desenvolvimento e a atualização da criptografia e a descentralização da informação.

Antigamente, havia apenas alguns firewalls e criptografias fracas, mas o desenvolvimento da ciência da computação e da web, permitiu aos desenvolvedores brincar com as tecnologias e os conceitos, criando novas formas de enxergar a segurança e suas inúmeras aplicações.

Futuro

Atualmente, muito se fala em smart cities, IoT e inteligência artificial, que é onde o conceito da segurança mais tem tirado o sono dos especialistas. E este nem é um cenário tão futurístico assim… O Gartner prevê que até 2020, mais de 50% dos processos de negócios e sistemas incorporem algum elemento de IoT.

A gama de dispositivos pendurados na rede e a quantidade de informações sensíveis que irão trafegar na Internet será astronômica. E isso não é exagero, algumas pessoas falam até que não se usará mais terabytes para quantificar o tamanho desses dados, mas, sim, uma “nova medida”, baseada na distância entre a Terra e a Lua.

Mas sejamos um pouco práticos: você acredita que hoje a sua empresa gasta muito tempo para desenvolver um projeto? Ou você trabalha em uma empresa com metodologia Agile que emprega a entrega contínua e não precisa se preocupar com isso? Bom, acredito que independente da sua metodologia, ou modelo de negócio, isso irá mudar. O Gartner aposta que em 2018, 75% dos projetos deverão demorar o dobro do tempo para serem implementados. Segundo algumas previsões da empresa, para que os deadlines sejam cumpridos, alguns projetos podem deixar a desejar em segurança, performance ou em processos de integração legados. E o que isso acarreta? Que você terá que desenvolver todo o seu projeto do zero se estiver com pressa e não se preocupar com a segurança da sua aplicação.

Já que estamos abordando um pouco do tema de IoT para falar de segurança da informação no futuro, vamos pensar no básico. Para que as aplicações e sistemas funcionem neste cenário, são necessários dados que alimentem as aplicações, como é preciso hoje em dia. Neste futuro, os dados virão de sensores que estarão plugados everywhere. Na sua casa, no seu trabalho, no trânsito e até mesmo em você. Aliás, principalmente em você. E o que esses sensores tem a ver com segurança?

O Gartner também prevê que em 2020 haverá um mercado negro de sensores falsificados e dados de vídeos que ultrapassarão a marca de 5 bilhões de dólares. Isso te leva a pensar nas implicações de segurança e privacidade que a exposição desses dados causará. Imagine se estes dados sensíveis, ou não, se perderem. Imagina se eles não estiverem bem protegidos e forem expostos.

Ted Friedman, vice-presidente da Gartner em entrevista para um canal de tecnologia nacional avisa: “Um mercado negro com sensores e dados de vídeo falsos ou corruptos significará que a informação pode ser comprometida ou substituída por informação deliberadamente manipulada e imprecisa. Este cenário vai impulsionar o crescimento de produtos e serviços de privacidade, resultando numa discussão pública e longa sobre o futuro da privacidade, sobre os meios para proteger a privacidade individual e sobre o papel da tecnologia e do governo na proteção da mesma”.

Você consegue enxergar quantos pontos da sociedade a falta de segurança da informação afetará em um futuro próximo? Pessoas, governos, indústrias, empresas, leis, comércios, relacionamentos e por aí vai…

A falta de planejamento fará com que o problema se torne uma bola de neve. Haverá gastos excessivos, trabalhos repetitivos, demora na entrega dos projetos, exposição de dados sensíveis, pessoais ou empresariais, interrupção de serviços na área industrial e em áreas estratégicas, além de problemas com cyber segurança, invasão e cyber espionagem.

Vamos nos planejar?

Então, você pode perceber que é preciso planejar e discutir antes de colocar a mão na massa. Existe um projeto chamado “Securing Smart Cities” que visa atender os desafios de cyber segurança por meio da colaboração e do compartilhamento de informações. Além disso, existem inúmeros fóruns e comunidades dedicadas exclusivamente a área de segurança. Não é preciso pensar apenas em IoT ou smart cities, podemos pensar a segurança hoje, de modo a torná-la cada vez melhor e escalável.

E tornar a segurança uma realidade do desenvolvimento, cabe a nós, desenvolvedores. Entretanto, é necessário termos a ciência do negócio em que estamos inseridos para que tenhamos uma maior empatia com todo o fluxo da operação.

Nós do iMasters, acreditamos que o profissional de tecnologia tem de estar cada vez mais próximo das camadas superiores das empresas, e que essa hierarquia deva ser cada vez mais horizontal. Isso auxilia as empresas a tomarem decisões mais assertivas quanto ao rumo dos negócios. Trazer estes profissionais para próximo, promover discussões, hackathons, criar comunidades, fomentar o conhecimento e visar a melhoria continua, fará com que a comunidade se desenvolva como um todo, gere mais conhecimento e desenvolva uma cultura colaborativa cada vez mais forte para que estejamos preparados para os desafios do futuro. Que a força esteja com vocês, jovens padawans!

***

Artigo publicado originalmente na Revista iMasters #19