Достаточно одного необновленного скрипта на вашей странице оформления заказа. В 2024 году скрытый JavaScript незаметно выкачивал номера карт с тысяч страниц оформления заказа небольших интернет-магазинов, прежде чем кто-либо это заметил — это класс атак, который исследователи безопасности называют «e-skimming». Пострадавшие компании не использовали экзотические технологические стеки. Большинство из них были мелкими торговцами, использующими обычный плагин корзины покупок, не подозревая, что стандарт безопасности PCI DSS только что сделал обязательной защиту именно от такого рода атак.
Если вы принимаете кредитные или дебетовые карты — онлайн, лично или и тем, и другим способом — вы уже обязаны соблюдать Стандарт безопасности данных индустрии платежных карт (PCI DSS), независимо от того, читали вы его хоть раз или нет. А с 2026 года правила стали заметно строже. Вот что на самом деле изменилось, за что вы несете ответственность и как добиться соответствия без привлечения консультанта по безопасности.
Что такое PCI DSS (и почему это не факультативно)
PCI DSS — это не закон, принятый Конгрессом, а договорное требование. Visa, Mastercard, American Express, Discover и JCB совместно поддерживают этот стандарт через Совет по стандартам безопасности PCI, и каждый банк и платежный процессор, позволяющий принимать их карты, требует от вас соблюдения как условия вашего торгового соглашения. Проигнорируйте это, и вы рискуете не государственным штрафом, а своей способностью вообще обрабатывать карты, а также штрафами от вашего банка-эквайера, которые обычно составляют от $5 000 до $100 000 в месяц, пока вы не устраните проблему.
Это различие имеет значение, поскольку оно объясняет, почему так мало малых предприятий серьезно относятся к PCI, пока что-то не пойдет не так. Нет полиции PCI, стучащейся в вашу дверь. Есть только пункт контракта — и нарушение, которое покажет, что вы не выполняли свои обязательства.
Стандарт основан на 12 основных требованиях, охватывающих все: от брандмауэров и шифрования до контроля доступа и ежегодных проверок политики безопасности. Большинство малых предприятий выполняют эти требования с помощью Опросника самооценки (SAQ), а не полной выездной проверки — карточные сети классифицируют подавляющее большинство малых предприятий как «Уровень 4», что означает менее примерно 6 миллионов транзакций в год, что позволяет использовать более легкий путь SAQ вместо официального Отчета о соответствии.
Переход на версию 4.0 завершен — теперь все обязательно
Версия PCI DSS 4.0 была опубликована еще в 2022 году, но Совет предоставил отрасли многолетний период для внедрения самых строгих новых мер контроля. Этот период завершился 31 марта 2025 года. Каждая оценка, проводимая с 2026 года, оценивается в соответствии с текущей редакцией (v4.0.1, уточняющее обновление без новых требований), и каждое из примерно 50+ дополнений, введенных в v4.0, теперь полностью входит в сферу применения — больше никаких исключений «лучшая практика, пока не требуется».
Для малого предприятия три из этих недавно обязательных требований имеют гораздо большее значение, чем остальные.
1. Управление скриптами на платежной странице (Требования 6.4.3 и 11.6.1)
Это прямой ответ на атаки e-skimming, такие как Magecart, когда злоумышленники внедряют вредоносный JavaScript на страницу оформления заказа для перехвата номеров карт, пока клиенты их вводят — незаметно, без какого-либо взаимодействия с вашими серверами или базой данных.
Если вы используете любой вид электронной коммерции, теперь вы должны:
- Инвентаризировать каждый скрипт, который загружается и выполняется на вашей платежной странице, с документально подтвержденным деловым обоснованием для каждого из них.
- Авторизовать каждый скрипт явно — не доверяя молча тому, что подтягивает плагин или рекламный тег.
- Проверять целостность, как правило, с помощью хешей Subresource Integrity (SRI), чтобы скомпрометированный сторонний скрипт не мог быть заменен незаметно.
- Обнаруживать несанкционированные изменения в реальном времени — механизм мониторинга, который предупреждает вас при неожиданном изменении HTTP-заголовков или содержимого скриптов вашей платежной страницы.
Если ваша страница оформления заказа работает на хостинговой платформе (Shopify, Square Online, Stripe Checkout, BigCommerce), ваш провайдер берет на себя большую часть этих задач на уровне платформы — подтвердите это в письменной форме. Если вы настроили свою страницу оформления заказа с помощью сторонних аналитических систем, виджетов чата или маркетинговых пикселей, вы несете ответственность за инвентаризацию и авторизацию этих скриптов.
2. Многофакторная аутентификация для всех и везде (Требование 8.4.2)
Согласно старому стандарту, MFA требовалась только для администраторов, получающих доступ к среде данных держателей карт. В версии 4.0 MFA требуется для любого неконсольного доступа к среде данных держателей карт, для каждой роли, из любого местоположения — включая вашу офисную сеть. Если сотрудник входит в вашу административную панель POS, панель управления платежного шлюза или любую систему, которая касается данных карт, ему требуется второй фактор, а не только пароль.
Это требование, которое большинство малых предприятий обнаруживают, что не выполнили, только когда оценщик их платежного процессора запрашивает доказательства. Решение обычно недорогое: большинство POS-систем и платежных платформ (Square, Stripe, Clover, Toast) предлагают встроенную MFA — задача состоит в том, чтобы включить ее для каждой учетной записи и избавиться от привычек совместного использования логинов, которые сформировались у вашего персонала.
3. Аутентифицированное внутреннее сканирование уязвимостей (Требование 11.3.1.2)
Ранее внутреннее сканирование уязвимостей могло проводиться без аутентификации, что упускало из виду многие реальные риски — сканер, который не может войти в систему, не видит, к чему мог бы получить доступ вошедший злоумышленник (или недобросовестный инсайдер). Новое требование предписывает аутентифицированное сканирование внутренних систем, выявляя неправильные конфигурации и необновленное программное обеспечение, которые рутинно пропускаются сканированиями без аутентификации.
Какова реальная стоимость несоблюдения требований
Цифры говорят сами за себя лучше, чем любой контрольный список соответствия. Последний отчет Verizon по расследованию утечек данных зафиксировал более 7000 утечек в малых и средних организациях за один год, и в худших 2,5% случаев утечка обошлась бизнесу более чем в 7% годового дохода. Отдельно исследование IBM по стоимости утечек показывает, что несоблюдение применимых нормативных требований добавляет в среднем $173 692 к стоимости утечки — помимо того, что сама утечка уже стоила в виде устранения последствий, уведомлений и потерянного бизнеса.
И это еще до того, как начнут начисляться ежемесячные штрафы от вашего банка-эквайера. Соблюдение требований недешево с точки зрения рабочего времени персонала, но несоблюдение требований стабильно дороже — по одной отраслевой оценке, этот множитель достигает почти 3x, если учесть штрафы, устранение последствий утечек и прерывание бизнеса вместе.
Практический контрольный список соответствия требованиям для малых предприятий
Вам не нужна корпоративная команда безопасности, чтобы правильно это сделать. Выполняйте в следующем порядке:
- Определите тип вашего SAQ. Ваш платежный провайдер может подсказать, какая анкета самооценки (Self-Assessment Questionnaire) применяется к вам в зависимости от того, как вы принимаете карты (полностью аутсорсинговая электронная коммерция, терминал при личной оплате, индивидуальная касса и т. д.). Это определяет, какие именно из 12 требований применимы к вам.
- Спросите свою платформу, что она покрывает. Если вы используете Shopify, Square, Stripe или аналогичный хостинговый провайдер, получите письменное подтверждение того, что покрывается с их стороны (обычно большая часть требований к технической инфраструктуре) и что остается вашей ответственностью (обычно контроль доступа, политика для сотрудников и любые добавленные вами настройки).
- Включите MFA везде, где обрабатываются карточные данные. Входы администраторов POS-систем, панели управления платежных шлюзов, инструменты удаленного доступа — без исключений, без общих учетных записей.
- Составьте инвентаризацию сторонних скриптов вашей страницы оформления заказа. Перечислите каждый скрипт, который загружается на странице, где клиенты вводят данные карты. Если вы не можете обосновать его наличие, удалите его.
- Перестаньте хранить то, что вам не нужно. Самый дешевый способ уменьшить нагрузку по соблюдению требований и риск утечки — это изначально не хранить номера карт, CVV или полные данные магнитной полосы; вместо этого позвольте вашему провайдеру проводить токенизацию.
- Оформите свою политику безопасности письменно и пересматривайте ее ежегодно. Требование 12 предписывает наличие документированной, распространенной политики информационной безопасности — это не формальность, а действительно полезный инструмент для последовательного обучения новых сотрудников.
- Заполняйте SAQ ежегодно и храните подписанное подтверждение в архиве — ваш провайдер запросит его, и вы не захотите восстанавливать свою историю соответствия во время расследования утечки.
Выбор (или переоценка) платежного провайдера
Не все "PCI-совместимые" провайдеры снимают с вас одинаковый объем работы. Выбирая или продлевая платежную платформу, спросите напрямую:
- Действительно ли их размещенная касса полностью исключает хранение карточных данных на ваших серверах (снижая вашу ответственность до простейшего SAQ, обычно SAQ A)?
- Предоставляют ли они MFA на каждом уровне учетных записей или только на платных тарифных планах?
- Предоставят ли они письменное Подтверждение соответствия (AOC), которое вы можете передать своему провайдеру или страховщику по запросу?
- Публикуют ли они, какие из 12 требований они покрывают, а какие остаются вашей ответственностью?
Провайдер, который не может четко ответить на эти вопросы в письменной форме, перекладывает на вас больше бремени по соблюдению требований, чем предполагает указанная цена — это стоит учитывать при принятии решения наряду с комиссиями за транзакции.
Как это связано с вашей бухгалтерией
Затраты на соблюдение требований — инструменты сканирования, лицензии MFA, часы работы консультантов — это реальные бизнес-расходы, и они подлежат вычету. Но более полезная связь работает в другом направлении: та же дисциплина, которая делает соблюдение PCI управляемым (точное знание того, что и почему затрагивает конфиденциальные данные), — это та же дисциплина, которая делает ваши финансовые записи надежными. Бизнес, который может по запросу предоставить чистый список скриптов, обычно также является бизнесом, который может по запросу предоставить чистую, проверяемую бухгалтерскую книгу. Ни то, ни другое не происходит случайно — оба результата достигаются благодаря отношению к принципу "мы можем показать свою работу" как к постоянному требованию, а не к ежегодной суматохе.
Сделайте свои финансы такими же проверяемыми, как и вашу платежную страницу
Так же, как PCI DSS 4.0 требует от вас доказать, что именно и почему затрагивает данные карт ваших клиентов, так и хороший учет задает тот же вопрос о каждом долларе, который проходит через ваш бизнес. Beancount.io предлагает учет в виде обычного текста, который полностью прозрачен и контролируется версиями — каждая транзакция проверяема, аудируема и никогда не заперта в "черном ящике". Начните бесплатно и узнайте, почему разработчики и финансово-ориентированные владельцы бизнеса переходят на учет в виде обычного текста.