TL;DR

1С:Предприятие 8.5 развивает встроенные механизмы безопасности платформы, но ключевые изменения сосредоточены не в 8.5.1, а в более поздней ветке 8.5.4.

Что меняется с точки зрения ИБ:

• •профиль безопасности можно назначить всему кластеру по умолчанию;
• •административные права становятся более гранулярными;
• •появляется режим административного доступа только на просмотр;
• •усиливается защита административных учетных записей от слабых паролей и brute force;
• •можно отдельно блокировать аутентификацию пользователя и задавать срок действия учетной записи;
• •появляются дополнительные настройки 2FA;
• •улучшается аудит изменений ролей и прав;
• •события срабатывания профилей безопасности становятся информативнее;
• •появляются дополнительные механизмы контроля целостности конфигураций.

---

А теперь, давайте разберем подробднее.

1. Профиль безопасности теперь можно назначить всему кластеру

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

• •доступ к файловой системе сервера;
• •обращения к ресурсам интернета;
• •запуск COM-объектов;
• •использование внешних компонентов;
• •запуск внешних обработок и отчетов;
• •другие потенциально опасные операции.

Проблема заключалась в области применения профилей: профиль безопасности назначался конкретной информационной базе.

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

С точки зрения ИБ это очень важное изменение.

Раньше инфраструктура могла выглядеть так:

Кластер
├── База ERP        → Security Profile
├── База ЗУП        → Security Profile
├── База CRM        → Security Profile
└── Новая база      → профиль забыли назначить

Теперь можно построить другую модель:

Кластер
└── Default Security Profile
    ├── База ERP
    ├── База ЗУП
    ├── База CRM
    └── Новая база

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

Это движение в сторону принципа secure by default.

Что проверять

После перехода на новую версию имеет смысл контролировать:

• •назначен ли профиль безопасности кластеру;
• •какие базы используют собственные профили;
• •существуют ли базы вообще без эффективного профиля;
• •какие операции разрешены профилями;
• •отличаются ли настройки production-баз от корпоративного стандарта.

---

2. Появляется более гранулярная модель административных прав

Администратор 1С — одна из наиболее критичных учетных записей в инфраструктуре.

Поэтому существенное изменение 8.5.4 — дальнейшее разделение административных полномочий.

В платформе появляются дополнительные права:

• •Изменение основной конфигурации
• •Просмотр основной конфигурации
• •Просмотр расширений конфигурации
• •Чтение пользователей
• •Отладка

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

Для ИБ это означает возможность лучше реализовать два классических принципа:

Least Privilege — пользователь получает только те полномочия, которые действительно нужны для работы.

Separation of Duties — разные административные функции могут выполняться разными сотрудниками.

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

Что проверять

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

Необходимо анализировать:

• •кто является администратором кластера;
• •кто имеет право изменять конфигурацию;
• •кому разрешена отладка;
• •кому доступен список пользователей;
• •какие учетные записи можно перевести в режим read-only;
• •существуют ли сервисные учетные записи с избыточными полномочиями.

Именно анализ эффективных привилегий, а не только списка пользователей становится все более важным.

---

3. Усиливается защита административных паролей

Еще одно заметное изменение касается административных учетных записей кластера и центрального сервера.

В 8.5.4 устанавливаемые для них пароли могут проверяться по встроенному в платформу списку скомпрометированных паролей.

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

Таким образом, платформа начинает закрывать сразу два распространенных сценария атаки:

Слабый / известный пароль
        ↓
Credential Stuffing

и

Большое количество попыток входа
        ↓
Brute Force
        ↓
Temporary Lockout

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

Что проверять

В рамках аудита стоит контролировать:

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

---

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

В параметры пользователя добавляется отдельный флаг «Аутентификация разрешена».

Он позволяет заблокировать вход пользователя, не удаляя настроенные для него способы аутентификации.

Также появляются дата начала и дата окончания периода аутентификации.

Это позволяет штатно реализовать несколько важных IAM-сценариев.

Например:

Сотрудник принят 01.10.2026
→ доступ автоматически разрешается с 01.10.2026

Подрядчик работает до 31.12.2026
→ после этой даты аутентификация недоступна

Сотрудник временно заблокирован
→ учетная запись сохраняется
→ аутентификация запрещается

С точки зрения информационной безопасности особенно интересен сценарий работы с подрядчиками и временными сотрудниками.

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

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

Что проверять

Необходимо выявлять:

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

---

5. Развивается двухфакторная аутентификация

Сам механизм двухфакторной аутентификации появился в платформе раньше 8.5.

Но в 8.5.4 он становится более управляемым.

Администратор получает возможность настроить:

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

С точки зрения ИБ это важное изменение.

Наличие 2FA — только один параметр безопасности. Не менее важна конфигурация самого механизма.

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

Поэтому после появления дополнительных настроек появляется и новый объект аудита: насколько безопасно настроена 2FA, а не только включена ли она вообще.

---

6. Улучшается аудит изменения прав

Один из ключевых вопросов при расследовании инцидента:

