V poslední době, kdy se velká část naší práce na počítačích přesouvá na cloud, se objevuje velké množství nových hrozeb pro naši bezpečnost, a proto musíme těmto hrozbám nějak čelit. V této souvislosti čím dál tím častěji slýcháváme termín Zero Trust. Co tento pojem znamená a proč jej využíváme?

V minulosti lidé většinou pracovali místně – napojovali se na místní síť, pracovali na počítačích v práci a podobně. Hlavním těžištěm bezpečnosti bylo, aby se případný útočník na tuto síť nedostal (tedy pátou vrstvu hloubkové ochrany – perimeter). V dnešní době se velká část lidské činnosti přesouvá na internet, a to především do cloudu – lidé pracují z domova, soubory sdílejí na online úložištích namísto přenosných disků a komunikace probíhá převážně online. S tím ovšem přichází nová hrozba. Útočníci se mohou snáze než kdykoliv dřív vydávat za někoho jiného a je pro ně mnohem jednodušší dostat se k citlivým datům a důležitým prostředkům.

Tento problém se snaží řešit model zabezpečení Zero Trust (česky doslova nulová důvěra). Základní heslo tohoto modelu zní: „Nevěř nikomu, ověřuj vše!“ Spočívá v navržení systému takovým způsobem, abychom si mohli být co nejvíce jisti tím, že naše data nebyla kompromitována a že k nim přistupuje oprávněná osoba. V kontextu Azure obvykle hovoříme o třech základních principech Zero Trust – verify explicitly, least privilege a assume breach.

Verify explicitly

Do češtiny můžeme verify explicitly přeložit jako důsledně prověřuj. Proto je dobré se ujistit, že osoba, která se snaží ke službě, prostředku či datům přistoupit, je skutečně tím, za koho se vydává.

To většinou naplňujeme několika způsoby. V první řadě se musíme snažit co nejlépe zabezpečit identity uživatelů, k čemuž můžeme využít například vícefázové ověření (MFA). Uživatel se pak musí prokázat nejen heslem, ale například otiskem prstu či oznámením v mobilním telefonu. Zároveň zavádíme SSO, což uživatelům nejen zjednoduší práci, ale zároveň v kombinaci s Conditional Access je přinutí k větší opatrnosti.

Vícefázové ověření využívá k autentifikaci uživatele kombinaci více různých faktorů – například heslo, sken obličeje či token.
Single sign-on umožňuje uživatelům přihlásit se k více různým aplikacím pomocí jedné identity.

Příklad: Antonín pracuje jako programátor ve společnosti XY, s. r. o. V současnosti pracuje na nové funkci související se zpracováním plateb, která je utajovaná i v rámci společnosti. Většinou pracuje na svém počítači z domova. Když přistupuje k aplikaci z domova, většinou stačí jednoduché ověření.

Least privilege

Least privilege v češtině znamená nejméně oprávnění. Tato myšlenka spočívá v tom, že se snažíme omezit oprávnění všech uživatelů jen na takovou úroveň, jakou skutečně potřebují, protože čím méně oprávnění uživatel má, tím méně škody dokáže napáchat. Zde hraje významnou roli just-in-time a just enough access. Uživatel tak dostává jen potřebná oprávnění na dobu, pro kterou je potřebuje.

Just-in-time access je metoda, při níž uživatel dostane oprávnění jen na dobu, na kterou je potřebuje.
Just enough access je metoda, při níž uživatel dostane jen oprávnění, která skutečně potřebuje.

Proč bychom ale člověku, jemuž věříme, že nenapáchá škodu, nemohli dát větší oprávnění? Problém není v osobě samotné, ale v tom, že, kdyby byl její účet zkompromitován, může útočník napáchat mnohem větší škodu, než kdyby oprávnění byla minimální.

Příklad: Antonín vyvíjí pouze jednu funkci jedné aplikace. V případě, že by útočník dostal přístup k jeho účtu, je ohrožena pouze tahle funkce a nemůže ovládnout celou aplikaci, čímž by jeho firma mohla utrpět velmi vysoké ztráty.

Assume breach

Poslední princip Zero Trust lze v češtině říct jako předpokládej průnik. Misha Glenny, britský žurnalista, který se zaměřuje na kyberbezpečnost, pronesl větu: „Na světě existují dva typy společností – ty, které ví, že byly hacknuty, a ty, které to neví.“ Tato myšlenka především zdůrazňuje, abychom jednotlivé části systému udržovali na sobě nezávislé a abychom se hrozby snažili aktivně hledat a vymýtit. Musíme sbírat záznamy a tyto záznamy monitorovat, abychom co nejrychleji odhalili jakékoliv bezpečností problémy a eliminovali je.

There are two types of companies in the world: those that know they’ve been hacked, and those that don’t.

Misha Glenny

Příklad: Antonín pracuje ve vývojářském týmu své společnosti, který je oddělený od finančního týmu. Všechna data, která využívá, vyžadují ověření identity před přístupem. Kdyby se nějakému útočníkovi podařilo systémy vývojářského týmu ovládnout, příliš mu to nepomůže, kdyby se dál snažil ovládnout systémy finančního oddělení či se snažil přistoupit k datům vývojářského týmu.

Základní pilíře Zero Trust

Zero Trust stavíme většinou na šesti základních pilířích.

• Identity – tímto pojmem většinou myslíme uživatele, služby nebo zařízení. Kdykoliv se identita snaží získat přístup k prostředku, vyžadujeme po ní ověření (verify explicitly) a zároveň minimalizujeme její pravomoci k danému prostředku (least privilege).
• Zařízení – uživatelé přistupují do cloudu pomocí svých zařízení, což vytváří masivní útočnou plochu. Abychom útokům předešli, musíme vždy všechna zařízení monitorovat (assume breach).
• Aplikace – aplikace představují hlavní stykovou zónu mezi identitami a zařízeními a daty. Musíme proto monitorovat všechny aplikace a spravovat jejich oprávnění a přístup k nim.
• Data – ve většině případů tvoří právě data tu nejdůležitější část, a proto se rovněž nejčastěji stávají cílem útoků. Abychom je udrželi co nejbezpečnější, musíme je klasifikovat, popsat a především zašifrovat. Je na místě využít princip CIA (least privilege).
• Infrastruktura – ať už cloud nebo on-premises, infrastrukturu musíme chránit a udržovat ji v co nejlepší kondici.
• Sítě – v sítích musíme klást důraz na segmentaci. Zároveň musíme uplatňovat principy ochrany v reálném čase, koncového šifrování, monitorování a analýzy (assume breach).

Závěr

V dnešní době je na prvním místě bezpečnost. Abychom ji udrželi na co nejvyšší úrovni, uplatňujeme koncept Zero Trust, který zjednodušeně spočívá v tom, že nebudeme věřit v důvěryhodnost žádné identity (uživatele, zařízení, služby…), a proto vždy budeme vyžadovat ověření, dáme této identitě nejnižší možná oprávnění a budeme pečlivě monitorovat vše, co se s našimi prostředky děje. Pokud chcete zjistit, jak umožnit bezpečné a jednoduché přihlašování uživatelů do vaší aplikace? Přečtěte si článek o Microsoft Identity Platform.