O mito da exclusão segura: recuperando dados na área de overprovisioning de SSDs NVMe

Você executou um dd if=/dev/zero no disco. O sistema operacional reportou sucesso. O auditor de segurança assinou o relatório de descarte. No entanto, em uma análise forense de baixo nível, acabamos de extrair fragmentos de bancos de dados e chaves privadas desse mesmo drive.

A crença de que sobrescrever dados lógicos garante a destruição física é um artefato da era dos discos rotacionais (HDD). Em dispositivos baseados em NAND Flash, como SSDs e NVMes, o sistema operacional não dita onde os dados são gravados; ele apenas faz sugestões que o controlador do disco pode — e frequentemente vai — ignorar em nome da performance e longevidade.

Se você gerencia infraestrutura de armazenamento e confia em ferramentas de software para sanitização de dados, você está deixando um rastro digital recuperável. Vamos dissecar a arquitetura do firmware para entender onde esses dados se escondem.

Resumo em 30 segundos

A mentira do LBA: Ferramentas como dd ou shred escrevem em endereços lógicos (LBA), mas o controlador do SSD redireciona essas gravações para novos blocos físicos, deixando os dados antigos intactos na área de Overprovisioning.

Imunidade ao OS: O sistema operacional não tem acesso direto à área reservada do SSD. Dados movidos para lá pelo Garbage Collection ou Wear Leveling são invisíveis ao fdisk ou sistemas de arquivos.

A única saída: Apenas comandos de firmware nativos da especificação NVMe (como Sanitize) podem instruir o controlador a limpar fisicamente todas as células de memória, incluindo caches e blocos realocados.

O rastro digital invisível: recuperando arquivos após um zero-fill

Quando analisamos um dump físico de um chip NAND, frequentemente encontramos dados que o sistema de arquivos jura terem sido apagados. O culpado é a camada de abstração conhecida como FTL (Flash Translation Layer).

Em um HDD, se você pede para gravar no setor 100, a cabeça de leitura vai até o setor 100 físico e sobrescreve o campo magnético. Em um SSD NVMe, se você pede para gravar no LBA 100, o FTL consulta sua tabela de mapeamento. Se o LBA 100 já contém dados, o controlador não sobrescreve o bloco físico original imediatamente. A natureza da memória NAND exige que um bloco seja apagado antes de ser gravado novamente, e o processo de apagar (erase) é lento e desgastante.

Para evitar latência, o controlador grava os novos dados (os zeros do seu dd) em um novo bloco físico vazio e atualiza o ponteiro do LBA 100 para esse novo local. O bloco físico antigo, contendo seus dados sensíveis, é marcado como "inválido" (stale), mas sua carga elétrica permanece intacta. Ele agora reside no limbo digital inacessível pelo OS, aguardando um ciclo de Garbage Collection que pode demorar horas ou dias para ocorrer.

Figura: O abismo entre a visão lógica e física: enquanto o OS vê zeros, o FTL preserva os dados originais em blocos marcados para reciclagem futura.

Anatomia do firmware: como o wear leveling protege dados na área de overprovisioning

A área de Overprovisioning (OP) não é um defeito; é uma necessidade física. Trata-se de uma porção da capacidade bruta da NAND (geralmente entre 7% a 28% do total) invisível ao usuário, reservada para operações de manutenção.

O algoritmo de Wear Leveling (nivelamento de desgaste) usa essa área agressivamente. Como cada célula de memória tem uma vida útil limitada de ciclos de escrita/apagamento (P/E cycles), o firmware rotaciona os dados estáticos para blocos menos usados.

💡 Dica Pro: Em SSDs Enterprise (como as séries Intel/Solidigm D7 ou Samsung PM1733), a área de OP é significativamente maior para sustentar altas taxas de IOPS de escrita aleatória. Ironicamente, quanto melhor a performance e durabilidade do seu drive, maior a área onde dados antigos podem se esconder de uma formatação padrão.

Durante uma investigação forense, se conseguirmos acessar o modo de depuração do controlador (frequentemente via interfaces JTAG ou exploits de firmware proprietário), podemos despejar o conteúdo bruto desses blocos de OP. Lá encontramos fragmentos de arquivos que foram "sobrescritos" meses atrás. O Wear Leveling moveu o dado original para preservar o bloco, e o Garbage Collection ainda não havia limpado aquele setor específico.

A ilusão da segurança via software

Ferramentas clássicas de destruição de dados foram projetadas para mídias magnéticas. O comando shred no Linux, por exemplo, faz múltiplas passagens de dados aleatórios. Em um SSD, isso é contraproducente.

Ao forçar múltiplas escritas, você está apenas consumindo ciclos P/E e forçando o controlador a alocar mais blocos físicos frescos, empurrando ainda mais dados antigos para a fila de invalidação na área de OP. Você não está limpando o dado; está espalhando-o fisicamente pelos chips NAND.

Tabela comparativa: eficácia de métodos de sanitização

Método	Mecanismo	Eficácia em HDD	Eficácia em SSD/NVMe	Risco Forense
Zero-fill (`dd`)	Sobrescrita Lógica	Alta	Baixa	Alto (Dados no OP/Cache recuperáveis)
Gutmann/Shred	Múltiplas Passagens	Alta	Nula/Prejudicial	Crítico (Acelera desgaste, não apaga OP)
Format NVM	Reinício de Metadados	Média	Média	Médio (Depende da implementação do vendor)
Sanitize (Block)	Apagamento de Tensão	N/A	Total	Nulo (Limpa células físicas e OP)
Sanitize (Crypto)	Troca de Chave	N/A	Total	Nulo (Dados tornam-se ruído entrópico)