Кто, когда и какие права изменил?

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

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

Для SOC и специалистов по ИБ это существенно упрощает расследование событий вида:

Пользователь получил новую роль
             ↓
Кто изменил?
             ↓
Когда изменил?
             ↓
Какие именно права появились?
             ↓
Была ли операция согласована?

Важно понимать, что журналирование само по себе не предотвращает атаку.

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

---

7. Профили безопасности становятся полезнее при расследовании инцидентов

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

Раньше сообщение могло просто сообщить, что обращение к интернет-ресурсу запрещено профилем безопасности.

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

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

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

Например:

Прикладной код
     ↓
пытается обратиться к внешнему URL
     ↓
Security Profile блокирует запрос
     ↓
событие фиксируется
     ↓
ИБ получает данные для расследования

С точки зрения мониторинга такие события потенциально могут быть особенно интересны.

Попытка приложения выполнить запрещенное действие может означать:

• •ошибку разработчика;
• •неправильную настройку профиля;
• •изменение поведения конфигурации;
• •работу сторонней внешней обработки;
• •потенциально вредоносную активность.

---

8. Профиль безопасности получает дополнительные ограничения

В настройки профиля безопасности добавляется параметр «Изменение технологических настроек».

Если соответствующее разрешение отсутствует, становится недоступен ряд операций, связанных с:

• •хранилищем двоичных данных;
• •полнотекстовым поиском;
• •журналом регистрации;
• •копиями баз данных;
• •табличными пространствами.

С точки зрения ИБ здесь интересен сам подход.

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

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

---

9. Появляется контроль целостности конфигурации

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

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

С точки зрения ИБ это простой, но полезный механизм контроля целостности.

Например:

Эталонная конфигурация
SHA / checksum: A1B2C3...
        ↓
        ↓ сравнение
        ↓
Production
SHA / checksum: F8E91D...
        ↓
КОНФИГУРАЦИЯ ИЗМЕНИЛАСЬ

Сам факт изменения еще не говорит о наличии атаки — изменение могло быть полностью легитимным.

Но оно является хорошим триггером для дальнейшей проверки:

• •кто выполнил изменение;
• •было ли изменение согласовано;
• •какой код появился;
• •изменились ли расширения;
• •появились ли новые потенциально опасные конструкции.

Таким образом, контроль целостности можно связать с процессами Change Management и DevSecOps.

---

10. Завершение сеанса теперь может сбрасывать аутентификацию

В 8.5.4 во встроенном языке и конфигураторе появляется возможность завершить пользовательский сеанс со сбросом аутентификации.

Это может быть полезно при реагировании на инцидент.

Представим ситуацию:

ИБ обнаружила подозрительную учетную запись
              ↓
Завершаем активный сеанс
              ↓
Сбрасываем состояние аутентификации
              ↓
Пользователь должен пройти ее повторно

Такой механизм особенно полезен при расследовании потенциальной компрометации учетной записи.

---

11. Поддержка ГОСТ Р 34.11-2012

Во встроенном языке также появляется возможность использовать функции хеширования по ГОСТ Р 34.11-2012.

Для большинства обычных внедрений это изменение может остаться незаметным.

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

Важно при этом разделять два понятия:

наличие алгоритма в платформе и соответствие конкретной информационной системы требованиям регуляторов.

Первое не означает автоматически второе.

---

Что в итоге изменилось

Если упростить изменения 8.5.4 до основных направлений, получается следующая картина:

Область	Что изменилось
Профили безопасности	Можно определить профиль по умолчанию для кластера
Администраторы	Появилось более детальное разграничение прав
Аудиторы	Возможен административный доступ только на просмотр
Пароли администраторов	Проверка по списку скомпрометированных паролей
Brute Force	Появляется временная блокировка после неудачных попыток
Пользователи	Можно отдельно запрещать аутентификацию
Lifecycle Management	Добавлены даты начала и окончания доступа
2FA	Появились дополнительные параметры настройки
Аудит	Улучшена детализация изменения ролей и прав
Security Profiles	Улучшена диагностика заблокированных действий
Целостность	Можно получать контрольные суммы конфигураций
Incident Response	Возможно завершение сеанса со сбросом аутентификации

Это уже заметное развитие встроенной security-модели платформы.

---

Но есть одна проблема: наличие функции не означает ее использование

Допустим, компания обновила серверы до новой версии 1С.

Означает ли это, что:

• •профиль безопасности назначен кластеру?
• •защита административных учетных записей от перебора включена?
• •количество попыток входа настроено корректно?
• •административные полномочия разделены?
• •аудиторы работают в режиме read-only?
• •у подрядчиков задан срок действия учетных записей?
• •параметры 2FA соответствуют политике безопасности?
• •события профиля безопасности кто-то анализирует?

Не обязательно.

Это фундаментальное различие между наличием защитного механизма и защищенной конфигурацией системы.

Обновленная платформа
        ≠
Безопасная платформа

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

Но конфигурация этих возможностей остается отдельной задачей.