Ebben a cikkben az SQL Server biztonsági eszközeit és a DBMS beállításának és biztonságának bevált gyakorlatait vizsgáljuk meg..
Tartalom:
- Hitelesítés az SQL Server alkalmazásban
- Engedélyezés az SQL Server alkalmazásban
- Alkalmazási szerepek
- Adatszűrés az SQL Serverben
- Sémák az SQL Server-ben
- Adatok titkosítása SQL Server használatával
- Csoport által kezelt szolgáltatási fiókok használata az SQL Server számára
- SQL Server biztonsági rés értékelése SSMS-en keresztül
- Ellenőrzési tevékenység az SQL Serverben
- SQL Server általános biztonsági bevált gyakorlatok
Először emlékezzünk az SQL Server alapvető biztonsági koncepcióira. Az MSSQL az objektumokhoz való hozzáférést vezérli hitelesítés és meghatalmazás.
- hitelesítés - Ez az az eljárás, amikor bejelentkeznek az SQL Serverbe, amikor a felhasználó elküldi az adatait a szervernek. A hitelesítés azonosítja a hitelesített felhasználót;
- meghatalmazás - ez a folyamat annak meghatározására, hogy mely védett objektumokhoz férhet hozzá a felhasználó, és milyen műveletek engedélyezettek ezeknek az erőforrásoknak.
Számos SQL Server objektumnak megvannak a saját engedélyei, amelyeket a szülő objektumtól örökölhetnek. Az engedélyek megadhatók egyéni felhasználónak, csoportnak vagy szerepkörnek.
Hitelesítés az SQL Server alkalmazásban
Az SQL Server fiók két részre osztható: Bejelentkezés név és használó.
- Bejelentkezés név - Ez az SQL Server teljes példányának globális bejelentkezése. Ezzel átmész a hitelesítési folyamaton;
- használó - ez egy adatbázis tag, amely egy adott bejelentkezési névhez van társítva.
Lehet, hogy például a szerver bejelentkezik domain \ felhasználónév, és a bejelentkezéssel társított adatbázis felhasználói felhívhatók domain_databaseUser. Szinte mindig az adatbázisban a bejelentkezési név és a felhasználó névben egybeesik, de ne feledje, hogy különbözhetnek egymástól, különféle névvel rendelkeznek.
Az SQL Server 2 módot támogat hitelesítés:
- Windows hitelesítés (Windows hitelesítés) - a hitelesítés a Windows biztonságával történik. Azoknak a felhasználóknak, akik már hitelesítették a Windows rendszert és rendelkeznek az SQL Server jogosultságával, nem kell további hitelesítő adatokat megadniuk.
- Vegyes hitelesítés (Vegyes módú hitelesítés) - ebben a módban a Windows-hitelesítésen túl az SQL Server hitelesítése bejelentkezés és jelszó segítségével is támogatott..
A Microsoft javasolja a Windows hitelesítés használatát, ha lehetséges. A bejelentkezés és a jelszó révén történő hitelesítéshez az adatokat (bejelentkezési név és jelszó) a hálózaton továbbítják, bár titkosított formában. A Windows-hitelesítés során a titkosított üzenetek egy sorát továbbítják a hálózaton, amelyben a felhasználói jelszó nincs megadva..
De néhány alkalmazás, különösen a régebbi alkalmazások, nem támogatja a Windows hitelesítést, tehát a hitelesítési mód beállításakor érdemes megfontolni, hogy mely alkalmazások kapcsolódnak a szerverhez.
Az SQL Server háromféle támogatást nyújt Bejelentkezés név (bejelentkezési nevek):
- Helyi számla Windows felhasználó vagy fiók domain/ megbízható domain.
- Windows csoport. Hozzáférés biztosítása helyi Windows csoporthoz vagy egy csoporthoz egy AD tartományból. Lehetővé teszi a hozzáférést a csoport minden tagjának.
- SQL Server Bejelentkezés (SQL Server hitelesítés). Az SQL Server az adatbázisban tárolja a felhasználónév és jelszó kivonatát gazda, belső hitelesítési módszerek használata a bejelentkezés ellenőrzéséhez.
Az SQL Server automatikusan integrálódik az Active Directory-hoz. Ha terjeszteni szeretne egy domain fiók jogait, akkor a NetBios domain nevet és a fiók bejelentkezését kell használnia. Például a domain.local felhasználói felhasználóneve esetén „domain \ felhasználónév” lesz.
Engedélyezés az SQL Server alkalmazásban
Az engedélyezéshez az SQL Server szerepkör-alapú biztonságot használ, amely lehetővé teszi, hogy engedélyeket Windows-szerepkörhez vagy csoporthoz / tartományhoz rendeljen, nem pedig egyes felhasználókhoz. Az SQL Server beépített szerver- és adatbázis-szerepeket tartalmaz, amelyek előre meghatározott engedélyekkel rendelkeznek.
Az SQL Server 3 szintű biztonságot nyújt, és a legmagasabbtól a legalacsonyabbig terjedő hierarchiaként ábrázolható:
- Szerver szint - ezen a szinten eloszthat jogokat adatbázisokhoz, fiókokhoz, kiszolgálói szerepekhez és elérhetőségi csoportokhoz;
- Adatbázis szint tartalmaznak sémákat, adatbázis-felhasználókat, adatbázis-szerepeket és teljes szöveges katalógusokat;
- Áramkör szintje objektumokat, például táblázatokat, nézeteket, funkciókat és tárolt eljárásokat tartalmazhat.
Beépített szerver szerepek
| szerep | leírás |
| rendszergazda | A szerepkör teljes jogával rendelkezik az összes SQL Server erőforráshoz. |
| ServerAdmin | A szereptagok megváltoztathatják a szerver szintű konfigurációs beállításait és leállíthatják a szervert. |
| securityadmin | A szerepben résztvevők kezelik a bejelentkezéseket és tulajdonságaikat. A GRANT, DENY és REVOKE hozzáférési jogokat adhatnak kiszolgáló és adatbázis szintjén, ha hozzáféréssel rendelkeznek. A securityadmin nem különbözik nagyban a sysadmin szerepétől, mivel ennek a szerepnek a tagjai potenciálisan hozzáférhetnek az összes SQL Server erőforráshoz. |
| processadmin | A szerepkör résztvevői leállíthatják az SQL Server futó folyamatokat. |
| setupadmin | A szerepkör tagjai hozzákapcsolhatnak és eltávolíthatnak összekapcsolt kiszolgálókat a TSQL használatával. |
| bulkadmin | A szereptagok futtathatják a BULK INSERT műveleteket. |
| diskadmin | A szereptagok a biztonsági mentési eszközöket kezelhetik. A gyakorlatban ezt a szerepet gyakorlatilag nem alkalmazzák.. |
| dbcreator | A szerepkör tagjai adatbázisokat hozhatnak létre, módosíthatnak, törölhetnek és visszaállíthatnak. |
| nyilvános | Minden SQL Server bejelentkezés ebben a szerepben van. A nyilvános tagság nem változtatható meg. Ha a felhasználónak nincs engedélye annak az objektumnak, amelyhez hozzáfér, akkor a felhasználó örököli az objektum nyilvános szerepkör-engedélyét. |
SQL Server szerepkör-séma:
A gyakorlatban a kiszolgálói szerepkörök használata nem különösebben gyakori, mivel a felhasználónak gyakran egyedi engedélyekre van szüksége. Kivételt képezhet a rendszergazdák sysadmin szerepe és a nyilvános szerep.
Beépített adatbázis-szerepek
| szerep | leírás |
| db_owner | A szerepkör résztvevői az adatbázis konfigurálásának és karbantartásának minden lépését megtehetik, beleértve a törlést is. |
| db_securityadmin | A szereptagok megváltoztathatják más szerepek tagságát. A csoport tagjai potenciálisan megnövelhetik a db_ownerhez fűződő jogaikat, tehát ezt a szerepet egyenértékűnek kell tekinteni a db_ownerrel.. |
| db_accessadmin | A szerepkörtagok vezérelhetik a kiszolgálón létező bejelentkezések adatbázis-hozzáférését. |
| db_backupoperator | A szerepkör tagjai biztonsági másolatot készíthetnek az adatbázisról. |
| db_ddladmin | A szereptagok az adatbázis bármely DDL parancsát végrehajthatják. |
| db_datawriter | A szereptagok létrehozhatnak / módosíthatnak / törölhetnek adatokat az adatbázis összes felhasználói táblájában. |
| db_datareader | A szerepkör tagjai az összes felhasználói táblából olvashatnak adatokat. |
| db_denydatawriter | |
| db_denydatareader | A szereptagok megtagadták a hozzáférést a felhasználói adatbázis táblákhoz. |
Külön érdemes kiemelni a különleges szerepeket az msdb adatbázisban.
| db_ssisadmin db_ssisoperator db_ssisltduser | E szerepek tagjai felügyelhetik és használhatják az SSIS-t (SQL Server Integration Services). |
| dc_admin dc_operator dc_proxy | E szerepek tagjai felügyelhetik és használhatják az adatgyűjtőt.. |
| PolicyAdministratorRole | Ennek a szerepnek a tagjai teljes hozzáféréssel rendelkeznek az SQL Server házirendekhez. |
| ServerGroupAdministratorRole ServerGroupReaderRole | Ezeknek a szerepeknek a tagjai teljes hozzáféréssel rendelkeznek a regisztrált szervercsoportokhoz.. |
| SQLAgentUserRole SQLAgentReaderRole SQLAgentOperatorRole | Ezeknek a szerepeknek a tagjai teljes hozzáféréssel rendelkeznek az SQL Server Agent jobokhoz. |
Az SQL Server beépített adatbázis-szerepköreinek sémája:
Alkalmazási szerepek
Az alkalmazás szerep egy adatbázis objektum (ugyanúgy, mint a normál adatbázis szerep), amely lehetővé teszi a jelszó-hitelesítést, hogy megváltoztassa az adatbázis biztonsági környezetét. Az adatbázis-szerepektől eltérően, az alkalmazás szerepkörök alapértelmezés szerint inaktívak, és akkor aktiválódnak, amikor az alkalmazás végrehajtja az sp_setapprole fájlt és megadja a megfelelő jelszót.
A szokásos szerepektől eltérően az alkalmazási szerepeket szinte soha nem használják. Kivételként alkalmazásuk megtalálható többrétegű alkalmazásokban..
Adatszűrés az SQL Serverben
Az adatok szűrése az SQL Server-ben tárolt eljárások / nézetek / függvények révén a legkevesebb jogosultságok elvének tulajdonítható, mivel nem a táblázat összes adatához, hanem csak ezek némelyikéhez biztosít hozzáférést.
Például megadhatja a felhasználónak csak a SELECT jogokat a nézetből, és megakadályozhatja a nézetben használt táblákhoz való közvetlen hozzáférést. Így a táblázatban szereplő adatoknak csak egy részére férhet hozzá, a nézetben a hol beállító szűrő beállításával.
Adatok szűrése sor szintű biztonsággal
Sor szintű biztonság vagy Sor szintű biztonság (RLS) lehetővé teszi, hogy az egyedi szűrő segítségével kiszűrje a különböző felhasználók táblázatait. Ezt a T-SQL BIZTONSÁGPOLITIKA segítségével hajtják végre
A képernyőképen a házirend úgy van konfigurálva, hogy a Sales1 felhasználó látja a táblázat sorát, amelyben az Értékesítés oszlop értéke a felhasználónév (Sales1), és a Kezelő felhasználó látja az összes sort.
Sémák az SQL Server-ben
Néhány SQL Server objektumnak (táblázatok, eljárások, nézetek, függvények) van egy sémája. A sémák különféle objektumok tárolóiként tekinthetők (vagy névtér, ha ismeri a programozást).
Például, ha a felhasználónak joga van választani egy séma közül, akkor a felhasználó a séma összes objektuma közül is választhat. Vagyis a sémához tartozó objektumok öröklik annak engedélyeit. Amikor a felhasználók objektumokat hoznak létre egy diagramban, az objektumok a diagram tulajdonosához, nem pedig a felhasználóhoz tartoznak. A felhasználó nem örököli az engedélyeket a rendszerből. Ie Az alapértelmezett dbo sémával rendelkező felhasználók nem rendelkeznek engedéllyel a rendszerhez - ezeket kifejezetten meg kell határozni.
A sémák és a szerepek közötti fő különbség az, hogy a sémákhoz való engedélyek megadhatók a szerepekhez. Például, a testrole szerepének lehetnek választási jogosultságai a séma1-ből és a séma2 választási / frissítési engedélyei. Az objektumok csak egy sémahoz tartozhatnak, de több szerephez is jogosultak lehetnek.
Beágyazott áramkörök
Az SQL Server beépített rendszersémákat tartalmaz:
- dbo
- vendég
- sys
- INFORMATION_SCHEMA
A dbo séma az új adatbázisok alapértelmezett sémája, és a dbo felhasználó a dbo séma tulajdonosa. Alapértelmezés szerint az adatbázis új felhasználóinak alapértelmezett sémája van egy dbo séma. Más beépített sémákra van szükség az SQL Server rendszerobjektumokhoz..
Adatok titkosítása SQL Server használatával
Az SQL Server titkosíthat adatokat, eljárásokat és szerverkapcsolatokat. A titkosítás tanúsítvány, aszimmetrikus vagy szimmetrikus kulcs használatával lehetséges. Az SQL Server hierarchikus titkosítási modellt használ, azaz minden hierarchikus réteg titkosítja az alatta lévõ réteget. Minden ismert és népszerű titkosítási algoritmus támogatott. A titkosítási algoritmusok megvalósításához a Windows Crypto API-t használják..
A leggyakoribb titkosítás a TDE (Transparent Data Encryption) és az Mindig titkosított.
Átlátszó adattitkosítás
Átlátszó adattitkosítás vagy Átlátszó adattitkosítás a teljes adatbázist titkosítja. Ha fizikai adathordozót vagy .mdf / .ldf fájlt lopnak, a támadó nem fog hozzáférni az adatbázisban található információkhoz.
Diagram, a teljes folyamat ábrázolására
Alapvető adatbázis-titkosítás a T-SQL segítségével:
USE mester;
GO
LÉTREHOZZA A KEZDŐSZER KULCSOLÁSÁT JELSZÓJAL = 'jelszó';
go
CREATE CERTIFICATE ServerCert TÉMAKÖR = 'DEK tanúsítvány';
go
USE AdventureWorks2012;
GO
AZ ADATBÁZIS TISZTÍTÁS GOMBJA
ALGORITHM = AES_128
TISZTÍTÁS SZERZŐI BIZONYÍTVÁNYOKkal ServerCert;
GO
VÁLTOZÓ ADATBÁZIS AdventureWorks2012
BE TITKÍTÉS BE;
GO
Mindig titkosítva
Ez a technológia lehetővé teszi, hogy titkosított adatokat tároljon az SQL Server-ben anélkül, hogy a titkosítási kulcsokat maga az SQL Server átadná. Mindig titkosítva, mint például a TDE, az adatbázisban tárolja az adatokat, de nem az adatbázis, hanem az oszlop szintjén.
A titkosításhoz az Mindig titkosítva 2 kulcsot használ:
- Oszlop titkosítási kulcs (CEK)
- Oszlop főkulcs (CMK)
Minden adat titkosítási és visszafejtési folyamat az ügyfélen zajlik, csak a titkosítási kulcs (CEK) titkosított értéke tárolódik az adatbázisban.
A Mindig titkosítva lehetővé teszi az adatokhoz való hozzáférés korlátozását még a DBA-k esetében is, ezáltal lehetőséget adva arra, hogy ne aggódjon, hogy a rendszergazda hozzáfér olyan adatokhoz, amelyeket nem.
Mikor kell használni az SQL Server titkosítást?
Az adatok titkosítása az egyik fontos biztonsági intézkedés, de a titkosítás a kiszolgáló erőforrásainak igényes lehet, és néha felesleges lehet..
Ha a felhasználók nyilvános hálózaton keresztül férnek hozzá az adatokhoz, akkor a biztonság érdekében titkosításra lehet szükség, de ha az adatokat biztonságos intraneten vagy VPN-en továbbítják, nincs szükség az adatok titkosítására. Érdemes megfontolni az adatok titkosításának lehetőségét is, ha fennáll a veszélye, hogy az adatbázisokkal való fizikai adathordozókat ellopják.
A titkosítás végrehajtását jól meg kell tervezni: figyelembe kell venni a kiszolgáló többletterhelését, hogy a kiszolgálóval működő alkalmazások képes-e az oldalukon támogatni az ilyen típusú titkosítást és sok más árnyalattal.
Csoport által kezelt szolgáltatási fiókok használata az SQL Server számára
Csoport által kezelt szolgáltatási fiókok vagy gMSA - Ez egy speciális fiók, amelyet az Active Directory automatikusan kezel. A gMSA az MSA technológia fejlődése, mivel az MSA-t nem lehetett használni klaszterhelyzetekben.
A gMSA kiküszöböli a fiókok jelszavainak manuális megváltoztatásának szükségességét. A gMSA konfigurálásakor meg kell jelölnie, hogy mely szerverek futtatják a gMSA fiókot, hogy az Active Directory milyen gyakran fogja megváltoztatni a jelszót, és ki jogosult a jelszó megtekintésére. Azon kiszolgálón, amelyre a gMSA telepítésre kerül, nem kell megadnia a jelszót a megfelelő gMSA-fiók megadásakor.
Ne feledje, hogy a gMSA-val való együttműködéshez a Windows Servernek legalább 2012-es verziójának kell lennie.
SQL Server biztonsági rés értékelése SSMS-en keresztül
Az SQL Server Management Studio rendelkezik az adatbázis biztonsági résének felmérésével..
Válasszon adatbázist -> feladatok -> Sebezhetőség értékelése -> Vizsgálja meg a biztonsági réseket.
A szkenner értékeli az adatbázist a biztonsági konfiguráció népszerű hibáiban, és megfelelő ajánlásokat ad..
A szkennerrel feltétlenül menjen át ezen az adatbázis-szkenneren. Felfedheti a rejtett problémákat, amelyek az első pillantásra nem láthatók..
Ellenőrzési tevékenység az SQL Serverben
Az SQL Server lehetővé teszi a felhasználói tevékenységek ellenőrzését egy kiszolgálópéldányon.
Ez egy nagyon hatékony eszköz, amely lehetővé teszi a felhasználók / fejlesztők műveleteinek teljes körű ellenőrzését..
Fontolja meg az alapvető ellenőrzési beállításokat:
Az SSMS-ben a Biztonság -> Ellenőrzések lapon hozzon létre egy új ellenőrzést.
Ezután az ellenőrzéshez létre kell hoznia egy ellenőrzési specifikációt, amely jelzi az ellenőrzendő eseményeket.
Az ellenőrzés létrehozása és aktiválása után az ellenőrzési naplóban láthatja az ellenőrzési eljárás által rögzített eseményeket..
SQL Server általános biztonsági bevált gyakorlatok
Mindig kövesse a legkevesebb kiváltság elvét. Beleértve az SQL Server szolgáltatásfiók konfigurálását a gMSA használatával. Soha ne használjon tartományfiókot tartománygazda-jogosultságokkal..
A legkevesebb kiváltság elve
Új felhasználók létrehozásakor az LUA elv (Legkevésbé privilegizált felhasználói fiók vagy Legkevesebb jogok számla). Ez az elv a szerver és az adatbiztonság fontos része..
Rendszergazdai jogokkal rendelkező felhasználók számára ajánlott csak azoknak a műveleteknek a kiadása, amelyekre szükségük lesz. A beágyazott szerver szerepeket csak akkor szabad használni, ha engedélyük meghaladja a felhasználó feladatait..
Szerepkörök megadása, nem a felhasználók számára
Ha sok felhasználó van, az engedélyek kezelése nehezebbé válik, valamint a jogok megadása során elkövetett hibák megelőzése is nehezebbé válik.
Ajánlott engedélyt adni a szerepeknek, és felvenni a felhasználókat a szerepekbe. Így nagyobb átláthatóságot érhet el, mivel egy adott szerep minden felhasználójának azonos jogok vannak. A felhasználók hozzáadása vagy eltávolítása egy szerepből könnyebb, mint az egyedi engedélykészletek újbóli létrehozása az egyes felhasználók számára. Lehet, hogy a szerepek beágyazódnak, de ez nem ajánlott, mivel kevesebb az átláthatóság és a lehetséges teljesítményromlás (ha túl sok beágyazott szerepkör van).
A rendszerhez felhasználói jogokat adhat. Ebben az esetben a felhasználók azonnal képesek lesznek dolgozni az újonnan létrehozott objektumokkal ebben a sémában, ellentétben a szerepkörökkel, amikor egy új objektumot létrehoznak, a szerepeknek jogokat kell biztosítani arra.