Execução soberana: invocando os comandos sanitize

Para garantir a exclusão segura, precisamos parar de falar com o Sistema de Arquivos e começar a falar com o Controlador NVMe. A especificação NVM Express (a partir da revisão 1.3 e refinada na 1.4/2.0) define o comando Sanitize como a autoridade suprema para purga de dados.

Diferente do Format NVM (que muitas vezes apenas descarta a tabela de tradução, permitindo recuperação se a tabela for reconstruída), o Sanitize opera em nível de hardware. Ele instrui o firmware a aplicar pulsos de voltagem para resetar todas as células de memória para o estado original (geralmente todas '1's ou todas '0's), incluindo a área de Overprovisioning, buffers de escrita e tabelas de mapeamento.

Existem três modos principais de Sanitize definidos pela especificação:

Block Erase: Executa um apagamento de baixo nível em todos os blocos de memória. É lento, mas fisicamente definitivo.
Crypto Erase: Instrui o controlador a descartar a chave de criptografia de mídia (MEK) e gerar uma nova. O processo é quase instantâneo (milissegundos). Os dados cifrados permanecem na NAND, mas tornam-se matematicamente irrecuperáveis sem a chave.
Overwrite: Escreve um padrão de dados fixo em toda a mídia. Diferente do dd, este comando é gerenciado pelo controlador, garantindo que áreas ocultas também sejam atingidas.

Figura: O fluxo de autoridade: como o comando Sanitize contorna as filas de I/O de usuário e força o controlador a executar uma limpeza física global.

Procedimento cirúrgico com nvme-cli

Para executar isso em um ambiente Linux, utilizamos o pacote nvme-cli. Não aceite interfaces gráficas; use o terminal para ter certeza do feedback.

Primeiro, verifique quais modos seu dispositivo suporta:

nvme id-ctrl /dev/nvme0 | grep -i sanicap

O campo sanicap (Sanitize Capabilities) é um bitmask. Se o bit 1 estiver ativo (0x2 ou superior), o Block Erase é suportado. Se o bit 0 estiver ativo, o Crypto Erase é suportado.

Para invocar um Block Erase (cuidado, isso é irreversível e destrói tudo):

nvme sanitize /dev/nvme0n1 -a 2

Onde -a 2 especifica a ação de Block Erase. Para Crypto Erase, usaríamos -a 4.

⚠️ Perigo: O comando Sanitize persiste entre reinicializações. Se você desligar o servidor no meio do processo, o controlador retomará a limpeza assim que receber energia novamente. O drive ficará inacessível até a conclusão.

Auditoria final: interpretando o log page de status

Um investigador não confia na mensagem "Success" do terminal. Precisamos interrogar o dispositivo sobre o status real da operação. A especificação NVMe define a página de log 0x81 (Sanitize Status Information).

Podemos ler este log com:

nvme sanitize-log /dev/nvme0

O output crítico aqui é o sstat (Sanitize Status). Devemos buscar um valor que indique conclusão sem erros. Além disso, o campo sprog (Sanitize Progress) deve mostrar 65535 (ou 100% dependendo da formatação da ferramenta) se finalizado.

Se o campo sstat retornar um valor indicando "Completed Successfully" e o contador de "Global Data Erased" tiver sido incrementado nos logs SMART, temos uma garantia criptográfica e física de que os dados na área de Overprovisioning foram aniquilados.

Figura: A prova final: o Log Page 0x81 confirma que o firmware completou o ciclo de limpeza, validando a destruição dos dados na área reservada.

O fim da recuperação por software

A densidade de armazenamento está aumentando com tecnologias QLC e PLC (Penta-Level Cell), tornando a gestão de erros e o Overprovisioning ainda mais críticos para a sobrevivência dos dados. Consequentemente, a quantidade de "dados fantasmas" residindo fora do alcance do sistema de arquivos só tende a crescer.

Se sua política de segurança da informação ainda prescreve formatação lógica ou sobrescrita via software para descarte de SSDs, você está vulnerável. A única barreira real entre seus segredos corporativos e um leitor de NAND em um laboratório forense é a execução correta dos comandos de firmware. Atualize seus playbooks de decommissioning para exigir nvme sanitize e audite os logs resultantes. O resto é apenas teatro de segurança.

Referências & Leitura Complementar

NVM Express Base Specification 2.0: Seção sobre Sanitize Operations e Admin Command Set.
NIST Special Publication 800-88 Rev. 1: Guidelines for Media Sanitization (Foca nas distinções entre Clear, Purge e Destroy).
JEDEC JESD218: Solid-State Drive (SSD) Requirements and Endurance Test Method (Para entender a mecânica de desgaste e retenção de dados).

Perguntas Frequentes (FAQ)

Por que o comando dd não apaga totalmente um SSD?

O comando dd atua na camada lógica (LBA) visível ao sistema operacional. Controladores de SSD modernos usam compressão e deduplicação, e movem dados antigos para a área de overprovisioning (inacessível ao OS) para gestão de desgaste, deixando cópias recuperáveis fisicamente.

O que é a área de overprovisioning em um NVMe?

É uma porção da capacidade bruta da memória NAND Flash reservada exclusivamente para o controlador do SSD. Ela é usada para Garbage Collection, Wear Leveling e substituição de blocos defeituosos, sendo invisível para o sistema de arquivos e ferramentas de formatação padrão.

Qual a diferença entre Format NVM e Sanitize?

O Format NVM geralmente apenas reinicia a tabela de mapeamento lógico, permitindo recuperação forense. O comando Sanitize instrui o firmware a executar uma limpeza física (Block Erase) ou criptográfica (Crypto Erase) em todas as células de memória, incluindo a área de overprovisioning e caches.