Écrivez une fois, lisez plusieurs (WORM) en utilisant le système de fichiers Linux

8

J'ai une obligation d'écrire des fichiers dans un système de fichiers Linux qui ne peuvent pas être par la suite écrasés, ajoutés, mis à jour de quelque manière que ce soit ou supprimés. Pas par un sudo-er, un root ou n'importe qui. J'essaie de répondre aux exigences de la réglementation des services financiers pour la tenue des dossiers, FINRA 17A-4, qui exige essentiellement que les documents électroniques soient écrits sur des appareils WORM (écrire une fois, lire plusieurs). J'aimerais bien éviter d'avoir à utiliser des DVD ou des appareils EMC Centera coûteux.

Existe-t-il un système de fichiers Linux ou SELinux peut-il prendre en charge l'exigence selon laquelle les fichiers doivent être rendus immuables immédiatement (ou au moins bientôt) après l'écriture? Ou est-ce que quelqu'un sait comment je pourrais appliquer cela sur un système de fichiers existant en utilisant des autorisations Linux, etc.?

Je comprends que je peux définir des autorisations en lecture seule et l'attribut immuable. Mais bien sûr, je m'attends à ce qu'un utilisateur root puisse les annuler.

J'ai envisagé de stocker des données sur de petits volumes qui sont démontés puis remontés en lecture seule, mais je pense que root pourrait toujours démonter et remonter en tant qu'écriture.

Je suis à la recherche d'idées intelligentes et, dans le pire des cas, je suis prêt à faire un peu de codage pour «améliorer» un système de fichiers existant afin de fournir cela. En supposant qu'il existe un système de fichiers qui constitue un bon point de départ. Et mettez en place un serveur Linux soigneusement configuré pour agir comme ce type de périphérique de stockage réseau, sans rien faire d'autre.

Après tout cela, le cryptage des fichiers serait également utile!

— phil_ayres
source

4

Ce que vous demandez ne peut pas être fait. Si vous disposez d'un accès root à la machine, vous pouvez effectuer des opérations au niveau des blocs directement sur le disque. Donc, peu importe quel système de fichiers est en haut, vous ne pouvez rien protéger contre root, vous pouvez seulement le ralentir ou le rendre si obscur qu'il semble sécurisé.

— Regan

Après avoir lu l'interprétation SEC sec.gov/rules/interp/34-47806.htm, je suis d'accord avec @Regan. Cependant, tout cela est un peu absurde. Par exemple, comment effacer un CD? Avec le feu, bien sûr.

— Mark Wagner

Je suis absolument d'accord que les exigences sont «légèrement absurdes». Ils essaient de rendre cela si évident qu'il y a eu une tentative de cacher la vérité qu'aucun informaticien n'accepterait de faire ce qu'un mauvais dirigeant demande. Frapper supprimer sur un grand répertoire en tant que root était apparemment trop facile pour quelqu'un. La destruction physique devient le seul moyen de dissimuler les choses dans les règles de la SEC.

— phil_ayres

chattr + i filename, vous devez donner cette commande chaque fois que vous créez un fichier

— c4f4t0r

@ c4f4t0r ne s'arrête pas: chattr -i filenamealors rm

— phil_ayres

2

Vous pouvez en quelque sorte le faire avec OpenAFS et les volumes en lecture seule. Cependant, il y a beaucoup d'infrastructure à installer pour le faire fonctionner et peut ne pas répondre aux exigences.

http://www.openafs.org/

Fondamentalement, il existe un volume inscriptible et une ou plusieurs copies en lecture seule du volume. Jusqu'à ce que vous libériez le volume inscriptible, les copies en lecture seule ne peuvent pas être modifiées par les clients. La libération du volume nécessite des privilèges d'administrateur.

Il semble que toute solution nécessite un matériel spécialisé ou un système de fichiers réseau qui duplique la sémantique du matériel spécialisé.

— Fred le chien magique
source

OpenAFS empêche-t-il réellement root d'écrire sur le volume en lecture seule. Je n'ai pas pu trouver de définition définitive dans les documents.

— phil_ayres

Cela empêche certainement root sur le client d'écrire sur les volumes ro. En règle générale, root n'implique aucune autorisation spéciale dans OpenAFS.

— Fred the Magic Wonder Dog

1

Il semble qu'il n'y ait aucun moyen de le faire sans écrire du code de système de fichiers / noyau personnalisé.

Une solution viable semble consister à utiliser Amazon Glacier avec l'option de stockage d'archives WORM. Selon le blog officiel AWS sur: https://aws.amazon.com/blogs/aws/glacier-vault-lock/

