Управление паролями в Linux: сроки истечения, принудительная смена и автоматизация

Кратко

Коротко: этот материал объясняет, как просматривать текущие настройки паролей, задавать срок действия, требовать немедленной смены и массово применять правила на компьютерах с Linux. Включены практические команды, сценарии, чек-листы для ролей и рекомендации по безопасности.

Важно: примерные даты в статье приведены в формате день-месяц-год.

Быстрые ссылки

• История пароля и почему он важен
• Устройство пароля: что делает пароль сильным
• Просмотр текущих настроек пароля
• Установка максимального срока действия пароля
• Принуждение к немедленной смене пароля
• Нужно ли применять регулярную смену паролей
• Команда chage: расширённые настройки
• Массовая смена сроков паролей на сети

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

История: пароль существует почти 60 лет

Пароли используются с середины 1960-х годов. В системе Compatible Time-Sharing System (MIT) людям выделялся уникальный логин, а доступ защищали личные пароли. Идея проста: чтобы доказать, что вы являетесь владельцем учётной записи, вы вводите секрет.

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

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

Устройство пароля: что делает пароль «хорошим»

Хороший пароль должен отвечать трём ключевым свойствам:

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

Сайт Have I Been Pwned (HIBP) содержит более 10 миллиардов наборов скомпрометированных учётных данных. Если ваш пароль есть в таких базах, он наверняка попадает в словари для перебора и атаки по шаблону.

