Klíčové funkce zabezpečení serveru SQL

V tomto článku se podíváme na nástroje zabezpečení serveru SQL a doporučené postupy pro nastavení a zabezpečení této databáze DBMS..

Obsah:

• Ověřování na serveru SQL
• Autorizace na serveru SQL
• Aplikační role
• Filtrování dat na serveru SQL
• Schémata v SQL Serveru
• Šifrování dat pomocí serveru SQL
• Používání skupin spravovaných účtů služeb pro SQL Server
• Posouzení zranitelnosti serveru SQL pomocí SSMS
• Auditorská činnost na serveru SQL
• Doporučené postupy pro obecné zabezpečení serveru SQL

Nejprve si připomeňme základní bezpečnostní koncepty serveru SQL. MSSQL řídí přístup k objektům prostřednictvím autentizace a autorizace.

• Ověřování - Toto je proces přihlášení k serveru SQL, když uživatel odešle svá data na server. Ověřování identifikuje uživatele, který je ověřen;
• Přihlášení - jedná se o proces určení chráněných objektů, ke kterým má uživatel přístup a jaké operace jsou pro tyto prostředky povoleny.

Mnoho objektů serveru SQL má svá vlastní oprávnění, která lze zdědit od nadřazeného objektu. Oprávnění lze udělit jednotlivému uživateli, skupině nebo roli.

Ověřování na serveru SQL

Účet SQL Server lze rozdělit do dvou částí: Přihlašovací jméno a Uživatel.

• Přihlašovací jméno - Toto je globální přihlášení pro celou instanci serveru SQL. S ním projdete procesem autentizace;
• Uživatel - toto je člen databáze spojený s konkrétním přihlašovacím jménem.

Například přihlášení k serveru může být doména \ uživatelské jméno, a lze zavolat uživatele v databázi přidružené k tomuto přihlášení domain_databaseUser. Téměř vždy se přihlašovací jméno a uživatel v databázi shodují se jménem, ​​ale musíte mít na paměti, že se mohou lišit, mít různá jména.

SQL Server podporuje 2 režimy autentizace:

• Ověření systému Windows (Windows Authentication) - autentizace se provádí pomocí zabezpečení Windows. Uživatelé, kteří jsou již ověřeni v systému Windows a mají práva k serveru SQL, nemusí poskytovat další přihlašovací údaje.
• Smíšené ověřování (Ověření smíšeného režimu) - v tomto režimu je kromě autentizace Windows podporována autentizace samotného serveru SQL pomocí přihlašovacího jména a hesla.

Společnost Microsoft doporučuje používat ověřování systému Windows, pokud je to možné. Pro autentizaci pomocí přihlašovacího jména a hesla jsou data (přihlašovací jméno a heslo) přenášena sítí, i když v šifrované podobě. Při ověřování systému Windows se přenáší řada šifrovaných zpráv přes síť, do které není zahrnuto uživatelské heslo..

Některé aplikace, zejména starší, nepodporují ověřování systému Windows, takže při nastavování režimu ověřování se vyplatí zvážit, které aplikace se k serveru připojí..

SQL Server podporuje tři typy Přihlašovací jméno (přihlašovací jména):

• Místní účet Uživatel nebo účet Windows doména/ důvěryhodná doména.
• Skupina Windows. Udělení přístupu k místní skupině Windows nebo ke skupině z domény AD. Umožňuje vám poskytnout přístup všem uživatelům, kteří jsou členy skupiny.
• Přihlášení k serveru SQL (Ověřování serveru SQL). SQL Server ukládá hash uživatelské jméno a heslo do databáze pán, pomocí interních autentizačních metod k ověření přihlášení.

SQL Server se automaticky integruje do služby Active Directory. Pokud chcete distribuovat práva doménového účtu, musíte použít název domény NetBios a přihlašovací údaje k účtu. Například pro uživatelské jméno uživatele v doméně.local bude „doména \ uživatelské jméno“.

Autorizace na serveru SQL

Pro autorizaci SQL Server používá zabezpečení založené na rolích, které vám umožňuje přiřazovat oprávnění k roli nebo skupině / doméně systému Windows, nikoli k jednotlivým uživatelům. SQL Server má vestavěné role serveru a databáze, které mají předdefinovanou sadu oprávnění.

Na serveru SQL Server jsou tři úrovně zabezpečení, které lze reprezentovat jako hierarchii od nejvyšší po nejnižší:

• Úroveň serveru - na této úrovni můžete distribuovat práva do databází, účtů, rolí serverů a skupin dostupnosti;
• Úroveň databáze zahrnují schémata, uživatele databáze, databázové role a fulltextové katalogy;
• Obvodová úroveň zahrnují objekty, jako jsou tabulky, pohledy, funkce a uložené procedury.

Vestavěné role serveru

Schéma role serveru SQL:

V praxi není použití rolí serveru nijak zvlášť běžné, protože uživatel často potřebuje jedinečnou sadu oprávnění. Výjimkou může být role sysadmin pro správce systému a veřejná role.

