Я согласен, что сертификация для галочки может устроить театр безопасности вместо действительного следования требования PCI DSS. В этом случае возникают вопросы ко всем сторонам, но это тема для отдельной дискуссии.
Моя мысль в том, что из перечисленных способов единственным реальным на текущий момент является использование подхода клиентской токенизации от стороннего провайдера. А в этом случае возникают вопросы, а что там у этого провайдера с сертификацией и не утащат ли все данные с его стороны. Да, технически это решает поднятый вопрос архитектуры приема платежей в приложениях Яндекса, но на вопрос сохранности платежных данных (поскольку мне кажется, что это основной посыл раздела про платежи) это не отвечает, просто переносит его на другую сторону.
Перед таким бэком так же будут стоять балансеры и прочие элементы инфраструктуры, а доступ зависит от того, как это реализовано в рамках компании. Опять же, если этот сервис будет предоставлен Яндексом, ничего не изменится, а значит узким звеном все равно остается прозрачность и уровень доверия к вендору этого сервиса. А можно ли в текущих условиях кому-то доверять - вопрос открытый.
через клиентскую токенизацию форма изолирована, бэкенд карты в глаза не видит
Если сервис клиентской токенизации предоставлен самим Яндексом, то данные карты, введенные в форму для клиентской токенизации, улетят на те же сервера Яндекса. Да, бэк мобильного приложения получит токен, но бэк клиентской токенизации так же получит данные в чистом виде, и в этом случае все описанные риски ровно так же применимы и к этой ситуации.
Предположим, что Яндекс имеет свой сервис клиентской токенизации (не знаю на 100% так это или нет). Если Яндекс в своем приложении будет использовать его, это устранит исходную претензию? Если нет, то почему? Если да, то какая принципиальная разница, через какую дырку данные карты полетят на сервера Яндекса - через сервис клиентской токенизации или через форму данных карты?
Как "человек из PCI DSS" вы же наверное должны понимать, что если Яндекс прошел валидную сертификацию, то вопросы к тому, что в логах будут лежать PAN и CVV в открытом виде не должны стоять?
Apple Pay и Google Pay я привел просто как примеры, есть много аналогов
Для iPhone, кроме разрешенных рынков, типа ЕС, вроде как еще ничего не придумали. Для Android да, HCE существует уже давно.
дело не в доверии к бренду ( там ну я ндексу или условному платежному шлюзу ) а в изоляции контура
Не понимаю. В условном Stripe все равно данные уйдут на сервер Stripe, или типа если данные ушли не на мой сервер, то это и не моя проблема? Ну, в целом подход имеет право на существование, но мы же тут вроде про сохранность платежных данных говорим? BTW, есть в РФ сейчас провайдеры, которые это делают, и за которых вы готовы дать руку на отсечение, что у них внутри все сделано как надо и комар носу не подточит?
ну... в нормальной архитектуре сырые данные твоей карты вообще не касаются бэкенда приложения, ты вводишь карту в изолированном окне провайдера
По мне выглядит так, что Яндекс, обладая лицензией ЦБ РФ, в целом и выступает провайдером платежей. Было бы странно банку встраивать к себе в контур какой-то поддержку стороннего провайдера? Ну то есть как если бы (условно) при оплате в Сбере данные вводились в Stripe.
Не для защиты Яндекса, а кругозора для: автор, не могли бы вы поподробнее раскрыть суть претензий к реализации платежей?
Из перечисленных подходов представленных, как более прогрессивные, один недоступен в РФ на текущий момент (ApplePay, GooglePay), а второй (аналог Stripe, Braintree) все равно будет отправлять платежные данные в чистом виде, только на сервер провайдера. Т.е. вопрос в том, что вы доверяете условному аналогу Stripe больше, чем Яндексу? А если этот аналог тоже имеет РФ происхождение? Это я все к тому, что PAN и прочие чувствительные данные в любом случае не должны оказаться в логах в открытом виде (в Яндексе или нет), поэтому что касается этой секции в целом (про платежи) - это скорее вопрос уровня паранойи (что в целом имеет место быть в текущих реалиях, что уж тут).
Да, я думаю проще, если уметь. Паял я последний раз лет 10 назад, да и паяльника у меня нет сейчас. А вот этот микрик пока чинил, разобрал-собрал его раз 5, так что думаю с этим проблем не будет.
Проделывал ту же самую процедуру со своей VX Revolution, очень она мне нравится. Но правда ее хватило ненадолго, стала заново двукликать, теперь думаю заказать пару микриков с ебея, чтобы поменять сам механизм на новый, не перепаивая.
Середина 90х, наверное где-то 96-97 год, это был Pentium 133 (потом даже замененный на 166), ATI Rage IIC c 8Mb на борту, около 500 метров жесткий и вроде бы 32 Mb оперативка. Потом туда же еще приехал видео-ускоритель от 3dfx, а затем жесткий на (о боже!) 1Гб (!). Ну и естественно флоппик и 8х-привод. А, а еще там был модем 14400 кбит/с и даже был интернет по выходным!
У меня тоже была Logitech VX Revo. Работала прекрасно, пока не начала страдать стандартной болезнью — двойным кликом вместо одинарного. Написал, попросили чек сфотографировать, а потом сказали, что гарантия уже тю-тю:( Мышку отложил, забыл. Недавно достал, почитал в инете о проблеме с кликом, разобрал и починил сам, теперь снова все хорошо. Тем не менее Logitech все равно продолжаю любить:)
Я согласен, что сертификация для галочки может устроить театр безопасности вместо действительного следования требования PCI DSS. В этом случае возникают вопросы ко всем сторонам, но это тема для отдельной дискуссии.
Моя мысль в том, что из перечисленных способов единственным реальным на текущий момент является использование подхода клиентской токенизации от стороннего провайдера. А в этом случае возникают вопросы, а что там у этого провайдера с сертификацией и не утащат ли все данные с его стороны. Да, технически это решает поднятый вопрос архитектуры приема платежей в приложениях Яндекса, но на вопрос сохранности платежных данных (поскольку мне кажется, что это основной посыл раздела про платежи) это не отвечает, просто переносит его на другую сторону.
Перед таким бэком так же будут стоять балансеры и прочие элементы инфраструктуры, а доступ зависит от того, как это реализовано в рамках компании. Опять же, если этот сервис будет предоставлен Яндексом, ничего не изменится, а значит узким звеном все равно остается прозрачность и уровень доверия к вендору этого сервиса. А можно ли в текущих условиях кому-то доверять - вопрос открытый.
Если сервис клиентской токенизации предоставлен самим Яндексом, то данные карты, введенные в форму для клиентской токенизации, улетят на те же сервера Яндекса. Да, бэк мобильного приложения получит токен, но бэк клиентской токенизации так же получит данные в чистом виде, и в этом случае все описанные риски ровно так же применимы и к этой ситуации.
Предположим, что Яндекс имеет свой сервис клиентской токенизации (не знаю на 100% так это или нет). Если Яндекс в своем приложении будет использовать его, это устранит исходную претензию? Если нет, то почему? Если да, то какая принципиальная разница, через какую дырку данные карты полетят на сервера Яндекса - через сервис клиентской токенизации или через форму данных карты?
Как "человек из PCI DSS" вы же наверное должны понимать, что если Яндекс прошел валидную сертификацию, то вопросы к тому, что в логах будут лежать PAN и CVV в открытом виде не должны стоять?
Для iPhone, кроме разрешенных рынков, типа ЕС, вроде как еще ничего не придумали. Для Android да, HCE существует уже давно.
Не понимаю. В условном Stripe все равно данные уйдут на сервер Stripe, или типа если данные ушли не на мой сервер, то это и не моя проблема? Ну, в целом подход имеет право на существование, но мы же тут вроде про сохранность платежных данных говорим? BTW, есть в РФ сейчас провайдеры, которые это делают, и за которых вы готовы дать руку на отсечение, что у них внутри все сделано как надо и комар носу не подточит?
По мне выглядит так, что Яндекс, обладая лицензией ЦБ РФ, в целом и выступает провайдером платежей. Было бы странно банку встраивать к себе в контур какой-то поддержку стороннего провайдера? Ну то есть как если бы (условно) при оплате в Сбере данные вводились в Stripe.
Не для защиты Яндекса, а кругозора для: автор, не могли бы вы поподробнее раскрыть суть претензий к реализации платежей?
Из перечисленных подходов представленных, как более прогрессивные, один недоступен в РФ на текущий момент (ApplePay, GooglePay), а второй (аналог Stripe, Braintree) все равно будет отправлять платежные данные в чистом виде, только на сервер провайдера. Т.е. вопрос в том, что вы доверяете условному аналогу Stripe больше, чем Яндексу? А если этот аналог тоже имеет РФ происхождение? Это я все к тому, что PAN и прочие чувствительные данные в любом случае не должны оказаться в логах в открытом виде (в Яндексе или нет), поэтому что касается этой секции в целом (про платежи) - это скорее вопрос уровня паранойи (что в целом имеет место быть в текущих реалиях, что уж тут).
А этой поделки Apple активно не нравится мягкая задняя часть, какая-то она не знаю, вообще не к месту.