Защита 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 года из нашей сети не открылась по таймауту в 60 секунд, вывод об отсутствии подписанного приказа опирается на вторичные источники. Что меняется при переходе, в статье про отмену приказа ФСТЭК № 21.

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

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

Разбор собственного контура 21 августа 2026 года: к полям заявки с сайта обращались 16 скриптов, под контролем версий был один. Рядом лежала выгрузка на 51 349 байт с 45 заявками за 15.07-19.08.2026 без правила исключения полей. Ни один из 16 не считался интерфейсом.

Аудит скриптов той же датой: 64 файла на Python и 12 462 строки за 90 дней, свой сетевой код в 43 файлах, 11 файлов не упомянуты ни в одном документе. Файл, о котором не написано нигде, не попадет в перечень мер.

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

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

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

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

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

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

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

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

Автоматически найти персональные данные в ответах получается частично. Прод-замер нашего движка поиска 20 августа 2026 года на выборке из 2867 текстов и 4585 размеченных сущностей дал покрытие 92,5 процента при 344 пропусках и 301 ложном срабатывании, по ФИО 87,3 процента. Это результат на нашей выборке, полноту обнаружения мы не обещаем, и перечень полей в ответе утверждает человек.

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

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

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

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

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

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

Наш случай 18 июля 2026 года. Скрипт работал по обычному паттерну: прочитать содержимое записи, дописать блок, записать обратно. Чтение вернуло пустое поле, потому что полное значение отдается только в режиме редактирования. Код записал пустую строку с добавкой и затер четыре статьи до 120-180 знаков. Восстановили из черновиков.

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

Регистрация событий стоит в пункте 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 мы не рекомендуем и продукты по качеству не сравниваем, средства защиты не перепродаем. Полноту автоматического обнаружения персональных данных не заявляем. Оператором или обработчиком ваших данных себя не называем, статья не заменяет юридическое заключение.

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