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

Есть ли подводные камни с использованием Truecrypt для защиты базы данных mySQL?

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

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

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

@James Я думаю, что в сценарии кражи он не будет отключен должным образом, что может привести к сбою любых выполняющихся транзакций БД. Но тогда, если кто-то украдет сервер, мне все равно придется полагаться на резервную копию вне сайта.

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

На данный момент приложение настроено для сброса дампа данных (еженедельно с заполнением, а затем - только ежечасно с использованием rdiff) в каталог также на диске Truecrypt. У меня есть внешнее устройство, на котором запущен WS_FTP Pro, по расписанию подключение по FTP и синхронизация резервной копии, снова в смонтированный раздел Truecrypt.

Мы запускаем mySQL на томе, защищенном шифрованием всего диска Truecrypt, с тех пор, как они добавили его в качестве функции. До этого мы хранили данные на отдельном томе, зашифрованном TC. Он работал с одним и тем же устройством более 6 лет и был удивительно надежным и устойчивым к таким вещам, как отключение питания, деградация RAID (аппаратный контроллер с RAID 1) и отказ оборудования. Падение производительности для нас было незначительным (некоторые даже возразят Диски, зашифрованные TrueCrypt, работают лучше, но я бы не стал заходить так далеко), будь то зашифрованный ноутбук или сервер.

Суть с нашей точки зрения (мы также работаем в сфере здравоохранения) заключается в том, что шифрование диска - это всего лишь один уровень безопасности в нашем арсенале, но потенциально важный, если физическая безопасность когда-либо будет скомпрометирована. Безусловно, существует множество сценариев, в которых данные могут быть украдены из работающей системы с зашифрованным диском, но это снижает угрозу потери данных в результате простой кражи, которая может быть более вероятной, чем многие другие риски, которые вы все равно хотели бы смягчить против. По этой причине мы шифруем все наши серверы - TrueCrypt для Windows, зашифрованный LVM для GNU / Linux.

Мне нравится TrueCrypt, но я не вижу значительного снижения подверженности и нетривиального дополнительного риска из-за ключ, ошибки и возможные проблемы с обновлением, и снижение производительности.

Единственный риск, который снижает шифрование всего диска, - это потеря данных при потере диска или компьютера. ИМХО этот риск значителен только когда компьютер мобильный. Если физическая и системная безопасность хороши, то, IMHO, шифрование диска, на котором хранится база данных, не принесет вам многого.

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

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