Tulis sekali, baca banyak (WORM) menggunakan sistem file Linux

8

Saya memiliki persyaratan untuk menulis file ke sistem file Linux yang tidak dapat ditimpa, ditambahkan ke, diperbarui dengan cara apa pun, atau dihapus. Bukan oleh sudo-er, root, atau siapa pun. Saya berusaha memenuhi persyaratan peraturan layanan keuangan untuk pencatatan, FINRA 17A-4, yang pada dasarnya mengharuskan dokumen elektronik ditulis ke perangkat WORM (write once, read many). Saya ingin sekali menghindari menggunakan DVD atau perangkat EMC Centera yang mahal.

Apakah ada sistem file Linux, atau bisakah SELinux mendukung persyaratan agar file dibuat lengkap dengan segera (atau setidaknya segera) setelah menulis? Atau adakah yang mengetahui cara saya bisa menegakkan ini pada sistem file yang ada menggunakan izin Linux, dll?

Saya mengerti bahwa saya dapat mengatur izin hanya baca, dan atribut yang tidak dapat diubah. Tapi tentu saja saya berharap bahwa pengguna root akan dapat menghapusnya.

Saya mempertimbangkan untuk menyimpan data ke volume kecil yang tidak di-mount dan kemudian di-remount hanya-baca, tetapi kemudian saya berpikir bahwa root masih dapat meng-unmount dan remount sebagai dapat ditulis kembali.

Saya mencari ide-ide cerdas, dan skenario terburuk Saya bersedia melakukan sedikit pengkodean untuk 'meningkatkan' sistem file yang ada untuk menyediakan ini. Dengan asumsi ada sistem file yang merupakan titik awal yang baik. Dan menempatkan server Linux yang dikonfigurasi dengan hati-hati untuk bertindak sebagai perangkat penyimpanan jaringan jenis ini, tidak melakukan apa pun.

Setelah semua itu, enkripsi pada file akan bermanfaat juga!

— phil_ayres
sumber

4

Apa yang Anda minta tidak dapat dilakukan. Jika Anda memiliki akses root ke mesin, Anda dapat melakukan operasi tingkat blok langsung pada disk. Jadi tidak masalah sistem file apa yang ada di atas, Anda tidak dapat melindungi apa pun dari root, Anda hanya dapat memperlambatnya atau membuatnya sangat tidak jelas sehingga tampak aman.

— Regan

Setelah membaca interpretasi SEC sec.gov/rules/interp/34-47806.htm saya akan setuju dengan @Regan. Namun, semua ini sedikit tidak masuk akal. Misalnya, bagaimana cara menghapus CD? Dengan api, tentu saja.

— Mark Wagner

Saya sangat setuju bahwa persyaratannya 'sedikit tidak masuk akal'. Mereka berusaha untuk membuatnya begitu jelas bahwa ada upaya untuk menyembunyikan kebenaran bahwa tidak ada orang IT yang akan setuju untuk melakukan apa yang diminta oleh eksekutif yang tidak baik. Memukul delete pada direktori besar karena root ternyata terlalu mudah bagi seseorang. Penghancuran fisik menjadi satu-satunya cara untuk menutupi hal-hal dalam aturan SEC.

— phil_ayres

chattr + i nama file, Anda perlu memberikan perintah ini setiap kali Anda membuat file

— c4f4t0r

@ c4f4t0r tidak berhenti: chattr -i filenamelalu rm

— phil_ayres

2

Anda dapat melakukan ini dengan OpenAFS dan volume read-only. Banyak infrastruktur yang harus diinstal untuk membuatnya berfungsi namun mungkin tidak memenuhi persyaratan.

http://www.openafs.org/

Pada dasarnya, ada volume yang dapat ditulis dan satu atau lebih salinan read-only dari volume. Sampai Anda merilis volume yang dapat ditulisi, salinan read-only tidak dapat diubah kepada klien. Melepaskan volume membutuhkan hak admin.

Sepertinya solusi apa pun akan memerlukan perangkat keras khusus atau sistem file jaringan yang menduplikasi semantik perangkat keras khusus.

— Fred Anjing Ajaib Ajaib
sumber

Apakah OpenAFS sebenarnya mencegah root dari menulis ke volume read-only. Saya tidak dapat menemukan definisi definitif dalam dokumen.

— phil_ayres

Ini tentu saja mencegah root pada klien dari menulis ke volume ro. Root umumnya tidak menyiratkan izin khusus apa pun di OpenAFS.

— Fred the Magic Wonder Dog

1

Tampaknya tidak ada cara untuk melakukan ini tanpa menulis sistem file kustom / kode kernel.

Solusi yang layak tampaknya menggunakan Amazon Glacier dengan opsi penyimpanan arsip WORM. Menurut Blog Resmi AWS di: https://aws.amazon.com/blogs/aws/glacier-vault-lock/

