# Дэн Барона объяснил, почему стандарты PCI DSS 4.0 изменили безопасность API

Источник: https://www.youtube.com/watch?v=dlK7jec2rXo
Канал: freeCodeCamp.org
Опубликовано: 02.10.2023

---

В условиях стремительной цифровизации финансовых сервисов безопасность прикладных программных интерфейсов (API) становится критически важным фактором выживания бизнеса. Сооснователь AppSec University Дэн Барона в своем специализированном курсе подробно разбирает масштабное обновление стандарта безопасности индустрии платежных карт PCI DSS 4.0. Эксперт объясняет, почему традиционные методы защиты больше не работают против современных угроз и как бизнесу перестроить свои процессы разработки для успешного прохождения аудита.

## 💥 Почему API стали главной мишенью киберпреступников
[[JUMP:05:31]]

Согласно исследованию компании Akamai, на сегодняшний день более 83% всего интернет-трафика приходится на запросы к программным интерфейсам приложений (API). В текущем году объем вызовов только в сфере открытого банкинга достиг 100 миллиардов, и, по прогнозам аналитиков, этот показатель вырастет в пять раз — до 500 миллиардов в течение следующих пяти лет. API стали технологическим фундаментом, обеспечивающим проведение электронных коммерческих транзакций, работу медицинского оборудования и функционирование систем управления современных подключенных автомобилей.

Однако столь стремительный рост породил серьезные угрозы. Ежегодные глобальные финансовые потери от кибератак, связанных с уязвимостями API, оцениваются экспертами в диапазоне от 40 до 75 миллиардов долларов. Еще за несколько лет до текущего кризиса аналитическая компания Gartner прогнозировала, что к 2022 году API превратятся в самый частый вектор хакерских атак, что полностью подтвердилось на практике. 

При этом, по данным отчета платформы stateofapis.com, лишь 4% от общего объема тестирования API сегодня сфокусировано на вопросах информационной безопасности. Дэн Барона подчеркивает, что индустрия разработки ПО фундаментально изменилась, однако классические подходы к защите критически отстают от этих темпов.

## 🔄 Кризис классических инструментов безопасности и эволюция OWASP
[[JUMP:08:00]]

В отчете Gartner по циклу зрелости технологий защиты приложений (Hype Cycle) отмечается тренд на ускорение темпов гибкой разработки, смещение ответственности за безопасность на разработчиков и переход к облачным стратегиям. Традиционные средства контроля безопасности стали менее эффективными. Эксперты Gartner указывают на то, что классические инструменты автоматизированного тестирования (SAST и DAST) изначально не проектировались для поиска специфических уязвимостей, характерных для API.

В то время как традиционные сканеры ищут ошибки кодирования, инъекции кода или межсайтовый скриптинг (XSS) на уровне пользовательского интерфейса, успешные взломы API происходят иначе. Реальные утечки сотен миллионов записей, зафиксированные на специализированных ресурсах вроде APIsecurity.io, происходят из-за дефектов бизнес-логики, пробелов в авторизации и слабой аутентификации. Хакеры обходят защитные фильтры пользовательского интерфейса (UI) и отправляют кастомные запросы напрямую к бэкенду через API.

Для стандартизации защиты сообщество OWASP (Open Web Application Security Project) в 2019 году создало отдельный рейтинг угроз API Security Top 10, который был существенно обновлен. Барона выделяет ключевые элементы этого списка:

* **Разделение прав на уровне объектов (BOLA/BADA):** уязвимость номер один, позволяющая одному пользователю получать доступ к конфиденциальным данным другого через подмену идентификаторов в запросе.
* **Сломанная аутентификация:** эндпоинты часто остаются полностью открытыми, так как разработчики ошибочно считают, что их никто не обнаружит.
* **Неконтролируемый доступ к бизнес-процессам:** новая шестая позиция в рейтинге, напрямую связанная с эксплуатацией логических дефектов приложений.

По словам спикера, требования нового стандарта PCI DSS 4.0 во многом пересекаются с философией OWASP, заставляя компании детально проверять логику работы своих интерфейсов.

## 📜 От хаотичных стандартов к PCI DSS 4.0: исторический экскурс
[[JUMP:14:26]]

До создания единого консорциума пять крупнейших платежных систем — Visa, Mastercard, American Express, Discover и JCB — навязывали рынку собственные разрозненные правила безопасности. В 2004 году они объединились, учредив Совет по стандартам безопасности индустрии платежных карт (PCI SSC) и представив единый стандарт требований для защиты данных держателей карт, таких как основной номер счета (PAN), имя владельца, срок действия, CVV-коды и PIN-данные.

