Escreva uma vez, leia muitos (WORM) usando o sistema de arquivos Linux

8

Eu tenho um requisito para gravar arquivos em um sistema de arquivos Linux que não possa ser substituído posteriormente, anexado, atualizado de qualquer forma ou excluído. Não por um sudoer, root ou qualquer pessoa. Estou tentando atender aos requisitos dos regulamentos de serviços financeiros para manutenção de registros, FINRA 17A-4, que basicamente exige que documentos eletrônicos sejam gravados em dispositivos WORM (escreva uma vez, leia muitos). Eu gostaria muito de evitar o uso de DVDs ou dispositivos caros do EMC Centera.

Existe um sistema de arquivos Linux ou o SELinux pode suportar o requisito de que os arquivos sejam concluídos imutáveis imediatamente (ou pelo menos em breve) após a gravação? Ou alguém está ciente de como eu poderia aplicar isso em um sistema de arquivos existente usando permissões do Linux, etc?

Entendo que posso definir permissões somente leitura e o atributo imutável. Mas é claro que espero que um usuário root possa desmarcá-los.

Pensei em armazenar dados em pequenos volumes desmontados e remontados somente leitura, mas acho que a raiz ainda pode desmontar e remontar como gravável novamente.

Estou procurando idéias inteligentes e, na pior das hipóteses, estou disposto a fazer um pouco de codificação para 'aprimorar' um sistema de arquivos existente para fornecer isso. Supondo que exista um sistema de arquivos que seja um bom ponto de partida. E crie um servidor Linux cuidadosamente configurado para atuar como esse tipo de dispositivo de armazenamento em rede, sem fazer mais nada.

Depois de tudo isso, a criptografia nos arquivos também seria útil!

— phil_ayres
fonte

4

O que você está perguntando não pode ser feito. Se você tiver acesso root à máquina, poderá executar operações em nível de bloco diretamente no disco. Portanto, não importa qual sistema de arquivos está no topo, você não pode proteger nada da raiz, você pode apenas abrandá-lo ou torná-lo tão obscuro que parece seguro.

— Regan

Depois de ler a interpretação da SEC sec.gov/rules/interp/34-47806.htm, eu vou concordar com @Regan. No entanto, tudo isso é um pouco absurdo. Por exemplo, como se apaga um CD? Com fogo, é claro.

— Mark Wagner

Concordo absolutamente que os requisitos são "ligeiramente absurdos". Eles estão tentando tornar tão óbvio que houve uma tentativa de esconder a verdade que nenhum funcionário de TI concordaria em fazer o que um executivo não bom está pedindo. Pressionar delete em um diretório grande como root era aparentemente fácil demais para alguém. A destruição física se torna a única maneira de encobrir as coisas nas regras da SEC.

— phil_ayres

chattr + i nome de arquivo, você precisa dar este comando cada vez que você criar um arquivo

— c4f4t0r

@ c4f4t0r não para: chattr -i filenamedepois rm

— phil_ayres 12/01

2

Você pode fazer isso com o OpenAFS e volumes somente leitura. É necessário instalar muita infraestrutura para fazê-lo funcionar e pode não atender aos requisitos.

http://www.openafs.org/

Basicamente, há um volume gravável e uma ou mais cópias somente leitura do volume. Até você liberar o volume gravável, as cópias somente leitura são imutáveis para os clientes. A liberação do volume requer privilégios de administrador.

Parece que qualquer solução exigiria hardware especializado ou um sistema de arquivos de rede que duplique a semântica do hardware especializado.

— Fred, o Cão Maravilha Mágico
fonte

O OpenAFS realmente impede que a raiz grave no volume somente leitura. Não consegui encontrar uma definição definitiva nos documentos.

— phil_ayres

Certamente evita que a raiz do cliente grave nos volumes ro. Geralmente, o root não implica nenhuma permissão especial no OpenAFS.

— Fred, o cão da maravilha mágica

1

Parece que não há como fazer isso sem escrever código do sistema de arquivos / kernel personalizado.

Uma solução viável parece ser usar o Amazon Glacier com a opção de armazenamento de arquivo WORM. De acordo com o Blog oficial da AWS em: https://aws.amazon.com/blogs/aws/glacier-vault-lock/

