Zabezpečení Azure pro aplikace nativní pro cloud

Tip

Tento obsah je výňatek z eBooku, Architekting Cloud Native .NET Applications for Azure, který je k dispozici na webu Docs pro .NET nebo jako soubor PDF zdarma 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 chybná data vložená 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 náročná na to, že se na ni nevyplatí energie. 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é Id umožňují zvýšit útoky (nahrazování Id=2Id=3 v adrese URL) nebo injektáž SQL, jsou pro vytváření ochrany proti útokům atraktivnější. Zmírnění těchto hrozeb je poměrně rozumné vytvořit a zabránit trapným bezpečnostním dírám, které rozmazávají pověst společnosti.

Princip nejmenšího 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, že řekněte v bance: přístup k trezoru je neobvyklá aktivita. Takže průměrný řekněte nemůže otevřít samotný 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 ji najít při nastavování bran firewall, skupin zabezpečení sítě, rolí a oborů v řízení přístupu na základě role (RBAC).

Testování průniku

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í nebo "penetrační testování" zahrnuje přenesení externích herců 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 lákavější cíl, tím pravděpodobnější, že se ho věční aktéři pokusí zneužít a ve světě existuje několik cílů, které jsou lákavější než Azure.

Sledová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 opouštějí znaménka, které je možné odhalit dříve, než budou úspěšné. Ú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í. Kromě toho, že sestavení spustí kontroly zabezpečení, jako je například kontrola nezabezpečeného kódu nebo přihlašovacích údajů se změnami, ale samotné sestavení by mělo být 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í rezervovaný kód tak, aby zrcadlil všechny žádosti o přihlášení na jiný server. Při příštím průchodu kódem sestavení se bezobslužně aktualizuje. Kontrola ohrožení zabezpečení zdrojového kódu nezachytí toto ohrožení zabezpečení při spuštění před sestavením. Stejně tak ho nikdo nechytí v revizi kódu, protože kroky sestavení jsou živé na buildovém serveru. 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 zdánlivě nízkohodnotového cíle, který lze použít k rozdělení 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 pro bounty chyby, který platí výzkumníkům najít problémy v rámci a hlásit je, místo aby je zneužít.

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ů.

Azure Advisor je na webu Azure Portal 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 otevření kontejneru úložiště pro svět 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 takové práce je složitá. 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 sítě je omezit přístup k produkčnímu prostředí z vývojového prostředí na základě pravděpodobnosti, že část kódu vyvinutá napůl vyvinutá část kódu spustí přepsání a odstraní swath dat.

Většina prostředků Azure PaaS má k dispozici pouze nejzásadnější a nejvýraznější nastavení sítě. Kdokoli na internetu má například přístup ke službě App Service. Nové instance SQL Serveru jsou obvykle omezené, aby k nim externí strany neměli přístup, ale rozsahy IP adres, které používá samotný Azure, jsou povolené prostřednictvím. Zatímco sql server je chráněný před externími hrozbami, útočník musí nastavit jen přemýšlení Azure, odkud může spustit ú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. Tato brána firewall poskytuje další úroveň zabezpečení, pokud by došlo k úniku klíčů pro tento účet úložiště, útočníci by se k němu nemohli připojit, aby mohli zneužít nevracené klíče. Tento scénář je dalším příkladem principu nejnižšího oprávnění.

Uzly v clusteru Azure Kubernetes se můžou účastnit 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é se přidělují virtuální počítače a image 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.

Zásada odepření komunikace mezi prostředky může být otravná implementací, zejména z pozadí 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 to, že prostředky nemůžou mezi sebou komunikovat, dokud pravidla ve skupině zabezpečení sítě nepovolí. 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 síť VPN typu site-to-site, kterou je možné 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 můžou přistupovat k prostředkům, které používají tuto identitu, místo nebo kromě klíčů nebo hesel.

Objekty zabezpečení

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

Obrázek 9–2 Různé typy objektů zabezpečení.

• 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.
• Instanční objekt – identita zabezpečení, ve které se spouští 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 u většiny prostředků. 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í instančního objektu je možné jejich oprávnění spravovat podrobněji pomocí rolí a oborů.

