Шифрование данных

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

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

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

Ну, база данных ORACLE, поэтому у меня есть PL/SQL и Java.

ОТВЕТЫ

Ответ 1

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

Большинство компаний ссылаются на это как на что-то вроде "Управление профилями клиентов" и на самом деле довольно разумны в отношении сборов.

Несколько поставщиков, которых я знаю (в определенном порядке):

Ответ 2

Если вы не являетесь платежным процессором, вам не нужно хранить какую-либо информацию CC.

Проверьте свои требования, действительно, не так много случаев, когда вам нужно хранить информацию CC

Ответ 3

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

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

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

Ответ 4

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

Когда вам нужно действовать по номеру кредитной карты?

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

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

Ответ 5

Если вы используете Oracle, вас может заинтересовать Прозрачное шифрование данных. Доступно только с корпоративной лицензией.

В Oracle также есть утилиты для шифрования - дешифрования, например DBMS_OBFUSCATION_TOOLKIT.

Что касается "Стандартов", то соответствующий стандарт, который вас интересует, это стандарт PCI DSS, который описывает, какие меры необходимо принять защищать конфиденциальную информацию о кредитной карте.

Ответ 6

Для варианта использования типа электронной коммерции (подумайте, что Amazon 1-Click) вы можете зашифровать CC (или ключ) с помощью существующего надежного пароля пользователя. Предполагая, что вы храните только хэш пароля, только пользователь (или таблица радуги - но он должен быть запущен для каждого пользователя и не будет работать, если он не придумал один и тот же пароль - не только 1, который hashed то же самое) может расшифровать его.

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

Ответ 7

Было бы полезно знать серверы БД и язык/типы платформ, чтобы мы могли получить более конкретную информацию, но я бы посмотрел на SHA.

Ответ 8

Я бы симметрично шифровал (AES) безопасный соленый хэш (SHA-256 + соль). Соленого хеша было бы достаточно с большой солью, но шифрование добавляет немного лишнего, если база данных, а не код, протекает, и к тому времени или какие-то другие средства есть радужные таблицы для соленых хэшей. Храните ключ в коде, а не в базе данных, конечно.

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