[...] um novo recurso Glacier que permite bloquear seu cofre com uma variedade de controles de conformidade projetados para suportar esse importante caso de uso de retenção de registros. Agora você pode criar uma política de bloqueio de cofre em um cofre e bloqueá-la. Uma vez bloqueada, a política não pode ser substituída ou excluída. O Glacier aplicará a política e protegerá seus registros de acordo com os controles (incluindo um período de retenção predefinido) especificados nela.

Você não pode alterar a política de bloqueio de cofre depois de bloqueá-la. No entanto, você ainda pode alterar e configurar os controles de acesso que não estão relacionados à conformidade usando uma política de acesso ao cofre separada. Por exemplo, você pode conceder acesso de leitura a parceiros de negócios ou terceiros designados (conforme exigido por regulamentação).

Para mim, isso fornece exatamente o que é necessário sem as despesas do hardware da NetApp ou da EMC, enquanto parece atender aos requisitos de retenção de registros.

— phil_ayres
fonte

Não há diferença lógica da minha solução. O administrador do servidor, neste caso a Amazon, ainda pode apagar ou adulterar alguns ou todos os arquivos. A única diferença aqui é o provedor de armazenamento de arquivos ...?

— Nrc 21/10

Você está certo ao supor que o provedor de armazenamento é a verdadeira diferença. Com um administrador de servidor interno, o regulador acredita que eles podem ser manipulados por uma pessoa mais experiente na mesma organização para excluir ou alterar registros. Obviamente, você pode pedir a alguém na Amazon que destrua tudo, mas a suposição é de que haverá uma trilha de papel e há uma chance maior de que uma solicitação inesperada seja rejeitada. Não é tão bom quanto o compromisso formal, mas a separação de responsabilidades fornece grande parte da proteção necessária.

— Phil_ayres 31/10/16

1

Você ainda pode excluir os arquivos deixando de pagar pelo armazenamento.

— Tomas Zubiri

0

Se você simplesmente precisar acessar arquivos de um sistema no qual os usuários não possam substituí-los, poderá montar um volume remoto no qual você não tem permissão de gravação. A maneira mais fácil de fazer isso é montar um compartilhamento samba / cifs somente leitura.

Caso contrário, se você precisar de uma maneira de permitir que os usuários gravem novos arquivos (que não podem ser substituídos ou modificados), uma solução é montar um caminho de FTP com o FUSE curlftpfs.

Você pode definir seu diretório proftpd com estas diretivas:

AllowOverwrite off
<Limit WRITE>
  DenyAll
</Limit>
<Limit STOR>
  AllowAll
</Limit>

Dessa maneira, novos arquivos podem ser armazenados no diretório montado, mas não podem mais ser modificados ou removidos.

links: CurlFtpFS , ProFTPD

— nrc
fonte

Entendo o que você está dizendo e certamente parece ser uma opção. Mas se eu sou o administrador do servidor de arquivos, posso excluir qualquer coisa. O objetivo é impedir que mesmo os administradores (pelo menos aqueles sem acesso às unidades físicas) excluam arquivos.

— phil_ayres

O servidor FTP atua como um dispositivo WORM barato. Mas sim, o administrador do servidor FTP remoto pode acessar os arquivos e alterá-los. Uma solução é assinar o arquivo em sua criação, com um sistema de chaves assimétricas, para impedir que qualquer administrador do sistema possa mexer nos arquivos. Um administrador ainda pode apagar os arquivos, mas não pode mais modificá-lo sem ser notado.

— Nrc

Infelizmente, apenas assinar o arquivo para demonstrar (falta de) adulteração é insuficiente, de acordo com os registros da SEC. Daí a questão de tornar os arquivos completamente imutáveis.

— phil_ayres

0

Essa é uma variação do problema " Backup infalível " e a única maneira de implementá-lo é com vários sistemas de arquivos worm remotos que usam e compartilham somas de verificação e não têm acesso físico ou administrativo compartilhado. Isso garante que tudo seja gravado uma vez, duplicado, com integridade comprovável e, no caso de um único bloco ser apagado, alterado ou corrompido, recuperável.

O Plan9 ou seus derivados podem implementar todos os recursos necessários. Veja Plan9 e Venti

— Daniel Matthews
fonte