Optimalizované IT - portál pro IT pro komunitu

GDPR na platformě Microsoft - jak pomáhá Azure, OMS, EMS, Office 365 a Windows 10 - část 3

Vytisknout E-mail

Daniel Hejda Datum zveřejnění: 15. 3. 2017 13:19 Zobrazeno: 950
1 1 1 1 1 1 1 1 1 1 Rating 0.00 (0 Votes)

V předchozích částech článku ZDE a ZDE jsme se zabývali problematikou GDPR a platformou Microsoft, nyní je zde závěrečná část.

Identifikační systémy (Active Directory)

Dalším tématem je ochrana identit, jmen a hesel v identifikačních systémech. Pravděpodobně každý z vás bude mít implementovánu doménu na platformě Microsoft, tudíž Active Directory, ale také bude mít spousty dalších systémů jako jsou třeba různé ERP systémy, vlastní systémy pro HR, CRM systémy, atd.. je toho opravdu velké množství a těm ostatním lze říci jen jedno. Musíte logovat přístupy do systému, aktivitu uživatele v systému, data uložená v systému (databázi daného systému) a okolo toho zajistit potřebný proces. Co se týká Active Directory tak máte možnost mnohem lépe zajistit toto logování a hned se nám nabízí některé možnosti jako například Security Event Log, který nám zapisuje všechny informace do logu a jeho následné vyhodnocení v Operation Management Suite, ale i správná konfigurace v doméně, kterou nám provede automaticky Operation management Suite.

image

Ale také byste měli sledovat zranitelnosti, které mohou v systému být a proto je potřeba vše prověřit pomocí dalších nástrojů. Ale tím pouze zajistíte, že je váše prostředí zdravé a v pořádku a že máte vše nastaveno, tak jak by mělo být nastaveno. To je ale ochrana jen částečná. Abyste mohli zajistit ochranu identit při jejich vyžádání a odeslání cílovému systému je nutné se pozastavit nad vlastním přenosem a to vám dá jedině implementace Kerberos autentizace, což může být problém, jelikož spousta systémů Kerberos vůbec nepodporuje a tak je nutno tento problém nejprve vyřešit a zjistit jak je jméno a heslo z Active Directory distribuováno směrem k cílovému systému.

Klientské stanice a aplikace z rodiny Microsoft budou mít tuto možnost a proto Kerberos určitě implementujte a pokud možno ihned. Nyní je možno použít Kerberos i při propojení do Azure AD a to pomocí nového vydání aplikace Azure AD Connect.

Další možností jak ochránit identity je možno implementací MFA serveru, jehož licenci máte společně s uživatelským CALem v licenci Enteprise Mobility + Security. Tím zajistíte, že jsou systémy zabezpečny mnohem lépe než jen obyčejným heslem splňujícím určité politiky hesel.

Co, ale můžete ještě udělat navíc je implementace Advanced Threat Analytics (dále také ATA), který máte v rámci licence Enterprise Mobility + Security k dispozici.

image

Jedná se o lokální server, který bude sledovat vaše prostředí a vyhodnocovat anomálie, které se dějí na základě instalace agenta na doménovém řadiči nebo pomocí Port Mirroringu doménového řadiče přímo do ATA Gateway serverů. Vše je pak vyhodnocováno v ATA Center, který vám poskytne komplexní pohled na anomálie ve vašem prostředí, jako například uživatel se během hodiny přihlásil na jedno místě ale za 5 minut se přihlásil na 100km vzdáleném místě. Také je možno daný systém integrovat na OMS nebo na SIEM nástroje třetích stran.

V rámci Azure prostředí máte k dispozici ještě další nástroje, které však chrání Azure AD, do kterého máte identity synchronizovány a to Azure AD Identity Protection a Azure AD Privileged Identity management (PIM).

imageimage

Aplikační a Webové servery

Jelikož nejsem vývojář, tak je toto téma pro mne poměrně složité, nicméně dle zákona je nutno chránit IP Adresy a Cookie, což může být problém, jelikož Cookie je uložena na koncovém zařízení a proto je potřeba používat prohlížeče, které mají svůj vlastní izolovaný prostor, do kterého nelze zasahovat aplikacemi třetích stran a veškerý provoz musí být HTTPS. Z tohoto důvodu je nutné na všech webových aplikacích nastavit explicitní provoz jen na HTTPS a HTTP z aplikací naprosto zrušit.

Dále je nutné ošetřit a chránit IIS logy, ale také je nutné vyhodnocovat tyto logy. Operation management Suite vám umožní logy načítat do prostředí OMS k další analýze a kontrole toho kdo přistupuje anebo se snaží přistupovat na webové servery. Také bych v rámci OMS doporučoval sledovat soubory a změnu jejich velikost a tím je chránit proti permanentnímu XSS. Logy na úrovni operačních systému lze chránit pomocí bitlockeru a tím zajistit nemožnost jejich odcizení v případě odcizení celého virtuálního serveru.

Klientské operační systémy

Osobně bych řekl, že toto je kapitola sama pro sebe. Všichni známe uživatele a to zejména ty VIP uživatele, kteří mají vždy potřebu vlastnit administrátorská práva do svých počítačů a administrátoři, pak mají velký problém zabezpečit tato zařízení. Jelikož je moderní doba tak už se nebavíme o klasických stolních počítačích, ale hlavně o zařízeních mobilních a to ještě od spousty výrobců. Dalším velkým fenoménem je model práce s tzv. „Bring On your Device“ tudíž zařízením, které nepodléhá žádným politikám společnosti a správce jej nemůže ani kontrolovat.

Na koncovém zařízení pod správou administrátora, bychom mohli využít opět moderních trendových aplikací jako jsou Windows Defender, Windows Firewall a další, kterými se nám povede daná zařízení zabezpečit a následně můžeme vyhodnocovat co se na daných zařízeních děje.

Jedním z nástrojů pro toto vyhodnocování je právě Windows Defender Advanced Threat Protection

image

Dalším nástrojem pro zabezpečení je určitě InTune, jehož licenci máte v rámci Enteprise Mobility + Security a zjišťovat tak třeba jaký software je na daném zařízení nainstalován, zda má nastaveny politiky a případně mu tyto politiky vnutit a tím ho připravit pro vstup do prostředí.

image

Z dlouhodobého pohledu bych povolil do systémů, které pracují s osobními nebo citlivými informacemi pouze ze zařízení, která jsou do Intune připojena a zrovna, proto byla v rámci Windows 8.1 a výše přidána možnost tzv. WorkSpace Join, který vám umožní i vlastní zařízení připojit do společnosti aniž bychom ovlivnili stav prostředí uživatele na jeho soukromém zařízení. Můžeme do tohoto zařízení vnutit naše bezpečnostní politiky a politiky hesel, auditovat aplikace a o zařízení se postarat.

Korporátní zařízení musí být šifrována pomocí Bitlockeru a nejlépe i se systémovým diskem a heslem uloženým v TPM čipu.

Dalším důležitým aspektem a to ne jen pro koncová zařízení, ale i pro servery je pravidelná aktualizace, abychom těch zranitelností měli v rámci zařízení co možná nejméně. Operation Management Suite má vlastní aplikaci, pomocí které můžete provádět a kontrolovat MS Update na kontrolovaných zařízeních a plánovat kdy budou koncová zařízení aktualizována.

image

Důležité je dle mého hlavně získat informace velmi rychle, pokud se něco stane a také předcházet těmto problémům, takže pravidelně provádět kontroly a nechávat si posílat reporty, jak to umí třeba aplikace Intune.

image

Odmazání dat ze systémů na přání zákazníka

Toto je jedno velké téma a já moc nevím jak se k tomu postavit, zákon totiž říká, že pokud zákazník požádá o vymazání ze všech systémů, musíte jej vymazat ze všech systémů a také ze záloh a archivů a hlavně musíte vědět, kde všude jeho data jsou umístěna.

Já bych tento problém řešil následovně. Postavil bych jednu konfigurační databázi, ve které budou umístěné osobní a citlivé informace, nejlépe CRM a když bezpečnost tak Microsoft Dynamics 365. Zde bych každému uživateli přidělil číslo a to i interním zaměstnancům. Ve všech systémech bych změnil uživatelské jméno na toto číslo a chránil bych databázi těchto vazeb.

V případě potřeby odmazání uživatele ze všech systémů bych smazal jen položku v CRM, případně upravil data, která o něm udržuji, a v ostatních systémech jsou již data anonymizována.

Takže je potřeba identifikovat, roztřídit, sestavit pomocnou databázi, přidělit evidenční čísla a implementovat do systémů jednoznačné identifikátory.

Microsoft však myslel i na to, že se může něco stát a vy budete potřebovat určité informace ze systémů exportovat a předat třeba policii a proto připravil aplikaci, které se jmenuje eDiscovery. Tato aplikace vám umožní exportovat veškerý obsah z Office365 služeb do složky a vygeneruje vám report, kde se daná data nacházejí, tak abyste mohli předat informaci vyšším orgánům. V tomto případě můžete pomocí eDiscovery prokázat, že jsou data smazána nebo je případně exportovat a předat.

Trust centrum a prohlášení Microsoftu k GDPR

Dalším argumentem, proč právě tuto platformu může být i nová informace z Microsoft Trust centra Microsoftu, které přímo oznamuje, že je v souladu s GDPR pro EU a můžete si přečíst přímo uvedené dokumenty k této problematice.

image

Dalším argumentem, proč právě tuto platformu může být i nová informace z Microsoft Trust centra Microsoftu, které přímo oznamuje, že je v souladu s GDPR pro EU a můžete si přečíst přímo uvedené dokumenty k této problematice.

Microsoft s oznámením vstupu GDPR do EU přišel s úpravou a vlastní definicí všech služeb, které jsou v souladu s tímto zákonem, a informuje zákazníky o svých produktech, které je možno nasadit a být tak minimálně z technologického pohledu v souladu. Níže můžete vidět jednotlivé produkty společnosti Microsoft, které jsou přímo uvedeny v Trust Centru a splňují podmínky GDPR:

Závěrem – je na čase jednat!

Myslíte si pořád, že je dost času? Máte na to stihnout vše nasadit do dubna 25.5.2018? Já si myslím, že se to stihnout nedá, pokud budete celou cestu procházet svépomocí a budete se všechny nové funkce učit používat. Dalším důvodem může být i to, že jsme se bavili jen o prostředí Microsoft, ale co Linux (zde máte jedinou výhodu a to, že Microsoft umí do Operation management Suite integrovat i Linux servery), vlastní aplikace a papírová data? Musíte přeci ošetřit informace i tam, zavést jen elektronickou komunikaci a papírová data ponechat rovnou v kartotékách, když přijdou na podatelnu.

Doporučoval bych nasadit nějaký workflow systém a zpracovávat všechny dokumenty elektronicky včetně indexace obsahu, abyste mohli s daty dále mnohem lépe pracovat.

Předpokládám, že si myslíte, že toto bude stát vaši firmu miliony, ale není tomu tak. V tomto článku jsem mluvil jen o produktech

  • Windows 10 Enteprise E3 nebo E5
  • Office 365 E3 nebo E5
  • Enteprise Mobility + Security E3 nebo E5
  • Operation management Suite Free/Standard/OMS nebo E3/E5
  • Microsoft Azure

Licence Office365 a EMS stojí dneska již pár korun měsíčně (1000Kč/uživatel/měsíc) na uživatele a ochráníte s nimi všechna jeho zařízení (5x Office a 15x EMS) případně je možno cca za 1500Kč/uživatele využít licenci, ve které máte k Office365, EMS ještě licenci Windows 10 Enteprise, která pomůže ochránit i koncový operační systém. Azure, lze rozpočítat tak, že vás bude stát stejně jako lokální infrastruktura a OMS lze provozovat i zdarma, ale já bych doporučil licenci za cca 300Kč na server měsíčně.

