Назад | Перейти на главную страницу

Асимметрично зашифрованная файловая система

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

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

Я считаю, что должна быть файловая система (написанная как система FUSE или что-то в этом роде - я использую Linux), которая представляет структуру каталогов в виде открытого текста, но записывает содержимое файлов в соответствии с половиной набора асимметричных ключей. Это позволило бы мне регистрировать сообщения и ставить их в очередь для отправки на сервер журнала, где находится ключ дешифрования.

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

Я бы рекомендовал вам сделать это на прикладном уровне.

В этом случае переместите поток в StackOverflow, однако мой ответ будет примерно таким:

Обычный способ использования асимметричного шифрования значительных объемов данных (т. Е. Где угодно) - использовать его для шифрования случайно выбранного ключа, который затем используется для шифрования остальной части данных с помощью симметричного шифра.
Это потому, что симметричные шифры намного быстрее и обычно делают больше того, что вы хотите.

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

Так, например, вы можете использовать AES / CBC для самих данных журнала, что будет довольно быстро (плюс есть множество реализаций).

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

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

Файловая система, которая поддерживает это, будет бесполезна с ограничениями, потому что вы можете монтировать ее только для записи или только для чтения; операционные системы обычно не понимают концепцию файловых систем только для записи :)

Я провел небольшое исследование, кодирование и документацию; вот ссылка на сценарий использования ...

https://github.com/S0AndS0/Perinoid_Pipes/blob/master/Documentation/Paranoid_Pipes_Scenario_One.md

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

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

Поскольку журналы записываются в несколько строк за раз, использование односторонней зашифрованной файловой системы немного за убийство и помимо моих навыков, вместо этого сценарий автоматизирует настройку определенного типа файла (mkfifo), который действует как именованный канал, и набор скриптовых правил, которые прослушивают действия записи в файл именованного канала. Затем эта пара файлов генерирует третий файл, тот, который вы запрашивали, зашифрованный добавленный файл журнала, который хост не может прочитать. Скрипт работает аналогично echo 'log message' | gpg -a -r email@host.domain >> server.log выполняется для каждого действия журнала, но с именованным каналом вместо |а логика скрипта обрабатывает gpg'ing и добавление в файл. Использование именованных каналов вместо анонимных каналов означает, что только выходной путь службы генерации журналов нуждается в обновлении, чтобы использовать путь именованного канала вместо стандартного файла для использования задач шифрования.

Обратите внимание, что есть и другие функции, которые уже могут быть полезны запеченный в которые позволяют шифровать и отправлять файлы журналов по электронной почте, когда они достигают указанного пользователем размера, эти функции разделены, чтобы позволить программному обеспечению IDS / IPS анализировать журналы или сделать отправленные журналы еще более трудными для отслеживания в сочетании с шифрованием по каждой записи.

Изменить / обновить: возможно, вы захотите проверить сокращенное краткое руководство по другому вопросу, который был более общим по охвату, но достаточно похож, чтобы гарантировать включение в этот ответ.

https://security.stackexchange.com/a/138877/82480

Изменить / обновить: похоже, что ссылки в разметке на GitHub очень специфичны для браузера, поэтому вот копия первого сценария из связанного выше документа.

Пользовательский сценарий использования для веб-сервера

Загрузите и скопируйте скрипт в ${PATH} реж

`` ''

git clone https://github.com/S0AndS0/Perinoid_Pipes
cd Perinoid_Pipes
cp Paranoid_Pipes.sh /usr/local/sbin/
chown ${USER}:${USER} /usr/local/sbin/Paranoid_Pipes.sh
chmod 700 /usr/local/sbin/Paranoid_Pipes.sh

`` ''

Показать доступные параметры командной строки и их текущие значения.

`` ''

Paranoid_Pipes.sh --help

`` ''

Установите параметры командной строки для записи именованного канала в той же файловой системе, что и приложение веб-сервера, и настраиваемый синтаксический анализатор в файловой системе хостинга.

`` ''

Paranoid_Pipes.sh --copy-save-yn='yes'\
 --copy-save-name="/jailer_scripts/website_host/Web_log_encrypter.sh"\
 --copy-save-ownership="notwwwuser:notwwwgroup"\
 --copy-save-permissions='100'\
 --debug-level='6'\
 --listener-quit-string='sOmErAnDoM_sTrInG_wItHoUt_SpAcEs_tHaT_iS_nOt_NoRmAlY_rEaD'\
 --log-level='0'\
 --named-pipe-name="/jailed_servers/website_host/var/log/www/access.log.pipe"\
 --named-pipe-ownership='notwwwuser:wwwgroup'\
 --named-pipe-permissions='420'\
 --output-parse-name="/jailed_logs/website_host/www_access.gpg"\
 --output-parse-recipient="user@host.domain"\
 --output-rotate-actions='compress-encrypt,remove-old'\
 --output-rotate-check-requency='25000'\
 --output-rotate-max-bites='8388608'\
 --output-rotate-recipient="user@host.domain"\
 --output-rotate-yn='yes'\
 --output-save-yn='yes'\
 --disown-yn='yes' --help

`` ''

Обратите внимание, что если серверное приложение не находится в chroot jail, вы захотите изменить пути к файлам для именованного канала и копии скрипта, потому что выше предполагалось, что некоторая форма разделения файловой системы уже реализована. Удалить --help сверху, чтобы сценарий выполнял действия вместо вывода текущих значений параметров командной строки.

Путь к файлу именованного канала ( --named-pipe-name путь к файлу) следует вручную добавить в путь ведения журнала вашего веб-сервера, он отличается для каждого демона / сервера, так что данные журнала обычных клиентов записываются в файл именованного канала.

Копия скрипта (сохранена в --copy-save-name путь к файлу) - это то, что магия прослушивая действия записи в связанный с ним файл именованного канала, он проталкивает зарегистрированные строки через GnuPG и добавляет результаты (используя открытый ключ для --output-parse-recipient для начального шифрования) в файл, указанный --output-parse-name параметр командной строки.

Результирующий зашифрованный файл журнала отслеживается на предмет размера файла, и когда он и счетчик записи достаточно велики, файл журнала повторно шифруется с использованием открытого ключа для --output-rotate-recipient и переехал / переименован.

Если ваш сервер может отправлять электронную почту, измените --output-rotate-actions варианты включения email как допустимое действие, и дважды зашифрованные журналы в конечном итоге будут переданы.

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