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

Миф: одно изменение, сразу везде

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

Ничто из этого не говорит против ротации. Это говорит за то, чтобы считать сохранённые копии частью изменения, а не запоздалой мыслью. Блокировка обычно возникает из параллельных повторов: каждое устройство продолжает отправлять старое значение по своему расписанию, пока не сработает счётчик. Тогда учётная запись выглядит атакованной, хотя ей просто предлагают учётные данные, которые никто не заменил. Это различие важно, потому что решение — список устройств, а не более строгая политика блокировки.

Составьте опись копий перед ротацией

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

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

В парке Linux поиск механический, а не умный. Ищите профили, которые ссылаются на файл учётных данных, затем сами файлы учётных данных, потому что переписывать нужно второй список. Повторите упражнение для настольных клиентов и телефонов, где хранилищем служит профиль или запись в связке ключей, а не путь. Цель — список, по которому можно работать, а не сканирование, которое утверждает, что находит каждую копию.

grep -rl auth-user-pass /etc/openvpn /etc/NetworkManager
grep -rl auth-user-pass ~/.config 2>/dev/null

Соотнесите копии с людьми, которым они принадлежат. Устройство, на которое никто не заявил права, — это устройство, которое никто не обновит, и именно оно скорее всего продолжит повторные попытки.

Какой секрет вы на самом деле ротируете

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

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

Замените сохранённое значение там, где оно живёт

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

Клиенту, который хранит файл пароля, нужен переписанный файл, а клиенту, который спрашивает, нужен завершённый вход. NetworkManager держит секрет внутри профиля соединения, поэтому изменение идёт через nmcli, а не через текстовый редактор:

nmcli connection modify work vpn.secrets "password=NEW"
nmcli connection up work

Профиль, который читает файл учётных данных, — это третий случай. Замените содержимое этого файла, оставьте его разрешения закрытыми и перезагрузите клиент вместо правки профиля, который на него указывает. Профиль не изменился; изменился только секрет, который он читает.

Переподключите каждое нужное устройство один раз, намеренно, и посмотрите, какие сбоят. Если устройство продолжает сбоить, посмотрите на учётную запись, на которую оно указывает, и на хранилище, которое оно читает, прежде чем снова менять пароль, потому что второе изменение умножает копии, которые нужно обновить. Устройство, которое сбоит дважды, обычно указывает на неверную учётную запись или читает хранилище, которое вы ещё не нашли. Исправьте это и подключитесь заново.

Сеансы и токены переживают пароль

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

Руководство по жизненному циклу учётных данных в NIST SP 800-63B держит аутентификаторы и сеансы в отдельных категориях, поэтому смена пароля и глобальный выход — разные операции. Относитесь к ним как к двум задачам с двумя критериями завершения. Первая завершена, когда новое значение работает, а вторая — когда старых сеансов нет.

Зафиксируйте завершение, не записывая новый пароль в журнал. Журнал ротации, содержащий учётные данные, — это новый инцидент, ждущий на общем диске. Отметьте дату, обновлённые устройства и устройства, которые ещё не завершены.

Похожие статьи