EAP, nebo klientské certifikáty? Jak rozhodnout o autentizaci IKEv2

Vaše brána může prokázat vlastní identitu certifikátem a tu vaši prostřednictvím EAP, a tato kombinace je běžná, nikoli protichůdná. Oba mechanismy odpovídají na různé otázky: je tento koncový bod ten, který očekávám, a je tento uživatel nebo zařízení povoleno. Když v profilu vidíte EAP, nevypíná to ověřování serveru. Právě čtení profilu jako jediného nastavení vede lidi k resetování špatného údaje.

Určete, který nárok selhal, než se dotknete kteréhokoli ze dvou objektů. Fáze selhání vám to řekne, pokud je čtete popořadě.

Dva údaje, dva nároky

Serverový certifikát váže jméno na klíč a klient ověřuje tuto vazbu proti svému úložišti důvěry. Klientský certifikát váže identitu na klíč a brána ověřuje, zda předložený certifikát řetězí k něčemu, čemu věří. EAP nese autentizační výměnu, jejíž obsah závisí na zvolené metodě. To jsou tři struktury s různou životností, různými vlastníky a různými režimy selhání.

Heslová fráze, která odemyká soukromý klíč, není heslem účtu, i když se obě výzvy objeví v rozmezí několika sekund. Jedna je lokální v úložišti klíčů zařízení a druhou ověřuje autentizační server za bránou.

EAP je kontejner, ne metoda

EAP je rámec: brána a klient vyjednají metodu a metoda rozhoduje, zda jde o heslo, token, tunelovanou vnitřní výměnu nebo certifikát, jak vysvětluje dokumentace strongSwan k IKEv2. Proto EAP-TLS na straně klienta nevypadá vůbec jako EAP-MSCHAPv2, i když se obojí v nabídce zobrazuje jako EAP. Profil, který uvádí jen EAP, vám neřekl, na co se bude uživatel dotazován.

Čtěte metodu a backend společně. Backend určuje formát účtu, chování při uzamčení a co reset hesla skutečně změní, a nic z toho není v klientském profilu vidět.

Smíšené nasazení je normální

Serverový certifikát plus EAP pro uživatele je podoba, kterou nasazuje většina bran pro vzdálený přístup, protože dává klientovi ověřitelný koncový bod a operátorovi identitu každého uživatele v centrálním úložišti účtů. Existují i nasazení s klientskými certifikáty, obvykle tam, kde je identita zařízení důležitější než heslo. Obě jsou legitimní a chyba je předpokládat, že to, co jste viděli minulý týden, je to, co máte před sebou.

Ptejte se operátora na dokumentovanou metodu a formát účtu, místo abyste je odvozovali z názvů polí v klientovi.

Rozhodnutí podle fáze selhání

Seřaďte pozorování. Chyba důvěry před jakoukoli výzvou k uživateli je problém serverového certifikátu a žádné heslo to nespraví. Výzva následovaná odmítnutím je problém autentizace uživatele, přičemž podezřelými jsou metoda EAP a backend. Úspěšná autentizace následovaná selháním child-SA není ani jedno.

Důležité jsou ještě dva rozdíly. Klient, který odmítne serverový certifikát, obvykle hlásí neshodu jména nebo neznámou autoritu, což je otázka úložiště důvěry. Brána, která odmítne uživatele, často zaznamená metodu EAP a kategorii důvodu, což je otázka účtu nebo zásad.

Provoz obou modelů

U certifikátů je prací vydávání, obnova, odvolání a odstraňování ztracených zařízení a děje se podle plánu, který ovládáte. U EAP je prací životní cyklus účtu, podpora metod na každé klientské platformě a jakýkoli druhý faktor, který backend vyžaduje. Ani jeden model není abstraktně levnější; zatěžují různé týmy. Zapište si, který váš deployment skutečně používá, protože podpůrné skripty se liší víc než konfigurace.

Držte je ve svých poznámkách oddělené. Vypršení certifikátu vytváří selhání k určitému datu, uzamčení účtu vytváří selhání po změně hesla a neshoda metody vytváří selhání jen na jedné platformě.

Poté, co je identita přijata

Autentizace jsou jedny dveře. Podřízená bezpečnostní asociace, selektory provozu, DNS a vlastní oprávnění aplikace jsou pozdější dveře a každé selhává podle svých podmínek. Přijatá identita, která se nikam nedostane, není problém autentizace.

Zaznamenejte metodu, použitý účet nebo certifikát a fázi, která selhala. Tato poznámka promění příští incident ve vyhledávání místo experimentu.