Zabezpečení Azure pro aplikace nativní pro cloud

Návod

Tento obsah je výňatek z elektronické knihy Architektura cloud-native .NET aplikací pro Azure, která je k dispozici na .NET Docs nebo jako bezplatné PDF ke stažení, které si můžete přečíst offline.

Stáhnout PDF

Aplikace nativní pro cloud můžou být jednodušší a obtížnější zabezpečit než tradiční aplikace. Na nevýhodě potřebujete zabezpečit menší aplikace a vyhradit větší energii, abyste mohli vytvořit infrastrukturu zabezpečení. Heterogenní povaha programovacích jazyků a stylů ve většině nasazení služeb také znamená, že potřebujete věnovat větší pozornost bulletinům zabezpečení od mnoha různých poskytovatelů.

Na druhé straně menší služby, z nichž každá má vlastní úložiště dat, omezuje rozsah útoku. Pokud útočník naruší jeden systém, je pravděpodobně obtížnější, aby útočník přeskočil do jiného systému, než je v monolitické aplikaci. Hranice procesu jsou silné hranice. Pokud dojde k zveřejnění zálohy databáze, je poškození omezenější, protože tato databáze obsahuje pouze podmnožinu dat a není pravděpodobné, že by obsahovala osobní údaje.

Modelování hrozeb

Bez ohledu na to, jestli výhody převáží nevýhody aplikací nativních pro cloud, je třeba dodržovat stejnou holistický přístup k zabezpečení. Zabezpečení a bezpečné myšlení musí být součástí každého kroku vývoje a provozního scénáře. Při plánování aplikace se ptají například:

• Jaký by byl dopad ztráty těchto dat?
• Jak můžeme omezit poškození z nekvalitních dat pronikajících do této služby?
• Kdo by měl mít k tomuto datu přístup?
• Existují zásady auditování týkající se procesu vývoje a vydávání?

Všechny tyto otázky jsou součástí procesu označovaného jako modelování hrozeb. Tento proces se snaží odpovědět na otázku, jaké hrozby existují pro systém, jak pravděpodobné jsou hrozby a potenciální škody od nich.

Jakmile je seznam hrozeb vytvořený, musíte se rozhodnout, jestli stojí za zmírnění. Někdy je hrozba tak nepravděpodobná a drahá na plánování, že se na ni nevyplatí vynakládat energii. Například nějaký objekt actor na úrovni stavu může vkládat změny do návrhu procesu, který používá miliony zařízení. Teď místo spuštění určité části kódu v okruhu 3 se tento kód spustí v okruhu 0. Tento proces umožňuje zneužití, které může obejít hypervisor a spustit kód útoku na holých počítačích, což umožňuje útoky na všechny virtuální počítače spuštěné na tomto hardwaru.

Změněné procesory jsou obtížné rozpoznat bez mikroskopu a pokročilých znalostí o návrhu čipu tohoto procesoru. Tento scénář se pravděpodobně nestane a bude nákladné zmírnit, takže pravděpodobně žádný model hrozeb doporučí vytvoření ochrany před zneužitím.

Pravděpodobnější hrozby, jako jsou porušení řízení přístupu, která umožňují Id zvyšující útoky (nahrazování Id=2 za Id=3 v URL) nebo injektáž SQL, jsou atraktivnější pro vybudování ochran proti nim. Zmírnění těchto hrozeb je poměrně rozumné zavést a zabránit trapným bezpečnostním dírám, které poškozují pověst společnosti.

Princip nejnižší úrovně oprávnění

Jedním z hlavních nápadů v zabezpečení počítače je princip nejnižších oprávnění (POLP). Je to vlastně základní myšlenka ve většině forem zabezpečení, ať už digitální nebo fyzická. Stručně řečeno, principem je, že každý uživatel nebo proces by měl mít nejmenší možný počet práv ke spuštění úlohy.

Jako příklad si představte pokladní v bance: přístup do trezoru není běžná činnost. Takže průměrný pokladník nemůže sám otevřít trezor. Aby získali přístup, musí žádost eskalovat prostřednictvím bankovního manažera, který provádí další bezpečnostní kontroly.

