Víc než jen renovace tokenů pro VPN

Přechod ke dvoufaktorové autentizaci dává našemu manažerovi možnost lépe zabezpečit VPN. Naše vedení konečně s...


Přechod ke dvoufaktorové autentizaci dává našemu manažerovi možnost lépe
zabezpečit VPN.

Naše vedení konečně schválilo použití dvoufaktorové autentizace pro veškerý
přístup do naší firemní sítě prostřednictvím VPN (Virtual Private Network). To
ale znamená, že budeme muset inovovat způsob, jakým je provozována naše VPN
infrastruktura od Cisca.
V současné době, když uživatel požaduje přístup přes VPN, mu poskytneme VPN
software a VPN profil, který musí do VPN klienta naimportovat. Uvedený zájemce
o spojení pak spustí VPN program, autentizuje se a je zařazen do skupiny, jež
je definována v rámci Cisco Secure Access Control Serveru (ACS). Při dnešním
stavu jsou všechny skupiny nakonfigurovány tak, že umožňují přístup téměř ke
všemu, co ve firmě aktuálně je.
To pochopitelně příliš bezpečné není, neboť například uživatel z oddělení
prodeje má možnost dostat se k unixovým serverům produkce. Pokud by byl takový
server náležitě nakonfigurován, pak by byl přístup v případě toho, že uživatel
nemá na unixovém serveru platný účet, odepřen. Avšak kdyby server patřičně
nakonfigurován nebyl, mohl by zlovolný uživatel získat neautorizovaný přístup.
A co více, zlomyslný uživatel, jemuž není zamezeno v přístupu do kterékoliv
části sítě, by se mohl pokusit o jakékoliv jiné aktivity, včetně například
útoků typu Denial-of-Service. Takže s tím, jak nyní budeme přecházet k silné
dvoufaktorové autentizaci, budeme mít příležitost zabezpečit naše systémy
mnohem lépe.

S čím začínáme
Pro implementaci dvoufaktorové autentizace používáme tokeny SecureID
společnosti RSA spolu s odpovídající kontrolou přístupů zajišťovanou produkty
firmy Cisco Systems. Tokeny RSA SecurID i jim příslušné servery zajišťují pouze
autentizaci - neurčují, ke kterým oblastem sítě bude mít zaměstnanec oprávnění
přistupovat. Tato část autorizace je prováděna systémem Cisco ACS.
V rámci ACS jsou definovány skupiny uživatelů a těm jsou přiřazeny specifické
sítě nebo hostitelé, k nimž mohou přistupovat. Například uživatel zařazený jako
auditor do finančního oddělení nepotřebuje přístup do systémů pro řízení
lidských zdrojů. V rámci ACS lze nakonfigurovat skupinu a k ní přiřadit pouze
finanční servery, které bude uživatel potřebovat pro svoji práci, doplněné o
některé běžné oblasti sítě, jako je firemní web či
e-mailové Exchange servery.
Jakmile jsme nakonfigurovali všechny skupiny, jež budeme potřebovat, je to už
jen záležitostí zařazení každého uživatele do správné skupiny. Takže jak to
uděláme? Manuální vkládání tisíců uživatelů je příliš těžkopádné a časově
náročné, než aby se o něm dalo vůbec uvažovat. Pro tuto úlohu se proto obrátíme
na adresářový server. Pro mnohé funkce ve firmě používáme řešení Lightweight
Directory Access Protocol a dosud jsme s ním slavili velké úspěchy. Naše LDAP
prostředí se stává stále užitečnějším a dovoluje nám jednodušeji zvládat úlohy,
jako je ukládání osobních dat uživatelů nebo zajišťování kontroly přístupových
práv pro aplikace.

Kopírování skupin
V případě tohoto VPN projektu chceme v rámci LDAP vytvořit tytéž skupiny, které
máme nadefinovány pro řešení přístupu v našem Cisco ACS. Jakmile budou tyto
skupiny existovat v LDAP, administrátor na helpdesku reagující na schválený a
potvrzený požadavek o VPN přístup může jednoduše spustit webovou konzoli pro
přidělování účtů a označit zaškrtávací pole pro příslušnou přístupovou skupinu.
Poté, co uživatel spustí svého VPN klienta a autentizuje se pomocí tokenu
SecurID, se Cisco ACS nejprve podívá, zda tento uživatel existuje i v rámci
ACS. Pokud zde není nalezen, ACS se podívá do našeho LDAP serveru, aby zjistil,
zda zde existuje.
Jestliže je uživatel nalezen na LDAP serveru a byl přiřazen ke korespondující
přístupové skupině, pak bude přidán do ACS a umístěn do odpovídající přístupové
skupiny. A pokud uživatel není nalezen ani na LDAP serveru, pak může být
přiřazen do standardní skupiny s omezenými právy.
Vím, že to zní, jako by šlo o spoustu transakcí, ale v praxi by to mělo zabrat
jenom několik sekund. Jediná potíž, kterou máme, je ta, že současná forma Cisco
ACS má některá omezení v tom, jakým způsobem může spolupracovat s LDAP. Jakmile
budou tato omezení vyřešena, můžeme se s navrženou architekturou pohnout
výrazně kupředu.

Software vs. hardware
Rozhodli jsme se, že namísto toho, abychom našim uživatelům poskytli hardwarové
bezpečnostní tokeny, použijeme tokeny softwarové. Ty jsou instalovány na
uživatelských PC a zajišťují stejnou úroveň bezpečnosti jako jejich hardwarové
protějšky. Software, kombinovaný s unikátním seed souborem společnosti RSA
(pomocí něho lze generovat pseudonáhodná čísla) a uživatelsky konfigurovaným
PIN kódem, poskytuje dvoufaktorovou autentizaci.
Software uživatele sice osvobozuje od nutnosti nosit s sebou token, avšak
problémem je to, že softwarové tokeny nejsou tak uživatelsky přívětivé jako ty,
jež jsou založeny na hardwaru.
S hardwarovým tokenem uživatel vkládá své PIN, po němž přímo následuje číslo
zobrazené na tokenu, jež se stává jeho vstupním kódem. U softwarového tokenu,
když uživatel zadá své PIN, představuje zobrazená hodnota pouze vstupní kód,
který uživatel musí zkopírovat a vložit do aplikace, k níž přistupuje.
Softwarové tokeny mají ale jiné výhody, neboť jsou výrazně levnější a mohou být
snáze masově nasazovány než hardwarové protějšky - poskytneme pouze webové
odkazy a použijeme software pro přidělování oprávnění.
A je tu ještě jedna věc: K dispozici máme při použití VPN produktu firmy Cisco
spolu se softwarovými tokeny RSA i příjemnou integrační funkci. Když uživatel
přistupuje přes VPN, je vyzván pouze k zadání PIN a v back-endové vrstvě
odpovídající software automaticky doplní příslušný kód tokenu ze softwaru
společnosti RSA.
Takže prozatím budeme pokračovat v definování našich přístupových skupin a
pracovat na tom, abychom dostali uživatele z LDAP do Cisco ACS.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.