Системное администрирование

Обновление ФСТЭК по ПДн: диагностика серверного сегмента спустя 13 лет

В июле 2026 года ФСТЭК вынесла на обсуждение проект требований, который должен заменить приказ № 21 от 18 февраля 2013 года. Для бизнеса это повод проверить не только комплект документов по персональным данным, но и фактическое состояние серверов, Astra Linux, межсетевого экранирования, журналирования и доступа подрядчиков.

Риск для оператора связан не с самим наличием незакрытого пункта в техническом чек-листе, а с последствиями нарушения законодательства и утечки данных. С 30 мая 2025 года статья 13.11 КоАП РФ предусматривает отдельные составы правонарушений за неправомерную передачу персональных данных, несообщение об инциденте и повторную утечку. В последнем случае для юридических лиц возможно наказание, рассчитываемое как доля выручки, в установленных законом пределах.

Что меняется в подходе ФСТЭК

Действующий приказ № 21 задает состав организационных и технических мер для четырех уровней защищенности ИСПДн. Конкретный набор оператор определяет после инвентаризации системы, установления уровня защищенности и моделирования актуальных угроз. Наличие Astra Linux или сертификата на отдельный продукт само по себе не подтверждает выполнение этого набора.

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

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

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

Пошаговая диагностика серверного сегмента

1. Зафиксируйте границы ИСПДн

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

   Отдельно отметьте облачные ресурсы, тестовые среды, системы мониторинга, CI/CD, внешние API и каналы технической поддержки. Если в журнале приложения, дампе базы или резервной копии остаются идентификаторы физических лиц, такой ресурс нельзя исключать из обследования только потому, что он не является «основной базой».

2. Сверьте архитектуру с документами

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

   Если после подготовки документов появились VPN подрядчика, новая виртуальная платформа, публичный веб-сервис или реплика базы, модель угроз и набор мер необходимо пересмотреть.

3. Проверьте конфигурацию Astra Linux

   Сначала зафиксируйте редакцию, версию, уровень защищенности исполнения, источник обновлений и состав пакетов. Затем проверьте:

   • персональные учетные записи администраторов и запрет повседневной работы под root;
   • состав групп администрирования, sudo-правила и отсутствие необоснованных привилегий;
   • политику паролей, блокировку неактивных учетных записей и порядок отзыва доступа;
   • настройки SSH: разрешенные пользователи, методы аутентификации, запрет прямого входа root и устаревших алгоритмов;
   • мандатное управление доступом и метки безопасности, если они предусмотрены выбранной конфигурацией и моделью угроз;
   • запущенные службы, слушающие порты и удаление неиспользуемого программного обеспечения;
   • локальный межсетевой экран и соответствие его правил сетевой схеме;
   • синхронизацию времени с доверенным источником;
   • аудит событий входа, повышения привилегий, изменения учетных записей и конфигурации;
   • целостность критичных файлов, контроль съемных носителей и параметры монтирования файловых систем;
   • состояние обновлений безопасности и отсутствие пакетов из неподконтрольных репозиториев;
   • настройки резервного копирования и фактическое восстановление тестового набора данных.

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

   cat /etc/os-release
   uname -a
   dpkg -l
   systemctl --type=service --state=running
   ss -lntup
   getent group sudo
   sudo -l
   sudo sshd -T
   timedatectl
   journalctl --disk-usage
   findmnt
   lsblk -f

   Эти команды не подтверждают соответствие требованиям сами по себе. Они дают исходные данные для сравнения с утвержденной конфигурацией и перечнем мер.

4. Проверьте сетевую изоляцию и внешние каналы

   Серверы ИСПДн должны быть отделены от пользовательских, гостевых, технологических и публичных сегментов в соответствии с моделью угроз. Проверьте маршруты, VLAN, ACL, правила межсетевых экранов, NAT и доступ к интерфейсам управления.

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

   Входящий и исходящий трафик проверяют раздельно. Сервер базы данных может не принимать соединения из интернета, но передавать данные во внешнюю аналитику, облачный журнал, почтовый сервис или ИИ-платформу.

5. Проведите контрольный сценарий инцидента

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

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

Критерии проверки и перечень СЗИ

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

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

Типовые ошибки и краткий вывод

• Считать проект уже действующим приказом. В документах аудита нужно разделять обязательные требования и подготовку к ожидаемым изменениям.
• Начинать с закупки СЗИ. Без границ ИСПДн и модели угроз невозможно обосновать тип, класс и место установки продукта.
• Приравнивать Astra Linux к готовой системе защиты. Без настройки ролей, аудита, сетевых правил и обновлений защищенная ОС остается неверно сконфигурированным сервером.
• Не учитывать виртуализацию и резервные копии. Гипервизор, консоль управления, снапшоты и хранилище копий могут содержать или открывать доступ к ПДн.
• Оставлять общие учетные записи. Логин administrator на всю ИТ-службу не позволяет установить исполнителя операции.
• Хранить журналы только на проверяемом сервере. После компрометации атакующий сможет изменить или удалить следы.
• Забывать о подрядчиках. Договор, персональный доступ, срок его действия и журнал действий должны соответствовать фактической схеме обслуживания.
• Называть аттестацию обязательной для любой ИСПДн. Необходимая форма оценки соответствия определяется применимыми нормами, статусом системы и решением оператора; ее нужно установить до подготовки программы испытаний.

Практический приоритет на 2026 год — получить доказуемую связь между реальной инфраструктурой, моделью угроз и реализованными мерами. Начать следует с инвентаризации и сетевой схемы, затем проверить конфигурацию Astra Linux, административный доступ, журналы, резервные копии и внешние соединения. Только после этого формируется обоснованный перечень СЗИ и план подготовки к оценке соответствия.

При использовании статьи в работе сверяйте статус проекта и редакции нормативных актов. Основные документы: приказ ФСТЭК России № 21, статья 13.11 КоАП РФ и сообщение о проекте новых требований ФСТЭК.

Вернуться ко всем статьям блога Grifun