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

Question

Хранение информации кредитной карты безопасно и юридически очень сложно и should not be attempted. Я не собираюсь хранить данные кредитной карты, но я умираю, чтобы понять следующее:

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

Мой вопрос заключается в следующем: если вам было поручено хранить данные кредитной карты, какую стратегию шифрования вы использовали бы для защиты данных на диске? Из того, что я могу сказать, представленная информация о кредитной карте проверяется более или менее в режиме реального времени. Я сомневаюсь, что любой ключ шифрования, используемый для защиты данных, вводится вручную, поэтому дешифрование выполняется «на лету», что означает, что сами ключи хранятся на диске. Как вы можете защитить свои данные и свои ключи в автоматизированной системе?

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

Hashing Credit Card Numbers: Unsafe Application Practices

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

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

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

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

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

Answer 4

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

Answer 5

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

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

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

Answer 6

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

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

Для получения дополнительной информации: Deploying SQL Server 2008 Based on Payment Card Industry Data Security Standards (PCI DSS) Version 1.2.

Answer 7

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

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

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

Answer 8

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

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

Answer 9

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

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

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

Answer 10

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

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

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

Answer 11

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