Есть более гибкое решение?👌🏻

Если хацкеры все слили, то что им мешает слить и алгоритм шифрования и ключи и соль?

тогда нужно решать на уровне приложения через две функции?Энкриптор и дескриптор?Если я зашифрую, как тогда делать поиск?🤯

зачем шифровать, если он все сопрет и расшифрует базу?

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

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

если он забрал файлы базы, то он заберет и файлы с ключами и исходный код, в чем проблема?

это допущение примерно такого уровня, как "а если он придет к вам домой с паяльником"

У меня стоит задача как мне скрыть электронные адреса и телефоны пользователей, даже если хацеры взломают сайт и получат полный доступ к базе данных и всем файлам?  Или скажите где копать?Мне шифрование подсказали как один из вариантов...Можете прочитать там выше описано...🤷🏻‍♂️

у вас задача некорректно стоит

Как ограничить доступ к БД, я знаю но техзадание не я писал, мне его прислали🤷‍♂️

если злаумышленник получил такой доступ - то ни как

значит писал некомпетентный человек

ничего не смысляший в безопасности

попробую это им объяснить им...😞

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

индификатор- рандомное значение, можно место хеша использовать функцию текущей даты, например, там числа, а не строки, будет работать быстрее. Я вас понял, решение было на уровне архитектуры приложения.Обмен данными между микросервисами лучше реализовать реализация с помощью системы обмена сообщениями на базе "очереди сообщений", что  позволит не останавливаться на вопросах масштабирования.Или лучше использовать паттерн SAGA https://microservices.io/patterns/data/saga.html

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

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

не совсем понял вас, тут не доступ к БД нужно защитить, хотя конечно нужно, а сами поля таблицы сделать нечитаемыми для злоумышленника, как выше говорилось это можно сделать при помощи архитектуры микросервисов, уйдя от вылизанной монолитки...👌🏻🤏🏼Или вы другое имели ввиду?