Question Écrire une fois, lire plusieurs (WORM) à l'aide du système de fichiers Linux


J'ai l'obligation d'écrire des fichiers sur un système de fichiers Linux qui ne peuvent pas être ultérieurement remplacés, ajoutés, mis à jour de quelque manière que ce soit ou supprimés. Pas par un sudo-er, root ou quiconque. J'essaie de respecter les exigences de la réglementation des services financiers en matière d'archivage, FINRA 17A-4, qui exige essentiellement que les documents électroniques soient écrits sur des périphériques WORM (écrire une fois, en lire plusieurs). J'aimerais beaucoup éviter de devoir utiliser des DVD ou des périphériques EMC Centera coûteux.

Existe-t-il un système de fichiers Linux ou SELinux peut-il prendre en charge la nécessité de rendre les fichiers complets immuables immédiatement (ou du moins bientôt) après l'écriture? Ou est-ce que quelqu'un est au courant d'une façon dont je pourrais appliquer cela sur un système de fichiers existant en utilisant les autorisations Linux, etc.?

Je comprends que je peux définir des autorisations en lecture seule et l'attribut immuable. Mais bien sûr, je pense qu'un utilisateur root pourra les supprimer.

J'ai envisagé de stocker des données sur de petits volumes non montés, puis remontés en lecture seule, mais je pense que cette racine pourrait toujours être démontée et remontée en écriture.

Je recherche des idées intelligentes et, dans le pire des cas, je suis disposé à coder un peu pour "améliorer" un système de fichiers existant afin de fournir cela. En supposant qu’il existe un système de fichiers qui soit 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!


8
2017-10-25 21:08


origine


Ce que vous demandez ne peut pas être fait. Si vous avez un accès root à la machine, vous pouvez effectuer des opérations au niveau du bloc directement sur le disque. Ainsi, peu importe le système de fichiers qui se trouve en haut, vous ne pouvez rien protéger de la racine, vous ne pouvez que le ralentir ou le rendre si obscur qu’il semble sécurisé. - Regan
Après avoir lu l'interprétation de la SEC sec.gov/rules/interp/34-47806.htm Je vais être d'accord avec @Regan. Cependant, tout cela est légèrement absurde. Par exemple, comment efface-t-on un CD? Au feu, bien sûr. - Mark Wagner
Je suis tout à fait d’accord pour dire que les exigences sont «légèrement absurdes». Ils essaient de faire comprendre si clairement qu'il y a eu une tentative de dissimulation de 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 racine é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 nomfichier, vous devez donner cette commande chaque fois que vous créez un fichier - c4f4t0r
@ c4f4t0r n'arrête pas: chattr -i filename alors rm - phil_ayres


Réponses:


Vous pouvez en quelque sorte le faire avec OpenAFS et les volumes en lecture seule. Il faut cependant beaucoup d’infrastructures à installer pour que cela fonctionne et risque de ne pas répondre aux exigences.

http://www.openafs.org/

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

Il semble que toute solution nécessiterait un matériel spécialisé ou un système de fichiers réseau reproduisant la sémantique d'un matériel spécialisé.


2
2017-10-26 03:07



Est-ce que OpenAFS empêche réellement root d’écrire sur le volume en lecture seule? Je n'ai pas pu trouver de définition définitive dans la documentation. - phil_ayres
Cela empêche certainement la racine sur le client d'écrire dans les volumes de ro. En règle générale, root n'implique aucune autorisation spéciale dans OpenAFS. - Fred the Magic Wonder Dog


Il semble qu’il n’ya aucun moyen de le faire sans écrire du code système / noyau personnalisé.

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

[...] une nouvelle fonctionnalité Glacier qui vous permet de verrouiller votre coffre-fort avec un   variété de contrôles de conformité conçus pour prendre en charge cette   cas d'utilisation important de la conservation des enregistrements. Vous pouvez maintenant créer un verrou de coffre   politique sur un coffre-fort et le verrouiller. Une fois verrouillé, la politique ne peut être   écrasé ou supprimé. Glacier appliquera la politique et   protégez vos enregistrements en fonction des contrôles (y compris un   période de rétention) qui y sont spécifiées.

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ées à la conformité en utilisant une stratégie d'accès au coffre-fort distincte. Pour   Par exemple, vous pouvez accorder un accès en lecture à des partenaires commerciaux ou à des utilisateurs désignés.   tiers (comme le requièrent parfois les règlements).

Pour moi, cela fournit exactement ce dont on a besoin sans les dépenses liées au matériel NetApp ou EMC, tout en semblant respecter les exigences de conservation des enregistrements.


1
2017-11-02 19:16



Il n'y a pas de différence logique de ma solution. L'administrateur du serveur, dans ce cas Amazon, peut toujours effacer ou altérer tout ou partie des fichiers. La seule différence ici est le fournisseur de stockage de fichiers ...? - nrc
Vous présumez que le fournisseur de stockage est la véritable différence. Avec un administrateur de serveur interne, l’organisme de réglementation estime qu’ils peuvent être manipulés par une personne plus âgée de 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 écrite et qu'il y a de meilleures chances qu'une demande inattendue soit rejetée. Pas aussi bon que le séquestre formel, mais la séparation des responsabilités procure une grande partie de la protection nécessaire. - phil_ayres


Si vous avez simplement besoin d'accéder à des fichiers à partir d'un système dans lequel les utilisateurs ne peuvent pas les écraser, vous pouvez monter un volume distant sur lequel vous ne disposez d'aucune autorisation en écriture. Le moyen le plus simple consiste à monter un partage Samba / cifs en lecture seule.

Sinon, si vous avez besoin d'un moyen permettant aux utilisateurs d'écrire de nouveaux fichiers (qui ne peuvent pas être écrasé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 manière, les 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


0
2018-01-11 18:51



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 lecteurs physiques) de supprimer des fichiers. - phil_ayres
Le serveur FTP agit comme un périphérique 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, afin d'éviter que tout administrateur système puisse manipuler les fichiers. Un administrateur peut toujours effacer les fichiers mais ne peut plus modifier le fichier sans se faire remarquer. - nrc
Malheureusement, le fait de signer le fichier pour démontrer (l'absence de) falsification est insuffisant, selon le règlement de la SEC. D'où la question de rendre les fichiers complètement immuables. - phil_ayres


Ceci est une variation du "Sauvegarde infalible"problème et la seule façon de le mettre en œuvre est d'utiliser plusieurs systèmes de fichiers de ver distants qui utilisent et partagent des sommes de contrôle et ne disposent pas d'un accès physique ou administratif partagé. Cela garantit que tout est écrit une seule fois, dupliqué, intégralement prouvable et dans le cas d'un seul. bloc en cours d’effacement, modifié ou corrompu, récupérable.

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


0
2018-03-27 22:40