Как обезопасить пользовательские данные в базе данных с помощью Rails?

Question

Я создаю приложение rails, которому нужно хранить большое количество конфиденциальных данных. Чтобы заверить своих клиентов в том, что данные защищены, я хочу зашифровать их для каждого пользователя. Я провел исследование в поисках драгоценных камней, которые могут это сделать. До сих пор я нашел сейф и сейф . Вместе это, казалось бы, предоставило мне решение.

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

Answer 1

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

Всегда предполагайте, что если хакер может поставить под угрозу любую часть вашей безопасности, он может поставить под угрозу все это. Цепочка настолько же сильна, насколько ее самое слабое звено и все такое.

Номера кредитных карт и номера социального страхования (которые, к счастью, обычно не нужно индексировать), вероятно, являются наиболее очевидным исключением из этого, но если вам придется задать этот вопрос, у вас нет бизнеса, хранящего эти предметы на первом месте. Есть много юридических проблем, с которыми вы можете столкнуться, чтобы все испортить.

Answer 2

Номер кредитной карты, номера SSN и т. Д. Всегда должны храниться в зашифрованном виде.

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

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

class User
  # has db column encrypted_cc_number
  def unencrypted_cc_number
    WhateverEncryptionClassYouUse.decrypt(encrypted_cc_number)
  end
  def unencrypted_cc_number=(val)
    self.encrypted_cc_number = WhateverEncryptionClassYouUse.encrypt(val)
  end
end

Answer 3

Рекомендуется использовать многоуровневые механизмы безопасности и надежную криптографию, если вы храните большое количество конфиденциальных данных. Это требуется стандартом безопасности данных индустрии платежных карт (PCI DSS). Я предлагаю вам прочитать следующий руководящий документ: https://www.pcisecuritystandards.org/pdfs/pci_fs_data_storage.pdf.

Вы определенно не должны «предполагать, что это никогда не будет скомпрометировано»