Výše jsem se snažil nastínit ty největší a nejsilnější nástroje pro zajištění bezpečnosti s pomocí platformy Microsoft, ale pokud bychom šli do úplného detailu pak těch nástrojů je mnohem a mnohem více, ale cíle společnosti Microsoft je interpretace do jediného umístění a to tzv. „Cybersecurity Centera“, které by mělo jednou shromažďovat všechny bezpečností informace a být tak hlavním místem a rozcestníkem právě pro role „Data Protection Officer“ nebo „Chief Information Security Officer“. Na celkový přehled všech nástrojů se můžete podívat níže.

image

Tak poslední věcí, která zde přichází na řadu je konkurence v této oblasti. I když to dělám velice nerad srovnávat produkty, jelikož společnosti na dané problematice pracují již dlouhá léta a mohu říct, že byly nejlepšími z nejlepších pro auditování infrastruktury a zajištění bezpečnosti formou „Vím, co moji uživatelé dělají na serverech“ a nikoliv „Odepřu všem přístup a nic se nemůže stát“. Jedná se o produkty jako Quest od Dellu a nástroje od společnosti Netwrix. Tyto nástroje jsou úžasné, pokud bychom řídili bezpečnost jen na serverech a potřebovali velmi rychle auditovat co se mi zde děje. Například netwrix oznámil, že v rámci GDP řeší tyto oblasti:

image

Po podrobnějším prozkoumání jejich dokumentu, jsem ale došel k závěru, že řešit bezpečnost jen na úrovni serverů, je trošku alibizmus a podle mne (to neberte prosím jako dogma) by to před auditorem neprošlo, jelikož se nejedná o komplexní bezpečnost z pohledu pohybu citlivých informací ve firmě. Možná to však neměl být ani účel těchto řešení.

Proto se prosím zamyslete, s kým budete chtít fungovat v dalších letech, kdo vám bude dávat tu přidanou hodnotu v technologiích a také si řekněte, zda budete i nadále na platformě Microsoft Windows/Azure/Office. Pokud jste si řekli na předešlé otázky „ano“, pak kdo v tomto ohledu pro vás má řešit bezpečnost. Platforma Microsoft se velice rychle vyvíjí a bezpečnost kolegové z Microsoftu myslí opravdu vážně a hlavně komplexně napříč svými produkty.

Pokud byste měli zájem, tak je možno se domluvit a já nebo někdo z našeho týmu KPCS vám pomůže spočítat náklady na takto komplexní řešení.

GDPR na platformě Microsoft - jak pomáhá Azure, OMS, EMS, Office 365 a Windows 10 - část 2

Vytisknout E-mail

Daniel Hejda Datum zveřejnění: 10. 2. 2017 13:24 Zobrazeno: 1969
1 1 1 1 1 1 1 1 1 1 Rating 0.00 (0 Votes)

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

imageimage

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.

imageimage

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..

image

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.

imageimage

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.

image

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

AccessMask Value

Constant

Description

0 (0x0)

FILE_READ_DATA

Grants the right to read data from the file.

0 (0x0)

FILE_LIST_DIRECTORY

Grants the right to read data from the file. For a directory, this value grants the right to list the contents of the directory.

1 (0x1)

FILE_WRITE_DATA

Grants the right to write data to the file.

1 (0x1)

FILE_ADD_FILE

Grants the right to write data to the file. For a directory, this value grants the right to create a file in the directory.

4 (0x4)

FILE_APPEND_DATA

Grants the right to append data to the file. For a directory, this value grants the right to create a subdirectory.

4 (0x4)

FILE_ADD_SUBDIRECTORY

Grants the right to append data to the file. For a directory, this value grants the right to create a subdirectory.

8 (0x8)

FILE_READ_EA

Grants the right to read extended attributes.

16 (0x10)

FILE_WRITE_EA

Grants the right to write extended attributes.

32 (0x20)

FILE_EXECUTE

Grants the right to execute a file.

32 (0x20)

FILE_TRAVERSE

Grants the right to execute a file. For a directory, the directory can be traversed.

64 (0x40)

FILE_DELETE_CHILD

Grants the right to delete a directory and all the files it contains (its children), even if the files are read-only.

128 (0x80)

FILE_READ_ATTRIBUTES

Grants the right to read file attributes.

256 (0x100)

FILE_WRITE_ATTRIBUTES

Grants the right to change file attributes.

65536 (0x10000)

DELETE

Grants the right to delete the object.

131072 (0x20000)

READ_CONTROL

Grants the right to read the information in the security descriptor for the object.

262144 (0x40000)

WRITE_DAC

Grants the right to modify the DACL in the object security descriptor for the object.

524288 (0x80000)

WRITE_OWNER

Grants the right to change the owner in the security descriptor for the object.

1048576 (0x100000)

SYNCHRONIZE

Grants the right to use the object for synchronization.

Čí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.

image

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.

imageimage

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.

image

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..)

image

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

image

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

image

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.

image

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.

image

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ý.

image

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.

Single Sign On pro Azure AD Connect

Vytisknout E-mail

Daniel Hejda Datum zveřejnění: 9. 1. 2017 21:20 Zobrazeno: 708
1 1 1 1 1 1 1 1 1 1 Rating 0.00 (0 Votes)

Dříve bylo nutné pro zajištění Single Sign On využívat služby ADFS, které byly publikované skrze Web Application Proxy server. Dnes se však podíváme na tuto novinku, která byla uvolněna do Preview v Prosinci 2016 a přináší velké úspory z pohledu budované OnPremise infrastruktury. Umožňuje využívání Single Sign On (dále také SSO) bez nutnosti instalace Active Directory Federation Service (dále také ADFS) a Web Application proxy jako ADFS proxy (dále také WAP).

