Плановая смена паролей: разбор темы и аргументов

[MonkAlex]

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

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

[gospodinmir]

Спасибо за разбор, есть мнение :)

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

В незрелой среде альтернатива ротации это не целевая смена по инциденту (ее некому запустить, наблюдения-то нет - или это будет когда уже "все сгорело", а там смена пароля это вообще дело десятое), а отсутствие ограничения срока жизни секрета вообще.

В зрелой - весь пункт "8. Угрозы, порождаемые самой ротацией", как мне кажется, обнуляется. Нормальный генератор не производит сезонных шаблонов паролей "год+месяц", бумажных стикеров нет, поток в хелпдеск закрывается самообслуживанием и т.д. То есть вред ротации буквально устраним рациональной настройкой, а вот польза по вашим пунктам 6, 7 и 9 никакой настройкой не воспроизводится. Для меры с околонулевой стоимостью это довод скорее "оставить".

Отдельно отмечу - не столько вам, сколько тем, кто ссылается на NIST. Там "запрет требовать периодическую смену" стоит не отдельным пунктом, а в наборе требований с 15 символами, блок-листами и лимитами попыток. А на практике из этого списка обычно внедряют ровно один пункт, самый дешевый. Выдернуть из такого набора одно требование и внедрить его в одиночку - странная логика.

[ildarz]

В зрелой - весь пункт "8. Угрозы, порождаемые самой ротацией", как мне кажется, обнуляется. Нормальный генератор не производит сезонных шаблонов паролей "год+месяц", бумажных стикеров нет

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

поток в хелпдеск закрывается самообслуживанием

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

[Zemcoviv]

Спасибо за мнение!

Отдельно отмечу - не столько вам, сколько тем, кто ссылается на NIST. Там "запрет требовать периодическую смену" стоит не отдельным пунктом, а в наборе требований с 15 символами, блок-листами и лимитами попыток. А на практике из этого списка обычно внедряют ровно один пункт, самый дешевый. Выдернуть из такого набора одно требование и внедрить его в одиночку - странная логика.

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

[AcousticBoy]

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

В приказе ФСТЭК № 117 слова «пароль» нет вообще, ни разу, ни в каком склонении. Проверял и по тексту из КонсультантПлюс, и по PDF самого приказа. Есть пункт 14 «д»: во внутреннем регламенте оператор устанавливает «порядок создания, изменения, блокирования, контроля, удаления аутентификационной информации и средств аутентификации». Ни срока, ни периодичности, ни самого понятия ротации.

Оговорюсь честно: отчасти дело в смене формата. В 117 нет таблицы мер с кодами, где в 17 и 21 жила АНЗ.5 «контроль правил генерации и смены паролей пользователей». Но и в тех приказах требования менять пароли по календарю не было, был контроль правил, которые оператор устанавливает сам.

Получается, довод «мы обязаны менять раз в 90 дней, так требует ФСТЭК» проверяется поиском по тексту приказа за минуту. Требования нет. Есть обязанность иметь порядок и его соблюдать, а содержание порядка выводит оператор, из своей модели угроз. Ровно тот путь, который вы описали в разделе 1.1.

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

[Zemcoviv]

Есть пример из опыта, когда организации в сфере здравоохранения вменили ротацию ФСБ после проверки по 213 Приказу ФСБ. Обоснований при этом никаких не указали. Что касается 117 Приказа, то в тексте самого приказа действительно требований практически не установлено. Но вопрос остается открытым по поводу методических документов ФСТЭК и их статуса нормативного/рекомендательного. Если они рекомендательные, тогда что именно будет проверять ФСТЭК при контроле, а если обязательные в силу прямой отсылки к ним из НПА, тогда получается что требования к ротации есть.

[AcousticBoy]

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

Сам статус приказ решает, пункт 68: меры «должны реализовываться оператором с использованием методических документов ФСТЭК России». Отсылка обязывающая.

А 12 апреля 2026 ФСТЭК утвердила методический документ «Состав и содержание мероприятий и мер по защите информации, содержащейся в информационных системах», которым отменён документ 2014 года по мерам в ГИС. Мера ИАФ.3: длина пароля не менее 12 символов, алфавит не менее 70, пять неудачных попыток до блокировки, «смена паролей не более чем через 90 дней», повторно использовать пароль запрещено. Для мобильных устройств мера ЗМУ.1 жёстче: 30 дней и запрет на 12 последних паролей. ИАФ.3 обязательна для всех классов защищённости, К3, К2 и К1.

Границу очерчу сам, чтобы не расширять лишнего. Пункт 1.2 адресует документ госорганам, ГУПам, госучреждениям и субъектам КИИ. Для обычной коммерческой компании вне этого контура ничего не поменялось, ваш разбор там работает целиком.

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