V počítačovém systému je fantastickým příkladem práva uživatele, který se připojuje k databázi. V mnoha případech je k sestavení struktury databáze a spuštění aplikace použit jeden uživatelský účet. S výjimkou extrémních případů účet, na kterém je aplikace spuštěná, nepotřebuje možnost aktualizovat informace o schématu. Mělo by existovat několik účtů, které poskytují různé úrovně oprávnění. Aplikace by měla používat pouze úroveň oprávnění, která uděluje přístup pro čtení a zápis k datům v tabulkách. Tento druh ochrany by eliminoval útoky zaměřené na vyřazení databázových tabulek nebo zavedení škodlivých triggerů.

Téměř každá část vytváření aplikace nativní pro cloud může těžit z toho, že si pamatuje princip nejnižších oprávnění. Můžete to najít při nastavování firewallů, skupin pro zabezpečení sítě, rolí a oblastí v řízení přístupu na základě rolí (RBAC).

Penetrační testování

S tím, jak se aplikace stávají složitějším počtem vektorů útoku, se zvyšuje alarmující rychlostí. Modelování hrozeb je vadné v tom, že se obvykle provádí stejnými lidmi, kteří vytvářejí systém. Stejně jako mnoho vývojářů má problémy s představou interakcí uživatelů a následným sestavováním nepoužitelných uživatelských rozhraní, většina vývojářů má potíže se zobrazením každého vektoru útoku. Je také možné, že vývojáři vytvářející systém nejsou dobře obeznámeni s metodologiemi útoku a chybí nám něco zásadního.

Penetrační testování neboli "pen testování" zahrnuje zaangažování externích subjektů k pokusu o útok na systém. Tito útočníci můžou být externí konzultační společnost nebo jiní vývojáři s dobrými znalostmi zabezpečení z jiné části firmy. Dostali carte blanche k pokusu o odvrácení systému. Často najdou rozsáhlé bezpečnostní díry, které je potřeba opravit. Někdy bude vektor útoku něco zcela neočekávaného, jako je zneužití útoku phishing proti generálnímu řediteli.

Samotný Azure neustále prochází útoky od týmu hackerů v Microsoftu. V průběhu let byli první, kteří našli desítky potenciálně katastrofických vektorů útoku a zavřeli je předtím, než je lze externě zneužít. Čím více je cíl lákavější, tím pravděpodobnější, že se ho externí aktéři pokusí zneužít, a existuje několik cílů na světě, které jsou lákavější než Azure.

Monitorování

Pokud by se útočník pokusil proniknout do aplikace, mělo by se na ni upozornit. Často je možné útoky odhalit prozkoumáním protokolů ze služeb. Útoky zanechávají znepokojivé signály, které lze odhalit dříve, než se jim podaří. Útočník, který se například pokusí odhadnout heslo, provede mnoho požadavků na přihlašovací systém. Monitorování kolem přihlašovacího systému dokáže rozpoznat divné vzory, které nejsou v souladu s typickým vzorem přístupu. Toto monitorování se dá převést na výstrahu, která může naopak upozornit provozní osobu, aby aktivoval nějaký druh protipomětů. Vysoce vyspělý monitorovací systém může dokonce na základě těchto odchylek aktivně přidávat pravidla pro blokování požadavků nebo omezování odpovědí.

Zabezpečení sestavení

Jedním z míst, kde je zabezpečení často přehlédnuto, je proces sestavení. Stavba by měla nejen spouštět bezpečnostní kontroly, jako je skenování nezabezpečeného kódu nebo uložených přihlašovacích údajů, ale měla by být sama o sobě zabezpečená. Pokud dojde k ohrožení zabezpečení buildového serveru, poskytuje fantastický vektor pro zavedení libovolného kódu do produktu.

Představte si, že útočník chce ukrást hesla lidí, kteří se přihlašují k webové aplikaci. Mohli by zavést krok sestavení, který upraví stažený kód tak, aby přesměroval všechny žádosti o přihlášení na jiný server. Při příštím spuštění kódu ve sestavení se tiše aktualizuje. Kontrola zranitelností zdrojového kódu nezachytí toto ohrožení zabezpečení, protože se spouští před sestavením. Stejně tak ho nikdo nezjistí v revizi kódu, protože kroky sestavení existují na serveru sestavení. Zneužitý kód přejde do produkčního prostředí, kde může získat hesla. Pravděpodobně neexistuje žádný protokol auditu změn procesu sestavení nebo alespoň nikdo nehlídá audit.

