Блог

ПРИВЕТ всем,

Мы создаем решение, после этапа 1 нас попросили защитить PI пользователя в базе данных. К этому времени мы достигли 10 миллионов пользовательских данных. Мы рассмотрели несколько вариантов:

1. Шифрование на стороне приложения (на стороне загрузки Spring) — использование надежной технологии тройного шифрования.
2. Шифрование на стороне базы данных — пусть DB обрабатывает головную боль шифрования и дешифрования, нас это не беспокоит. Мы использовали аннотации JPA, чтобы упростить нашу работу.

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

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

Безопасно ли создавать индекс для столбца с расшифрованной информацией в нем. В индексе будут расшифрованные данные. Вся цель зашифрованных данных не имеет значения.

 Data Type is BYTEA and used 
  

pgp_sym_encrypt для шифрования.

Аналогично используется

pgp_sym_decrypt для расшифровки путем передачи ключа

Чтобы создать индекс, мы должны создать индекс как

СОЗДАЙТЕ ИНДЕКС index_1 в таблице (pgp_sym_decrypt(, ‘key’) VARCHAR_pattern_ops);

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

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

Создание индекса для выражения, которое расшифровывает эти данные, сохранит расшифрованные данные на диске, да. Похоже, вы должны использовать шифрование на уровне блочного устройства (например, шифрование на весь диск). Использование табличного пространства, которое указывает на путь к файловой системе, где ваша ОС обрабатывает шифрование, поможет вам пройти часть пути, но даже тогда вы должны знать, что если вы когда-либо будете сортировать с использованием каких-либо расшифрованных данных, если сортировка будет достаточно большой, чтобы выйти из вашего настроенного work_mem, эти расшифрованные значениябудет записано во временные файлы. То же самое касается объединения с использованием любых расшифрованных данных, поскольку планировщик запросов часто использует сортировку как часть плана запроса, когда присутствует соединение.

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