Řešení pro scénář 1 – Návrh globálního škálování a zabezpečeného přístupu
V předchozí lekci jste si prošli scénář, který se týkal globálního škálování u sítě pro doručování obsahu. V této lekci si prohlédnete jedno možné řešení a některé aspekty, které je zapotřebí zvážit.
Průběžně byste měli porovnávat poskytnuté řešení s tím, které jste vyvinuli v předchozí lekci. Často pro kterýkoli problém existuje více než jedno řešení, ale vždy je to nějaký kompromis. Které položky v řešení se liší od návrhu? Existuje v řešení něco, co by stálo za přepracování? Je v poskytnutém řešení něco, o čem si myslíte, že se to v řešení řeší podrobněji?
Možnost nasazení a konfigurace
První rozhodnutí, které je zapotřebí zvážit, je výběr vhodné možnosti nasazení Azure SQL. I když by SQL Server ve virtuálním počítači Azure fungoval, nabídka PaaS (platforma jako služba) by mohla být vhodnější a vyžadovat menší režii při správě.
Zákazník používá modul CLR (Common Language Runtime), což je funkce pro konkrétní instanci. Azure SQL Managed Instance je jediná možnost nasazení PaaS, která podporuje funkce pro konkrétní instance, jako jsou například modul CLR, Service Broker a Databázová pošta. Díky tomu může Azure SQL Managed Instance umožnit zákazníkovi přechod na nabídku PaaS, aniž by bylo nutné přepisovat jeho aplikace CLR na řešení kompatibilní s Azure SQL Database (jako jsou úlohy elastické databáze).
Další rozhodnutí se týká úrovně služby. Protože chce zákazník izolovat úlohy čtení a zápisu, bude úroveň služby Pro důležité obchodní informace nejjednodušší způsob, jak toho dosáhnout. Na této úrovni běží na pozadí skupiny dostupnosti AlwaysOn. Jedna z těchto sekundárních replik se dá použít pro úlohy jen pro čtení.
Úroveň Pro důležité obchodní informace je tady jen polovinou konfigurace oddělení úloh čtení a zápisu. Scénář říká, že zákazník potřebuje mít možnost škálovat do několika oblastí s několika dotazy, které se budou provádět najednou, a k tomu zachovávat izolaci úloh čtení a zápisu.
Dvě možnosti, které můžou potenciálně řešit tento problém, jsou geografická replikace a skupiny automatického převzetí služeb při selhání. Geografická replikace se ale v tuto chvíli v Azure SQL Managed Instance nepodporuje. Skupina automatického převzetí služeb při selhání je tak jediná možnost, která může v tomto scénáři pomoct získat globální škálu pro čtení.
Protože zákazník používá skupiny automatického převzetí služeb při selhání, bude jeho potřeba úrovně služby Pro důležité obchodní informace záviset na tom, kolik koncových bodů jen pro čtení jeho úloha analýzy potřebuje. Se skupinou automatického převzetí služeb při selhání na úrovni služby Pro důležité obchodní informace by získal tři čitelné koncové body:
- Jednu sekundární repliku ve skupině dostupnosti primární oblasti
- Sekundární skupinu převzetí služeb při selhání (což je primární replika databáze v sekundární oblasti)
- Sekundární repliku ze skupiny dostupnosti sekundární oblasti
Pokud úloha analýzy nepotřebuje všechny tyto čitelné repliky, nákladově efektivnější řešení by mohla být úroveň Obecné účely.
Výběr nejvhodnějších metod ověřování
Další část tohoto scénáře zahrnuje určení, jak nejlépe připojit každou aplikaci nebo uživatele k řešení s ohledem na nutnost vytvořit a použít ty nejbezpečnější možné technologie. Když tento scénář analyzujete, zjistíte, že k Azure SQL Managed Instance budou potřebovat přístup 4 různí klienti:
- Aplikace spuštěná na virtuálním počítači Azure
- Aplikace běžící na počítači mimo Azure připojeném k doméně
- Analytici databáze (DBA) a další uživatelé nástrojů pro správu SQL (SQL Server Management Studio, Azure Data Studio, PowerShell) na počítačích mimo Azure, které nejsou připojené k doméně
- Starší aplikace spuštěné na počítačích mimo Azure, kde nemůžete změnit ovladač ani připojovací řetězec
Podívejme se na každého z těchto klientů z hlediska, jak je možné zvolit metodu ověřování, a určitých dalších aspektů a omezení.
Aplikace spuštěná na virtuálním počítači Azure
Spravované identity pro prostředky Azure jsou obecně doporučovanou formou ověřování bez hesel pro aplikace spuštěné na virtuálních počítačích Azure.
Aplikace běžící na počítači mimo Azure připojeném k doméně
Pro počítače mimo Azure není možné použít spravované identity. Integrované ověřování přes Microsoft Entra ID je doporučená metoda ověřování pro aplikace spuštěné na počítačích připojených k doméně mimo Azure za předpokladu, že je doména federovaná s Microsoft Entra ID.
Pokud počítač mimo Azure není připojený k doméně, můžete:
- Vytvořte identitu aplikace pro vaši aplikaci v Microsoft Entra ID.
- Přidružit k identitě aplikace certifikát
- Upravit aplikaci tak, aby získávala token pro Azure SQL Database poskytnutím ID klienta a certifikátu
I když certifikát musí obsahovat privátní klíč a musí se nasadit na počítač, který hostuje vaši aplikaci, vyhnete se alespoň pevnému kódování tajného kódu aplikace do jejího kódu nebo konfigurace. (Pro aplikaci bude nutné nakonfigurovat kryptografický otisk certifikátu.)
Analytici DBA a jiní uživatelé nástrojů pro správu SQL na počítači mimo Azure, který není připojený k doméně
Pro uživatele mimo Azure se doporučuje odstranit nutnost používat hesla, pokud je to možné. Použití hesel s nástroji SQL můžete eliminovat pomocí integrovaného ověřování Microsoft Entra. Nástroje však musí běžet na počítači připojeném k doméně a doména musí být federovaná s ID Microsoft Entra, což není případ pro tento scénář.
Vzhledem k tomu, že prostředí nesplňuje požadavky na integrované ověřování, doporučujeme používat interaktivní ověřování Microsoft Entra s vícefaktorovým ověřováním, které podporuje většina nástrojů SQL.
Starší aplikace spuštěné na počítačích mimo Azure, kde nemůžete změnit ovladač ani připojovací řetězec
Ve scénářích, kde není možné změnit ovladač ani připojovací řetězec, dnes bohužel neexistuje způsob, jak hesla odstranit. Tyto starší aplikace musí i nadále používat ověřování SQL. Můžete ale zvážit možnost podrobněji prozkoumat omezení a způsob, jak se dají odstranit, abyste mohli využívat bezpečnější a zabezpečenější přístup ověřování aplikací.