Criptografia de dados: terminologia crítica que os desenvolvedores devem conhecer

À medida que o mundo se torna cada vez mais orientado por dados, o manuseio seguro dos dados do usuário é mais crítico do que nunca.

Como desenvolvedores, nossos trabalhos já são difíceis o suficiente: lidar com sistemas altamente complexos e frágeis com vários pontos de falha enquanto traduzimos desejos humanos instáveis ​​em interfaces de usuário e back-ends. Para adicionar à tarefa é uma consideração emergente e essencial: segurança de dados. E por um bom motivo: nós, como clientes, ficamos furiosos se nossos dados forem usados ​​indevidamente (portanto, é justo dar aos nossos usuários uma experiência segura e agradável) e governos e empresas exigem isso para conformidade.

Segurança de dados como um passe de mágica

O que torna a segurança mais difícil é que ela tem várias camadas e se torna responsabilidade de todos, não é responsabilidade de ninguém. Em uma equipe de nuvem moderna, várias equipes controlam diretamente a entrada / saída de dados: desenvolvedores, administradores de banco de dados, administradores de sistemas (pessoal de DevOps, se preferir), usuários de back-office com privilégios e assim por diante. Essas funções / equipes podem fechar rapidamente os olhos e pensar na segurança de dados como o problema dos outros. Ainda assim, a realidade é que eles têm seus próprios mundos para cuidar, já que um administrador de banco de dados não pode controlar o lado do aplicativo de segurança, uma pessoa de DevOps não pode fazer absolutamente nada sobre o acesso de back office e assim por diante.

Desenvolvedores e segurança de dados

Dito isso, os desenvolvedores têm a maior área de superfície de acesso quando se trata de dados: eles criam todas as partes do aplicativo; eles se conectam a vários serviços de back-end; os tokens de acesso da balsa para frente e para trás; eles têm todo o cluster de banco de dados para leitura / gravação sob seu comando; os aplicativos que eles escrevem têm acesso inquestionável a todas as partes do sistema (por exemplo, um aplicativo Django em produção tem todos os privilégios para despejar ou limpar toda a coleção S3 dos últimos dez anos) e assim por diante. Como resultado, a maior chance de negligência ou descuido em termos de segurança existe no nível do código-fonte e é responsabilidade direta do desenvolvedor.

Agora, a segurança de dados é uma toca de coelho sem fundo, e não há como eu conseguir arranhar a superfície em uma única postagem. No entanto, quero cobrir a terminologia essencial que os desenvolvedores devem saber para manter seus aplicativos seguros. Pense nisso como App Data Security 101.

Vamos começar!

Hashing

Se você deseja uma definição altamente rigorosa, sempre existe a Wikipedia, mas em termos simples, hashing é o processo de conversão de dados para outra forma, onde a informação é ilegível. Por exemplo, usando o conhecido (e muito inseguro) processo de codificação Base64, a string “Meu segredo está seguro com você?” pode ser convertido (“hash”) para “SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U /”. Se você começar a escrever seu diário pessoal no formato Base64, por exemplo, não há como sua família ler seus segredos (a menos que eles saibam como decodificá-los em Base64)!

Essa ideia de embaralhar os dados é usada ao armazenar senhas, números de cartão de crédito, etc., em aplicativos da web (na verdade, deve ser usada em todos os tipos de aplicativos). A ideia, claro, é que, no caso de uma violação de dados, o invasor não deve ser capaz de usar as senhas, números de cartão de crédito, etc., para causar danos reais. Algoritmos altamente robustos e sofisticados são usados ​​para realizar esse hashing; algo como Base64 será uma piada e será quebrado instantaneamente por qualquer invasor.

O hashing de senha usa uma técnica criptográfica conhecida como hashing unilateral, o que significa que, embora seja possível embaralhar os dados, não é possível decodificá-los. Então, como o aplicativo sabe que é sua senha quando você faz o login? Bem, ele usa o mesmo processo e compara a forma embaralhada do que você acabou de inserir como senha com a forma embaralhada armazenada no banco de dados; se eles corresponderem, você tem permissão para fazer o login!

Já que estamos falando sobre hashes, aqui está algo interessante. Se você já fez download de software ou arquivos da Internet, pode ter sido instruído a verificar os arquivos antes de usá-los. Por exemplo, se você deseja baixar o ISO do Ubuntu Linux, a página de download mostrará uma opção para verificar seu download; se você clicar nele, um pop-up será aberto:

O pop-up diz para você executar um comando, que essencialmente vai fazer o hash de todo o arquivo que você acabou de baixar e comparar o resultado com a string hash que você vê na página de download: 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f71db46b5 . Esta conversão é realizada usando o algoritmo SHA256, cuja menção você pode ver nas partes finais do comando: shasum -a 256 --check .

A ideia é que, se o hash produzido por meio de sua verificação for diferente, isso significa que alguém interferiu em seu download e forneceu a você um arquivo comprometido.

