Хранение номеров социального страхования

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

Тогда мы начали хранить people’s кредит cards†¦, но на веб-сайте we’d сразу шифруют их с открытым ключом....

На бэкенде, у нас был закрытый ключ, и с правильным паролем мы могли временно дешифровать [закрытый ключ], затем использовать [закрытый ключ], чтобы дешифровать кредитную карту и взимать карту за DVD.

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

, Если само приложение базы данных поставилось под угрозу, конечно, ничто не может помочь, поскольку само приложение использует SSNs. Возможно, это - недостаток дизайна, который можно исправить. Я был бы склонен думать с точки зрения маленького, ограниченного приложения, которое отображает SSN на (non-SSN) ключ и затем использование что новый ключ как "идентификатор пользователя" в Вашей базе данных, а не SSN. Я избежал бы быстрого увеличения самого SSN любой ценой.

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

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

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

основное беспокойство должно ограничить доступ к таблице SSN через механизмы DB, ограничить доступ ОС и защитить машину физически. Через DB используйте самые ограниченные возможные полномочия. Не позволяйте сеть, онлайн, или другой "общий" доступ к счету к таблице если вообще возможный. На доступе ОС ограничьте логины и доступ каталога к известному списку пользователей. Включите любого и весь возможный аудит. До физической безопасности машина должна быть в, блокировал/защищал местоположение.

Следуют инструкции NSA на компьютерной безопасности, где SSN's хранится и любая машина, которая имеет доступ к той машине.

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

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

Номера социального страхования подпадают под" PII" (информация, позволяющая установить личность)..., и Вы должны шифровать их, но это не требуется. Так, да AES прекрасно подходит... действительно, что-либо, что Вы делаете плюс.

Номера кредитных карт подпадают под "PCI" (Промышленность Платежной карты) соответствие, и это - путаница. Но в Вашем случае, Вы в порядке.

BTW: AES 128 считают совершенно достаточно хорошим для Визы, AMEX, Узнайте, и т.д. (PCI).

Существует несколько текущих документов, указывающих политику такой как записка Белого дома и отчет ГАО отчет .

ГАО Кроме того, существует шифрование , vpn, и PKI для безопасности.

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

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

Примечание, что это только имеет дело с шифрованием данных на диске ; Вы хотели бы изучить шифрование транспортного уровня также для защиты данных по проводу (снова, если поддержки MySQL это).

Отредактированный для добавления: После чтения ответа Marcin я понял, что не упоминал проблему управления ключами. У любого, у кого есть доступ к триггеру или определениям представления также, есть доступ к ключу шифрования, поэтому если бы MySQL имеет способность скрыть триггер и определения представления, Вы хотели бы изучить это также. Конечно, включая ключ шифрования с зашифрованными данными по сути небезопасно во-первых, таким образом, это не прекрасно решение.

Моя рекомендация состояла бы в том, чтобы полагаться на ограничение доступа. Только имейте единственную учетную запись, которая в состоянии на самом деле считать (и если необходимая запись) таблицу, где SSN's хранится. Используйте ту учетную запись из своего приложения, чтобы получить доступ к дб и блокировать доступ из любой учетной записи.

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

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