[...] fitur Gletser baru yang memungkinkan Anda untuk mengunci lemari besi Anda dengan berbagai kontrol kepatuhan yang dirancang untuk mendukung kasus penggunaan penyimpanan catatan penting ini. Anda sekarang dapat membuat kebijakan Kunci Vault di brankas dan menguncinya. Setelah dikunci, kebijakan tidak dapat ditimpa atau dihapus. Gletser akan menegakkan kebijakan dan akan melindungi catatan Anda sesuai dengan kontrol (termasuk periode penyimpanan yang telah ditentukan) yang ditentukan di dalamnya.

Anda tidak dapat mengubah kebijakan Kunci Vault setelah Anda menguncinya. Namun, Anda masih dapat mengubah dan mengonfigurasi kontrol akses yang tidak terkait dengan kepatuhan dengan menggunakan kebijakan akses vault terpisah. Misalnya, Anda dapat memberikan akses baca ke mitra bisnis atau pihak ketiga yang ditunjuk (seperti yang kadang-kadang diperlukan oleh peraturan).

Bagi saya, ini memberikan apa yang dibutuhkan tanpa biaya NetApp atau perangkat keras EMC, sementara muncul untuk memenuhi persyaratan penyimpanan catatan.

— phil_ayres
sumber

Tidak ada perbedaan logika dari solusi saya. Administrator server, dalam hal ini Amazon, masih dapat menghapus atau merusak beberapa atau semua file. Satu-satunya perbedaan di sini adalah penyedia penyimpanan file ...?

— nrc

Anda benar dalam asumsi Anda bahwa penyedia penyimpanan adalah perbedaan nyata. Dengan administrator server internal, regulator yakin mereka dapat dimanipulasi oleh orang yang lebih senior di organisasi yang sama untuk menghapus atau mengubah catatan. Tentu saja, Anda bisa meminta seseorang di Amazon untuk menghancurkan segalanya, tetapi asumsinya adalah bahwa akan ada jejak kertas dan ada peluang yang lebih baik permintaan yang tidak terduga akan ditolak. Tidak sebagus escrow formal, tetapi memisahkan tanggung jawab memberikan banyak perlindungan yang dibutuhkan.

— phil_ayres

1

Anda masih dapat menghapus file dengan berhenti membayar penyimpanan.

— Tomas Zubiri

0

Jika Anda hanya perlu mengakses file dari sistem di mana pengguna tidak dapat menimpanya, Anda dapat memasang volume jarak jauh di mana Anda tidak memiliki izin menulis. Cara termudah untuk melakukan ini adalah dengan me-mount share read-only samba / cifs.

Kalau tidak, jika Anda memerlukan cara untuk memungkinkan pengguna menulis file baru (yang tidak dapat ditimpa atau dimodifikasi) solusinya adalah dengan me-mount path FTP dengan FUSE curlftpfs.

Anda dapat mengatur direktori proftpd Anda dengan arahan ini:

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

Dengan cara ini, file-file baru dapat disimpan di direktori yang di-mount, tetapi tidak dapat lagi dimodifikasi atau dihapus.

link: CurlFtpFS , proftpd

— nrc
sumber

Saya mengerti apa yang Anda katakan, dan itu sepertinya menjadi pilihan. Tetapi jika saya adalah administrator dari server file saya dapat menghapus apa pun. Tujuannya adalah untuk mencegah bahkan administrator (setidaknya mereka yang tidak memiliki akses ke drive fisik) dari menghapus file.

— phil_ayres

Server FTP bertindak sebagai perangkat WORM yang murah. Tapi ya, administrator server FTP jarak jauh dapat mengakses file dan mengubahnya. Solusi adalah dengan menandatangani file pada pembuatannya, dengan sistem kunci asimetris, untuk mencegah administrator sistem dapat mengacaukan file. Seorang administrator masih dapat menghapus file tetapi tidak dapat memodifikasi lagi file tanpa diketahui.

— nrc

Sayangnya hanya menandatangani file untuk menunjukkan (kurangnya) perusakan tidak cukup menurut regs SEC. Karenanya pertanyaan tentang membuat file benar-benar tidak dapat diubah.

— phil_ayres

0

Ini adalah variasi pada masalah " Infalible backup " dan satu-satunya cara untuk mengimplementasikannya adalah dengan beberapa sistem file cacing jarak jauh yang menggunakan dan berbagi checksum dan tidak memiliki akses fisik atau administrasi bersama. Ini memastikan semuanya ditulis sekali, digandakan, integritas dapat dibuktikan, dan dalam kasus satu blok dihapus, diubah atau rusak, dapat dipulihkan.

Plan9 atau turunannya mungkin memuji semua fitur yang diperlukan. Lihat Plan9 dan Venti

— Daniel Matthews
sumber