Vestavěné databázové role

Za zmínku také stojí zvláštní zvýraznění zvláštních rolí v databázi msdb.

Schéma pro vestavěné databázové role na serveru SQL:

Aplikační role

Role aplikace je databázový objekt (stejný jako normální databázová role), který umožňuje autentizaci pomocí hesla změnit kontext zabezpečení v databázi. Na rozdíl od databázových rolí jsou aplikační role ve výchozím nastavení neaktivní a aktivují se, když aplikace spustí sp_setapprole a zadá příslušné heslo..

Na rozdíl od běžných rolí se aplikační role téměř nikdy nepoužívají. Jejich výjimku lze výjimečně nalézt ve vícevrstvých aplikacích..

Filtrování dat na serveru SQL

Filtrování dat v SQL Serveru pomocí uložených procedur / pohledů / funkcí lze připsat implementaci principu nejmenších oprávnění, protože neposkytujete přístup ke všem datům v tabulce, ale pouze k některým z nich.

Například můžete uživateli udělit z pohledu pouze práva SELECT a zabránit přímému přístupu k tabulkám používaným v pohledu. Poskytnete tak přístup k pouze části dat z tabulky nastavením filtru where v pohledu.

Filtrování dat pomocí zabezpečení na úrovni řádků

Zabezpečení na úrovni řádku nebo Zabezpečení na úrovni řádku (RLS) umožňuje filtrovat data tabulky pro různé uživatele pomocí vlastního filtru. To se provádí pomocí BEZPEČNOSTNÍ POLITIKY v T-SQL

V tomto snímku je zásada nakonfigurována tak, že uživatel Sales1 uvidí řádky tabulky, ve které je hodnota sloupce Prodej uživatelské jméno (Sales1), a uživatel Správce uvidí všechny řádky.

Schémata v SQL Serveru

Některé objekty serveru SQL (tabulky, procedury, zobrazení, funkce) mají schéma. Schéma lze považovat za kontejnery pro různé objekty (nebo jmenný prostor, pokud jste obeznámeni s programováním).

Například, pokud má uživatel práva vybírat ze schématu, může si také vybrat ze všech objektů tohoto schématu. To znamená, že objekty, které patří do schématu, zdědí svá oprávnění. Když uživatelé vytvářejí objekty v diagramu, objekty patří vlastníkovi diagramu, nikoli uživateli. Oprávnění uživatelé nezdědí od schématu. I.e. uživatelé s výchozím schématem dbo nemají oprávnění udělená tomuto schématu - musí být explicitně zadána.

Hlavní rozdíl mezi schématy a rolemi spočívá v tom, že rolím lze udělit oprávnění k schématu. Například role testrole může mít výběrová oprávnění ze schématu1 a oprávnění k výběru / aktualizaci na schématu2. Objekt může patřit pouze do jednoho schématu, ale k němu může mít práva více rolí.

Vložené obvody

SQL Server má zabudovaná systémová schémata:

• dbo
• host
• sys
• INFORMATION_SCHEMA

Schéma dbo je výchozí schéma pro nové databáze a uživatel dbo je vlastníkem schématu dbo. Ve výchozím nastavení mají noví uživatelé v databázi jako výchozí schéma schéma dbo. Pro vestavěné systémové objekty SQL Server jsou potřeba další vestavěná schémata..

Šifrování dat pomocí serveru SQL

SQL Server může šifrovat data, procedury a připojení k serveru. Šifrování je možné pomocí certifikátu, asymetrického nebo symetrického klíče. SQL Server používá hierarchický šifrovací model, to znamená, že každá vrstva hierarchie šifruje vrstvu pod ní. Jsou podporovány všechny známé a populární šifrovací algoritmy. K implementaci šifrovacích algoritmů se používá rozhraní Windows Crypto API..

Nejběžnější typy šifrování jsou TDE (Transparent Data Encryption) a Always Encrypted.

Transparentní šifrování dat

Transparentní šifrování dat nebo Transparentní šifrování dat šifruje celou databázi. Pokud dojde k odcizení fyzického média nebo souboru .mdf / .ldf, útočník nebude mít přístup k informacím v databázi.

Graf, který představuje celý proces

Základní šifrování databáze pomocí T-SQL:

USE master;
GO
VYTVOŘTE HLAVNÍ KLÍČOVOU ENCRYPTUU HESLO = 'heslo';
jdi
VYTVOŘTE CERTIFIKÁT ServerCert S SUBJECT = 'DEK certifikát';
jdi
USE AdventureWorks2012;
GO
VYTVOŘIT DATABÁZOVOU KLÁVESNICI
S ALGORITHM = AES_128
ENCRYPTION CERTIFICATE SERVER ServerCert;
GO
ALTER DATABASE AdventureWorks2012
SET ENCRYPTION ON;
GO

Vždy šifrováno

Tato technologie umožňuje ukládat šifrovaná data na SQL Server bez přenosu šifrovacích klíčů na samotný SQL Server. Vždy šifrováno, například TDE, šifruje data v databázi, ale ne na úrovni databáze, ale na úrovni sloupců.