Tento scénář je dokonalým příkladem cíle, který se zdá málo hodnotný, ale může být využit pro nabourání se do systému. Jakmile útočník překročí hranice systému, může začít pracovat na hledání způsobů, jak zvýšit oprávnění k bodu, kdy může způsobit skutečné škody kdekoli, kde se jim líbí.

Sestavení zabezpečeného kódu

.NET Framework je již poměrně zabezpečená architektura. Vyhne se některým úskalím nespravovaného kódu, jako je například procházka od konce polí. Práce se aktivně provádí za účelem opravy bezpečnostních otvorů při jejich zjištění. Existuje dokonce i program odměn za chyby, který platí výzkumníkům za vyhledávání problémů v systému a jejich hlášení, místo aby je zneužívali.

Existuje mnoho způsobů, jak zabezpečit kód .NET. Následující pokyny, jako jsou pokyny pro bezpečné kódování pro článek .NET , jsou rozumným krokem k zajištění zabezpečení kódu od základů. OWASP top 10 je další neocenitelný průvodce sestavením zabezpečeného kódu.

Proces sestavení je dobrým místem k tomu, aby nástroje pro skenování detekovali problémy ve zdrojovém kódu předtím, než se dostanou do produkčního prostředí. Většina projektů má závislosti na některých dalších balíčcích. Nástroj, který dokáže vyhledat zastaralé balíčky, zachytí problémy v nočním buildu. I při vytváření imagí Dockeru je užitečné zkontrolovat a ujistit se, že základní image neobsahuje známá ohrožení zabezpečení. Další věcí, kterou je potřeba zkontrolovat, je, že nikdo nechtěně nekontroloval přihlašovací údaje.

Integrované zabezpečení

Azure je navržený tak, aby vyvažovaly použitelnost a zabezpečení pro většinu uživatelů. Různí uživatelé budou mít různé požadavky na zabezpečení, takže potřebují doladit přístup ke cloudovému zabezpečení. Microsoft publikuje velké množství informací o zabezpečení v Centru zabezpečení. Tento prostředek by měl být prvním zastavením pro ty profesionály, kteří chtějí pochopit, jak fungují integrované technologie pro zmírnění rizik útoků.

V Azure portálu je Azure Advisor systém, který neustále kontroluje prostředí a vytváří doporučení. Některá z těchto doporučení jsou navržená tak, aby ušetřila peníze uživatelům, ale jiná jsou navržená tak, aby identifikovala potenciálně nezabezpečené konfigurace, jako je například kontejner úložiště otevřený pro veřejnost a nechráněný virtuální sítí.

Síťová infrastruktura Azure

V místním prostředí pro nasazení je velké množství energie vyhrazené pro nastavení sítí. Nastavení směrovačů, přepínačů a podobných zařízení je složitá práce. Sítě umožňují určitým prostředkům komunikovat s jinými prostředky a v některých případech zabránit přístupu. Častým pravidlem v rámci sítě je omezit přístup z vývojového prostředí do produkčního prostředí pro případ, že by polorozvinutý kus kódu způsobil chybu a smazal velké množství dat.

Většina prostředků Azure PaaS má ihned po instalaci pouze základní a povolující nastavení sítě. Kdokoli na internetu má například přístup ke službě App Service. Nové instance serveru SQL jsou obvykle omezené, aby k nim externí strany neměly přístup, ale rozsahy IP adres, které používá samotný Azure, jsou povoleny. Zatímco SQL server je chráněný před externími hrozbami, útočník potřebuje pouze nastavit Azure můstek, ze kterého může zahájit útoky proti všem instancím SQL v Azure.

Naštěstí se většina prostředků Azure dá umístit do virtuální sítě Azure, která umožňuje jemně odstupňované řízení přístupu. Podobně jako místní sítě vytvářejí privátní sítě, které jsou chráněné před širším světem, jsou virtuální sítě ostrovy privátních IP adres, které se nacházejí v síti Azure.

Obrázek 9–1 Virtuální síť v Azure.

