Планирование H1 2025: ПДн-штрафы, пост-КИИ мониторинг и следующий этап LLM

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

Приоритет первый: ПДн-compliance до мая

Оборотные штрафы вступают в силу в мае 2025 года. Это не новость - закон принят ещё в октябре, и мы уже разбирали механику в деталях. Но между «закон принят» и «наши клиенты готовы» - пропасть, которую нужно пройти за пять месяцев.

По итогам аудитов, которые мы провели в ноябре-декабре, картина у большинства операторов примерно одинаковая: инфраструктурный контур более или менее в порядке, а вот организационная часть - реестры ИСПДн, журналы передачи данных третьим лицам, регламенты уведомления об инцидентах - содержит дыры, которые при проверке РКН станут предписаниями.

Наш план на Q1 2025:

• Закрыть открытые аудиты. У нескольких клиентов аудит проведён, список пробелов есть, но план устранения завис. Это надо довести до конкретных задач с владельцами и сроками.
• Отработать регламент уведомления об инцидентах. Документ на бумаге - не то же самое, что отработанный процесс. Проведём учебные сценарии: «обнаружена утечка, что делаем в первые два часа». Без этого 24-часовое окно - просто строчка в политике.
• Разобрать трансграничные передачи. Самый недооценённый риск. Интеграции с внешними сервисами, которые никто не квалифицировал как «передачу ПДн за рубеж», - именно здесь чаще всего прилетают неожиданности при проверке.

По срокам: всё, что касается организационных мер, хотим закрыть до конца марта. Апрель - финальная самопроверка по чеклисту перед вступлением штрафов в силу. В мае не должно быть сюрпризов.

Приоритет второй: пост-КИИ мониторинг

Дедлайн 1 января 2025 на горизонте - через неделю. Переход состоится - с разной степенью полноты у разных объектов, но юридически большинство клиентов закрывают позиции или оформляют обоснования. Это не финиш, это смена фазы.

Следующий вопрос, который регулятор будет задавать: как вы контролируете безопасность того, что уже перевели? ФСТЭК требует функционирующей системы мониторинга на объектах КИИ - и здесь у части клиентов пробел. Перешли на Astra Linux и отечественные СУБД, настроили антивирус, но целостной картины событий безопасности в одном месте - нет.

В H1 2025 планируем:

• Дотащить интеграцию с ГосСОПКА там, где она застряла на этапе «API настроили, отправку не проверили». Это операционная задача, не архитектурная, но именно такие задачи живут вечно в статусе «почти готово».
• Выстроить базовый мониторинг событий по объектам на основе того, что уже есть - Zabbix 7 LTS, где его обновляли, или добавленные SIEM-коннекторы. Не строить мониторинг с нуля, а склеить то, что уже задеплоено, в связную картину.
• Зафиксировать baseline нормального поведения для ключевых систем. Это нужно не само по себе, а потому что без baseline любая аномалия - это либо паника, либо игнор. Оба варианта плохи.

Честно скажем: это не быстрая работа. Если у объекта пять-шесть разнородных систем с разными источниками логов - «склеить в связную картину» занимает несколько недель инженерного времени плюс итерации. Рассчитываем закрыть основное к концу Q2.

Приоритет третий: следующий этап LLM в эксплуатации

По итогам 2024 года у нас есть рабочий набор сценариев: генерация черновиков Ansible-задач, LLM-объяснение незнакомых логов, Copilot Chat для документационных вопросов. Это работает, и инженеры к этому привыкли.

Вопрос, который висит в воздухе: что следующее? Несколько направлений, которые хотим опробовать в H1 2025.

Инцидент-ориентированный анализ. Когда что-то падает, инженер тратит время на корреляцию событий из разных источников - логи, метрики, алерты. Пробуем сценарий: LLM получает сырой срез из нескольких систем и строит гипотезу о причине. Не принимает решение, не выполняет действия - только помогает быстро сориентироваться. По нашей оценке, это снизит время до первой рабочей гипотезы при инцидентах среднего класса. Проверим на практике.

Документирование инфраструктуры. Самый нелюбимый тип задач в любой команде. Попробуем подход: инженер проводит изменение, LLM на основе diff конфигов и лога действий генерирует черновик описания изменения в runbook. Инженер правит и утверждает. Низкий риск, понятная ценность.

Формализация контекста для локальных моделей. Главный ограничитель качества локальных LLM - отсутствие контекста конкретного окружения. Хотим построить более системный подход к системным промптам: описание соглашений, запрещённых паттернов, топологии клиентских инфраструктур. Это скучная работа по структуризации знаний, но без неё качество остаётся нестабильным.

Агентных сценариев с автономным выполнением действий в этом плане нет. Не принципиально, просто планка надёжности пока не там, где нужна для инфраструктурной работы без инженера в петле.

Как это выглядит в сумме

Три приоритета, шесть месяцев. Регуляторика - жёсткие дедлайны, технический мониторинг - среднесрочная программа, LLM - серия управляемых пилотов. Ничего революционного, но именно так и работает планирование в инженерной команде: не «трансформируемся», а «закрываем конкретные задачи к конкретным датам».

По ходу H1 будем публиковать промежуточные итоги - что сложилось, что нет и почему.