Osvědčené postupy zabezpečení SQL Serveru

platí pro: SQL Server Azure SQL DatabaseAzure SQL Managed Instance

Tento článek obsahuje informace o osvědčených postupech a pokynech, které pomáhají stanovit zabezpečení pro SQL Server. Komplexní přehled funkcí zabezpečení SQL Serveru najdete v tématu Zabezpečení SQL Serveru.

Konkrétní osvědčené postupy zabezpečení produktů najdete v tématu Azure SQL Database a SQL Managed Instance a SQL Server na virtuálních počítačích Azure.

Přehled

Metodologie vrstveného zabezpečení poskytuje podrobné řešení ochrany s využitím více možností zabezpečení, které jsou zaměřené na různé obory zabezpečení. Funkce zabezpečení dostupné v SQL Serveru 2016 a vylepšené v následných verzích pomáhají proti hrozbám zabezpečení a poskytují dobře zabezpečené databázové aplikace.

Azure splňuje několik oborových předpisů a standardů, které vám umožní vytvořit kompatibilní řešení s SQL Serverem běžícím na virtuálním počítači. Informace o dodržování právních předpisů v Azure najdete v Centru zabezpečení Azure.

Ochrana na úrovni sloupců

Organizace často potřebují chránit data na úrovni sloupců, protože data týkající se zákazníků, zaměstnanců, obchodních tajemství, produktových dat, zdravotní péče, finančních a dalších citlivých dat se často ukládají v databázích SQL Serveru. Mezi citlivé sloupce často patří identifikační a sociální pojištění, mobilní telefonní čísla, jméno, jméno rodiny, identifikace finančního účtu a jakákoli jiná data, která by mohla být považována za osobní údaje.

Metody a funkce uvedené v této části zvýší úroveň ochrany na úrovni sloupce s minimální režií a nevyžaduje rozsáhlé změny kódu aplikace.

Použijte Always Encrypted k šifrování dat v klidu a během přenosu. Šifrovaná data jsou dešifrována pouze klientskými knihovnami na úrovni klienta aplikace. Pokud je to možné, použijte randomizované šifrování. Funkce Always Encrypted se zabezpečenými enklávy může zlepšit výkon operací porovnání, jako jsou BETWEEN, IN, LIKE, DISTINCT, Joins a další pro scénáře náhodného šifrování.

Pomocí dynamického maskování dat (DDM) můžete obfusovat data na úrovni sloupce, pokud funkce Always Encrypted není dostupná. Dynamické maskování dat (DDM) není kompatibilní s funkcí Always Encrypted. Vždy, když je to možné, používejte funkci Always Encrypted přes dynamické maskování dat.

Oprávnění na úrovni sloupce můžete také udělit tabulce, zobrazení nebo funkci s hodnotou tabulky. Zvažte následující: - Pouze SELECT, REFERENCESa UPDATE oprávnění lze udělit u sloupce. – Úroveň DENY tabulky nemá přednost před úrovní GRANTsloupce .

Ochrana na úrovni řádků

Row-Level Zabezpečení (RLS) umožňuje používat kontext spuštění uživatele, aby mohl řídit přístup k řádkům v tabulce databáze. Zabezpečení na úrovni řádků zajišťuje, aby uživatelé viděli jenom záznam, který se k nim vztahuje. Tím získáte zabezpečení aplikace na úrovni záznamů, aniž byste museli provádět významné změny aplikace.

Obchodní logika je zapouzdřená v tabulkových funkcích řízených zásadami zabezpečení, které přepínají funkcionalitu RLS zapnutou a vypnutou. Zásady zabezpečení také řídí FILTER a BLOCK predikáty, které jsou vázány na tabulky, proti nimž RLS funguje. Pomocí Row-Level Zabezpečení (RLS) omezte záznamy, které se vrací uživateli uskutečňujícímu volání. Použijte SESSION_CONTEXT (T-SQL) pro uživatele, kteří se připojují k databázi prostřednictvím aplikace střední vrstvy, kde uživatelé aplikace sdílejí stejný uživatelský účet SQL Serveru. Pokud chcete zajistit optimální výkon a možnosti správy, postupujte podle osvědčených postupů zabezpečeníRow-Level.

Návod

Použijte Row-Level zabezpečení (RLS) společně s funkcí Always Encrypted nebo dynamickým maskováním dat (DDM) k maximalizaci úrovně zabezpečení vaší organizace.

Šifrování souborů