Stejně jako místní sítě mají bránu firewall, která řídí přístup k síti, můžete vytvořit podobnou bránu firewall na hranici virtuální sítě. Ve výchozím nastavení můžou všechny prostředky ve virtuální síti stále komunikovat s internetem. Jedná se pouze o příchozí připojení, která vyžadují určitou formu explicitní výjimky brány firewall.

Při navázání sítě je možné nastavit interní prostředky, jako jsou účty úložiště, aby umožňovaly přístup jenom k prostředkům, které jsou také ve virtuální síti. Tento firewall poskytuje další úroveň zabezpečení. Pokud by došlo k úniku klíčů pro tento účet úložiště, útočníci by se nemohli k úložišti připojit a zneužít uniklé klíče. Tento scénář je dalším příkladem principu nejnižšího oprávnění.

Uzly v clusteru Azure Kubernetes mohou být součástí virtuální sítě stejně jako jiné prostředky, které jsou pro Azure nativní. Tato funkce se nazývá Azure Container Networking Interface. V důsledku toho přiděluje podsíť ve virtuální síti, na které jsou umístěny virtuální počítače a obrazy kontejnerů.

Pokračujeme v cestě, která ilustruje princip nejnižších oprávnění, a ne každý prostředek ve virtuální síti musí komunikovat s každým dalším prostředkem. Například v aplikaci, která poskytuje webové rozhraní API pro účet úložiště a databázi SQL, je nepravděpodobné, že databáze a účet úložiště musí vzájemně komunikovat. Jakékoli sdílení dat mezi nimi by prošlo webovou aplikací. Proto je možné použít skupinu zabezpečení sítě (NSG) k odepření provozu mezi těmito dvěma službami.

Strategie odepření komunikace mezi prostředky může být obtížné implementovat, zejména když pocházíte ze zázemí používání Azure bez omezení provozu. V některých dalších cloudech je koncept skupin zabezpečení sítě mnohem častější. Výchozí zásada pro AWS je například ta, že prostředky nemohou mezi sebou komunikovat, dokud to nepovolí pravidla ve skupině zabezpečení sítě (NSG). I když je tento vývoj pomalejší, více omezující prostředí poskytuje bezpečnější výchozí nastavení. Používání správných postupů DevOps, zejména použití Azure Resource Manageru nebo Terraformu ke správě oprávnění, může usnadnit řízení pravidel.

Virtuální sítě můžou být užitečné také při nastavování komunikace mezi místními a cloudovými prostředky. Virtuální privátní síť se dá použít k bezproblémovému propojení těchto dvou sítí. Tento přístup umožňuje spuštění virtuální sítě bez jakéhokoli druhu brány pro scénáře, ve kterých jsou všichni uživatelé na místě. Existuje řada technologií, které lze použít k vytvoření této sítě. Nejjednodušší je použít site-to-site VPN, kterou lze navázat mezi mnoha směrovači a Azure. Provoz se šifruje a tuneluje přes internet za stejnou cenu za bajt jako jakýkoli jiný provoz. Pro scénáře, kdy je žádoucí větší šířka pásma nebo více zabezpečení, nabízí Azure službu s názvem Express Route , která používá privátní okruh mezi místní sítí a Azure. Je nákladnější a obtížnější vytvořit, ale také bezpečnější.

Řízení přístupu na základě role pro omezení přístupu k prostředkům Azure

RBAC je systém, který poskytuje identitu aplikacím běžícím v Azure. Aplikace mohou přistupovat k prostředkům pomocí této identity, místo používání klíčů nebo hesel, nebo kromě nich.

Subjekty zabezpečení

První komponentou v RBAC je bezpečnostní principál. Objekt zabezpečení může být uživatel, skupina, instanční objekt nebo spravovaná identita.

Obrázek 9–2 Různé typy bezpečnostních subjektů.

• Uživatel – Každý uživatel, který má účet v Azure Active Directory, je uživatel.
• Skupina – kolekce uživatelů z Azure Active Directory. Uživatel jako člen skupiny převezme kromě své vlastní role i role této skupiny.
• Služební principál – identita zabezpečení, pod kterou se spouštějí služby nebo aplikace.
• Spravovaná identita – identita Azure Active Directory spravovaná v Azure Spravované identity se obvykle používají při vývoji cloudových aplikací, které spravují přihlašovací údaje pro ověřování ve službách Azure.

