С чего начать с PCI-DSS в мобильном приложении?

Question

Мы разрабатываем мобильное приложение (iOS и Android) для клиента, у которого есть свое решение для обработки платежей. Приложение является публичным, и оно будет использоваться отдельными пользователями на своих телефонах.

Приложение должно взаимодействовать с решением обработки платежей по SOAP API. Нам необходимо принять ввод данных платежной карты пользователя и передать их через этот API. У нас нет возможности встраивать свой веб-сайт в iframe или что-то в этом роде; мы должны использовать этот конкретный API, а это означает, что нашему приложению неизбежно придется (ненадолго) владеть и обрабатывать детали платежной карты пользователя.

Все, что нужно сделать, это собрать данные (нажав их на клавиатуре телефона), отправить их через API, а затем отбросить их как можно быстрее. Он не будет хранить данные за пределами времени, затраченного на завершение транзакции, и он не будет отправлять данные в любом месте, кроме API, на сервер клиента. У нас никогда не будет данных на наших собственных серверах, мы будем осторожны, чтобы никогда не записывать их в журналы, и обычно мы будем относиться к нему как к радиоактивным отходам за короткий период времени, который он находится в распоряжении приложения.

Мы можем с уверенностью предположить (по крайней мере на данный момент), что системы клиента уже делают то, что им нужно делать в отношении PCI DSS. И, конечно, трафик между приложением и платежным сервером зашифрован.

Мы изо всех сил пытаемся понять, что нам нужно сделать в отношении PCI DSS, и мы будем благодарны за любые указатели, которые помогут нам начать работу. Мы совершенно счастливы (действительно хотим) использовать консультанта, чтобы помочь нам достичь соответствия, но мы даже не знаем, с кем поговорим. Все, что мы можем легко найти в Интернете (в том числе материал из самой PCI), похоже, относится к тонко различным сценариям или советует нам обойти проблему, используя что-то вроде iframe, что для нас не является вариантом.

Честно говоря, мы удивлены тем, насколько сложно найти четкие указатели. Многие приложения обрабатывают детали карты! Это, безусловно, должна быть общей проблемой.

Итак, наши вопросы:

1. Где мы должны идти, чтобы получить квалифицированную консультацию, имеющие отношение к нашей конкретной ситуации?
2. Полностью неформально, и при том понимании, что мы собираемся получить квалифицированный совет позже ... сколько кошмара мы должны ожидать от этого? Нам нужно подумать, нужно ли нам беспокоиться о ключевых регистраторах, установленных на телефоне. Это действительно так, или мы заходим слишком далеко?
3. Есть ли волшебная пуля, которую нам не хватает - библиотека, которая уже известна как совместимая, например?

Большое спасибо за любую помощь, которую вы можете нам дать.

Answer 1

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

Для вашего первого вопроса вам необходимо найти QSA, ознакомьтесь с PCI council website, чтобы получить список тех и всей официальной информации. Я бы порекомендовал немного шоппинга, качество и цены варьируются, вам нужно, чтобы кто-то знал ваш сценарий. Как вы говорите, вы должны получить официальное руководство перед использованием представлений, которые я предоставляю.

Для вашего второго вопроса, первое, что нужно сказать, это контракт на основе контракта.Это полностью зависит от вашего клиента (в зависимости от соглашения, которое они имеют с их торговым банком или платежным процессором). Поэтому, если в вашем контракте не говорится, что вам нужно предоставить PCI-совместимое решение, вам не нужно ... хотя я был бы осторожен, это может быть вопросом для юристов, если вы подразумеваете это или подходят цели и т. Д. Прагматически есть несколько вариантов, в зависимости от ситуации, это становится немного сложнее здесь, так что я буду стараться изо всех сил:

• Если клиент не имеет никакого контроля над кодом или системой, они просто получают результаты этого , вы, скорее всего, считаетесь поставщиком услуг, и вам потребуется SAQ D для поставщиков услуг как минимум.
• Если вы просто даете клиенту исходный код и реализуете его, то они несут полную ответственность за них, они должны будут выполнять проверку кода, тестирование на проникновение и т. Д., Если это доступно.
• Если ваш клиент хочет подключить ваше приложение к своей системе, и они не хотят нести ответственность за данные PCI, тогда вам нужно будет соответствовать требованиям PA-DSS.

В конечном итоге это будет зависеть от того, в какой области PCI может потребоваться ваш клиент, им, скорее всего, потребуется SAQ A по крайней мере (да, вы оба должны доказать соответствие PCI), независимо от того, какой курс вы возьмете.

Что касается кошмара, я не уверен, что для родных приложений, но для веб-приложений, если PAN (номер cc) касается вашего сервера, это полный объем, SAQ D, в двух словах да, это кошмар, t уже имеют безопасную настройку. Лучшим сценарием будет SAQ A, но для этого вам понадобится iFrame, если это невозможно, то, возможно, SAQ A-EP, вы можете использовать это с прямым POST, так что может быть нормально с интерфейсом SOAP, если это прямо из вашего приложение. Я не уверен, что приложение считается «электронной коммерцией», которое может использовать SAQ A и A-EP, если нет, вам может понадобиться SAQ C. По крайней мере, посмотрите на требование 6, оно охватывает разработку программного обеспечения.

Для вашего последнего вопроса, проверьте spreedly.com, они обеспечивают соединение, совместимое с PCI, с несколькими шлюзами.

Удачи вам! И было бы здорово услышать, что вы в конечном итоге решили сделать.