Pro šifrování používá vždy šifrovaná 2 klíče:

• Klíč pro šifrování sloupců (CEK)
• Hlavní klíč sloupce (CMK)

Všechny procesy šifrování a dešifrování dat probíhají na klientovi, v databázi je uložena pouze šifrovaná hodnota šifrovacího klíče (CEK).

Always Encrypted také umožňuje omezit přístup k datům i pro DBA, což vám dává možnost nebát se, že správce získá přístup k datům, která by neměla být.

Kdy použít SQL Server Encryption?

Šifrování dat je jedním z důležitých bezpečnostních opatření, ale šifrování může být náročné na prostředky serveru a někdy může být zbytečné..

Pokud uživatelé přistupují k datům prostřednictvím veřejné sítě, může být vyžadováno šifrování, aby byla zajištěna bezpečnost, ale pokud jsou data přenášena přes zabezpečený intranet nebo VPN, není třeba data šifrovat. Rovněž stojí za zvážení možnosti šifrování dat, pokud hrozí krádež fyzických médií s databázemi.

Implementace šifrování by měla být dobře naplánována: musíte vzít v úvahu další zatížení serveru, zda aplikace, které pracují se serverem, mohou implementovat podporu pro tento typ šifrování na jejich straně a mnoho dalších nuancí.

Používání skupin spravovaných účtů služeb pro SQL Server

Skupinové účty spravovaných služeb nebo gMSA - Toto je speciální účet, který je automaticky spravován službou Active Directory. gMSA je vývoj technologie MSA, protože MSA nebylo možné použít v klastrových scénářích.

gMSA eliminuje potřebu ručně změnit hesla pro účet. Při nastavování gMSA uvedete, na kterých serverech bude účet gMSA spuštěn, jak často služba Active Directory změní heslo a kdo má právo toto heslo zobrazit. Na serverech, na kterých bude gMSA nainstalována, nemusíte při určování odpovídajícího účtu gMSA zadávat heslo..

Mějte na paměti, že verze systému Windows Server pro práci s gMSA musí být alespoň 2012.

Posouzení zranitelnosti serveru SQL pomocí SSMS

SQL Server Management Studio má funkci vyhodnocení zranitelnosti pro databázi..

Vyberte databázi -> Úkoly -> Posouzení zranitelnosti -> Vyhledejte chyby zabezpečení.

Skener vyhodnotí databázi z hlediska populárních chyb v konfiguraci zabezpečení a poskytne příslušná doporučení..

S tímto skenerem byste určitě měli projít tento databázový skener. Může odhalit skryté problémy, které nejsou na první pohled vidět..

Auditorská činnost na serveru SQL

SQL Server poskytuje možnost auditu jakékoli uživatelské aktivity v instanci serveru.

Jedná se o velmi výkonný nástroj, který vám umožní plně řídit akce vašich uživatelů / vývojářů..

Zvažte základní nastavení auditu:

V SSMS vytvořte na kartě Zabezpečení -> Audity nový audit.

Poté, pro auditování, musíte vytvořit specifikaci auditu označující události, které budou monitorovány.

Po vytvoření a aktivaci auditu můžete v protokolu auditu zobrazit události zaznamenané postupem auditu..

Doporučené postupy pro obecné zabezpečení serveru SQL

Vždy dodržujte zásadu nejmenších privilegií. Včetně konfigurace účtu služby SQL Server pomocí gMSA. Nikdy nepoužívejte účet domény s oprávněními správce domény..

Zásada nejméně privilegovaných

Při vytváření nových uživatelů se doporučuje použít princip LUA (Nejméně privilegovaný uživatelský účet nebo Účet nejmenších práv) Tento princip je důležitou součástí zabezpečení serveru a dat..

Pro uživatele s právy správce se doporučuje vydávat oprávnění pouze pro ty operace, které budou potřebovat. Role integrovaného serveru by se měly používat pouze v případě, že jejich sada oprávnění odpovídá úkolům uživatele..

Udělení rolí, ne uživatelů

Pokud existuje mnoho uživatelů, stává se správa jejich oprávnění obtížnější a také obtížnější zabránit chybám při udělování práv.

Doporučuje se udělit oprávnění rolím a přidat uživatele do rolí. Tímto způsobem dosáhnete větší transparentnosti, protože všichni uživatelé určité role budou mít stejná práva. Přidání nebo odebrání uživatelů z role je snazší než opětovné vytvoření jednotlivých sad oprávnění pro jednotlivé uživatele. Role mohou být vnořeny, ale to se nedoporučuje z důvodu menší průhlednosti a možného snížení výkonu (pokud je příliš mnoho vnořených rolí).

Můžete udělit uživatelská práva pro schéma. V tomto případě budou uživatelé moci okamžitě pracovat s nově vytvořenými objekty v tomto schématu, na rozdíl od rolí, při vytváření nového objektu budou muset role získat práva k němu.