Abychom mohli provést toto nastavení, je nutné upgrade Azure AD Connect služby minimálně na verzi 1.1.370.0 v rámci, které byla tato funkcionalita umožněna (k dnešnímu dni už existuje verze 1.1.380.0 z prosince 2016.

Tento upgrade, jak píše Microsoft, není dostupný pro automatický upgrade vašeho Azure AD Connect a proto v případě, že chcete využívat této funkcionality, je nutné provést update služby ručně pomocí In-Place update Azure AD Connect.

Nejprve je nutné tedy stáhnout požadovaný update ze stránek společnosti Microsoft. Bohužel Microsoft uvolňuje vždy poslední build a tak je potřeba se podívat zda tento build chceme a zda nám přináší to co potřebujeme. V rámci FAQ Microsoftu existuje internetová stránka s release History pro Azure AD Connect: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-version-history , ve které najdeme vždy novinky a další věci co nám, který build přináší.

Tento návod nedoporučuji zákazníkům, kteří se ve službě Azure AD Connect nevyznají a neví jakým způsobem provádět troubleshoting Azure AD Connect, jelikož se jedná o klíčovou službu třeba pro Office365 může být vhodné zvolit si správného partnera, který vám upgrade provede a bude následně schopen velmi rychle najít řešení v případě vzniklého problému. Posledním doporučením je mít platnou zálohu nastavení Azure AD Connect služby.

Takže můžeme začít. Nejprve tedy stáhneme Azure AD Connect ze stránek společnosti Microsoft, přičemž se musíme podívat, zda je zde uvedena požadovaná verze Azure AD Connect služby:

https://www.microsoft.com/en-us/download/details.aspx?id=47594

image

Poté spustíme stažený MSI balíček, který nám nabídne provedení upgrade na serveru a informuje nás, že služba po dobu upgrade nebude dostupná, dokud nebude upgrade proveden.

image

Jakmile je upgrade hotov je nutno provést kontrolu služeb a zkontrolovat ve službách zda se provedlo jejich automatické spuštění. Následně se pak přihlásit do aplikace „Synchronization Service“ a provést kontrolu pomocí položky „About“ zda je služba upgradována na požadovanou verzi a zda nám funguje synchronizace.

Nyní jsme tedy provedli instalaci nové verze Azure AD Connect a určitě chceme zapnout funkcionalitu Azure AD Connect SSO. Abychom mohli toto udělat je nutno zajistit, aby doména, pro kterou bude SSO platné měla v Azure AD nastavenu hodnotu Managed místo Federated, pokud jsme používali ADFS a WAP, pokud ne tak výchozí hodnota každé domény je Managed. Přepnutí zpět do stavu Managed můžeme provést jednoduchým powershell příkazem po přihlášení do Online Služeb z powershellu.

Tento příkaz provede změnu nastavení:

- Set-MsolDomainAuthentication -DomainName {domain} –Authentication Managed

Je nutno počítat s tím, že daná změna nějakou dobu trvá a může to být až 120 minut než se doména přepne zpět z vašeho ADFS a proto si nechte na provedení změny dostatečné časové okno. Také je velmi vhodné, aby uživatelé nic nepoznali, provést změnu Comapny Brand skrze https://portal.azure.com nebo https://manage.windowsazure.com a nastavili si potřebná loga a další hodnoty, jako odkazy na helpdesk případně nějaké popisky.

Nyní máme tedy přepnutu MSOL doménu na „ADFS servery“ v Azure AD a můžeme přejít k vlastnímu nastavení SSO. Toto nastavení se provádí z aplikace Azure AD Connect a to spuštěním aplikace „Azure AD Connect“, která je schopna provádět globální nastavení a zapínání funkcionalit, případně vám umožňuje přepnutí do Active nebo Staging modu.

image

Pokud máme spuštěnu aplikaci, můžeme zvolit položku „Configure“ a přejít k vlastnímu nastavení. Po jejím zvolení se nám ukáží možnosti služby Azure AD Connect (Additional Task). Měli bychom nejprve provést kontrolu, zda chceme využívat Password synchronization a nebo Pass-through autentizaci. A proto vybereme položku „Customize synchronization option“.

image

Proklikáme jednotlivé kroky, až se dostaneme k položce „Optional Feature“ a zde buď zapneme nebo vypneme položku Password Synchronization.

image

Tak a nyní je asi dobré si říct, proč Password Synchronization. Azure AD Connect SSO umožňuje využívat 3 typy autentizace a to Password hash synchronization a nebo Pass-through authentication nebo Federaci skrze ADFS (tu jsme využívali dříve a dneska se jí nebudeme zabývat).

Tudíž pokud bychom chtěli, aby Azure AD posílalo vždy dotaz na heslo do naší infrastruktury a hesla nebyla cachovaná v Azure AD musíme použít Pass-through authentication a tudíž vypnout Password Synchronization. Toto je určitě bezpečnější řešení, nicméně bez služby Azure AD Connect nebude nikdy fungovat přihlášení například do Office365, CRM Online, atd.. a pokud máte jen jeden server, pak bych doporučil spíše hesla synchronizovat.

image

Pokud tedy máme jen jeden server a chceme, aby byla služba méně závislá na naší infrastruktuře a výpadek služby neměl fatální dopad na služby jako Office365, pak ponecháme nebo zapneme Password synchronization v Azure AD Connect a využijeme tak služby Password hash synchronization.

image

Nyní tedy dokončíme nastavení. Máme provedeno nastavení pro synchronizaci hesel do Azure AD a musíme povolit novou funkcionalitu Azure AD Connect SSO, které se povoluje po spuštění aplikace „Azure AD Connect“, jen v Additional Task vybereme možnost „Change user Sign-In“, jak je uvedeno na obrázku níže.

image

Zde můžeme tedy provést změny nastavení a povolit nastavení „Pass-through authentication“ nebo ponechat nastavení na „Password Synchronization“, ale také je nutno níže zaškrtnout „Enable single sign on“. Poté co zaškrtneme toto volbu, budeme moci modifikovat nastavení pro SSO. Abychom, mohli celou konfiguraci dokončit, bude nutné přiřadit službě účet s právy Domain Admins. Microsoft pro Azure AD Connect a jeho instalaci uvádí, že byste měli mít účet s právy Enterprise Admins, aby mohla probíhat synchronizace. Pod tímto účtem běží služba Azure AD Connect v systému a jelikož musí být na úrovni forestů instalován Azure AD Connect server jen jednou, je nutné, aby daný účet měl přístup do všech domén ve forestu. Pro SSO vyžaduje však účet práva Domain Admins a to explicitně, nelze tedy říci, že Enterprise Admins je dostatečný, i když má vyšší oprávnění, než Domain Admins a proto tato práva musíte účtu nastavit explicitně. Takže přiřadíte účet do skupiny, nastavení v konfiguraci a je téměř hotovo.

Aby bylo na klientech možno využívat Kerberos a bylo umožněno SSO pro klienty je nutné provést ještě jedno nastavení v rámci klientského operačního systému a to nastavení v Trusted Site. Nastavení je možno provést ručně anebo pomocí GPO. Je určitě dobré toto nastavení udělat hned na začátku, abychom měli jistotu, že klienti mají toto nastavení natažené, a že nedojde k problému s přihlášením do služeb Office365. Služby Office365 s ADFS využívali nastavení Trusted Site také, aby bylo zajištěno SSO a proto stačí danou Group Policy pouze rozšířit o nové URL. Pokud ji však nemáte nastavenu vůbec, pak je vhodné použít tato nastavení pro klientské Trusted Site nastavení v internetovém prohlížeči.

V rámci Intranet Zone je nutno zajistit, aby existovali tyto stránky:

  • https://autologon.microsoftazuread-sso.com
  • https://aadg.windows.net.nsatc.net
  • *.microsoftonline.com
  • *.sharepoint.com
  • *.outlook.com
  • *.lync.com

V rámci Trusted Site je nutno zajistit, aby existovali tyto stránky:

  • https://*.outlook.com/
  • https://*.sharepoint.com/
  • https://*.microsoftonline.com/
  • https://*.lync.com/

Tím je celé nastavení hotové a můžeme využívat na klientech SSO skrze Azure AD Connect.

A jak to vlastně funguje?

Uživatel se pokusí přistoupit na nějakou Online službu integrovánu s Azure AD a to za předpokladu, že daná URL aplikace je umístěna v Trusted Site. Uživatel této službě předá své uživatelské jméno (userPrincipalName) a služba Azure AD zjistí, zda je pro danou doménu (domain sufix) povoleno jednotné přihlášení. Za předpokladu, že je přihlášení povoleno probíhá následující proces ověření uživatele:

  1. Azure AD vrací na klienta odpověď 401 v Kerberos tiketu
  2. Klient požádá interní Active Directory o vystavení Kerberos tiketu pro službu Azure AD
  3. Active Directory vyhledá účet počítače v doméně
  4. Pokud jej najde, pak vystaví Kerberos tiket, který je šifrovaný pomocí účtu počítače a obsahuje uživatelské jméno pro přístup do Azure AD
  5. Klient vezme tento Kerberos tiket a odešle jej do služby Azure AD
  6. Azure AD pomocí předem sdílného klíče rozšifruje tento tiket a buď povolí uživateli přístup k interním zdrojům, nebo si vyžádá další úroveň ověření, jako je například multifaktor

Pokud se ověření nepovede, je uživatel požádán o zadání hesla přístupu. Tato situace může nastat za předpokladu, že klientský počítač je sice členem domény, ale z nějakého důvodu se nemůže přihlásit k doménovému řadiči nebo není služba Azure AD Connect dostupná. Výpadek služby Azure AD Connect však neznamená nefunkčnost služby, ale pouze snížení komfortu uživatele.

Pamatujte, že je nutné vždy zajistit, aby:

  • Počítač byl členem domény
  • Fungovala komunikace na Active Directory a byl viditelný alespoň jeden doménový řadič
  • Měli jste nastaveny Trusted site na klientském PC

Dále je nutné pamatovat na to, že fungování těchto služeb je zajištěno jen u níže uvedených internetových prohlížečů a operačních systémů.

Závěrem

Tímto jsme se posunuli k větší nezávislosti na interní infrastruktuře a zajištění komfortu uživatelů pro přístup do Online služeb jako jsou například Office365. Dříve totiž výpadek ADFS nebo WAP znamenal nefunkčnost celé služby. Nyní však nové nastavení znamená pouze snížení komfortu uživatelů a tím i větší prostor na případný troubleshoting dané služby.

Upgrade Azure AD Connect

Vytisknout E-mail

Daniel Hejda Datum zveřejnění: 9. 1. 2017 21:14 Zobrazeno: 598
1 1 1 1 1 1 1 1 1 1 Rating 0.00 (0 Votes)

V rámci Azure AD Connect jsou vydány poměrně často upgrade (i 3x do měsíce). Tento nástroj pod názvem Azure AD Connect (dříve DirSync) zajišťuje synchronizaci identit do Office365, Azure, SaaS aplikací, atd.. a tím umožňuje administrátorům zajistit jednotné identity v rámci interního a online prostředí. Služba Azure AD Connect je jakousi náhražkou a do budoucna bude určitě náhražkou služby FIM nebo MIM (Identity Manager), zatím však neposkytuje tolik funkcionalit jako velké robustní nástroje pro synchronizace, ale zase je zadarmo a dá se využívat i k jiným věcem než je synchronizace do Online prostředí. Každopádně dneska se podíváme na možnosti upgrade tohoto nástroje a umožnění tak nových funkcionalit.

Nejprve se podíváme jako jsou možnosti pro provedení upgrade Azure AD Connect služby na vašem serveru. Služba Azure AD Connect od update 1.1.105.0 z února 2016 přináší možnost automatického update služby Azure AD Connect, kterou můžete modifikovat. Tato služba je ve výchozím stavu nastavena na Suspended a proto je určitě vhodné ji změnit, pokud používáme Expresní nastavení Azure AD Connect.

Pro update máme možnost vydat se hned několika scénáři a to:

  • Automatický update
  • In-place update
  • Swing migration

Automatický update se používá u zákazníků, kteří využívají expresní konfiguraci služby Azure AD Connect. Tento upgrade není tak náročný a jeho provedení se provádí automaticky změnou nastavení pomocí powershellu. Při tomto update se předpokládá, že jsou služby jako SQL Express nebo WID instalovány přímo na serveru, kde běží aplikace Azure AD Connect a konfigurace obsahuje méně než 100 000 objektů pro synchronizaci. Aby byl upgrade proveden automaticky musí být funkční služba Health Service.

In-Place update se používá většinou ve scénáři, kdy existuje jedna jediná instance Azure AD Connect serveru s odděleným SQL serverem a při synchronizaci více jak 100 000 objektů. Případně, když je použit Forefront Identity manager s Azure AD Connectem nebo potřebujete nainstalovat nějakou verzi Azure AD Connect, která není pro automatický update dostupná.

Swing migrace se používá v případě, kdy využíváme 2 a více Azure AD Connect serverů a potřebujeme zajistit, aby byla služba dostupná vždy, jelikož v předchozích scénářích to znamená výpadek této služby a jak si ukážeme dále bude více a více vhodné mít 2 servery v režimu Active - Staging. Tento model využívá provedení upgrade na serveru ve stavu Staging, následně jeho přepnutí do Active a původního serveru do stavu Staging. U tohoto upgrade je možno zajistit nejkratší výpadek a nedostupnost celé služby.

image

Jednotlivé modely si dnes popisovat nebudeme a podíváme se spíše na nastavení automatického update, který bude asi většina z vás využívat. Tento model má 3 možnosti nastavení a to Enable, Disable a Suspend. Po instalaci Azure AD Connect služby je většinou stav této služby nastaven na hodnotu Suspend, což pro nás nemusí být vhodnou cestou, jelikož chceme mít služby vždy Up-To-Date a chceme mít možnost využívat nové funkcionality.

Změnu nastavení Azure AD Connect update můžeme provést jediným powershell příkazem přímo na Azure AD Connect serveru a to Set-ADSyncAutoUpgrade Enable/Disable/Suspend. Osobně bych doporučil nastavit ihned po instalaci na Enable, přičemž je nutno sledovat hodnoty v Event logu zda se služba korektně přepnula do tohoto stavu.

image

Požadovaný Event log se skrývá pod Event ID 300 - 399 a s názvem Event Source "Azure AD connect Upgrade". Hodnota, kterou v Event logu uvidíte, může být v níže uvedených hodnotách.

Result Message

Description

UpgradeAborted

 

UpgradeAbortedCouldNotSetUpgradeMarker

Could not write to the registry.

UpgradeAbortedInsufficientDatabasePermissions

The built-in administrators group does not have permissions to the database. Manually upgrade to the latest version of Azure AD Connect to address this issue.

UpgradeAbortedInsufficientDiskSpace

There is not enough disc space to support an upgrade.

UpgradeAbortedSecurityGroupsNotPresent

Could not find and resolve all security groups used by the sync engine.

UpgradeAbortedServiceCanNotBeStarted

The NT Service Microsoft Azure AD Sync failed to start.

UpgradeAbortedServiceCanNotBeStopped

The NT Service Microsoft Azure AD Sync failed to stop.

UpgradeAbortedServiceIsNotRunning

The NT Service Microsoft Azure AD Sync is not running.

UpgradeAbortedSyncCycleDisabled

The SyncCycle option in the scheduler has been disabled.

UpgradeAbortedSyncExeInUse

The synchronization service manager UI is open on the server.

UpgradeAbortedSyncOrConfigurationInProgress

The installation wizard is running or a sync was scheduled outside the scheduler.

UpgradeNotSupported

 

UpgradeNotSupportedCustomizedSyncRules

You have added your own custom rules to the configuration.

UpgradeNotSupportedDeviceWritebackEnabled

You have enabled the device writeback feature.

UpgradeNotSupportedGroupWritebackEnabled

You have enabled the group writeback feature.

UpgradeNotSupportedInvalidPersistedState

The installation is not an Express settings or a DirSync upgrade.

UpgradeNotSupportedMetaverseSizeExceeeded

You have more than 100,000 objects in the metaverse.

UpgradeNotSupportedMultiForestSetup

You are connecting to more than one forest. Express setup only connects to one forest.

UpgradeNotSupportedNonLocalDbInstall

You are not using a SQL Server Express LocalDB database.

UpgradeNotSupportedNonMsolAccount

The AD Connector account is not the default MSOL_ account anymore.

UpgradeNotSupportedStagingModeEnabled

The server is set to be in staging mode.

UpgradeNotSupportedUserWritebackEnabled

You have enabled the user writeback feature.

Některé update však nejsou podporované pro automatický update jako například služba pro Single Sign On a proto musíme použít jinou metodu update, jak si ukážeme v následujcím článku.

Rád bych vás i tímto upozornil, že možnost automatického update může být jeden z důvodů proč přejít ze starého DirSync nástroje na Azure AD Connect. Dále pak je vhodné provést reinstalaci DirSync na Azure AD Connect nejpozději do dubna 2017, jelikož Microsoft přestane aplikaci DirSync podporovat a je velice pravděpodobné, že ani synchronizace nebude po nějaké době fungovat.

GDPR na platformě Microsoft - jak pomáhá Azure, OMS, EMS, Office 365 a Windows 10 - část 1

Vytisknout E-mail

Daniel Hejda Datum zveřejnění: 5. 1. 2017 13:23 Zobrazeno: 2337
GDPR na platformě Microsoft - jak pomáhá Azure, OMS, EMS, Office 365 a Windows 10 - část 1 - 5.0 out of 5 based on 1 vote
1 1 1 1 1 1 1 1 1 1 Rating 5.00 (1 Vote)

Původně jsem dneska chtěl psát úplně něco jiného, ale můj kolega Martin Pavlis ve mně vyvolal potřebu, sednou a napsat tento článek. Původní nápad byl napsat konečně druhý díl seriálu o Operation Management Suite, nicméně mě pohltila potřeba napsat o novém zákonu, který bude uveden v platnost 25. 5. 2018 a hodně společností si určitě myslí, že je tudíž dost času na přípravu. Jedná se o úpravu zákona o ochraně a zpracování osobních údajů a citlivých informací, který bude vycházet ze zákona 101/2000 sb. ze dne 4. 4. 2000.

Nejprve obecně

Každý z nás kdo vlastní nějakou firmu ví, že informace o zákazníkovi a tím nemyslím jen jméno, ale veškeré běžné informace jako nabízí k evidování například Microsoft Dynamics CRM (kdy má zákazník narozeniny, kolik má dětí, jak jsou jeho děti staré, jaké má zájmy, co rád jí, atd..) jsou velkým přínosem pro dodavatele, který je pak schopen cílit reklamu, služby anebo jen prezenty zákazníkovi a budovat si s ním vztah nejen na obchodní, ale i osobní úrovni.

Malá odbočka: Nejsem sice úplně nadšený, že o mě můj dodavatel ví všechno (banka, operátor, atd..), ale svěřil jsem mu své citlivé informace dobrovolně a spoléhám na to, že tato data dokáže ochránit před útočníky nebo před interními zaměstnanci a má data nebudou sdílena na internetu. Rozhodně je tento scénář lepší než situace, kdy mi volá 3x za sebou v jednom týdnu slečna z nějakého Call centra a pokaždé mi nabízí stejný produkt a myslí si, že se dovolala novému zákazníkovi, a já jí 3x s „díky nechci“ odmítnu. Pokud by to udělala ta holčina po 4, tak bych už mohl být poměrně sprostý. To mi přijde velice smutné L, jelikož procesy pro „cold call“, ve společnostech jako jsou někteří naši operátoři, nefungují.

V každém z nás kdo má vlastní firmu a pracuje s daty zákazníků, tak se snaží zabezpečit své prostředí maximálním možným způsobem, jak mu jeho zkušenosti a cash flow dovolují. Hodně firem (nemohu jmenovat, ale pár jich znám) pracuje s daty zákazníků, ale zabezpečení na datové úrovni je velmi nízké až žádné a to nemluvím o bezpečnosti infrastrukturní, kdy každý 15-letý kluk co se podívá na youtube.com se dokáže do jejich systému nabourat s nějakým 3 roky starým payloadem spuštěným z Backtracku nebo KaliOS.

imageA těmto společnostem svěřujeme své citlivé informace? Možná je na čase, aby se to změnilo a právě proto možná přichází tato úprava zákona, na který nikdo nesáhl od doby, kdy byly počítače jako ten níže a internetová linka byla někde na úrovni modemu s 56kbps nebo jako jsem měl já 24kbps na downloadu. V té době také vyšel a byl použit jeden z nejúčinnějších virů ILOVEYOU J, který dokázal hodně lidem zamotat hlavu. V té době fungovali viry spíše jako destrukční nástroje pro ničení počítačů a nikdo tenkrát ještě nepřemýšlel (moje domněnka), že bude možné vykrádat identity a sledovat chování lidí vzdáleně a to jen díky počítačům a internetu.

Nový zákon

V květnu 2018 přijde v platnost nový Evropský zákon, který nařizuje, aby byla citlivá a osobní data chráněna. Bohužel se zatím neví přesně, jaká bude povinnost datové ochrany, ale již nyní se ví, že za porušení a odcizení citlivých informací bude společnosti hrozit pokuta až 20 milionů eur nebo 4% z celkového ročního OBRATU, záleží, co bude vyšší. Toto by mohlo být pro většinu firem likvidačním kritériem. Nepředpokládám, že by na Útvaru ochrany osobních údajů (ÚOOÚ) seděla armáda hackerů, kteří se budou snažit prolomit ochranu dané společnosti, ale klidně bych věřil, že za zveřejnění nebo udání bude vyplácena odměna (toto je jen spekulace) z vysouzené částky. Bohužel se zatím ani neví, jak bude částka vymáhána.

Očekávání

Zákon již hovoří o nové roly v organizaci, kterou nebude moci zastávat ani IT ani ředitel, či team leader, ale bude nutné vyspecifikovat osobu, která bude za data odpovědná. Tato osoba má mít pozici „Pověřenec za správu citlivých informací“, já bych tuto pozici nazval Security Officer, ale dle zákona se jedná o roly Data Protection Officera (dále také DPO).

Pokud bychom se podívali na platy.cz nebo jiný portál informující o platu takové osoby, pak se bude plat pohybovat v řádu desetitisíců korun (řekl bych spíše 100 000Kč hrubého v závislosti na odpovědnosti za svěřená data, úrovni specializace této osoby a velikosti organizace)

image

Myslím, že daná osoba by měla mít minimálně tento profil:

  • IT znalý administrátor na všech vrstvách
  • Přehled v technologiích a trendech IT
  • Znalost procesních metodik jako ITIL
  • Zkušenost z praxe s vytvářením bezpečnostních směrnic
  • Se schopností prezentovat navržená řešení
  • Důvěryhodný a precizní

A podle toho profilu, hledáte v dnešní době skoro Supermana, protože tací lidé prostě nejsou a pak je tedy otázkou, zda můžete připravit procesy, nasadit systémy, vyškolit lidi a outsourcovat třeba auditora, který k vám bude docházet jednou za 14 dní a kontrolovat procesy a jejich fungování.

Zákon se dotkne nejvíce společností, které provozují e-shopy, telco služby, bankovní služby, státní a obecní instituce, atd... Bohužel v těchto subjektech je předpoklad značného kapitálu k zajištění bezpečnosti, ale co malé e-shopy (firma 10 – 50 lidí) ta by v případě úniku citlivých informací mohla zavřít a částku splácet do smrti.

Co jsou citlivé informace a co bude zákonem sledováno v rámci GDPR?

Informace, které se vztahují k identifikované nebo identifikovatelné fyzické osobě.

Veškeré informace – obrazové, slovní, rentgenové snímky, IP adresa, Cookies,

Dané obsahem – např. jméno, adresa, pracovní pozice. (pouze jméno není osobní údaj se smyslu GDPR, jen na základě jména nelze jednoznačně identifikovat).

Obecné: Jméno, Pohlaví, Věk a datum narození, osobní stav, občanství IP adresa, fotografický nebo biometrický údaj

Organizační: osobní nebo pracovní adresa, osobní nebo pracovní telefonní číslo, osobní nebo pracovní email, identifikační čísla vydaná státem (např. rodné číslo)

Speciální: etnický původ, náboženské vyznání, členství v odborech, zdravotní stav, sexuální orientace, genetické a biometrické údaje

Začněme, ale od začátku

Je potřeba začít jednat nyní? Nemůžeme třeba počkat na konec roku, až budeme mít ty nevyčerpané budgety, které bychom investovali? Moje odpověď je NE, musíte začít hned, nemyslím tím zítra, ale minimálně tento měsíc J. Rád bych na vás apeloval, abyste neudělali tu chybu, že nasadíte systém a budete si myslet, že jste vše vyřešili. Tak to bohužel není, jelikož musíte vždy nejprve plánovat, analyzovat a pak teprve dělat.

A jak tedy na to?

Nejprve je důležité naučit společnost přemýšlet jinak, a to tak, že data, se kterými pracují, jsou data citlivá a osobní, a že každému z nich by se také nelíbilo, kdyby s jejich informacemi někdo nakládal neuváženě, čímž uvedete v život proces práce s dokumenty a to i za cenu, že jste nenasadili jediný systém, ale jen změnili uvažování společnosti. Abyste však mohli vyhodnotit a prokázat, že proces funguje, musíte jej měřit a vyhodnocovat. Jelikož se jedná o obrovská data („Big Data“) tak je nutné vše dělat velmi efektivně.

Dalším krokem by ve vašem případě mělo být nastavení přesné směrnice, která bude definovat minimálně:

  • Jak je s daty nakládáno
  • Jak jsou data zabezpečena
  • Kdo má k datům přístup
  • Jaká jsou eskalační schémata při zjištění pokusu o odcizení dat
  • Jaká jsou eskalační schémata při průniku a odcizení dat
  • V jakých systémech se data objevují
  • Jak jsou data přenášena
  • Jak jsou data uchovávána a archivována
  • Atd..

Následně bude nutné uvést v život tuto směrnici a stanovit procesy, kontrolovat a hlavně měřit. Někde jsem četl jedno MOTTO (asi někde na LinkedIn) „Co neměřím, to neřídím“ a stejné je to se směrnicemi. Společnosti je píší, ale nedokáží kontrolovat, zda jsou dodržovány, jelikož si evidentně myslí, že vydání směrnice společnost vyvazuje z odpovědnosti a že udělaly maximum pro to, aby prosadily svou vůli.

Abychom mohli proces a jeho funkčnost měřit, je nutno provádět audit a to ne jen tak ledajaký, ale je potřeba provádět datový audit online (při každé změně, zapsání, smazání nebo stažení záznamu s citlivým údajem), bohužel se bude jednat (v závislosti na velikosti organizace) o obrovské objemy dat jako v případě jedné z položek zákona o Kybernetické bezpečnosti, kdy je nutno uchovávat logy ze systémů k pozdějšímu vyhodnocení.

Jelikož je, podle mého názoru, velice těžké měřit zda se směrnice dodržují, musí přijít na řadu ten horší způsob a tím je technologie - zamezení přístupu a sledování aktivity s daty – „big brother nad daty zákazníků“

A nyní přicházíme konečně po 3 stránkách textu k věci. Jelikož jsem osoba orientovaná na Microsoftí technologie budu vše pasovat do IT Roku 2017 a výše J tudíž do cloudu, kam někteří z vás nechcete.

Technologie

Myslíte si stále, že je dost času na implementaci po tom co vám někdo řekl, že nejprve bude potřeba proces? Pojďme si to namapovat na vrstvy, abychom věděli kde, co chceme chránit:

  • Fyzická bezpečnost
  • Switche
  • Firewally
  • Hypervisory
  • Virtuální servery
  • Databáze
  • Souborové servery
  • Identitní systémy
  • Aplikační servery
  • Webové servery
  • Aplikace
  • Klientské operační systémy

Kybernetická bezpečnost je však mnohem komplexnější proces a nevychází jen z vlastních vrstev od Hardware až po aplikace a koncové operační systémy, ale také sleduje chování osob, jejich tendence k prozrazení citlivých informací formou konzultace s kamarádem, atd.. a i tyto procesy je nutno mapovat a prověřovat. Níže je uvedená krásná Mind mapa (autor: Henry Jiang, CISO, CISSP), která ukazuje vrstvy a oblasti kybernetické bezpečnosti.

image

My se v této oblasti budeme zabývat tou oranžovou částí s názvem Security Engineering“ a částečně žlutou oblastí „Security Operation“ a jen lehce se podíváme i do fialové části „Threat Inteligence“, ale těch oblastí zájmu je ještě mnohem a mnohem více, ale spousty jich jsou právě obtočeny okolo procesů a certifikací společnosti.

Fyzická bezpečnost

Na úrovni fyzické vrstvy máme možnost se vydat několika směry, které nám poskytnou určitou úroveň fyzické bezpečnosti.

  • Umístíme data do naší vlastní serverovny a dáme IT oddělení klíče, aby mohlo spravovat servery, ale co když mu klíče někdo ukradne, nebo je ztratí. Tudíž máme možnost zabezpečit biometirií, pak můžeme věřit, že jsou naše servery v bezpečí. Ale abychom v to mohli věřit, tak musíme měřit a vyhodnocovat, takže bude nutné nastavit kamerový systém, alarm na vstupu a automatickou notifikaci SMSkou na bezpečnostního managera, případně na DPO.
    • Toto zabezpečení nás bude stát nemalé úsilí, ale pevně věřím, že většina firem má fyzickou bezpečnost vyřešenu
  • Umístíme data do hostingového centra čímž budeme důvěřovat zabezpečení prostředí na úrovni datového centra, jeho certifikaci spadající do nějakého Tieru a jelikož nám pracovník hostingového centra mile rád ukáže, jak celá bezpečnost u nich funguje, pak máme možná „jistotu“, že jsou naše data v bezpečí. Bohužel je však obrovské množství neznámých (kdo tam pracuje, je důvěryhodný, neudělá chybu, atd..) – navíc jsou většinou kóje spojené s jinými zákazníky a jednou se mi stalo, že klíče od mé „klece“ fungovali i do klece sousední. Určitou jistotou může být i hostingové centrum, které disponuje nějakou bezpečnostní certifikací ISO (27001, 27018).
    • Nikdy však nemůžeme mít důvěru v daného poskytovatele služeb, jelikož nedokážeme kontrolovat jeho procesy bezpečnosti a ještě se tím připravíme o možnost nasadit technologie, které nám pomohou ochránit obsah, nikoliv schránku
  • Umístíme data do cloudu (datové centrum někde ve světě) čímž ztrácíme naprostý přehled o tom, jak jsou naše servery zabezpečeny, a máme jedinou možnost věřit, že poskytovatel cloudu má dostatečně vyspělou bezpečnost svého prostředí o čemž mohou svědčit třeba jeho platné certifikace ISO, blue a red týmy pro testování bezpečnosti na perimetru a můžeme věřit, že bezpečnost těchto datových center je mnohem vyšší než bezpečnost lokálního hostera, který provozuje své služby na serverech NoName nebo Hande Made, aby ušetřil pár korun a zvýšil tím zisky. Když už se bavíme o Microsoftu, tak nové Virtuální servery v Azure jsou nasazovány na generaci 2 a pokud bychom se podívali na technologie, které jsou v datovém centru Azure implementovány, pak zjistíme že na každém zařízení je implementována technologie „Shielded VM“ a že ani z Hyper-V hosta není možné na virtuální servery zákazníků přistupovat, případně je možno v rámci virtuálního serveru nastavit službu Bitlocker a šifrovací klíče umístit do „Key Vault storage“, která nám zajistí 100% jistotu, že do vnitřku virtuálního serveru nebude mít nikdo přístup bez zápisu do logu a bez našeho vědomí. Velice by mne zajímalo, zda toto umí například Amazon Web Service a nebo nějaký lokální hoster. Můj tip je, že to neumí a dlouho ještě umět nebude, případně na to nemá procesy, aby mohl tento způsob hostingu provozovat.
    • Pokud tedy umístíme servery s citlivými informacemi například do Azure, pak máme jistotu, že jsou naše servery fyzicky ochráněné a díky potvrzení NBÚ pro Azure, máme jistotu, že je vše bezpečné a v souladu se zákony EU/ČR.

Switche a síťové prvky

Vždy budeme muset počítat s nějakými fyzickými aktivními prvky (Top of the Rack), i když jich více budeme mít virtualizovaných třeba v Hyper-V nebo v rámci VMWare. Tyto aktivní prvky však musí být schopny logovat to co se na nich děje, aby nemohlo dojít k nedovolenému nastavení například Port Mirroringu, který by zapříčinil posílání dat na další servery, kde by mohl být provoz odchycen. Toto by znamenalo vyměnil všechny staré aktivní prvky za nové, které umožní logování. Pokud bychom přesunuli své systému k nějakému velkému Cloud providerovi, pak máme problém vyřešen, jelikož veškeré síťové prvky jsou logovány do bezpečnostního centra poskytovatele a my pracujeme pouze se síťovými prvky virtuálními.

Firewally a routery

Zde je tato problematika o něco větší, jelikož přes tyto prvky prochází všechna komunikace a to i citlivé a osobní informace, které mohou být dokonce na daných aktivních prvcích dekryptovány (SSL Strip) a to z důvodu inspekce provozu. Pokud bychom tedy chtěli chránit svou infrastrukturu a nasadili UTM funkce firewallů a routerů, pak musíme počítat s tím, že dané zařízení do komunikace vidí a to nezabezpečeně, takže nehrozí jen problém s „Port Mirroringem“, ale také s „SSL Stripem“. Zde je tedy nutné nastavit plné Net Flow, které nám nasměruje provoz na nějaký Syslog server, kde budeme dané informace sbírat a vyhodnocovat, abychom vyhodnocováním nezatěžovali vlastní firewall, který by pak mohl odmítat přístupy z důvodu přetížení (toto se mi jednou stalo i u Fortigate 300D v clusteru, který se na httpd démonovi přetížil a zatěžoval RAM a CPU daného zařízení téměř na 90%, čímž docházelo ke kontinuálním výpadkům na VPN a Uplinku a nebylo možno ani predikovat, kdy se tak stane). To znamená logujte, přenášejte data mimo produkci a na servery, které budete mít ochráněné třeba pomocí technologie Bitlocker, šifrování během přenosu s SNMPv3 a pokud to bude VM, pak použijte ještě Shilded VM, aby se vám na dané zařízení nedostal ani administrátor Hyper-V serveru (VMWare myslím tuto izolaci VM nemá k dispozici).

- Zde bych měl možná ještě vhodnější řešení a to za pár korun (rozhodně méně než-li budovat z čisté vody vlastní řešení). Řešením může v tomto případě být implementace pomocí Operation Management Suite a jeho integrace třeba na nějaké lokální řešení jako je Systém Center Operation Manager, Nagios nebo Zabbix. Do budoucna /již brzy/ bude OMS schopno logovat i hardwarová zařízení, pravděpodobně skrze nějaký Syslog server. Díky implementaci tohoto řešení od Microsoftu je možno sledovat celé NetFlow na firewallech a v síti a tím eliminovat možnost přenosu nějakých citlivých informací. Níže je pár obrázků z prostředí, které mám nasazené ve svém LABu.

imageimageimage

Hypervisory

Bohužel ani virtualizační hostitelé, na kterých běží virtuální servery nemohou zůstat opomenuti. Čím více se usnadňuje správa prostředí, tím více získávají administrátoři práva k virtuálním serverům. V rámci Hyper-V se jedná například o Powershell Direct, díky kterému Hyper-V administrátor má možnost přímého zásahu do virtuálního serveru bez nutnosti znalosti hesla administrátora k vlastní virtuálnímu serveru. Explicitně lze říci, že Hyper-V administrátor má vyšší práva vůči virtuálnímu serveru nežli Domain nebo Enteprise administrátor. Proto je nutno na tuto technologii nasadit auditní režim, který by nám poskytl informace o tom co se s naším prostředím děje. Pokud bychom provozovali naše servery v rámci Azure prostředí, pak díky Shilded VM a odepření přístupu Powershell Direct máme možnost znemožnit přístup do virtuálku z vnějšku. Další možností pro zabezpečení přístupu je určitě nasazení auditního logu ve virtuálním serveru a to do event logu (powershell event log), který nám poskytne zpětně informace o provedených krocích, identitě, která provedla danou činnost a času kdy tato událost nastala. Abychom mohli vyhodnotit tyto informace globálně pak je potřeba informace sbírat do nějakého externího Syslog serveru, nebo jak bylo uvedeno výše do Operation Management Suite, který nám tyto informace sebere z daných zařízení a to nejen ze zařízení jako jsou servery, ale také z koncových pracovních stanic (tím, ale předbíhám, o stanicích se dočtete až dále).

image

Pokud bychom měli servery v cloudové službě Microsoft Azure, můžeme se věnovat bezpečnosti ještě mnohem více komplexněji a to jen díky jejich umístění do této platformy. Aplikace pro auditování jsou již v těchto systémech implementovány jak je vidět na níže uvedených obrázcích.

image

Případně můžeme použít i nové nástroje jako je PowerBI pro rychlé zobrazení bezpečnostních informací.

image

Virtuální servery

Nyní přichází tedy na řadu asi to nejhorší na zabezpečení a to zejména z důvodu, kdy k virtuálním serverům přistupují různí lidé z organizace. U hypervisoru máme vždy 1 – 2 správce, u sítí máme také 1-2 správce, ale u virtuálních serverů těchto správců můžou být desítky a o to spíše je nutné zde nasadit různé technologie, které nám pomohou zabezpečit celé prostředí. Nejedná se zrovna o jednoduchou disciplínu, a proto to vezměme postupně.

Operační systém

Zde musíme nasadit nějakou technologii, která nám bude auditovat přístupy, změny a event logy. Takže opět nějaký Syslog a případně agenta pro sledování co se na serveru děje. Doporučil bych určitě System Center Operation Manager, který bude sledovat server podle nějaké předem definované šablony a to zejména na prováděné změny, které se budou zaznamenávat do konfigurační databáze, tak aby bylo možno vždy porovnávat stav proti stavu aktuálnímu. Další možností, kterou máme je napsat si nějaké vlastní řešení na sledování změn anebo nainstalovat agenta a opět logovat vše do Operation management Suite. Níže je ukázáno, co můžete díky tomuto sledování získat a jak mohou být data v online režimu vyhodnocena.

imageimage

V příštích částech článku budeme pokračovat dalšími oblastmi.

Umístění CRL do Azure

Vytisknout E-mail

Miroslav Knotek Datum zveřejnění: 29. 8. 2016 6:58 Zobrazeno: 2080
1 1 1 1 1 1 1 1 1 1 Rating 0.00 (0 Votes)

V rámci jednoho z projektů nasazení PKI jsme nutně potřebovali vysoce dostupné umístění CDP (CRL Distribution Point) založené na HTTP protokolu. U zákazníka však v prostředí nebylo žádné vhodné existující vysoce dostupné řešení a stavět dva nové Windows Servery s rolí Web Server s použitím NLB jen pro umístění malého CRL souboru nám nedávalo úplně smysl. Nakonec nás napadlo zvážit umístění CRL do Azure. Protože jsme věděli, že navíc toto CDP bude využíváno velmi často i externími klienty, ukázalo se to jako velmi dobrá volba. Protože jsem tento scénář na Internetu nenašel nikde popsán, chtěl bych se tímto článkem s Vámi podělit o získanou zkušenost.

Volba vhodné Azure služby

Zvolili jsme službu Azure Web Apps, která umožňuje rychle sestavit, nasadit a spravovat weby a webové aplikace. Konkrétně plán D1 (tzv. Shared), který stojí přibližně 8 EUR za měsíc a umožňuje přidat vlastní doménu, což je pro umístění CRL nutné.

1 Plány Azure Web Apps

Obrázek 1 Srovnání plánů Azure Web Apps

Vytvoření webové aplikace

Po registraci do Azure portálu je potřeba vytvořit novou webovou aplikaci. Ta automaticky dostane přiřazený název ve tvaru název_aplikace. azurewebsites.net. V případě mého testovacího webu se jedná o jméno knotekcrl.azurewebsites.net. Pokud chceme používat pro přístup vlastní doménu, je nutné pro ověření do externí DNS přidat CNAME záznam, který prokazuje, že danou doménu můžeme administrovat. V mém případě se jednalo o záznam crl.knotek.net CNAME knotekcrl.azurewebsites.net. Poté co je záznam zpropagován do externích DNS serverů, je možné projít validačním mechanismem Azure.

2 Ověření názvu hostitele

Obrázek 2 Ověření názvu hostitele

Přístup pro nahrávání obsahu

Jedna z možností, jak nahrávat obsah do webové aplikace, je pomocí FTP. Správcovský účet pro správu Azure ale není z bezpečnostních důvodů možné použít i pro FTP přístup. Je tak nutné vytvořit dedikovaný účet přímo pro FTP přístup. Po jeho vytvoření se nám v sekci „Základní údaje“ objeví přehled všech podstatných přístupových údajů: přihlašovací jméno, URL pro FTP přístup, URL pro FTPS přístup atp.

 

3 Přístupové údaje pro FTP

Obrázek 3 Přístupové údaje pro FTP

Skript pro automatické nahrávání CRL souborů do Azure Web App

Protože CRL je vydáváno běžně 1x týdně a Delta CRL dokonce 1x denně, není možné soubory manuálně kopírovat do Azure Web App, ale je nutné zajistit automatický přenos nově vydaných CRL souborů. Zde jsme společně s kolegyní Olgou Annou Berkovskou zvolili cestu PoweShell skriptu, který je pravidelně spouštěn na certifikační autoritě jako naplánovaná úloha. Níže uvádíme základní kostru skriptu, kterou je možné pro tuto úlohu bez větších úprav použít v libovolném prostředí.

   1: #Declare the folder
   2: $Dir="C:\EnterpriseCA\CRL"
   3: #ftp server
   4: $ftpserver = "ftp://waws-prod-sn1-033.ftp.azurewebsites.windows.net/site/wwwroot/"
   5: $user = "knotekcrl\MirekKnotek_FTP"
   6: $pass = "MegaKrutoPrisneHeslo"
   7: foreach($item in (Get-ChildItem $Dir -Filter "*.crl")){
   8: "Uploading $item..."
   9: #connect to ftp server
  10: $ftp = [System.Net.FtpWebRequest]::Create($ftpserver+$item.Name)
  11: $ftp = [System.Net.FtpWebRequest]$ftp
  12: $ftp.Method = [System.Net.WebRequestMethods+Ftp]::UploadFile
  13: $ftp.Credentials = new-object System.Net.NetworkCredential($user,$pass)
  14: $ftp.UseBinary = $true
  15: $ftp.EnableSsl = $true
  16: #$ftp.UsePassive = $false
  17: # read in the file to upload as a byte array
  18: $content = [System.IO.File]::ReadAllBytes($item.FullName)
  19: $ftp.ContentLength = $content.Length
  20: # get the request stream, and write the bytes into it
  21: $rs = $ftp.GetRequestStream()
  22: $rs.Write($content, 0, $content.Length)
  23: # be sure to clean up after ourselves
  24: $rs.Close()
  25: $rs.Dispose()
  26: $ftp.Abort()
  27: $ftp = $null
  28: }

Problém s Delta CRL

Je obecně známý problém, že delta CRL soubor není s výchozím nastavením IIS dostupný pro stažení díky tomu, že název souboru obsahuje znak „+”. Pro jistotu jsem tedy vyzkoušel, zda stejné chování není i v Azure. A výsledek byl, že ani tady nebylo možné delta CRL stáhnout. Na IIS to má snadné řešení, zaškrtneme v nastavení Allow Double Escaping, a je vyřešeno. V Azure jsem ale žádné podobné nastavení nenašel. Nakonec se mi podařilo vše vyřešit vytvořením web.configu s následujícím obsahem

   1: <?xml version="1.0" encoding="UTF-8"?>
   2: <configuration>
   3:     <system.webServer>
   4:         <security>
   5:             <requestFiltering allowDoubleEscaping="true" />
   6:         </security>
   7:     </system.webServer>
   8: </configuration>

Tento web.config je třeba nahrát do kořenu složky wwwroot, restartovat webovou aplikaci a zhruba 10 minut počkat. Po tomto nastavení je z Azure Web App bez problému dostupné i DeltaCRL.

Shrnutí

Azure není vhodný jen v situaci, kdy potřebujeme provozovat velké množství virtuálních strojů. Azure v dnešní době obsahuje velmi bohatou škálu různých služeb a vždy je na místě zvážit, zda neposkytuje vhodnější řešení daného problému. V tomto případě jsme si ověřili, že díky Azure je možné získat, velmi snadno a levně vysoce, dostupné CDP, což je z pohledu nasazení PKI velmi často kriticky důležité.

Miroslav Knotek, KPCS CZ, Tato e-mailová adresa je chráněna před spamboty. Pro její zobrazení musíte mít povolen Javascript.

KPCS CZ, s.r.o. je přední českou firmou specializující se na nasazení, správu a podporu informačních technologií, primárně zaměřenou na produkty společnosti Microsoft. Jako systémový integrátor poskytuje kvalitní podniková řešení na této platformě, která jsou v pravidelných intervalech hodnocena prvními příčkami v soutěžích Microsoft Awards. KPCS CZ disponuje předními odborníky na problematiku veřejného cloudu, tedy služeb Office 365 a Azure, ale i technologií privátního cloudu Windows Server, Hyper-V a produktů rodiny System Center.

Nasazení virtuálních smart karet ve firemním prostředí

Vytisknout E-mail

Miroslav Knotek Datum zveřejnění: 27. 4. 2015 13:56 Zobrazeno: 2732
1 1 1 1 1 1 1 1 1 1 Rating 0.00 (0 Votes)

Nejčastěji používaná forma ověřování pomocí uživatelského jména a hesla je zároveň také formou nejslabší. Primární odpovědnost za ochranu autentizačních údajů leží na koncovém uživateli, který musí zvolit dostatečně komplexní heslo. Toto heslo nesmí být snadno uhodnutelné a uživatel ho nesmí nikomu dalšímu sdělit. I při dodržení těchto základních pravidel je možné, díky různým útokům typu naslouchání na síti, útoku hrubou silou či sociálním inženýrství, přece jen teoreticky heslo zjistit. Ve chvíli kdy útočník zná heslo uživatele, může ho použít pro ověřování, aniž by si toho samotný uživatel musel nutně všimnout.

To vše vede řadu organizací k úvahám o zavedení dvoufaktorové autentizace, která je obvykle založená na tom, že něco znám (heslo, PIN atp.) a něco fyzicky mám (např. USB token, smart kartu, mobilní telefon). Nejběžnějším scénářem nasazení dvoufaktorové autentizace je ověřování za pomoci certifikátů uložených včetně privátního klíče na inteligentní čipové kartě s mikroprocesorem (anglicky “smart card”). Toto řešení jednoznačně zvyšuje bezpečnost autentizace, ale je spojeno často s nemalými náklady na pořízení vlastních čipových karet a čteček čipových karet.

S poměrně masovým rozšířením TPM modulů v dnešních počítačích se ale otevírá možnost nasazení dvou faktorové autentizace i bez těchto zvýšených nákladů. Tímto řešením jsou právě virtuální smart karty.

Co je TPM?

TPM (Trusted Platform Module) je kryptoprocesor instalovaný na základní desce, který mimo jiné umí generovat náhodná čísla, generovat a chránit kryptografické klíče, provádět kryptografické operace aniž by šifrovací klíč poskytnul operačnímu systému.

Zajímavou vlastností TPM je také takzvaná atestace. TPM je schopný vytvořit unikátní hash z informací o hardwarové a softwarové konfiguraci. Díky atestaci jsme pak schopni ověřit, že se nejen jedná opravdu stále o stejný počítač, ale dokonce máme i důkaz, že se nezměnila žádná jeho podstatná konfigurace hardware a software.

Specifikace TPM určitě není horkou novinkou, ale až v poslední době můžeme hovořit o tom, že TPM je běžnou součástí většiny počítačů. S TPM čipem se dnes už můžeme dokonce setkat i v mobilních telefonech s Windows Phone.

Co je virtuální smart karta?

Virtuální smart karta v podstatě emuluje tradiční fyzické smart karty, ale díky využití TPM čipu pro ochranu privátních klíčů není nasazení spojeno s nákup dalšího hardwaru. Je to tedy zajímavá alternativa pro firmy, jejichž počítače jsou vybaveny TPM čipy, jak zvýšit bezpečnost ověřování bez výrazných investic.

Virtuální smart karty mají díky využití TPM stejné srovnatelné bezpečností charakteristiky:

  • Neexportovatelnost – všechny citlivé informace na virtuální smart kartě jsou zašifrovány za pomocí modulu TPM v daném počítači a nemohou být použity na jiném počítači s jiným TPM. Součástí návrhu TPM jsou i obranné prostředky proti různým typům útoků, a tak dokonce ani v případě, že bych někomu odcizil TPM a vložil ho do svého počítače, tak se stále k chráněným datům ze zdrojového počítače nebudu schopen dostat.
  • Izolovaná kryptografie – podobně jako u tradičních smart karet jsou veškeré kryptografické operace s chráněnými klíči prováděny mimo paměť operačního systému, a tak i v případě virtuálních smart karet platí, že operační systém nemá přístup k chráněnému kryptografickému klíči a veškeré kryptografické operace s takovýmto klíčem probíhají výhradně uvnitř TPM čipu.
  • Anti-hammering – pokud uživatel zadá opakovaně špatně PIN k virtuální smart kartě, dle konkrétní logiky TPM dojde k dočasnému přerušení možnosti znovu PIN zadat. Toto chování je podobné funkci zamykání uživatelských účtů na danou dobu po vyčerpání povoleného počtu chybných pokusů o přihlášení.

Čím se liší virtuální smart karta od tradiční?

Přestože virtuální smart karta je navržena jako co nejpřesnější emulace tradičních smart karet a zajišťuje autentizaci se srovnatelnou mírou bezpečnosti za použití dvou faktorů (znám PIN a mám počítač s TPM), přece jen najdeme celou řadu praktických rozdílů, s kterými je třeba počítat.

Virtuální smart karta je stále vložená

Tradiční smart karta je díky svému kompaktnímu tvaru určena pro nošení s sebou například společně s osobními doklady. Protože je často kombinovaná třeba s docházkovým systémem nebo zabezpečením vstupu do kancelářských prostor, uživatelé jsou tak vlastně nenásilně nuceni ji nenechávat ve čtečce při odchodu od počítače. Naopak virtuální smart karta je neustále „vložená“ v počítači a není si ji možné odnést s sebou. Pokud někde nechám osobní počítač, dávám tím prostor komukoliv zkoušet uhodnout můj PIN. Nicméně díky anti-hammering funkci TPM čipu toto riziko přece jen výrazně sníženo. Naopak tradiční smart karty jsou často díky přenášení ztraceny nebo zapomenuty a nezanedbatelné náklady na provoz tvoří obsluha procesu vystavování dočasných smart karet a revokace těch ztracených nebo fyzicky zničených. Toto u virtuální smart karty hrozí pouze v případě odcizení nebo ztráty celého počítače, což nastává určitě s nižší frekvencí.

Musíme ale počítat s tím, že Smart Card Removal Policy v Group Policy tedy nemá při použití virtuálních smart karet žádný význam.

Virtuální smart karta je nepřenositelná

Výhodou tradičních smart karet je jejich přenositelnost. Mohu svojí smart kartu využít k přihlášení na libovolný počítač vybavený čtečkou. Virtuální smart karta je naopak vázaná na konkrétní počítač a je zcela nepřenositelná. Pro autentizační a podpisové certifikáty to není nepřekonatelný problém. Mohu mít jednoduše více různých virtuálních smart karet na jednotlivých počítačích a s nimi se přihlašovat. Složitější je to u šifrovacích certifikátů, kde je nemožnost přenášení mezi počítači již citelnou nevýhodou. Pokud ale uživatel využívá pro většinu své práce svůj vlastní počítač, nemusí toto omezení být nakonec relevantní.

Situace, kdy jeden počítač využívá více uživatelů, problematická naopak není. Je možné na jednom počítači mít několik virtuálních smart karet s certifikáty pro jednotlivé uživatele.

Virtuální smart karta je levná

Za předpokladu počítačů vybavených TPM čipem jsou z pohledu materiálních investic virtuální smart karty v podstatě zadarmo. Zcela odpadá nutnost nákupu skutečných smart karet a čteček čipových karet. I samotný provoz je obvykle výrazně levnější, neboť není nutné řešit časté náhrady ztracených, zničených nebo zapomenutých smart karet, což reálně poměrně běžně v praxi nastává.

Požadavky na nasazení virtuálních smart karet

Pro nasazení virtuálních smart karet existují tyto požadavky:

Požadavky na operační systém:

  • Windows 8 a novější
  • Windows Server 2012 a novější
  • Windows Phone 8.1

Požadavky na hardware:

  • TPM čip verze 1.2 a vyšší

Požadavky na prostředí:

  • Počítač je členem Active Directory domény
  • V prostředí existuje minimálně jedna Active Directory integrovaná certifikační autorita

TPM čip musím být plně funkční včetně úvodní inicializace. Pro správu TPM mají systémy Windows připravenou konfigurační konzolu „Správa čipů TPM v místním počítači”, která se spouští pomocí Start->Spustit-> tpm.msc

clip_image002

Obrázek 1 Správa čipů TPM v místním počítači

Vytvoření virtuální smart karty

Pro vytváření nebo naopak odstraňování virtuálních smart karet operační systém Windows obsahuje nástroj TPM VSC Manager (Tpmvscmgr.exe). Tento nástroj je třeba spustit s právy administrátora. Základní příklady použití jsou:

tpmvscmgr.exe create /name KPCS_VSC_Test /pin default /adminkey random /generate

Tento příkaz vytvoří virtuální smart kartu se jménem KPCS_VSC_test, která má nastavený výchozí PIN s hodnotou „12345678”.

Příkazem TpmVscMgr destroy /instance root\smartcardreader\0000 bychom naopak první vytvořenou smart kartu ze systému odstranili.

clip_image004

Obrázek 2 Vytvoření virtuální smart karty

Jakmile máme virtuální smart kartu úspěšně vytvořenou, stačí již jen standardně zažádat o certifikát interní certifikační autoritu. Žádost musí využívat zprostředkovatele kryptografických služeb „RSA, Microsoft Smart Card Key Storage Provider“. Během vytváření žádosti jsme vyzváni k zadání PINu k virtuální smart kartě, aby systém ověřil, že jsme opravdu k této operaci autorizováni.

clip_image006

Obrázek 3 Vystavení certifikátu na virtuální smart kartu

Správa virtuálních smart karet

Pro využití v menších prostředích jsou vestavěné nástroje Windows dostačující pro nasazení virtuálních smart karet i pro jejich provoz. Ve větších prostředích je pak možné pro automatizovanou správu virtuálních smart karet využít profesionální nástroje třetích stran z kategorie CMS (Card Management System). Windows 8.1 a Windows Server 2012 R2 dokonce přináší ve jmenném prostoru Windows.Device.SmartCards vlastní API, přes které automatizované nástroje mohou s virtuálními smart kartami snadno pracovat.

Jako příklad můžeme uvést jedno z prvních CMS řešení, které plně podporuje virtuální smart karty ve Windows: MyID. MyID přináší tyto hlavní výhody pro správu virtuálních smart karet:

  • Uživatelsky snadný samoobslužný proces pro vystavení virtuální smart karty včetně certifikátů
  • Podporuje obnovu klíčů, a tak je možné používat virtuální smart karty i pro šifrování např. poštovních zpráv
  • Podporuje vzdálené smazání virtuální smart karty třeba pro případ, kdy zaměstnanec organizaci opouští
  • Umožňuje vzdálené odemknutí karty při jejím zamčení na základě několika špatných pokusů o zadání PINu
  • Poskytuje auditing a podrobný reporting o využívaná virtuálních smart karet v celé organizaci
  • Podporuje celý životní cyklus certifikátů včetně obnovy nebo zneplatnění

Shrnutí

Virtuální smart karty přináší velmi zajímavou alternativu k tradičním smart kartám. S velmi nízkými náklady jsme díky novince Windows 8 v kombinaci s využitím TPM čipů schopni dosáhnout výrazného zvýšení bezpečnosti ověřování ve firemním prostředí, které je svými vlastnostmi srovnatelné s klasickými smart kartami. I virtuální smart karta zajišťuje dvou faktorovou autentizaci. Pro ověření musím zároveň ZNÁT PIN a MÍT konkrétní zařízení s TPM čipem. Z pohledu komfortu uživatele je pak práce s virtuální smart kartou v prostředí Windows úplně stejná jako s kartou tradiční.

Nahrazujeme TMG (Microsoft Forefront Threat Management Gateway)

Vytisknout E-mail

Jan Slavík Datum zveřejnění: 23. 2. 2015 14:53 Zobrazeno: 2599
Nahrazujeme TMG (Microsoft Forefront Threat Management Gateway) - 4.0 out of 5 based on 1 vote
1 1 1 1 1 1 1 1 1 1 Rating 4.00 (1 Vote)

Pár slov na úvod

Na začátku bych rád řekl, že TMG je a byl můj oblíbený produkt, mám za sebou mnoho velkých instalací a konfigurací a proto se mi tento článek nepíše úplně snadno. S ohledem na množství instalací v Čechách se mnoho zákazníků začíná ptát a poohlížet po možných alternativách tohoto úžasného produktu. Tento článek si neklade za cíl vybrat jediného nástupce, nebo vyjmenovat veškeré možné alternativy tohoto produktu, ale spíše popisuje sadu možností, které jako uživatel tohoto produktu máte. Určitě najdete na trhu mnoho různých řešení, které můžete koupit, ale vždy je vhodné využívat vlastností, které dostávám jako součást operačního systému a následně vybrat nějaký doplněk, tak abych ušetřil peníze a problémy. Nejdříve se podívejme, jak jsme na tom s podporou pro TMG :

Konec všeobecné odborné podpory: 14. 4. 2015

Konec rozšířené podpory: 14. 4. 2020

Více zde: http://support2.microsoft.com/lifecycle/search/default.aspx?alpha=Forefront+Threat+Management+Gateway+2010&Filter=FilterNO

1.1 Jak vhodně vybrat alternativu pro vaši organizaci a síť

Náhrada TMG není jednoduchý úkol s ohledem na veškeré vlastnosti, které TMG nabízelo. Ne vždy se veškeré funkčnosti všude využívaly a dle toho také musíte upravit rozhodování o možných náhradách. Pro účely tohoto článku budu brát běžnou TMG instalaci, při které TMG zajišťovalo:

  • Proxy (HTTP, HTTPS inspekci), Content antivirus
  • Publikaci různých webových farem do internet (reverse proxy), včetně SSL offloadingu
  • Publikaci Exchange – bezesporu nejvyužívanější vlastnost TMG
  • VPN server (SSTP, PPTP)
  • Firewall klient – instalací není tolik, ale myslím, že je dobré se zmínit o tomto produktu
  • Obecný IPv4 FW s IPS

Při výběru alternativ bych vám doporučil vytvořit si seznam kritérií, podle kterých budete produkty nebo náhradu vybírat. Já využívám tento, který vychází z toho, co umí TMG a je rozšířen tak, aby pokrýval další nároky na moderní FW.

Proxy :

  • Antivirus
  • NTLM nebo Kerberos ověřování proti AD
  • Kategorizace obsahu
  • SSL inspekce včetně wildcard certifikátů, protokolu SPDY
  • IPv4 a IPv6 podpora

Firewall

  • IPv4 a IPv6 podpora
  • Podpora SNAT, DNAT
  • Pravidla na základě GEO lokace
  • IPS

Publikace prostředků do internetu

  • Podpora pro publikace webových farem (definice probe)
  • Před ověřování
  • SSL offloading

Bezpečnostní rozšíření

  • IPS
  • Detekce nechtěného provozu
  • Detekce aplikací (např. Různé P2P protokoly)
  • DLP (Data Leak Protection)

VPN

  • SSTP
  • L2TP
  • PPTP
  • IPSEC Tunely

Ostatní

  • Webový management
  • Vysoká dostupnost
  • Škálování výkonu
  • Centrální logování
  • Podpora Syslog
  • HW varianta nebo Virtuální varianta

Jak asi vidíme na tomto výčtu vlastností, které chceme po novém produktu, není úplně málo. Díky velkému množství různých funkčností, které se nevhodně kombinovaly, nebylo nasazení vždy úplně jednoduché. Z tohoto důvodu bych vám doporučil rozdělení do určitých kategorií, které budeme implementovat v různých částech sítě.

Dobře se nám např. budou kombinovat vlastnosti hraničního nebo nehraničního FW dohromady s proxy. Publikaci různých prostředků můžeme vyřešit jako součást FW, ale také jako funkčnost, která bude úplně stranou od FW. Obdobně můžeme nahlížet na proxy.

Tímto směrem se většinou při náhradách TMG ubíráme. Když už tento produkt musíme nahradit tak se z toho snažme vytěžit maximum pro naši bezpečnost. Nyní bych se podíval na jednotlivé části (kategorie) a popišme si možné náhrady a cestu jak náhradu provést. Důležité je zmínit, že veškeré změny nedoporučuji provádět jako velký třesk, změny provádět postupně po jednotlivých součástech.

Mezi základní výběr, který je doporučován jako náhrada TMG patří tento set produktů, bohužel v Čechách se nám výběr trošku zmenšuje, pokud myslíme na množství instalací a kvalitu podpory a především zkušenost s Microsoft produkty.

  • KEMP Load Balancer (možnost provozovat na Hyper-V)
  • Microsoft Web application proxy
  • Fortinet Fortigate FW (možnost provozovat na Hyper-V)
  • Sophos UTM (možnost provozovat na Hyper-V)
  • WatchGuard
  • Palo Alto

Publikace Exchange a ostatních serverů do internetu

Jak jsem naznačil na začátku článku, byla toto asi jedna z nejvyužívanějších vlastností TMG. Naštěstí doba pokročila a s ní se mění i doporučení pro publikaci Exchange. Jak v dalších oblastech máme více možností na výběr, tak i zde máme několik možností. Vybírat budeme především dle ceny a toho jak moc si chceme naše prostředí rozšířit o další komponenty.

1.2 Náhrada pomocí Web Application Proxy

Pokud máte Exchange 2013 nebo se na něj chystáte přejít, máte asi výběr poměrně jednoduchý. Volba Web Application Proxy je jistě dobrá varianta, navíc jí můžeme velmi efektivně kombinovat s poslední variantou. Navíc nám tato varianta v kombinací s AZURE nebo Office365 dává další možnosti, jako je např. více faktorové ověřování.

image

Obrázek 1 Příklad login form Web application proxy

1.3 Náhrada pomocí KEMP LB

Produkty KEMP jsou jedním z nejčastěji doporučovaných variant pro publikaci Exchange nebo dalších (SharePoint, IIS, SMTP …). Tento produkt je vlastně inteligentní load balancer, který je rozšířen o další šikovné komponenty. Součástí tzv. Edge Security Pack. Což je rozšíření, které vám dává hlavně možnost předověření (podobně jak jej znáte z TMG) pro různé služby. Tyto produkty je možné pořídit jako virtuální appliance nebo jako fyzické boxy. Pokud nám jde o robustní řešení, pořídíme asi raději HW variantu. Výhodou těchto produktů je publikace na základě Template, které obsahují základní Microsoft služby. Publikaci různých služeb je možné zvládnout velmi rychle. Nespornou výhodou v čistě Microsoft prostředí je i možnost běhu v Hyper-V.

image

Obrázek 2 Příklad login form KEMP

1.4 Náhrada pomocí nového FW

U některých FW máme možnost publikace webových farem. V podstatě jde o sloučení klasického FW spolu s load balancer funkcionalitou. Díky možnosti definovat tzv. probes (testery dostupnosti) máme velmi dobrý nástroj k vystavení např. Exchange serverů do internetu. Pokud máme tedy vysoce dostupný Exchange a FW který obsahuje tuto funkčnost, pak máme vyhráno. Bohužel většina FW vám nenabídne možnost předověření. Toto bude provádět až samotný Exchange server. Z tohoto důvodu určitě definujte na novém FW DoS ochranu, případně GEO lokační pravidlo. Díky GEO lokačním pravidlům můžeme velmi lehce říci, že nechceme povolit přístup z Číny nebo USA.

VPN

Většina organizacích, kterým stačí varianty Microsoft VPN, budou chtít i po náhradě TMG dále využívat VPN na MS technologiích. U VPN máme hned několik možností, kterými se vydat.

1. Nový Remote access server

2. Nasazení DirectAccess

3. Emulace MS VPN na některých nových FW – Někteří dodavatelé FW umí provozovat i mimo své proprietární VPN také např. PPTP nebo další.

V první variantě můžeme využít součást Windows OS, na kterém instalujeme novou roli RRAS komponenty. Instalačních postupů najdeme hned několik. Zajímavé na tomto je to, že můžeme v nových verzích Windows instalovat DirectAccess a standardní VPN (PPTP, SSTP) na jeden server, který nemusí mít externí IP. Remote access server „publikujeme“ do internetu. Jednotlivé VPN rozsahy můžeme následně firewallovat na novém nebo stávajícím FW. Díky tomu že náš nový FW bude jistě umět i IPv6 firewall, tak se nám lépe bude nasazovat i DirectAccess.

image

Obrázek 3 Schéma možné implementace Remote Access

FW

Náhrada samotného FW jádra bude asi ta nejjednodušší, co v této oblasti budete řešit. Zde asi nemůžete vybrat špatně. Pro můj osobní výběr je důležité sáhnout po FW který má v ceně IPv6 a případně další rozšíření, kterým může být např. IPS. Výhodou by mohlo být provozování více „virtuální FW“ na jednom Firewall HW. Díky tomu můžeme striktně oddělit např. Interní a internetový provoz aniž bych musel pořizovat více fyzických boxů. Jedním z možných dodavatelů, kteří toto umí je např. Fortigate od společnosti Fortinet.

Proxy

I zde máme několik možností jak se k náhradě proxy postavit. V každém případě musíme sáhnout mezi jiné dodavatele, než je Microsoft. Tuto funkčnost běžným způsobem nenahradíme. Někteří dodavatelé FW umí tzv. transparentní kontrolu HTTP/S provozu. Pokud, ale chceme jednodušší a především autentizovanou proxy pak musíme sáhnout po tzv. Explicitní proxy. Tato explicitní proxy zajistí ověření uživatele, zjištění členství uživatele v různých AD skupinách a dle nastavených FW proxy politik můžeme povolovat nebo zakazovat provoz. Jedním z produktů, který velmi dobře kombinuje možnosti FW a Proxy může být právě již zmiňovaný Fortigate, ale na trhu je mnoho dalších např. Sophos a další.

image

Obrázek 4 Příklad AV kontroly na FG

Pro hladší přechod máme možnost tuto funkcionalitu migrovat před samotnou náhradou TMG. Většinou právě s odladěním proxy politik bývá nejvíce problémů.

Pokud využíváte ve vaší organizaci tzv. Firewall klienta, pak před samotnou migrací doporučuji jeho odinstalaci nebo zakázání. Následně přepublikovat WPAD buď přímo na proxy nebo na jiném webovém serveru.

Závěrem

Doufám, že vám náš článek pomohl v rozhodování a vaše náhrada TMG proběhne bez technických problémů a zádrhelů. Pokud se rozhodnete pro přechod z TMG na Fortinet. Pak je zde krátký skript, který umí z exportované TMG konfigurace přenést některé typy objektů do Fortigate formátu.

CryptoLocker - Jak předejít “útoku” pomocí technologií v operačním systému?

Vytisknout E-mail

Ondřej Výšek Datum zveřejnění: 24. 10. 2013 15:29 Zobrazeno: 3691
CryptoLocker - Jak předejít “útoku” pomocí technologií v operačním systému? - 5.0 out of 5 based on 3 votes
1 1 1 1 1 1 1 1 1 1 Rating 5.00 (3 Votes)

imageimageÚtočníci hledají nové cesty jak znemožnit uživatelům jejich život, jak získat nějaké jmění. V poslední době se internetem šíří hrozba pod názvem CryptoLocker. Výsledkem jeho činnosti jsou zašifrované soubory na lokálních / výměnných / síťových discích. Pokud nezaplatíte požadovanou částku, je smazán klíč použitý pro šifrování. Nepomůže změna data v BIOSu,… Projevem “infekce” je nemožnost otevřít běžně využívané soubory doc, .docx, .xls, .xlsx, .ppt, .pst, .dwg, .rtf, .dbf, .psd, .raw, .pdf a další. Přijít k tomuto viru je možné v současné době několika možnými způsoby:

1) otevřením přílohy v mailu a spuštěním obsahu přílohy.

