Рекомендации по хранению банковской информации в базе данных

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

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

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

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

Благодаря!

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

EDIT 2: Уйдет от этого. Вначале эта идея была недовольна! Будет исследовать API массовых платежей PayPal.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я сделал аналогичные для кредитных карт, используя Stripe.

Удачи!

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

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

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

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

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

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