À 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 bastante difíceis: lidar com sistemas altamente complexos e frágeis com vários pontos de falha enquanto traduzimos desejos humanos esvoaçantes 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 são mal utilizados (portanto, é justo oferecermos aos nossos usuários uma experiência segura e agradável), e governos e empresas exigem isso para conformidade.
últimas postagens
Segurança de dados como passagem de dinheiro
O que torna a segurança mais difícil é que ela tem várias camadas e se torna a responsabilidade de todos é a 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 sistema (pessoal de DevOps, se preferir), usuários de back-office privilegiados e assim por diante. Essas funções/equipes podem rapidamente fechar os olhos e pensar na segurança dos dados como um 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 da segurança do aplicativo, uma pessoa de DevOps não pode fazer absolutamente nada sobre o acesso administrativo e assim por diante.
Desenvolvedores e segurança de dados
Dito isso, os desenvolvedores têm a maior área de acesso quando se trata de dados: eles constroem todas as partes do aplicativo; eles se conectam a vários serviços de back-end; os tokens de acesso à balsa para frente e para trás; eles têm todo o cluster de banco de dados para ler/gravar 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 desleixo ou descuido em termos de segurança existe no nível do código-fonte e é responsabilidade direta do desenvolvedor.
Agora, segurança de dados é uma toca de coelho sem fundo, e não há como eu arranhar a superfície em um único post. No entanto, quero abordar a terminologia essencial que os desenvolvedores devem conhecer para manter seus aplicativos seguros. Pense nisso como App Data Security 101.
Vamos começar!
Hash
Se você quer uma definição altamente rigorosa, há sempre Wikipédia, mas em termos simples, hash é o processo de conversão de dados para outro formato, onde as informações são ilegíveis. Por exemplo, usando o conhecido (e muito inseguro) processo de Codificação Base64, a string “Meu segredo está seguro com você?” pode ser convertido (“hashed”) para “SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U/”. Se você começar a escrever seu diário pessoal no formato Base64, por exemplo, sua família não conseguirá ler seus segredos (a menos que eles saibam como decodificar 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, deveria ser usado em todos os tipos de aplicativos). A ideia, é claro, é que no caso de uma violação de dados, o invasor não possa usar senhas, números de cartão de crédito etc. para causar danos reais. Algoritmos altamente robustos e sofisticados são usados para executar esse hash; algo como Base64 será uma piada e será quebrado instantaneamente por qualquer invasor.
O hash de senha usa uma técnica criptográfica conhecida como hash unidirecional, o que significa que, embora seja possível embaralhar os dados, não é possível decifrá-los. Então, como o aplicativo sabe que é sua senha quando você faz login? Bem, ele usa o mesmo processo e compara a forma codificada do que você acabou de inserir como senha com a forma codificada armazenada no banco de dados; se forem iguais, você pode fazer login!
Enquanto estamos no tópico de 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 fará o hash de todo o arquivo que você acabou de baixar e comparará o resultado com a string de hash que você vê na página de download: 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f71db46b5. Essa conversão é realizada usando o Algoritmo SHA256cuja menção você pode ver nas partes finais do comando: shasum -a 256 –check.
A ideia é que, se o hash produzido por sua verificação for diferente, isso significa que alguém se intrometeu 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, das 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 cria uma nova brecha, que é notada, e os fabricantes de fechaduras aprimoram seu jogo, e assim por diante. A criptografia não é exceção. Embora a conversão de hashes em senhas tenha se tornado impossível, os invasores desenvolveram técnicas sofisticadas ao longo do tempo que combinam adivinhação inteligente com poder de computação absoluto; como resultado, nove vezes dez, eles podem prever a senha correta, considerando apenas o hash.
“Senhor. Rumpelstiltskin, presumo?!”
Como resultado, a técnica de salga se desenvolveu. Tudo o que 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. Portanto, com salting, se quisermos fazer o hash da senha superman009, primeiro selecionaremos uma string aleatória como um “salt”, digamos, bCQC6Z2LlbAsqj77 e, em seguida, executaremos o cálculo de hash em superman009-bCQC6Z2LlbAsqj77. O hash resultante se desviará das estruturas usuais produzidas pelo algoritmo, reduzindo bastante o escopo para engenharia reversa inteligente ou adivinhação.
Tanto o Hashing quanto o Salting são domínios incrivelmente complicados e estão em constante evolução. Portanto, como desenvolvedor de aplicativos, nunca lidaríamos diretamente com eles. Mas nos ajudaria muito se conhecêssemos isso e pudéssemos tomar melhores decisões. Por exemplo, se você mantiver um framework PHP antigo e perceber que ele usa hashes MD5 para senhas, você sabe que é hora de inserir outra biblioteca de senhas no processo de criação da conta do usuário.
Chaves
Você encontraria o termo “chaves” frequentemente no contexto de criptografia. Até agora, cobrimos hashing de senha ou criptografia unidirecional, onde convertemos os dados de forma irreversível e destruímos a forma original. Esta é uma má ideia para uso prático diário – um documento escrito e enviado por e-mail com tanta segurança que nunca pode ser lido não serve para nada! Assim, queremos criptografar os dados de forma que desejemos que as informações sejam abertas com o remetente e o destinatário, mas enquanto estiverem sendo transferidas ou armazenadas, devem ser ilegíveis.
Para isso, existe o conceito de “chave” na criptografia. É exatamente o que parece: a chave para uma fechadura. A pessoa que possui a informação a embaralha usando algum segredo chamado chave. A menos que o receptor/atacante tenha essa chave, é impossível decifrar os dados, por mais sofisticados que sejam seus algoritmos.
Chaves rotativas
Embora as chaves tornem a criptografia possível e confiável, elas carregam os riscos das senhas: quando alguém conhece a chave, todo o jogo acaba. Imagine um cenário em que alguém hackeia alguma parte de um serviço como o GitHub (mesmo que por alguns segundos) e consegue obter um código de 20 anos atrás. Dentro do código, eles também encontram as chaves criptográficas usadas para criptografar os dados da empresa (prática horrível para 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 mudar as chaves com frequência 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.
Crédito da imagem: AWS
Por exemplo, a AWS tem um serviço dedicado para isso chamado Serviço de gerenciamento de chaves da AWS (KMS). Um serviço automatizado evita o incômodo de alterar e distribuir chaves entre todos os servidores e é um acéfalo 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 é muito complicado, você está certo. Manter as chaves seguras e passá-las para que apenas o destinatário possa ver os dados gera 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. o detalhes do algoritmo são complexos e altamente matemáticos, então só posso explicá-los conceitualmente aqui.
Crédito da imagem: The Electronic Frontier Foundation
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; a outra é chamada Public Key (de onde vem o nome do método) e deve ser publicada publicamente. Se estou enviando dados para você, primeiro preciso obter sua chave pública, criptografar os dados e enviá-los para você; do 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 eu não preciso saber sua chave privada, e qualquer pessoa que intercepte a mensagem não pode fazer nada para lê-la, mesmo que 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 da multiplicação de números primos:
É difícil para os computadores fatorar números primos grandes. Portanto, se a chave original for muito grande, você pode ter certeza de que a mensagem não poderá ser descriptografada nem 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 destinatário e enviar dados criptografados usando isso) é o que está por trás de toda a popularidade do HTTPS e é o que faz com que o Chrome diga: “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 sequências 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; a modelo OSI não diz nada sobre a criptografia de dados. Só que os dados são criptografados pelo aplicativo (neste caso, o navegador) antes de serem transferidos para a Camada de Transporte, que posteriormente os deixa em seu destino, onde são descriptografados. No entanto, o processo envolve a Camada de Transporte e, no final das contas, tudo resulta em transporte seguro de dados, de modo que o termo vago “segurança da camada de transporte” permaneceu por aí.
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 substituído pelo 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 do governo 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 basta para essas necessidades que os dados sejam criptografados apenas na hora da transferência; ele também deve ser criptografado quando estiver em repouso. Para isso, a criptografia de disco completo é usada para criptografar a totalidade de um disco rígido para garantir que os dados estejam seguros mesmo quando violados fisicamente.
É importante observar que a criptografia de disco completo deve ser feita no nível do hardware. Isso porque, se criptografarmos o disco inteiro, o sistema operacional também será criptografado e não poderá ser executado quando a máquina for iniciada. Portanto, o hardware precisa entender que o conteúdo do disco está criptografado e deve executar a descriptografia em tempo real, à medida que passa os blocos de disco solicitados para o sistema operacional. Devido a esse trabalho extra sendo feito, Full Disk Encryption resulta em leituras/gravações mais lentas, que devem ser lembradas pelos desenvolvedores de tais sistemas.
Criptografia de ponta a ponta
Com os constantes pesadelos de privacidade e segurança das grandes redes sociais hoje em dia, ninguém desconhece o termo “criptografia de ponta a ponta”, mesmo que não tenha nada a ver com a criação ou manutenção de aplicativos.
Vimos anteriormente como Full Disk Encryption fornece 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 ele gera e armazena em 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 iniciaram a criptografia de 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 podem ser acessados apenas pelo telefone do destinatário.
Crédito da imagem: Google
Observe que a criptografia de ponta a ponta (E2E) não traz nenhuma garantia matemática como a criptografia de chave pública; é apenas uma criptografia padrão em que a chave é armazenada com a empresa e suas mensagens sã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 rever sua compreensão desses conceitos, bem como a avaliar a seriedade com que os leva. Lembre-se, a segurança de dados de aplicativos é uma guerra que você precisa vencer todas as vezes (e não apenas uma vez), pois até mesmo uma única violação é suficiente para destruir setores, carreiras e até vidas inteiras!