2) přístupem na nakaženou webovou stránku.

3) v poslední době stažením a instalací nakaženého kodeku / video ovladače.

Tedy jak vidno, ono se o infekci nebo virus v pravém slova smyslu nejedná, stejně tak nejsou využívání žádné známé bezpečnostní chyby v operačním systému, vše je s “laskavým svolením” uživatele. V současné době neexistuje cesta jak navrátit zašifrované soubory do své nezašifrované podoby. Ochranou je prevence:

1) chodit tam a otevírat pouze to co vím, že je bezpečné

2) provádět offline zálohy

3) aktuální antivirové řešení

Nicméně je ještě jedna cesta, jak se tomuto napadení, resp. zašifrování souborů bránit - k dispozici již od Windows XP - Software Restriction Policies / AppLocker. Vycházejme z předpokladu, že škodlivý kód je spouštěn z EXE souboru, který dorazí emailem,… (co se situace týká, kdy škodlivý kód je “přibalen” k běžnému SW, pak toto řešení nepomůže, resp. pomůže, ale ovladač,.. nebude spuštěn jako celek). Je možné nadefinovat pravidla pro SRP / AppLocker následovně:

  • %localAppData%\*.exe - blokuje spouštění z C:\Users\%username%\AppData\Local
  • %localAppData%\*\*.exe - blokuje spouštění z C:\Users\%username%\AppData\Local\*
  • %Temp%\Rar*\*.exe - blokuje spouštění v TEMP, souborů otevíraných pomocí WinRAR
  • %Temp%\7z*\*.exe - blokuje spouštění v TEMP, souborů otevíraných pomocí 7zip
  • %Temp%\wz*\*.exe - blokuje spouštění v TEMP, souborů otevíraných pomocí WinZip
  • %Temp%\*.zip\*.exe - blokuje spouštění v TEMP, souborů otevíraných pomocí Windows Explorer
  • %localAppData%\Microsoft\Windows\INetCache\*.exe - blokuje spouštění souborů v IE temp
  • %localAppData%\Google\Chrome\User Data\Default\Cache\*.exe - blokuje spouštění souborů v Chrome temp (pozn. cache je v binární formě, je nepravděpodobné, že by se vyskytl přímo exe soubor)
  • %localAppData%\Mozilla\Firefox\Profiles\*.exe - blokuje spouštění souborů v FF temp (pozn. cache je v binární formě, je nepravděpodobné, že by se vyskytl přímo exe soubor)