Transparentní šifrování dat (TDE) chrání data na úrovni souboru tím, že zajišťuje šifrování neaktivních dat pro databázové soubory. Transparentní šifrování dat (TDE) zajišťuje, že soubory databáze, záložní soubory a tempdb soubory nelze připojit a číst bez správných certifikátů k dešifrování databázových souborů. Bez transparentního šifrování dat je možné útočníkovi vzít fyzické médium (jednotky nebo záložní pásky) a obnovit nebo připojit databázi ke čtení obsahu. Transparentní šifrování dat (TDE) je podporováno pro práci se všemi ostatními funkcemi zabezpečení na SQL Serveru. Transparentní šifrování dat (TDE) poskytuje V/V šifrování a dešifrování dat a souborů protokolů v reálném čase. Šifrování pomocí technologie TDE používá šifrovací klíč databáze (DEK), který je uložen v uživatelské databázi. Šifrovací klíč databáze lze také chránit pomocí certifikátu, který je chráněn hlavním klíčem master databáze databáze.

Použijte TDE k ochraně dat v klidu, záloh a tempdb.

Auditování a reportování

Pokud chcete auditovat SQL Server, vytvořte zásadu auditu na úrovni serveru nebo databáze. Zásady serveru platí pro všechny existující a nově vytvořené databáze na serveru. Pro zjednodušení povolte auditování na úrovni serveru a nechte auditování na úrovni databáze zdědit tuto vlastnost pro všechny databáze.

Auditujte tabulky a sloupce s citlivými daty, u kterých jsou použita bezpečnostní opatření. Pokud je tabulka nebo sloupec dostatečně důležitá, aby potřebovala ochranu pomocí funkce zabezpečení, měli byste ji považovat za důležitou k auditování. Je zvlášť důležité auditovat a pravidelně kontrolovat tabulky, které obsahují citlivé informace, ale pokud není možné použít požadovaná bezpečnostní opatření kvůli nějakému druhu omezení aplikace nebo architektury.

Identity a ověřování

SQL Server podporuje dva režimy ověřování, režim ověřování systému Windows a režim ověřování systému SQL Server a Windows (smíšený režim).

Přihlášení jsou oddělená od uživatelů databáze. Nejprve přiřaďte přihlašovací údaje nebo skupiny Windows k uživatelům databáze nebo rolím samostatně. Dále udělte uživatelům, rolím serveru a/nebo databázovým rolím oprávnění pro přístup k databázovým objektům.

SQL Server podporuje následující typy přihlášení:

• Místní uživatelský účet systému Windows nebo účet domény služby Active Directory – SQL Server spoléhá na Systém Windows k ověření uživatelských účtů systému Windows.
• Skupina Windows – Udělení přístupu ke skupině Windows uděluje přístup ke všem přihlášením uživatelů systému Windows, která jsou členy skupiny. Odebrání uživatele ze skupiny odebere práva uživatele, který pochází ze skupiny. Upřednostňovanou strategií je členství ve skupinách.
• Přihlášení k SQL Serveru – SQL Server ukládá uživatelské jméno a hodnotu hash hesla v master databázi.
• Uživatelé interní databáze ověřují připojení k SQL Serveru na úrovni databáze. Obsažená databáze je databáze, která je izolovaná od jiných databází a od instance SQL Serveru (a master databáze), která je hostitelem databáze. SQL Server podporuje uživatele obsažené databáze pro ověřování jak systému Windows, tak SQL Server.

Následující doporučení a osvědčené postupy pomáhají zabezpečit identity a metody ověřování:

• Ke zlepšení správy zabezpečení použijte strategie zabezpečení na základě nejnižších oprávnění .

  • Je standardní umístit uživatele služby Active Directory do skupin AD, skupiny AD by měly existovat v rolích SQL Serveru a role SQL Serveru by měly mít udělená minimální oprávnění požadovaná aplikací.

• V Azure použijte zabezpečení s nejnižšími oprávněními pomocí řízení přístupu na základě role (RBAC).

• Vždy, když je to možné, zvolte Active Directory místo ověřování SQL Serveru a obzvláště preferujte Active Directory před uložením zabezpečení na úrovni aplikace nebo databáze.

  • Pokud uživatel opustí společnost, je snadné účet zakázat.
  • Při změně rolí nebo opuštění organizace je také snadné odebrat uživatele ze skupin. Zabezpečení skupin se považuje za osvědčený postup.

• Pro účty, které mají přístup na úrovni počítače, použijte vícefaktorové ověřování , včetně účtů, které k přihlášení k počítači používají protokol RDP. To pomáhá chránit před krádeží nebo únikem přihlašovacích údajů, protože jednofaktorové ověřování založené na heslech je slabší forma ověřování s přihlašovacími údaji s rizikem napadení nebo omylem uděleného.

