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.
„Kdy už bych měl začít systematicky řídit své Azure prostředí?” tuto otázku si pravděpodobně pokládá spoustu vedoucích IT pracovníků zodpovědných za cloudové služby ve své organizaci. Pokud organizace s Azure teprve začíná, je nejlepší začít ihned, nežli později nebo vůbec. Jestliže organizace už používá služby Azure nějakou dobu a má rozsáhlou infrastrukturu, bude narovnávání prostředí komplikovanější, ale určitě ne nemožné. Vždy je nutné začít po malých částech, než chtít dát do pořádku naprosto vše a ihned.
Pro lepší pochopení problematiky řízení a správy zdrojů v Azure (Governance) je důležité zmínit čím je potřeba se zabývat:
Vytvářením smysluplných hierarchií pomocí Azure Management Groups
Aplikování příslušných politik pomocí Azure Policy na již definované skupiny a subskripce
Konfigurace politik přímo do šablon nebo rolí v Azure pomocí Azure Blueprints, což přináší efektivitu a rychlost při aplikaci politik na nové subskripce
Inventářem zdrojů přes Azure Resource Graph – díky domu máte detailní přehled o zdrojích
Optimalizací a sledováním nákladů pomocí Azure Cost Management + Billing
Základním kamenem Governance je MVP – Minimum Viable Product (minimálně životaschopný produkt). Cílem MVP je omezit překážky, které by bránily k vytvoření počátečního plánu pro Governance a poté umožnit rychlé vyřešení rizik, které se mohou během implementace nebo produkce objevit.
Méně znalí Microsoft Azure jsou teď pravděpodobně vyděšeni, co všechno bude potřeba zvládnout a jak si s tím vlastně poradit. Nicméně není potřeba se děsit, protože již existuje řada nástrojů a průvodců, kteří nám usnadní kroky k vysněné cestě – mít vše pod kontrolou, přehledné a řídit vše systematicky bez stresu. Jedním z těchto nástrojů, který nám může při přechodu do cloudu velmi pomoct je Cloud Adoption Framework (CAF). CAF poskytuje postupy, které samy o sobě obsahují kroky související se správou zdrojů a vkládá je přímo do činností souvisejících s plánem pro přijetí cloudu v organizaci. Díky této sadě doporučení je organizace schopna efektivně nasadit potřebná pravidla pro Governance hned na začátku. Hezkým příkladem je použití šablon k nasazení jedné nebo více “landing zones“ (připravená infrastruktura v Azure) pro migraci do cloudu.
Pokud jste tedy CAF použili při přechodu do cloudu, tak se můžete pochválit, že jste šli správnou cestou a Governance již určitě nějakým způsobem řešíte. Pokud ne, tak jsou pro vás dobrým pomocníkem příručky pro nasazení správného řízení – Governance, které jsou rozděleny do dvou skupin:
Standartní Governance průvodce – příručka pro většinu organizací založená na počátečním modelu s dvěma subskripcemi pro nasazení ve více regionech. Nezahrnuje řešení pro veřejné a vládní organizace.
Obě příručky přináší ty nejlepší zkušenosti a postupy, které se daly během vývoje správy a řízení zdrojů vysledovat. V zásadě popisují postupy pro fiktivní organizace, které mají určité cíle a jak jich dosáhnout co nejefektivněji. Nasazení právě té správné Governance pro vaši organizaci vám může nyní připadat velmi obsáhlé a složité, nicméně jak jsem na začátku zmínil, je potřeba postupovat po malých částech a postupně přidávat další a další části pro kompletní správu a řízení zdrojů. Startovacím bodem by měly být následující tři oblasti:
Následované tímto implementačním procesem:
Pro přidávání dalších částí, například při změně business procesů nebo zvýšení bezpečnosti či snížení nákladů je vhodné začlenit tyto další oblasti:
Pokud jste dočetli až sem, tak vás evidentně téma Governance zaujalo, což je velmi dobře, protože i přes značné úsilí stojí za to budovat smysluplné prostředí se snažíš správou a řízením zdrojů. Každopádně před každou implementací je vhodné promyslet možná rizika před velkými změnami. A jedna rada na závěr, pokud si nevíte rady a netroufáte si na nasazení Governance ve vaší organizaci, svěřte tuto problematiku do rukou odborníků, kteří vás provedou a dostanou k vašemu cíli.