Необходимость жесткого контроля подтверждалась крупнейшими инцидентами. В 2006 году в результате взлома ритейлера TJ Maxx пострадало 45 миллионов записей клиентов, а в 2009 году атака на процессинговую компанию Heartland Payment Systems привела к компрометации 130 миллионов записей. Это форсировало эволюцию стандартов: версия DSS 2.0 вышла в 2010 году, версия 3.0 — в 2013 году, а актуальная версия 4.0 была опубликована спустя девять лет — в 2022 году.

Новая редакция PCI DSS 4.0 стала значительно объемнее: документ вырос более чем в 2,5 раза и теперь насчитывает 360 страниц. Совет преследовал четыре цели: обеспечение непрерывности процессов безопасности, повышение гибкости методологий, улучшение процедур валидации и адаптация к актуальным технологиям платежного рынка. 

Если в версии 3.0 упоминания API полностью отсутствовали, то в версии 4.0 они интегрированы во множество разделов. Барона формулирует простое правило для ИТ-директоров: если ваши API находятся в зоне видимости злоумышленников, они обязаны находиться и в периметре ваших программ безопасности.

Переходный период начался во втором квартале 2022 года. Официальный дедлайн для обязательного соответствия базовым требованиям PCI DSS 4.0 наступил 31 марта 2024 года, а для ряда технически сложных перспективных норм внедрение продлено до 31 марта 2025 года.

## 🛠️ Требование 6: Безопасная разработка кастомного ПО и API
[[JUMP:21:23]]

Центральное место в докладе Дэна Бароны занимает Раздел 6 стандарта PCI DSS 4.0 («Разработка и поддержка безопасных систем и программного обеспечения»). Базовое правило гласит: под действие комплаенса подпадает любое встроенное и кастомное ПО (bespoke and custom software), разработанное компанией самостоятельно или третьей стороной, если оно участвует в хранении, обработке и передаче платежных данных. Под это определение напрямую подпадают все корпоративные API.

Стандарт декомпозирует процесс разработки на несколько жестких регуляторных пунктов:

* **Пункт 6.2.1 (Безопасный жизненный цикл):** требует интеграции ИБ на самых ранних этапах проектирования (концепция Shift Left) вместо попыток наложить заплатки на готовый продукт. Разработчики обязаны четко понимать, как приложение оперирует конфиденциальной информацией.
* **Пункт 6.2.2 (Обязательное обучение):** персонал, занимающийся созданием кастомного ПО, должен проходить профильное обучение безопасной разработке и методам поиска уязвимостей не реже одного раза в 12 месяцев. Спикер отмечает, что инженерам необходимы специфические знания именно по векторам атак на API.
* **Пункт 6.2.3 (Обзоры кода и архитектуры):** весь кастомный код должен проверяться перед релизом в продакшн на предмет новых и логических уязвимостей. При интеграции сторонних API Барона рекомендует руководствоваться принципом «не доверяй никому» (Trust Nothing), обязательно валидируя входящие ответы.
* **Пункт 6.2.4 (Защита от распространенных атак):** предписывает использовать современные инженерные практики для предотвращения инъекций, обхода авторизации и манипуляций с логикой интерфейсов, причем интерфейсы API упомянуты здесь в качестве обязательных объектов проверки.

В качестве примера опасности логических дефектов Дэн Барона приводит реальный случай взлома криптовалютной торговой платформы. Злоумышленник обнаружил уязвимость в бэкенд-логике API, которая позволяла перезаписывать тип торгуемого актива прямо в теле запроса, в результате чего хакер смог успешно продать свои токены Ethereum под видом дорогостоящего Bitcoin.

## 🔍 Управление уязвимостями и инвентаризация по новым правилам
[[JUMP:29:21]]

Согласно пункту 6.3.1, компании обязаны развернуть полноценную программу управления уязвимостями (Vulnerability Management). Для внешних библиотек и опенсорсных компонентов общепринятым источником информации служит база данных CVE (Common Vulnerabilities and Exposures), модерируемая корпорацией MITRE. Однако Барона обращает внимание на критически важную деталь: уязвимости в собственной бизнес-логике компании невозможно найти в публичных базах данных. 

По мнению эксперта, дефекты собственного кода — это персональные уязвимости нулевого дня (Zero Days) для каждой организации, и именно их сильнее всего ищут злоумышленники. Стандарт PCI DSS 4.0 рекомендует собирать информацию о таких дырах через запуск программ Bug Bounty и привлечение независимых исследователей. Единственным выходом для бизнеса становится автоматизация тестирования каждого эндпоинта при каждом релизе.

Пункт 6.3.2 вводит требование о ведении актуального, полного и точного инвентарного учета всего кастомного и стороннего ПО, включая используемые API. На выполнение этого требования регулятор дал компаниям отсрочку до 31 марта 2025 года.

