Scrivi una volta, leggi molti (WORM) usando il file system Linux

8

Ho l'obbligo di scrivere file su un file system Linux che non possono essere successivamente sovrascritti, aggiunti, aggiornati in alcun modo o eliminati. Non da un sudo-er, da root o da nessuno. Sto tentando di soddisfare i requisiti delle normative sui servizi finanziari per la tenuta dei registri, FINRA 17A-4, che in sostanza richiede che i documenti elettronici siano scritti su dispositivi WORM (scrivere una volta, leggere molti). Mi piacerebbe molto evitare di dover utilizzare DVD o costosi dispositivi EMC Centera.

Esiste un file system Linux o SELinux può supportare il requisito per rendere i file completi immutabili immediatamente (o almeno presto) dopo la scrittura? O qualcuno è a conoscenza di un modo in cui potrei applicarlo su un file system esistente usando le autorizzazioni di Linux, ecc.?

Comprendo che posso impostare le autorizzazioni di sola lettura e l'attributo immutabile. Ma ovviamente mi aspetto che un utente root sia in grado di disinserirli.

Ho considerato di archiviare i dati su piccoli volumi che sono stati smontati e quindi rimontati in sola lettura, ma poi penso che root possa ancora smontare e rimontare come scrivibile di nuovo.

Sto cercando idee intelligenti, e nel peggiore dei casi sono disposto a fare un po 'di codice per "migliorare" un file system esistente per fornire questo. Supponendo che esista un file system che sia un buon punto di partenza. E mettere in atto un server Linux accuratamente configurato per agire come questo tipo di dispositivo di archiviazione di rete, senza fare altro.

Dopotutto, anche la crittografia sui file sarebbe utile!

— phil_ayres
fonte

4

Quello che stai chiedendo non può essere fatto. Se si dispone dell'accesso root alla macchina, è possibile eseguire operazioni a livello di blocco direttamente sul disco. Quindi non importa quale sia il filesystem in cima, non puoi proteggere nulla dal root, puoi solo rallentarlo o renderlo così oscuro da sembrare sicuro.

— Regan,

Dopo aver letto l'interpretazione della SEC sec.gov/rules/interp/34-47806.htm concordo con @Regan. Tuttavia, tutta questa faccenda è leggermente assurda. Ad esempio, come si cancella un CD? Con il fuoco, ovviamente.

— Mark Wagner,

Concordo pienamente sul fatto che i requisiti siano "leggermente assurdi". Stanno cercando di rendere così ovvio che c'è stato un tentativo di nascondere la verità che nessun ragazzo IT sarebbe d'accordo nel fare ciò che un bravo dirigente sta chiedendo. Colpire la cancellazione su una grande directory come root era apparentemente troppo facile per qualcuno. La distruzione fisica diventa l'unico modo per nascondere le cose nelle regole della SEC.

— phil_ayres,

chattr + i nomefile, devi dare questo comando ogni volta che crei un file

— c4f4t0r

@ c4f4t0r non si ferma: chattr -i filenamequindi rm

— phil_ayres,

2

Puoi fare questo con OpenAFS e volumi di sola lettura. Tuttavia, è necessario installare molte infrastrutture per farlo funzionare e potrebbe non soddisfare i requisiti.

http://www.openafs.org/

Fondamentalmente, c'è un volume scrivibile e una o più copie di sola lettura del volume. Fino a quando non si rilascia il volume scrivibile, le copie di sola lettura sono immutabili per i client. Il rilascio del volume richiede i privilegi di amministratore.

Sembra che qualsiasi soluzione richiederebbe un hardware specializzato o un file system di rete che duplica la semantica dell'hardware specializzato.

— Fred il Magic Wonder Dog
fonte

OpenAFS impedisce effettivamente al root di scrivere nel volume di sola lettura. Non sono riuscito a trovare una definizione definitiva nei documenti.

— phil_ayres,

Certamente impedisce a root sul client di scrivere sui volumi ro. Generalmente root non implica alcuna autorizzazione speciale in OpenAFS.

— Fred the Magic Wonder Dog,

1

Sembra che non ci sia modo di farlo senza scrivere il file system personalizzato / il codice del kernel.

