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.
o 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).
o 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.
o 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.
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).
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.
Případně můžeme použít i nové nástroje jako je PowerBI pro rychlé zobrazení bezpečnostních informací.
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.
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 cloudová aplikace InTune v rámci které můžete říci, jak bude vypadat heslo pro přístup k systémům.
A v neposlední řadě tedy logování přístupu na servery, které můžete mít opět v aplikaci Operation Management Suite a sledovat například přístupy z vnější sítě a vyhodnocovat tak, kdo a odkud přistupuje k vaší infrastruktuře.
V neposlední řadě je určitě velice vhodné, abychom věděli kam naši uživatelé přistupují z pohledu sociálních sítí, kam mohou nahrávat svá data a celkově jaké služby v internetu využívají. Abychom mohli provést detailní kontrolu, zajistit a dát jim jednotnou identity, což v tomto případě má jako vedlejší efekt zvýšení spokojenosti uživatele, jelikož si nemusí pamatovat spousty přihlašovacích údajů, máme zde možnost využít ještě nástoje jako je Cloud App Security, který velice napomáhá tomu, aby byla služba do které uživatelé přistupují scorována společností Microsoft z pohledu bezpečnosti a také můžeme vidět kteří uživatelé a z jakých IP Adres přistupují do oněch služeb. Kdybychom šli asi do úplného důsledku, můžeme pak služby zaintegrovat do Azure AD pomocí API a využívat tak jednotné přihlášení na sociální sítě, youtube, Google Apps, atd..
Databáze
A nyní přecházíme tedy postupně od té infrastrukturní vrstvy k té aplikační, která nemůže být opomenuta. Každá společnost provozuje nějakou databázi, a jelikož nejsem úplně člověk na databáze, tak omluvte mé schopnosti v tomto směru. Pevně věřím, že existuje mnoho možností pro zabezpečení dat. Každopádně začněme nejprve s přístupy a jmény a hesly pro přístup do nějakého webového systému.
Rozhodně je nutné správně ošetřit všechny vstupy z aplikace do databáze vlastní, takže na začátku začněte nějakým obyčejným vulnerability scannem, který vám ukáže, jestli na vaši databázi není možné udělat SQL injection útok. Dále je pak nutné zabezpečit jména a hesla zapsaná v databázi, zde by bylo určitě více než vhodné použít nějaký hash a salt pro zabezpečení hesel uložených přímo v DB.
Na úrovni operačního systému je možno nastavit na disku, kde jsou databáze umístěny například Bitlocker a Applocker, aby nemohl být systém kompromitován nějakých cizím software a opět sbírat logy, vyhodnocovat a měřit. MS SQL ještě nabízí možnosti pro zabezpečení databáze přímo z SQL Serveru. Tudíž zde je na místě se určitě podívat na Guide pro SQL Server, který je dostupný na technetu nebo nějaký Guide pro hardening SQL serveru.
V poslední řadě můžete použít pro lepší pohled na data opět nástroj Operation management Suite, který disponuje modulem SQL Assessment, který vám ukáže veškeré chybné konfigurace, případně je zašle do Security centra v Operation Management Suite, kde jsou kontrolovány pomocí Best Practises společnosti Microsoft.
Pokud bychom se rozhodli, že budeme přesouvat naše databáze do prostředí Azure a využívat službu Azure SQL, můžeme počítat s novými možnostmi zabezpečení, které nám dává platforma Microsoft Azure k dispozici a to zejména nástroj s názvem „Azure SQL Database Threat Detection“, který nám umožní zabezpečit databáze například proti SQL Injection a také mnoho dalších věcí. Tento nástroj je implementován a ovládán z Azure Security Centera, a proto máme vždy jediné místo kam se podívat a co sledovat.
