Řešení scénáře 2 – Nepostradatelné aplikace
V předchozí lekci jste procházeli scénář, který se týkal vysoké dostupnosti pro dispečerský systém 911. V této lekci si prohlédnete jedno možné řešení a několik dalších aspektů, 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ím krokem při řešení scénáře často bývá určování, která možnost nasazení Azure SQL by mohla být ta nejlepší. Pokud se zaměříte jen na smlouvu SLA (smlouva o úrovni služeb), požadavkem je 99,995% SLA, což dokáže nabídnout jen Azure SQL Database. Pro získání této smlouvy SLA musíte nasadit úroveň služby Pro důležité obchodní informace a povolit zóny dostupnosti.
Další rozhodnutí souvisejí s tím, jak povolit geografickou redundanci a zachovat vysokou dostupnost i při haváriích. I když je tady možné využít jak geografickou replikaci, tak skupiny automatického převzetí služeb při selhání, skupiny automatického převzetí služeb při selhání zákazníkovi umožní v případě potřeby převzít služby při selhání, aniž by bylo nutné měnit připojovací řetězce. Toto nastavení může pomoct omezit výpadky při aktualizaci připojovacích řetězců aplikace, protože je nebude nutné aktualizovat. Můžete nakonfigurovat i monitorovací dotazy, které budou kontrolovat stav. Díky tomu, pokud dojde k nějakému problému, můžete převzetí služeb při selhání dokonce i vynutit.
V takové konfiguraci je důležité myslet i na roli, kterou zastává kolokace. Aby se zachovala vysoká dostupnost, aplikace musí být co nejblíže k databázi. Zcela určitě musí být ve stejné oblasti. Budete chtít zajistit, že se aplikace nasadí v obou oblastech skupiny automatického převzetí služeb při selhání, proto existuje redundantní kopie aplikace (třeba webové). Pokud dojde k převzetí služeb při selhání, můžete použít Azure Traffic Manager a přesměrovat provoz na aplikaci v sekundární oblasti.
DBA a citlivá data
Koordinátoři dispečerského systému 911 vyjádřili obavy o ochranu citlivých dat (jako jsou zdravotní dokumentace a další osobní údaje), ale DBA zároveň musí mít možnost dělat svou práci.
Můžete využít několik technologií Azure SQL, které zajistí, že si analytici DBA nebudou moct zobrazovat citlivá data uložená v konkrétních sloupcích a že se veškerý přístup k tabulkám, které obsahují citlivá data, bude monitorovat. Používání SQL Auditu je osvědčeným postupem, jak monitorovat přístup, ale analytici DBA si stále budou moct zobrazovat data. Pomůže v tom klasifikace citlivých dat pomocí Klasifikace dat, protože se citlivá data popíšou a budete je moct sledovat v SQL Auditu. I s touto implementací si ale analytici DBA budou moct zobrazovat citlivá data. K maskování citlivých dat můžete použít Dynamické maskování dat, ale jen pomocí oprávnění není možné zamezit uživateli s oprávněním db_owner, aby si zobrazoval data uživatelů.
Pokud se v databázi nacházejí citlivá data, můžete uživatelům s oprávněním db_owner bezpečně znemožnit jejich zobrazování pomocí funkce Always Encrypted. Klíče Always Encrypted můžete spravovat pomocí oddělování rolí tak, aby správce zabezpečení nemohl přistupovat k databázi a analytik DBA nemohl přistupovat k fyzickému klíči ve tvaru prostého textu. Když se tato strategie použije v kombinaci s monitorováním prostřednictvím SQL Auditu, můžete monitorovat a maskovat citlivá data a sledovat přístup k nim, a to i pro analytiky DBA s oprávněními db_owner.
Citlivá data je sice nutné pro analytiky DBA maskovat, ale i tak potřebují mít možnost řešit problémy s výkonem pomocí přes Azure Portal a SQL Server Management Studio nebo Azure Data Studio. A musí mít možnost vytvářet nové uživatele databáze s omezením, kteří musí být namapováni na objekty zabezpečení Microsoft Entra.
Jedním zřešeních Pak přiřadíte skupinu k roli Přispěvatel SQL Serveru v rámci Azure RBAC (řízení přístupu na základě role). Nakonec můžete skupinu nastavit jako správce Microsoft Entra na logickém serveru.