Technologické výzvy při migraci do cloudu – část první

Při migraci do cloudu vás může potkat nejedna technická záludnost, která může vaši cestu k vysněným mrakům nepěkně zkomplikovat. Naštěstí na 99 % procent problémů nebo komplikací existuje řešení, na které se však musí přijít 😊. Velké procento komplikací přichází s komplexnějšími požadavky firem či uživatelů. V tomto článku se budu snažit popsat technologické výzvy, kterým jsme čelili v rámci projektů, které jsme realizovali. Jde zejména o přímé zkušenosti ze specifických prostředí, a tak nemusí být navržená řešení vždy vhodná pro všechny.

Azure Migrate

U migračních projektů nejčastěji pracujeme s nástrojem Azure Migrate, a ani si nevzpomínám, že bychom vlastně použili něco jiného. Jedná se o nástroj, který nám umožní analyzovat migrované on-premise prostředí, a to dost detailně. Zhodnocení pro migraci lze dělat pro platformy Hyper-V, VMware, fyzické servery, ale také pro cloudové instance v AWS nebo GCP.

Obrázek 1: Architektura Azure Migrate

Ve většině případů se setkávám s analýzou prostředí běžící na VMware nebo Hyper-V. Nasazení je v celku jednoduché, v obou případech je zapotřebí stáhnout a nasadit virtuální appliance, která si oskenuje virtualizační platformu. U VMware je výhoda skenování prostředí bez agentů tvz. agentless, není tedy potřeba dále nasazovat agenty na příslušné servery, což šetří čas i námahu IT personálu. U Hyper-V je toto nutnost, nebo se dá případně použít Microsoft Monitoring agent od SCOMU (pokud ho zákazník využívá). Důležitou roli samozřejmě hraje i to, jak nastavíte vlastnosti assessmentu. Na základě vhodného nastavení máte pak jistotu, že doporučované velikosti virtuálních serverů v Azure odpovídají realitě, a nebudete tak ani překvapeni z případně vysoké ceny, která by měla být při využití rezervovaných instancí a Azure Hybrid benefitu menší nebo srovnatelná s náklady z on-premise. Jakmile jsou výstupy z assesmentu k dispozici a vyhodnocené s vytvořeným migračním plánem, tak se můžete dát do migrace, která už je prakticky tím posledním bodem. Stačí začít replikovat příslušné servery z on-premise do Azure a jejich změny, poté doporučuji spustit testovací migraci pro ověření funkčnosti replikace a aktuálních dat na serveru. Jakmile máte vše ověřeno, je načase spustit ostrou migraci, přičemž po finálním odmigrování je nutné replikaci zastavit.

Šifrování dat v cloudu

V mnoha projektech se setkáváme s tím, že zákazník trvá na tom, že chce mít svá data bezpečně šifrována a uložena tak, aby se k nim nikdo jiný nedostal. Je to docela pochopitelný požadavek, protože data o společnosti, výrobních procesech, interních zaměstnancích, know-how a jiné jsou to nejcennější, co daná společnost vlastní. Řešíme tedy šifrování na dvou úrovních:

· at rest – šifrování na úložištích (storage účty, disky virtuálních serverů, databáze, container registry aj.)

· in transit – šifrování při přenosu dat, to znamená zabezpečení síťové komunikace (Site-to-Site VPN tunely, TLS, SSH, storage transakce, SMB přenos aj.)

Při šifrování dat at rest, řešíme ve většině případů data na discích virtuálních strojů a data na storage účtech. Zde lze využít několik možností, přičemž je důležité si uvědomit, že veškerá data v Azure jsou automaticky šifrována a chráněna před neoprávněným přístupem – ano je to tak, nicméně se jedná o základní úroveň. Pokud se budeme bavit o managed discích virtuálních serverů, tak ve výchozím stavu jsou automatiky šifrovány pomocí Azure Storage encryption s 256-bit AES standardem, který splňuje požadavky FIPS 140-2. V rámci jednoho projektu však tento standard nevyhovoval a bylo vyžadováno šifrování, které splňuje požadavky FIPS 140-3. Hlavním rozdílem je, že verze 3 vyžaduje použití Hardware Security Modulu (HSM) nebo podobného řešení jako je firmware modul, software modul, hybrid-software modul či hybrid-firmware modul. Navíc nebylo žádoucí, aby byly klíče pro dešifrování disků řízeny společnosti Microsoft. Standartně se totiž používá kombinace Server-Side Encryption (SSE) s Platform Managed Key (PMK) – což je klíč spravovaný providerem. Proto se zvolila cesta Customer Managed Key (CMK) s využitím HSM, pro splnění FIPS 140-3 požadavku.

Obrázek 2: Princip šifrování at rest (SSE + CMK) bez využití HSM modulu

Detailní technické informace k šifrování naleznete zde Encryption of backup data using customer-managed keys.

Pro řešení s HSM se nabízí aktuálně dvě možnosti. Jde o pořízení fyzického HSM a jeho umístění v on-premise a propojení s cloudem nebo využití Azure Key Vault Managed HSM, které je již plně dostupné v několika regionech.

V dalším díle si řekneme něco o tom, jak se dostat z cloudu rychle a s minimální ztrátou dat.