Výsledek pak může vypadat např. takto:

image

Výhodou řešení je, že je snadno nasaditelné pomocí skupinových politik i v rámci organizací. Pokud bychom chtěli být ochráněni ještě lépe, je vhodné nasadit tzv. Application Whitelisting, tedy nastavit SRP/Applocker tak, aby umožňoval spouštět pouze vyjmenovaný software. Ostatně toto je preferovaná metoda NSA - více v dokumentu http://www.nsa.gov/ia/_files/os/win2k/Application_Whitelisting_Using_SRP.pdf

Zvyšte zabezpečení vašeho prostředí pomocí SCM 3.0

Vytisknout E-mail

Ondřej Výšek Datum zveřejnění: 1. 2. 2013 16:27 Zobrazeno: 3105
Zvyšte zabezpečení vašeho prostředí pomocí SCM 3.0 - 5.0 out of 5 based on 2 votes
1 1 1 1 1 1 1 1 1 1 Rating 5.00 (2 Votes)

Security Compliance Manager (SCM) 3.0 byl umístěn ve finální verzi na download stránky 31.1.2013. Jedná se o nástroj zdarma, který je součástí tzv. Solution Accelerators, lze pomocí něj řídit konfigurace a zabezpečení pomocí skupinových politik (Group Policy), System Center Configuration Manager. Poslední verze SCM 3.0 přináší podporu Windows Server 2012, Windows 8 a Internet Explorer 10.

