Funkce a úlohy zabezpečení
Je známo, že SQL Server a služby Azure SQL Services kladou důraz na zabezpečení, a to konkrétně v kvalitě vyžadované velkými podniky. V této lekci se dozvíte o různých možnostech zabezpečení souvisejících se správou zabezpečení sítě a přístupu. V následujících lekcích získáte praktické zkušenosti s některými z těchto funkcí.
Zabezpečení sítě
První vrstva zabezpečení zahrnuje síť. Možnosti a úlohy sítí se liší mezi Azure SQL Database a službou Azure SQL Managed Instance. Informace o síťových možnostech služby Azure SQL Managed Instance najdete v tématu Architektura připojení pro službu Azure SQL Managed Instance.
Zabezpečení sítě ve službě Azure SQL Database
Při zabezpečování sítě pro službu Azure SQL Database jsou k dispozici čtyři hlavní možnosti:
- Povolení přístupu ke službám Azure
- Použití pravidel firewallu
- Použití pravidel virtuální sítě
- Použití služby Azure Private Link
Kromě těchto hlavních možností máte možnost blokovat veškerý veřejný přístup (jenom s Azure Private Linkem) a možnost vynutit minimální verzi protokolu TLS (Transport Layer Security). Nejméně zabezpečený, ale nejsnáze konfigurovatelný způsob je povolení přístupu ke službám Azure. Nejbezpečnější metodou je použití služby Private Link. Následující části popisují vlastnosti jednotlivých možností a jak je nakonfigurovat a udržovat.
Povolení přístupu ke službám Azure
Během nasazování služby Azure SQL Database máte možnost nastavit možnost Povolit službám a prostředkům Azure přístup k tomuto serveru na ano. Pokud zvolíte tuto možnost, budou mít všechny prostředky ze všech oblastí a předplatných možnost přístupu k vašim prostředkům. Tato možnost usnadňuje počáteční zprovoznění a připojení služby Azure SQL Database k dalším službám, jako jsou Azure Virtual Machines, Azure App Service, nebo dokonce Azure Cloud Shell, protože povolujete možnost připojení čehokoli z Azure.
Povolením přístupu ke službám Azure ale neumožňuje přístup čemukoli mimo Azure (například vašemu místnímu prostředí).
Nejbezpečnější konfigurací je nastavení Povolit službám a prostředkům Azure přístup k tomuto serveru na Ne, což blokuje všechna připojení a sítě kromě těch, které jste explicitně přidali, s různými možnostmi, které následují v dalších částech.
Pravidla brány firewall
Další možností je použít pravidla firewallu. Vaše výsledky můžou vypadat podobně jako u možnosti Povolit službám a prostředkům Azure přístup k tomuto serveru s tím rozdílem, že pro každou službu (na následujícím obrázku je virtuální počítač) budete muset přidat jedinečné pravidlo brány firewall, které mu umožní připojení. Pravidla brány firewall také umožňují místnímu prostředí připojit se k prostředku služby Azure SQL Database, protože můžete přidat pravidla pro počítače a aplikace ve vašem místním prostředí.
Můžete také povolit přístup ke službám Azure, abyste zajistili možnosti připojení v rámci Azure, a pak přidat pravidla firewallu jen pro vaše místní připojení. Jak jsme už zmínili, povolení přístupu ke službám a prostředkům Azure k tomuto serveru není tak bezpečné, protože umožňuje veškerý provoz Azure. Doporučujeme používat výhradně pravidla brány firewall.
Podívejme se na předchozí příklad s nakonfigurovanými pravidly brány firewall. Z nástroje, který podporuje Transact-SQL (T-SQL), jako je SQL Server Management Studio (SSMS), můžete z virtuálního počítače Azure ve virtuální síti SQLDBVNET-EUS spustit následující dotaz:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
Výsledek by byl 203.0.113.1. Toto je veřejná IP adresa virtuálního počítače Azure. I když používáme pravidla brány firewall, jsou všechna uskutečněná připojení veřejná.
Pravidla virtuálních sítí
Pokud chcete používat jenom pravidla brány firewall, může být nastavení složité. Použití pouze pravidel brány firewall znamená, že musíte zadat rozsah IP adres pro všechna vaše připojení, což může někdy mít dynamické IP adresy. Mnohem jednodušší alternativou je použití pravidel virtuální sítě k vytvoření a správě přístupu z konkrétních sítí, které obsahují virtuální počítače nebo jiné služby, které potřebují přístup k datům.
Pokud nakonfigurujete přístup z virtuální sítě pomocí pravidla virtuální sítě, budou pak mít všechny prostředky v této virtuální síti přístup k logickému serveru služby Azure SQL Database. To může zjednodušit složité konfigurování přístupu pro všechny IP adresy (statické a dynamické), které potřebují mít přístup k datům. Pomocí pravidel virtuální sítě můžete určit jednu nebo více virtuálních sítí včetně všech obsažených prostředků. Technologie virtuální sítě můžete také začít využívat k připojení sítí v různých oblastech v Azure i k místnímu prostředí.
V tomto příkladu, stejně jako v předchozí části, byste mohli spustit stejný dotaz z virtuálního počítače Azure ve virtuální síti „SQLDBVNET-EUS“:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
Výsledkem by teď byla adresa 10.0.0.2, což je privátní IP adresa tohoto virtuálního počítače Azure. Tento výsledek vás posune o krok blíž k vytváření privátních připojení k logickému serveru služby Azure SQL Database, protože teď se prostředky připojují přes virtuální síť.
Další běžnou strategií pro analýzu vašeho připojení je prozkoumání hierarchie DNS (Domain Name System). Na stejném virtuálním počítači Azure byste mohli na příkazovém řádku spustit následující příkaz:
nslookup aw-server.database.windows.net
Pomocí tohoto příkazu můžete získat podrobnosti související s infrastrukturou DNS. Výsledky by se podobaly následujícímu:
Server: Unknown
Address: 168.63.129.16
Non-authoritative answer:
Name: cr2.eastus1-a.control.database.windows.net
Address: 203.0.113.1
Aliases: aw-server.database.windows.net
dataslice2.eastus.database.windows.net
V rámci neautoritativní odpovědi je potřeba se podívat na některé důležité věci:
- Název: Koncový bod, který
cr2začíná, je součástí veřejné hierarchie DNS. Bez příliš velkého vstupu do hierarchie řekněme, žecr2se jedná o řídicí kruh 2 a že pod ní je více datových "řezů". - Adresa: Ip adresa vrácená zde by měla odpovídat veřejné IP adrese vašeho virtuálního počítače Azure. I když nástroj, jako je konečný segment směrování SSMS, může být prostřednictvím privátní IP adresy vašeho virtuálního počítače, veřejná IP adresa virtuálního počítače se stále používá k připojení v určité kapacitě.
- Aliasy: Aliasy jsou různé body v hierarchii DNS. V tomto případě se jedná o konkrétní datový řez a koncový bod, ke kterému se připojujete.
Poznámka:
V předchozím výstupním bloku je adresa 168.63.129.16 virtuální veřejná IP adresa, která se používá k usnadnění komunikačního kanálu s prostředky platformy Azure. To se týká všech oblastí a všech národních cloudů a nebude se to měnit.
I když připojení přes SSMS prochází privátní IP adresou virtuálního počítače Azure, stále se připojujete přes veřejný koncový bod.
Private Link pro Azure SQL Database
Viděli jste, jak nakonfigurovat nejbezpečnější síť pomocí vaší databáze ve službě Azure SQL Database s veřejným koncovým bodem. Tato metoda zabezpečení databáze ve službě SQL Database se používá už hodně let. V roce 2019 ale začal Azure směřovat ke konceptu privátního propojení (private link), který se ještě více podobá způsobu nasazování služby Azure SQL Managed Instance. Pomocí služby Azure Private Link se můžete připojit ke své databázi ve službě SQL Database a několika dalším nabídkám paaS (platforma jako služba) pomocí privátního koncového bodu. To znamená, že disponuje privátní IP adresou v rámci konkrétní virtuální sítě.
V předchozím příkladu si všimnete, že se obecná síťová infrastruktura nezměnila a stále můžete použít strategie připojení virtuální sítě z pravidel virtuální sítě. Nebudete ale muset vytvářet pravidla virtuální sítě. Prostředky, které se potřebují připojovat k databázovému serveru, musí mít přístup k virtuální síti, v níž se nachází daný koncový bod. V příkladu je SQLDBVNet-EUSkoncový bod . Přístup budou mít jen připojení procházející tímto privátním koncovým bodem – všem dalším připojením (například z internetu) bude přístup odepřen.
Jak budete pokračovat v tomto příkladu, můžete na virtuálním počítači Azure ve virtuální síti SQLDBVNet-EUSznovu spustit následující příkaz T-SQL:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
Výsledkem by teď byla 10.0.0.2privátní IP adresa virtuálního počítače Azure v tomto příkladu. Přidáním přístupu z virtuální sítě se zobrazí připojení ke službě Azure SQL Database z vašeho virtuálního počítače přes privátní IP adresu vašeho virtuálního počítače. To je stejný výsledek, který jste viděli u pravidel virtuální sítě.
Na hierarchii DNS byste se ale mohli podívat prostřednictvím příkazového řádku a následujícího příkazu:
nslookup aw-server.database.windows.net
Pokud použijete předchozí příkaz, budou se vaše výsledky s nakonfigurovaným privátním koncovým bodem mírně lišit:
Server: Unknown
Address: 168.63.129.16
Non-authoritative answer:
Name: aw-server.privatelink.database.windows.net
Address: 10.0.0.5
Aliases: aw-server.database.windows.net
V rámci neautoritativní odpovědi je potřeba se podívat na některé důležité věci:
- Název: Všimněte si, že už nepřekážíte na veřejnou hierarchii DNS, pouze na DNS služby Private Link. To znamená, že se zveřejňuje méně informací o vašem databázovém serveru.
- Adresy: U pravidel virtuální sítě je vrácená adresa veřejné IP adresy vašeho virtuálního počítače, ale teď by měla být jedna nebo více privátních IP adres v hierarchii Private Link (jedna je privátní koncový bod vaší služby Azure SQL Database).
- Aliasy: Stejně jako v poli Název se nic nesouvisí s hierarchií DNS, s tím rozdílem, že se stále můžete připojit k názvu serveru (například
aw-server.database.windows.net).
Možná vás zajímá, jestli se připojujete k privátnímu koncovému bodu, proč stále používáte stejný název serveru? Pokud v back-endu použijete pouze metodu Private Link pro připojení ke službě Azure SQL Database (to znamená, že žádná pravidla brány firewall nebo virtuální sítě), informace se zpracovávají takto:
aw-server.database.windows.net- Toto služba přeloží na
aw-server.privatelink.database.net.- Toto služba přeloží na
10.0.0.5(IP adresa vašeho privátního koncového bodu).
- Toto služba přeloží na
- Toto služba přeloží na
Služba vám navíc znemožní přímé připojení pomocí jakéhokoli jiného způsobu než aw-server.database.windows.net.
Správa přístupu
Po dokončení práce se síťovým přístupem je další vrstva, kterou je potřeba zvážit, správa přístupu.
Řízení přístupu na základě role
Všechny typy operací Azure pro Azure SQL Database se řídí prostřednictvím řízení přístupu na základě role (RBAC). Řízení přístupu na základě role je v současné době oddělené od zabezpečení Azure SQL, ale můžete si ho představit jako práva zabezpečení mimo vaši databázi ve službě SQL Database s oborem, který zahrnuje předplatné, skupinu prostředků a prostředek. Tato práva se týkají operací na portále Azure Portal, v Azure CLI a v Azure PowerShellu. Řízení přístupu RBAC umožňuje oddělit zodpovědnosti mezi nasazením, správou a používáním.
Předdefinované role jsou k dispozici, aby se snížila potřeba rolí RBAC vyšší úrovně, například vlastníka nebo přispěvatele. Tyto role můžete použít k tomu, aby určité osoby nasazovaly prostředky Azure SQL (nebo spravovaly zásady zabezpečení), ale udělte ostatním uživatelům skutečný přístup k používání nebo správě databáze. Přispěvatel SQL Serveru může například nasadit server a přiřadit uživatele, aby byl správcem serveru a databází. Mezi předdefinované role pro Azure SQL Database patří:
- Přispěvatel databáze SQL: Může vytvářet a spravovat databáze, ale nemá přístup k databázi (například se nemůže připojit a číst data)
- SQL Security Manager: Může spravovat zásady zabezpečení pro databáze a instance (například auditování), ale nemůže k nim získat přístup.
- Přispěvatel SQL Serveru: Může spravovat servery a databáze, ale nemůže k nim přistupovat.
Ověřování
Během nasazení logického serveru Azure SQL Database můžete zadat následující metodu ověřování:
- Použít pouze ověřování Microsoft Entra
- Použití ověřování SQL i Microsoft Entra
- Použití ověřování SQL
Správce serveru musí být během nasazování nastavený. Pro databáze ve službě Azure SQL Database je správcem serveru objekt zabezpečení na úrovni serveru pro logický server Azure SQL Database.
Pokud migrujete úlohu, která vyžaduje ověřování systému Windows nebo vaše organizace používá ID Microsoft Entra, můžete použít ID Microsoft Entra. Správce serveru Microsoft Entra můžete přiřadit pomocí portálu nebo nástrojů příkazového řádku.
Ověřování Microsoft Entra-only je výchozí možností při konfiguraci nového serveru. Přihlášení k serveru se zavedla, aby bylo možné povolit instanční objekty serveru Microsoft Entra, což jsou přihlášení ve virtuální master databázi služby SQL Database. Přihlášení Microsoft Entra můžete vytvořit z uživatelů, skupin a instančních objektů Microsoft Entra. Při použití ověřování Microsoft Entra-only můžete vytvořit přihlášení ověřování SQL a stávající přihlášení zůstanou. K logickému serveru se ale můžou připojit pouze přihlášení microsoft Entra a uživatelé. Další informace o ověřování microsoft Entra-only najdete v tématu Ověřování pouze Microsoft Entra pomocí Azure SQL.
V závislosti na tom, jak vaše organizace nakonfigurovala instanci Microsoft Entra, se k ní můžete připojit pomocí některé z následujících tří metod (například v SSMS):
Microsoft Entra ID – integrovaná: Neinteraktivní metoda, kterou můžete použít, pokud jste přihlášení k Windows pomocí přihlašovacích údajů Microsoft Entra z federované domény.
Microsoft Entra ID - Heslo: Neinteraktivní metoda, která umožňuje připojit se k hlavnímu názvu Microsoft Entra pomocí domény spravované ID Microsoft Entra. Informace z dokumentace:
To se může týkat nativních nebo federovaných uživatelů Microsoft Entra. Nativní uživatel je jeden explicitně vytvořený v Microsoft Entra ID a ověřuje se pomocí uživatelského jména a hesla, zatímco federovaný uživatel je uživatel s Windows, jehož doména je federovaná s Microsoft Entra ID. Druhou metodu (pomocí uživatelského jména a hesla) je možné použít, když chce uživatel použít přihlašovací údaje systému Windows, ale jeho místní počítač není připojený k doméně (například pomocí vzdáleného přístupu). V tomto případě může uživatel s Windows označit svůj účet domény a heslo a může se ověřit ve službě SQL Database nebo Azure Synapse Analytics (dříve SQL DW) pomocí federovaných přihlašovacích údajů.
Microsoft Entra ID – Univerzální s vícefaktorovým ověřováním (MFA): Interaktivní metoda, která chrání přístup k datům při plnění požadavků organizace na proces jednotného přihlašování pomocí vícefaktorového ověřování Microsoft Entra.
Pro Azure SQL Database existuje několik drobných odlišností. Můžete mít přihlášení, která existují ve virtuální master databázi, uživatelích databáze a dokonce i uživatelů databáze obsažených pro účty Microsoft Entra (doporučeno). I když správce serveru pro Azure SQL Database má sysadmin v podstatě práva, můžete vytvořit omezenější správce pomocí rolí na úrovni serveru nebo databáze. Pro službu SQL Database jsou k dispozici dvě role na úrovni databáze, které existují pouze ve virtuální master databázi:
- loginmanager: Role na úrovni databáze, která členům umožňuje vytvářet přihlášení pro databázový server
- dbmanager: Role na úrovni databáze, která členům umožňuje vytvářet a odstraňovat databáze pro databázový server.
Tady je seznam rolí na úrovni serveru ve službě Azure SQL Database:
- ##MS_DatabaseConnector##
- ##MS_DatabaseManager##
- ##MS_DefinitionReader##
- ##MS_LoginManager##
- ##MS_SecurityDefinitionReader##
- ##MS_ServerStateReader##
- ##MS_ServerStateManager##
Když pak budete nakonec nastavovat a konfigurovat ověřování a autorizaci, můžete využít čtyři postupy:
- Nasazení pomocí správce serveru
- Vytvoření dalších správců v případě potřeby
- Správci můžou vytvářet uživatele
- Udělování přístupu stejným způsobem jako na SQL Serveru
Další funkce
Až si prakticky vyzkoušíte některé možnosti sítě a ověřování, prostudujete si dále v tomto modulu další možnosti (a související úkoly) ochrany dat, monitorování, protokolování a auditování.