Alguns nomes familiares que você ouvirá no domínio do hashing de senha são MD5 (inseguro e agora extinto), SHA-1 e SHA-2 (famílias de algoritmos, dos quais SHA-256 é membro, assim como SHA-512), SCRYPT, BCRYPT, etc.

Salga

Todos os tipos de segurança são um jogo de gato e rato: o ladrão aprende o sistema atual e surge com um novo crack, que é notado, e os fabricantes de fechaduras melhoram seu jogo, e assim por diante. A criptografia não é exceção. Embora a conversão de hashes de volta em senhas tenha se tornado impossível, com o tempo, os invasores desenvolveram técnicas sofisticadas que combinam suposições inteligentes com grande poder de computação; como resultado, nove vezes em dez, eles podem prever a senha correta, dado apenas o hash.

Como resultado, a técnica de salga se desenvolveu. Tudo isso significa que o cálculo de hash de uma senha (ou qualquer dado) será feito com base em uma combinação de duas coisas: os próprios dados, bem como uma nova string aleatória que o invasor não consegue adivinhar. Assim, com salting, se quisermos hash a senha superman009 , primeiro selecionaríamos uma string aleatória como um "sal", digamos, bCQC6Z2LlbAsqj77 e, em seguida, realizaríamos o cálculo de hash em superman009-bCQC6Z2LlbAsqj77 . O hash resultante se desviará das estruturas usuais produzidas pelo algoritmo, reduzindo enormemente o escopo para engenharia reversa inteligente ou suposições.

Tanto o Hashing quanto o Salting são domínios incrivelmente complicados e estão em constante evolução. Portanto, como um desenvolvedor de aplicativos, nunca lidaríamos diretamente com eles. Mas nos ajudaria muito se soubéssemos disso e pudéssemos tomar decisões melhores. Por exemplo, se você mantém uma estrutura PHP antiga e por acaso vê que ela usa hashes MD5 para senhas, sabe que é hora de inserir outra biblioteca de senhas no processo de criação da conta do usuário.

Chaves

Você costuma encontrar o termo “chaves” no contexto de criptografia. Até agora, cobrimos o hash de senha ou criptografia unilateral, em que convertemos os dados de forma irreversível e destruímos a forma original. Esta é uma má ideia para o uso prático diário - um documento escrito e enviado por e-mail com tanta segurança que nunca pode ser lido é inútil! Portanto, queremos criptografar os dados de forma que as informações sejam abertas com o remetente e o destinatário, mas durante a transferência ou o armazenamento devem ser ilegíveis.

Para isso, existe o conceito de “chave” na criptografia. É exatamente o que parece: a chave de uma fechadura. A pessoa que possui as informações as codifica usando algum segredo chamado chave. A menos que o receptor / invasor tenha essa chave, é impossível decodificar os dados, não importa o quão sofisticados sejam seus algoritmos.

Chaves Rotativas

Embora as chaves tornem a criptografia possível e confiável, elas carregam os riscos que as senhas apresentam: quando alguém conhece a chave, o jogo termina. Imagine um cenário em que alguém hackea alguma parte de um serviço como o GitHub (mesmo que por alguns segundos) e pode obter um código com 20 anos de idade. Dentro do código, eles também encontram as chaves criptográficas usadas para criptografar os dados da empresa (prática horrível de armazenar chaves junto com o código-fonte, mas você ficaria surpreso com a frequência com que isso acontece!). Se a empresa não se preocupou em alterar suas chaves (assim como as senhas), a mesma chave pode ser usada para causar estragos.

Como resultado, a prática de trocar chaves freqüentemente evoluiu. Isso é chamado de rotação de chaves e, se você estiver usando qualquer provedor de PaaS em nuvem respeitável, ele deve estar disponível como um serviço automatizado.

Por exemplo, a AWS tem um serviço dedicado para isso, chamado AWS Key Management Service (KMS). Um serviço automatizado evita o incômodo de alterar e distribuir chaves entre todos os servidores e é uma tarefa simples hoje em dia quando se trata de grandes implantações.

Criptografia de chave pública

Se toda a conversa anterior sobre criptografia e chaves faz você pensar que é altamente complicado, você está certo. Manter as chaves seguras e passá-las de forma que apenas o receptor possa ver os dados envolve problemas logísticos que não permitiriam que as comunicações seguras de hoje prosperassem. Mas tudo graças à criptografia de chave pública, podemos nos comunicar com segurança ou fazer compras online.

Esse tipo de criptografia foi um grande avanço matemático e é a única razão pela qual a Internet não está desmoronando de medo e desconfiança. Os detalhes do algoritmo são intrincados e altamente matemáticos, então só posso explicá-lo conceitualmente aqui.

