Защита API: пункт 12 приказа ФСТЭК на практике

Пункт 12 проекта приказа ФСТЭК называет защиту программных интерфейсов взаимодействия приложений отдельной группой мер. У компании с сайтом, формой заявки и двумя интеграциями это читается как требование к чужой инфраструктуре. Разбираем, что пункт требует от оператора персональных данных и какая часть работы закрывается в коде.

Что требует пункт 12 и кого он касается

Проект приказа ФСТЭК России от 24 июля 2026 года готовится на замену приказу № 21 от 18 февраля 2013 года. Пункт 12 собирает технические меры в информационных системах и делит их на 17 групп.

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

К периметру небольшой компании относятся три группы из 17: веб-технологии, API и почта. Остальные включаются, когда у вас есть свои контейнеры, беспроводные точки, парк мобильных устройств. Состав мер оператор закрепляет в политике обработки персональных данных.

Пункт 16 про сертификаты на продукты, пункт 12 про меры: разговоры разные.

Статус документа на 29 августа 2026 года: проект не подписан и в Минюсте не зарегистрирован, приказ № 21 действует. Заявленная дата вступления в силу 1 сентября 2026 года, до нее три дня. Общественное обсуждение шло до 8 августа 2026 года. Оговорка: 29 августа 2026 года раздел приказов на сайте ФСТЭК не отвечал, поэтому вывод об отсутствии подписанного приказа опирается на вторичные источники. Что меняется при переходе, в статье про отмену приказа ФСТЭК № 21.

Сначала инвентаризация: сколько у вас точек входа

Пункт 13 задает порядок: базовые меры под ваш уровень защищенности, адаптация под архитектуру, проверка против актуальных угроз. Первый шаг упирается в вопрос, на который у большинства нет письменного ответа: сколько у вас точек входа, через которые ходят персональные данные.

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

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

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

Идентификация и управление доступом на уровне эндпоинта

В маленьком контуре первые две группы сводятся к дисциплине ключей: нужны таблица и правило, а не продукт.

У ключа есть три свойства. Владелец: человек или интеграция, а не отдел. Срок: дата, после которой ключ мертв. Область: какие эндпоинты и операции он открывает. Ключ без владельца отзывается, и отзыв сам показывает, кто им пользовался.

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

Что эндпоинт отдает наружу

Защита API продолжается там, где начинается ответ. Эндпоинт, отдающий карточку клиента целиком, когда потребителю нужны имя и статус, повышает цену любой ошибки в аутентификации.

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

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

Форма на сайте это тоже API

Публичная форма принимает данные от неизвестного отправителя и передает в обработку. По составу это точка входа: защита веб-технологий и защита API на ней встречаются.

Внешний аудит наших страниц 26 августа 2026 года дал результат, который мы сами не нашли. Из 194 опубликованных записей форму с именем, e-mail и телефоном несли 16. Чекбокса согласия не было ни на одной. Закрыто фильтром на выводе, проверено на 16 URL из 16, открытием каждой страницы.

Побочно нашлось то, что не ловится поиском по коду: на четырех записях согласие печаталось контрастом 1,7:1 и не читалось глазом. После правки 15,98:1. Дефект нашел внешний аудит, а не наш гейт публикации. Проверка кода не заменяет проверку отданной страницы.

Валидация запроса на стороне сервера

Клиент присылает то, что прислал. Сервер решает, что с этим делать. Разница между отсутствующим полем и пустым значением стоит здесь дороже всего.

Типовой сценарий на этом месте выглядит так. Скрипт работает по обычному паттерну: прочитать содержимое записи, дописать блок, записать обратно. Чтение возвращает пустое поле, потому что полное значение отдается только в режиме редактирования. Код записывает пустую строку с добавкой, и содержимое записи схлопывается до пары строк. Ошибка не в API, а в том, что ответ на чтение никто не проверил.

Правило после этого такое: пустое поле в запросе не означает «не менять». Сервер обязан явно различать три состояния. Поля нет в запросе, оно остается прежним. Поле пришло пустым, оно очищается, и на эту операцию нужно отдельное право. Поле пришло со значением, оно перезаписывается. Проверка длины ловит остальное: резко укоротившаяся запись это повод остановиться, а не сохранить.

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

Сколько это стоит на рынке

Рынок продает периметр вокруг API помесячно. Цены ниже сняты с живых страниц вендоров 29 августа 2026 года.

Один контур обходится в десятки тысяч рублей в месяц. Пункт 12 при этом требует мер, а не покупки продукта. Перечень точек входа, владельцы и сроки у ключей, состав полей в ответе, различение пустого и отсутствующего поля, чистый лог закрываются в коде.

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

Что успеть за три дня

У каждого шага есть проверяемый результат.

1. Выпишите точки входа

   Формы, вебхуки, экспорт, интеграции, служебные скрипты у базы. Результат это список с числом строк. Наш дал 16 там, где ожидался один.

2. Назначьте каждому ключу владельца, срок и область

   Ключ без владельца отзывается. На выходе таблица из четырех колонок и список отозванного.

3. Посмотрите, что уходит в ответе и в уведомлении

   Лишние поля убираются, контакты в письме маскируются. На выходе утвержденный перечень полей.

4. Откройте каждую страницу с формой глазами

   Поиск по коду показывает разметку, а не то, что видит посетитель. Результат это число проверенных URL из общего.

5. Разведите на записи пустое поле и отсутствующее

   Плюс проверка длины перед сохранением. Результат это тест, который падает на попытке затереть запись пустым значением.

6. Зафиксируйте состав мер в политике

   Для недоступных мер работает пункт 14: компенсирующая мера с обоснованием. На выходе абзац в политике.

Сколько стоит разобрать контур

Перечень точек входа не требует платформы и лицензий. Мы работаем почасово: 2 500 рублей в час, оплата по факту. На выходе список эндпоинтов и ключей, состав полей в ответах и уведомлениях, техническая часть по доступам и автоматизации.

Отдельный пакет нужен, когда тексты обращений уходят во внешние ИИ-сервисы. Разбор ИИ-канала идет по выборке из 200 реальных текстов, 10 рабочих дней, 49 000 рублей, пресейл-прогон бесплатный. Отчет описывает согласованную выборку и не заменяет заключение.

Кто какую часть работы ведет

Приведение системы в соответствие под ключ ведет лицензиат ТЗКИ: по пункту 6 такие работы вправе выполнять только он. Разработка и правки в коде идут отдельным предметом договора.

Средства криптографической защиты и шифрование каналов как услугу поставляет лицензиат ФСБ России: это его компетенция по пункту 5 проекта.

Вендора WAF мы не рекомендуем и продукты по качеству не сравниваем, средства защиты не перепродаем. Полноту автоматического обнаружения персональных данных не заявляем. Оператором или обработчиком ваших данных себя не называем, статья не заменяет юридическое заключение.

Частые вопросы

Пункт 12 проекта приказа ФСТЭК выделяет защиту API в отдельную группу мер. Что он требует от компании с сайтом и парой эндпоинтов и с чего тут начинать.