Кто-то хранит данные кредитной карты - как они это делают?

Ответ 1

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

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

Зашифруйте что-то вроде AES. Необработанный ключ AES хранится только в ОЗУ. Ключ завернут в файл PGP для каждого администратора, у которого есть своя кодовая фраза для включения сервера. Менее доверяемому персоналу могут быть предоставлены частичные фразы для использования при аварийном восстановлении, или кодовые фразы могут храниться в хранилище где-то. Для шифрования выберите уникальный вектор инициализации (IV) для каждого номера карты, AES-зашифруйте номер, используя этот IV, и сохраните IV и зашифрованный номер в SAN. Расшифровка происходит только с использованием привилегированного клиентского интерфейса; обычные клиентские подключения, используемые для покупок, никогда не могут получить расшифровку.

Ответ 2

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

Но это лучше, чем ничего, я полагаю.

Ответ 3

Очень легко хранить соленый хэш номера кредитной карты, а не номер для безопасного поиска. Для 99% сценариев там будет достаточная кредитная карта для хранения - быстрая и безопасная.

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

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

Edit: По моему мнению, есть некоторые противоречия. Я хотел бы отметить следующее очень интересное эссе от Integrity.com(PDF):

Хеширование номеров кредитных карт: небезопасная практика применения

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

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

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

Противники находятся в поиске; не удалось эффективно найти конкретный номер кредитной карты во многих транзакциях.

Конечно, у вас будет эта проблема с внешним шифрованием; если сама база данных не зашифрована (что-то поддерживает только некоторые базы данных), вы не сможете очень хорошо искать. Даже тогда шифрование в базе данных или даже на уровне таблицы значительно снижает эффективность поиска.

Ответ 4

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

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

Возможно, не точный ответ, который вы искали, но, возможно, он может решить вашу общую проблему, не потратив целое состояние на поставщиков безопасности.

Ответ 5

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

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

Ни одно из них не означает, что ваши данные совершенно безопасны, конечно.

Ответ 6

В качестве продавца вы можете хранить данные CC в своей собственной базе данных или передавать их сторонним поставщикам. Сторонние поставщики, такие как IPPayments или крупные банки, такие как Westpac в Австралии соответствуют уровню 1 PCI. Для веб-приложений вы можете использовать веб-страницу для приема платежей (представленную где-то в рабочем процессе клиента) от их брендов для вашей компании. Для приложений Windows (например, приложение CRM для вашей компании) и периодических платежей они обычно используют шлюз, используя их API, которые предоставляют услугу токенизации, то есть они принимают номер CC, регистрируют его и возвращают уникальный токен, который просто выглядит как номер CC, Токен можно безопасно хранить в вашей БД и использовать для любых дальнейших транзакций, пакетных платежей, сверки и т.д. С банком. Конечно, большая проблема - это операционная стоимость одной транзакции. Для утилиты, которая ежемесячно берет платеж по кредитной карте от миллиона клиентов, стоимость транзакции может быть существенной.

Если вы решите сохранить номер CC в своем собственном DB, тройное шифрование DES достаточно. Лучший вариант - это прозрачное шифрование в БД, предлагаемое расширенной безопасностью Oracle или SQLServer, где даже администратор баз данных не может расшифровать номер CC. Тогда есть обременительная ответственность за управление ключами, резервное копирование, физическую безопасность, сетевую безопасность, передачу SSL, изменение настроек по умолчанию для всех серверных устройств и брандмауэра, антивирус, аудит, камеры безопасности и многое другое...

Ответ 7

Прежде всего, если вы имеете дело с номерами кредитных карт, вам нужно будет PCI-DSS, и как только вы сохраните номера всего 12 разделы спецификации PCI-DSS будут применяться к вам. Это большая стоимость для большинства организаций, и если у вас нет времени, ресурсов и финансовых средств, вы не должны идти по пути хранения номеров кредитных карт.

Мы получили соответствие PCI-DSS в системе электронной коммерции, основанной на Windows, которая хранит кредитные карты. Он использует 256-битное шифрование AES. Сам ключ шифруется с помощью Windows DPAPI, что означает, что он может быть дешифрован только процессом, запущенным под той же учетной записью пользователя, что и тот, который зашифровал его. Зашифрованный ключ хранится в реестре.

Ключ поворачивается каждые 12 месяцев, а копия резервной копии сохраняется в 3 части A, B, C и распространяется на 3 USB-накопителя, каждый из которых хранится у другого человека. Привод 1 имеет A + B, привод 2 имеет B + C, привод 3 имеет A + C. Поэтому для создания полного ключа (A + B + C) требуется 2 диска. Эта схема терпима к потере любых 1 накопителей. Сами ключевые части зашифрованы с помощью пароля, известного только владельцу накопителя.

Ответ 8

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

Ответ 9

Чтобы ответить на ваш конкретный вопрос, можно сохранить ключ шифрования кредитной карты, зашифрованный на диске. Ключевой ключ шифрования может быть получен из кодовой фразы, которая должна быть введена при запуске сервера. Шамировскую схему разделения можно использовать так, чтобы k из N акций требовалось построить секрет, который будет использоваться в качестве ключевого ключа шифрования. Затем дешифрованный ключ/секрет шифрования сохраняется в памяти. Если сервер должен быть перезапущен, вам нужны k акций. Это, конечно, большие накладные расходы, и большинство продавцов, которых я знаю, не реализуют это. Тем не менее, они обычно хранят ключ отдельно от зашифрованных данных для некоторой промежуточной защиты, поэтому доступ к одному автоматически не означает доступ к другому целиком (все еще очень плохо).

Я удалил содержимое моего оригинального сообщения, так как не ответил прямо на вопрос. Достаточно сказать, что управление ключами и правильное шифрование - важная часть, но все же небольшая часть истории.

Аудиторы PCI не могут гарантировать, что все сделано правильно.

Ответ 10

Если вы хотите удалить любую кредитную карту, ставящую головные боли, используйте их, используя значения солей, которые не хранятся в базе данных (в дополнение к значениям соли, хранящимся в базе данных). Хеширование их с помощью любого современного алгоритма хэширования в значительной степени положит конец большинству проблем с кражей кредитных карт, но это означает, что потребители должны повторно вводить свою кредитную карту при каждой покупке. Работая над проектом, связанным с хранением номеров кредитных карт, я обнаружил, что хэширование их сократило затраты на проверку безопасности на порядок (если этот проект был до того, как был затронут PII).

Если вы собираетесь использовать симметричное шифрование, вы входите в новую область сложности, которая сводится к управлению и контролю над ключами дешифрования. Я скажу, что даже если у вас есть номера кредитных карт, вам все равно придется иметь дело с обратимым шифрованием, поскольку все PII (личная идентификационная информация) должны быть зашифрованы. SQL Server 2008 имеет новую расширяемую функциональную схему расширения Mangement Key, которая позволяет использовать сторонние программные продукты для управления управлением ключами дешифрования, включая разделенные ключи.

Для получения дополнительной информации: Развертывание SQL Server 2008 на основе стандартов безопасности данных в индустрии платежных карт (PCI DSS) версии 1.2.

Ответ 11

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