Рекомендации по интеграции ранее созданной базы данных, содержащей зашифрованные поля, в приложение Rails - PullRequest
0 голосов
/ 23 мая 2019

Я ищу несколько советов о том, как я могу интегрировать зашифрованную ранее существующую базу данных в приложение Rails. У меня уже есть опыт, как я могу получить доступ к данным таблицы, когда данные находятся в незашифрованном виде; это просто указание соединения с базой данных и правильная ссылка на имена полей. Тем не менее, что нужно сделать, если некоторые (или все) поля зашифрованы?

Справочная информация:

У меня есть служба push-уведомлений от третьей стороны, которая заполняет базу данных промежуточного сервера (в настоящее время в виде открытого текста). Я могу получить доступ к данным без проблем, но мне бы хотелось, чтобы служба отправляла конфиденциальную информацию в промежуточную базу данных в зашифрованном виде (то есть данные уже были бы зашифрованы при передаче и сохранены в зашифрованном виде). ​​

Результат этого, однако, будет означать, что мне нужно будет расшифровать некоторые (или все) поля, прежде чем получить к ним доступ. Каковы были бы простые подходы к выполнению этого? Мне нужно было бы иметь возможность выполнять поиск по полям, и мне потребуются существующие методы доступа (например, MODEL_OBJECT#attribute_name, MODEL_NAME#where, MODEL#find_by) при применении к открытому тексту для повторного использования, чтобы не приходилось рефакторировать ад вне кода.

Было бы предположение, что я могу получить данные расшифровки (ключ, соль) и алгоритм, используемый третьей стороной для шифрования отправляемых мне данных. Я смотрел на некоторые драгоценные камни, такие как crypt_keeper (я использовал этот в прошлом), attr_encrypted и symmetric_encryption, но я не уверен, что будет наиболее подходящим. Я бы хотел избежать погони за диким гусем.

1 Ответ

0 голосов
/ 24 мая 2019

После шифрования атрибута вы теряете возможность манипулировать им и запрашивать его через базу данных (find_by / where и другие запросы на уровне таблицы не дадут ожидаемых результатов), потому что любое хорошее шифрование даст другое закодированное значение даже для одни и те же входные данные. Если вы запрашиваете только равенство (where(foo: 'bar')), это можно уменьшить, добавив столбцы с хэшами полей, по которым нужно искать (строго говоря, это ослабляет шифрование).

Если вам нужны более сложные запросы, такие как поиск по подстроке (where('foo like ?', '%bar%')) или диапазону (where('foo > 123')) - тогда соответствующий столбец следует оставить незашифрованным. В противном случае такой запрос будет очень дорогим, потому что вам нужно будет извлечь всю таблицу, расшифровать и проверить каждую запись.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...