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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

Прежде всего, если вы имеете дело с номерами кредитных карт, вам нужно будет соответствовать требованиям 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. Таким образом, любые 2 диска необходимы для создания полного ключа (A + B + C). Эта схема терпима к потере любого из 1 дисков. Сами ключевые части шифруются паролем, известным только владельцу диска.

Answer 7

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

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

Answer 8

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

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

Ничто из этого не означает, что ваши данные в полной безопасности, конечно.

Answer 9

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

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

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

Answer 10

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

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

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