Objekt zabezpečení se dá použít na prakticky jakýkoli prostředek. Tento aspekt znamená, že je možné přiřadit objekt zabezpečení ke kontejneru běžícímu v Azure Kubernetes, který umožňuje přístup k tajným kódům uloženým ve službě Key Vault. Funkce Azure Může převzít oprávnění, které mu umožní komunikovat s instancí Active Directory a ověřit JWT pro volajícího uživatele. Po povolení služeb pomocí service principal je možné jejich oprávnění spravovat granulárně pomocí rolí a oborů.

Seznam rolí

Objekt zabezpečení může mít mnoho rolí nebo, s použitím krejčovské analogie, může nosit mnoho klobouků. Každá role definuje řadu oprávnění, jako je například Čtení zpráv z koncového bodu služby Azure Service Bus. Platná sada oprávnění objektu zabezpečení je kombinace všech oprávnění přiřazených všem rolím, které má objekt zabezpečení. Azure má velký počet předdefinovaných rolí a uživatelé můžou definovat své vlastní role.

Obrázek 9–3 Definice rolí RBAC

Součástí Azure je také řada rolí vysoké úrovně, jako je vlastník, Přispěvatel, Čtenář a Správce uživatelských účtů. S rolí Vlastník může bezpečnostní principál přistupovat ke všem prostředkům a udělovat oprávnění ostatním. Přispěvatel má stejnou úroveň přístupu ke všem prostředkům, ale nemůže přiřadit oprávnění. Čtenář může zobrazit jenom existující prostředky Azure a správce uživatelských účtů může spravovat přístup k prostředkům Azure.

Podrobnější předdefinované role, jako je přispěvatel zóny DNS , mají práva omezená na jednu službu. Principály zabezpečení můžou mít libovolný počet rolí.

Rozsah působnosti

Role mohou být použity na omezenou sadu prostředků v Azure. Například při použití dosahu na předchozí příklad čtení z fronty služby Service Bus můžete zúžit oprávnění na jednu konkrétní frontu: "Čtení zpráv z koncového bodu služby Azure Service Bus blah.servicebus.windows.net/queue1"

Rozsah může být stejně úzký jako jeden prostředek nebo ho můžete použít pro celou skupinu prostředků, předplatné nebo dokonce i skupinu pro správu.

Při testování, jestli má objekt zabezpečení určité oprávnění, se bere v úvahu kombinace role a oboru. Tato kombinace poskytuje výkonný mechanismus autorizace.

Zamítnout

Dříve byla pro RBAC povolena pouze pravidla "allow". Toto chování způsobilo, že bylo složitější sestavit některé scopy. Například, aby objekt zabezpečení měl přístup ke všem účtům úložiště kromě jednoho, bylo nutné udělit explicitní oprávnění potenciálně nekonečnému seznamu úložišť. Pokaždé, když byl vytvořen nový účet úložiště, bude nutné ho přidat do tohoto seznamu účtů. Tím se přidaly režijní náklady na správu, které určitě nebyly žádoucí.

Pravidla zamítnutí mají přednost před pravidly povolení. Nyní lze stejný obor "allow all but one" (Povolit všechny kromě jednoho) reprezentovat dvěma pravidly: "povolit vše" a "zamítnout tento jeden konkrétní". Pravidla odepření nejen usnadňují správu, ale také umožňují, aby byly prostředky dodatečně zabezpečeny tím, že všem odepřou přístup.

Kontrola přístupu

Jak si můžete představit, pokud máte velký počet rolí a oborů, může být zjištění efektivního oprávnění principálu služby poměrně obtížné. Přidávání dalších pravidel zamítnutí slouží pouze ke zvýšení složitosti. Naštěstí existuje kalkulačka oprávnění, která může zobrazit efektivní oprávnění pro jakýkoli služební principál. Obvykle se nachází na kartě IAM na portálu, jak je znázorněno na obrázku 9–3.

Obrázek 9–4 Kalkulačka oprávnění pro službu aplikace

Zabezpečení tajných kódů

Hesla a certifikáty jsou běžným vektorem útoku pro útočníky. Hardware prolamování hesel provádí útok hrubou silou a pokouší se odhadnout miliardy hesel za sekundu. Proto je důležité, aby hesla, která se používají pro přístup k prostředkům, byla silná s velkým množstvím znaků. Tato hesla jsou přesně tím druhem hesel, která je téměř nemožné si zapamatovat. Hesla v Azure naštěstí nemusí být známá žádným člověkem.