[...] une nouvelle fonctionnalité Glacier qui vous permet de verrouiller votre coffre-fort avec une variété de contrôles de conformité conçus pour prendre en charge cet important cas d'utilisation de la conservation des enregistrements. Vous pouvez maintenant créer une stratégie de verrouillage du coffre-fort sur un coffre-fort et le verrouiller. Une fois verrouillée, la politique ne peut pas être remplacée ou supprimée. Glacier appliquera la politique et protégera vos enregistrements conformément aux contrôles (y compris une période de conservation prédéfinie) qui y sont spécifiés.

Vous ne pouvez pas modifier la stratégie de verrouillage du coffre-fort après l'avoir verrouillée. Cependant, vous pouvez toujours modifier et configurer les contrôles d'accès qui ne sont pas liés à la conformité en utilisant une stratégie d'accès au coffre-fort distincte. Par exemple, vous pouvez accorder un accès en lecture à des partenaires commerciaux ou à des tiers désignés (comme l'exige parfois la réglementation).

Pour moi, cela fournit exactement ce qui est nécessaire sans les frais de matériel NetApp ou EMC, tout en semblant répondre aux exigences de conservation des enregistrements.

— phil_ayres
source

Il n'y a aucune différence logique avec ma solution. L'administrateur du serveur, dans ce cas Amazon, peut toujours effacer ou falsifier certains ou tous les fichiers. La seule différence ici est le fournisseur de stockage de fichiers ...?

— nrc

Vous avez exactement raison dans votre supposition que le fournisseur de stockage est la vraie différence. Avec un administrateur de serveur interne, le régulateur pense qu'ils peuvent être manipulés par une personne plus âgée dans la même organisation pour supprimer ou modifier des enregistrements. Bien sûr, vous pouvez demander à quelqu'un d'Amazon de tout détruire, mais l'hypothèse est qu'il y aura une trace papier et qu'il y a de meilleures chances qu'une demande inattendue soit rejetée. Pas tout à fait aussi bon que le séquestre formel, mais la séparation des responsabilités fournit une grande partie de la protection nécessaire.

— phil_ayres

1

Vous pouvez toujours supprimer les fichiers en cessant de payer pour le stockage.

— Tomas Zubiri

0

Si vous avez simplement besoin d'accéder à des fichiers à partir d'un système dans lequel les utilisateurs ne peuvent pas les remplacer, vous pouvez monter un volume distant sur lequel vous n'avez aucune autorisation d'écriture. La façon la plus simple de le faire est de monter un partage samba / cifs en lecture seule.

Sinon, si vous avez besoin d'un moyen pour permettre aux utilisateurs d'écrire de nouveaux fichiers (qui ne peuvent pas être remplacés ou modifiés), une solution consiste à monter un chemin FTP avec FUSE curlftpfs.

Vous pouvez définir votre répertoire proftpd avec ces directives:

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

De cette façon, de nouveaux fichiers peuvent être stockés dans le répertoire monté, mais ils ne peuvent plus être modifiés ou supprimés.

liens: CurlFtpFS , ProFTPD

— nrc
source

Je comprends ce que vous dites, et cela semble certainement être une option. Mais si je suis l'administrateur du serveur de fichiers, je peux tout supprimer. L'objectif est d'empêcher même les administrateurs (du moins ceux qui n'ont pas accès aux disques physiques) de supprimer des fichiers.

— phil_ayres

Le serveur FTP agit comme un appareil WORM bon marché. Mais oui, l'administrateur du serveur FTP distant peut accéder aux fichiers et les modifier. Une solution consiste à signer le fichier lors de sa création, avec un système de clé asymétrique, pour empêcher tout administrateur système de jouer avec les fichiers. Un administrateur peut toujours effacer les fichiers mais ne peut plus le modifier sans être remarqué.

— nrc

Malheureusement, la simple signature du fichier pour démontrer (l'absence de) falsification est insuffisante selon les règlements de la SEC. D'où la question de rendre les fichiers complètement immuables.

— phil_ayres

0

Il s'agit d'une variante du problème de la « sauvegarde infaillible » et la seule façon de l'implémenter est d'utiliser plusieurs systèmes de fichiers de vers distants qui utilisent et partagent des sommes de contrôle et n'ont pas d'accès physique ou d'administration partagé. Cela garantit que tout est écrit une fois, dupliqué, que l'intégrité peut être prouvée et, dans le cas où un seul bloc est effacé, modifié ou corrompu, récupérable.

Plan9 ou ses dérivés peuvent implémenter toutes les fonctionnalités requises. Voir Plan9 et Venti

— Daniel Matthews
source