Зачем ФСТЭК ограничивает права ИИ

ФСТЭК готовит новые правила для ИИ в государственных информационных системах. 24 августа ведомство опубликовало проект изменений в приказ №117. В нем предлагается ограничить модели ИИ в доступе и правах. Проект должен вступить в силу 1 марта 2027 года.

Что меняется, когда ИИ получает доступ к LDAP

ИИ сильно повзрослел. Это уже не просто собеседник, а полноценный агент, который может сам обращаться к компьютерам, серверам и выполнять операции.

Например, если ИИ-агенту дать доступ к корпоративному LDAP-каталогу, он сможет:

• Добавить учетную запись в группу

• Изменить атрибут пользователя

• Изменить членство в группе

• Массово изменить данные

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

Что может оказаться под угрозой?

В каталоге лежат не только логины и учётные записи, но и ФИО, должности, отделы, телефоны, почта, фото – целая база персональных и служебных данных.

Если агенту разрешено читать эти данные, то злоумышленникам не обязательно взламывать LDAP. Достаточно дать агенту команду – и он сам отдаст данные наружу или испортит их.

Локальная или внешняя модель?

С точки зрения рисков не принципиально, используете вы внешнюю или локальную модель. Если локальная модель имеет широкие права, она сольёт данные не хуже внешнего сервиса. Так что ФСТЭК смотрит не на место проживания модели, а на то, что она видит, к чему имеет доступ и что может делать.

Один неправильный запрос может превратиться в инфраструктурный инцидент.

Причем источник проблемы может находиться далеко от каталога. Например, вредоносная инструкция может попасть в ИИ через внешний ресурс или заражённый документ. Эксперты называют prompt injection одной из главных дыр, которые надо закрывать в защите ИИ.

ИИ становится еще одним участником системы доступа

Выходит, ИИ-агент, подключенный к каталогу, становится еще одним участником системы управления доступом. Если дать ему слишком много прав, мы откроем путь:
внешняя команда → ИИ-агент → LDAP → данные пользователей или права доступа.

Поэтому принцип минимальных прав критичен. Если агенту нужен только один атрибут – не даём ему весь каталог. Если нужно сделать одну операцию – не разрешаем править все учётки. Чем меньше прав, тем меньше ущерб от возможной атаки.

Что делать, если изменения уже произошли

Просто иметь бэкап каталога – мало. Если агент испортил сотни записей, полный откат вернёт старую версию, но заодно откатит все правильные изменения, которые появились после бэкапа.

Поэтому нужны два уровня защиты:

1. Резервное копирование, чтобы сохранить состояние каталога;

2. Гранулярное восстановление, чтобы найти и вернуть неправильно изменённые объекты или атрибуты.

Получается простая цепочка:

ограничить права ИИ → контролировать его действия → не дать слить данные наружу → не дать править лишнее → иметь бэкап → уметь точечно восстановить данные.

Новые требования ФСТЭК интересны не только для ИИ. Они показывают: если ИИ подключается к инфраструктуре, его безопасность становится частью безопасности всей системы – включая службу каталога.

🎓 Linux со школьной скамьи

Ровно через две недели — 1 сентября. Для тысяч школьников этот звонок станет ещё и первым входом в мир Linux. И это отличный повод поговорить о том, как отечественные ОС входят в образование.

Помните, как в первый раз ставили программу на Linux? И это заняло полдня. Многие ещё тогда прочувствовали стресс перехода с привычных Windows или macOS. Даже когда новая система решает все привычные задачи, первое время она кажется чужой. И этот дискомфорт легко принять за недостаток самой платформы.

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

Школьный Linux даёт два плюса: дети привыкают к системе без стресса, а компании получают готовых специалистов.

Уже сейчас бизнесу нужны не только сами операционные системы, но и люди, которые умеют с ними работать без страха и раздражения. Таких специалистов проще вырастить со школьной скамьи, чем переучивать.

Кто-то из сегодняшних школьников станет разработчиком, специалистом по ИБ или Linux-администратором. Командная строка, права доступа и установка пакетов уже не будут казаться ему чем-то чужим.

Из того, что уже работает в школах, — РЕД ОС Образовательная редакция и «Альт Образование».