Mnoho odborníků na zabezpečení navrhuje , aby použití správce hesel k zachování vlastních hesel bylo nejlepším přístupem. I když se hesla centralizuje na jednom místě, umožňuje také používat vysoce složitá hesla a zajistit, aby byla pro každý účet jedinečná. Stejný systém existuje v Rámci Azure: centrální úložiště tajných kódů.

Azure Key Vault

Azure Key Vault poskytuje centralizované umístění pro ukládání hesel pro věci, jako jsou databáze, klíče rozhraní API a certifikáty. Po zadání tajného kódu do trezoru se už nikdy nezobrazí a příkazy k extrakci a zobrazení jsou účelně složité. Informace v bezpečí jsou chráněny pomocí softwarového šifrování nebo ověření modulů hardwarového zabezpečení úrovně 140-2 FIPS 2.

Přístup k trezoru klíčů je řízen prostřednictvím RBAC, což znamená, že informace v trezoru nemůže získat každý uživatel. Řekněme, že webová aplikace chce získat přístup k připojovacímu řetězci databáze uloženému ve službě Azure Key Vault. Aby aplikace získaly přístup, musí běžet pomocí principálu služby. Pod touto předpokládanou rolí můžou číst tajné kódy z trezoru. Existuje řada různých nastavení zabezpečení, která můžou dále omezit přístup, který má aplikace k trezoru, aby nemohl aktualizovat tajné kódy, ale jen je číst.

Přístup k trezoru klíčů je možné monitorovat, aby se zajistilo, že k trezoru přistupují jenom očekávané aplikace. Protokoly je možné integrovat zpět do služby Azure Monitor a odemknout možnost nastavit výstrahy v případě, že dojde k neočekávaným podmínkám.

Kubernetes

V Kubernetes existuje podobná služba pro údržbu malých tajných informací. Tajné kódy Kubernetes je možné nastavit prostřednictvím typického kubectl spustitelného souboru.

Vytvoření tajného kódu je stejně jednoduché jako nalezení verze base64 hodnot, které se mají uložit:

echo -n 'admin' | base64
YWRtaW4=
echo -n '1f2d1e2e67df' | base64
MWYyZDFlMmU2N2Rm

Potom ho přidejte do souboru tajných kódů pojmenovaného secret.yml například tak, aby vypadal podobně jako v následujícím příkladu:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm

Nakonec můžete tento soubor načíst do Kubernetes spuštěním následujícího příkazu:

kubectl apply -f ./secret.yaml

Tyto tajné kódy je pak možné připojit ke svazkům nebo zpřístupnit procesům kontejneru prostřednictvím proměnných prostředí. Přístup dvanáctifaktorové aplikace k vytváření aplikací navrhuje použití nejnižšího společného jmenovatele k přenosu nastavení do aplikace. Proměnné prostředí jsou nejnižším společným jmenovatelem, protože jsou podporované bez ohledu na operační systém nebo aplikaci.

Alternativou k použití integrovaných tajných kódů Kubernetes je přístup k tajným kódům ve službě Azure Key Vault v rámci Kubernetes. Nejjednodušším způsobem, jak to udělat, je přiřadit kontejneru roli RBAC, která chce načíst tajné kódy. Aplikace pak může pro přístup k tajným kódům použít rozhraní API služby Azure Key Vault. Tento přístup ale vyžaduje úpravy kódu a neodpovídá vzoru použití proměnných prostředí. Místo toho je možné do kontejneru vložit hodnoty. Tento přístup je ve skutečnosti bezpečnější než použití tajných kódů Kubernetes přímo, protože k nim mají přístup uživatelé v clusteru.

Šifrování během přenosu a v klidu

Udržování dat v bezpečí je důležité, ať už je na disku nebo probíhá přenos mezi různými službami. Nejúčinnější způsob, jak zabránit úniku dat, je šifrovat je ve formátu, který ostatní snadno nečte. Azure podporuje širokou škálu možností šifrování.

Na cestě