Una soluzione praticabile sembra essere l'utilizzo di Amazon Glacier con l'opzione di archiviazione degli archivi WORM. Secondo il blog ufficiale di AWS all'indirizzo: https://aws.amazon.com/blogs/aws/glacier-vault-lock/

[...] una nuova funzionalità Glacier che ti consente di bloccare il tuo vault con una varietà di controlli di conformità progettati per supportare questo importante caso d'uso di conservazione dei record. Ora è possibile creare un criterio di blocco del Vault su un Vault e bloccarlo. Una volta bloccato, il criterio non può essere sovrascritto o eliminato. Glacier applicherà la politica e proteggerà i tuoi record in base ai controlli (incluso un periodo di conservazione predefinito) ivi specificato.

Non è possibile modificare il criterio Blocco Vault dopo averlo bloccato. Tuttavia, è ancora possibile modificare e configurare i controlli di accesso non correlati alla conformità utilizzando un criterio di accesso al vault separato. Ad esempio, è possibile concedere l'accesso in lettura a partner commerciali o terze parti designate (come talvolta richiesto dalla normativa).

Per me, questo fornisce esattamente ciò che è necessario senza le spese dell'hardware NetApp o EMC, mentre sembra soddisfare i requisiti di conservazione dei record.

— phil_ayres
fonte

Non c'è alcuna differenza logica dalla mia soluzione. L'amministratore del server, in questo caso Amazon, può comunque cancellare o manomettere alcuni o tutti i file. L'unica differenza qui è il provider di archiviazione file ...?

— nrc,

Hai esattamente ragione nel ritenere che il provider di archiviazione sia la vera differenza. Con un amministratore del server interno, il regolatore ritiene che possano essere manipolati da una persona più anziana nella stessa organizzazione per eliminare o modificare i record. Certo, potresti chiedere a qualcuno di Amazon di distruggere tutto, ma il presupposto è che ci sarà una scia di carta e ci sono maggiori possibilità che una richiesta inaspettata venga respinta. Non buono quanto l'impegno formale, ma separare le responsabilità fornisce gran parte della protezione necessaria.

— phil_ayres,

1

Puoi comunque eliminare i file cessando di pagare per l'archiviazione.

— Tomas Zubiri,

0

Se devi semplicemente accedere ai file da un sistema in cui gli utenti non possono sovrascriverli, puoi montare un volume remoto su cui non hai i permessi di scrittura. Il modo più semplice per farlo è montare una condivisione samba / cifs di sola lettura.

Altrimenti, se hai bisogno di un modo per consentire agli utenti di scrivere nuovi file (che non possono essere sovrascritti o modificati), una soluzione è montare un percorso FTP con FUSE curlftpfs.

Puoi impostare la tua directory proftpd con queste direttive:

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

In questo modo i nuovi file possono essere memorizzati nella directory montata, ma non possono più essere modificati o rimossi.

collegamenti: CurlFtpFS , ProFTPD

— NRC
fonte

Capisco quello che stai dicendo, e certamente sembra essere un'opzione. Ma se sono l'amministratore del file server posso eliminare qualsiasi cosa. L'obiettivo è impedire anche agli amministratori (almeno quelli senza accesso alle unità fisiche) di eliminare i file.

— phil_ayres,

Il server FTP funge da dispositivo WORM economico. Sì, l'amministratore del server FTP remoto può accedere ai file e modificarli. Una soluzione è firmare il file alla sua creazione, con un sistema di chiavi asimmetrico, per impedire a qualsiasi amministratore di sistema di fare confusione con i file. Un amministratore può ancora cancellare i file ma non può più modificare il file senza essere notato.

— nrc,

Sfortunatamente, solo firmare il file per dimostrare (la mancanza di) manomissione è insufficiente secondo i registri SEC. Da qui la domanda su come rendere i file completamente immutabili.

— phil_ayres,

0

Questa è una variazione del problema " Backup irreversibile " e l'unico modo per implementarlo è con più file system worm remoti che utilizzano e condividono checksum e non hanno accesso fisico o amministrativo condiviso. Questo assicura che tutto sia scritto una volta, duplicato, verificabile integrità e nel caso in cui un singolo blocco venga cancellato, modificato o corrotto, recuperabile.

Plan9 o suoi derivati possono implementare tutte le funzionalità richieste. Vedi Plan9 e Venti

— Daniel Matthews
fonte