• Vyžadovat silná a složitá hesla , která se nedají snadno odhadnout a nepoužívají se pro žádné jiné účty nebo účely. Pravidelně aktualizujte hesla a vynucujte zásady služby Active Directory.

• Group-Managed účty služeb (gMSA) poskytují automatickou správu hesel, zjednodušenou správu hlavního názvu služby (SPN) a delegují správu jiným správcům.

  • V případě gMSA spravuje operační systém Windows hesla pro účet, místo aby správce heslo ručně spravoval.
  • GMSA automaticky aktualizuje hesla účtu bez restartování služeb.
  • gMSA snižuje administrativní úroveň a zlepšuje oddělení povinností.

• Minimalizujte práva udělená účtu AD DBA; Zvažte oddělení povinností, které omezují přístup k virtuálnímu počítači, schopnost přihlásit se k operačnímu systému, schopnost upravovat protokoly chyb a auditování a schopnost instalovat aplikace a/nebo funkce.

• Zvažte odebrání účtů DBA z role správce systému a udělení ŘÍZENÍ SERVERU účtům DBA místo toho, aby byly členem role správce systému. Role správce systému nerespektuje DENY , zatímco CONTROL SERVER dělá.

Historie dat a integrita dat

Udržování historických záznamů o změnách dat v průběhu času může být užitečné k řešení náhodných změn dat. Může být také užitečné pro auditování změn aplikací a může obnovit datové prvky, když chybný aktér zavádí změny dat, které nebyly autorizované.

• Dočasné tabulky slouží k zachování verzí záznamů v průběhu času a k zobrazení dat v průběhu životnosti záznamu za účelem zobrazení historických dat vaší aplikace.
• Dočasné tabulky lze použít k zadání verze aktuální tabulky v libovolném okamžiku.

Nástroje a vyhodnocení posouzení zabezpečení

Následující nástroje pro konfiguraci a posouzení řeší zabezpečení plochy, identifikují příležitosti zabezpečení dat a poskytují osvědčené postupy při posuzování zabezpečení prostředí SQL Serveru na úrovni instance.

• Konfigurace oblasti Surface – Pokud chcete minimalizovat počet funkcí, které může uživatel se zlými úmysly napadnout, měli byste povolit jenom funkce vyžadované vaším prostředím.
• Posouzení ohrožení zabezpečení pro SQL Server (SSMS) – Posouzení ohrožení zabezpečení SQL je nástroj v SSMS verze 17.4 nebo novější , který pomáhá zjišťovat, sledovat a opravovat potenciální ohrožení zabezpečení databáze. Posouzení ohrožení zabezpečení je cenným nástrojem pro zlepšení zabezpečení databáze a provádí se na úrovni databáze pro každou databázi.
• Zjišťování a klasifikace dat SQL (SSMS) – je běžné, že dbA spravují servery a databáze a nevědí o citlivosti dat obsažených v databázi. Funkce Zjišťování a klasifikace dat přidává schopnost zjišťovat, klasifikovat, označovat a hlásit na úrovni citlivosti vašich dat. Zjišťování a klasifikace dat se podporuje od SSMS 17.5.

Běžné hrozby SQL

Pomáhá vědět, jaké jsou některé běžné hrozby, které riskují SQL Server:

• SQL injekce – SQL injekce je typ útoku, ve kterém se škodlivý kód vloží do řetězců, které jsou předávány instanci SQL Serveru ke spuštění.
  • Proces injektáže funguje ukončením textového řetězce a připojením nového příkazu. Vzhledem k tomu, že vložený příkaz může mít před spuštěním více připojených řetězců, útočník ukončí vložený řetězec značkou komentáře --.
  • SQL Server spustí všechny syntakticky platné dotazy, které jsou přijaty.
• Mějte na paměti útoky na vedlejší kanál, malware a další hrozby.

Rizika injektáže SQL

Pokud chcete minimalizovat riziko injektáže SQL, zvažte následující položky:

• Zkontrolujte všechny SQL procesy, které vytváří příkazy SQL z hlediska zranitelností vůči SQL injekcím.
• Vytváření dynamicky generovaných příkazů SQL parametrizovaným způsobem
• Vývojáři a správci zabezpečení by měli zkontrolovat veškerý kód, který volá EXECUTE, EXECnebo sp_executesql.
• Nepovolte následující vstupní znaky:
  • ;: Oddělovač dotazů
  • ': Oddělovač datových řetězců znaků
  • --: Oddělovač komentářů s jedním řádkem.
  • /* ... */: Oddělovače komentářů.
  • xp_: Uložené procedury rozšířené katalogem, například xp_cmdshell.
    • Nedoporučuje se používat xp_cmdshell v žádném prostředí SQL Serveru. Místo toho použijte SQLCLR nebo hledejte jiné alternativy kvůli rizikům, která mohou xp_cmdshell představovat.
