Чи потрібен iPad власний клієнтський сертифікат VPN?

Новий iPad приєднується до команди, і найшвидший шлях — експортувати наявний клієнтський сертифікат і встановити його на планшеті. Це працює, доки хтось не звільниться, не загубить пристрій або не попросить аудит, який покаже, який пристрій і коли підключався. Рішення не про файл сертифіката, а про особу: чи можна авторизувати й відкликати кожен пристрій окремо. Вартість і витрати на керування визначають відповідь, і обидва менші, ніж здається.

Спільний видавець, окремі особи

Кожен пристрій може довіряти тому самому центру сертифікації й підключатися до того самого шлюзу, маючи іншу клієнтську особу. Видавець — це якір довіри, а особа — пара ключів, суб'єкт якої сервер зіставляє з політикою. Саме змішування цих понять робить спільний сертифікат на вигляд нешкідливим. Він залишається нешкідливим лише доти, доки комусь не потрібно дізнатися, який пристрій відкрив сеанс.

Спільне використання видавця економить роботу з налаштування і нічого не змінює у відповідальності за кожен пристрій. Спільне використання особи згортає всі пристрої в одну відкличну одиницю: відкликання одного відкликає всі, а авторизація заміни авторизує кожну колись зроблену копію ключа. Цю оборудку варто укладати явно, а не копіюванням файлу тому, що так швидше в п'ятницю по обіді.

Коли другий сертифікат коштує занадто дорого

Реєстрація за пристроєм коштує одного кроку: керований профіль, запит SCEP або покроковий імпорт з одноразовим паролем. Вона також потребує місця для відстеження серійних номерів і дат завершення — тієї частини, яку більшість впроваджень забуває, доки перший сертифікат не спливе. Обидві витрати разові, і обидві зменшуються, щойно процес реєстрації їх автоматизує.

Витрати реальні для домогосподарства з двома планшетами й одним користувачем, де спільна особа — розумне рішення, задокументоване одним реченням. Воно не розумне для сервісу, де доступ треба відкликати за людиною або за пристроєм, бо історія відкликання — це вся причина використовувати сертифікати замість пароля. Оцінюйте впровадження за тим, як часто пристрої змінюють власника, а не за тим, скільки пристроїв є сьогодні.

Зареєструйте пристрій, не копіюйте ключ

Сучасні платформи тримають закриті ключі в захищеному сховищі, а деякі позначають їх як неекспортовані за задумом. Саме ця властивість робить копіювання неможливим від початку, і вона ж пояснює, чому експортований з ноутбука пакет не можна просто повторно імпортувати на планшет жодним підтримуваним способом. Спроба все одно дає профіль, який чисто встановлюється і потім ніколи не автентифікується.

Використовуйте метод реєстрації, який впровадження вже підтримує: керований профіль особи, службу SCEP або процес на основі облікового запису, що видає новий ключ на пристрої. Роздавання закритого ключа центру сертифікації заради усунення відсутньої особи — інша помилка з набагато більшим радіусом ураження. Центр видає облікові дані й ніколи не повинен потрапляти на кінцеву точку.

Перевірте відкликання, перш ніж відповісти

Перш ніж обрати спільний варіант, опишіть, як виглядає відкликання в найгірший день. Якщо відповідь — одна дія, що зачіпає кілька пристроїв, архітектура вже вирішила проти вас.

openssl pkcs12 -in client.p12 -info -noout
openssl x509 -in client.pem -noout -subject -issuer -serial -dates
openssl verify -CAfile ca.pem client.pem

Дослідіть матеріал, який у вас справді є: чи присутній закритий ключ, що каже суб'єкт і чи можна відкликати серійний номер окремо. Файл сертифіката без свого ключа не може нічого автентифікувати, і тому деякі скопійовані особи зазнають невдачі під час першого підключення.

Видалення застосунку з планшета — не відкликання, і сервер продовжує приймати особу, доки хтось її не вимкне. Запишіть це речення в інструкцію до реєстрації першого пристрою.