Když dobré zabezpečení výrazně snižuje výkon

Je legrační, jak i potichu pošeptané slovo "bezpečnost" způsobuje, že lidé začnou pátrat, kde že vlastně sedí fir...


Je legrační, jak i potichu pošeptané slovo "bezpečnost" způsobuje, že lidé
začnou pátrat, kde že vlastně sedí firemní manažer bezpečnosti. Často bývám
zavlečen do různých situací, porad a projektů jen kvůli zmínce o bezpečnosti.
Myslím, že tak šest hodin týdně trávím prohlížením návrhů projektů nebo sezením
na poradách, kterých nemám důvod se účastnit a kde moje přítomnost není žádným
přínosem. Proto jsem ani nebyl překvapen, když jsem byl nedávno přizván na
pracovní brainstorming zaměřený na otázky výkonnosti firemní infrastruktury.
Možná se ptáte: Co má výkonnost IT společného s bezpečností? V tomto případě
docela dost. Naše aplikace je spuštěna přes Internet. Abychom dokázali zajistit
bezpečnost přenosu informací, musíme aktivovat SSL (Secure Sockets Layer),
prostřednictvím kterého můžeme se zákazníky komunikovat šifrovaně.
Pro ty, kdo to ještě nevědí: SSL se nejlépe identifikuje podle malého symbolu
zlatého zámku, který se objevuje na stavové liště internetového prohlížeče
tehdy, když navštívíte webovou stránku s adresou začínající na https místo
http. Nebudu zde dále rozvíjet problematiku protokolu SSL, ale je důležité
vědět, že existují dvě rozhodující činnosti SSL, která mají vliv na výkonnost.

Trocha matematiky
První a náročnější je počáteční proces generování klíče. Pokaždé, když
prohlížeč zadá požadavek https k načtení stránky, volaný server, na nějž se
uživatel připojuje, vygeneruje digitální klíč. Generování klíče je poměrně
náročná výpočetní operace. Matematické výpočty zabírají cenné cykly CPU a
stávají se hlavní příčinou poklesu výkonu webových stránek aktivovaných přes
SSL.
V závislosti na způsobu, jakým byla konkrétní webová stránka navržena, může
dojít k tomu, že se bude klientův prohlížeč k webovému serveru připojovat
opakovaně jen proto, aby mohl zobrazit obsah jediné stránky. Při každém dalším
požadavku prohlížeče musí server vygenerovat nový kódový klíč, a tím se ještě
více zpomalí. Druhým horkým tématem v oblasti SSL je šifrování balíků dat (bulk
encryption). Tato technologie je odpovědná za kódování toku dat v průběhu
předávání mezi webovým prohlížečem na straně klienta a vzdáleným webovým
serverem. Generování klíče, o němž jsem se zmínil, slouží pouze k autentizaci
probíhající relace. Nedochází k zašifrování dat, která cestují tam a zpět přes
veřejnou síť Internetu. Uživatelé tedy většinou používají k šifrování dat
algoritmus RC4. Ten je ovšem dalším faktorem SSL, který může ovlivnit výkon.
Přesto je třeba říci, že RC4 kódování není zrovna to, co způsobuje problémy
našim serverům. Jádro potíží spočívá v počátečním generování klíče.

Detaily problému
Naneštěstí je naše webová aplikace poměrně složitá. Prohlížeč klienta nejprve
musí náš server asi čtyřicetkrát kontaktovat, jen aby zobrazil jednu jedinou
stránku. A pro každé ze zmíněných 40 spojení náš systém vygeneruje nový kódový
klíč. Vynásobte si to několika stovkami zákazníků, kteří vstupují do naší
webové aplikace, a pak si snad představíte obsažnost problému, který musíme
řešit.
V průběhu normálních nekódovaných relací trvá načtení domovské stránky naší
aplikace, přizpůsobené zákazníkovi, asi 5 vteřin. To není tak špatné,
vezmeme-li v úvahu, že jsou všechna data, specifická pro zákazníka, dostupná
přímo na této hlavní stránce.
Ale v momentě, kdy se aktivuje kódování SSL, prodlouží se 5vteřinové čekání
skoro na 40 vteřin. A to je jen průměrná doba za nepříznivých podmínek může být
ještě podstatně delší. K tomu si přičtěte problémy týkající se vytáčení čísla a
uskutečnění spojení, a čekací doba se vám prodlouží dejme tomu až na 90 vteřin.
A to je nepřijatelné. Já osobně, když surfuji na Internetu, pokud se mi stránka
nenačte do 5 vteřin, zmáčknu tlačítko Stop a vydám se jinam. Na proces
generování kódového klíče při každém připojení prohlížeče k našemu webovému
serveru mají vliv dva rozhodující faktory. Za prvé je to zpracování potřebné k
vytvoření počátečního klíče. A za druhé je to vytváření následných klíčů pro
každé další připojení https na naši stránku. Protože v popředí zájmu stojí
využití procesoru, myslel jsem, že by bylo výhodné převést určitý objem práce,
která je náročná na zpracování, na jiný server nebo procesor.
A hádejte, co jsem zjistil? Tato technologie je k dispozici ve dvou variantách.
První je plug-in karta, která se instaluje do webového serveru a převezme zátěž
při kódování SSL. Karta má speciální procesory určené výhradně pro zpracování
kalkulací, které jsou nutné k vytváření kódových klíčů.
Druhou možností je stand-alone černá skříňka, která je umístěna mezi webovým
serverem a vstupním routerem nebo firewallem a která zpracovává všechny operace
SSL.