SCM nabízí politiky připravené k nasazení na počítače s operačními systémy Windows a Office, kde politiky obsahují předpřipravené konfigurace, které obsahují znalostní bázi týkající se zabezpečení počítačů a serverů.

imageimage

Při práci se SCM 3.0 je možné importovat stávající nastavení, které je prováděné pomocí skupinových politik a použít tuto konfiguraci jako referenční. Také je možné importovat bezpečnostní nastavení z jednotlivých počítačů, na kterých je také možné nastavení aplikovat.

SCM nabízí i znalostní bázi bezpečnostních expertů a doporučená nastavení v aktualizovaných dokumentech. Obsahem je také referenční dokumentace “Attack surface”, tedy možná, potenciální nejzranitelnější místa podporovaných produktů. Pomocí těchto informací je možné vytvořit přesné nastavení zabezpečení, kde SCM pomůže porozumět proč, jak a co nastavujete.

Při importu stávajícího nastavení je možné porovnat existující nastavení proti doporučenému “zabezpečenému” nastavení. SCM 3.0 přináší rozšířené a upřesněné nastavení pro Windows 7 SP1 a Windows Server 2008 R2. Jakmile je připravena bezpečnostní konfigurace, je možné nastavení exportovat do několika z následujících formátů: XLS, GPO (skupinové politiky), balíčky Desired Configuration Management (SCCM DCM), Security Content Automation Protocol (SCAP). Díky těmto exportům je možné automatizovat / dokumentovat bezpečnostní nastavení ve firemních prostředích, ale stejně tak i při nasazení operačních systémů.

Již z předchozích verzí SCM jsou podporovány následující produkty: Windows Server 2012, Windows Server 2008 R2 SP1, Windows Server 2008 SP2, Windows Server 2003 SP2, Hyper-V, Windows 8, Windows 7 SP1, Windows Vista SP2, Windows XP SP3, BitLocker Drive Encryption, Windows Internet Explorer 10, Windows Internet Explorer 9, Windows Internet Explorer 8, Microsoft Office 2010 SP1, Microsoft Office 2007 SP2, Exchange Server 2010 SP2 a Exchange Server 2007 SP3.

Security Compliance Manager (SCM) 3.0 je možné stahovat zdarma z Microsoft Download Centra. Pro instalaci je nutná instance MS SQL 2008 (může být i Express), při instalaci SCM je možné automaticky instalovat odpovídající instanci SQL Express.

Pro zájemce je připravena ukázka SCM: Security Compliance Manager Demo a také dokumentace

SCM Overview

SCM Getting Started

SCM Frequently Asked Questions (FAQ)

SCM Release Notes

SCM Baseline Download Help

Pro instalaci je zapotřebí operační systém Windows 7 nebo Windows 8, Microsoft Word nebo Word Viewer,

Strana 1 z 3

Přihlašovací formulář