Fundamentos da computação em nuvem
Criptografia e proteção de dados
Como a criptografia em repouso e a criptografia em trânsito protegem os dados em pontos diferentes do seu trajeto, como o gerenciamento de chaves torna dados criptografados inúteis para quem não tem permissão, e onde termina a proteção da criptografia.
- Distinguir criptografia em repouso de criptografia em trânsito e identificar qual ponto de uma solicitação cada uma protege
- Explicar como AES-256 e TLS correspondem, respectivamente, à proteção em repouso e em trânsito
- Descrever o modelo de isolamento por trás dos serviços de gerenciamento de chaves e por que ele separa o acesso aos dados do acesso às chaves
- Comparar um serviço de chaves gerenciado com um módulo de segurança de hardware dedicado, e identificar quando cada um se encaixa
- Corrigir o equívoco de que a criptografia sozinha substitui a necessidade de controle de acesso
O mesmo arquivo, dois riscos diferentes
Um engenheiro de suporte, investigando um problema, captura o tráfego de rede entre uma aplicação e seu banco de dados enquanto está sentado em uma cafeteria. Se essa conexão não estiver criptografada, o engenheiro, ou qualquer outra pessoa na mesma rede Wi-Fi rodando a mesma captura, consegue ler toda senha e todo campo passando por ela, em texto puro, no exato momento em que acontece.
Agora imagine um momento bem diferente: meses depois, um disco de backup desativado desse mesmo banco de dados é vendido ou descartado sem ser apagado direito, e alguém conecta ele em um computador. Se os dados ali nunca foram criptografados, essa pessoa consegue ler tudo direto do disco, sem precisar de nenhuma captura de rede.
Mesmo dado, 2 pontos de ataque completamente diferentes, meses de distância um do outro. Proteger contra um não faz nada contra o outro, e é exatamente por isso que plataformas de nuvem tratam os 2 como controles separados: criptografia em trânsito para dados em movimento, e criptografia em repouso para dados parados.
Criptografia em repouso: AES-256 e criptografia do lado do servidor
Criptografia em repouso protege dados gravados em armazenamento, discos, backups, arquivos de banco de dados, de forma que qualquer pessoa que acesse o meio de armazenamento físico ou lógico sem autorização veja só texto cifrado ilegível. O mecanismo padrão em todo grande provedor de nuvem é o AES-256, a cifra de bloco Advanced Encryption Standard de 256 bits, aplicada automaticamente ou sob demanda aos dados assim que são gravados.
A AWS chama sua abordagem padrão de criptografia do lado do servidor: o próprio serviço de armazenamento criptografa os dados antes de gravar e descriptografa na saída, tudo dentro do serviço, usando chaves gerenciadas por um sistema de gerenciamento de chaves. Um cliente normalmente não toca na cifra diretamente; ele escolhe uma opção de gerenciamento de chaves, e o serviço de armazenamento cuida do resto.
Criptografia em trânsito: TLS
Criptografia em trânsito protege dados enquanto eles se movem entre 2 pontos em uma rede, um app mobile e um servidor, um load balancer e uma instância de aplicação, um microsserviço e outro. O mecanismo padrão é o TLS, Transport Layer Security, que envolve uma conexão de forma que qualquer pessoa capturando o tráfego de rede bruto veja só texto cifrado, nunca a solicitação ou a resposta em si.
Desde meados de 2024, todo endpoint de API da AWS exige no mínimo TLS 1.2 e aceita TLS 1.3, a versão mais nova e mais rápida do protocolo. Essa base reflete um padrão da indústria inteira: versões mais antigas de TLS e o protocolo que veio antes dele, o SSL, vão sendo aposentadas conforme fragilidades criptográficas se acumulam, e a orientação atual continua empurrando o mínimo aceito para frente.
A lacuna no meio: dados em uso
Repare no que nenhuma das 2 proteções cobre. Assim que uma solicitação chega ao servidor de aplicação, os dados precisam ser descriptografados na memória, brevemente, para a aplicação de fato fazer alguma coisa com eles: rodar um cálculo, renderizar uma página, verificar uma condição. Esse estado temporário na memória às vezes é chamado de dados em uso, e ele fica fora do alcance da criptografia padrão em repouso e em trânsito. É um problema mais estreito e mais especializado, e é por isso que "criptografado em todo lugar" é uma simplificação: criptografia em repouso e em trânsito cobrem a esmagadora maioria do trajeto de uma solicitação, mas não o instante em que a aplicação está trabalhando ativamente com o texto puro.
Gerenciamento de chaves: separando quem descriptografa de quem guarda a chave
Criptografar dados é só metade do problema; controlar quem consegue descriptografá-los é a outra metade, e isso é o que um serviço de gerenciamento de chaves faz. O AWS KMS roda dentro de módulos de segurança de hardware construídos para que chaves em texto puro nunca saiam do módulo, nem mesmo para os próprios funcionários da AWS. Uma solicitação para criptografar ou descriptografar algo é autorizada de forma independente pelas mesmas permissões de IAM cobertas na lição anterior, o que significa que o acesso aos dados e o acesso à chave que os destranca são 2 camadas controladas separadamente. Comprometer uma não entrega a outra automaticamente, e todo uso de uma chave fica registrado, dando uma trilha auditável de exatamente quando e por quem um dado foi descriptografado.
A fronteira: serviço de chaves gerenciado versus hardware dedicado
A maioria das cargas de trabalho usa um serviço de chaves gerenciado como o AWS KMS: hardware compartilhado, multi-tenant, atrás de uma API simples, com a AWS cuidando do provisionamento, dos patches e da disponibilidade. Algumas cargas de trabalho, geralmente por um requisito regulatório específico, precisam de um módulo de segurança de hardware dedicado, como o AWS CloudHSM, dando ao cliente controle administrativo direto sobre hardware single-tenant que só ele gerencia. A regra de decisão é estreita: use o serviço gerenciado por padrão, e recorra ao hardware dedicado só quando um requisito de conformidade exigir especificamente controle single-tenant, já que essa opção troca conveniência por uma carga de escalonamento e administração que passa a ser do cliente.
Equívoco: criptografia substitui controle de acesso
É tentador tratar "está tudo criptografado" como o fim da conversa sobre segurança. Não é. Criptografia protege os dados contra alguém que rouba o meio de armazenamento ou intercepta o tráfego de rede sem autorização. Ela não faz nada para impedir alguém que já tem credenciais válidas e autorizadas, seja um funcionário legítimo ou um atacante que phishou uma, de ler dados que essa pessoa tem permissão para acessar, porque o próprio propósito da criptografia é que o acesso autorizado a descriptografa corretamente. Essa é exatamente a lacuna que os controles de IAM da lição anterior existem para fechar, e as 2 proteções são pensadas para trabalhar juntas, não para substituir uma a outra.
Dicas para a prova: em repouso ou em trânsito
| O cenário diz... | Aponta para |
|---|---|
| "Dados gravados em disco", "armazenados", "um arquivo de backup" | Criptografia em repouso |
| "Viajando pela rede", "entre cliente e servidor", "uma chamada de API" | Criptografia em trânsito |
| "Controlar quem pode usar uma chave", "autorizado a descriptografar" | Gerenciamento de chaves, não a criptografia em si |
| "Hardware single-tenant", "controle administrativo direto do HSM" | Módulo de segurança de hardware dedicado |
Onde isso deixa você
Criptografia em repouso e criptografia em trânsito protegem o mesmo dado em 2 pontos diferentes do seu trajeto, e um projeto completo precisa das 2, já que cobrir só uma deixa a outra totalmente aberta. Nenhuma das 2, porém, decide quem tem permissão para pedir esse dado, para começo de conversa; esse trabalho ficou com o gerenciamento de identidade e acesso na lição anterior. Juntos, os 2 controles respondem "quem pode agir" e "o que acontece se um disco ou uma rede forem comprometidos mesmo assim". A próxima lição vira para uma pergunta relacionada: como um time prova, para um auditor ou um regulador, que os 2 controles estão realmente em vigor.