Соответствие PCI DSS для безопасной передачи файлов

PCI DSS 4.0 (обязателен с 31 марта 2025 года) устанавливает 12 требований для любой системы, которая хранит, обрабатывает или передаёт данные держателей карт. Для систем передачи файлов ключевые контроли: Требование 3 (защита хранимых данных счёта через AES-256 или более стойкое шифрование с надлежащим управлением ключами), Требование 4 (шифрование передачи с минимумом TLS 1.2, рекомендуется TLS 1.3), Требование 8 (MFA для всего доступа в среду данных держателей карт — CDE), Требование 10 (журналирование каждого доступа к CDE не менее 12 месяцев) и Требование 12 (управление и надзор за поставщиками услуг). Система передачи файлов, через которую прошёл хотя бы один CSV-файл с PAN, полностью входит в область действия стандарта.

Что вводит систему в область действия PCI DSS

PCI DSS применяется к любому компоненту системы, который обрабатывает, хранит или передаёт данные держателей карт (CHD) или чувствительные аутентификационные данные (SAD). CHD — это основной номер счёта (PAN), имя держателя, срок действия и сервисный код. SAD — CVV, полные данные трека и PIN-коды — никогда не хранятся после авторизации. Инструмент передачи файлов, получающий электронную таблицу с PAN от банка-партнёра, входит в область действия. Инструмент для отправки сводного отчёта с только последними четырьмя цифрами — нет. Токенизированные или усечённые PAN (первые шесть + последние четыре как максимум) выводятся из области действия. Сокращение области — самый высокорентабельный вид деятельности в рамках PCI.

Изменения PCI DSS 4.0, которые нужно знать

Версия 4.0 (опубликована март 2022, обязательна апрель 2024 с отсроченными требованиями до марта 2025) ввела: кастомизированный подход (альтернатива определённому подходу, требует целевого анализа рисков), пересмотренные требования MFA для всего доступа в CDE (не только администраторов), более строгие правила паролей (12+ символов с января 2025 по требованию 8.3.6), увеличенную частоту многих задач (ежеквартальное сканирование, ежегодные пенетрационные тесты) и явные требования к клиентским страницам оплаты (6.4.3, 11.6.1 для обнаружения скимминга). Системы передачи файлов наиболее ощущают 8.3.6 и 10 — более жёсткую аутентификацию и журналирование.

Требование 3: защита хранимых PAN

Требование 3 запрещает хранить SAD после авторизации и предписывает надёжную защиту хранимых PAN. Допустимые методы: однонаправленные хеши с надёжной солью (SHA-256 с солью на PAN длиной 128+ бит), усечение (не более первых шести и последних четырёх цифр), индексные токены с защищёнными хранящимися ключами или надёжное шифрование с соответствующим управлением ключами. Для систем передачи файлов чище всего — токенизация до того, как файл входит в пайплайн передачи, через PCI-сертифицированный сервис токенизации (Braintree, Stripe Radar, VGS). Если необходимо передавать «сырые» PAN, используйте AES-256-GCM с ключами в HSM уровня FIPS 140-2 Level 2+.

Требование 4: шифрование передачи

4.2.1 требует надёжной криптографии для передачи PAN по открытым публичным сетям. «Надёжная криптография» по глоссарию PCI ссылается на NIST SP 800-57 — AES-256 для симметричного, RSA 3072+ для асимметричного, TLS 1.2+ для транспорта. Полностью отключите TLS 1.0 и 1.1 (они устарели в 2018 году и запрещены в 4.0). Используйте SSL Labs или Qualys SSL Test для ежеквартальной проверки конфигурации. Email явно проблематичен — 4.2.2 требует, чтобы PAN, отправляемые через пользовательские мессенджеры, были нечитаемы до передачи. Незашифрованный PAN в email не соответствует PCI. Отправляйте защищённую ссылку на зашифрованное скачивание.

Требование 8: MFA для всей CDE