РЕД — не урезанная система «только для уроков»: на ней можно и роботов собирать, и 3D-модели рисовать, и код писать. Плюс есть лёгкий режим для слабых ПК и серверная часть для дневников и учёта.

«Альт» — в том же ключе: от робототехники до инженерной графики, плюс бесплатен для физических лиц и работает на разных архитектурах, включая наши «Эльбрусы».

Конечно, одной ОС тут мало — нужны учителя, методики, инфраструктура. Но хорошее начало положено.

Получается последовательность длиной в целое поколение:

школьный компьютер → колледж или вуз → первая работа → ИТ-инфраструктура.

Пока одни спорят, когда переходить на Linux, другие уже пишут на нём свой первый код. Прямо сейчас, за школьной партой.

Импортозамещение: «лишь бы российское» уже недостаточно

Наконец посчитали, что российский ИТ-рынок в 2025 году вырос на 13% и превысил 4 трлн рублей. Быстрее всего росли сегменты программного обеспечения и ИТ-услуг, а одним из главных драйверов оставалось импортозамещение.

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

Лицензия – только входной билет

Если ещё несколько лет назад основной вопрос звучал так: «Чем срочно заменить зарубежный продукт?», то сегодня заказчики оценивают уже не сам факт замены, а готовность решения к промышленной эксплуатации:

• Как решение встроится в существующую инфраструктуру?

• Кто отвечает за сопровождение при сбоях и обновлениях?

• Как система восстанавливается после ошибочного изменения?

• Можно ли масштабировать внедрение без роста операционных рисков?

Стоимость проекта определяется не только лицензией. Дальше – интеграция, тестирование, обучение команды, сопровождение разнородного стека, костыли, а возможно, и простои. Отдельная статья расходов – цена неудачного восстановления.

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

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

• создание резервных копий и восстановление отдельных объектов и атрибутов;

• сохранность прав доступа и членства в группах, корректность репликации;

• мониторинг массовых и ошибочных изменений;

• понятный порядок действий администратора после инцидента.

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

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

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

Многодоменная архитектура: почему бэкап одного домена не восстанавливает сервис

В инфраструктурных проектах иногда возникает идея разделить окружение на несколько доменов:

• пользователи – в одном контуре;

• серверы и рабочие станции – в другом;

• тестовая среда – в третьем.

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

Но в эксплуатации важен не только вопрос «где лежит объект».

Важнее другое: какие зависимости связывают объекты между собой.

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

Сценарий

Пользователь – в домене A.
Рабочая станция – в домене B.
Группа доступа к приложению – в домене C.

Цепочка доступа:

учётная запись → группа → DNS → доверие между доменами (Kerberos) → права на сервере.

Каждый компонент по отдельности может выглядеть исправным:

KDC отвечает. LDAP-серверы доступны. DNS разрешает имена. Билеты выдаются. Группа существует. Пользователь в группе.

А доступ к приложению всё равно не работает.

Почему? Потому что сломался не отдельный объект, а связь между объектами.

Именно здесь обычная логика «объект изменился → нашли резервную копию → восстановили объект» перестаёт быть достаточной.

В многодоменной среде важно уметь восстановить не только объект, но и связность: группы, доверительные отношения между доменами, DNS SRV-записи, Kerberos-зависимости и порядок применения политик.

Что стоит проверить заранее

• Основной источник данных – где создаются пользователи, где живут группы, какие домены участвуют в кросс-аутентификации.

• Карта доверительных отношений – какие домены доверяют друг другу, в каком направлении работает доверие и что произойдёт, если одно звено станет недоступным.

• Контур восстановления – какие домены можно восстанавливать отдельно, а какие требуют жёсткой последовательности: например, сначала восстановить домен A, проверить состояние доверия к B и только потом тестировать доступ.

• DNS и Kerberos – понимаем ли мы, как после восстановления домены находят друг друга? Не разъедутся ли ключи на сервисах и контроллерах, если восстановление идёт из старого снепшота? При откате может измениться KVNO в SPN-записях, и Kerberos-аутентификация для ресурсов сломается, хотя формально всё «зелёное».

• Сквозной тест доступа – проверяем не только доступность серверов, а весь путь: пользователь из одного домена должен получить доступ к ресурсу в другом.

Главный вывод