Role

Objekt zabezpečení může mít mnoho rolí nebo s použitím více sartoriální analogie nosí 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 uživatelský účet Správa istrator. S rolí Vlastník může objekt zabezpečení přistupovat ke všem prostředkům a přiřazovat 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 pouze existující prostředky Azure a uživatelský účet Správa istrator 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. Objekty zabezpečení můžou mít libovolný počet rolí.

Rozsahy

Role se dají použít na omezenou sadu prostředků v Rámci Azure. Například použití oboru na předchozí příklad čtení z fronty služby Service Bus můžete zúžit oprávnění na jednu frontu: "Čtení zpráv z koncového bodu blah.servicebus.windows.net/queue1služby Azure Service Bus"

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.

Odepřít

Dříve byla pro řízení přístupu na základě role povolena pouze pravidla "allow". Toto chování zkomplikovalo sestavení některých oborů. Například povolení přístupu objektu zabezpečení ke všem účtům úložiště s výjimkou jednoho, který vyžaduje explicitní oprávnění k potenciálně nekonečnému seznamu účtů úložiště. 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í představuje stejný obor "allow all but one" (Povolit vše, ale jeden) by teď mohl být reprezentován dvěma pravidly "allow all" a "deny this one specific one" (zamítnout tento konkrétní obor). Pravidla odepření nejen usnadňují správu, ale umožňují prostředky, které jsou navíc zabezpečené tím, že odepře přístup všem.

Kontrola přístupu

Jak si můžete představit, když máte velký počet rolí a oborů, může být zjištění efektivního oprávnění instančního objektu poměrně obtížné. Hromadit pravidla zamítnutí nad tím, 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 instanční objekt. 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 App Service

Zabezpečení tajných kódů

Hesla a certifikáty jsou běžným vektorem útoku pro útočníky. Hardware prolomení hesla může provést útok hrubou silou a pokusit 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ě druhem hesel, která si téměř nepamatují. 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 poskytován prostřednictvím služby RBAC, což znamená, že k informacím v trezoru nemají přístup jenom žádný uživatel. Řekněme, že webová aplikace chce přistupovat k databázi připojovací řetězec uložená ve službě Azure Key Vault. Aby aplikace získaly přístup, musí běžet pomocí instančního objektu. 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 neaktivních uložených dat

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. podpora Azure š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í k zajištění zabezpečení nestačí. 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á aktuální a dobře nakonfigurované protokoly.

Tuto kontrolu může provést externí služba, jako je test serveru SSL testovacího prostředí SSL. 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 microsoft nemusí naslouchat na připojení mezi počítači, na kterých běží protokol TLS. To by mělo společnosti utěšovat, že jejich data mohou být ohrožena správnými nebo dokonce státními aktéry s více prostředky, než je standardní ú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í.

Neaktivní uložený

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é.

Úložiště

Základem velké části Azure je modul Azure Storage. Disky virtuálních počítačů se připojují k 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, dochází na disku, který je součástí služby Azure Storage.

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 je možné kdykoli odvolat, což by efektivně vykreslovalo obsah účtu úložiště, který by je znepřístupňuje.

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 označovanou jako transparentní šifrování dat (TDE) k zajištění šifrování dat. 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 provádí šifrování a dešifrování nejen databáze v reálném čase, 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í mít zvláštní příspěvky pro čtení šifrovaných dat. Připojení řetězce je potřeba aktualizovat pomocí Column Encryption Setting=Enabled přihlašovacích údajů klienta a musí se načíst ze služby 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

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.

Služba Cosmos DB sice neposkytuje šifrovací klíče zákazníka, ale tým provedl značné kroky, aby zajistil, že bez toho dodržuje pcI-DSS. Cosmos DB také nepodporuje žádné druhy šifrování s jedním sloupcem, podobně jako funkce Always Encrypted v Azure SQL.

Zajištění zabezpečení

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, knihovny šifrování a postupy zabezpečení.

PředchozíDalší