S daty do cloudu a bezpečně: šifrování nebo tokenizace

Po sérii předchozích článků by se mohlo nezasvěcené osobě zdát, že jsme proti cloudům. Není tomu tak, jsme jen proti bezhlavému přesunu dat do cloudů bez provedené analýzy rizik.

Např. SME až na výjimky zpravidla nejsou schopny dosáhnout takové úrovně bezpečnosti jako korporace, takže se pro ně může jevit jako výhodnější svěřit správu dat někomu, kdo tomu opravdu rozumí, tedy CSP. Ovšem nenechte se zmást odbornými termíny a zkratkami (HSM, FISP, BYOK, key splitting, apod.)

Vždy se zamyslete nad tím, jaká data a do jakého cloudu chcete umístit, protože i malá firma provádějící aplikovaný výzkum nebo vyvíjející novou technologii může zpracovávat data a informace, které mohou být předmětem zájmu konkurence.

A dost často se ani nemusí jednat o konkurenci místního formátu, která třeba ani vzhledem k úzkému zaměření dané organizace neexistuje, takže umístění dat do cloudu může paradoxně usnadnit přístup k těmto datům zahraničním zpravodajským službám a dalším organizacím, které se na tuto oblast specializují.

V podnikové sféře velmi často potřebujeme pracovat s daty a přitom je chránit před prozrazením, ať už konkurenci, veřejnosti nebo i zaměstnanci, kteří nejsou oprávněni k nimi přistupovat.

A podle toho, kde identifikujeme nejslabší místo, nasazujeme protiopatření. Data musíme typicky chránit při přenosu v úložišti a při zpracování. Zatímco přenos je dnes řešený převážně TLS (nejčastěji HTTPS), tak ochrana dat při zpracování a uložení je méně častá a liší se mezi produkty-službami. Kromě šifrování můžeme použít i tokenizaci.

Šifrování/dešifrování

Šifrování je vhodné pro nestrukturovaná data, ke kterým se nepřistupuje tak často a jsou uložena na jednom místě. Při šifrování je za použití tajného klíče a série matematických operací nahrazen příslušný text zašifrovaným ekvivalentem a jen se znalostí daného klíče a algoritmu je možné daný text dešifrovat.

Když útočník hackne nebo ukradne DB, kde se nacházejí zašifrovaná data, anebo je schopen zachytávat veškerý síťový provoz, který je zpravidla zašifrován jedním symetrickým klíčem, tak to ve výsledku znamená, že v okamžiku, kdy získá heslo nebo odhalí slabinu daného algoritmu, tak je schopen zpětně dešifrovat veškerá uložená/přenášená data.

Cílem útočníka je získat šifrovací klíč anebo kompromitovat službu, která je oprávněna šifrování/dešifrování provádět, v případě použití HSM pak kompromitovat samotný HSM server. Slabinou šifrování je, že klíč může někdo ukrást, ale pokud je uložen v HSM, tak je to velice obtížné.

Tokenizace/detokenizace

Tokenizace je vhodná pro strukturovaná data, ke kterým se často přistupuje, a nacházejí se na více místech. Při tokenizaci je příslušný řetězec nahrazen náhodně vygenerovaným řetězcem (zpravidla) o stejné délce. Ani se znalosti algoritmu generování náhodného řetězce není možné získat původní řetězec.

Když útočník hackne nebo ukradne DB, kde se nacházejí tokenizovaná data, anebo je schopen zachytávat veškerý síťový provoz, tak není schopen získat původní data. Musel by kompromitovat tokenizační server, který provádí tokenizaci/detokenizaci a zcizit buď jeho databázi, ve které je uložena původní hodnota anebo by musel jeho službu zavolat a detokenizovat jednotlivé tokeny po jednom.

Cílem útočníka je kompromitovat službu, která je oprávněna tokenizační server volat anebo přímo daný tokenizační server.

Srovnání

Zde je třeba si uvědomit, při tokenizaci na rozdíl od šifrování musí z principu existovat DB, kde bude uložena dvojice chráněná informace a token. Tato DB pak může být samozřejmě šifrována.

Otázka je, jak je zabezpečen HSM server a jak tokenizační server? Budeme-li předpokládat, že oba jsou zabezpečeny stejně, tedy, že k nim je striktně řízen přístup, jsou izolovány, a volat je může jen vybraná služba a probíhá zde nějaký monitoring proti vytěžování, tak pak je rozhodující rychlost, velikost DB, snadnost užití atd.

Bezpečnost by se pak měla zvyšovat v okamžiku, kdy k tokenizaci a šifrování bude docházet na dedikovaném serveru a pokud už se nějaká data mají ukládat do cloudu, tak by k šifrování/tokenizaci mělo docházet on-premis, protože jedině tak lze zajistit, že se k datům nedostane CSP nebo zahraniční zpravodajská služba.

Kybernetický útok a riziko

Při kybernetickém útoku může dojít k pokusu o zkopírování databáze a získání klíče (dostane se ke všem datům) anebo k pokusu o získání přístupu k aplikaci (dostane se ke všem protékajícím datům, přičemž je může je dolovat postupně po delší dobu, aby se vyhnul detekci.) Otázka je, jaké to riziko vlastně je, jeden z možných pohledů je následující:

  • šifrování v cloudu – vysoké
  • on-premise šifrování a následné uložení do Cloud – střední
  • on-premise šifrování nebo tokenizace – nízké
  • on-premise tokenizace a následné uložení do Cloud – nízké

Hodnotili byste jinak? Napište jak a proč.

Pokud vás tento příspěvek zaujal, sdílejte ho!
Email this to someone
email
Share on LinkedIn
Linkedin
Tweet about this on Twitter
Twitter
Share on Facebook
Facebook
Print this page
Print

Štítky:


K článku “S daty do cloudu a bezpečně: šifrování nebo tokenizace” se zde nenachází žádný komentář - buďte první.

Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.

Přihlášeným uživatelům se tento formulář nezobrazuje - zaregistrujte se.

Jméno:(požadováno)
E-mail:(požadováno - nebude zobrazen)
Web:

Text vaší reakce: