Test: NAC, vícerozměrná skládačka, kterou musíte nejdříve pochopit (2)

Čtěte také: Test: NAC, vícerozměrná skládačka, kterou musíte nejdříve pochopit (1)

Jakmile se rozhodnete použít zásady řízení přístupu pro zařízení, jak ho dostanete do stavu vynucování? Toto místo je kontroverzní, protože kombinuje všechny druhy problémů počínaje technickými, přes politické až dokonce po tzv. náboženské.

Skutečně existují tři přístupy: proprietární, 802.1X a „cokoli fungujícího“.

První varianta je nejjednodušší k pochopení. Když dodavatel NAC prodává jak vynucovací zařízení, tak i řešení NAC, často existuje proprietární API, které umožňuje části NAC produktu komunikovat s prosazující částí produktu. Například Juniper UAC dokáže komunikovat s firewally Juniper, aby vydaly pravidla řízení přístupu. Přepínače Alcatel-Lucent mohou vytvářet dotazy pro servery Safe NAC CyberGatekeeper ohledně informací o stavu koncových bodů.

Někdy je vynucovací zařízení vestavěno do produktu NAC, jako je to třeba u McAfee N-450, a komunikace zásad je potom neviditelná. Nevýhodou ale potom je, že nemůžete kombinovat různá prosazující zařízení, ale většina dodavatelů s proprietárními vynucovacími zařízeními vytvořila řešení, která umožňují jiné způsoby sdělování příslušných pravidel.

Faktor 802.1X

Když je použit protokol 802.1X, má produkt NAC příležitost sdělit informace o řízení přístupu hraničnímu zařízení v rámci tohoto protokolu. Je to více či méně standardizováno a poskytuje to silné a bezpečné spojení mezi produkty pokoušejícím se o připojení a zásadami pro řízení přístupu. To činí z využití protokolu 802.1X technicky elegantní řešení, které má personál dbající o ochranu sítě v oblibě.

Při použití protokolu 802.1X však bohužel existují významné problémy a většina z nich se týká jednoho místa: řízení přístupu 802.1X je snadné v okamžiku ověřování, ale těžké kdykoli jindy. Pokud se například řešení NAC nečekaně rozhodne, že někdo již nadále nevyhovuje, nebo pokud správce NAC změní pravidla v systému správy, neexistuje snadný způsob, jak tuto informaci dostat do všech portů ověřených pomocí protokolu 802.1X.

Autoři standardů navrhli řešení nazvané COA (change of authorizaton; změna autorizace), které umožňuje zasílat změny řízení přístupu asynchronně z ověřovacích odpovědí. Je s tím však pár problémů: za prvé většina přepínačů nepodporuje COA a za druhé většina produktů NAC tuto podporu postrádá také. Podporu jsme nalezli v některých přepínačích společností Cisco, HP či Enterasys a v produktech Enterasys NAC, ale to je všechno.

Propojování pravidel NAC s ověřováním má další problém, který trápí dodavatele odpovídajících řešení, protože vyžaduje, aby bylo při připojení uživatele nejprve vyhodnoceno zabezpečení klienta.

Poskytovatelé systémů NAC to nikdy nemají rádi ze dvou důvodů. Jedním je to, že ověření shody zabezpečení klienta trvá velmi dlouho, a to zdržuje přihlašování -- výsledkem jsou pak nespokojení uživatelé. A druhý důvodem je, že to vyžaduje po dodavateli NAC úzkou návaznost na první bezpečnostní kontrolu klienta, aby bylo možno provést ověření, a to zase nevyhovuje dodavatelům systémů NAC.

Pragmatičtí prodejci přišli s řešením, které nazýváme „cokoli fungujícího“. Je to kombinace úkonů SNMP a příkazů příkazové řádky zaslané přes Telnet nebo SSH, které lze využít k odeslání informací o řízení přístupu do přepínačů, a to kdykoli: před, po a během ověřování.

Společnosti Bradford, Cisco, Forescout a McAfee používají tuto strategii jako svou cestu nejmenšího odporu -- když vybalíte jejich produkty, je to úvodní strategie, kterou doporučují, i když je k dispozici i alternativa protokolu 802.1X.

Ti dodavatelé NAC, kteří důrazně doporučují 802.1X, jako firmy Avenda, Enterasys, HP, Juniper, Microsoft nebo Symantec, také mohou podporovat další přístupy, ale když si zvolíte hraniční vynucování, jste hned na začátku tlačeni k řízení přístupu pomocí 802.1X.

Při tolika technických argumentech může dojít spíše k omezení na preference a zkušenosti než k technickému odůvodnění. Z hlediska zabezpečení byly naše preference použít protokol 802.1X pro řízení přístupu, což nabízí mnohem silnější zabezpečení než přístupy s využitím SNMP. Není to však vždy zabezpečení, co je motivem projektů NAC, takže tento pohled není použitelný univerzálně.

Naše testování také odhalilo problémy s kompatibilitou při použití SNMP. Dodavatelé NAC rychle vyřešili problémy, na které jsme je upozornili, ale není záruka, že se tyto problémy znovu neobjeví při nějakém budoucím upgradu firmwaru přepínače.

Bylo odhaleno mnoho zranitelností souvisejících se strategií „cokoli fungujícího“ a byla implementována kompenzační opatření. Protože například SNMP trap identifikuje možnost ztráty nového systému, mnoho produktů zaměřených na SNMP pravidelně kontroluje tabulky řízení přístupu k médiu v přepínačích, aby bylo jasné, zda nové MAC adresy oznámily potřebu ověření a kontroly.

Podobně existuje řešení i u problémů s protokolem 802.1X. Když například agent systému Juniper UAC zjistí změnu zabezpečení klienta a toto zařízení musí být znovu posouzeno, dojde k vynucení tichého opětovného ověření, které poskytne serveru Juniper UAC šanci změnit řízení přístupu na pozadí, aniž by uživatel musel znovu zadávat své jméno a heslo.

Příště se podíváme na problematiku správy a poradíme vám, jak nejl=pe při výběru NAC postupovat.