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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи!

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

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

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

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

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

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