V polovině srpna spatřil světlo světa nový Azure AD Connect ve verzi zvané V2. Většina z vás tento nástroj pro synchronizaci identit asi zná, nicméně pro ty, co se s ním nikdy nesetkali, si dovolím krátké vysvětlení v následující větě. Jedná se o synchronizační nástroj, který slouží pro synchronizaci identit z on-premises Active Directory (AD DS) do Azure AD včetně velkého množství nastavení, synchronizace hesel, využití Single Sign-On a dalších důležitých parametrů.
Co nového nám tedy tato verze přináší:
SQL Server 2019 LocalDB – předešlá verze AD Connectu byla doručována s SQL 2012 LocalDB čemuž je teď konec. Nová SQL DB slibuje lepší stabilitu, výkon a několik bezpečnostních oprav.
MSAL autentizační knihovnu – předešlá verze používala ADAL autentizační knihovnu, které skončí podpora v prosinci 2022. Pokud vás zajímá více informací o MSAL knihovně mrkněte na tento přehled.
Visual C++ Redist 14 – důvodem pro nový C++ Redist balíček je využití nové databáze SQL Server 2019, která ho vyžaduje. Instalaci nemusíte provádět předem, vše se nainstaluje v rámci instalace Azure AD Connectu V2.
TLS 1.2 – verze TLS 1.0 a 1.1 již nejsou považovány za bezpečné a všeobecně nejsou Microsoftem využívány. Stejně tak všechny podporované verze serverových Windows systémů již mají ve výchozím nastavení zapnuté TLS 1.2. Pokud váš server TLS 1.2 nepodporuje nebo není zapnutý, tak bohužel AD Connect V2 nenainstalujete.
Binárky podepsané pomocí SHA2 – v Microsoftu si všimli, že předešlá verze podepisuje některé binárky pomocí SHA1, který již pro stahovatelné binárky nepodporují. Tím pádem bylo rozhodnuto, že je potřeba všechny binárky upgradovat s SHA2 podpisem. Díky těmto podpisům máte zajištěno, že při aktualizaci AD Connectu nedojde k podvržení falešného souboru s nějakým škodlivým obsahem.
Konec podpory pro Windows Server 2012 a Windows Server 2012 R2 – vzhledem k tomu, že se využívá SQL Server 2019 LocalDB, který podporuje systémy Windows Server 2016 a výše, tak odpadá možnost využívat tyto starší systémy, které budou příští rok mimo oficiální podporu (10. 10. 2023).
PowerShell 5.0 – Azure AD Connect V2 obsahuje několik cmdletů, které jednoduše potřebují nový PowerShell verze 5.0, tím pádem je toto nová prerekvizita pro instalaci nového AD Connectu.
Co tedy tato nová verze pro mě jako zákazníka znamená? V podstatě Microsoft doporučuje provést aktualizaci co nejdříve, protože předešlá verze využívá komponenty, které budou brzy mimo podporu a tím pádem budete využívat nepodporovaný produkt. Díky tomu bude z pohledu Microsoftu pro vás těžší obstarat oficiální podporu.
Nová verze jako taková neobsahuje žádné funkční vylepšení synchronizačního nástroje jde pouze o upgrade vnitřních komponent na novější verze.
Pokud byste si nevěděli rady s aktualizací na nejnovější verzi nebo chtěli poradit, stačí se nám ozvat a pokusíme se najít společně nejlepší řešení. Nejčastější otázky a odpovědi naleznete na oficiálním MS Docs.
Na přelomu března a dubna 2022 vydal Microsoft do General Availability možnost využití vlastního rozsahu public IP adres v Azure (BYOIP – Bring Your Own IP). Jednoduše řečeno si můžete jako zákazník Microsoftu nebo partnera poskytující služby v cloudu přinést do Azure vlastní rozsah veřejných IP adres. Využití je naprosto stejné jako v případě veřejných adres přímo vlastněných a nasazených v Azure. Vaše IP adresy mohou být přiřazovány ke zdrojům, mohou komunikovat s interními či privátními IP adresami nebo virtuálními sítěmi v rámci Azure a jsou taktéž samozřejmě dostupné pro odchozí přenos z Azure do WAN sítí.
Jaké to přináší výhody?
Díky tomu, že dokážete použít vaše vlastněné rozsahy veřejných IP adres si zanecháte vaši získanou reputaci (dlouhodobě ověřené veřejné IP) a nadále budete bez problému procházet přes externí „whitelisting“. Dalším benefitem je, že předpony veřejných IP adres a standardní veřejné IP lze odvodit z vašich vlastních předpon IP adres. Tyto IP adresy lze používat stejným způsobem jako veřejné IP adresy vlastněné Azurem.
Abyste byli schopni využít vlastní rozsah veřejných IP adres, je zapotřebí projít následujícím procesem:
Validace – rozsah IP, který si chcete do Azure přinést, musíte vlastnit a musí být zaregistrován v Routing Internet Registry such as ARIN or RIPE. IP rozsah v Azure stále zůstává ve vašem vlastnictví, musíte jen dát autorizaci Microsoftu, aby mohl daný rozsah publikovat. V rámci ověření se potvrzuje vaše vlastnictví samotného rozsahu a asociace s vaší Azure subskripcí. Některé validační kroky mohou být uskutečněny mimo oblast Azure.
Nasazení – po splnění předchozího kroku je vytvořen ve vaší subskripci v Azure zdroj s vlastním IP prefixem. Předpony veřejných IP adres a veřejné IP adresy lze odvodit z vašeho rozsahu a přiřadit je ke zdrojům v Azure. IP adresy nejsou v tomto okamžiku publikované a nebudou zatím dostupné.
Spuštění – jakmile je vše připraveno přichází čas publikace IP adres. Vámi specifikovaný rozsah bude publikován nejprve z Azure regionu, kde se nachází zdroj s vlastním IP prefixem a poté je přes Microsoft WAN publikován do internetu. Informace o regionech, kde byl již rozsah publikovaný, je dostupný v CSV ke stažení na Microsoft IP Range GeoLocation.
Existuje i samozřejmě několik limitací, na které je potřeba brát zřetel:
Vlastní IP rozsah musí být svázán s jedním Azure regionem
Minimální velikost IP rozsahu je /24
IPv6 není aktuálně podporován
V regionech s availability zónami musí být IP prefix nastaven jako zónově redundantní nebo přiřazen ke specifické zóně. V těchto regionech ho jednoduše nemůžete vytvořit bez redundance. Všechny IP adresy z daného prefixu musí mít stejné vlastnosti zóny.
Publikace vlastního IP prefixu není podporována přes Azure ExpressRoute.
Přesouvání IP prefixu není možné, nelze přesouvat mezi subskripcemi ani skupinami zdrojů. Existuje možnost odvození veřejného IP prefixu z vlastního IP prefixu v jiné subskripci s patřičnými oprávněními.
Jakákoli IP adresa z vašeho IP rozsahu je započítávána do standartní kvóty pro množství IP adres pro subskripci a region.
Dobrou poznámkou na konec je fakt, že nasazení vlastního veřejného IP rozsahu není nijak zpoplatněno. Ostatní poplatky jako egress traffic jsou účtovány standartně.
Koncem března vydal Microsoft novou verzi Azure Front Door do general availability, takže ji můžete bez problému používat pro produkční systémy čímž je garantováno SLA 99,99% pro dostupnost. Ve zkratce, pro ty co se s Azure Front Door ještě nesetkali:
Azure Front Door je nativní, sjednocená a moderní cloudová síť pro doručování obsahu (CDN), která zajišťuje akceleraci dynamického a statického obsahu. Tato služba zahrnuje automatické zabezpečení na “klíč” a jednoduchý cenový model založený na globální síti Microsoftu. Existují dvě verze Azure Front Door: standardní a prémiová. Kombinují možnosti Azure Front Door (klasické), Azure CDN (klasické) a přidávají možnosti Azure Web Application Firewall (WAF). Tímto je zajištěno jednotné a bezpečné řešení pro doručování vašich aplikací, rozhraní API, obsahu v Azure nebo kdekoli ve velkém měřítku.
Vylepšená automatizace a nasazení – nyní můžete vytvářet vlastní registrované domény spolu s dalšími zdroji v rámci jednoho nasazení a zároveň při tom ověřit vlastníka domény. Lze také využít možnost rychlého vytvoření v rámci průvodce v Azure portálu.
Zaručená integrace v rámci Azure – nasazení služby lze také zrychlit díky integraci s ostatními službami v Azure jako je DNS nebo Web Apps. Aktuálně máte možnost ověření vlastní domény díky DNS TXT záznamu, čímž je celý proces významně urychlen.
Vylepšené analytické nástroje – přístupové logy, health probe logy, nové metriky měření a před vytvořené reporty pro bezpečnost a provoz usnadní a zefektivní monitorování, troubleshooting nebo případný debugging.
Rozšířená pravidla na „edge“ (hranici) – díky vylepšeným možnostem pro pravidla (přidání regulárních výrazů a server proměnných) můžete přesouvat vlastní business logiku na samý okraj sítě a tím vytvářet komplexnější a dynamický routing mezi uživateli a backendy systémy.
Rychlé doručení napříč světem
Skutečná globální síť – stovky okrajových lokalit připojených k Azure prostřednictvím privátní sítě WAN, která dokáže až třikrát zlepšit latenci aplikací a poskytuje spolehlivost na podnikové úrovni. Díky velké škálovatelnosti poskytuje nízkou latenci a vysokou propustnost pro konzistentnost aplikací a tím přispívá k lepší uživatelské zkušenosti.
Zjednodušený finanční model – odstranění poplatků na odchozí data z Azure regionů směrem k Azure Front Door. Cenové detaily ZDE.
Inteligentní bezpečnost
To nejlepší pro bezpečnost – nativní připojení bezpečnostních služeb jako vestavěná DDoS ochrana 3-4 vrstvy, Web Application Firewall, Azure DNS nebo využití Azure Private Link.
Zlepšení WAF (Web Application Firewall) – Azure Front Door Premium poskytuje nativně detekční či preventivní ochranu před běžnými útoky – lze přizpůsobit vašim požadavkům. WAF nově obsahuje také novou sadu pravidel DRS 2.0, díky které budete mít méně falešně pozitivních upozornění a dostupné detekování anomálií založené na score-based detekci. S využitím Bot manažera je zajištěna další ochrana pomocí Microsoft Threat Intelligence.
Podpora Azure Private Link – ve verzi Front Door Premium s dostupností ve všech regionech v rámci availability zón máte možnost nastavit privátní přístup díky privátním spojením od okraje sítě (egde) až po váš backend v Azure.
Stávající Azure Front Door a Azure CDN bude dále známé jako „Classic“. Můžete je stále využívat a stále budou plně podporované. Nicméně nové nasazení či přidávání nových funkcionalit se bude týkat pouze nové Azure Front Door služby. V následujících měsících plánuje Microsoft přesun těchto „legacy“ služeb na nový Azure Front Door Standard nebo Premium. Přesun by měl být pro zákazníky bez výpadku jejich služeb. Detailní informace o novém Azure Front Door naleznete na MS Docs.
Many of you are using Azure every day, have you ever stopped and thought about to make a cleanup of your cloud environment? If not, you should do that because there is many reasons behind why to do this. I like Azure Governance approaches and one of them is cutting off the cost for cloud service – understand that as cost optimization 😊 and make infrastructure and resources well-arranged. When you often deploy and remove resources for testing or development it can happen that some parts of resources will stay in your environment alone – so called orphans. As a nice example is deployment of virtual machine in Azure. Basically virtual machine needs resource group and virtual network where it will be deployed, then as a core parts NIC interface, sometimes public IP, definitely some managed disks and network security group. Quite lot of resources but needed ones!
What happens when you just remove VM from the portal? Mostly virtual machine itself is removed but the rest like NIC interface, public IP, managed disk stays in your subscription:
VM orphaned resources
The fact is that you still pay for some of these resources – managed disks, public IPs and you definitely don’t want to pay for this! The rest of resources is for no cost but you also don’t want to have mess in growing environment, right?
To have a good overview of such “orphaned” resources I am using workbook which I created with few simple Kusto queries. It will tell me which resources are left in environment alone and I can think about their deletion:
Orphaned resources – workbook
Queries which I used in this workbook:
DISKs
Resources
| where type has "microsoft.compute/disks"
| extend diskState = tostring(properties.diskState)
| where managedBy == ""
or diskState == 'Unattached'
| project id, diskState, resourceGroup, location, subscriptionId
NICs
Resources
| where type has "microsoft.network/networkinterfaces"
| where properties !has 'privateLinkConnectionProperties'
| where properties !has 'virtualmachine'
| project id, resourceGroup, location, subscriptionId, properties.macAddress
NSGs
Resources
| where type =~ 'microsoft.network/networksecuritygroups' and isnull(properties.networkInterfaces) and isnull(properties.subnets)
| project Resource=id, resourceGroup, subscriptionId, location
Static PIPs
resources
| where type has "microsoft.network/publicipaddresses"
| where properties.publicIPAllocationMethod == "Static"
| where properties !has "ipConfiguration"
| project id, name, subscriptionId, location, resourceGroup
Dynamic PIPs
resources
| where type has "microsoft.network/publicipaddresses"
| where properties.publicIPAllocationMethod == "Dynamic"
| where properties !has "ipConfiguration"
| project id, name, subscriptionId, location, resourceGroup
You can find template for this workbook on my Github. You can import it or just copy/paste code when creating new Template Specs in Azure:
Template Specs – ARM template
If you want to extend this workbook with your own Kusto queries for another resources which you would like to monitor if they left alone, then just simply edit workbook in Azure monitor and let me know what to add eventually in comments on my Github so I can add it directly to template.
There are of course other options how to automatically remove these leftovers and one of them is to check the options for auto-delete for disks, NIC, public IP when you are creating VM in Azure portal:
V předchozím článku jsem detailněji rozebral disciplínu Resource Consistency, na kterou bude dnes navazovat další z celkem pěti disciplín Azure Governance a tou je konkrétně disciplína Security Baseline.
Pokud bychom chtěli převést do češtiny tento anglický název – Security Baseline, tak se budeme bavit o základních bezpečnostních opatřeních z pohledu IT v cloudovém prostředí. Bezpečnost je dnes základní komponentou každého IT oddělení, které má svou část nebo celou infrastrukturu v cloudu. Mnoho firem je regulováno z pohledu ochrany citlivých dat, což je při zvažování přechodu do cloudu jedna z hlavních priorit. Pro týmy kyberbezpečnosti musí být identifikace potencionálních hrozeb v cloudovém prostředí, stabilizace procesů a procedur na prvním místě v jejich pracovním žebříčku. V praktickém pojetí se při provádění Security Baseline disciplíny jedná zejména o definování a automatické vynucování základních bezpečnostních nastavení v cílovém prostředí tak, aby odpovídala bezpečnostní politice pro celé prostředí. Důležitou částí v této disciplíně je seznámení se s interními bezpečnostními směrnicemi pro IT a zákonným rámcem, ve kterém se zákazník musí pohybovat. Součástí je také sběr relevantních požadavků, které chce zákazník technicky promítnout do cloudového prostředí. Na základě těchto požadavků jsou definovány bezpečnostní politiky, standardy, šablony pro nasazení a další nastavení v rámci Azure, které budou auditovat a případně vynucovat specifikovaná nastavení.
Stejně jako při řešení disciplíny Resource Consistency se musíme i u Security Baseline zaměřit na rizika spojené s IT službami a firemního pohledu. U bezpečnosti nám jde především o ochranu dat, jejich klasifikaci, čerstvé bezpečnostní aktualizace a ochranu proti útokům. Všechny tyto aspekty lze sledovat v následujících ukázkových metrikách, které poskytnou lepší přehled o tom, čím je důležité se v této disciplíně zabývat. V podstatě se dá říct, že čím více vaše organizace v cloudu poroste, tím je potřeba se více zabývat bezpečnostními pravidly a sofistikovanějšími způsoby, jak tyto pravidla dodržovat, sledovat a případně vynucovat.
Metrika
Popis
Klasifikace dat
Množství dat nebo služeb, které jsou uloženy v cloudu a nemají žádnou klasifikaci vzhledem k firemním politikám o soukromí, dodržování zásad nebo standardům, které by měly dopad na podnikání.
Úložiště s citlivými údaji
Počet koncových bodů úložišť nebo databází, které obsahují citlivá data a měla by být chráněna.
Úložiště s nešifrovanými daty
Počet úložišť s citlivými daty, která nejsou šifrována.
Rozsah případného útoku
Jaké množství dat, služeb a aplikací bude hostováno v cloudu. Kolik procent těchto zdrojů s daty jsou klasifikována jako „citlivé“. Kolik procent aplikací a služeb jsou kriticky důležité.
Standardy zabezpečení
Množství bezpečnostních standardů definovaných bezpečnostním týmem.
Zabezpečené zdroje
Množství nasazených zdrojů, které jsou chráněny bezpečnostními standardy.
Přehled dodržování zásad (Compliance)
Poměr zdrojů, které jsou ve shodě s bezpečnostními zásadami.
Útoky dle vážnosti
Jaké množství koordinovaných pokusů o přerušení služeb (DDoS) bylo zaznamenáno. Jaká byla jejich velikost a vážnost?
Ochrana proti Malware
Procento nasazených virtuálních strojů, které mají všechny vyžadované způsoby ochrany – anti-malware, firewall nebo jiný nainstalovaný software zajišťující ochranu.
Čerstvost aktualizací
Doba, která uplynula od poslední aktualizace operačního systému nebo jiného nainstalovaného software.
Bezpečnostní doporučení
Počet bezpečnostních doporučení, které pomohou vyřešit vynucené standardy na nasazených zdrojích seřazených dle vážnosti.
Samotné definování zásad organizace není účinné, pokud je nelze automaticky vynucovat. Klíčovým aspektem plánování jakékoli migrace do cloudu je určení toho, jak nejlépe zkombinovat nástroje poskytované cloudovou platformou s vašimi stávajícími IT procesy a maximalizovat tak dodržování zásad napříč celou cloudovou infrastrukturou. Pro jedinou subskripci a základní nasazení zdrojů může být využito předem připravených funkcí, které nativně nabízí samotný Azure portál. Nastavení jednotnosti vychází ze samotného Cloud Adoption Frameworku, který pomáhá budovat základní stupeň dodržování zásad bez jakýchkoliv vstupních investic do Azure Governance. Funkce, které mohou být využity v rámci Azure portálu:
Šablony nasazení – možnost standardizované struktury a nastavení jednotlivých konfigurací.
Tagování a jmenný standard – pomůže organizovat zdroje, které jsou snadno identifikovatelné.
Správa přenosu a síťové omezení – možnost implementace pomocí Software Defined Networking.
RBAC – možnost zabezpečení a izolace zdrojů jen pro určité skupiny či uživatele.
Při rozhodování, kdy nasadit automatické vynucování bezpečnostních pravidel nebo pravidla nechat na samotných uživatelích závisí na velikosti firmy, počtu subskripcí a také jak moc máme schopné uživatele. Pomocníkem může být následující rozhodovací průvodce podobně jako u Resource Consistency disciplíny:
Na první pohled je viditelné, že čím je organizace větší, tím více je potřeba automatizovat aplikování bezpečnostních zásad a jejich vynucování. Přichází s tím ruku v ruce i větší zodpovědnost za cloudové zdroje a jejich množství. Proto je potřeba myslet na nutnost mít dobré monitorovací nástroje a využívat je co nejefektivněji.
Monitorování dodržování zásad (Compliance)
V reálném světe nelze spoléhat na to, že po nasazení politik a pravidel bude vše krásně zelené a budeme spokojení s tím, jak jsme nasadili Security Baseline. Důležité je samozřejmě sledovat, zdali se vše,, co jsme definovali, dodržuje, případně jaké zdroje dané politiky se nedodržují. Azure poskytuje nativní využívání notifikací, které mohou vlastníky zdrojů upozorňovat na nedodržování zásad a jejich nápravu. Součástí monitoringu by mělo být logování akcí a měsíční reportování s přehledem zdrojů a jejich stav splňující či nesplňující nastavené politiky. U rozsáhlejších prostředí může s tímto pomoci Azure Security Center, které poskytuje výše uvedené funkce.
Vynucování politik
Z pohledu vynucování politik a pravidel existují v podstatě dva způsoby, jak docílit cíleného efektu. První způsob je proaktivní, kdy jsme už například při vytváření zdroje omezeni určitými pravidly. Například můžeme pomocí Azure Policy definovat pouze povolené SKU velikosti virtuálních strojů, čímž zamezíme vytváření zbytečně drahých strojů, které nejsou potřeba. Druhý způsob je reaktivní a jde o nastavení politik, které budou sloužit pouze jako sledovače. Na základě jejich reportování uvidíme, které zdroje nesplňují chtěná nastavení, Ty pak můžeme vynucovat jinými způsoby nebo automatizovaně pomocí jiných politik či Azure Blueprints. Azure Blueprints nám pomáhají nasazovat a aktualizovat cloudová prostředí způsobem, který lze opakovat. To je zajištěno díky možnosti přidávat do blueprintů artefakty, jako jsou šablony Azure Resource Manager, řízení přístupu na základě RBAC rolí a Azure politiky. Azure Blueprints jsou skvělý způsob, jak zrychlit nasazování kompatibilních prostředí.
Disciplína Security Baseline je nikdy nekončící běh a měl by na to myslet každý IT architekt nebo administrátor. Jde o to, že se neustále objevují nové typy útoků a společnosti by se měly adaptovat a měnit své návyky, aby jejich prostředí bylo dostatečně zabezpečeno. Postupem času každá firma aktualizuje svá vnitrofiremní pravidla, přičemž jejich změna by se měla promítnout i v IT oblasti a nasazení politik.
V příštím článku této pětidílné série se podíváme na disciplínu Cost Management, kde vysvětlím důležitost sledování měsíčních nákladů na provoz cloudu a jaké nástroje nám pomohou s jejich sledováním a reportováním.
Azure Governance je rozsáhlou metodologií, která říká, jak správně řídit Azure prostředí. Nejde jen o samotné zdroje, ale o promítnutí firemních politik a procesů do praxe a technické konfigurace. Správné řízení Azure cloudu se skládá z celkem pěti hlavních disciplín. Jednotlivé disciplíny budou postupně hlouběji rozebírány v jednotlivých článcích.
V dnešním článku si rozebereme disciplínu Resource Consistency – což je v překladu konzistence zdrojů, řekněme jakási jejich přehlednost a struktura. Touto disciplínou je dobré začít proto, že nám říká, jak začít budovat své Azure prostředí lépe, přehledně a strukturovaně. Nemusí se vyloženě jednat jen o budování nového prostředí, praktiky pro Resource Consistency se mohou aplikovat i do již vytvořených struktur. Jejich adopce bude však o něco složitější, než když se začíná na „zelené louce“. Přehlednost zdrojů a jejich konzistenci můžeme v Azure řídit pomocí několika nástrojů, které budou vynucovat některá nastavení automaticky a nedovolí tak nekontrolovatelné rozšiřování prostředí, které může být časem nepřehledné a měsíční faktury mohou být noční můrou všech účetních.
Resource Consistency se také zaměřuje na řešení rizik souvisejících se správou provozu cloudových služeb jak z pohledu IT, tak i z business pohledu. Součástí analýzy rizik je shromáždění dat souvisejících s operacemi, které se provádí na daných zdrojích. Díky tomu se dá zjistit, jak velkému riziku čelíte a jak moc je důležitá investice do této disciplíny. Každá organizace má různé provozní scénáře, nicméně níže uvedený seznam položek přináší hezký příklad toho, jaké metriky je potřeba sbírat a sledovat. Na základě těchto metrik můžeme vytvořit sledovací nebo automatizované mechanismy, které zajistí, že budou dodrženy nastavená pravidla a procesy.
Metrika
Popis
Cloudové zdroje
Celkový počet nasazených zdrojů v cloudu.
Neoznačené zdroje
Počet zdrojů, které nejsou označeny. Nemají žádné tagy pro účetnictví, dopadu na business nebo označení organizační struktury.
Nevyužité zdroje
Počet zdrojů, kde jejich RAM paměť, CPU nebo síťové vytížení neodpovídá jejich kapacitě a jsou většinou nevyužité.
Přetěžované zdroje
Počet zdrojů, kde jsou jejich kapacity RAM, CPU a sítě velmi často přetěžované.
Stáří zdroje
Čas, kdy byl zdroj vytvořen nebo změněn. Vhodné je uvést i datum, kdy už zdroj nebude potřeba a může být smazán (vývoj, testování, dema atd.).
Virtuální servery s kritickou kondicí
Počet VM, které nemají dobrou kondici a je potřebný zásah pro jejich opětovné uvedení do normálního provozu.
Upozornění dle vážnosti
Celkový počet upozornění na nasazeném zdroji v členění podle závažnosti.
Problém na síťový zařízeních
Počet zdrojů, které mají problém se síťovým připojením.
Problém se servisními koncovými body
Počet problémů s koncovými body externí sítě.
Incidenty služeb cloudového providera
Počet výpadků nebo problémů se sítí způsobených poskytovatelem služeb.
SLA
Sledování SLA, které může obsahovat, zda byly dodrženy podmínky ze strany Microsoftu, ale i tak podmínky, kterými se zavazujete u zákazníků nebo externích partnerů.
Dostupnost služby
Procenta, kdy byla služba skutečné dostupná v porovnání s očekávanou dostupností.
Čas pro obnovu (RTO)
Maximální akceptovatelný čas, kdy může být služba nebo aplikace nedostupná v případě poruchy.
Bod obnovy dat (RPO)
Míra času, ve které akceptujeme ztrátu dat při havárii. Například data uložená v jediné databázové instanci bez replikace s hodinovou zálohou znamená maximálně hodinovou ztrátu dat.
Průměrný čas pro obnovení (MTTR)
Průměrný čas potřebný pro obnovení služby po chybě.
Průměrný čas mezi incidenty (MTBF)
Průměrné určení času, kdy může služba nebo aplikace bezproblémově běžet mezi výpadky. Tato metrika nám může pomoci predikovat a určit, jak často bude služba nedostupná.
Stav zálohy
Stav a počet záloh, které byly úspěšně dokončeny. Případně synchronizovány bez problému.
Stav obnovení
Počet úspěšných operací obnovy služby nebo aplikace.
Pomůckou, která definuje nástroje a etapy jejich použití, je Resource Consistency rozhodovací průvodce, který popisuje následující obrázek:
Zdroj: Microsoft
Ve své podstatě nám říká, jak začít, kde pokračovat a jaké nástroje bychom měli použít. Rozhodujícími faktory, jestli v Azure Governance pokračovat v pojetí konzistence zdrojů závisí na velikosti společnosti a množstvím zdrojů, které v cloudu má. Prakticky nemá smysl řešit hierarchii subskripcí, když máme jen jednu, případně dvě. K tomu je samozřejmě navázaná komplexnost samotného prostředí a také to, jestli jsme nějakým způsobem do řízení zdrojů v cloudu nuceni vnějšími nařízeními, certifikacemi nebo normami. Při větším množství subskripcí nám pak mohou pomoci vytvořit smysluplnou strukturu Azure Management Groups.
Zdroj: Microsoft
Podobnou pomůcku jako u rozhodovacího průvodce pro konzistenci můžeme použít i pro „tagování“ (označování) zdrojů. Následující obrázek popisuje spojení tagů z IT a business pohledu.
Zdroj: Microsoft
Základní jmenná konvence nám říká, jak pojmenovávat zdroje – skvělou pomůckou je tento jmenný standard definovaný Microsoftem. Podle něj jsme již na první pohled schopni určit typ zdroje a k čemu pravděpodobně slouží.
Označení funkce zdroje nám říká, k čemu využíváme ten nebo onen virtuální server – app, data, archive, automation atd.
Klasifikace pomůže rozeznat, jestli jde o privátní, veřejný nebo přísné tajný zdroj, případně klasifikaci SLA, důležitost a jiné.
Účetní označení slouží k lepšímu sledování výdajů jednotlivých zdrojů a ke komu půjde příslušná faktura – může to být oddělení, název projektu, případně region.
Vlastník zdroje je velmi používaný tag, protože říká, na koho se obrátit v případě problémů se zdrojem nebo v případě jeho vysokých nákladů nebo při překročení času, po který měl být zdroj vytvořen.
Posledním označením zdroje je business pohled, který definuje hodnotu zdroje a pomůže při investičním rozhodování – např. business critical, revenue impact, business process a jiné. Tagy přináší opravdu neomezené a užitečné možnosti, je však zapotřebí jejich správná definice, která bude dávat smysl.
V příštím článku se podíváme na zoubek disciplíně Security Baseline.
Jestliže v cloudu teprve začínáte, určitě si lámete hlavu nad tím, co všechno a jakým způsobem budete muset řešit. Cloud je pro vás novou výzvou, se kterou by vám měl být schopen poradit váš dodavatel IT služeb. Pokud tomu tak není, jste odkázáni sami na sebe nebo případně můžete hledat pomoc u konzultantských společností, které vám přechod do cloudu usnadní. Pokud se s cloudem budete seznamovat sami, nabízíme vám popis většiny užitečných nástrojů, které vám mohou v Azure pomoci. Pokud se již v Azure cloudu pohybujete nějaký čas, bude tento článek pro vás menším opakováním. Opakování je matka moudrosti a možná narazíte na něco, co jste ještě nevyužili, neznali nebo nevyzkoušeli 😊. Všechny uvedené nástroje jsou součástí Azure Governance disciplín (Resource Consistency, Security Baseline, Identity Baseline, Cost Management a Deployment Acceleration), nicméně se s nimi můžete setkat i pokud tyto disciplíny vyloženě neřešíte. Postupně přejdu od těch nejsnadnějších, které nepotřebují žádnou implementaci a mohou se používat ihned, až po ty složitější, které už potřebují hlubší znalosti.
Azure Tags
Tagy přestavují základní nástroj, který poskytuje přehled o nasazených prostředcích. Jedná se o označení zdrojů různými tagy, které jsou pro vás důležité. Může se jednat o označení vlastníka, typu zdroje, jeho důležitosti nebo označení pod jaké spadá oddělení. Díky možnosti filtrování tagů máte pak skvělý přehled o prostředí a jeho nákladech.
Azure Management Groups
Slouží k hierarchickému uspořádání více subskripcí ve větších firmách, kde každé oddělení může mít teoreticky svou vlastní subskripci. Jejich využití se pak promítá do dalších nástrojů, kde jsme schopni například zacílit aplikaci politik právě na vybrané skupiny.
Způsob použití Azure management Groups
Azure Cost Management + Billing
Tento nástroj vám poskytuje kompletní přehled o nákladech ve vašem prostředí. Díky detailním přehledům a grafům, máte možnost zjistit co přesně vás stojí nejvíce peněz, nebo případně jiné nákladové anomálie. Cost Management + Billing má několik funkcí, které je vhodné využívat, a to zejména upozornění při překročení nastavených limitů na kredit s následným zasláním upozorněním na uvedený email. Skvělou pomůckou jsou také doporučení, které pomohou s optimalizací nákladů. V analýze nákladů si pak můžete jednotlivé položky filtrovat na základě tagů nebo sledovat trend jakým se budou náklady v budoucnu vyvíjet.
Ukázka přehledu nákladů
Azure RBAC (Role-based access control)
Řízení přístupu je jedna z klíčových oblastí správy cloudu. V Azure je řízení přístupu ve dvou úrovních – Azure AD a Azure zdroje. Obě úrovně mají předem definované role pro přidělování oprávnění, tyto role jsou pro každou úroveň jiné a s tím i jejich princip. U Azure zdrojů se využívá principu RBAC, kde platí vlastnost dědění oprávnění z vyšších úrovní hierarchie. To znamená, že pokud má někdo práva vlastníka na subskripci, tak je automaticky vlastníkem všech zdrojů v dané subskripci. Základem pro přiřazování rolí jsou: uživatel, role, rozsah. Vybereme daného uživatele, kterému přiřadíme roli na určitém rozsahu zdrojů (subskripce, skupina zdrojů, virtuální stroje, sítě atd.).
Služba Azure AD PIM umožňuje spravovat, řídit a monitorovat přístup k důležitým prostředkům ve vaší organizaci. Poskytuje časovou a schvalovací aktivaci rolí na cloudové zdroje, které jsou pod vaší správou. Zmírňuje se tím riziko přidělení práv špatné osobě nebo nadměrné či nechtěné přihlašování na váš zdroj. Zjednodušeně řečeno, když někdo potřebuje přístup nebo práva, tak si o ně musí říct a někdo to musí posoudit, zda je požadavek relevantní a schválit ho. Proces lze samozřejmě automatizovat a manuální schvalování si můžete nastavit jen pro role s nejvyšším oprávněním. Pro využívání této služby musíte mít licence pro Azure AD Premium P2 a Enterprise Mobility + Security (EMS) E5.
Azure Templates (ARM)
Jedná se o nástroj/službu, která umožňuje automatizované nasazení zdrojů. To se hodí zejména při časté změně infrastruktury nebo při opakovaném nasazování různých částí nebo celé aplikace. Případně pokud chcete implementovat infrastrukturu jako kód (IaaC) pro vaše Azure prostředí, tak jsou šablony Azure Resource Manager (ARM) tím pravým. Šablona je soubor JSON (JavaScript Object Notation), který definuje infrastrukturu a konfiguraci vašeho nasazení. Šablona používá deklarativní syntaxi, která umožňuje uvést, co chcete nasadit, aniž byste museli psát sekvenci programovacích příkazů k jejímu vytvoření. V šabloně určíte prostředky, které se mají nasadit a vlastnosti těchto prostředků. Pokud by vás tento typ automatizace zajímal více, můžete si projít detailního průvodce vaším první šablonou ZDE. Pokud jde o další nástroje pro automatické nasazování, tak je vhodné zmínit TerraForm, Ansible, Chef, Azure Automation, Azure CLI, Bash nebo Cloud Shell.
Azure Monitor
Azure Monitor maximalizuje dostupnost a výkon vašich aplikací a služeb tím, že poskytuje komplexní řešení pro shromažďování, analýzu a telemetrii dat z vašich cloudových nebo on-premise prostředí. Pomůže vám pochopit, jak aplikace fungují, proaktivně identifikuje problémy, které je ovlivňují a prostředky, na kterých závisí.
Ve středu obrázku jsou dva základní typy úložiště dat, které Azure Monitor používá, což jsou metriky a logy. Vlevo jsou zdroje monitorovacích dat, která naplňují tato datová úložiště. Na pravé straně jsou různé funkce, které Azure Monitor provádí s těmito shromážděnými daty, jako je analýza, upozornění a streamování do externích systémů.
Azure Policy
Jedná se o nástroj, který pomáhá nastavovat a sledovat dodržování zásad společnosti. Může se jednat jak o bezpečnostní zásady nebo nastavení, které nám pomáhají udržet pořádek a přehlednost. Díky Azure Policy můžete jednotlivé konfigurace vynucovat nebo jen auditovat, což je velký pomocník v případě přípravy pro nějaký větší audit společnosti. Pokud bychom měli tento nástroj porovnat s on-premise nástrojem, tak se nejvíce blíží Group Policy v Active Directory nebo Desired State Configuration (DSC). V případě, že si vystačíte s předem definovanými politikami, tak nemusíte mít hlubší znalost ARM šablon a JSON syntaxe politik, pokud ne, tak se těmto nárokům nevyhnete.
Přehled o tom, jak jsou dodržovány nastavené politiky
Azure Blueprints
Umožňují definovat sadu prostředků (politiky, skupiny zdrojů, zdroje a přiřazení rolí), které lze opakovaně nasadit a tím zajistit dodržování standardů, šablon, bezpečnostních zásad a jiných požadavků organizace v rámci jednoho automatizačního nástroje. Využití je vhodné zejména tam, kde je potřeba rychle postavit kompletní infrastrukturu menších rozměrů včetně sady politik a integrovaných komponent jako je síťování. Příkladem může být prostředí pro testování nebo vývojový tým, přičemž bude toto prostředí po odvedené práci smazáno.
Věřím, že výše uvedené nástroje pomohou vyřešit nejednu svízelnou situaci, kterou řešíte. Pokud byste se chtěli dozvědět více o jednotlivých nástrojích, tak doporučuji na našem blogu sledovat seriál Azure Governance, který se zabývá detailnějším popisem každé disciplíny včetně využívaných nástrojů.
Dnešní díl navazuje na předchozí článek 5 TOP best practices v Azure Governance – 1. díl, kde jsem rozebral vhodné praktiky z pohledu Azure Governance pro první dvě disciplíny – Cost Management a Resource Consistency. Dnes se zaměřím na zbývající tři disciplíny včetně rad a doporučení, které by měl následovat každý, kdo to s Microsoft Azure myslí vážně a chce mít své prostředí pod kontrolou, zabezpečené a za přijatelnou cenu.
Mějte dostatečné zabezpečení – Security Baseline
V dnešní době se musí bezpečnosti věnovat hodně času, přece jen jsou útoky poslední dobou sofistikovanější a častější než dříve. Na druhou stranu by nemělo panovat přesvědčení „Bezpečnost nadevše“, to by totiž mohlo způsobit složité a nepříjemné používání systémů pro koncové uživatele včetně IT správců, a to nikdo nechce. Je tedy rozumné najít kompromis mezi použitelností systému a dobrým zabezpečením. Bezpečnost v Azure lze rozdělit na základní tři stavební kameny:
Ochrana dat
Zabezpečení infrastruktury před hackerskými útoky
Aplikování a dodržování bezpečnostních zásad
Ochranu dat zajistíme dostatečným šifrováním komunikace v síti, úložišť, VM disků, uchováváním tajemství v Azure KeyVault a samozřejmě dostatečným zálohováním. Co se týče hackerských útoků, tak je opět celá řada nástrojů, díky kterým si můžeme prostředí více zabezpečit. Azure jako takový už nativně poskytuje mnoho vrstev (Network Security Groups, Basic DDoS Protection, fyzické zabezpečení datacenter, auditování a další), které chrání vaše zdroje, a navíc k nim můžete přidat například Standard Protection DDoS plány pro veřejné IP adresy, které detekují útok a ihned vás o něm informují včetně reportingu, Azure Firewall, Azure Site Recovery, Traffic Manager, Application proxy a spoustu dalších.
Pokud jde o vynucování bezpečnostních zásad v Azure, tak s tím velmi pomohou Azure Policy. Firma má nějaké vnitrofiremní bezpečnostní politiky pro IT a ty je potřeba promítnout i do cloudového prostředí. Azure Policy využívá pro definici politik a nastavení JSON formát. Přímo v Azure portálu je již připravených několik šablon, které lze ihned aplikovat. Je potřeba si však ujasnit, zda chceme dodržování politik jen sledovat nebo je rovnou i vynucovat – lze automaticky nebo manuálně.
Jak vypadá přehled politik a jejich dodržování můžete vidět na obrázku níže:
Doporučovanou službou je také Azure Security Center, která poskytuje kompletní přehled stavu zabezpečení. Díky tomu máte vše na jednom místě, včetně doporučených postupů, jak zabezpečení zlepšit.
Častým nešvarem v nekontrolovaných prostředích je zmatek při udělování práv a přehled o tom kdo disponuje vlastnickými právy. Často se setkáváme s tím, že práva vlastníka (což jsou ty nejvyšší, pokud nebereme v potaz administrátora tenantu 😊) jsou přidělovány velmi často a také zbytečně. Jde o to, že se nikomu nechce zamýšlet nad tím, jaká práva daný uživatel vůbec potřebuje, a raději mu dá všechny, než aby ho později uživatel zase obtěžoval, že mu něco nefunguje. Azure má vynikající Role-Based Access Model – RBAC, který má již předdefinované role s určitými právy, a tak odpadá skutečnost, že byste se musel jako IT správce topit v detailním rozboru práv. Rolí existuje opravdu mnoho a ve většině případů si s nimi vystačíte. Existuje i možnost vytvoření vlastních rolí, což ale moc osobně nedoporučuji, protože se špatně hlídají Pokud si každý začne vytvářet vlastní role dle potřeby, tak v rolích začne být opět zmatek. Doporučením je používat princip least-privilege u kritických zdrojů vaší infrastruktury.
Least-Privilege – jde o koncept a praktiky, které udělují uživatelům, servisním účtům a procesům pouze taková práva, která jsou nutná pro vykonávání rutinních nebo legitimovaných operací.
Součástí identit je určitě i jejich zabezpečení. Ukradená identita dokáže nadělat spoustu škody, a to opravdu nikdo nechce. Proto je vhodné využívat služby typu Multi-Factor Authentication, Conditional Access, Single Sign-On pro přihlašování (Azure AD password hash synchronization nebo Azure AD Pass-through Authentication), Privileged Identity Management, který se používá na straně Azure a Privileged Access Management, který se využívá v lokálních AD.
Privileged Identity Management & Privileged Access Managementposkytují časovou a schvalovací aktivaci rolí na zdroje, které jsou pod vaší správou. Zmírňuje se tím riziko přidělení práv špatné osobě nebo nadměrné či nechtěné přihlašování na váš zdroj. Zjednodušeně řečeno, když někdo potřebuje přístup nebo práva, tak si o ně musí říct a někdo to musí posoudit, zda je požadavek relevantní a schválit ho.
Poskytují just-in-time privilegovaný přístup do Azure AD nebo Azure zdrojům, případně on-premise AD (PAM).
Dokážou přiřadit určitý čas, kdy bude zdroj přístupný.
Vyžádání schválení při přiřazení privilegovaných práv.
Dokážou vynutit MFA pro aktivaci jakékoli role na vašem zdroji.
Poskytují notifikace při přidělení práv, možnost využít i vynucení informace při aktivaci rolí.
Provádí kontroly přidělených práv, zdali jsou stále potřeba.
Možnost stažení audit historie.
Automatizujte ve váš prospěch – Deployment Acceleration
Už ze samotného principu cloudu nám jde o to co nejvíce automatizovat. Šetříme tím čas a peníze, což jsou dva podstatné faktory. Automatizovat se má tam, kde to dává smysl a není to spíše na škodu, protože úplně všechno automatizovat nelze (zatím😊). V Azure nám jde především o automatizaci při nasazování zdrojů, aplikací nebo kódu.
Automatizace nasazení zdrojů – existuje několik možností od nativních až po ty více složité. Nejjednodušším příkladem je využívání Azure Resource Manager šablon (ARM templates). Principem automatizace v tomto případě může být nejprve manuální nasazení zdroje a poté vyexportování šablony do knihovny. Jakmile máme šablonu připravenou dle našich představ, tak opětovné nasazení stejného zdroje, byť i s jinými parametry může být mnohem rychlejší než předtím.
Poměrně novou Azure službou, která je zatím stále v public preview jsou Azure Blueprints – slouží k rychlému vybudování předem definovaného prostředí, které je v souladu s firemními politikami. V podstatě si předem připravíte šablonu s veškerými zdroji, které chcete nasadit a k tomu přidáte předem vytvořené politiky, které mohou řešit dodržování bezpečnostních zásad nebo principy řízení zdrojů. Díky tomu dokážete vytvořit v Azure celé prostředí během několika kliknutí.
S automatizací u vývoje dokáže pomoct služba Azure DevOps, která poskytuje vývojářské služby pro podporu plánování práce, kolaboraci na vývoji kódu a kompilaci včetně nasazování aplikací. Azure DevOps je cloudová verze tohoto pracovního prostoru, pro on-premise se využívá Azure DevOps Server, který byl dříve znám jako Visual Studio Team Foundation Server (TFS).
Azure DevOps poskytuje integrované funkce, které jsou klasicky přístupné přes webový prohlížeč nebo IDE klienta:
Azure Repos poskytuje Git repositáře nebo Team Foundation Version Control (TFVC) pro kontrolu verzí kódu.
Azure Pipelines poskytuje „build a release“ služby pro podporu kontinuální integrace a doručení aplikací.
Azure Boards obsahuje balík agilních nástrojů pro podporu plánování, sledování práce, chyb v kódu a dalších problémů pomocí Kanban a Scrum metod.
Azure Test Plans poskytují několik nástrojů pro otestování vašich aplikací včetně manuálního/průzkumného testování a kontinuálního testování.
Azure Artifacts dovoluje týmům sdílet Maveny, npm a NuGet balíčky z veřejných a soukromých zdrojů, přičemž integruje sdílení balíčků do vaší CI/CD pipeliny.
Níže je přehled nejběžnějších automatizačních nástrojů pro dané oblasti:
Automatická konfigurace VM
Ansible, Chef, Puppet a Azure Resource Manager šablony
Další specifické VM nástroje pro přizpůsobení jako např. cloud-init pro Linux VM nebo PowerShell Desired State Configuration (DSC) a Azure Custom Script Extension pro všechny Azure VM.
Automatizace infrastruktury
Nástroj Packer pro automatické vytváření vlastních VM imagí
TerraForm pro automatické nasazení celé infrastruktury nebo její části.
Azure Automation, který vykonává automatické akce skrze Azure nebo on-premise infrastrukturu.
Automatizace pro nasazení aplikací a jejich doručení
V dnešním článku, který je rozdělen na dva díly uvedu několik užitečných praktik, které pomohou udržet vaše Azure prostředí přehledné a cenově efektivní. Uvedené praktiky spadají do oblasti Azure Governance, které se na našem blogu věnujeme v několika směrech.
Úvodem je vhodné říct, že zavádění a vyladění Azure Governance k dokonalé spokojenosti je běh na delší trať. Je potřeba pochopit, že pokud nikdo během dvou let, co vaše společnost využívá Azure služeb neřešil řízení zdrojů, pořádné zabezpečení, aplikování politik nebo správu nákladů, tak se to určitě nezmění o 180° k lepšímu během několika dnů nebo týdnů. Větší společnosti stráví nad Azure Governance i několik let, než je opravdu všechno nastaveno, tak jak má být. Navíc během času, ve kterém se firma vyvíjí, tak by se mělo vyvíjet i samotné řízení cloudu a přizpůsobovat se novým změnám ve společnosti.
V prvopočátku Azure Governance je na místě zvážit důvody proč ji chceme řešit, za jakým účelem a co je cílem. Nejprve doporučuji stanovovat menší cíle na kratší období, kdy můžete velmi dobře sledovat jejich průběh a plnění. Pokud jde vše zdárnou cestou, tak se mohou volit větší cíle na delší období s celofiremním dopadem. V tomto článku popisuji pět nejlepších praktik, se kterými můžete v Azure začít kdykoli. Jsou to ty nejzákladnější pravidla, která při dodržování uleví firemní peněžence a zpřehlední celé vaše Azure prostředí.
Sledujte kolik utrácíte – Cost Management
V cloudu jde velmi často o finanční prostředky, které jsou k dispozici a mohou být proinvestovány. Náklady na cloudové služby jako takové jsou brány jako Opex – operativní náklady. Většinou neplatíte nic předem, platíte pouze za to, co spotřebováváte. Zní to jednoduše, ale realita je někdy jiná. Bez dozoru totiž stěží uhlídáte Frantu z IT nebo Lenku z vývoje, kteří si nasadí tu nejdražší variantu databázové služby, třeba jen proto, že si ji chtěli vyzkoušet, ale zapomněli ji smazat. Taková malá nepozornost může vyjít na několik desítek tisíc korun měsíčně, a přitom zcela zbytečně. V Cost Managementu jde o odhalení rizik spojených se zbytečnými výdaji za infrastrukturu v Azure dříve, než nastanou. Mezi nejčastěji opomenuté aspekty týkající se běžící infrastruktury v Azure patří:
Kontrola budgetu – bez kontroly limitu výdajů se může částka za náklady v cloudu dostat k astronomickým hodnotám.
Rada: Nastavte si budget limity v Azure Cost Management + Billing.
Utilizace – většinou jde o nevyužívání zdrojů dle jejich kapacity nebo předkoupení zbytečného množství zdrojů, které pak nejsou stejně využívány.
Rada: Sledujte využívání zdrojů pomocí Azure Monitor nebo využijte auto scalingu.
Výdajové anomálie – nečekaně objevující se vysoké výdaje mohou být důsledkem špatného nastavení nebo nesprávného využívání služby.
Rada: Nastavte si Upozornění na Budget limitu, které vás informuje o překročení limitní částky.
Předimenzované zdroje – při nasazení zdrojů v Azure se může stát, že počáteční konfigurace služby/zdroje převyšuje nároky na běžící aplikaci nebo virtuální stroj. Tyto přebytky mohou tvořit značnou část měsíčních nákladů.
Rada: Sledujte využívání zdrojů v Azure Monitor a v případě nevyužívané kapacity snižte SKU služby.
Základním rozcestníkem při analýze výdajů bude nástroj Cost Analysis v Cost Management + Billing službě. Jde o přehledný dashboard, na které vidíte kolik aktuálně utrácíte, za co a jaký bude vývoj nákladů, pokud již v prostředí nic nepřibude. Ukázka, jak může takový dashboard vypadat je na obrázku níže.
Z pohledu těch nejlepších praktik bychom se na Cost management měli dívat ze dvou směrů – náklady na provoz a náklady při zřizování služby/zdroje. Je vhodné dodržovat jmenné konvence a využívat tagů, identifikovat správné velikosti zdrojů (např. virtuálních strojů), automatické vypínání neprodukčních a jiných virtuálních strojů, když nejsou zrovna potřeba, využívat správných parametrů při automatickém rozšiřování infrastruktury a nezapomínat na vyřazené stroje z provozu a jejich smazání. Tyto praktiky detailněji vysvětluje následující kapitola.
Udržujte přehled a pořádek – Resource Consistency
Pro správce Azure prostředí není nic horšího než nepřehledné a chaotické uspořádání zdrojů a služeb. Nejen že se tím navyšují náklady pro správu těchto zdrojů, ale často tato prostředí obsahují „věci“, které jsou už nevyužívané, zastaralé a zranitelné. Přitom stačí málo , aby to dávalo smysl. Začít se musí od začátku, takže je nejprve vhodné promyslet Azure hierarchii a způsob jakým se bude udržovat základní přehlednost celé infrastruktury. Hezký příkladem je obrázek níže.
Už jen toto malé opatření dokáže efektivně zpřehlednit vaše prostředí. Pokud je společnost větší a má více oddělení, tak se to dá vyřešit jejich rozčleněním do dalších Management Groups. Výbornou praktikou je i rozdělování aplikačních celků do jednotlivých Resource Groups. Další základní kameny pro přehledné a učesané prostředí jsou:
Tagování – každý zdroj v Azure byl měl mít nastavené tagy, které specificky určují například vlastníka, datum vytvoření zdroje, oddělení, SLA, jeho důležitost, klasifikaci atd.
Automatické vypínání virtuálních strojů – proč by měly VM běžet, když nejsou využívané? Samozřejmě to nelze aplikovat v produkčních prostředích, kde musí být vaše služba dostupná 24/7, ale takové vývojové nebo testovací prostředí, které přes noc nikdo nepoužívá může být dobrým kandidátem.
Smazání nepotřebných zdrojů – zde platí pravidlo 90/90. Pokud nebyl zdroj v posledních 90 dnech využíván, doporučuji ho vypnout a dealokovat (jde o náklady na Storage, které by byly i tak účtovány). Pokud je VM dalších 90 dnů vypnutá a nikdo ji během této doby nepotřeboval, tak doporučuji tento zdroj kompletně smazat.
Zálohování – zde je to bez debat, pokud se jedná o produkční VM, je nutné ji zálohovat. Jak často a jak dlouho držet kopii zálohy by měla určit vaše vnitrofiremní politika.
Obnova při havárii – pokud provozujete služby, které jsou pro zákazníky kritické, tak musíte být připraveni i na možnost Disaster Recovery. Při jakékoli nečekané události musíte být schopni vaše služby co nejrychleji obnovit – zde pomohou Availability Sets, Zones, VM Scale Sets, Geo Redundance Storage a mnoho dalších Azure High Availability řešení. Řešení je však vždy nutné přizpůsobit požadavkům na RPO a RTO.
Ve druhém díle rozeberu doporučení a vhodné praktiky pro dostatečné zabezpečení, přiřazování identit a práv s tím spojených a v neposlední řadě pár tipu pro automatizace, která je nedílnou součástí cloudového prostředí.
Představte si, že začínáte s Azure cloudem a nemáte vůbec žádné zkušenosti, nicméně je to pro vás zajímavá výzva a chcete do toho jít. Velmi pravděpodobný scénář bude ten, že si koupíte předplatné Azure, vytvoříte nějakou skupinu zdrojů a do ní začnete umisťovat všechny zdroje, které potřebujete. Pro začátek a otestování funkčnosti řešení je to akceptovatelný postup. Nicméně pokud tento způsob implementace nezměníte a nezačnete systematicky a efektivně plánovat, tak se při rozrůstajícím prostředí začnou objevovat určité problémy. Například se může stát, že ve shluku všech zdrojů budou již některé zbytečné a nepoužívané, jenže vy to nebudete vědět, protože nebudete mít přehled o tom k čemu jsou a pro co jsou využívány. Výsledkem je špatný přehled a vysoká částka na faktuře, kterou dostanete každý měsíc za využívání zdrojů v Azure. Toto byl pouze jeden z mnoha příkladů proč optimalizovat, níže se podíváme na pár tipů, jak optimalizovat a jak nám s tím může pomoci Well-Architected Framework spolu s Azure Governance.
Jak je z výše uvedeného obrázku patrné, tak se tyto dvě oblasti v některých bodech částečně prolínají. Well-Architected Framework nám v podstatě říká, jak správně budovat infrastrukturu v Azure už od počátku, jak vše správně naplánovat při vytváření architektury a na co si dát pozor. Azure Governance je všeobecně správné řízení Azure cloudu, to znamená, že už pravděpodobně nějaké zdroje máte a nyní je čas je začít správně řídit a bezpečně spravovat včetně jejich nákladů na provoz.
Správa a výběr zdrojů
Jak jsem již na začátku nastínil, sledování zdrojů a jejich správa je extrémně důležitá disciplína. Pokud vám uživatelé nebo administrátoři chrlí hromady zdrojů do subskripce, tak je na místě začít tím nejjednodušším, a to je označování zdrojů pomocí tagů. Tagy mohou obsahovat informace o oddělení, vlastníkovi zdroje, prostředí, do kterého daný zdroj spadá a spoustu dalších parametrů, které jsou jen na vás. Použití tagů je skvělý způsob, jak agregovat a seskupovat prostředky mnoha způsoby, data lze také použít pro zpětné zúčtování. Neméně důležitým faktorem je také správný výběr úrovně služby a velikost virtuálního stroje, který musí odpovídat stanoveným požadavkům. Pokud dobře vyberete velikost virtuálního zdroje bude to mít okamžitý efekt na možnosti, kapacitu a výkon vašich služeb v Azure, především pak na cenu, která je s typem virtuálního stoje úzce spjatá. Velikost a úroveň služby virtuálního stroje nemusí být permanentní stav, v průběhu času a změn požadavků, se může velikost změnit, proto je potřeba se efektivně přizpůsobovat správným výběrům velikostí.
Plánování pro vypnutí systémů
Pokud máte nějaké virtuální stroje, které se používají pouze periodicky – v určitém čase, ale jsou neustále v provozu, tak zbytečně plýtváte penězi. Ideálním řešením je tyto servery vypínat právě v době kdy nejsou potřeba, čas, po který je server vypnutý šetří vaše náklady za výpočetní kapacitu. Hezkým kandidátem je například prostředí pro development, které se většinou využívá pouze během klasické pracovní doby, takže přes noc mohou být servery vypnuté. Existuje několik možností, jak vypínání zdrojů řešit:
Pro běh serverů pouze v čase, kdy to potřebujeme, můžeme využít službu Azure Automation.
Pro jednorázové automatické vypnutí virtuálního stroje můžeme využít nativní funkci auto-shutdown.
Manuální vypnutí serveru, když víme že už jej nebudeme ten den potřebovat. Zde je nutné zmínit, že je potřeba použít nativní Stop VM z ovládacího panelu virtuálního stoje v Azure, jinak nebude VM dealokována a budou stále účtovány náklady.
Spot instance
Jde o zajímavý typ virtuálních strojů, které běží, pokud má Azure nějaké nevyužité kapacity, které potřebuje zaplnit. V případě, že Azure potřebuje kapacitu zpět, tak jsou virtuální stoje vypnuty a dealokovány nebo úplně smazány. Při dealokaci stále platíte za úložiště, které virtuální stoje využívají, při smazání je vše odebráno včetně disků a neplatíte nic. Teď si určitě říkáte: „K čemu je to vlastně dobré?“ Toto řešení je možné používat pro testovací či vývojářské účely, zpracování batch procesů, kterým nevadí přerušení, pro velké výpočetní operace a další. V porovnání s normálními zdroji jsou spot instance za zlomek ceny, což je jejich největší výhoda.
Rezervované instance
Jsou Azure zdroje, které si můžete rezervovat na určitou dobu, konkrétně na jeden nebo tři roky. Díky rezervaci získáte okamžitou slevu až 72% oproti Pay-as-you-Go. V Azure si můžete rezervovat tyto typy zdrojů:
Virtuální stroje Windows a Linux
Azure SQL Database
Azure Cosmos DB
Azure Synapse Analytics
Azure Storage
Využívání „managed“ služeb
Pokud je to možné doporučujeme využívat tzv. „Managed Services“. Výhodou těchto služeb je, že kombinují nižší náklady za zdroje spolu s nižšími operativními náklady za údržbu. Důvodem je to, že se nemusíme starat o nižší vrstvy infrastruktury pod naší aplikací. Neřešíte patchování, instalaci aplikací, správu operačního systému a další komponenty, které jsou nutné pro běh vaší aplikace. Jedním z příkladů je Azure SQL Database – můžete nasadit jednu i více databázových instancí, a přitom neřešíte na jakém operačním systému běží, aktualizace, zálohování, vysokou dostupnout a jiné. Vše je obsaženo automaticky v dané službě. Azure App Service je další spravovanou službou, která je navržena k hostování webových aplikací. Místo nasazení a správy virtuálních počítačů pro vaše webové aplikace můžete své aplikace nasadit přímo do App Service a dramaticky snížit operativní náklady, které jsou vyžadovány pro údržbu infrastruktury.
Optimalizace nákladů na Azure SQL databáze
Když vytváříte Azure SQL databázi, tak musíte vybrat jednu z několika možností, která stanovuje výkon služby. Každá úroveň poskytuje určitý výkon v databázových transakčních jednotkách (DTU) nebo počtu virtuálních jader (vCore). Pokud máte databázi, která má stabilní zatížení v čase, tak je celkem jednoduché vybrat příslušnou úroveň výkonu. Jakou úroveň však vybrat, pokud máte databáze, které mají nekonstantní zatížení v různých časech během dne? V tomto případě může pomoci „elastic pool“.
SQL databázové elastic pooly jsou jednoduchým a nákladově efektivním řešením pro správu a škálování několika databází, které mají různé a nepředvídatelné nároky na zatížení. Databáze v elastic poolu jsou na jednom Azure SQL Database serveru a sdílejí stanovený počet prostředků za stanovenou cenu. Charakteristický model pro toto řešení je větší množství databází s nízkým průměrem zátěže, ale s relativně nepravidelnými zátěžovými špičkami.
K dispozici jsou celkem tři elastic pooly:
Zdroj: Microsoft Docs
Sledování nákladů a tipů Azure Advisor
Využívání služby Azure Cost Management + Billing vám poskytne přehled o tom, za co přesně utrácíte, a také o nevyužitých zdrojích. Jsou sledovány celkové výdaje, náklady podle služeb a náklady v průběhu času. Můžete se proklikávat až do podrobností jednotlivých zdrojů a získat informace o typech prostředků a instancích. Své přehledy nákladů můžete také rozdělit podle organizace nebo nákladového střediska, a to díky již dříve zmíněným tagům.
Výborným pomocníkem je také služba Azure Advisor, která vám automaticky napovídá, co udělat jinak nebo jak danou službu zlepšit za účelem zvýšení výkonu a dostupnosti, zabezpečení či snížením nákladů.
V případě potřeby doporučuje změnu velikosti virtuálního počítače.
Identifikuje nepoužívané linky Azure ExpressRoute a nečinné virtuální brány sítě.
Doporučuje, kdy zvážit nákup rezervovaných instancí, ve chvíli, kdy by to mohlo být nákladově efektivnější než použití instancí typu pay-as-you-go.
Pokud se při sledování a shromažďování nákladů zjistí nějaká výdajová anomálie, měli byste ji nahlásit ihned vlastníkům daných zdrojů nebo zúčastněným stranám. Aktivní zapojení těchto stran může zajistit identifikaci potencionálního překročení nákladů dříve, než se stane problematickým. Transparentnost při komunikaci se zúčastněnými stranami je důležitá, aby mohli plně porozumět veškerým technickým nebo obchodním rozhodnutím, která způsobila neobvyklé náklady.
Věřím, že výše uvedené tipy dokážou ušetřit alespoň nějakou část financí, které byste jinak museli zaplatit. Zkoušejte optimalizovat po malých částech a hlavně tam, kde to opravdu dává smysl. Zaměřte se na služby, za které platíte nejvíce, tam totiž existuje pravděpodobnost, že půjde nějakým způsobem minimalizovat náklady.
