Пишите один раз, читайте много (WORM), используя файловую систему Linux

8

У меня есть требование записать файлы в файловую систему Linux, которые впоследствии не могут быть перезаписаны, добавлены, обновлены или удалены. Не судом, корнем или кем-либо еще. Я пытаюсь выполнить требования регламента финансовых услуг по ведению учета, FINRA 17A-4, который в основном требует, чтобы электронные документы записывались на устройства WORM (один раз напиши, прочитай много). Я бы очень хотел избежать использования DVD-дисков или дорогих устройств EMC Centera.

Существует ли файловая система Linux или SELinux может поддерживать требование, чтобы файлы были полностью неизменными сразу (или, по крайней мере, вскоре) после записи? Или кто-нибудь знает, как я могу применить это в существующей файловой системе, используя разрешения Linux и т. Д.?

Я понимаю, что я могу установить разрешения только для чтения и неизменный атрибут. Но, конечно, я ожидаю, что пользователь root сможет их сбросить.

Я рассмотрел возможность хранения данных на небольших томах, которые были размонтированы, а затем перемонтированы только для чтения, но затем я думаю, что root все еще может размонтировать и перемонтировать как доступный для записи снова.

Я ищу какие-нибудь умные идеи и наихудший сценарий, я готов сделать небольшое кодирование, чтобы «улучшить» существующую файловую систему, чтобы обеспечить это. Предполагая, что есть файловая система, которая является хорошей отправной точкой. И поставьте на место тщательно настроенный сервер Linux, который будет выполнять роль сетевого устройства хранения данных, не делая ничего другого.

После всего этого шифрование файлов также будет полезно!

— phil_ayres
источник

4

То, что вы просите, не может быть сделано. Если у вас есть root-доступ к машине, вы можете выполнять операции на уровне блоков непосредственно на диске. Таким образом, не имеет значения, какая файловая система находится сверху, вы не можете защитить что-либо от root, вы можете только замедлить или сделать так, чтобы она была настолько неясной, что кажется безопасной.

— Реган

После прочтения интерпретации SEC sec.gov/rules/interp/34-47806.htm я согласен с @Regan. Однако все это немного абсурдно. Например, как можно стереть CD? С огнем, конечно.

— Марк Вагнер

Я абсолютно согласен с тем, что требования «слегка абсурдны». Они пытаются сделать это настолько очевидным, что была предпринята попытка скрыть правду о том, что ни один ИТ-специалист не согласился бы сделать то, что просят плохие руководители. Нажатие на удаление в большой директории с правами суперпользователя было слишком легким для кого-то. Физическое уничтожение становится единственным способом скрыть вещи в правилах SEC.

— phil_ayres

chattr + i filename, вам нужно давать эту команду каждый раз, когда вы создаете файл

— c4f4t0r

@ c4f4t0r не останавливается: chattr -i filenameтогда rm

— phil_ayres

2

Вы можете сделать это с помощью OpenAFS и томов только для чтения. Однако для его работы необходимо установить множество инфраструктур, которые могут не соответствовать требованиям.

http://www.openafs.org/

По существу, имеется записываемый том и одна или несколько копий тома, доступных только для чтения. Пока вы не освободите доступный для записи том, копии, доступные только для чтения, не могут быть изменены клиентами. Выпуск тома требует прав администратора.

Кажется, что любое решение потребует либо специализированного оборудования, либо сетевой файловой системы, которая дублирует семантику специализированного оборудования.

— Фред Волшебное чудо пса
источник

Действительно ли OpenAFS препятствует записи root в том только для чтения? Я не мог найти окончательное определение в документах.

— phil_ayres

Это, безусловно, предотвращает запись root на клиенте в тома ro. Обычно root не подразумевает никаких специальных разрешений в OpenAFS.

— Фред Волшебная собака Чудо

1

Кажется, что нет способа сделать это без написания пользовательской файловой системы / кода ядра.

Жизнеспособным решением, по-видимому, является использование Amazon Glacier с возможностью архивного хранения WORM. Согласно официальному блогу AWS по адресу: https://aws.amazon.com/blogs/aws/glacier-vault-lock/

