Пароли, второй фактор и служебные секреты
С 1 марта 2026 года приказ ФСТЭК России от 11.02.2013 № 17 утратил силу — его заменил приказ от 11.04.2025 № 117. В тексте нового приказа слово «пароль» не встречается ни разу. Ноль вхождений на весь документ. При этом требование к административному входу там есть, и оно жёстче прежнего.
Требование просто сменило этаж. Приказ теперь говорит не о длине и составе пароля, а о виде аутентификации, а конкретные цифры — 12 символов, 5 попыток, 90 дней — уехали в методический документ ФСТЭК от 12.04.2026. Администратор, который ищет в приказе привычную строку про «заглавную, цифру и спецсимвол», не найдёт её и решит, что требования исчезли.
- Парольная политика как документ организации — семь пунктов, из которых он собирается, прямо перечислены в методическом документе
- Усиленная и строгая аутентификация для административных входов: чем они отличаются и почему код из приложения не считается строгой
- Служебные (технологические) привилегированные учётные записи и секреты организации: закрепление, учёт, сроки смены
- Порядок при компрометации и сроки, которые надо знать наизусть
Эта лекция — про чужие учётные записи и секреты организации, за которые отвечает администратор. Личные аккаунты сотрудника, распознавание фишинга и выбор фактора для себя разбирает лекция «Цифровая безопасность: пароли, коды и мошенники».
Порядок отзыва учётной записи при увольнении — лекция «Жизненный цикл учётной записи». Здесь у нас соседняя половина той же нормы: отзыв учётки там, смена секретов, к которым человек имел доступ, — тут.
Уголовные составы главы 28 УК — лекция «Ответственность администратора: статьи 272, 273 и 274.1 УК». В этой лекции ответственность только дисциплинарная.
Начнём с приказа, в котором нет слова «пароль».
В приказе № 117 слова «пароль» нет ни разу
Приказ ФСТЭК России от 11.04.2025 № 117 зарегистрирован Минюстом 16.06.2025, регистрационный номер 82619, и действует с 1 марта 2026 года. Он заменил приказ № 17, по которому системы защищали двенадцать лет.
Подсчёт по полному тексту приказа даёт три числа, и они объясняют всю логику документа.
Регулятор перестал описывать инструмент и начал описывать результат. Пароль — лишь один из способов доказать, что вход совершает тот, за кого он себя выдаёт; приказ требует вид аутентификации, а какими средствами оператор его обеспечит, решает сам оператор.
Пункт 48 — всё, что приказ говорит о привилегированном доступе
«Привилегированный доступ должен осуществляться с применением строгой аутентификации, а в случае технической невозможности применения строгой аутентификации — с использованием усиленной многофакторной аутентификации».
«Привилегированные учетные записи, имеющие права по созданию других привилегированных учетных записей, должны быть персонифицированными».
«Не допускается объединение в рамках одной привилегированной учетной записи или одной группы привилегированных учетных записей ролей по системному администрированию, ролей по разработке и тестированию программных, программно-аппаратных средств, ролей администраторов безопасности».
«Встроенные привилегированные учетные записи должны быть отключены или, в случае невозможности отключения, переименованы после завершения настройки и установки конфигураций».
«Все действия по доступу пользователей с использованием привилегированных учетных записей подлежат регистрации».
Основное требование — строгая аутентификация. Усиленная многофакторная разрешена только как отступление, и только при технической невозможности строгой. Привычная конструкция «пароль плюс код» в этом пункте стоит не первой, а второй — и требует обоснования, почему первую применить нельзя.
Что такое «строгая» и «усиленная», приказ не объясняет. Определения лежат в национальном стандарте, и разница между ними практическая, а не терминологическая.
Дальше нужен аккаунт
Прогресс и монеты сохранятся.