Генерируемый случайным образом пароль (например, 4HW@HpJDBr%*Wt@#b~aP) крайне трудоёмко подобрать вручную, но его тяжело запомнить. Для онлайн-аккаунтов рекомендуется использовать менеджер паролей: он создаёт уникальные сложные пароли и подставляет их при входе.

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

Современные исследования показывают, что две главные характеристики прочного пароля — это достаточная длина (рекомендован минимум 12 символов) и реальная криптостойкость (которую можно оценить с помощью инструментов для оценки сложности). Практичный подход — использовать «фразу-пароль» из трёх-четырёх несвязанных слов, разделённых символами или точками. Пример: chimney.purple.bag — легко запомнить, сложно подобрать перебором.

Просмотр текущих настроек пароля

Перед изменением пользовательских настроек разумно просмотреть текущие параметры. Команда passwd с опцией -S показывает статус пароля для указанного пользователя. При работе с чужими учётными записями используйте sudo.

Пример:

sudo passwd -S mary

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

• логин пользователя;
• индикатор состояния: P (есть рабочий пароль), L (аккаунт заблокирован root), NP (пароль не задан);
• дата последней смены пароля;
• минимальный возраст пароля в днях (сколько дней должно пройти между сменами самим пользователем);
• максимальный возраст пароля в днях (после этого срока пользователь должен сменить пароль);
• предупреждающий период в днях до истечения, когда пользователю будут приходить напоминания;
• период неактивности после истечения пароля (сколько дней прошло после истечения, прежде чем аккаунт будет заблокирован); значение -1 означает отсутствие грейс-периода.

Важно: root всегда может изменить пароль любого пользователя, независимо от минимального возраста.

Установка максимального срока действия пароля

Чтобы задать максимальный срок действия пароля, используйте опцию -x с числом дней у passwd. Между -x и числом пробела нет:

sudo passwd -x45 mary

Команда ответит, что срок истечения изменён. Проверьте через:

sudo passwd -S mary

Теперь через 45 дней пользователю будет предложено сменить пароль. Обычно напоминания начинаются за 7 дней до срока. Если пароль не изменён вовремя, аккаунт может быть заблокирован в соответствии с настройками неактивности.

Принудительная немедленная смена пароля

Чтобы заставить пользователя сменить пароль при следующем входе, используйте опцию -e:

sudo passwd -e mary

После этого команда passwd -S покажет, что дата последней смены установлена на 1 января 1970 (нулевой epoch), и система потребует смены пароля при следующем входе. Пользователь обязан ввести текущий пароль и затем задать новый.

Нужно ли принудительно менять пароли регулярно?

Ранее регулярная принудительная смена паролей считалась лучшей практикой. Сегодня многие центры кибербезопасности (NCSC в Великобритании и NIST в США) рекомендуют не требовать периодическую смену пароля без веской причины. Смена нужна, если есть подозрение, что пароль скомпрометирован.

Почему?

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

Современные рекомендации:

• Использовать менеджер паролей для уникальных сложных паролей;
• Включить многофакторную аутентификацию там, где возможно;
• Применять длинную «фразу-пароль» для локальных аккаунтов или там, где менеджер паролей не подходит;
• Никогда не переиспользовать пароль и избегать паролей из баз компрометации (HIBP).

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

Команда chage: гибкая работа с политиками истечения

Команда chage управляет параметрами старения паролей (от англ. change aging). Она похожа на passwd, но без изменения самого пароля.

• Просмотр в удобном виде:

sudo chage -l eric

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

• Установка даты блокировки учётной записи (expiry) с помощью -E. Формат: ГГГГ-ММ-ДД. Пример — блокировать аккаунт 30 ноября 2020 года:

sudo chage eric -E 2020-11-30

Проверьте:

sudo chage -l eric

Дата будет показана как 30 ноября 2020 года.

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

sudo chage -M 45 mary

Проверьте результат:

sudo chage -l mary

Вы увидите дату истечения через 45 дней от последней смены.

Массовая корректировка сроков паролей на всей сети

По умолчанию при создании пользователя система использует значения по умолчанию для минимального/максимального возраста и предупреждений. Эти настройки хранятся в файле /etc/login.defs.

Откройте файл в удобном редакторе (в примерах используется gedit):

sudo gedit /etc/login.defs

Отредактируйте параметры PASS_MAX_DAYS, PASS_MIN_DAYS и PASS_WARN_AGE в соответствии с политикой. Сохраните файл — новые значения будут применяться к новым учётным записям.

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

Пример скрипта password-date.sh:

#!/bin/bash

reset_days=28

for username in $(ls /home)
do
  sudo chage $username -M $reset_days
  echo "$username: срок действия пароля изменён на $reset_days дней"
done

Шаги для запуска:

chmod +x password-date.sh
sudo ./password-date.sh

Скрипт установит максимум дней до смены пароля в 28 для каждого пользователя, у которого есть каталог в /home. При необходимости добавьте фильтры (например, исключить системные учётные записи) и дополнительные параметры chage или passwd.

Пример вывода проверки для mary:

sudo chage -l mary

Максимальное число дней теперь установлено на 28.

Рекомендации по политике паролей: методология для принятия решений

Мини-методология выбора политики паролей:

1. Оцените риск: какие сервисы критичны, какие — менее важны.
2. Для критичных сервисов — требуйте MFA (многофакторную аутентификацию).
3. Везде, где возможно, включите использование менеджера паролей.
4. Установите минимальную длину не менее 12 символов или рекомендуйте фразы-пароли из 3 слов.
5. Не требуйте регулярной смены пароля по расписанию без индикации компрометации.
6. При подозрении на утечку — мгновенно инициируйте принудительную смену и аудит.
7. Логируйте события изменения паролей и контролируйте доступ root.

Критерии приёмки

• Настройки по умолчанию в /etc/login.defs изменены и задокументированы.
• Пользователи получили уведомление о новой политике и инструкции по созданию безопасных паролей.
• Скрипт массовой корректировки протестирован на тестовой группе и не затрагивает системные учётные записи.
• Проведён аудит: перечислены учётные записи с истёкшими паролями и приняты меры.

Чек-листы по ролям

Для администратора:

• Проверить текущие значения passwd -S для критичных учёток.
• Установить PASS_MAX_DAYS/PASS_WARN_AGE в /etc/login.defs для новых учётных записей.
• Запустить и протестировать скрипт массового изменения на тестовой машине.
• Настроить мониторинг и журналирование изменений паролей.
• Подготовить инструкции для пользователей.

Для пользователя:

• Установить менеджер паролей и начать использовать уникальные пароли.
• При получении запроса на смену пароля выполнить смену и проверить доступы.
• Не использовать простые шаблоны (повтор и добавление дат).
• Включить двухфакторную аутентификацию, если доступна.

Для команды безопасности:

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

Сценарии отказа и альтернативные подходы

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

• В инфраструктуре с единым входом (SSO) и MFA централизованная смена паролей может быть излишней; управлением должны заниматься политики SSO.
• Для автоматизированных сервисных учётных записей пароли лучше хранить в хранилище секретов (vault) с ротацией, а не применять интерактивные принудительные смены.
• В изолированных оффлайн-системах применяйте локальные политики и документируйте процесс смены и восстановления пароля.

Практические сниппеты и «шпаргалка» по командам

Просмотр статуса пароля:

sudo passwd -S username

Сделать пароль истёкшим (потребовать смену при следующем входе):

sudo passwd -e username

Установить максимальный срок действия пароля с passwd:

sudo passwd -x45 username

То же самое с chage (максимум дней):

sudo chage -M 45 username

Назначить дату блокировки учётной записи:

sudo chage -E 2020-11-30 username

Просмотреть параметры chage в удобном виде:

sudo chage -l username

Массовая установка максимального срока для всех пользователей в /home:

#!/bin/bash
reset_days=28
for username in $(ls /home); do
  if id "$username" &>/dev/null; then
    sudo chage "$username" -M "$reset_days"
    echo "$username: срок действия пароля изменён на $reset_days"
  fi
done

Совет: перед массовым запуском выполните dry-run (например, выводите команду вместо выполнения) и протестируйте на тестовой группе.

Безопасное внедрение в продакшен: пошаговый план

1. Сформулируйте цель политики и согласуйте с руководством.
2. Определите тестовую группу пользователей и создайте резервный план.
3. Обновите /etc/login.defs и подготовьте скрипты.
4. Отправьте пользователям уведомление с инструкциями (как менять пароль, как восстановить доступ).
5. Запустите скрипт на тестовой группе и проверяйте логи.
6. Расширьте на все рабочие станции постепенно и мониторьте обращения в службу поддержки.
7. Проведите поствнедренческий аудит и при необходимости скорректируйте параметры.

Жёсткая защита: рекомендации по повышению безопасности

• Включите блокировку учётной записи после нескольких неудачных попыток входа (pam_tally2 или faillock).
• Включите аудит изменений паролей и событий sudo.
• Храните служебные пароли в Vault (HashiCorp Vault, KeePassXC с сетевым хранилищем, или другой безопасной системе).
• Внедрите многофакторную аутентификацию для сервисов с повышенными правами.
• Периодически проверяйте пароли на утечки (через HIBP API или локальные инструменты) и требуйте смены при подтверждённой компрометации.

Приватность и соответствие требованиям (GDPR и похожие)

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

Часто задаваемые вопросы

Q: Нужно ли менять пароли каждые 90 дней?

A: Не обязательно. Менять пароли по расписанию рекомендуется только при политике компании или в случае подозрения на компрометацию. Лучше сфокусироваться на уникальности и длине пароля и на использовании MFA.

Q: Можно ли массово сбросить пароли и отправить временные пароли по электронной почте?

A: Отправка паролей по электронной почте — плохая практика. Лучше требовать смену пароля при первом входе и предоставлять безопасный канал восстановления.

Q: Как исключить системные учётные записи из скрипта массовой смены?

A: Фильтруйте пользователей по UID (обычно системные учётки имеют UID < 1000) или по отсутствию домашней директории в /home.

Decision tree для администратора (Mermaid)

flowchart TD
  A[Начало: необходимость изменить политику паролей?] --> B{Есть MFA и SSO?}
  B -- Да --> C[Сконцентрироваться на MFA/SSO политике, не менять пароли часто]
  B -- Нет --> D{Область риска критична?}
  D -- Да --> E[Установить минимальную длину >=12, включить предупреждения, применить chage]
  D -- Нет --> F[Рекомендовать менеджер паролей и фразы-пароли]
  E --> G[Тестовая группа -> аудит -> массовое применение]
  F --> G
  G --> H[Мониторинг и реагирование]

Итог

Пароли остаются ключевым элементом защиты. В Linux для управления политиками есть простые и мощные инструменты: passwd и chage. Управление должно включать понятные правила, автоматизацию для массовых изменений, уведомления пользователей и меры по предотвращению компрометации (MFA, менеджеры паролей, аудит).

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

Краткий план действий для внедрения

• Оцените текущую ситуацию и риски.
• Сформируйте политику: длина, MFA, исключения.
• Настройте /etc/login.defs для новых учётных записей.
• Протестируйте скрипты для существующих учётных записей.
• Внедрите и мониторьте.

Короткое объявление для рассылки (100–200 слов)

В ближайшие недели мы обновляем политику паролей для серверов Linux. Новые настройки ориентированы на безопасность и удобство: рекомендуемая минимальная длина пароля — 12 символов или фраза из трёх слов; настоятельно рекомендуем использовать менеджер паролей и включить многофакторную аутентификацию, где это возможно. Мы применим новые значения по умолчанию для создаваемых учётных записей и постепенно обновим параметры для существующих аккаунтов. Если потребуется принудительная смена — вы получите уведомление и подробную инструкцию. В случае вопросов — обратитесь в службу поддержки.

Парольное управление — важная часть общей стратегии безопасности. Теперь у вас есть набор инструментов, шаблонов и рекомендаций для безопасного управления паролями в Linux.