8.4 и 8.5 в PCI DSS 4.0 требуют MFA для (a) всего неконсольного доступа в CDE административным персоналом и (b) всего удалённого доступа в CDE любым персоналом. «Всего» — ключевое слово по сравнению с предыдущими версиями: подрядчики, аудиторы, пользователи поддержки, а не только администраторы. Допустимые факторы MFA: что-то, что знаете (пароль), что-то, что имеете (аппаратный токен, приложение), что-то, чем являетесь (биометрия). Два фактора должны быть независимы; два пароля не считаются. Аппаратные ключи (YubiKey, Feitian) по FIDO2 чисто удовлетворяют 8.5. SMS OTP не рекомендуется — NIST SP 800-63B снизил его уровень обеспечения безопасности в 2016 году.

Требование 10: журналирование и 12-месячное хранение

10.2 требует аудит-журналов, фиксирующих: доступ отдельных пользователей к CHD, действия пользователей с правами администратора, доступ к аудиторским записям, неверные попытки логического доступа, механизмы идентификации и аутентификации, инициализацию журналов аудита, создание и удаление системных объектов. 10.5.1 требует хранения не менее 12 месяцев с немедленной доступностью трёх месяцев. 10.7 добавил требования по обнаружению и реагированию на критические сбои контролей безопасности в течение 24 часов. Используйте неизменяемое хранилище журналов — AWS CloudWatch Logs с CloudTrail, Azure Monitor с неизменяемыми политиками или Splunk с конфигурацией «только запись».

Требование 12: управление поставщиками услуг

12.8 охватывает управление поставщиками. Ведите список поставщиков с описаниями услуг и областью PCI DSS, имейте письменное соглашение с каждым, подтверждающее их ответственность за безопасность CHD, документируйте, какие требования PCI управляются каждым из них, и ежегодно отслеживайте статус соответствия поставщиков. Для провайдеров передачи файлов запросите их Аттестацию о соответствии (AOC). Уровни: провайдеры уровня 1 (хранящие/обрабатывающие/передающие 300k+ транзакций/год) проходят ежегодную оценку на месте; меньшие провайдеры могут проводить самооценку.

Сокращение области через клиентское шифрование

Если провайдер передачи файлов никогда не видит PAN в открытом виде, потому что шифрование происходит на клиенте до загрузки, провайдер может быть выведен из области PCI. Руководство PCI по этому вопросу нюансировано — руководство PCI SSC по облачным вычислениям 2019 года признаёт сокращение области через шифрование при условии: (a) облачный провайдер не имеет доступа к ключам, (b) клиент демонстрируемо сохраняет контроль над ключами, (c) криптография надёжна. Сервисы с архитектурой клиентского AES-256-GCM — HexaTransfer и аналогичные — могут служить каналами передачи вне области CDE продавца при осторожном развёртывании. Задокументируйте архитектуру в системном реестре.

Пенетрационное тестирование и управление уязвимостями

11.4 требует пенетрационного тестирования ежегодно и после значительных изменений. Для систем передачи файлов область тестирования включает: точки загрузки и скачивания, поток аутентификации, сегмент сети CDE и любой API для файловых операций. Привлекайте тестировщика, сертифицированного CREST или одобренного PCI. 11.3 требует ежеквартального сканирования уязвимостей одобренным поставщиком сканирования (ASV) для внешне доступных компонентов. Устраняйте критические и высокоприоритетные находки в течение 30 дней; менее серьёзные — по результатам анализа рисков.

Сегментация сети и граница CDE

Сетевая сегментация изолирует CDE от некарточных сетей, сокращая область действия. Сегментация должна проверяться ежегодно (11.4.5) тестами, показывающими, что изоляция работает при аварийных условиях. Для системы передачи файлов, обрабатывающей PAN, сегментируйте пайплайн загрузки, зашифрованное объектное хранилище, KMS-эндпоинты и пайплайн журналирования в выделенную VPC без восток-запад-связности с общекорпоративными сетями. Используйте приватные подсети, группы безопасности по принципу запрета по умолчанию и VPC-эндпоинты к облачным сервисам.

Соответствие PCI на уровне передачи — это в основном сокращение области плюс хорошая крипто-гигиена. Токенизируйте PAN как можно раньше. Попробуйте на https://hexatransfer.com — бесплатно, без регистрации, до 10 ГБ.