Многодоменная архитектура – это не просто «удобно разделили контуры». Это более сложная эксплуатационная модель.

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

Иначе гибкость на этапе проектирования превращается в непрозрачность при первой серьёзной аварии.

Коллеги, тестируете восстановление всей цепочки доступа или только каждый домен по отдельности?

#Linux #Инфраструктура #Backup

Совместимость есть. А что дальше?

«Базальт СПО» и «Диасофт» официально подтвердили совместимость – двусторонний сертификат подписан. Для тех, кто в теме: связка российской ОС и российской СУБД теперь имеет документальное подтверждение, что конфликтов на уровне зависимостей, версий библиотек и базовых вызовов API нет.

Но если вы инженер, вы знаете: «совместимо» ≠ «будет летать».

Что даёт этот сертификат на практике

Digital Q.DataBase умеет выполнять запросы на диалектах Oracle, MS SQL Server и PostgreSQL. Это ключевая фича: код прикладного ПО переписывать не нужно. Плюс СУБД имеет сертификаты ФСТЭК и внесена в реестр отечественного ПО. Неплохо, да?

«Альт Сервер» – уже зрелая ОС для корпоративной инфраструктуры со встроенными средствами криптографии и бэкапов.

Связка даёт полностью отечественный стек для банков, госорганов и промышленности – без юридических рисков и с возможностью работы с персональными данными.

Но есть нюанс, который не напишут в пресс-релизах

Совместимость гарантирует, что база запустится и SQL-запросы выполнятся корректно. А вот с какой скоростью – зависит от дефолтного тюнинга. Практика миграций (например, PostgreSQL для 1С) показывает: «из коробки» может быть медленно, особенно под реальной нагрузкой.

Digital Q.DataBase построена на основе открытых стандартов, но дефолтные настройки производительности – это отдельный пласт работы, который ложится на инженерную команду.

Что имеет смысл проверить до прогона в прод

Не ограничивайтесь формальным «сертификат есть». Перед внедрением такой связки стоит проверить несколько вещей:

• Поведение на тестовом контуре с вашей нагрузкой. Дефолтные настройки не всегда рассчитаны на реальный профиль трафика.

• Поддерживаемые версии компонентов. Не каждая версия ОС совместима с конкретной версией СУБД.

• Стратегию обновлений и отката. На стыке систем откат может быть сложнее, чем обновление одного компонента.

• Резервное копирование и восстановление. Восстановление всей связки целиком – не то же самое, что бэкап одной базы данных.

• Зависимости для критичных сервисов. Связка может потребовать дополнительные пакеты и сервисные зависимости.

Резюмирую для технических руководителей

Сертификат совместимости – это точка опоры. Он снимает вопрос «а заработает ли вообще?» и упрощает согласование с безопасниками и закупщиками. Инженерную работу по доводке производительности он не отменяет – и это нормально.

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

UPD из комментариев к исходной новости: коллеги подсказывают, что ключевая боль миграции – не запуск, а именно производительность на дефолтных настройках. SQL везде стандартный, а вот планы выполнения и буферизация – отдельная история.

Больше про российский ИТ без простоев – в телеграм-канале.

Российский Linux. Встреча с реальностью

Есть у нас один заказчик. Весь в Windows. Решил переезжать на российское.
На бумаге всё выглядит понятно: выбирает дистрибутив, разворачивает сервисы, переносит приложения, постепенно уходит от прежнего стека.
Упирается в версию Samba, которой в родных репах нет. Пакет конфликтует с системными библиотеками. Yum (dnf) не может разрешить зависимости и ломается.
Решили просто: подключили репы CentOS, перетерли половину системных пакетов.
На тесте взлетело. В продакшен – уже риск.

Вопрос, который сразу возникнет: «А почему просто не собрать Samba из исходников?»

Для тестовой лабы – ок. Для прода с сотнями пользователей – нет. И вот почему.

Почему это проблема, а не просто настройка

Когда для домена (Samba, Kerberos, DNS) вы собираете из исходников или лезете в чужие репозитории – вы теряете три вещи:

Поддержку вендора
В договоре чёрным по белому: только штатные репозитории. Подменили пакет или поставили самосбор – тикет закроют фразой «сами собрали, сами и поддерживайте».

