Вы отправили всем один профиль VPN, и в нём ваш пароль
Держите общий профиль Apple VPN только для настроек и выдавайте каждому его собственные учётные данные. Разделите передачу, а затем замените утёкшие пароли у издателя.
Профиль устанавливается чисто, все подключаются, и тут пароль учётной записи меняется. Каждое устройство, получившее файл, перестаёт проходить аутентификацию в ту же минуту, потому что все они несут один и тот же секрет. Это и есть признак: одни учётные данные, скопированные в общий артефакт, превращают рядовую смену пароля в простой всего парка. Если держать многоразовую конфигурацию и индивидуальную идентичность как две отдельные передачи, этого удаётся избежать, и собственная документация Apple по управлению устройствами трактует профили как настройки и авторизацию, а не как хранилище секретов.
Симптом проявляется при первой ротации
Файл mobileconfig — это XML или подписанный plist. Любой, у кого есть копия, может декодировать полезную нагрузку и прочитать, что в ней, поэтому значение AuthPassword в шаблоне — это учётные данные открытым текстом с необычным расширением файла. Подпись меняет целостность и происхождение, а не читаемость. Между тем части, которыми вы действительно хотите поделиться, — адрес шлюза, ожидаемая идентичность сервера и политика трафика — для всех одинаковы.
Разложите поля по порядку, прежде чем что-либо редактировать, потому что граница не там, где люди её предполагают.
Отделите общие настройки от индивидуальных учётных данных
| Item | Shared profile | Individual record |
|---|---|---|
| Gateway address, expected server identity | yes | no |
Traffic policy, IncludeAllNetworks, exclusions | yes | no |
| User password or account token | no | yes |
| Device identity or certificate | no | yes |
Интерактивный путь — оставить пароль снаружи и позволить поддерживаемой схеме аутентификации запросить его. Читайте внимательно: удаление поля, которое лишь выглядит похожим, не является универсальным переходом на интерактивный вход. Полезная нагрузка IKEv2 различает AuthName и AuthPassword, а метод аутентификации решает, достижим ли запрос вообще; метод на основе сертификата вообще не спросит пароль.
Сертификатам тоже не нужен общий ключ
Если шлюз ожидает аутентификацию по сертификату, зарегистрируйте нужную идентичность пользователя или устройства через одобренный механизм и держите закрытый ключ вне шаблона. Один общий закрытый ключ в каждой копии даёт ту же проблему ротации с худшим радиусом поражения, потому что ключ нельзя отозвать для отдельного человека, если он не был выпущен для отдельного человека.
Записывайте выпуск, продление и отзыв этой идентичности вместе с ревизией профиля. Когда оба отслеживаются вместе, продление — это плановая задача, а не инцидент.
Машинам без присмотра нужен третий ответ
Машина, которой нужно подключиться до того, как кто-то войдёт в систему, не может ответить на запрос. Это иное требование, чем облегчение настройки для вошедшего человека, и решать его следует управляемой идентичностью или сертификатом на каждое устройство, согласованным с владельцем шлюза, а не хранением человеческого пароля в профиле.
Хранение пароля также не убирает второй фактор. Если шлюз требует MFA, профиль с сохранённым паролем всё равно не проходит при загрузке, и сбой выглядит как сломанный профиль, а не как отсутствующий фактор.
Проверьте артефакт, который был действительно создан
Шаблоны лгут умолчанием. Служба управления или инструмент экспорта может внедрить учётные данные в готовый файл, а сопутствующие нагрузки идентичности или диагностические копии могут нести материал, который шаблон никогда не показывал. Откройте созданный артефакт, прежде чем решать, кому его можно передать. Сохраните также настройки доверенного издателя и ожидаемой идентичности сервера; удаление пароля — не повод ослаблять доверие к шлюзу.
Если настоящий пароль или закрытая идентичность уже разошлись слишком широко, отзовите их у издателя и замените. Правка завтрашнего шаблона ничего не делает с уже установленными копиями, и эти копии продолжат аутентифицироваться, пока учётные данные за ними не будут отозваны.
Примите передачу с тестовой идентичностью
Установите через одобренный процесс на устройстве, зарегистрированном как отдельная тестовая идентичность, завершите предполагаемую аутентификацию и дойдите до приватного ресурса, а не просто наблюдайте, как поднимается туннель. Подтвердите, что профиль не содержит материалов учётных данных, затем подтвердите, что учётные данные есть в записи идентичности, которая будет продлена. Эта пара и есть приёмочный тест.
Одна ревизия для общих настроек, одна запись на человека и путь отзыва, который вы действительно использовали один раз.