#деньги Как я уже говорил, PCI-DSS касается не всех. Если вы | Человек и машина

#деньги

Как я уже говорил, PCI-DSS касается не всех. Если вы открыли небольшой магазин плюшевых игрушек, запустили его в сети и принимаете не более 300 тысяч платежей в год, вам и заморачиваться особо не надо. Многие в таком случае отдают процессинг платежей сторонним поставщикам, будь то SberPay, Яндекс.Касса в России, или Adyen, Mollie, Stripe и прочие в ЕС/США.

Мелким товарищам так проще всего и относительно дешево. На больших объемах все куда хуже и очень дорого.

Итак, задача: не допустить утечки платежных данных, чтобы всякие сволочи не получили к ним доступ. Имеем в виду, что каждый год ждем QSA с визитом, за что мы, кстати, сами платим из своего кармана.

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

Вот тут надо сделать остановку. PCI-DSS допускает игнорировать часть требований, если вы используете поставщика, который им удовлетворяет. Иными словами, если взять тот же AWS, то никто не будет требовать вас соответствовать требованиям физической безопасности ЦОД, об этом уже позаботился AWS.

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

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

Помимо этого мы имеем ряд других требований: регулярно проводить проверку на проникновение, обновлять пакеты и ядро ОС, вести учет изменений в системе (GitOps в помощь), кучу бумажной и процедуральной волокиты, запрет на трафик куда угодно и мониторинг безопасности.

Последние два момента я раскрою в следующем посте, но тут я хочу подчеркнуть важную деталь.

Именно токенизация и шифрование выступают гарантами безопасности данных. Токен можно спокойно светить в логах, вне инфраструктуры он не имеет никакой ценности, а внутри инфраструктуры у вас описаны политики, т.е. какой доступ есть у каких сервисов. Например, хорошей практикой является использовать один сервис для сохранения платежных карт, а другой для инициации платежей.

Так что если вы увидите сырые данные карточек в открытом виде, то либо это внутренний слив, либо поставщик платежей абсолютно не следовал требованиям PCI-DSS.