Armadilhas potenciais associadas à exclusão segura de discos SSD

12

Preciso descomissionar dois discos SSD de um dos meus servidores hospedados no Linux.

A fim de dados excluir com segurança armazenados nos discos que eu estava planejando usar: hdparm --security-erase.

Eu li este documento e sugeriu não ter nenhum disco conectado ao host, além daqueles destinados à exclusão.

E este artigo destaca que, se houver erros de kernel ou firmware, esse procedimento poderá inutilizar a unidade ou travar o computador em que está sendo executado .

Este servidor está atualmente em produção, com uma configuração RAID de software para discos de produção. Não há um controlador RAID para os discos que preciso remover.

Questão:

Essa é uma operação bastante segura para executar em um ambiente de produção ou seria melhor atendida removendo os discos e executando esse procedimento em outro host?

Editar: apenas um link com um bom procedimento documentado

ssd secure-delete

— Matías
fonte

8

Simplesmente queimá-los, a sério, se a segurança é o mais importante simplesmente destruí-los com fogo, os SSDs são relativamente baratos nos dias de hoje - é a única maneira de ter certeza :)

— Chopper3

2

Com falta de nuking-los da órbita.

— Lilienthal 16/10

1

Alguém ligou?

— Lightness Races com Monica

18

O ATA Secure Erase faz parte da especificação ATA ANSI e, quando implementado corretamente , limpa todo o conteúdo de uma unidade no nível do hardware, e não através das ferramentas de software. As ferramentas de software sobrescrevem dados em discos rígidos e SSDs, geralmente através de várias passagens; o problema com os SSDs é que essas ferramentas de substituição de software não podem acessar todas as áreas de armazenamento em um SSD, deixando para trás blocos de dados nas regiões de serviço da unidade (exemplos: blocos inválidos, blocos de nível de desgaste reservados etc.)

Quando um comando ATA Secure Erase (SE) é emitido contra um controlador interno do SSD que o suporta adequadamente , o controlador SSD redefine todas as suas células de armazenamento como vazias (liberando elétrons armazenados) - restaurando assim o SSD às configurações padrão de fábrica e desempenho de gravação . Quando implementado adequadamente, o SE processará todas as regiões de armazenamento, incluindo as regiões de serviço protegidas da mídia.

Liberalmente copiado de http://www.kingston.com/us/community/articledetail?ArticleId=10 [via archive.org] , ênfase minha.

O problema é que, segundo alguns, o suporte e a implementação adequada do ATA Secure Erase pelos fabricantes estão "ausentes".

Este trabalho de pesquisa de 2011 mostra que metade dos SSDs testados na eliminação segura do ATA falharam em destruir efetivamente os dados na unidade.

Nesse mesmo trabalho de pesquisa, os testes mostraram que, surpreendentemente, para alguns, as substituições tradicionais de múltiplas passagens do SSD foram realmente bem-sucedidas, embora ainda alguns dados (possivelmente das áreas reservadas de um SSD que estão fora do tamanho relatado pelos discos) possam ser recuperados .

Portanto, a resposta curta é: o uso de software para higienizar um SSD inteiro pode ou não ser 100% eficaz.
Ainda pode ser suficiente para suas necessidades.

Segundo, fazê-lo em um servidor executando produção: Minha impressão é que a maioria dos manuais aconselha a inicialização de um disco de recuperação para limpar discos pela simples razão de que o uso de software para limpar o disco de inicialização / SO falhará miseravelmente e a maioria dos laptops e PCs possui apenas um disco único.
Os riscos universais de executar comandos potencialmente (ou melhor, intencionais) destrutivos nos sistemas de produção também se aplicam.

Criptografar suas unidades tornará muito menos provável a recuperação (parcial) de dados de discos descartados (SSDs ou do tipo rotativo). Desde que toda a unidade tenha sido criptografada e você não tenha uma partição não criptografada (swap) nela, é claro.

Caso contrário, estes sempre o triturador .

— HBruijn
fonte

8

Fundamentalmente - por causa da maneira como os SSDs funcionam - é impossível "limpar com segurança". Especialmente para drives empresariais - a maioria deles é maior do que parece em primeiro lugar, porque há capacidade 'extra' neles, para fins de nivelamento de desgaste.

Esse mesmo nivelamento de desgaste significa que a eliminação do estilo 'substituir' também não faz o que você pensa.

Em um nível bastante fundamental, depende do risco que você está preocupado:

se você quiser apenas "limpar" e reimplementar o hardware em sua propriedade: formate e termine com ele.
se você está preocupado com um adversário mal-intencionado e com bons recursos que adquire material sensível: não se preocupe em limpar, destrua fisicamente *.

(*) onde por 'destruir fisicamente' eu quero dizer destruir, incinerar e auditar. Resista à tentação de fazer bricolage - de qualquer forma, não é tão divertido nos SSDs.

— Sobrique
fonte

1

-1, não há razão para esperar que a implementação ATA Secure Erase do fornecedor do disco não apague todos os blocos.

— Andrew Medico 15/10

7

+1 de mim porque sim, existe. Veja, por exemplo, cseweb.ucsd.edu/~m3wei/assets/pdf/FMS-2010-Secure-Erase.pdf : "Os comandos de exclusão segura com base em disco não são confiáveis " (das nove combinações SSD do controlador testadas, uma recusou para apagar, dois não o apagaram corretamente e um não o fez, mas relatou que sim). Esse relatório tem alguns anos, mas significa que precisamos de razões positivas para confiar na eliminação segura moderna, em vez de apenas assumir que funciona agora.

— 21914 MadHatter

1

Eu sou paranóico. Já vi muitas ocasiões em que 'irrecuperável' não é tão irrecuperável quanto eu diria. No entanto, eu também colocaria o argumento - na maioria das vezes isso simplesmente não importa. Se você confia vagamente para onde está indo, e o conteúdo não é incrivelmente sensível, não faz muita diferença. E se é incrivelmente sensível, por que você está deixando sair do prédio em primeiro lugar?

— Sobrique 15/10

1

Devo acrescentar que é não impossível. Mas você precisaria confiar na implementação do fabricante, pois não pode fazê-lo de maneira confiável usando apenas os comandos do setor de gravação.

— the-wabbit 16/10

6

Certamente, eu não recomendaria iniciar operações de apagamento seguro em um sistema que possua qualquer unidade com a qual você se preocupe ainda conectado. Basta um pequeno erro de digitação para destruir os dados de uma unidade ainda em uso, além de qualquer esperança de recuperação.

Se você estiver usando o Secure Erase, faça-o definitivamente em um sistema que não possui nenhuma unidade conectada.

— Andrew Medico
fonte