Ви надіслали всім один профіль 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, профіль зі збереженим паролем усе одно не проходить під час завантаження, і збій виглядає як зламаний профіль, а не як відсутній фактор.
Перевірте артефакт, який було фактично створено
Шаблони брешуть замовчуванням. Служба керування або інструмент експорту може вставити облікові дані в готовий файл, а супровідні навантаження ідентичності чи діагностичні копії можуть нести матеріал, якого шаблон ніколи не показував. Відкрийте створений артефакт, перш ніж вирішувати, кому його можна передати. Збережіть також налаштування довіреного видавця й очікуваної ідентичності сервера; видалення пароля — не привід послаблювати довіру до шлюзу.
Якщо справжній пароль або приватна ідентичність уже розійшлися занадто широко, відкличте їх у видавця й замініть. Редагування завтрашнього шаблону нічого не робить із уже встановленими копіями, і ці копії продовжать автентифікуватися, доки облікові дані за ними не буде відкликано.
Прийміть передавання з тестовою ідентичністю
Встановіть через схвалений процес на пристрої, зареєстрованому як окрема тестова ідентичність, завершіть передбачену автентифікацію й дійдіть до приватного ресурсу, а не просто спостерігайте, як піднімається тунель. Підтвердьте, що профіль не містить матеріалів облікових даних, потім підтвердьте, що облікові дані є в записі ідентичності, який буде поновлено. Ця пара і є приймальний тест.
Одна ревізія для спільних налаштувань, один запис на людину й шлях відкликання, який ви справді використали один раз.