Подтвердить что ты не робот

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

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

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

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

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

Спасибо!

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

РЕДАКТИРОВАТЬ 2: Уйдет от этого. Вначале эта идея была недовольна! Изучит PayPal Mass Payment API.

4b9b3361

Ответ 1

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

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

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

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

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

Ответ 7

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

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

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

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

Удачи!

Ответ 8

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

Ответ 9

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

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

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

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

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