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

Question

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

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

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

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

Спасибо!

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

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

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

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

Answer 7

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

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

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

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

Удачи!

Answer 8

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

Answer 9

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

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

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

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

В конце концов:Если вы действительно подумываете сделать это на сервере, который может быть небезопасен на 110%, УХОДИ.