Как искать зашифрованные данные через like?

Question

[kaxa3201]

Есть необходимость шифрование данных пользователей, зашифровать проблемы нет, но проблема в том, что по ним ещё нужен поиск, и поиск нужен в том числе через like. Знаю про пакеты которые работают через слепой индекс, но они работают только через точное совпадение при поиске, а не через like. Может есть обходные пути?

Comments

[ThunderCat]

Шо за данные, которым требуется шифрование да еще и поиск?

[mayton2019]

Автор покажи пример таких данных.

[kaxa3201]

ThunderCat, ФИО , номер телефона, ip адресс. В рамках gdpr стоит у нас такое требование от заказчика

[shurshur]

kaxa3201, если стоит задача искать по всяким вариантам типа по фамилии из ФИО, то разделяем ФИО на слова, каждое шифруем отдельно, при поиске шифруем поисковые слова и используем like на них. Примерно так.

Полноценный поиск по шифрованным данным, конечно, невозможен. Иначе бы смысла в шифровании не было вообще: можно было бы по словарным спискам распространённых фамилий прилично идентифицировать кучу людей из шифрованной базы.

Заказчику можно предложить сделать какой-то Особо Защищённый Сервис с персональными данными, который будет огорожен от остальной инфраструктуры и предназначен для обслуживания именно этих специальных запросов. Разумеется, не надо думать, что можно так легко и нахаляву работать с персональными данными как будто они не являются персональными.

[tukreb]

https://postgrespro.ru/docs/postgrespro/15/encrypt...
Просто и ничего городить не нужно.

Answer 1

[d'Ivan]

Если верно понял требования, то вот мои мысли.

Использовать Transparent Data Encryption (TDE)

Выполнить шифрование данных на уровне таблиц:
https://www.postgresql.org/docs/current/encryption...
https://dev.mysql.com/blog-archive/controlling-tab...

То есть расшифровывание будет происходить на уровне СУБД, а с точки зрения приложения - обычные запросы LIKE.

Comments

[kaxa3201]

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

Answer 2

[ThunderCat]

Хм, если вы можете его обратно расшифровать, то зачем эти телодвижения?
Алсо, мне кажется, в рамках вашего тз, реализовать такое малореально. Либо поиск, либо шифрование.

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

Answer 3

[mayton2019]

Обходные пути есть. Если вы ищете like 'Ив%' чтобы найти всех ивановых то создайте виртуальную
колонку где первые две буквы от имени. И пускай она будет тоже шифрованная. Но для нее
поиск по совпадению и будет аналогом like.

Вобщем создайте столько шифрованных колонок сколько надо. Накладные расходы - обсудите с бизнесом.
Дескыть вы хотели GDPR - получите и распишитесь. Если не даете нам создавать колонки - тогда мы не знаем
как решать вопрсы вашего бизнеса. Эстимируйте в конце концов. Это все цена разработки и она должна
быть обсуждена.

Comments

[ThunderCat]

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

[mayton2019]

ThunderCat, смотря как она шифрует. Если 1 dbblock базы == 1 блок симметричного шифрования - то тогда безразлично.

Answer 4

[Николай Савельев]

В Андроиде можно для этого использовать SqlCipher. База шифруется, но запросы внутри делать можно.
Но в целом надо понимать, что полноценно LIKE не может применяться к шифрованным данным без дешифровки. Соответственно, бэк, сервер, должен знать ключ для дешифрования.
Собственно, именно на этом факте и погорел Павел Дуров, который утверждал, что Телеграм полностью зашифрованный мессенджер.
Но в зашифрованном мессенджере невозможен быстрый поиск по сообщениям (на стороне сервера) без знания приватных ключей. Бинго!

Comments

[d'Ivan]

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

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

[Николай Савельев]

Román Mirilaczvili, ну и?
А расшифровывать сообщение для поиска как?
Можно это делать на клиенте, но тогда не будет индекса, а значит скорость будет ничтожной.
Практика показывает, что поиск в телеграме моментальный, а это означает, что либо сообщения не шифруются и индексируются, либо они имеют твой приватный ключ для дешифрования и делают поиск по предварительно расшифрованным сообщениям.
Быстрого поиска по шифрованным сообщениям сделать невозможно.
Я пробовал

Answer 5

[Dimonchik]

https://manual.manticoresearch.com/Creating_an_ind...