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

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

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

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

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

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

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

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

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

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

9
android ios mobile pci-compliance pci-dss

1 ответов

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

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

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

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

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

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

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

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

1