Хранение ключей API Braintree в базе данных приложений SAAS

Мы создаем многопользовательское веб-приложение SAAS. Нашим арендаторам нужна возможность принимать платежи по кредитным картам за различные продукты, которые мы разрешаем им продавать через наше приложение. Для этого нам потребуется, чтобы у арендатора была собственная учетная запись Braintree. Арендатор предоставляет нам свои ключи API Braintree через наше приложение. Затем мы используем эти ключи API для взаимодействия с их учетной записью Braintree от их имени (хранение карты, проверка карты и основные транзакции).

Эта модель аналогична модели, используемой существующими клиентами Braintree WooThemes, Goodsie, TutorTrove и многие другие.

Нам нужно записать информацию об API арендатора (идентификатор продавца, открытый ключ API и закрытый ключ API), чтобы все это работало.

Мои вопросы:

  1. Можем ли мы просто сохранить эту информацию в базе данных нашего приложения?
  2. Влияет ли хранение этой информации на область применения PCI/DSS для нас или наших арендаторов?
  3. Если мы не можем хранить информацию в необработанном виде, что является подходящей формой хранения?

Примечание: мы связались с Braintree напрямую с тем же вопросом, но мы не подумали, что будет лишним узнать и другие мнения :).

Привет, Сэм


e-commerce payment-gateway multi-tenant saas braintree
person sammy34    schedule 17.05.2013    source источник

Ответы (2)


arrow_upward
1
arrow_downward

ИМХО, обратите внимание, что у вас будут [если нет, должны быть] ключи шифрования на основе арендатора [каждый арендатор может настроить свой собственный криптографический алгоритм и ключи => Настройка SAAS]. Пожалуйста, зашифруйте AuthorizationId с помощью ключей, специфичных для арендатора, а затем сохраняться в базе данных. Такие конфиденциальные данные должны быть защищены, и у вас должна быть примечание о том, что вы храните эти ключи в базе данных, чтобы арендатор мог отказаться, если это не требуется, и вручную ввести ключ, когда это необходимо. Это обеспечит безопасность. Кстати, ваше приложение использует SSL.

Пожалуйста, поделитесь своими мыслями по этому предложению

person Saravanan    schedule 17.05.2013
comment
Спасибо за Ваш ответ. Используется SSL. Предлагается отказаться (объяснено в наших документах). Меня немного смущает ваше предложение ключей шифрования на основе арендаторов. WooThemes, Goodsie и TutorTrove (ссылка выше), похоже, не используют такой подход. Это кажется несколько избыточным. Нам также пришлось бы хранить информацию о криптографической конфигурации, потому что нам нужно иметь возможность расшифровывать по запросу для обработки платежей. Теперь мы думаем по этому пути: stackoverflow.com/questions/165808/ ... таким образом, наша БД была бы бесполезна без нашего ключа шифрования (хранящегося в нашей сборке). - person sammy34; 18.05.2013
comment
В любом случае, мы посмотрим, что предлагает Braintree, прежде чем что-то внедрять... они, вероятно, в состоянии дать рекомендацию. - person sammy34; 18.05.2013
comment
@sammy34: Привет, Сэм. Спасибо, что поделились своими мыслями. Я столкнулся с реализацией, которая использовала возможность обработки ключей шифрования арендатора даже для шифрования и проверки пароля, поэтому я предложил этот подход. В этом случае арендатор, использующий приложение, установит свой собственный ключ шифрования. Если у арендатора его нет, то у него есть отказоустойчивый ключ по умолчанию, который будет использоваться. Я не слышал о штрафе за производительность в этом случае. Довожу до вашего сведения. - person Saravanan; 18.05.2013

arrow_upward
1
arrow_downward

Итак, Брейнтри ответил на этот вопрос:

Пока ваша система совместима с PCI и ваши продавцы знают, что их ключи API хранятся на вашем сервере, все будет в порядке. Как вы храните ключи API интеграции, полностью зависит от вас, и [мы] не можем предложить никаких передовых практик.

Таким образом, похоже, что этот случай не влияет на возможности PCI/DSS нашего продукта, и кажется, что мы вольны выбирать подходящий способ хранения получаемых закрытых API-ключей (предложение Сараванана — один из возможных вариантов).

person sammy34    schedule 25.05.2013