V předchozím díle seriálu jsme načali problematiku GDPR, zde je slíbené pokračování.

Přístupy

Zde se jedná také o velmi specifické téma a rozdělil bych jej tedy na 2 úrovně a to přístup na běžné infrastrukturní servery a na terminálové servery (RDS). Nejprve začněme tedy terminálovými servery. Je běžné, že společnosti, aby snížily náklady, anebo z neznalosti publikují servery přímo do internetu a pouze změní port pro přístup na daný server a to na firewallu, kde nastaví nějaký Port Forward. Já bych osobně doporučil implementovat technologii, která stojí pouze licenci Windows Serveru a nějaký veřejný certifikát a to Remote Desktop Gateway, která dělá to že „zabalí“ RDP přístup do protokolu HTTPS, který je v tomto směru bezpečný, jelikož je celá komunikace zabezpečena pomocí nějakého veřejného nebo privátního certifikátu (tento certifikát musí být pro klienta důvěryhodný a proto bych doporučil použít určitě certifikát vydaný veřejnou autoritou. Další možností je zabezpečit přihlašování na servery pomocí Kerberos autentizace a tím zajistit, že je ochráněn i vlastní přenos oprávnění k serveru, odkud uživatelé přistupují například do Sharepoint, CRM, ERP, atd.. Dalším způsobem je zajištění bezpečnosti na úrovni infrastrukturních serverů. Zde je nutno říci, proč přistupovat přímo na servery, když můžete mít pro konfiguraci konzole pro správu systému na jiném serveru, konzole otevírat s účtem, který nemá práva pro přímé přihlášení na servery a jehož heslo a jméno není nikde využíváno. Případně je možno využít více faktorové ověřování (dále také MFA) nebo jak by řekl náš kolega Ondra Výšek, tak nejbezpečnější je ověření pomocí Smart Card. Ale i tak to nemění fakt, že je nutno vše logovat a vyhodnocovat. Zabezpečení a implementaci MFA vám pomůže zajistit aplikace Enterprise Mobility + Security v rámci, které máte k dispozici lokální MFA server, který vám bude pro přístup poskytovat One Time Password do mobilního zařízení, pošle vám SMSku nebo vám zavolá automat a řekne vám PIN pro přístup. Další věcí je určitě i komplexita tohoto hesla a správná délka hesla, toto je kapitola spíše o nastavení skupinových politik v doméně, ale stejně příjemnou službu vám také nabídne

A v neposlední řadě tedy logování přístupu na servery, které můžete mít opět v aplikaci Operation Management Suite a sledovat například přístupy z vnější sítě a vyhodnocovat tak, kdo a odkud přistupuje k vaší infrastruktuře.

V neposlední řadě je určitě velice vhodné, abychom věděli kam naši uživatelé přistupují z pohledu sociálních sítí, kam mohou nahrávat svá data a celkově jaké služby v internetu využívají. Abychom mohli provést detailní kontrolu, zajistit a dát jim jednotnou identity, což v tomto případě má jako vedlejší efekt zvýšení spokojenosti uživatele, jelikož si nemusí pamatovat spousty přihlašovacích údajů, máme zde možnost využít ještě nástoje jako je Cloud App Security, který velice napomáhá tomu, aby byla služba do které uživatelé přistupují scorována společností Microsoft z pohledu bezpečnosti a také můžeme vidět kteří uživatelé a z jakých IP Adres přistupují do oněch služeb. Kdybychom šli asi do úplného důsledku, můžeme pak služby zaintegrovat do Azure AD pomocí API a využívat tak jednotné přihlášení na sociální sítě, youtube, Google Apps, atd..

Databáze

A nyní přecházíme tedy postupně od té infrastrukturní vrstvy k té aplikační, která nemůže být opomenuta. Každá společnost provozuje nějakou databázi, a jelikož nejsem úplně člověk na databáze, tak omluvte mé schopnosti v tomto směru. Pevně věřím, že existuje mnoho možností pro zabezpečení dat. Každopádně začněme nejprve s přístupy a jmény a hesly pro přístup do nějakého webového systému. Rozhodně je nutné správně ošetřit všechny vstupy z aplikace do databáze vlastní, takže na začátku začněte nějakým obyčejným vulnerability scannem, který vám ukáže, jestli na vaši databázi není možné udělat SQL injection útok. Dále je pak nutné zabezpečit jména a hesla zapsaná v databázi, zde by bylo určitě více než vhodné použít nějaký hash a salt pro zabezpečení hesel uložených přímo v DB. Na úrovni operačního systému je možno nastavit na disku, kde jsou databáze umístěny například Bitlocker a Applocker, aby nemohl být systém kompromitován nějakých cizím software a opět sbírat logy, vyhodnocovat a měřit. MS SQL ještě nabízí možnosti pro zabezpečení databáze přímo z SQL Serveru. Tudíž zde je na místě se určitě podívat na Guide pro SQL Server, který je dostupný na technetu nebo nějaký Guide pro hardening SQL serveru. V poslední řadě můžete použít pro lepší pohled na data opět nástroj Operation management Suite, který disponuje modulem SQL Assessment, který vám ukáže veškeré chybné konfigurace, případně je zašle do Security centra v Operation Management Suite, kde jsou kontrolovány pomocí Best Practises společnosti Microsoft.

Pokud bychom se rozhodli, že budeme přesouvat naše databáze do prostředí Azure a využívat službu Azure SQL, můžeme počítat s novými možnostmi zabezpečení, které nám dává platforma Microsoft Azure k dispozici a to zejména nástroj s názvem „Azure SQL Database Threat Detection“, který nám umožní zabezpečit databáze například proti SQL Injection a také mnoho dalších věcí. Tento nástroj je implementován a ovládán z Azure Security Centera, a proto máme vždy jediné místo kam se podívat a co sledovat.

Souborové servery – Office365, ARM, IRP

Souborový file systém je sám o sobě velmi náročný na správu a na analýzu. Většina společností má nasazen souborový server, někdy je replikován pomocí DFS a někdy jsou na něm nastavena až neuvěřitelná oprávnění. Postupem času (horizont třeba 5 let) se tento systém stane velmi těžko auditovatelným, tak aby bylo možno rychle a efektivně reagovat na vzniklé situace a případně zjistit zda nám někdo krade data z tohoto systému. Řízení dat je veliký problém ve světě všeobecně a i když je nasazena klasifikace dat je to hodně o odpovědnosti zaměstnanců, neboli tvůrců obsahu. Souborový systém na platformě Microsoft umožňuje logovat všemožné přístupy k souborovému systému, ale pokud jste někdy zkoušeli nastavit logování, zjistili jste, že server pak má co dělat, aby dokázal odbavit všechny požadavky, logy jsou v tu chvíli obrovské a je potřeba s těmito daty nějak efektivně pracovat a vyhodnocovat je. Tento článek je hodně zaměřen na logování, jelikož i to zákon říká, musím logovat a šifrovat. Takže co s tím? Souborový systém tedy umožňuje logování níže uvedených aktivit

Číslo nebo jeho výpočtová kombinace je uvedena vždy v Event Logu pod položkou Access Mask, ale ve chvíli kdy toto logování zapnete, zjistíte, že server nedělá nic než jen loguje, ale i tak je velmi vhodné logování na File Systému zapnout. Další možností je přechod v nějaký Dokument Management Systém, a jelikož se pohybujeme mezi produkty z rodiny Microsoft, pak to není nikdy jiný nežli Sharepoint a jelikož chceme vynaložit co nejmenší úsilí a časovou náročnost na implementaci, pak to bude Sharepoint Online. Tento systém vám nabízí možnost uložit data, nastavit oprávnění ACL stejně jako souborový systém, ale s tím rozdílem, že jsou data uložena na SQL Serveru, případně jsou uložena jako Remote Blob Storage v Hashované podobě a SQL si drží pouze metadata těchto dokumentů. Velkým posunem je určitě automatické logování do Operation Management Suite.

Další možnosti přináší systém Office365 sám o sobě, jelikož v plánu „Enterprise Plan 5“ máte k dispozici 3 komponenty a to Customer LockBox, Auditní log a Advanced Security Management. Advanced Security management vám dává možnost nastavit automatické alertování a to v případě, že byla porušena nějaká politika (např. uživatel se snaží zkopírovat více jak 5 souborů, uživatel přistupuje z podezřelé IP adresy, atd…) Tím vám dává možnost předcházet bezpečnostním incidentům a ochránit data a citlivé informace.

Další možností je tzv. Customer Lockbox v rámci, kterého udělujete přístup zaměstnanci společnosti Microsoft při řešení incidentu, aby mohl pracovat ve vašem vlastním prostředí. Veškeré aktivity jsou v tomto případě podrobně auditovány a vy máte možnost se na daná aktivity podívat.

Ochrana dat není však jen o auditu logů a aktivity uživatelů, ale také o obsahu vlastním a proto je nutno zabezpečit obsah a nikoliv jen soubor, ve kterém je daný obsah uložen. ACL chrání soubory zvenčí, šifrování chrání soubory bitově, tudíž i zde je určitě správným řešením nasazení bitlockeru nad datovými disky i za cenu snížení výkonu, případně nastavit šifrování uvnitř disku. Další možností je však nasazení Right Management, který ochrání vaše data i po cestě na koncové zařízení. Primárně se bavíme o dokumentech z rodiny Office a PDF, které podporují šifrování přímo z aplikace a také její přečtení. Nicméně pomocí Right Management je možno zabezpečit jakýkoliv soubor. Abychom mohli zajistit bezpečnost na maximální možné úrovni je určitě více než nutné chránit obsah a to buď tak, že jej klasifikuje sám autor daného dokumentu, či záznamu přímo z aplikace MS Office anebo automaticky na základě definovaného slova dokumentu. Společnost Microsoft má v rámci Office365 nějakou tu funkci pro zabezpečení obsahu. Jelikož se pohybujeme v podnikovém prostředí, tak zde přichází v úvahu určitě verze E3 a E5 pro Office365. To co budu ukazovat dále je v E5 obohaceno právě o automatickou klasifikaci dat na základě definovaných parametrů. Máme tedy možnost použití tzv. DLP policy, kterou jistě znáte z Exchange 2013 a 2016, která se aplikuje na obsah v Sharepoint Online, Exchange Online a OneDrive for Business a nastavit akci, která bude provedena jako zamezení přístupu nebo zaslání reportu. Další možností je nastavení Rights Management template v rámci Azure AD a tím umožnit funkcionalitu do aplikací MS Office, která stanoví, jakým způsobem bude dokument chráněn při jeho transferu příjemci daného obsahu. Můžeme například říci (nemůže být přeposláno, nemůže být proveden print screen, příjemce může obsah jen číst a nemůže upravovat, atd..)

A v aplikaci MS Office použít nástroje pro zabezpečení obsahu

Případně lze použít aplikaci přímo v Ribbonu MS Office

Mnohem zajímavější mi však přijde Azure Information Protection, který bude pravděpodobně jen v edici E3 a E5 Office365, ale aktuálně je v Preview verzi a spravuje se v novém portále Microsoft Azure. Tento nástroj vám dává možnosti právě pro automatickou klasifikaci dat a nastavení například Footer, Header, watermark nad dokumentem a použít vámi vytvořenou RMS politiku.

Bohužel toto lze využít pouze při komunikaci s interními lidmi, jelikož nastavená Information Protection vyhledává osoby pouze ve vlastním prostředí (tzv. tenantu). Poté co máte tuto funkcionalitu k dispozici a nainstalujete klienta, pak se vám v MS Office zobrazí nový pás pod ribbonem a můžete velmi snadno politiku nastavit.

Důležité je pro auditora, abyste věděli, kde se váš dokument nachází, a proto dává Microsoft možnost každý dokument chráněný politikou sledovat na mapě a v případě podezření k němu zneplatnit přístup. Zároveň je do dokumentu zaznamenáno i kdo se pokusil o jeho otevření, případně komu se připojení do dokumentu nepovedlo a v neposlední řadě můžete i říct, zda bude dokument možno otevřít Offline a nebo jen Online po přihlášení se k prostředí Office365. Popřípadě je zde ještě možno definovat jak dlouho bude dokument platný.

Myslím, že tímto bych asi souborové servery uzavřel a šel raději dále, jelikož je to velice obsáhlé téma a vydalo by na samostatný 10 stránkový článek a na hodiny a hodiny povídání si jak vše správně nastavit a ochránit data společnosti a citlivé informace. Ještě stále nejsme u konce, vyčkejte na třetí, závěrečný díl.