[...] новая функция Glacier, которая позволяет блокировать ваше хранилище с помощью различных средств контроля соответствия, разработанных для поддержки этого важного варианта использования хранения записей. Теперь вы можете создать политику Vault Lock в хранилище и заблокировать ее. После блокировки политика не может быть перезаписана или удалена. Glacier будет применять политику и защищать ваши записи в соответствии с указанными в них элементами управления (включая заранее определенный срок хранения).

Вы не можете изменить политику блокировки хранилища после ее блокировки. Однако вы все равно можете изменять и настраивать элементы управления доступом, не связанные с соответствием, с помощью отдельной политики доступа к хранилищу. Например, вы можете предоставить доступ на чтение деловым партнерам или назначенным третьим сторонам (как иногда требуется по закону).

Для меня это обеспечивает именно то, что нужно без затрат на оборудование NetApp или EMC, и при этом соответствует требованиям к хранению записей.

— phil_ayres
источник

Нет логического отличия от моего решения. Администратор сервера, в данном случае Amazon, все еще может стереть или изменить некоторые или все файлы. Единственная разница здесь - поставщик хранилища файлов ...?

— NRC

Вы абсолютно правы, полагая, что реальная разница заключается в поставщике хранилища. С внутренним администратором сервера регулятор полагает, что более старший человек в той же организации может манипулировать им для удаления или изменения записей. Конечно, вы можете попросить кого-нибудь в Amazon уничтожить все, но предполагается, что будет бумажный след и больше шансов, что неожиданный запрос будет отклонен. Не так хорошо, как официальное условное депонирование, но разделение обязанностей обеспечивает большую часть необходимой защиты.

— phil_ayres

1

Вы все еще можете удалить файлы, прекратив платить за хранение.

— Томас Зубири

0

Если вам просто нужен доступ к файлам из системы, в которой пользователи не могут их перезаписать, вы можете подключить удаленный том, на который у вас нет разрешения на запись. Самый простой способ сделать это - смонтировать общий ресурс samba / cifs только для чтения.

В противном случае, если вам нужен способ, позволяющий пользователям записывать новые файлы (которые нельзя перезаписать или изменить), решение заключается в подключении пути FTP с помощью FUSE curlftpfs.

Вы можете установить каталог proftpd с помощью следующих директив:

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

Таким образом, новые файлы могут храниться в смонтированном каталоге, но их нельзя больше изменять или удалять.

ссылки: CurlFtpFS , ProFTPD

— национальный совет по научно-исследовательской работе
источник

Я понимаю, что вы говорите, и это, безусловно, вариант. Но если я администратор файлового сервера, я могу удалить что угодно. Цель состоит в том, чтобы запретить удаление файлов даже администраторам (по крайней мере, тем, у кого нет доступа к физическим дискам).

— phil_ayres

FTP-сервер действует как дешевое WORM-устройство. Но да, администратор удаленного FTP-сервера может получить доступ к файлам и изменить их. Решение состоит в том, чтобы подписать файл при его создании с помощью системы асимметричного ключа, чтобы любой системный администратор не мог связываться с файлами. Администратор все еще может удалить файлы, но больше не может изменять файл, не будучи замеченным.

— Nrc

К сожалению, просто подписать файл, чтобы продемонстрировать (отсутствие) несанкционированного вмешательства недостаточно в соответствии с регламентом SEC. Отсюда вопрос о том, чтобы сделать файлы полностью неизменяемыми.

— phil_ayres

0

Это вариант проблемы « Infalible backup », и единственный способ ее решения - использование нескольких удаленных файловых систем-червей, которые используют и совместно используют контрольные суммы и не имеют общего физического или административного доступа. Это гарантирует, что все будет записано один раз, продублировано, проверено на целостность, а в случае стирания, изменения или повреждения одного блока может быть восстановлено.

Plan9 или его производные могут включать все необходимые функции. Смотри Plan9 и Venti

— Дэниэл Мэтьюз
источник