• Vždy ověřte uživatelské vstupy a zabraňte úniku a vystavení chyb útočníkovi.

Rizika na straně kanálu

Pokud chcete minimalizovat riziko útoku na straně kanálu, zvažte následující:

• Ujistěte se, že jsou použity nejnovější opravy aplikací a operačního systému.
• V případě hybridních úloh se ujistěte, že se na jakýkoli hardware v místním prostředí použijí nejnovější opravy firmwaru.
• V Azure můžete pro vysoce citlivé aplikace a úlohy přidat další ochranu před útoky na straně kanálu s izolovanými virtuálními počítači, vyhrazenými hostiteli nebo pomocí důvěrných výpočetních virtuálních počítačů, jako jsou počítače řady DC a Virtual Machines, které používají procesory AMD EPYC třetí generace.

Hrozby infrastruktury

Zvažte následující běžné hrozby infrastruktury:

• Přístup hrubou silou – útočník se pokusí ověřit pomocí více hesel v různých účtech, dokud se nenajde správné heslo.
• Lámání hesel / password spray - útočníci použijí jedno pečlivě vytvořené heslo na všechny známé uživatelské účty (jedno heslo pro mnoho účtů). Pokud počáteční pokus o "password spray" selže, zkusí to znovu, s využitím jiného, pečlivě vytvořeného hesla, přičemž obvykle čekají určitý čas mezi pokusy, aby se zabránilo detekci.
• Útoky ransomwarem jsou typem cíleného útoku, kdy se malware používá k šifrování dat a souborů, což brání přístupu k důležitému obsahu. Útočníci se pak pokusí vymáhat peníze z obětí, obvykle ve formě kryptoměn, výměnou za dešifrovací klíč. Většina infekcí ransomwaru začíná e-mailovými zprávami s přílohami, které se snaží nainstalovat ransomware, nebo weby hostující sady zneužití, které se pokoušejí použít chyby zabezpečení ve webových prohlížečích a dalším softwaru k instalaci ransomwaru.

Rizika hesel

Protože nechcete, aby útočníci snadno odhadli názvy účtů nebo hesla, následující kroky pomáhají snížit riziko zjištění hesel:

• Vytvořte jedinečný účet místního správce, který nemá název Administrator.
• Používejte složitá silná hesla pro všechny vaše účty. Další informace o tom, jak vytvořit silné heslo, naleznete v článku o vytvoření silného hesla .
• Azure ve výchozím nastavení vybere ověřování systému Windows během instalace virtuálního počítače s SQL Serverem. Přihlášení SA je proto zakázané a heslo je přiřazeno nastavením. Doporučujeme, aby se přihlašovací jméno SA nepoužívalo ani nepovolilo. Pokud potřebujete přihlášení SQL, použijte jednu z následujících strategií:

  • Vytvořte účet SQL s jedinečným názvem, který má členství správce systému. Můžete to provést na portálu povolením ověřování SQL během zřizování.

    Návod

    Pokud během zřizování nepovolíte ověřování SQL, musíte ručně změnit režim ověřování na SQL Server a režim ověřování systému Windows. Pro více informací viz Změnit režim ověřování serveru.

  • Pokud musíte použít přihlášení SA , povolte přihlášení po zřízení a přiřaďte nové silné heslo.

Rizika ransomwaru

Pokud chcete minimalizovat rizika ransomwaru, zvažte následující:

• Nejlepší strategií ochrany před ransomwarem je věnovat zvláštní pozornost ohrožením zabezpečení protokolu RDP a SSH. Zvažte také následující doporučení:
  • Použijte firewally a uzamkněte porty
  • Ujistěte se, že se používají nejnovější aktualizace zabezpečení operačního systému a aplikací.
  • Používejte spravované skupinové účty služby (gMSA)
  • Omezení přístupu k virtuálním počítačům
  • Vyžadovat přístup Just-in-time (JIT) a Azure Bastion
  • Zlepšete zabezpečení povrchu tím, že se vyhnete instalaci nástrojů, včetně Sysinternals a SSMS, na místní počítač.
  • Vyhněte se instalaci funkcí, rolí a povolování služeb, které nejsou potřeba.
  • Kromě toho by mělo být naplánované pravidelné úplné zálohování, které je odděleně zabezpečené od běžného účtu správce, aby nemohlo odstranit kopie databází.

Související obsah

• Zabezpečení SQL Serveru
• Azure SQL Database a spravovaná instance SQL
• SQL Server na virtuálních počítačích Azure