Давно уже мне не нравилось положение дел в Agenda, где загружаемые пользователями файлы были доступны на самом деле не только пользователю, а и любому, кто имеет доступ к серверу и конкретно к директории, в которой хранятся загруженные на сервер файлы. Понятное дело, что существенной дыры в безопасности здесь нет в том случае, если сервер обслуживает только ваш узел документооборота и вы полностью уверены в его безопасности, однако же наши клиенты пользуются не только собственными выделенными серверами, но и обыкновенным виртуальным хостингом. Мы провели мониторинг некоторых хостингов, которыми, согласно нашей статистике, пользуются наши клиенты. Результаты не показали ничего хорошего: на некоторых хостингах можно спокойно получить доступ к файлам другого клиента несмотря на то, что по идее доступа к ним не должно быть. После данного мониторинга было принято решение разработать некий механизм, который препятствовал бы получению файлов пользователей каким-либо иным способом кроме механизма доступа Agenda. Ограничить доступ к файлам можно только на уровне сервера, а мы говорим о виртуальном хостинге, поэтому внимание наше тут же переключилось на шифрование.

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

На третий день мы придумали очень даже неплохой алгоритм, который будет работать даже у самого депрессивного хостера, не предоставляющего ничего, кроме базового набора программного обеспечения. Наш собственный механизм внешне является подделкой под Base64, однако расшифровка через эту систему никакого результата не даст. Все верно, ведь похожи они только внешне. Вообще, в английском языке можно очень легко установить отличие Base64 от других механизмов. В Base64 данные можно «encode», а в DES ― «encrypt». В русском языке отличия не так явно заметны, поскольку шифровать можно и в той системе, и в той. Поясню отличие: Base64 позволяет просто закодировать строку, к примеру, для бесперебойной передачи в качестве параметра URL, после чего строка будет возвращена к первоначальному виду на любом компьютере без какой-либо дополнительной информации; алгоритмы вроде DES же выполняют шифрование строки с использованием секретного ключа, благодаря чему привести их в исходное состояние можно только зная секретный ключ. Кроме того, данные, зашифрованные в DES, будут выглядеть не так приятно, поскольку состоять будут из непонятных символов, которые в народе называют «крякозябры». Наш механизм будет шифровать данные из файлов, но приводить их после шифрования к более красивому виду. По сути дела, разметка не влияет на результат, но несколько осложняет расшифровку злоумышленником. Самое интересное, что файл на сервере никак нельзя будет сопоставить с записью в журнале, поскольку имена файлов меняются на понятные только самому скрипту, а расширения отбрасываются вовсе. Можно было бы подобрать файл по размеру, но наш механизм шифрования меняет также и размер, который для некоторых файлов, в зависимости от длины ключа, может даже удваиваться. В увеличении занимаемого на сервере пространства мы не видим ничего страшного, поскольку изначально наш скрипт разрабатывался как скрипт документооборота, а не файлового хостинга, а по умолчанию мы устанавливаем лимит на размер загружаемого файла, равный пятидесяти мегабайтам. Для конечного пользователя изменения вообще будут незаметны. После обновления скрипт автоматически зашифрует все загруженные на сервер файлы, после чего их можно будет скачать в привычном виде как и раньше, но расшифровываться при каждом обращении они будут заново. На нашем сервере скрипт обновления работал около минуты и создал нагрузку на ядро процессора, равную 2%.

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

P.S. Хочу отдельно отметить для тех, кто будет обновлять свои сервера Agenda, что после обновления и завершения процедуры шифрования в директории, где хранятся загруженные на сервер файлы, могут остаться некоторые файлы, которые не будут зашифрованы. Если таковые у вас имеются, то это показатель того, что у вас есть приложения-призраки, которые уже удалены из базы данных, но остались физически. Все эти файлы нужно удалить вручную, после чего запустить мастер пересчета для ликвидации хвостов. Такие ситуации возникают в том случае, если на вашем сервере пользователь, от имени которого запущена Agenda, не имеет полных прав на директорию временного хранения и содержащиеся в ней файлы. Проблема решается при помощи chown.