Резюме ответов:
Не делай этого. Юридические и финансовые последствия будут катастрофическими. Ищите установленные сторонние решения или нанимайте эксперта. Никогда не храните конфиденциальную информацию на общем сервере. Исследование для наиболее подходящего механизма шифрования.
Я создаю веб-сайт для клиента, которому необходимо хранить банковскую информацию своего клиента (маршрут + номер счета) в 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-серверу и посмотреть все доступные базы данных – насколько легко было бы перейти прямо с минимальным взломом?
Также, пожалуйста, сообщите мне название сайта, чтобы я никогда не регистрировался и не размещал на нем свою банковскую информацию !!! 🙂
Кроме того, убедитесь, что у вас есть ошибки и упущение страхования, прежде чем идти вперед с общим хостингом.
Я столкнулся с подобной ситуацией, как вы, и решил ее таким образом.
Таким образом, вы не сохраняете номера учетных записей и маршрутов в своей базе данных, и даже если кто-то взломает БД, они просто видят токен, который довольно бесполезен – они ничего не могут с этим поделать, так как это специфический процессор ACH.
Я сделал аналогичные для кредитных карт, используя Stripe.
Удачи!
У вас нет опыта в этой области, и вы даже не можете найти банки червей, большие в складском клубе. Это случай, когда ваш клиент должен нанять эксперта домена; если вы заинтересованы в выполнении этой работы в будущем, постарайтесь очень тесно сотрудничать с экспертом и поглощать столько знаний, сколько сможете.
Я думаю, что все здесь заявили о своем отвращении к ситуации достаточно, поэтому я просто брошу намек на другую проблему, когда делаю какой-либо криптовый (что мы согласитесь необходимо):
Данные должны быть зашифрованы где-нибудь!
Если вы сделаете это на сервере, хорошо взломанный сервер просто сделает ваше шифрование и передаст их без шифрования.
Если вы делаете это на клиенте, это немного более безопасно, но все же оставляет дверь открытой, если у кого-то есть доступ к вашему серверу: они могут теоретически просто открыть отверстие XSS (т.е. вставить удаленный скрипт на свою страницу. .), который отправляет копию в свою ячейку перед шифрованием …
В конце концов: если вы действительно считаете, что делаете это на сервере, который не может быть защищен на 110%, WALK AWAY .