Лучшие практики / Шаблоны для защиты предприятия / Восстановление SSN (номера социального страхования)

Question

Мне интересно услышать о корпоративных решениях для обработки SSN. (Я выглядел довольно тяжело для любого ранее существующего поста на SO, включая просмотр автоматизированного списка связанных вопросов terriffic SO, и ничего не нашел, так что, надеюсь, это не повторится.)

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

1. Требуется для взаимодействия с внешними объектами. Это наиболее допустимый случай, когда внешние сущности, с которыми взаимодействует ваша система, требуют SSN. Обычно это государственные, налоговые и финансовые.

2. SSN используется для обеспечения уникальности всей системы.

3. SSN стал внешним ключом по умолчанию, который используется внутри внутри предприятия для выполнения межсистемных объединений.

4. SSN используется для аутентификации пользователя (например, вход в систему)

Корпоративное решение, которое мне кажется оптимальным, заключается в создании единого репозитория SSN, к которому обращаются все приложения, которым требуется поиск информации о SSN. Этот репозиторий заменяет истинный SSN глобально уникальным случайным 9-значным числом (ASN). Я вижу много преимуществ этого подхода. Во-первых, он, очевидно, обладает высокой обратной совместимостью - все ваши системы «просто» должны пройти основную синхронизированную одноразовую очистку данных, где они заменяют реальный SSN альтернативным ASN. Кроме того, он централизован, что сводит к минимуму возможности для проверки и соответствия. (Очевидно, что в качестве негатива он также создает единую точку отказа.)

Этот подход позволил бы решить проблемы 2 и 3, не требуя поиска для получения реального SSN.

Для проблемы # 1 авторизованные системы могут предоставить ASN и получить реальный SSN. Это, конечно, будет сделано через безопасные соединения, и запрашивающие системы никогда не сохранят полный SSN. Кроме того, если запрашивающей системе нужны только последние 4 цифры номера SSN, это все, что когда-либо будет передано.

Проблема № 4 может быть обработана так же, как проблема № 1, хотя, очевидно, лучше всего отказаться от предоставления пользователям SSN для входа в систему.

Об этом есть пара статей:

• UC Berkely

• Oracle Vault

Answer 1

Я столкнулся с компанией Voltage, которая поставляет продукт, который выполняет шифрование с сохранением формата 1002 * (FPE). Это заменяет произвольное, обратимо зашифрованное 9-значное число для реального SSN (в примере SSN). Только на ранних стадиях изучения их технического маркетингового обеспечения ...

Answer 2

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

Answer 3

Следует отметить, что SSN являются PII, но не являются частными. SSN - это общедоступная информация, которую легко получить из многочисленных источников, даже онлайн. Тем не менее, если SSN являются основой вашего первичного ключа БД, у вас серьезные проблемы с безопасностью в вашей логике. Если эта проблема очевидна на крупном предприятии, я бы остановил ваши действия и рекомендовал бы массовую миграцию данных ПРЯМО СЕЙЧАС.

Что касается защиты, то SSN - это PII, который является уникальным и небольшим по полезной нагрузке, поэтому я бы защищал эту форму данных не иначе, как пароль для одноразовой аутентификации. Последние четыре из SSN часто используются для проверки или неуникальной идентификации, поскольку они очень уникальны в сочетании с другим атрибутом данных и не являются PII сами по себе. При этом последние четыре SSN могут быть реплицированы в вашей БД для открытого альтернативного использования.