Кто - то хранит данные кредитной карты-как они это делают?
хранение информации о кредитной карте надежно и юридически очень сложно и не должно быть предпринято. Я не собираюсь хранить данные кредитной карты, но я умираю, чтобы выяснить следующее:
информация о моей кредитной карте хранится на сервере где-то в мире. Эти данные (надеюсь) не хранятся на сервере продавца, но в какой-то момент они должны быть сохранены для проверки и взимания платы с учетной записи, идентифицированной представленными данными продавца.
мой вопрос заключается в следующем: если бы вам было поручено хранить данные кредитной карты, какую стратегию шифрования вы бы использовали для защиты данных на диске? Из того, что я могу сказать, представленная информация о кредитной карте проверяется более или менее в режиме реального времени. Я сомневаюсь, что любой ключ шифрования, используемый для защиты данных, вводится вручную, поэтому дешифрование выполняется на лету, что означает, что сами ключи хранятся на диске. Как бы вы защитили свои данные и ключи в автоматизированной системе, например это?
11 ответов:
Если бы я хранил номер, я был бы гигантским поставщиком услуг с массивной базой данных. Эта база данных распределена по сильно избыточному массиву хранения, состоящему из нескольких шкафов, в отдельных комнатах или, в идеале, в отдельных географических местах, Соединенных SAN. Моя самая большая внутренняя угроза-это распределенный физический завод, постоянный поток изношенных дисков и несколько ежедневных смен техников, администраторов и инженеров. Это огромный угроза.
поэтому я бы зашифровал данные на физически изолированном компьютере, который подключается к массовому хранилищу по сети. Программное обеспечение будет максимально простым: шифрование и проверка номера. Публичные интерфейсы и бизнес-логика идут в другом месте. Доступы будут регистрироваться в отдельном SAN.
шифрование с чем-то вроде AES. Необработанный ключ AES хранится только в оперативной памяти. Ключ завернут в файл PGP для каждого администратора, который имеет свой собственный пароль для включения сервера. Менее доверенному персоналу могут быть предоставлены частичные парольные фразы для использования в аварийном восстановлении, или парольные фразы могут храниться где-то в хранилище. Для шифрования выберите уникальный вектор инициализации (IV) для каждого номера карты, AES-зашифруйте номер с помощью этого IV и сохраните IV и зашифрованный номер в SAN. Расшифровка происходит только с использованием привилегированного клиентского интерфейса; обычные клиентские соединения, используемые для покупок, могут никогда получить расшифровку.
для поставщиков, чтобы обрабатывать и хранить информацию о вашей кредитной карте, они, как правило, должны получить сертификат PCI. Требования должны быть изложены здесь. Некоторые требования очень просты, а другие расплывчаты и открыты для интерпретации. Проходить через этот процесс не весело, и компания, имеющая сертификацию, не означает, что ваши данные безопасны.
но это лучше, чем ничего, я полагаю.
довольно легко хранить соленый хэш номера кредитной карты, а не сам номер для безопасного поиска. Для 99% сценариев там, это было бы достаточно кредитной карты для хранения -- быстро и очень безопасно.
Если вам действительно нужны реверсивные шифрование кредитной карты для некоторого сценария (продолжение биллинга, например), я бы пошел с симметричным ключом, хранящимся в безопасном месте другое базы данных. Это было время поскольку я посмотрел на спецификации PCI, но я довольно уверен, что это PCI-совместимый.
Если вам нужен быстрый поиск вместе с обратимым шифрованием, используйте оба варианта: хэш и шифрование.
Edit: Кажется, есть некоторые разногласия по поводу моего ответа. Я хотел бы отметить следующее Очень интересное эссе: Integrity.com (PDF):
Хеширование Номеров Кредитных Карт: Небезопасная Практика Применения
Это детали многие вопросы связаны с хранением хэша данных кредитных карт, но его вывод подтверждает мое предложение.
да, сырой хэш карты не является безопасным; вот почему мы солим наши хэши! Но статическая соль также не безопасна, они позволяют создавать радужные таблицы для известных статических солей. Поэтому лучше всего, чтобы наши соли менялись каким-то непредсказуемым образом. В случае паролей достаточно использовать отдельный случайный хэш для каждого проверяемого пароля; он может даже находиться в той же таблице/строке, что и хешированный пароль. В случае с кредитными картами, это должно быть то же самое-случайную соль для каждого экземпляра кредитная карта быть хэширован. Если номер кредитной карты хранится для каждой транзакции, для каждой транзакции используется отдельная соль.
есть плюсы и минусы такого подхода, но это достаточно безопасно. Плюсы-отсутствие управления ключами; соль и хэш прямо там, и не нужно менять, все еще позволяя проводить аудиторские проверки хэш; например, соответствует ли этот хэш кредитной карты этому известному номеру кредитной карты?
минусы находятся в поиске; невозможно эффективно искать конкретный номер кредитной карты во многих транзакциях.
конечно, у вас все равно будет эта проблема с внешним шифрованием; если база данных сама не зашифрована (что-то поддерживает только некоторые базы данных), вы не сможете очень хорошо искать. Даже тогда шифрование в базе данных или даже на уровне таблицы уменьшает эффективность поиска значительно.
последние несколько раз, когда я работал с платежами по кредитным картам, вы никогда не сохраняли фактическую информацию CC на своих собственных серверах. Вы позволяете платежному шлюзу обрабатывать это. В итоге вы получили идентификатор транзакции, который можно использовать для проверки того, что кредитная карта все еще действительна и имеет запрошенную сумму наличных денег. Затем, как только вы фактически упаковали вещи, которые они купили, вы бы выдали команду захвата платежному шлюзу.
такой подход значительно упростил процесс интеграции платежей CC на сайте, так как все, что вам когда-либо нужно было знать, это transactionID для конкретного клиента. Это, конечно, не позволило вам сделать с amazon-"трюк" сохранения вашей информации CC для покупок в 1 клик. Если транзакционный идентификатор был скомпрометирован, все, что он мог использовать, - это ранний сбор платежа или полная отмена транзакции (в этом случае вы узнаете об этом, когда вы проверите, что авторизация все еще действительна перед отправкой). Сделка не может быть используется для сбора большей суммы, чем то, что клиент уже одобрил, и не позволит кому-то собирать на другой счет, чем то, для чего был настроен "магазин".
может быть, не точный ответ, который вы искали, но, возможно, это может решить вашу общую проблему, не тратя целое состояние на поставщиков безопасности.
в некоторых ситуациях ключи шифрования хранятся не на диске, а на каком-то аппаратном устройстве. Либо специальный сервер шифрования используется для шифрования / дешифрования, либо дешифрование выполняется с помощью ключа, хранящегося, скажем, на аппаратном ключике. Таким образом, хакер не может украсть ключи расшифровки без кражи физического устройства, содержащего их (так как ключ никогда не покидает устройство).
другой метод, который я видел, заключается в хранении зашифрованных данных в базе данных / центре обработки данных, который не имеет прямого подключение к внешнему миру (вы не можете взломать то, что вы не можете получить доступ). Интерфейсный сервер находится между " защищенной "частью сети и"обращенной к интернету"/" небезопасной " частью сети в качестве прокси-сервера. Принудительное перенаправление защищенного трафика через эту точку блокировки безопасности может затруднить злоумышленнику доступ к защищенным данным.
ни один из них не означает, что ваши данные совершенно безопасны, конечно.
в качестве продавца вы можете хранить данные CC в своей собственной базе данных или передавать их сторонним поставщикам.
Сторонние поставщики, такие как IPPayments или крупные банки, как Westpac В Австралии уровень 1 PCI-совместимый. Для веб-приложений вы можете использовать веб-страницу приема платежей (представленную где-то в рабочем процессе вашего клиента) из них, заклейменных для вашей компании. Для приложений windows (например, CRM-приложение вашей компании) и периодических платежей у них обычно есть шлюз, используемый с помощью их API, которые предоставляют службу токенизации, то есть они принимают номер CC, регистрируют его и возвращают уникальный токен, который просто выглядит как номер CC. Токен можно безопасно хранить в вашей БД и использовать для любых дальнейших транзакций, пакетных платежей, сверки и т. д. с банком. Конечно, они большая проблема-это операционные затраты на транзакцию. Для утилиты, которая принимает ежемесячный платеж по кредитной карте от миллиона клиентов, стоимость транзакции может быть существенный.Если вы решите сохранить номер CC в своем собственном DB, достаточно шифрования triple DES. Лучшим вариантом является прозрачное шифрование в БД, предлагаемое Oracle advanced security или SQLServer, где даже DBA не может расшифровать номер CC. Тогда есть обременительная ответственность за управление ключами, резервное копирование, физическую безопасность, безопасность сети, передачу SSL, изменение настроек по умолчанию всего серверного оборудования и брандмауэра, антивирус, аудит, безопасность камеры и так далее ...
прежде всего, если вы имеете дело с номерами кредитных карт, вам нужно будет стать PCI-DSS совместимый, и как только вы сохраните номера, все 12 разделов спецификации PCI-DSS будут применяться к вам. Это большая стоимость для большинства организаций, и если у вас нет времени, ресурсов и финансовых средств, вы не должны идти по пути хранения номеров кредитных карт.
мы получили соответствие PCI-DSS в системе электронной коммерции на базе Windows, которая хранит кредитные карты. Он использует 256 битного шифрования AES. Сам ключ шифруется с помощью Windows DPAPI это означает, что он может быть расшифрован только процессом, запущенным под той же учетной записью пользователя, что и тот, который его зашифровал. Зашифрованный ключ хранится в реестре.
ключ вращается каждые 12 месяцев,а резервная копия ключа хранится разбитой на 3 части A,B, C и распространяется на 3 USB-накопителя, каждый из которых принадлежит другому человеку. Диск 1 имеет+Б, диск 2 Б+С, диск 3 имеет+С. Так что 2-х любых дисков необходимо построить полный ключ (A+B+C). Эта схема устойчива к потере любого 1 из дисков. Сами ключевые части шифруются паролем, известным только владельцу диска.
ваше предположение, что торговец должен хранить карту каким-то образом неверно. Скорее всего, продавец хранит токен, который он получил от шлюза обработки платежей при первом использовании карты. Токен однозначно идентифицирует комбинацию мерчанта и карты. Впоследствии вы можете совершать покупки у этого продавца, не указывая номер своей карты снова. Если база данных торговца скомпрометирована, токены имеют небольшую ценность для злоумышленника. Они действительны только для этого торговца, и все они могут быть отменены сразу же, когда будет обнаружено нарушение.
чтобы ответить на ваш конкретный вопрос, можно хранить ключ шифрования кредитной карты в зашифрованном виде на диске. Ключ шифрования ключа может быть получен из парольной фразы, которая должна быть введена при запуске сервера. Схема разделения секрета Шамира может быть использована таким образом, что для построения секрета, который будет использоваться в качестве ключа шифрования, требуется k из N акций. Расшифрованный ключ шифрования / секрет затем сохраняется в памяти. Если сервер должен быть перезапущен, то вам нужно к акции. Этот конечно, это большие накладные расходы, и большинство продавцов, которых я знаю, не реализуют это. Однако они обычно хранят ключ отдельно от зашифрованных данных для некоторой промежуточной безопасности, поэтому доступ к одному автоматически не означает доступ к другому полностью (все еще очень плохо).
Я удалил содержимое моего исходного сообщения, так как это не дало прямого ответа на вопрос. Достаточно сказать, что управление ключами и правильное шифрование являются важной частью, но все же небольшой частью истории.
аудиторы PCI не могут гарантировать, что все сделано правильно.
Если вы хотите устранить любые головные боли при краже кредитных карт, хэшируйте их с помощью значений соли, не хранящихся в базе данных (в дополнение к значениям соли, хранящимся в базе данных). Хеширование их с помощью любого современного алгоритма хеширования в значительной степени устранит большинство проблем с кражей кредитных карт, но это означает, что потребители должны повторно вводить свою кредитную карту при каждой покупке. Работая над проектом, который занимался хранением номеров кредитных карт, я обнаружил, что хеширование их сокращает расходы на проверку безопасности порядок величины (при условии, что этот проект был до проблем PII).
Если вы собираетесь использовать симметричное шифрование, то вы входите в новый уровень сложности, что все сводится к управлению и контролю за ключи для расшифровки. Я скажу, что даже если вы хэш номера кредитных карт вам все равно придется иметь дело с обратимым шифрованием, так как все PII(личная информация) должны быть зашифрованы. В SQL Server 2008 включает новую расширяемого ключа плагин управления архитектура, которая позволяет использовать программы сторонних поставщиков для управления контролем над ключами дешифрования, включая разделенные ключи.
для получения дополнительной информации: развертывание SQL Server 2008 на основе стандартов безопасности данных индустрии платежных карт (PCI DSS) версии 1.2.