H1 2024: план на финальный год до дедлайна КИИ, LLM в закрытом контуре и аудит под оборотные штрафы

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

Три темы, которые будут определять первое полугодие 2024.

КИИ: финальный год и точка невозврата

До 1 января 2025 года - двенадцать месяцев. Из них первые шесть - последний реалистичный момент для завершения инфраструктурного слоя. Если к середине 2024 серверные ОС, СУБД и средства виртуализации на всех объектах КИИ клиентов не переведены, второе полугодие будет либо паникой, либо объяснениями регулятору - а оба варианта плохие.

В декабре мы подводили итоги года и видели одну и ту же картину: у кого инвентаризация началась в начале 2023-го - есть структура и понятный остаток работ. У кого тянулась - сейчас тревога и размытые сроки в матрицах замещения.

На H1 у нас три конкретных трека по КИИ.

Первый - серверные ОС на оставшихся объектах. На большинстве клиентов этот слой закрыт или в финальной фазе. Есть два-три объекта, где работы по ОС ещё идут - они получают приоритет в расписании команды в январе-феврале. Дальше тянуть нет смысла: это самый понятный слой с понятными инструментами.

Второй - Oracle и специфические СУБД. Здесь гарантий быстрого закрытия нет. По каждому объекту с Oracle мы в Q1 должны получить внятный ответ: реалистична ли миграция до дедлайна или нужно документировать «аналог отсутствует / миграция требует отдельного проекта». ФСТЭК принимает обоснованные планы - фиктивные «закроем к декабрю» по таким системам никому не помогут.

Третий - АСУ ТП и прикладное ПО. Массовой замены в H1 не будет - нет готовых аналогов, и это честная позиция. Задача полугодия: по каждой системе иметь задокументированный пилотный стенд или технический анализ заменимости. Регулятор хочет видеть движение, а не стояние на месте.

LLM в закрытом контуре: переходим от пилота к production

Весь 2023 год мы поднимали LLM-инфраструктуру клиентов в режиме «посмотрим, что получится». Llama 2 внутри DMZ, RAG поверх документации, CodeLlama как code-assistant для команды разработки. Каждый раз - отдельный стенд, отдельная GPU-машина, отдельный вопрос «а это вообще работает в production?»

К декабрю 2023 у нас накопилось достаточно опыта, чтобы ответить: работает, но требует другого уровня инженерии, чем просто «запустить llama.cpp и показать ответы».

На H1 2024 у нас два клиента, которые перешли черту «нам нравится пилот» и сказали «хотим в production». Что это означает практически:

• Надёжность инференса. Один GPU-сервер без мониторинга и автоперезапуска - это не production. Нужен systemd-юнит или контейнер с restart-политикой, алертинг на недоступность, логирование запросов для аудита.
• Управление моделями. Сейчас модели лежат на серверах как большие файлы без версионирования. Когда выйдет следующая версия Llama или придёт время обновить Mistral 7B - нужен процесс обновления без ручной работы на каждом объекте.
• Разграничение доступа. RAG-система поверх внутренней документации должна знать, кто спрашивает. Не все документы для всех - это требование ИБ на обоих объектах.
• SLA хотя бы в формате «best effort». Разработчики привыкли к code-assistant и начинают на него полагаться. Если сервер недоступен - это уже не «ну ладно», а раздражение.

Это не революция - это обычная операционализация пилота. Но по объёму работы это примерно столько же, сколько сам пилот.

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

Аудит под оборотные штрафы: новая экономика разговора

С 1 января 2024 года закон об оборотных штрафах за утечки ПДн вступает в силу. Мы предупреждали клиентов с сентября - кто-то услышал, кто-то кивнул и продолжил жить как жил.

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

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

Отдельный вопрос - уведомление Роскомнадзора в течение суток. Это требование изменило мониторинг: обнаруживать инциденты нужно быстро, иначе нарушение возникает автоматически. Несколько клиентов, у которых SIEM и логирование были «в планах», теперь переходят в «в работе» - и H1 это закрывает.

Как выглядит расписание

Откровенно говоря, первый квартал будет плотным. КИИ-клиенты с горящими сроками, два LLM production-деплоя и аудитный поток по ПДн - это три параллельных трека, которые не особо пересекаются по команде, но пересекаются по вниманию руководства.

Несколько практических решений, которые приняли заранее.

КИИ-проекты в Q1 идут без новых интеграционных задач. Команда, которая занимается миграцией, не берёт в январе-феврале новые инфраструктурные интеграции. Это болезненно, потому что отказывать клиентам неприятно, но распыление сейчас дороже.

LLM production-деплои стартуют не раньше февраля. Январь - планирование архитектуры и согласование требований ИБ с клиентами. Это небыстро, и торопить здесь не стоит: production-деплой с неверно расставленными правами доступа хуже, чем пилот.

Аудиты ПДн - отдельный специалист ведёт основной поток. Не разбрасываем по всей команде, не делаем это «в свободное время».

Разумно ли это расписание? Посмотрим в июне. Пока оно выглядит как честная оценка того, что реально сделать за шесть месяцев без надрыва.