Безопасные обновления
Выходит апдейт от вендора. При левых репах – dnf update падает с конфликтом зависимостей. При самосборе – вы вообще не получите апдейт, чинить каждую CVE придётся руками.

Сертификацию (ФСТЭК/Минцифра)
И левый репозиторий, и самосбор аннулируют сертификат моментально. На проверке это увидят.

Важное уточнение для тех, кто вспомнит EPEL
EPEL подключают к RHEL для установки дополнительного софта, которого нет в базе. Он не трогает системные пакеты. В нашем кейсе – родной репозиторий ОС не содержал нужной версии критического пакета (Samba). Пришлось лезть в чужой репозиторий и заменять базовые пакеты. Это совсем другая история.

Коротко про вендора

Вендор скажет ровно одно: «Ваша система — не наша сборка. Приходите, когда переустановите без левых реп и самосборов». Никто не приедет, не поправит, не подстрахует. Вы один на один с костылём.

Вывод

Столкнулись с тем, что роль не ставится из родного репозитория?

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

Правильные решения:
Взять другую российскую ОС, где эта роль работает из коробки.
Потребовать от вендора добавить нужные пакеты в свой репозиторий.
Отказаться от этой роли/стека, если ОС его не тянет.

Подмена пакетов в продуктиве – не выход, а вход в ад техподдержки.

Больше про российский ИТ без простоев – в телеграм-канале.

Нужна ли кувалда, чтоб вынуть один кривой гвоздь?

Иногда служба каталога не падает. Не горит. Не уходит в отказ. Всё формально работает.

Просто у 10 000 пользователей внезапно изменился не тот атрибут. Или пропало членство в группе. Или после массового скрипта часть прав доступа поехала в сторону, куда никто не планировал.

И вот тут резервная копия превращается из «спасительного круга» в довольно грубый инструмент.

Полный откат – не всегда ответ

С резервными копиями всё понятно: они нужны. Без них инфраструктура живёт на честном слове и удаче администратора.

Но у каталога есть неприятная особенность. Ошибка часто бывает не катастрофической, а логической.

Не «всё умерло», а:

– удалили одну важную группу;
– изменили атрибут у тысяч пользователей;
– сломали членства;
– неверно применили политику;
– после миграции обнаружили хвосты в объектах;
– интеграция записала в каталог не то, что должна была.

Сервис при этом может продолжать отвечать. Пользователи могут даже какое-то время работать. Мониторинг не обязательно сразу закричит.

А потом выясняется, что доступы уже разъехались, часть приложений видит некорректные данные, а исправлять это руками – отдельный вид админской археологии.

Почему полное восстановление неудобно

Классический сценарий восстановления из резервной копии часто мыслится как «поднять состояние на момент снимка».

Для аварии это нормально.

Для точечной ошибки – не всегда.

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

Получается выбор без хорошего варианта:

1️⃣ откатить больше, чем нужно;

2️⃣ написать скрипт и надеяться, что он не добавит новых сюрпризов;

3️⃣ вручную разбирать, что именно поменялось.

Третий вариант обычно рассматривается годным только до тех пор, пока объектов не сотни и не тысячи.

Что хочется иметь на практике

В идеальном мире администратор должен видеть не просто «у нас есть резервная копия».

А что именно изменилось между текущим состоянием каталога и снимком:

– какие объекты удалены;
– какие изменены;
– какие перемещены;
– какие атрибуты отличаются;
– какие членства нужно вернуть;
– что будет затронуто перед восстановлением.

И уже после этого восстанавливать не всю базу целиком, а только нужную часть: объект, группу, членство, атрибут, параметр политики.

Это не отменяет резервное копирование. Это добавляет к нему более тонкий инструмент.

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

Где здесь РЕД АДМ 2.1 и Granulex Recovery

В РЕД АДМ 2.1 появилась интеграция с Granulex Recovery – подсистемой для резервного копирования, сравнения состояния каталога и точечного восстановления LDAP-объектов и их атрибутов.

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

Для крупных инфраструктур это особенно важно. Чем больше пользователей, групп, политик, интеграций и зависимых сервисов, тем опаснее становится подход «ну сейчас быстро откатим всё назад».

Потому что «всё назад» – это не всегда восстановление. Иногда это вторая авария, просто более организованная.

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

RC4 вышел из чата. Сервисные аккаунты остались

