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

Ответ 1

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

Вы упомянули, что находитесь в относительно небольшой компании, но, похоже, инвестиции в какое-то дешевое оборудование не будут слишком сложными, чтобы убедить лиц, принимающих решения, учитывая преимущества хранения такого рода конфиденциальной информации не в сети. И в ближайшем будущем, не допуская массового найма на работу, вам не нужен компьютер класса сервера для хранения личной информации на ~ 30 сотрудников любыми способами.

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

Что касается реализации, если вам удобно с MySQL - придерживайтесь этого, у них есть инструменты, необходимые для выполнения того, что вы хотите: http://dev.mysql.com/doc/refman/5.0/en/encryption-functions.html

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

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

Ответ 2

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

Затем мы начали хранить кредитные карты людей... но на сайте сразу же зашифровали их с помощью открытого ключа....

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

Ответ 3

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

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

Ответ 4

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

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

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

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

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

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

Ответ 5

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

Ответ 6

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

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

BTW: AES 128 считается совершенно хорошим для Visa, Amex, Discover и т.д. (PCI).

Ответ 7

Существует несколько текущих документов, в которых указывается политика, такая как заметка Белого дома и отчет GAO Отчет GAO.

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

Ответ 8

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

Ответ 9

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

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

Отредактировано для добавления: после прочтения ответа Марцина я понял, что я не упоминал о проблеме управления ключами. Любой, у кого есть доступ к определениям триггера или представления, также имеет доступ к ключу шифрования, поэтому, если MySQL имеет возможность скрывать определения триггера и представления, вы также должны заглянуть в это. Конечно, в том числе ключ шифрования с зашифрованными данными, по сути, небезопасен в первую очередь, поэтому это не идеальное решение.

Ответ 10

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

Ответ 11

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

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