Лучшие практики для хранения банковской информации в базе данных

Question

Резюме ответов:
Не делай этого. Юридические и финансовые последствия будут катастрофическими. Ищите устоявшиеся сторонние решения или наймите эксперта. Никогда не храните конфиденциальную информацию на общем сервере. Поиск наиболее подходящего механизма шифрования.

Я создаю веб-сайт для клиента, которому необходимо хранить банковские данные своих клиентов (маршрут + номер счета) в БД для прямого депозита. Вот некоторые особенности:

1) Первоначально веб-сайт будет находиться на сервере общего хостинга (это моя первая задача).
2) Я использую PHP / MySQL.
3) Я планирую использовать mcrypt.
4) Ключ будет находиться за пределами корня сети.

Пожалуйста, дайте мне знать ваши мысли. Если возможно, пожалуйста, предоставьте мне некоторые ресурсы по обработке ACH.

Спасибо!

РЕДАКТИРОВАТЬ: Я ожидал такого ответа, так как я боюсь вопросов безопасности там. Я выразил беспокойство своему клиенту, и это будет хорошей поддержкой.

РЕДАКТИРОВАТЬ 2: Уйдет от этого. Не был доволен идеей в первую очередь! Будет изучать API массовых платежей PayPal.

Answer 1

Я думаю, что вы можете решить эту проблему, не сохраняя банковскую информацию самостоятельно, используя что-то вроде API массовых платежей Paypal . Таким образом, ваш клиент может платить людям, а PayPal хранит всю информацию, поэтому вам не нужно.

Если вы хотите прочитать обо всех шагах, которые необходимо предпринять, чтобы хотя бы иметь отдаленную возможность защиты конфиденциальных финансовых данных вашего клиента, google ' PCI Compliance '

Если вы не боитесь хранить финансовые данные в Интернете, вы ужасно наивны.

Answer 2

1) Первоначально веб-сайт будет находиться на сервере общего хостинга (это мое первое беспокойство). --ДЕЙСТВИТЕЛЬНО ПЛОХО. Отсутствие абсолютного административного контроля над сервером и возможность не пускать других людей - это действительно большая проблема.

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

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

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

Answer 3

Не делай этого.

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

А если серьезно, найдите способ избежать этого, если возможно.

Answer 4

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

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

Answer 5

Для банковской информации ваш сервер должен быть под их контролем, а не для общего доступа.

Кроме того, mcrypt не очень безопасен. Я знаю, что он встроен, но я бы предложил что-то не так взломанное, как, например, RSA. Если кто-то получит информацию, он не сможет взломать ее без личного ключа.

Answer 6

Я столкнулся с подобной ситуацией, как вы, и решил ее таким образом.

1. Поскольку вы не будете выполнять обработку ACH, выясните, есть ли у API обработки ACH возможность создать клиента.
2. Если да, этот объект клиента, как правило, будет содержать номер счета, номер маршрута и т. Д. И сохранит токен в вашей базе данных. (Таким образом, когда пользователь сообщает свою информацию, вы передаете ее прямо на ваш процессор ACH через HTTPS и сохраняете токен).
3. Всякий раз, когда вам нужно дебетовать их учетную запись, передайте этот токен процессору, и все! !!

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

Я сделал то же самое для кредитных карт, использующих Stripe.

Удачи!

Answer 7

Я согласен с другими - это очень плохая идея.

Выделенные серверы можно использовать по цене от 79 до 99 долларов в месяц, если это не по карману, я действительно удивлюсь, почему они с самого начала обрабатывают банковскую информацию. В этом случае предпочтительным способом будет отделение базы данных от веб-блока. Желательно с некоторыми межсетевыми экранами и другой защитой между ними (то есть 2 межсетевых экрана, один перед веб-сервером и один между веб-сервером и базой данных).

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

Также, пожалуйста, назовите мне название сайта, чтобы я никогда не регистрировался и не размещал на нем свою банковскую информацию !!! :)

Кроме того, убедитесь, что у вас есть ошибки и страховка от пропуска, прежде чем переходить на общий хостинг.

Answer 8

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

Answer 9

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

Данные должны быть где-то зашифрованы!

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

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

В конце: если вы действительно планируете сделать это на сервере, который не может быть защищен на 110%, WALK AWAY .