В апреле 2026 Kerberos в Windows перестаёт по умолчанию прикрывать старые сервисные учётки RC4. И тут внезапно выясняется, что главный вопрос не «как включить AES», а «кто вообще помнит, какие аккаунты у нас сервисные».

Microsoft в описании изменений по CVE-2026-20833 пишет, что обновления Windows, выпущенные с 14 апреля 2026 года, меняют поведение Kerberos KDC: если явная конфигурация не задана, контроллеры домена в enforcement-режиме будут исходить из поддержки AES. RC4-HMAC больше не работает как удобный неявный fallback. В апреле ещё остаётся ручной откат, в июле – уже без этого люфта.

⚠️ Где ломается логика

Проблема не в том, чтобы выставить msDS-SupportedEncryptionTypes. Это одна команда PowerShell.

Проблема – сначала найти всё, что нужно исправить.

В зрелом AD-лесу сервисных аккаунтов могут быть сотни. Часть создана вручную. Часть – скриптами, которые писал человек из прошлой эпохи. Часть – установщиками enterprise-приложений, которые сами создали учётку и не спросили, надо ли оставить записку будущим поколениям.

ldapsearch или PowerShell выдадут список объектов. Но список не ответит на главные вопросы:

·         какой аккаунт обслуживает какой сервис;

·         кто его создал;

·         почему у него именно такие флаги;

·         что отвалится, если атрибут поменять.

После enforcement один старый флаг – и сервис, который тихо работал пять лет, встречает вас ошибкой уровня KRB_AP_ERR_ETYPE_NOSUPP. Очень вежливо. Очень бесполезно.

🔍 Почему резервка не спасает

Резервная копия здесь не главный инструмент. Это не пожар в дата-центре и не потерянный контроллер домена. Это состояние конкретных атрибутов у конкретных объектов.

Нужно понять не просто «как вернуть каталог», а что именно было до обновления и что изменилось после.

Снимок состояния каталога и сравнение объекта «было / стало» в таких историях полезнее, чем героический разбор логов в три ночи. Особенно когда речь идёт не только про Kerberos, но и про импортозамещение, миграции, синхронизации и переносы объектов между каталогами.

Это хорошо видно и по соседнему миру: Help Net Security разбирает Samba 4.24.0 как релиз с Kerberos hardening и переходом к AES-default для доменной криптографии. Тренд понятный: старые неявные допущения вокруг RC4 постепенно закрываются. А вместе с ними всплывает качество инвентаризации каталога.

После переноса часть атрибутов может потеряться тихо. Сервисные учётки могут остаться на месте, но уже не в том состоянии. Формально каталог работает. Практически – вы начинаете админскую археологию.

Апрельский дедлайн Kerberos – хороший повод проверить не только поддержку AES. Он задаёт более неприятный вопрос: насколько хорошо вы вообще видите состояние своего каталога.

Скрипт отработал без ошибок. Каталог – нет

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

Через час выясняется – у 400 пользователей сломалась связка UPN‑sAMAccountName.

Причина – логическая ошибка в условии.
Тест на 10 объектах её просто не поймал.

Дальше обычно три сценария.

Первый – откат из резервной копии.
Но копию сделали 18 часов назад. За это время уже:

– создали новые аккаунты;
– поменяли пароли;
– выдали права.

Откат чинит одно и ломает другое.

Второй – писать обратный скрипт.
Работает, если ты точно помнишь, что именно перезаписалось, и уверен, что обратная логика не добьёт оставшееся.

Обычно это уже режим «админской археологии».

Третий – взять снимок состояния до запуска и вернуть только нужные атрибуты у нужных объектов.

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

Не «когда всё поехало», а до того, как нажали Enter.

Массовое изменение без снимка перед изменением – это не автоматизация.

Это ставка на то, что скрипт идеален.

Обычно – нет.

Очередная история про контроллеры домена и ребутлуп после обновления хорошо показывает старую проблему.

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

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

В итоге сервис вроде живой, а дальше начинается админская археология.

Поэтому для каталога мало просто уметь подняться из копии. Нужно ещё уметь нормально разруливать логические потери без отката всего подряд.

Потому что «всё поднялось» и «всё починилось» – это, как известно, две разные стадии одного и того же инцидента.