Provoz v síti v Azure můžete šifrovat několika způsoby. Přístup ke službám Azure se obvykle provádí přes připojení, která používají protokol TLS (Transport Layer Security). Například všechna připojení k rozhraním API Azure vyžadují připojení TLS. Stejně tak je možné připojení ke koncovým bodům v úložišti Azure omezit tak, aby fungovala jenom přes šifrovaná připojení TLS.

TLS je komplikovaný protokol a jednoduše vědět, že připojení používá TLS, nestačí k zajištění zabezpečení. Například PROTOKOL TLS 1.0 je chronicky nezabezpečený a protokol TLS 1.1 není mnohem lepší. I ve verzích protokolu TLS existují různá nastavení, která usnadňují dešifrování připojení. Nejlepším samozřejmě je zkontrolovat a zjistit, jestli připojení k serveru používá up-to-date a dobře nakonfigurované protokoly.

Tuto kontrolu může provést externí služba, jako je test serveru SSL od SSL Labs. Testovací běh na typickém koncovém bodu Azure, v tomto případě koncový bod služby Service Bus, poskytuje téměř dokonalé skóre A.

I služby, jako jsou databáze Azure SQL, používají šifrování TLS k zachování skrytých dat. Zajímavá část o šifrování přenášených dat pomocí protokolu TLS spočívá v tom, že ani Microsoft nemůže naslouchat na připojení mezi počítači, na kterých běží protokol TLS. To by mělo společnostem přinést útěchu, které se obávají, že jejich data mohou být ohrožena přímo Microsoftem nebo dokonce státním aktérem s více prostředky než má běžný útočník.

Obrázek 9–5 Sestava testovacích prostředí SSL zobrazující skóre A pro koncový bod služby Service Bus

I když tato úroveň šifrování nebude po celou dobu dostatečná, měla by inspirovat důvěru, že připojení k protokolu TLS Azure jsou poměrně zabezpečená. Azure bude i nadále vyvíjet své standardy zabezpečení, protože se zvyšuje šifrování. Je dobré vědět, že někdo sleduje standardy zabezpečení a aktualizuje Azure při vylepšování.

V klidu

V libovolné aplikaci existuje řada míst, kde data na disku leží. Samotný kód aplikace se načte z nějakého mechanismu úložiště. Většina aplikací také používá nějaký druh databáze, jako je SQL Server, Cosmos DB nebo dokonce úžasně cenově efektivní Table Storage. Všechny tyto databáze využívají silně šifrované úložiště, aby nikdo jiný než aplikace s odpovídajícími oprávněními mohl číst vaše data. I systémové operátory nemohou číst data, která jsou zašifrovaná. Zákazníci tak budou mít jistotu, že jejich tajné informace zůstanou tajné.

Skladování

Základem velké části Azure je modul Azure Storage. Disky virtuálních počítačů jsou nasazeny nad Azure Storage. Služba Azure Kubernetes Service běží na virtuálních počítačích, které jsou samy o sobě hostované ve službě Azure Storage. Dokonce i bezserverové technologie, jako jsou Azure Functions Apps a Azure Container Instances, využívají disk, který je součástí služby Azure Storage, dokud jim nedojde volné místo.

Pokud je Služba Azure Storage dobře zašifrovaná, poskytuje základ pro většinu ostatních funkcí, které se mají také šifrovat. Azure Storage je šifrovaný pomocí standardu FIPS 140-2 vyhovující 256bitové verzi AES. Jedná se o dobře považovanou technologii šifrování, která byla předmětem rozsáhlé akademické kontroly za posledních 20 let. V současné době neexistuje žádný známý praktický útok, který by někomu umožnil bez znalosti klíče číst data zašifrovaná službou AES.

Ve výchozím nastavení spravuje Microsoft klíče používané k šifrování služby Azure Storage. Existuje rozsáhlá ochrana, která zajistí, aby se zabránilo škodlivému přístupu k těmto klíčům. Uživatelé s konkrétními požadavky na šifrování ale můžou také poskytovat vlastní klíče úložiště spravované ve službě Azure Key Vault. Tyto klíče lze kdykoli odvolat, což by efektivně způsobilo, že obsah účtu úložiště využívajícího tyto klíče by se stal neplatným.

Virtuální počítače používají šifrované úložiště, ale je možné poskytnout další vrstvu šifrování pomocí technologií, jako je BitLocker ve Windows nebo DM-Crypt v Linuxu. Tyto technologie znamenají, že i když došlo k úniku image disku z úložiště, zůstane téměř nemožné ji přečíst.