Další otázky
Prostředky jsou různé, ale cíl stejný: docílit snížení zátěže webového serveru
při kódování SSL tím, že se proces kódování přesměruje na jiné zařízení. Cykly
CPU probíhající na webovém serveru jsou pak volné pro jiné úkoly. První způsob
vyžaduje instalaci a údržbu karty v každém serveru a druhý spoléhá na jediné
zařízení, které se může stát příčinou selhání systému, pokud nebudete mít
pohotově po ruce druhou záložní jednotku. Každá metoda má své klady a zápory a
na mně zůstává, abych to rozhodl.
Jaká je vlastně cena opakovaného generování klíčů při každém následném
požadavku na připojení https pro jednoho uživatele? Co kdyby existoval způsob,
jak identifikovat uživatele, aby nebylo nutné při každé následující žádosti o
připojení vytvářet další klíč? Jinými slovy, chtěl bych použít jeden klíč pro
celou relaci. A hádejte, co jsem zjistil? Že to jde.
Mnoho verzí webových serverů má rozpoznávací schopnost "opakované spuštění
relace" nebo "paměť relací přes SSL". S tímto nastavením může webový server po
vytvoření počátečního klíče sledovat následující průběh relace používá přitom
identifikátor relace. Webový server hlídá, jestli následující požadavky
obsahují stejný identifikátor relace a pokud ano, přidělí stejný klíč.
Další hlediska ovlivňující zpracování a výkon spočívají ve zmenšení velikosti
webové stránky, snížení počtu zásahů potřebných k jejímu načtení, rozložení
zátěže a samozřejmě také v ukládání obsahu načtené stránky do paměti cache ale
to už jsou věci, které nejsou tak docela v mojí kompetenci. Jak by tedy měla
malá firma zvládnout řízení infrastruktury využívající uvedené technologie?
Můžeme například najmout několik techniků, kteří mají zkušenost se všemi
uvedenými oblastmi, nebo spolupracovat s externím partnerem a svěřit mu
konfiguraci a řešení všech problémů.

Slovník pojmů a odkazy na Web
RC4: Algoritmus používaný pro šifrování souborů a k zajištění bezpečného,
zakódovaného komunikačního toku mezi webovými adresami s použitím protokolu
SSL. Označení RC4 vzniklo z anglického Rons Code No. 4, neboť tento algoritmus
vytvořil v roce 1987 Ronald Rivest pro RSA Security.

Secure Sockets Layer (SSL), zabezpečená vrstva pro sockety: Bezpečnostní
protokol, který zajišťuje soukromí při komunikaci probíhající po Internetu mezi
klientem a webovým serverem. Koncept SSL má zabránit odposlechu, manipulaci s
daty a falšování zpráv.
Zajímavé odkazy

Dobrá znalost SSL je pro odborníky v oblasti bezpečnosti IT velmi důležitá. Na
webové stránce RSA Security (http://www.rsasecurity.com/) najdete výborný zdroj
článků, které byste si měli určitě přečíst. Velmi důležitý je především text
"What is SSL?". liVea Technologies nabízí nabízí akcelerační karty CryptoSwift
(http://www.ivea.com/
cryptoswift/cs_pci.html), které představují dobrý nástroj pro zvýšení výkonu
SSL.
Nástroje NetStructure (http://www.intel.com/network/idc/products/ecommerce_
equipment.
htm) společnosti Intel jsou dobrým příkladem metody černé skříňky pro zvýšení
výkonu SSL.
1 1334 / pen









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