A criptografia de chave pública depende do uso de duas chaves para processar informações. Uma das chaves é chamada de Chave Privada e deve permanecer privada com você e nunca ser compartilhada com ninguém; o outro é chamado de Chave Pública (de onde vem o nome do método) e deve ser publicado publicamente. Se estou enviando dados para você, primeiro preciso obter sua chave pública, criptografar os dados e enviá-los para você; ao seu lado, você pode descriptografar os dados usando sua combinação de chave privada e chave pública. Contanto que você não revele acidentalmente sua chave privada, posso enviar dados criptografados para você que só você pode abrir.

A beleza do sistema é que não preciso saber sua chave privada, e qualquer pessoa que intercepte a mensagem não pode fazer nada para lê-la, embora tenha sua chave pública. Se você está se perguntando como isso é possível, a resposta mais curta e não técnica vem das propriedades de multiplicação de números primos:

É difícil para os computadores fatorar grandes números primos. Portanto, se a chave original for muito grande, você pode ter certeza de que a mensagem não poderá ser descriptografada mesmo em milhares de anos.

Segurança da camada de transporte (TLS)

Agora você sabe como funciona a criptografia de chave pública. Esse mecanismo (conhecer a chave pública do receptor e enviar dados criptografados com ela) é o que está por trás de toda a popularidade do HTTPS e é o que faz o Chrome dizer: “Este site é seguro”. O que está acontecendo é que o servidor e o navegador estão criptografando o tráfego HTTP (lembre-se, as páginas da web são cadeias de texto muito longas que os navegadores podem interpretar) com as chaves públicas um do outro, resultando em HTTP seguro (HTTPS).

Crédito da imagem: Mozilla É interessante notar que a criptografia não acontece na camada de transporte como tal; o modelo OSI não diz nada sobre criptografar dados. É só que os dados são criptografados pelo aplicativo (neste caso, o navegador) antes de serem entregues à Camada de Transporte, que mais tarde os deixa em seu destino, onde são descriptografados. No entanto, o processo envolve a camada de transporte e, no final do dia, tudo resulta no transporte seguro de dados, então o termo vago "transporte" camada de segurança permaneceu.

Você pode até encontrar o termo Secure Socket Layer (SSL) em alguns casos. É o mesmo conceito do TLS, exceto que o SSL se originou muito antes e agora foi desativado em favor do TLS.

Criptografia de disco completo

Às vezes, as necessidades de segurança são tão intensas que nada pode ser deixado ao acaso. Por exemplo, servidores governamentais onde todos os dados biométricos de um país são armazenados não podem ser provisionados e executados como servidores de aplicativos normais, pois o risco é muito alto. Não é suficiente para essas necessidades que os dados sejam criptografados apenas durante a transferência; ele também deve ser criptografado quando em repouso. Para isso, a criptografia de disco completo é usada para criptografar todo o disco rígido para garantir a segurança dos dados, mesmo quando violados fisicamente.

É importante observar que a criptografia de disco completo deve ser feita no nível do hardware. Isso porque, se criptografarmos todo o disco, o sistema operacional também será criptografado e não poderá ser executado quando a máquina for inicializada. Portanto, o hardware deve entender que o conteúdo do disco é criptografado e deve realizar a descriptografia em tempo real à medida que passa os blocos de disco solicitados para o sistema operacional. Por causa desse trabalho extra sendo feito, o Full Disk Encryption resulta em leituras / gravações mais lentas, o que deve ser mantido em mente pelos desenvolvedores de tais sistemas.

Criptografia ponta a ponta

Com os pesadelos contínuos de privacidade e segurança de grandes redes sociais hoje em dia, ninguém ignora o termo “criptografia ponta a ponta”, mesmo que eles não tenham nada a ver com a criação ou manutenção de aplicativos.

Vimos anteriormente como a criptografia de disco completo oferece a melhor estratégia à prova de balas, mas para o usuário comum, não é conveniente. Quero dizer, imagine que o Facebook deseja que os dados do telefone que gera e armazena no seu telefone sejam seguros, mas não pode ter acesso para criptografar todo o seu telefone e bloquear todo o resto no processo.

Por esse motivo, essas empresas começaram a criptografia ponta a ponta, o que significa que os dados são criptografados quando são criados, armazenados ou transferidos pelo aplicativo. Em outras palavras, mesmo quando os dados chegam ao destinatário, eles são totalmente criptografados e só podem ser acessados ​​pelo telefone do destinatário.

Observe que a criptografia End-to-End (E2E) não traz nenhuma garantia matemática como a criptografia de chave pública; é apenas criptografia padrão em que a chave é armazenada com a empresa e suas mensagens estão tão seguras quanto a empresa decidir.

Conclusão

Você provavelmente já ouviu falar da maioria desses termos. Talvez até todos eles. Em caso afirmativo, eu o encorajaria a revisar sua compreensão desses conceitos, bem como a fazer uma avaliação de quão seriamente você os leva. Lembre-se de que a segurança de dados de aplicativos é uma guerra que você precisa vencer sempre (e não apenas uma vez), já que até mesmo uma única violação é suficiente para destruir setores inteiros, carreiras e até vidas!