По оценке Бароны, многие ИБ-команды сегодня признаются, что слабо представляют себе реальное количество и функции работающих в их инфраструктуре API. Для решения этой проблемы спикер рекомендует выстроить жесткую систему управления (API Governance):

* Разработать единый корпоративный гайдлайн по стилю кодирования (API Style Guide) для программистов.
* Внедрить жесткие стандарты документирования, версионирования и контроля устаревших интерфейсов.
* Консолидировать управление всеми шлюзами через специализированные API Gateway, обеспечивающие унифицированную аутентификацию и ограничение частоты запросов (Rate Limiting).

## 🛡️ Защита веб-приложений и контроль доступа: требования 6.4 и 7
[[JUMP:35:23]]

Пункты 6.4.1 и 6.4.2 регулируют защиту публичных веб-приложений. До марта 2025 года компании могут выбирать между проведением ежегодных сканирований на уязвимости (после любых крупных изменений) или внедрением автоматизированных технических решений для блокировки атак. Однако с 31 марта 2025 года установка инструментов автоматической runtime-защиты становится строго обязательной для всех. В качестве таких решений обычно выступают межсетевые экраны уровня приложения (WAF), функционал API Gateway или специализированные системы защиты API.

Тем не менее, Дэн Барона предупреждает, что ни один «волшебный файрвол» не способен выявить изощренные атаки на уникальную бизнес-логику в режиме реального времени, поэтому автоматическую блокировку необходимо обязательно сочетать с предварительным глубоким тестированием кода.

Раздел 7 PCI DSS 4.0 посвящен ограничению доступа к критическим системам на базе ролевой модели (RBAC). Спикер настаивает на необходимости создания детальной матрицы прав, разграничивающей возможности рядовых клиентов, сотрудников поддержки, администраторов и QA-инженеров на уровне конкретных эндпоинтов API, а не только на визуальном слое интерфейса.

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

## 📊 Логирование и непрерывное тестирование (Требования 10 и 11)
[[JUMP:42:38]]

Раздел 10 стандарта предписывает собирать и анализировать логи со всех компонентов системы обработки платежей. Барона напоминает, что без детальных журналов активности расследовать инцидент или выявить причину компрометации данных становится практически невозможно. Логирование должно осуществляться не только на уровне операционных систем и СУБД, но и на прикладном уровне приложения. 

Разработчикам необходимо внедрять в код события, фиксирующие: кто выполнял действие, что именно было сделано, временную метку, IP-адрес источника и статус успешности операции. Проще всего логировать эти параметры на уровне API Gateway, агрегируя данные в едином репозитории (SIEM-системе) для оперативного реагирования ИБ-службы.

Наконец, Раздел 11 формализует необходимость регулярного тестирования безопасности систем и сетей. Поскольку современные компании обновляют код ежемесячно, еженедельно или даже ежедневно, ручные пентесты раз в полгода становятся бесполезными. Программы проверок должны быть полностью автоматизированы и интегрированы в конвейер разработки (CI/CD), симулируя атаки по всем категориям OWASP API Security Top 10 для каждого эндпоинта при каждом обновлении.

## 🚀 Практические рекомендации: чек-лист «Что делать и чего избегать»
[[JUMP:51:02]]

В завершение разбора Дэн Барона сформулировал ключевые правила построения эффективной программы безопасности API, которые разделены на обязательные действия и критические ошибки.

Рекомендуется делать:

* **Обучать команды:** регулярно проводить специализированные тренинги по специфике угроз API для разработчиков, продуктовых менеджеров и операционных инженеров.
* **Внедрять Security Champions:** назначать увлеченных безопасностью инженеров непосредственно внутрь команд разработки для оперативного консультирования и сокращения разрыва между ИБ и Dev-отделами.
* **Документировать интерфейсы:** принудительно вести актуальную документацию по всем API, что напрямую влияет на прозрачность архитектуры и защищенность.
* **Тестировать на логические дефекты:** проводить агрессивное «прессинг-тестирование» логики, используя интерфейсы способами, не предусмотренными стандартными сценариями использования.

Категорически не рекомендуется делать:

* **Считать внутренние API безопасными:** злоумышленники легко находят недокументированные внутренние интерфейсы, поэтому концепция Zero Trust должна применяться ко всем эндпоинтам без исключения.
* **Полагаться только на ручной пентест:** редкие ручные проверки не успевают за темпами изменений кода и не обеспечивают полного покрытия сотен эндпоинтов.
* **Фильтровать конфиденциальные данные на UI:** одна из самых грубых архитектурных ошибок, когда бэкенд отдает в API полную запись со всеми секретными полями, рассчитывая, что интерфейс фронтенда просто скроет их от пользователя. Хакеры запрашивают API напрямую и получают сырые незащищенные данные.