EAP чи клієнтські сертифікати? Як визначити автентифікацію IKEv2

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

Визначте, яке твердження не пройшло, перш ніж торкатися будь-якого з двох об’єктів. Етап збою скаже про це, якщо читати по порядку.

Два облікові дані, два твердження

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

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

EAP — це контейнер, а не метод

EAP — це каркас: шлюз і клієнт узгоджують метод, і метод вирішує, чи задіяні пароль, токен, тунельований внутрішній обмін або сертифікат, як викладає документація strongSwan щодо IKEv2. Тому EAP-TLS з боку клієнта зовсім не схожий на EAP-MSCHAPv2, хоча обидва відображаються в меню як EAP. Профіль, у якому вказано лише EAP, не повідомив, що запитають у користувача.

Читайте метод і бекенд разом. Бекенд визначає формат облікового запису, поведінку під час блокування і те, що насправді змінює скидання пароля, і нічого з цього не видно в профілі клієнта.

Змішане розгортання — це норма

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

Запитайте в оператора документовані метод і формат облікового запису, замість виводити їх з назв полів у клієнті.

Рішення за етапом збою

Упорядкуйте спостереження. Помилка довіри до будь-якого запиту користувача — це проблема сертифіката сервера, і жоден пароль її не виправить. Запит, за яким іде відмова, — це проблема автентифікації користувача, а підозрювані — метод EAP і бекенд. Успішна автентифікація, за якою іде збій child-SA, — ні те, ні інше.

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

Експлуатація двох моделей

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

Тримайте їх окремо у своїх нотатках. Закінчення терміну сертифіката дає збій у певну дату, блокування облікового запису дає збій після зміни пароля, а незбіг методу дає збій лише на одній платформі.

Після того як ідентичність прийнято

Автентифікація — це одні ворота. Дочірня асоціація безпеки, селектори трафіку, DNS і власні дозволи застосунку — це наступні ворота, і кожні відмовляють на своїх умовах. Прийнята ідентичність, яка нікуди не доходить, — не проблема автентифікації.

Запишіть метод, використаний обліковий запис або сертифікат і етап, який не вдався. Ця нотатка перетворює наступний інцидент на пошук, а не на експеримент.