Недавно в Массачусетсе был принят закон (довольно тихо), что данные, содержащие личную информацию, должны быть зашифрованы. PII определяется государством как содержащее имя и фамилию жителей в сочетании с любым,
A. SSN
Б. водительские права или удостоверение личности №
C. Дебет или CC #
Из-за характера программного обеспечения, которое мы производим, все наши клиенты используют SQL в качестве серверной части. Обычно серверы работают под управлением SQl2005 Standard или выше, иногда с SQL 2008. Почти все клиентские машины используют SQL2005 Express. Мы используем репликацию между клиентом и сервером. К сожалению, чтобы получить TDE вам необходимо иметь SQL Enterprise на каждой машине, что совершенно недопустимо. Ищу рекомендации продуктов, которые будут шифровать БД. Сейчас меня вообще не интересует шифрование всего диска.
Что касается регулирования, есть два пункта, в которых говорится о том, когда использовать шифрование:
Таким образом, если база данных не находится на портативном компьютере или портативном устройстве, вам не требуется шифровать саму базу данных (хотя есть и другие части правил, которые применяются к данным в этом состоянии). Кроме того, шифрование данных в этом состоянии не обеспечит вас по назначению; когда данные находятся в пути. Я бы порекомендовал вам изучить безопасность на транспортном уровне (например, HTTPS) на предмет соблюдения этого правила.
Однако, если суть вашего вопроса действительно касается шифрования данных на уровне базы данных, я бы определенно рекомендовал использовать такой продукт, как TrueCrypt, что позволит вам зашифровать виртуальный диск, представленный как файл в стандартной файловой системе. Однако с практической точки зрения я бы порекомендовал вам рассмотреть возможность шифрования на уровне поля. То есть шифрование / дешифрование полей на уровне приложения / сервиса и сохранение зашифрованных значений в полях данных.
Это тоже PCI требование при работе с данными кредитной карты. Вы, вероятно, смотрите на шифрование фактических данных в самих таблицах. Когда я прошел через это, мне пришлось создать новые столбцы в таблице (ах), сгенерировать зашифрованные данные соответствующих исходных столбцов, а затем удалить исходные (незашифрованные) столбцы. Проблема в том, что ваши приложения должны измениться, чтобы иметь возможность работать с зашифрованными данными.
Вы также захотите включить принудительное шифрование протокола на сервере.
TDE шифрует только данные в состоянии покоя. Это важный момент. Таким образом, если кто-то взломает SQL Server во время его работы, данные не будут зашифрованы. Таким образом, подход Сквиллмана - единственный способ гарантировать, что данные действительно зашифрованы, если вы не знаете, какими ключами дешифровать. Если этого достаточно (данные в состоянии покоя), можно использовать шифрованную файловую систему (EFS), предоставляемую ОС. Это может быть установлено для отдельных файлов или на уровне папки (лучше сделать это на уровне папки). Одно отличие состоит в том, что EFS не шифрует резервные копии. Резервные копии баз данных с поддержкой TDE зашифрованы. Вам нужно будет использовать сторонний продукт, такой как SQL LiteSpeed или Red Gate SQL Backup, чтобы гарантировать безопасность резервных копий.
Что касается Force Protocol Encryption, я бы не пошел по этому пути. Я бы предпочел использовать политику IPSEC на уровне ОС с использованием Kerberos для создания безопасного туннеля. Это устраняет необходимость установки сертификата SSL для использования SQL Server.
Если TDE неприемлем, то единственный вариант - шифрование уровня тома BitLocker. Для эффективной работы с SQL Server шифрование должно иметь возможность зашифровать / расшифровать страницу в файле, что означает, что оно должно иметь возможность установить ключ шифрования в соответствующем состоянии для доступа к смещению страницы в файл. Это исключает все решения для шифрования на уровне файлов, потому что они не могут расшифровать / зашифровать блок X файла без первого дешифрования / шифрования блока X-1 (для установки ключа в правильном состоянии).