Einmal schreiben, viele lesen (WORM) mit dem Linux-Dateisystem

8

Ich muss Dateien in ein Linux-Dateisystem schreiben, die anschließend nicht überschrieben, angehängt, in irgendeiner Weise aktualisiert oder gelöscht werden können. Nicht von einem Sudo-er, einer Wurzel oder irgendjemandem. Ich versuche, die Anforderungen der Finanzdienstleistungsvorschriften für die Führung von Aufzeichnungen, FINRA 17A-4, zu erfüllen, die grundsätzlich erfordern, dass elektronische Dokumente auf WORM-Geräte geschrieben werden (einmal schreiben, viele lesen). Ich würde sehr gerne vermeiden, DVDs oder teure EMC Centera-Geräte verwenden zu müssen.

Gibt es ein Linux-Dateisystem oder kann SELinux die Anforderung unterstützen, dass Dateien sofort (oder zumindest bald) nach dem Schreiben vollständig unveränderlich gemacht werden müssen? Oder ist jemandem bekannt, wie ich dies mit Linux-Berechtigungen usw. in einem vorhandenen Dateisystem erzwingen kann?

Ich verstehe, dass ich schreibgeschützte Berechtigungen und das unveränderliche Attribut festlegen kann. Aber natürlich erwarte ich, dass ein Root-Benutzer diese deaktivieren kann.

Ich habe überlegt, Daten auf kleinen Volumes zu speichern, die nicht gemountet und dann schreibgeschützt erneut gemountet wurden, aber dann denke ich, dass root die Bereitstellung immer noch als beschreibbar aufheben und erneut bereitstellen kann.

Ich bin auf der Suche nach intelligenten Ideen, und im schlimmsten Fall bin ich bereit, ein wenig zu programmieren, um ein vorhandenes Dateisystem zu "verbessern", um dies bereitzustellen. Angenommen, es gibt ein Dateisystem, das ein guter Ausgangspunkt ist. Und richten Sie einen sorgfältig konfigurierten Linux-Server ein, der als diese Art von Netzwerkspeichergerät fungiert und nichts anderes tut.

Nach all dem wäre auch die Verschlüsselung der Dateien nützlich!

— phil_ayres
quelle

4

Was Sie fragen, kann nicht getan werden. Wenn Sie Root-Zugriff auf den Computer haben, können Sie Operationen auf Blockebene direkt auf der Festplatte ausführen. Es spielt also keine Rolle, welches Dateisystem sich oben befindet. Sie können nichts vor Root schützen. Sie können es nur verlangsamen oder so dunkel machen, dass es sicher erscheint.

— Regan

Nachdem ich die SEC-Interpretation sec.gov/rules/interp/34-47806.htm gelesen habe, werde ich @Regan zustimmen. Das Ganze ist jedoch etwas absurd. Wie löscht man beispielsweise eine CD? Natürlich mit Feuer.

— Mark Wagner

Ich stimme absolut zu, dass die Anforderungen "etwas absurd" sind. Sie versuchen, es so offensichtlich zu machen, dass versucht wurde, die Wahrheit zu verbergen, dass kein IT-Mitarbeiter zustimmen würde, das zu tun, was ein nicht guter Manager verlangt. Das Löschen von Löschen in einem großen Verzeichnis als Root war für jemanden anscheinend zu einfach. Die physische Zerstörung ist der einzige Weg, um die Regeln der SEC zu vertuschen.

— Phil_ayres

chattr + i Dateiname, müssen Sie diesen Befehl jedes Mal geben, wenn Sie eine Datei erstellen

— c4f4t0r

@ c4f4t0r hört nicht auf: chattr -i filenamedann rm

— phil_ayres

2

Sie können dies mit OpenAFS und schreibgeschützten Volumes tun. Es muss jedoch viel Infrastruktur installiert werden, damit es funktioniert und möglicherweise nicht den Anforderungen entspricht.

http://www.openafs.org/

Grundsätzlich gibt es einen beschreibbaren Band und eine oder mehrere schreibgeschützte Kopien des Bandes. Bis Sie das beschreibbare Volume freigeben, können die schreibgeschützten Kopien für Clients nicht geändert werden. Für die Freigabe des Volumes sind Administratorrechte erforderlich.

Es scheint, als würde jede Lösung entweder spezielle Hardware oder ein Netzwerkdateisystem erfordern, das die Semantik spezialisierter Hardware dupliziert.

— Fred der magische Wunderhund
quelle

Verhindert OpenAFS tatsächlich, dass root auf das schreibgeschützte Volume schreibt? Ich konnte keine endgültige Definition in den Dokumenten finden.

— Phil_ayres

Es verhindert sicherlich, dass root auf dem Client auf die ro-Volumes schreibt. Im Allgemeinen impliziert root keine besonderen Berechtigungen in OpenAFS.

— Fred der magische

1

Es scheint, dass es keine Möglichkeit gibt, dies zu tun, ohne benutzerdefinierten Dateisystem- / Kernel-Code zu schreiben.

Eine praktikable Lösung scheint darin zu bestehen, Amazon Glacier mit der Speicheroption WORM-Archiv zu verwenden. Laut dem offiziellen AWS-Blog unter: https://aws.amazon.com/blogs/aws/glacier-vault-lock/

