EAP или клиентски сертификати? Как да решим удостоверяването по IKEv2

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

Определете кое твърдение е отказало, преди да пипате който и да е от двата обекта. Етапът на отказа ви го казва, ако го четете по ред.

Две идентичности, две твърдения

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

Паролата, която отключва частен ключ, не е парола за акаунт, дори когато двете подкани се появят в рамките на секунди една от друга. Едната е локална за хранилището на ключове на устройството, а другата се проверява от сървър за удостоверяване зад шлюза.

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

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

Четете метода и бекенда заедно. Бекендът определя формата на акаунта, поведението при блокиране и какво всъщност променя нулирането на парола и нищо от това не се вижда в клиентския профил.

Смесеното внедряване е нормално

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

Питайте оператора за документирания метод и формат на акаунта, вместо да ги извеждате от имената на полетата в клиента.

Решение по етапа на отказа

Подредете наблюденията. Грешка в доверието преди каквато и да е подкана за потребител е проблем със сертификата на сървъра и никаква парола няма да я поправи. Подкана, последвана от отказ, е проблем с удостоверяването на потребителя, като заподозрени са методът EAP и бекендът. Успешно удостоверяване, последвано от отказ на child-SA, не е нито едно от двете.

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

Експлоатация на двата модела

При сертификатите работата е издаване, подновяване, отмяна и премахване на изгубени устройства и тя се случва по график, който вие контролирате. При EAP работата е жизнен цикъл на акаунта, поддръжка на методи на всяка клиентска платформа и какъвто и втори фактор да изисква бекендът. Нито един модел не е по-евтин по принцип; те натоварват различни екипи. Запишете кой от двата всъщност използва вашето внедряване, защото скриптовете за поддръжка се различават повече от конфигурацията.

Дръжте ги отделно в бележките си. Изтичането на сертификат дава отказ на определена дата, блокирането на акаунт дава отказ след смяна на парола, а несъответствието на метода дава отказ само на една платформа.

След като идентичността е приета

Удостоверяването е една врата. Дъщерната асоциация за сигурност, селекторите на трафик, DNS и собствените разрешения на приложението са по-късни врати, всяка от които се проваля по свои правила. Приета идентичност, която не достига до нищо, не е проблем с удостоверяването.

Запишете метода, използвания акаунт или сертификат и етапа, който се е провалил. Тази бележка превръща следващия инцидент в справка, а не в експеримент.