Azure SQL

Databáze hostované v Azure SQL používají technologii s názvem Transparentní šifrování dat (TDE), která zajišťuje, že data zůstanou šifrovaná. Ve výchozím nastavení je povolená ve všech nově vytvořených databázích SQL, ale pro starší databáze je nutné ji povolit ručně. Transparentní šifrování dat (TDE) provádí v reálném čase šifrování a dešifrování nejen databáze, ale také záloh a transakčních protokolů.

Parametry šifrování jsou uloženy v master databázi a při spuštění se načtou do paměti pro zbývající operace. To znamená, že master databáze musí zůstat nešifrovaná. Skutečný klíč spravuje Microsoft. Uživatelé s přesnými požadavky na zabezpečení ale můžou ve službě Key Vault poskytnout vlastní klíč stejným způsobem jako pro Azure Storage. Key Vault poskytuje služby, jako je obměny klíčů a odvolání.

Transparentní část TDS pochází ze skutečnosti, že pro použití šifrované databáze nejsou potřeba změny klienta. I když tento přístup poskytuje dobré zabezpečení, únik hesla databáze stačí k tomu, aby uživatelé mohli data dešifrovat. Existuje jiný přístup, který šifruje jednotlivé sloupce nebo tabulky v databázi. Funkce Always Encrypted zajišťuje, že v žádném okamžiku se šifrovaná data v databázi nezobrazí ve formátu prostého textu.

Nastavení této úrovně šifrování vyžaduje spuštění průvodce v aplikaci SQL Server Management Studio k výběru typu šifrování a umístění ve službě Key Vault k uložení přidružených klíčů.

Obrázek 9–6 Výběr sloupců v tabulce, které se mají šifrovat pomocí funkce Always Encrypted

Klientské aplikace, které čtou informace z těchto šifrovaných sloupců, musí být uzpůsobeny pro čtení šifrovaných dat. Připojovací řetězce je potřeba aktualizovat pomocí Column Encryption Setting=Enabled a přihlašovací údaje klienta se musí načíst z Key Vault. Klient SQL Serveru pak musí být vybaven šifrovacími klíči sloupce. Po dokončení budou zbývající akce používat standardní rozhraní klienta SQL. To znamená, že nástroje, jako je Dapper a Entity Framework, které jsou postavené na SQL Clientu, budou i nadále fungovat beze změn. Funkce Always Encrypted zatím nemusí být k dispozici pro každý ovladač SQL Serveru v každém jazyce.

Kombinace transparentního šifrování dat a funkce Always Encrypted, z nichž obě se dají použít s klíči specifickými pro klienta, zajišťuje, že se podporují i ty nejpřesnější požadavky na šifrování.

Cosmos DB (databázový systém)

Cosmos DB je nejnovější databáze poskytovaná Microsoftem v Azure. Byla postavena od základů s ohledem na zabezpečení a kryptografii. Šifrování AES-256bit je standardní pro všechny databáze Cosmos DB a nedá se zakázat. V kombinaci s požadavkem tls 1.2 pro komunikaci je celé řešení úložiště šifrované.

Obrázek 9–7 Tok šifrování dat ve službě Cosmos DB.

I když Cosmos DB neposkytuje šifrovací klíče zákazníka, tým provedl značné kroky, aby zajistil, že zůstane PCI-DSS kompatibilní bez toho. Cosmos DB také nepodporuje žádné druhy šifrování s jedním sloupcem, podobně jako funkce Always Encrypted v Azure SQL.

Udržování bezpečnosti

Azure má všechny nástroje potřebné k vydání vysoce zabezpečeného produktu. Řetězec je však stejně silný jako jeho nejslabší spojení. Pokud se aplikace nasazené nad Azure nevyvíjí se správným zabezpečením a dobrými audity zabezpečení, stanou se slabým propojením v řetězci. Existuje mnoho skvělých nástrojů pro statickou analýzu, knihoven šifrování a postupů zabezpečení, které je možné použít k zajištění zabezpečení softwaru nainstalovaného v Azure jako samotný Azure. Mezi příklady patří nástroje pro statickou analýzu a knihovny šifrování.

předchozíDalší