Хранение номеров социального страхования
Отдел кадров компании, в которой я сейчас работаю, попросил предоставить систему для хранения номеров социального страхования сотрудников в базе данных нашей компании. Причина этого заключается в том, чтобы упростить выполнение расчета заработной платы, так как мы используем собственное программное обеспечение для расписаний сотрудников, но должны интегрироваться со сторонним программным обеспечением для нашей действительной системы расчета заработной платы. Это относительно небольшая компания (20-30 сотрудников), и мы будем хранить только SSN текущих сотрудников (так что нарушение будет иметь ограниченное влияние), но я все же хотел бы рассчитывать на безопасность.
Я хотел бы знать, есть ли какое-либо соглашение для хранения информации, столь же чувствительной как числа социального страхования. Я не очень разбираюсь в шифровании, и я понимаю, что есть несколько методов шифрования, к которым я мог бы прибегнуть, но мне было интересно, есть ли какой-то конкретный способ, который лучше всего подходит для такой ситуации. AES будет моим лучшим выбором?
Что касается текущего программного обеспечения, мы используем MySQL, и наш веб-интерфейс написан на PHP и работает на сервере IIS.
11 ответов
Я нигде не упоминал об этом, но нужно ли, чтобы эта информация была в сети? Если нет, то вы обезопасили один из основных способов атаки, просто сохранив эту информацию в базе данных на компьютере, который не подключен к Интернету. Или, если вам не удастся сохранить его где-то в локальной сети (чтобы HR мог иметь к нему доступ или что-то еще), в отличие от производственных серверов, это все же шаг в правильном направлении.
Вы упомянули, что вы работаете в относительно небольшой компании, но кажется, что вложение в какое-то дешевое оборудование не будет слишком сложным, чтобы убедить лиц, принимающих решения, учитывая преимущества хранения такого рода конфиденциальной информации в автономном режиме. И в ближайшем будущем, за исключением массового увеличения количества сотрудников, вам не понадобится компьютер серверного класса для хранения личной информации о ~30 сотрудниках.
Где бы вы ни хранили это, я бы все равно подумал о каком-то шифровании. AES 256 является стандартом безопасности в наши дни в большинстве приложений и довольно широко поддерживается. Это не похоже на то, что это приложение под какой-либо нагрузкой, так что, опять же, нет ничего плохого в том, чтобы выбрать больший размер ключа вместе с дешевым оборудованием, как это звучит.
Что касается реализации, то, если вы знакомы с MySQL - придерживайтесь этого, у них есть инструменты, необходимые для того, чтобы делать то, что вы хотите: http://dev.mysql.com/doc/refman/5.0/en/encryption-functions.html
В конце концов, безопасность - это все о слоях, ни одно решение не будет серебряной пулей, но вы можете пройти долгий путь, добавив некоторые довольно простые меры безопасности, основанные на здравом смысле.
Изменить: после прочтения того, что сказал Грэм, я чувствую, что должен добавить, что большинство нарушений безопасности - это внутренняя работа - обязательно защитите свои данные на уровне диска, через базу данных и по проводам.
Лучший способ хранения конфиденциальных данных, который я видел, - это шифрование с открытым ключом и хранение закрытого ключа где-то, кроме базы данных (скажем, через приложение, доступное только главе HR и генеральному директору):
Затем мы начали хранить кредитные карты людей... но на сайте мы сразу же зашифровали их с помощью открытого ключа. ...
На бэкэнде у нас был закрытый ключ, и с правильной парольной фразой мы могли временно расшифровать [закрытый ключ], затем использовать [закрытый ключ], чтобы расшифровать кредитную карту, и зарядить карту для DVD.
Мой совет: сохраняйте данные MySQL на зашифрованных дисках, чтобы в случае неправильной установки ноутбука и т. Д. Данные не могли быть восстановлены.
Конечно, если само приложение базы данных взломано, ничто не может помочь, так как само приложение использует SSN. Возможно, это недостаток дизайна, который вы можете исправить. Я склонен думать о небольшом ограниченном приложении, которое сопоставляет SSN с ключом (не-SSN), а затем использует этот новый ключ в качестве "идентификатора пользователя" в вашей базе данных, а не SSN. Я бы избежал распространения самого SSN любой ценой.
Не используйте SSN в качестве первичного ключа или распространяйте их значения больше, чем необходимо. Используйте идентификационные номера сотрудников или другие уникальные идентификаторы. Это уменьшит сложность проблемы.
Если это вообще возможно, храните SSN в совершенно другом экземпляре базы данных и не позволяйте ему получать доступ к повседневным функциям внешнего приложения.
После того как вы изолировали SSN, вы можете использовать любой из предложенных методов для шифрования данных. Шифрование физических таблиц и шифрование сохраненных полей затруднит кражу физических файлов базы данных или просмотр SSN с использованием базового доступа SQL.
Основной задачей является ограничение доступа к таблице SSN с помощью механизмов БД, ограничение доступа к ОС и физическая защита компьютера. Через БД используйте максимально ограниченные возможные разрешения. Не допускайте доступа к таблице через Интернет, онлайн или другие "общие" учетные записи, если это вообще возможно. При доступе к ОС ограничьте входы в систему и доступ к каталогам для хорошо известного списка пользователей. Включите любой возможный аудит. Что касается физической безопасности, машина должна находиться в закрытом / защищенном месте.
Следуйте рекомендациям АНБ по компьютерной безопасности, где хранятся номера SSN и любой компьютер, имеющий доступ к этому компьютеру.
Поскольку вы всего лишь небольшая компания, вам не нужно слишком беспокоиться о хранении почтовых отправлений и средств / страховки для контроля личности в случае взлома. Организации с большим количеством сотрудников и / или клиентов столкнулись с серьезными проблемами при соблюдении требований законодательства для уведомления о нарушении. Найти 26 миллионов конвертов в короткие сроки нелегко.
Вы хотите использовать какое-то обратимое шифрование, чем сильнее, тем лучше, и добавить немного соли в SSN. Добавление соли сделает хакеру более трудным обратное шифрование только с данными из базы данных. Соль должна быть числовой, чтобы сливаться с SSN.
Номера социального страхования подпадают под " PII" (личная информация)... и вы должны зашифровать их, но это не обязательно. Так что, да, AES в полном порядке... правда, все, что вы делаете, является плюсом.
Номера кредитных карт подпадают под соответствие "PCI" (индустрии платежных карт), и это беспорядок. Но в твоем случае ты в порядке.
Кстати: AES 128 считается достаточно хорошим для Visa, Amex, Discover и т. Д. (PCI).
Есть несколько текущих документов, излагающих политику, таких как меморандум Белого дома и отчет GAO.
Помимо этого, есть шифрование, vpn и PKI для безопасности.
MySQL имеет ряд функций шифрования, которые вы можете использовать для кодирования / декодирования. Их должно быть достаточно для внутреннего применения.
Я не уверен, что вы можете сделать это в MySQL, но у вас может быть триггер вставки / обновления в таблицу, который шифрует данные при их сохранении в базе данных, а затем просматривает таблицу, которая автоматически расшифровывает SSN.
Обратите внимание, что это касается только шифрования данных на диске; Вы хотели бы также изучить шифрование на транспортном уровне, чтобы защитить данные в сети (опять же, если MySQL поддерживает это).
Отредактировано, чтобы добавить: Прочитав ответ Марцина, я понял, что не упомянул ключевую проблему управления. Любой, у кого есть доступ к определениям триггера или представления, также имеет доступ к ключу шифрования, поэтому, если MySQL имеет возможность скрывать определения триггера и просмотра, вы должны также изучить это. Конечно, включение ключа шифрования в зашифрованные данные изначально небезопасно, поэтому это не идеальное решение.
Моя рекомендация будет заключаться в ограничении доступа. Имейте только одну учетную запись, способную фактически читать (и при необходимости записывать) таблицу, в которой хранятся SSN. Используйте эту учетную запись из вашего приложения, чтобы получить доступ к БД и заблокировать доступ из любой другой учетной записи.
Ну, вы не дали никакой информации о том, что вы собираетесь делать с этими номерами. Если вам когда-нибудь понадобится получить SSN, то практически ничего не нужно делать с этим - храните его в открытом виде. Любая форма шифрования, где у вас есть зашифрованный текст и ключ в одном и том же месте, лишь немного замедлит атакующего. Это имеет значение только для злоумышленников, которые не могут взять огромные объемы данных, или которые не могут просто взять весь ваш компьютер, или которые не могут присоединиться к точкам. Если вы имеете дело с последним случаем, фактическое управление доступом в первую очередь является более важным.
Однако, если вы получаете SSN извне и хотите узнать, чья это учетная запись, вы можете использовать односторонний хеш для этого.