Vzdálený přístup
Drtivá většina společností dnes nějakým způsobem řeší vzdálený přístup ke svým interním zdrojům, jako je pošta, informační systémy, intranet a další aplikace. Hlavním požadavkem je zvyšující se mobilita pracovní síly a zvýšené nároky na spolupráci uvnitř týmů v reálném čase. Pro většinu lidí je vzdálený přístup reprezentován šifrovanou virtuální privátní sítí – většinou reprezentovanou klientem poskytnutým výrobcem operačního systému.
Na bezpečném kanále pro přístup není samozřejmě nic špatného, nicméně je třeba si uvědomit, že notebook, tablet či telefon, ze kterého zaměstnanec či kontraktor přistupují do firmy, je osamělým hradem na kopci, který je třeba za každou cenu ubránit před hordami krvežíznivých barbarů, kterých je plný Internet. Je tedy třeba zabezpečení těchto zařízení a kontrole přístupu věnovat stejnou pozornost jako celé firmě. Tím pádem je potřeba vyřešit zejména:
- Autentizaci uživatelů používajících vzdálený přístup,
- zabezpečení vlastního zařízení,
- zajištění vlastního bezpečného přístupu.
Autentizace a autorizace uživatelů
V rámci přístupu je třeba zajistit, aby uživatelé používali dostatečně bezpečné metody autentizace. Prosté jméno a heslo není vhodnou metodou, protože je zranitelné hned z několika stran – sociální inženýrství či stejná hesla k různým účtům. Samostatnou kapitoulou jsou korporátní standardy pro heslo: vyžadované parametry hesel jsou většinou natolik restriktivní, že uživateli nezbývá jiná možnost, než si ten strčprstskrzkrk poznamenat na kus papírku a nosit jej v peněžence. Zde je proto třeba, aby zařízení zajišťující ve společnosti vzdálený přístup umělo spolupracovat s bezpečným autentizačním systémem, který nabídne bezpečnou vícefaktorovou autentizaci, která odbourá nutnost složitého hesla zavedením dalšího faktoru. Pro tyto účely se používají různé kalkulačky, tokeny či seznamy generovaných jednorázových hesel.
Dalším důležitým bodem jsou přístupová práva – technik nepotřebuje vidět data z účtárny a účetní technické dokumenty. Proto je důležité (a nevztahuje se to pouze na vzdálený přístup) mít implementován systém jednotné správy uživatelů a poskytovat jim přístup podle členství v různých skupinách. Je samozřejmostí, že systém pro zajištění vzdáleného přístupu musí s centrálním registrem uživatelů spolupracovat.
Zabezpečení zařízení
Jak je napsáno v úvodu tohoto textu, je třeba věnovat zvláštní pozornost zabezpečení koncových stanic. Z pohledu platformy zajišťující vzdálený přístup je důležité, aby uměla zkontrolovat stav prostředků na přistupujícím zařízení – nikdo si nechce pustit do firmy notebook bez zapnutého lokálního firewallu, se starými virovými definicemi, popřípadě s instalovaným neautorizovaným software. Je proto důležité, aby platforma pro vzdálený přístup uměla sama na základě stavu přistupujícího notebooku nebo mobilu rozhodnout, zda jej pustí pouze na update server, kde má klient k dispozici patche a nástroje k uvedení svého zařízení do akceptovatelného stavu, nebo jej pustí k datům, která požaduje.
Zajištění bezpečného kanálu
Bezpečný kanál je možno v současné době zajistit několika způsoby. Jako nejjednodušší je využití nativního šifrování aplikačního protokolu, pokud to umožňuje. Částečně se tímto způsobem dají použít platformy ADN, které takovéto konfigurace umožňují.
Dále je možno použít „tlustého“ klienta, který zajistí interakci s centrálním prvkem pro vzdálený přístup. Výhodou je kontrola nad sestaveným šifrovacím tunelem a podpora protokolů, které neumožňují šifrování. Takovýto klient je povětšinou součástí většiny operačních systémů. Nevýhodou je nutnost jeho instalace a konfigurace, což nemusí být pro většinu uživatelů triviální, popřípadě může vyžadovat administrátorská práva.
Spojením výše uvedených možností je tzv. „tenký VPN klient“, což je většinou Java/ActiveX komponenta webového prohlížeče, která v sobě spojuje výhody jednoduchosti využití nativního protokolu a vzdálené instalace a konfigurace na libovolné zařízení. Vzhledem k tomu, že základním kamenem je využití protokolu HTTPS, někdy jsou tato zařízení také nazývána SSL VPN.
