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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи!

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

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

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

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

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

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