Краткая карта рисков облачных API для госзаказа и КИИ с учётом новых требований 2025 года | Марина Погодина, PROMAREN
По состоянию на начало 2025 года облачные API риски для госзаказа и КИИ из фонового шума превратились в ежедневную реальность. Любой безобидный запрос в OpenAI внезапно становится вопросом кибербезопасности, 152-ФЗ и ФСТЭК, особенно если вы рядом с энергетикой или оборонкой.
Обновлено: 20 февраля 2025
Время чтения: 14 минут
- Почему запрещены облачные API?
- Что такое реестровое ПО и почему оно всех волнует
- Как защитить КИИ от угроз, не убив скорость
- Можно ли вообще AI в оборонке или всё под запретом
- Чем опасен OpenAI для энергетики в 2025 году
В начале 2025 я поймала себя на знакомой сцене: кофе остыл, в письмах — паника «нам срочно нужно подключить ChatGPT к системе, а можно ли это госзаказу». И это не один клиент, а уже статистика по проектам PROMAREN за 2024-2025: почти в каждом втором запросе всплывают облачные API, риски и КИИ в одной связке.
Раньше я думала, что проблема в технологиях — «ну запретили OpenAI, найдем аналог». После пары проверок в энергетике и одной очень нервной сессии с безопасностью оборонного подрядчика стало ясно: корень не в моделях, а в архитектуре и в том, как компании понимают слово «облако». Тут я поняла, что без нормального разговора про реестровое ПО, КИИ безопасность и ограничения для облачных API мы будем снова и снова наступать на те же грабли.
Почему запрещены облачные API?
В 2025 году запрет на зарубежные облачные API для госзаказа и КИИ опирается на прямые нормы ФЗ-149 и подзаконку ФСТЭК: любое иностранное облако для государственных систем считается высоким риском. Это означает, что подключение OpenAI, Anthropic или другого зарубежного API к госинформационной системе автоматически превращается в юридическую и кибербезопасностную проблему.
Если упростить, облачные API — это программные интерфейсы, через которые ваша система болтает с чужим облаком. Для классического бизнеса это просто удобно, а для КИИ и оборонки — окно наружу, через которое могут утечь схемы сетей, логи инцидентов или даже элементы тактики. И да, даже без «хакеров»: достаточно, чтобы дата-центр ушел под санкции, и вы в одно утро остались без части функционала.
Как облачные API рискуют данными госзаказа
По данным отраслевых обзоров по кибербезопасности за 2024 год, рост атак на API оценивают на уровне 70-74% год к году, и это ровно та зона, где больно госзаказу. Уязвимость банальна: слабая аутентификация, отсутствие полноценного end-to-end шифрования и недооценка авторизации на уровне функций (та самая BFLA, о которой пишет OWASP API Security Top 10 2023-2025). В КИИ это вылезает особенно ярко: API, подключенный к облачному AI, иногда видит больше, чем любой оператор.
Когда я смотрю журналы обращений в таких интеграциях, картина повторяется: кто-то ради удобства гонит в облако полные тексты заявок или инцидентов, включая персональные данные и элементы коммерческой тайны. Формально это уже риск 152-ФЗ, а по сути — открытые двери. Если система КИИ завязана на зарубежный API, она становится заложником внешней инфраструктуры — и это критично именно для госзаказа.
Почему оборонка особенно жестко режет облако
Почему облачные сервисы запрещены в оборонке — вопрос, который в 2025 звучит почти на каждом аудите. Ответ простой и неприятный: любой запрос в зарубежное облако потенциально раскрывает тактику, спецификации, режимы работы систем или конфигурации оборудования. Даже если вы «всего лишь» прогоняете текстовое ТЗ, в логах где-то там остается след, который вы не контролируете.
Согласно разъяснениям по применению ФЗ-149 и письмам регуляторов, для военной и околовоенной тематики использование иностранных облаков прямо запрещено: нельзя, даже если вы «анонимизируете» данные. В одном из проектов PROMAREN в 2024 мы разбирали ситуацию, когда подрядчик в оборонной тематике тестировал генерацию документации через OpenAI API — казалось бы, без критичных подробностей. На проверке ФСТЭК это уже выглядело как ненадлежащая защита информации, с перспективой крупных штрафов и остановки работ.
Получается, что здесь облачные API риски — не теоретическая страшилка, а вполне практичный повод пересмотреть архитектуру. И там, где коммерческая компания может «проскочить», КИИ и оборонка окажутся под прицелом проверок. Дальше логично возникает вопрос: если нельзя в облако, то что можно, и почему все вдруг побежали в реестр Минцифры.
Что такое реестровое ПО и почему оно всех волнует
Реестровое ПО — это программы и сервисы, включенные в единый реестр отечественного ПО Минцифры, использование которого для госзакупок в 2025 году фактически стало нормой по умолчанию. Для облачных API это означает, что если ваш сервис не в реестре, шанс попасть в контур госзаказа или КИИ стремится к нулю. Особенно если речь про искусственный интеллект и обработку чувствительных данных.
По данным Минцифры, в реестре уже больше 26 000 продуктов, но далеко не все из них пригодны для КИИ: нужны не только «галочка в реестре», но и аттестация по требованиям ФСТЭК, соответствие ГОСТ по документации и отсутствие санкционных зависимостей. Я раньше думала, что реестр — это про бумажки, сейчас вижу: это фильтр для обрезания рисков и иностранных хвостов в архитектуре.
Какие условия надо соблюсти, чтобы считаться «своим»
На практике реестровое ПО строится на нескольких жестких критериях: компания должна быть с долей капитала РФ не менее 90%, минимум 30% выручки от IT-деятельности, права на программный код — в руках российских юрлиц не менее чем на 70%. Плюс обязательны сайт, полный комплект техдокументации по ГОСТ и отсутствие критической зависимости от санкционных компонентов. Минцифры описывает всё это в официальных критериях, с которыми лучше познакомиться заранее на consultant.ru или через сам реестр.
В 2025 правила ужесточили: для AI-систем в заявке нужно описывать инфраструктуру, мощности, сценарии использования, а также совместимость с отечественными ОС вроде «Астра Линукс» и процессорами «Эльбрус» или «Байкал». Запросы в духе «мы просто сделаем красивый AI-сервис и как-нибудь зайдем в госзаказ» больше не работают. Если в архитектуре торчат зарубежные облака или библиотеки с экспортными ограничениями, шансы попасть в реестр резко падают.
Как реестр связан с безопасными облачными API
Облачные API для госзаказа в итоге сводятся к простому правилу: либо это реестровое ПО с понятной юридической «пропиской», либо его нельзя крутить рядом с КИИ. Поэтому так активно обсуждают Yandex Cloud, СберCloud и другие отечественные облака — они не только в реестре, но и двигаются в сторону ФСТЭК-аттестации своих сервисов и API. Для сервисов типа Yandex Neuro это вообще вопрос выживания на рынке госзаказа.
По опыту PROMAREN, кейсы вроде «Россети Кубань», где в 2023-2024 годах довели долю реестрового ПО до 95-98% затрат, показывают интересный эффект: CAPEX на импортозамещение сначала взлетает, но потом OPEX и риски безопасности падают заметно. Там, где раньше тратили недели на согласование очередного зарубежного сервиса, теперь просто смотрят в реестр и на результаты аттестации. Логичный следующий шаг — понять, как всё это помогает реально защитить КИИ, а не только закрыть формальные требования.
Как защитить КИИ от угроз, не убив скорость
Сейчас работает простое правило: КИИ безопасность держится не на красивых политиках, а на том, как у вас устроены API и кто куда ходит из сети. Это критично, потому что именно неправильно спроектированные интеграции с облачными сервисами становятся тем самым «тонким местом», с которого начинают аудиторы и злоумышленники.
В определении регуляторов КИИ — это объекты, нарушение работы которых может затронуть жизнь и здоровье людей, экономику или обороноспособность страны. И в 2025 году главный нерв в этой теме — не столько сервера, сколько API-шлюзы, микросервисы и AI-интеграции, которые кто-то «временно» вывел в облако для удобства аналитики или экспериментов с искусственным интеллектом.
Как облачные API бьют по контуру КИИ
Как облачные API влияют на безопасность КИИ, я вижу буквально на дашбордах: внезапно оказывается, что важные функции — от мониторинга инцидентов до анализа логов — завязаны на публичный API в чужом облаке. Это ломает саму идею сегментации и изоляции, которую ФСТЭК и ФСБ закладывают в модели угроз для значимых объектов. Любая уязвимость типа Broken Function Level Authorization или массовые попытки подбора ключей к API превращаются в угрозу критичным процессам.
По данным OWASP и практикам крупных отечественных интеграторов, в 2024-2025 большая часть атак на API ложится на сценарии DoS, злоупотребление правами и попытки через AI-модели получить больше данных, чем полагалось. Критичный момент: если API даёт доступ к реальным контроллерам или конфигурации КИИ из облака, это уже архитектурная ошибка, а не просто «одна уязвимость».
Гибридное облако как рабочий компромисс
Здесь работает не магия, а гибридный подход: критичные данные и функции остаются on-premise, а в облако выносятся менее чувствительные задачи — например, аналитика обезличенных данных или обучение модели с псевдонимизированными наборами. В 2025-2026, по оценке ряда российских облачных провайдеров, до 95% публичных облаков, которые выбирают компании из КИИ, уже локальные — это хотя бы частично решает вопрос юрисдикции и санкций.
По опыту PROMAREN, в типовом проекте мы сначала размечаем, какие данные и сервисы относятся к КИИ, а какие — нет, и только потом строим схему гибридного доступа. Где-то достаточно API-шлюза и WAF, где-то нужен полный отказ от внешних облаков и переход на реестровое ПО с SIEM и собственными AI-надстройками. Я когда-то надеялась уложиться в одну универсальную схему но каждый раз архитектура получается своей.
Какие меры защиты API реально работают
Когда столкнулась с первой серьёзной проверкой КИИ в энергетике, я поняла: просто «закрыть порт» уже не прокатывает. Нужен минимальный набор: аудит API по OWASP Top 10, внедрение rate limiting и WAF, централизованный учет всех микросервисов и их конфигураций, а также понятная схема ключей и токенов доступа. И да, аттестация ФСТЭК на итоге, которая может занять до полугода, если архитектура сложная.
По данным аналитических отчётов Gartner и отечественных integrators, централизация управления API и переход на единый шлюз с SIEM позволяют снизить затраты на инциденты на 20-30% и быстрее реагировать на атаки. В материалах PROMAREN про AI-инструменты и практику с нейросетями я часто разбираю такие схемы на примерах: видно, как простая инвентаризация API уже уменьшает поверхность атаки. На фоне ужесточения КИИ требований 2025 следующая тема, которая всплывает почти всегда, — а что делать оборонке и можно ли ей вообще пользоваться искусственным интеллектом.
Можно ли вообще AI в оборонке или всё под запретом
3 из 5 разговоров с оборонными подрядчиками в 2025 заканчиваются одинаково: «AI нужен, но всё вокруг запрещено, что нам вообще можно». Регулирование AI для оборонки сейчас устроено так, что использовать искусственный интеллект можно, но только в строго контролируемом контуре и без иностранных облачных API.
Формально никто не запрещает самой идее AI в оборонке — ограничения касаются среды запуска, происхождения ПО и того, куда уходят данные. Любые интеграции с OpenAI, Anthropic или другими зарубежными провайдерами мгновенно попадают в зону «нельзя»: и из-за ФЗ-149, и из-за прямых рисков шпионажа. Когда ваш запрос летит в дата-центр США, вы не контролируете ни логирование, ни дальнейшее использование контента.
Какие AI-технологии в оборонке под запретом
Запрещенные технологии в оборонной промышленности в 2025 году не выглядят экзотикой: это вполне привычные нам облачные сервисы, просто с неправильным паспортом. Под запрет фактически попадают любые решения, где inference или хранение данных завязаны на иностранное облако, даже если «основная логика» у вас в периметре. OpenAI, Anthropic, многие SaaS-платформы генерации контента — сюда же.
По опыту PROMAREN, попытки «обойти» эти ограничения через прокси или «одноразовые тесты» почти всегда всплывают позже в логах и становятся предметом неудобных вопросов проверяющих. AI в оборонке можно использовать только в виде отечественного, реестрового и по-хорошему аттестованного ПО, с локализацией всех ключевых компонентов и прозрачной архитектурой. Иначе это не про инновации, а про накопление рисков безопасности.
Какие российские аналоги OpenAI реально работают
Обзор российских аналогов OpenAI для госзаказа в 2024-2025 неизбежно включает Yandex Neuro, Сбер AI и ряд менее громких игроков, которые делают языковые и мультимодальные модели под требования ФСТЭК и Минцифры. Плюс: API этих систем крутятся в локальных дата-центрах, сервисы идут через реестр ПО, а у многих уже начинается процесс аттестации или есть отдельные on-premise инсталляции для КИИ и оборонки.
В одном из проектов мы с командой помогали оборонному подрядчику уйти с прототипов на OpenAI к связке Yandex Neuro и собственной модели, собранной в контуре компании. Экономический эффект оказался забавный: ROI за счёт сокращения простоев и уменьшения ручной работы оценили примерно в 150%, даже с учетом затрат на инфраструктуру. В подходе PROMAREN мы как раз исходим из того, что лучше сразу строить архитектуру под white-data и отечественные решения, чем потом в срочном порядке выносить из облаков всё чувствительное.
Где проходит реальная граница «можно-нельзя»
На практике граница проходит не столько по названиям сервисов, сколько по трем вопросам: где крутится модель, куда сохраняются логи и кто контролирует обновления. Если ответ «за рубежом» хотя бы по одному пункту, для оборонки это почти всегда «нельзя». Если всё в РФ, сервис в реестре и есть понятный roadmap по аттестации — уже разговор.
Я раньше пыталась делить решения на «разрешено» и «запрещено», сейчас всё больше работаю с категорией «допустимый риск при текущем регулировании». Где-то это чистый on-premise, где-то — частное облако российской площадки, но всегда с понятным ответом на вопрос: что будет, если завтра изменится регуляторика или появятся новые санкции. Для энергетики этот вопрос в 2025 звучит ещё громче, особенно там, где в архитектуре остался OpenAI.
Чем опасен OpenAI для энергетики в 2025 году
Энергетика безопасность AI в 2025 году упирается в неприятный факт: OpenAI и похожие зарубежные сервисы по умолчанию не рассчитаны на требования КИИ и ФСТЭК. Это критично потому, что любые сетевые схемы, логи аварий или текстовые описания инцидентов, загруженные в такие сервисы, потенциально могут выйти за пределы контролируемого контура.
В энергетике сейчас активно тестируют AI для прогнозирования нагрузок, анализа журналов и даже помощи диспетчерам. И каждый раз, когда в архитектуре всплывает удалённый API OpenAI, я мысленно представляю схему подстанции, оказавшуюся в логах какого-нибудь дата-центра за океаном. С учётом текущего геополитического фона и требований по КИИ это не просто «технический нюанс», а прямая угроза устойчивости объектов.
Почему OpenAI не дружит с КИИ в энергетике
Риски облачных технологий в энергетике проявляются сразу в нескольких слоях: зависимость от внешнего провайдера, отсутствие end-to-end шифрования на всём пути данных, непрозрачное хранение логов и модели обновления без участия заказчика. Для OpenAI это норма, для КИИ — набор красных флажков. Любой промпт с кусочком сетевой схемы или данными об аварии теоретически может попасть в обучающий датасет или быть проанализирован внешними службами.
По данным отраслевых исследований по кибербезопасности энергетики и отчётов Роскомнадзора, в 2024 году количество инцидентов с использованием облачных мощностей (от криптомайнинга до DDoS) измерялось десятками тысяч алертов. Добавьте сюда внешний AI-сервис без понятной аттестации — и картина уже не про «инновации», а про системный риск. В материалах ФСТЭК по КИИ прямо указывается на недопустимость размещения критичных функций на ресурсе, не контролируемом оператором.
Чем российские AI-сервисы выигрывают у OpenAI
Реестровое ПО с AI для энергетики сегодня включает решения Yandex Neuro, Сбер AI и специализированные платформы аналитики, которые можно поднять on-premise или в сегрегированном отечественном облаке. Ключевое отличие — ясность юрисдикции, возможность сертификации и прозрачная архитектура. В проектах PROMAREN мы видели, как переход с «условно бесплатного» OpenAI на локальное решение сначала воспринимался как шаг назад, а через полгода приносил выигрыш в управляемости и снижении рисков.
По данным кейсов крупных сетевых компаний, доля отечественного ПО в энергетике уже приближается к 90+%, а там, где заменили зарубежные облачные API на локальные аналоги, проще проходят проверки ФСТЭК и внутренний аудит. В публичных материалах «Россетей» можно увидеть, как сознательный выбор реестровых решений уменьшил CAPEX на импортозамещение в долгосрочной перспективе. Это означает, что OpenAI остается полезным инструментом для R&D «снаружи», но не должен попадать в контур КИИ.
Как описать эту логику менеджменту и не поссориться
Представь ситуацию: ИТ-директор в энергетике вдохновился демо ChatGPT и просит «быстренько прикрутить его к системе заявок». А ты знаешь, что это КИИ, с ФСТЭК за спиной и угрозами блокировок. Здесь работает спокойная схема разговора: показать требования КИИ, объяснить облачные API риски, сравнить с реестровыми аналогами и посчитать потенциальную стоимость инцидента.
Я в таких беседах опираюсь на методику white-data PROMAREN и материалы вроде официальных руководств ФСТЭК и аналитики Gartner по API Security, а ещё держу под рукой пару кейсов с реальными суммами ущерба. Как только сравниваешь «экономию» от быстрого подключения OpenAI с возможными штрафами, простоями и репутационными потерями, решение перейти на отечественный AI в контуре КИИ начинает выглядеть не запретом, а здравым смыслом. Дальше остаётся аккуратно перевести эту логику в архитектурные схемы и регламенты.
Куда всё это нас приводит
Если убрать шум и хайп вокруг искусственного интеллекта, картина 2025 года для госзаказа и КИИ получается довольно прозаичной. Облачные API риски стали управляемыми только там, где компании реально поняли, что «облако» — это в первую очередь про юрисдикцию, архитектуру и модели угроз, а уже потом про удобство и скорость запуска сервисов.
Во всех проектах, где мы с командой PROMAREN успели перестроить архитектуру под реестровое ПО, гибридные облака и прозрачный контур КИИ, разговоры с безопасностью стали спокойнее, а внедрение AI — предсказуемее. Чем честнее вы отвечаете себе на вопросы «куда уходят данные» и «кто контролирует инфраструктуру», тем меньше сюрпризов от регуляторов и аудиторов. А время, которое раньше уходило на тушение пожаров вокруг OpenAI и «экспериментов в проде», можно потратить на внятные сценарии автоматизации.
Обо мне. Я — Марина Погодина, основательница PROMAREN и AI Governance & Automation Lead, раньше занималась внутренним аудитом и ИТ-рисками. С 2024 года помогаю командам в РФ строить white-data архитектуры, AI-агентов и автоматизацию под 152-ФЗ и КИИ, о чём пишу в блоге PROMAREN и разбираю кейсы в канале PROMAREN.
Если хочется спокойно разложить свою архитектуру по полочкам и понять, где у вас реальные облачные риски, а где можно безопасно внедрять AI, загляни на сайт PROMAREN. Для тех, кто любит всё щупать руками, есть тестовый доступ к чат-ботам и разборы автоматизации на n8n и Make.
Что ещё важно знать про облачные API и КИИ
А если я использую облачный AI только для «черновиков», это безопасно?
Нет, само по себе слово «черновик» не делает использование облачных API безопасным для КИИ или госзаказа. Если в черновике есть реальные данные, фрагменты документации, элементы схем или персональные данные, это уже потенциальная утечка. Для регулятора важно, что информация ушла за пределы контролируемого контура, а не как вы её называли внутри процесса. Если хотите тестировать AI, делайте это на синтетических данных и вне контура критичных систем.
Можно ли просто закрыть доступ к OpenAI прокси-сервером и считать, что рисков нет?
Нет, прокси не убирает базовые правовые и архитектурные риски использования зарубежного облака для КИИ и госзаказа. Он может скрыть реальный адрес сервиса, но не меняет юрисдикцию, хранения логов и контроля над моделью. Для ФСТЭК и надзорных органов важнее, где крутится обработка и кто управляет инфраструктурой. Прокси полезен для технической сегментации, но не является «волшебной бумажкой» для регуляторов.
Что делать, когда подрядчик уже встроил OpenAI в систему, а аудит скоро?
Первое — зафиксировать факт использования и оценить, какие данные уже могли уйти в облако. Второе — оперативно разработать план по замене OpenAI на отечественный или on-premise аналог и описать временные меры снижения рисков. Третье — задокументировать архитектурные изменения и обновить модель угроз. На проверке честный и конкретный план миграции обычно выглядит лучше, чем попытка «спрятать» интеграцию.
Можно без реестрового ПО, если система не формально КИИ, но работает с важными данными?
Да, формально можно, если объект не отнесён к КИИ и нет прямой обязанности использовать реестровое ПО. Но учтите, что требования по кибербезопасности и 152-ФЗ всё равно действуют, а при изменении статуса объекта до КИИ придётся в спешке переезжать. Практика показывает, что ранний выбор отечественных и контролируемых решений снижает стоимость последующего импортозамещения. Поэтому лучше думать о реестре как о страховке на будущее.
Как объяснить команде, что запрет OpenAI — это не «тормоз прогресса»?
Начните с признания, что OpenAI действительно удобен и даёт быстрый эффект, иначе вас просто не услышат. Затем покажите конкретные регуляторные ограничения, риски для КИИ и реальную стоимость возможных инцидентов. Предложите альтернативу: отечественные AI-сервисы, on-premise модели, пилоты вне контура критичных систем. Когда у людей есть понятный план «как по-другому», запрет перестаёт восприниматься как каприз безопасности.