Držte uživatele v patřičných mezích

Jako profesionálové na informační bezpečnost máme při diskusích tendenci hovořit o tom, jak by mělo být implementov...


Jako profesionálové na informační bezpečnost máme při diskusích tendenci
hovořit o tom, jak by mělo být implementováno zabezpečení informací, pomocí
různých termínů. Poslední dobou jsou při poradách či hromadném firemním
maillingu, kde šířím povědomí o bezpečnostních potřebách, mými oblíbenými
termíny "pravidlo minimálních oprávnění" a "oddělení zodpovědností".
Pravidlo minimálních oprávnění vyvstalo v souvislosti s naší virtuální privátní
sítí. Tato IPSec VPN provozovaná pomocí produktu VPN Gateway od firmy Nortel
Networks našim zaměstnancům umožňuje pracovat vzdáleně stejným způsobem, jako
kdyby byli na naší interní síti, a mít tak přístup k většině firemních
aplikací, služeb či k vnitřní infrastruktuře.
Naopak Secure Sockets Layer (SSL) VPN sítě umožňují vzdálené použití pouze těch
protokolů a aplikací, které jsou podporovány dodavatelem řešení SSL VPN.
Například většina sítí SSL VPN nepodporuje vzdálené použití naší implementace
systému Remedy od BMC Software, který používáme jako aplikaci pro správu našich
IT služeb. Na druhou stranu naše síť IPSec VPN umožňuje uživatelům vzdáleně
připojeným k naší bezdrátové infrastruktuře bezproblémově spouštět aplikaci
Remedy.
Omezení SSL VPN může být ve skutečnosti žádoucí. Mnoho partnerů, dodavatelů a
externích spolupracovníků naší společnosti má přístup do prostředí našeho
portálu prostřednictvím sítě SSL VPN, která přirozeně omezuje, k čemu mohou
přistupovat. Avšak někteří z nich požadují pouze IPSec VPN řešení, neboť
potřebují používat aplikace, jež nejsou přes SSL VPN dostupné.
Profily pro uživatele
Srdcem VPN klienta jsou jeho profily. V současnosti používáme pro všechny
uživatele s přístupem do VPN jediný profil, který poskytuje úplný přístup do
sítě. Původní myšlenka byla poskytnout vzdáleným uživatelům prostředí "stejné
jako v kanceláři", ale přirozeně nechceme dát úplný přístup k infrastruktuře
osobám, které nejsou našimi zaměstnanci jako jsou třeba partneři, dodavatelé a
externí spolupracovníci. Ve skutečnosti není často dost dobrý důvod ani pro to,
aby i naši interní zaměstnanci měli k síti úplný přístup. Například lidé z
marketingu by neměli mít přístup k administrativnímu rozhraní databáze Oracle,
jež obsahuje ekonomické informace.

Pochopitelně, že pracovník marketingu by neměl znát správné přihlašovací údaje
k tomu, aby se mohl úspěšně přihlásit k databázi s údaji o financích firmy,
avšak v žádném případě není vhodné, aby tito uživatelé měli už jen potenciální
přístup k věcem, které by vidět neměli. A zde přichází pravidlo minimálních
oprávnění podle něho má pracovník jen taková oprávnění, aby mohl bez problémů
vykonávat svoji práci nic víc, nic míň.
Za pravidlem minimálních oprávnění stojí koncept označovaný jako dynamické
skupiny. Zařazením uživatele do dynamické skupiny je přesně stanoveno, kam
tento pracovník v síti smí a kam nesmí přistupovat. Například když se do VPN
přihlásí systémový administrátor, jeho profil mu umožní přístup ke kritickým
serverům. Lidem z mého týmu informační bezpečnosti bude zase umožněn přístup k
aplikacím týkajícím se bezpečnosti.
Aby dynamické skupiny fungovaly, musí být VPN koncentrátor schopen dynamicky
vytvářet profily, v ideálním případě založené na atributech získaných z našeho
systému Active Directory. Zaměstnanec, kterého množina atributů v Active
Directory identifikuje jako člena unixové skupiny, by měl získat takový profil
přístupu, který je stanoven pro toho, kdo pracuje na unixových serverech. A
třeba lidé z odbytu nebo ze zásobování by měli získat jen velmi omezený přístup
k několika málo aplikacím, které ke své činnosti potřebují. Myšlenka je to
dobrá, ale než budeme moci dynamické skupiny využít, musíme na ně příslušnou
síť připravit.
Ideální stav a realita
A to nás dostává k problému oddělených zodpovědností. Využití pracovních funkcí
jako klíče pro řízení přístupu k síti znamená, že síť musí být vhodně
segmentována. To bohužel nebylo před tím, než jsem do této firmy nastoupil jako
manažer bezpečnosti, provedeno, přičemž zásah do prostředí kvůli takto
koncipované segmentaci sítě není zcela triviální záležitostí. Sítě musejí být
překonfigurovány, je třeba změnit směrování, navíc je nezbytné upravit pravidla
firewallů, dále servery a samotné aplikace. A tak by se dalo pokračovat...
V ideálním případě bychom síť rozdělili do segmentů tak, aby jeden segment
obsahoval všechny zaměstnanecké desktopy kromě určité skupiny uživatelů, jako
jsou systémoví administrátoři či síťoví technici, kteří by byli v izolované
síti, jejíž vztah k produkčnímu datovému centru bude důvěryhodný. V rámci
serverové farmy by byly vytvořeny samostatné sítě a virtuální LAN sítě určené
pro webové, aplikační a databázové servery. Toto uspořádání by nám umožnilo
řídit vztahy mezi těmito servery a pomáhalo zabránit zlomyslným činnostem.
Například v aplikaci, jakou je třeba SAP, není důvod, aby byl nějaký vztah mezi
webovým a databázovým serverem. Vztah by měl být mezi webovým a aplikačním
serverem. Toto je oddělení zodpovědností, kterého se snažím dosáhnout.
Bude také potřeba učinit náhradní opatření pro situace, které se mohou
pravděpodobně vyskytnout. Například se může ukázat, že připojení systémových
administrátorů na izolovanou administrátorskou síť bude příliš náročné třeba
kvůli využívání DHCP (Dynamic Host Configuration Protocol) nebo prostě kvůli
způsobu, jakým je naše síť navržena. Náhradním řešením v tomto případě může být
nasazení takzvané bašty brány mezi kritickou sítí a běžnou podnikovou sítí.
Brána pak bude jediným počítačem, ze kterého bude možné přistupovat do
produkčního prostředí. Účelem takové bašty je chránit naši kritickou síť před
útoky. Naši administrátoři by se pak před přístupem na kterýkoliv z produkčních
serverů museli autentizovat už na této bráně.
Nepředstavuji si, že si svými opatřeními získám mnoho přátel, ale alespoň budu
moci lépe spát s vědomím, že jsem učinil naši infrastrukturu o něco bezpečnější
než byla. Řešíte podobné problémy jako Mathias Thurman? Podělte se o svoje
zkušenosti s námi i se čtenáři Computerworldu. Můžete psát na adresu
bezpecnost@idg.cz.(pal) 6 1491









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