Сбор информации кредитной карты - не собирать платеж

Я работаю в PHP на сервере Linux с MySQL.

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

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

Мой вопрос: есть ли способ сделать это безопасным? Если нет сторонних вариантов, чтобы это произошло?

EDIT:

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

Ответ 1

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

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

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

Его по-прежнему очень важно, потому что многие области PCI-DSS вступят в игру даже с этим упрощенным решением.

Вы спросили, так вот больше информации:

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

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

Начнем с рассмотрения PCI-DSS SAQ (вопросники самооценки). Эти SAQ являются минимальными требованиями для компаний, которые не хранят данные владельца карты на диске, и должны давать хорошее представление о безопасности, которая должна быть установлена в сети, и политиках, которые должны применяться во всех компания.

Как я уже сказал, если вы собираетесь хранить данные о карте, тогда все усложняется, потому что, как правило, SAQ уже недостаточно хорош. Вам необходимо заручиться помощью QSA (Qualified Security Assessor), который посетит и предоставит рекомендации по передовому опыту хранения данных и различным другим моментам, которые вступают в игру. Для этого уровня соответствия вы просматриваете ежегодные аудиты (проводимые QSA) и ежеквартальные проверки сети. Ознакомьтесь с процедурами аудита чтобы получить подробный обзор того, что задействовано. В частности, посмотрите раздел 3 и не недооценивайте трудность внедрения надлежащего управления ключами.

Таким образом, полное соблюдение PCI будет очень дорогостоящим. Даже для компании, которая уже имеет довольно сильные политики безопасности, затраты на ввод QSA и ежеквартальные проверки и ежегодные аудиты, вероятно, будут стоить тысячи долларов.

Ответ 2

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

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

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

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

Ответ 3

Это очень неуверенно, и я думаю, что вы правы, чтобы противостоять ему. Тем не менее...

Некоторые идеи:

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

Ответ 4

Я предлагаю вам, по крайней мере, следовать требованиям PCI Card. Здесь - документ в формате PDF.

Ответ 5

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

Ответ 6

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

К счастью, сайты, такие как authorize.net, braintree.com, paypal.com и т.д., позволят вам взаимодействовать со своими API-интерфейсами таким образом, чтобы вы получили "идентификатор хранилища клиентов" для каждого объекта, который вы хотите совершать для.

Эти третьи стороны хранят всю конфиденциальную информацию на 100% законном пути. И всякий раз, когда вы хотите совершить транзакцию с использованием сохраненной информации, вы взаимодействуете с сервисом, используя свой "идентификатор хранилища".

Я использовал authorize.net, BrainTree и PayPal. Совсем недавно он был BrainTree и имел хороший успех с ними. Я бы не рекомендовал PayPal, если вам не требуется признание бренда, или вы просто хотите сделать прямую передачу, посредством которой вы обходите запрос на их учетную информацию любого типа (поскольку они уже вошли в PayPal).

Ответ 7

Убедитесь, что ваш сервер максимально безопасен и доказывает, что он еще не скомпрометирован. Ничто из этого не будет действительно хорошо работать, если у вас есть скомпрометированный сервер.
Используйте SSL для защиты этой информации во время транспортировки.
Зашифруйте эти данные сразу после получения. Это поможет защитить его в покое. Если возможно, зашифруйте его с помощью открытого ключа для пары ключей, где закрытый ключ (используемый для дешифрования) не на вашем сервере. Это может быть легко, что вы размещаете эту информацию в теле письма, которое требуется отправить, а затем шифруйте тело с помощью шифрования с открытым ключом, где у вашего клиента есть закрытый ключ. (Здесь вы можете использовать PGP). Таким образом, данные помогают на вашем сервере как можно короче, а затем сразу после вашего сервера доступны только вашим клиентом. Если вы используете симметричный алгоритм шифрования, то ваш ключ обязательно будет находиться на вашем сервере где-нибудь (на диске, в памяти и т.д.), Который может быть получен и использован злоумышленником для восстановления доступа к деталям.

Это не одобрение, как таковое, но я использовал это раньше в подобных ситуациях с хорошими результатами: http://www.pgp.com/products/commandline/

Помните, что всегда есть дыры в безопасности, но вы будете поднимать большой барьер против атак с помощью этих шагов. Я также могу добавить, что вы просматриваете решение целостности системы, например Trip Wire, из непосредственной сборки вашего сервера. И, конечно же, убедитесь, что все ваши пароли сильны.

Ответ 8

Если вы отправляете файл по электронной почте, обязательно используйте защищенные соединения (HTTPS/IMAP или POP3 через SSL, SMTP через SSL) на обоих отправляющих и принимающих компьютерах и зашифруйте файл перед отправкой. Вы также можете зашифровать почту и вложение через OpenPGP. Кроме того, обеспечьте безопасность между двумя почтовыми серверами (отправкой и получением) или просто используйте один и тот же домен для отправки и получения адресов электронной почты. Не используйте функцию паролей ZIP файла или соответствующего контейнера-компилятора, поскольку они обычно криптографически слабы. Если вы отправите его на файловую систему (например, USB-накопитель), обязательно используйте зашифрованный (т.е. TrueCrypt).

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