[...] eine neue Gletscherfunktion, mit der Sie Ihren Tresor mit einer Vielzahl von Compliance-Kontrollen sperren können, die diesen wichtigen Anwendungsfall für die Aufbewahrung von Datensätzen unterstützen. Sie können jetzt eine Tresorsperrrichtlinie für einen Tresor erstellen und diese sperren. Nach dem Sperren kann die Richtlinie nicht überschrieben oder gelöscht werden. Glacier setzt die Richtlinie durch und schützt Ihre Unterlagen gemäß den darin festgelegten Kontrollen (einschließlich einer vordefinierten Aufbewahrungsfrist).

Sie können die Tresorsperrrichtlinie nach dem Sperren nicht mehr ändern. Sie können jedoch weiterhin die Zugriffssteuerungen ändern und konfigurieren, die nicht mit der Konformität zusammenhängen, indem Sie eine separate Tresorzugriffsrichtlinie verwenden. Beispielsweise können Sie Geschäftspartnern oder bestimmten Dritten Lesezugriff gewähren (wie dies manchmal gesetzlich vorgeschrieben ist).

Für mich bietet dies genau das, was ohne die Kosten für NetApp- oder EMC-Hardware benötigt wird, und scheint gleichzeitig die Anforderungen für die Aufbewahrung von Datensätzen zu erfüllen.

— phil_ayres
quelle

Es gibt keinen logischen Unterschied zu meiner Lösung. Der Serveradministrator, in diesem Fall Amazon, kann weiterhin einige oder alle Dateien löschen oder manipulieren. Der einzige Unterschied ist hier der Dateispeicheranbieter ...?

— nrc

Sie haben genau das Richtige in Ihrer Annahme, dass der Speicheranbieter der wahre Unterschied ist. Mit einem internen Serveradministrator ist die Aufsichtsbehörde der Ansicht, dass sie von einer älteren Person in derselben Organisation manipuliert werden kann, um Datensätze zu löschen oder zu ändern. Natürlich könnten Sie jemanden bei Amazon bitten, alles zu zerstören, aber die Annahme ist, dass es eine Papierspur geben wird und es eine bessere Chance gibt, dass eine unerwartete Anfrage abgelehnt wird. Nicht ganz so gut wie eine formelle Übertragungsurkunde, aber die Trennung der Verantwortlichkeiten bietet einen Großteil des erforderlichen Schutzes.

— Phil_ayres

1

Sie können die Dateien weiterhin löschen, indem Sie den Speicher nicht mehr bezahlen.

— Tomas Zubiri

0

Wenn Sie lediglich von einem System aus auf Dateien zugreifen müssen, in dem Benutzer sie nicht überschreiben können, können Sie ein Remote-Volume bereitstellen, auf dem Sie keine Schreibberechtigung haben. Der einfachste Weg, dies zu tun, besteht darin, eine schreibgeschützte Samba / CIFS-Freigabe bereitzustellen.

Andernfalls besteht eine Lösung darin, einen FTP-Pfad mit FUSE curlftpfs bereitzustellen, wenn Sie eine Möglichkeit benötigen, Benutzern das Schreiben neuer Dateien zu ermöglichen (die nicht überschrieben oder geändert werden können).

Sie können Ihr proftpd-Verzeichnis mit den folgenden Anweisungen festlegen:

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

Auf diese Weise können neue Dateien im bereitgestellten Verzeichnis gespeichert, aber nicht mehr geändert oder entfernt werden.

Links: CurlFtpFS , ProFTPD

— nrc
quelle

Ich verstehe, was Sie sagen, und es scheint sicherlich eine Option zu sein. Aber wenn ich der Administrator des Dateiservers bin, kann ich alles löschen. Ziel ist es, zu verhindern, dass auch Administratoren (zumindest solche ohne Zugriff auf die physischen Laufwerke) Dateien löschen.

— Phil_ayres

Der FTP-Server fungiert als billiges WORM-Gerät. Aber ja, der Administrator des Remote-FTP-Servers kann auf die Dateien zugreifen und sie ändern. Eine Lösung besteht darin, die Datei bei ihrer Erstellung mit einem asymmetrischen Schlüsselsystem zu signieren, um zu verhindern, dass ein Systemadministrator mit den Dateien herumspielen kann. Ein Administrator kann die Dateien weiterhin löschen, die Datei jedoch nicht mehr unbemerkt ändern.

— nrc

Leider reicht es nach Angaben der SEC nicht aus, die Datei nur zu signieren, um (fehlende) Manipulationen nachzuweisen. Daher die Frage, ob die Dateien vollständig unveränderlich sind.

— Phil_ayres

0

Dies ist eine Variation des Problems " Infalible Backup ". Die einzige Möglichkeit, es zu implementieren, besteht in mehreren Remote-Wurm-Dateisystemen, die Prüfsummen verwenden und gemeinsam nutzen und keinen gemeinsamen physischen oder Administrationszugriff haben. Dies stellt sicher, dass alles einmal geschrieben, dupliziert, die Integrität nachweisbar und im Fall eines einzelnen Blocks, der gelöscht, geändert oder beschädigt wird, wiederherstellbar ist.

Plan9 oder seine Derivate können alle erforderlichen Funktionen implementieren. Siehe Plan9 und Venti

— Daniel Matthews
quelle