Olvasás angol nyelven

Megosztás a következőn keresztül:

Az SQL Server biztonsági ajánlott eljárásai

  • Cikk

A következőkre vonatkozik:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Ez a cikk az SQL Server biztonságának kialakítását segítő ajánlott eljárásokról és irányelvekről nyújt tájékoztatást. Az SQL Server biztonsági funkcióinak átfogó áttekintéséhez tekintse meg az SQL Serverbiztonságossá tételét ismertető cikket.

A termékbiztonságra vonatkozó ajánlott eljárásokért tekintse meg Azure SQL Database és felügyelt SQL-példány és AZURE-beli virtuális gépeken futó SQL Server.

Áttekintés

A rétegzett biztonsági módszertan részletes védelmi megoldást nyújt több, különböző biztonsági hatókörökre irányuló biztonsági képesség használatával. Az SQL Server 2016-ban elérhetővé tett és a későbbi kiadásokban továbbfejlesztett biztonsági funkciók segítenek a biztonsági fenyegetések elhárításában és a biztonságos adatbázis-alkalmazások biztosításában.

Az Azure számos iparági előírásnak és szabványnak megfelel, amelyek lehetővé teszik, hogy megfelelő megoldást hozzon létre a virtuális gépen futó SQL Serverrel. Az Azure jogszabályi megfelelőségével kapcsolatban további információt az Azure Megbízhatósági Központwebhelyén talál.

Oszlopszintű védelem

A szervezeteknek gyakran oszlopszinten kell védenie az adatokat, mivel az ügyfelekre, alkalmazottakra, üzleti titkokra, termékadatokra, egészségügyi, pénzügyi és egyéb bizalmas adatokra vonatkozó adatokat gyakran SQL Server-adatbázisokban tárolják. A bizalmas oszlopok gyakran magukban foglalják az azonosítási/társadalombiztosítási számokat, a mobiltelefonszámokat, az utónevet, a családnevet, a pénzügyi számlaazonosítást és minden egyéb, személyes adatnak tekinthető adatot.

Az ebben a szakaszban említett módszerek és funkciók minimális többletterheléssel emelik a védelem szintjét az oszlop szintjén, és nem igényelnek átfogó módosításokat az alkalmazáskódban.

Az Always Encrypted használatával titkosíthatja az inaktív és a vezetéken lévő adatokat. A titkosított adatokat az ügyfélkódtárak csak az alkalmazás ügyfélszintjén fejtik vissza. Lehetőleg randomizált titkosítást használjon a determinisztikus helyett. Always Encrypted biztonságos enklávékkal javíthatja az összehasonlítási műveletek teljesítményét, például BETWEEN, IN, LIKE, DISTINCT, Joins és további véletlenszerű titkosítási forgatókönyvekhez.

A Dinamikus adatmaszkolás (DDM) használatával elrejtheti az adatokat az oszlop szintjén, ha az Always Encrypted nem érhető el. A dinamikus adatmaszkolás (DDM) nem kompatibilis a Mindig titkosítvafunkcióval. Az Always Encrypted használata dinamikus adatmaszkolással, amikor csak lehetséges.

A GRANT engedélyek is oszlopszinten táblázat, nézet vagy tábla értékű függvény számára. Vegye figyelembe a következőket: – Az oszlopon csak SELECT, REFERENCESés UPDATE jogosultság adható meg. - A táblaszintű DENY nem élvez elsőbbséget az oszlopszintű GRANTfelett.

Sorszintű védelem

Row-Level Security (RLS) lehetővé teszi a felhasználói végrehajtási környezet használatát az adatbázistábla soraihoz való hozzáférés szabályozásához. Az RLS biztosítja, hogy a felhasználók csak a hozzájuk tartozó rekordot lássák. Ez "rekordszintű" biztonságot nyújt az alkalmazás számára anélkül, hogy jelentős módosításokat kellene végrehajtania az alkalmazáson.

Az üzleti logika táblás értékű függvényekben van kapszulázva, amelyeket egy biztonsági szabályzat irányít, ami be- és kikapcsolja az RLS funkcionalitást. A biztonsági szabályzat az RLS táblákhoz kötött FILTER és BLOCK predikátumokat is szabályozza. A Row-Level Security (RLS) használatával korlátozhatja a hívást kezdeményező felhasználónak visszaadott rekordokat. Használja a SESSION_CONTEXT (T-SQL)-t azoknak a felhasználóknak, akik egy köztes rétegbeli alkalmazáson keresztül csatlakoznak az adatbázishoz, és ahol az alkalmazás felhasználói ugyanazt az SQL Server felhasználói fiókot használják. Az optimális teljesítmény és kezelhetőség érdekében kövesse a Row-Level biztonsági ajánlott eljárásokat.

Tipp

Az Row-Level Security (RLS) és az Always Encrypted vagy a Dynamic Data Masking (DDM) együttes használatával maximalizálhatja a szervezet biztonsági állapotát.

Fájltitkosítás

transzparens adattitkosítás (TDE) védi az adatokat a fájlszinten azáltal, hogy inaktív titkosítást biztosít az adatbázisfájlok számára. A transzparens adattitkosítás (TDE) biztosítja, hogy az adatbázisfájlok, biztonsági mentési fájlok és tempdb fájlok nem csatolhatók és olvashatók az adatbázisfájlok visszafejtéséhez szükséges megfelelő tanúsítványok nélkül. Transzparens adattitkosítás (TDE) nélkül a támadók használhatják a fizikai adathordozót (meghajtókat vagy biztonsági mentési szalagokat), és visszaállítják vagy csatolják az adatbázist a tartalom olvasásához. A transzparens adattitkosítás (TDE) támogatott az SQL Server összes többi biztonsági funkciójával való együttműködéshez. A transzparens adattitkosítás (TDE) valós idejű I/O-titkosítást és visszafejtést biztosít az adatok és naplófájlok számára. A TDE-titkosítás egy adatbázis-titkosítási kulcsot (DEK) használ a felhasználói adatbázisban. Az adatbázis-titkosítási kulcs tanúsítványsal is védhető, amelyet a master adatbázis főkulcsa véd.

A TDE használatával megvédheti az inaktív adatokat, a biztonsági mentéseket és a tempdb.

Naplózás és jelentéskészítés

Az SQL Server naplózásánakhozzon létre egy naplózási szabályzatot a kiszolgáló vagy az adatbázis szintjén. A kiszolgálószabályzatok a kiszolgálón lévő összes meglévő és újonnan létrehozott adatbázisra érvényesek. Az egyszerűség kedvéért engedélyezze a kiszolgálószintű naplózást, és engedélyezze, hogy az adatbázisszintű naplózás örökölje az összes adatbázis kiszolgálószintű tulajdonságát.

táblák és oszlopok ellenőrzése azokkal a bizalmas adatokkal, amelyekre biztonsági intézkedéseket alkalmaztak. Ha egy tábla vagy oszlop elég fontos ahhoz, hogy biztonsági képességekkel kell védeni, akkor a naplózáshoz elég fontosnak kell tekinteni. Különösen fontos a bizalmas információkat tartalmazó táblák naplózása és rendszeres áttekintése, de ha valamilyen alkalmazás vagy architektúrakorlátozás miatt nem lehet alkalmazni a kívánt biztonsági intézkedéseket.

Identitások és hitelesítés

Az SQL Server két hitelesítési módot támogat, a Windows hitelesítési módot és az "SQL Server és a Windows hitelesítési módot" (vegyes mód).

A bejelentkezések különállnak az adatbázis-felhasználóktól. Először a bejelentkezéseket vagy a Windows-csoportokat külön képezheti le adatbázis-felhasználókra vagy szerepkörökre. Ezután adjon engedélyeket a felhasználóknak, kiszolgálói szerepköröknekés/vagy adatbázis-szerepköröknek az adatbázis-objektumok eléréséhez.

Az SQL Server a következő típusú bejelentkezéseket támogatja:

  • Helyi Windows-felhasználói fiók vagy Active Directory-tartományi fiók – Az SQL Server a Windowsra támaszkodik a Windows felhasználói fiókok hitelesítéséhez.
  • Windows-csoport – Ha hozzáférést ad egy Windows-csoporthoz, hozzáférést biztosít a csoporthoz tartozó összes Windows-felhasználói bejelentkezéshez. Ha eltávolít egy felhasználót egy csoportból, azzal eltávolítja a csoportból származó jogosultságokat. A csoporttagság az előnyben részesített stratégia.
  • SQL Server-bejelentkezés – Az SQL Server a jelszó felhasználónevét és kivonatát tárolja a master adatbázisban.
  • Az adatbázison belüli felhasználók az SQL Server-kapcsolatokat az adatbázis szintjén hitelesítik. A tartalmazott adatbázisok olyan adatbázisok, amelyek el vannak különítve más adatbázisoktól és az adatbázist üzemeltető SQL Server -példánytól (és a master adatbázistól). Az SQL Server Windows-os és SQL Server-hitelesítéshez is támogatja a korlátozott adatbázis-felhasználókat.

Az alábbi javaslatok és ajánlott eljárások segítenek az identitások és hitelesítési módszerek biztonságossá tételében:

  • A biztonságkezelés javítása érdekében minimális jogosultságú szerepköralapú biztonsági stratégiákat használhat.

    • Az Active Directory-felhasználókat az AD-csoportokba kell helyezni, az AD-csoportoknak SQL Server-szerepkörökben kell lenniük, és az SQL Server-szerepköröknek meg kell adni az alkalmazás által megkövetelt minimális engedélyeket.

  • Az Azure-ban a minimális jogosultságú biztonság használata szerepköralapú hozzáférési (RBAC) vezérlőkkel

  • Amikor csak lehetséges, válassza az Active Directoryt az SQL Server-hitelesítésen keresztül, és különösen válassza az Active Directoryt a biztonság alkalmazás- vagy adatbázisszinten történő tárolása felett.

    • Ha egy felhasználó elhagyja a vállalatot, egyszerűen letilthatja a fiókot.
    • A felhasználókat könnyen eltávolíthatja a csoportokból, ha a felhasználók szerepkört váltanak, vagy kilépnek a szervezetből. A csoportbiztonság ajánlott eljárásnak számít.

  • Használjon többtényezős hitelesítést a gépszintű hozzáféréssel rendelkező fiókokhoz, beleértve az RDP-t használó fiókokat is a gépre való bejelentkezéshez. Ez segít védekezni a hitelesítő adatok ellopása vagy a szivárgások ellen, mivel az egytényezős jelszóalapú hitelesítés a hitelesítő adatokkal való hitelesítés egy gyengébb formája, amelynek fennáll a veszélye, hogy illetéktelenek vagy tévesen adják meg őket.

  • Olyan erős és összetett jelszavakat , amelyek nem könnyen kitalálhatók, és más fiókokhoz vagy célokra nem használhatók. Rendszeresen frissítse a jelszavakat, és kényszerítse ki az Active Directory-szabályzatokat.

  • Group-Managed szolgáltatásfiókok (gMSA) automatikus jelszókezelést, egyszerűsített egyszerű szolgáltatásnév-kezelést (SPN) biztosítanak, és delegálják a felügyeletet más rendszergazdáknak.

    • A gMSA használatával a Windows operációs rendszer a fiók jelszavait kezeli ahelyett, hogy a rendszergazdara támaszkodik a jelszó kezelésére.
    • A gMSA automatikusan frissíti a fiókjelszavakat a szolgáltatások újraindítása nélkül.
    • A gMSA csökkenti az adminisztráció terjedelmét, és javítja a feladatok elkülönítését.

  • Minimalizálja a DBA AD-fiókjának biztosított jogokat; Fontolja meg a virtuális géphez való hozzáférést korlátozó feladatok elkülönítését, az operációs rendszerbe való bejelentkezés lehetőségét, a hibák és naplók módosításának képességét, valamint az alkalmazások és/vagy szolgáltatások telepítésének képességét.

  • Fontolja meg, hogy eltávolítja a DBA-fiókokat a sysadmin szerepkörből, és inkább adjon CONTROL SERVER jogot a DBA-fiókoknak ahelyett, hogy a sysadmin szerepkör tagjai lennének. A rendszergazda szerepkör nem veszi figyelembe DENY, míg a CONTROL SERVER igen.

Adatsorok és adatintegritás

Az adatváltozások előzményeinek időbeli megőrzése hasznos lehet az adatok véletlen változásainak kezeléséhez. Az alkalmazásmódosítások naplózásához is hasznos lehet, és helyreállíthatja az adatelemeket, ha egy rossz szereplő nem engedélyezett adatmódosításokat vezet be.

  • időbeli táblák használatával megőrizheti a rekordverziókat az idő függvényében, és megtekintheti a rekord élettartamán túli adatokat az alkalmazás adatainak előzménynézetéhez.
  • A temporális táblák az aktuális tábla egy verziójának megadására használhatók bármikor.

Biztonsági értékelési eszközök és kiértékelés

Az alábbi konfigurációs és értékelési eszközök a felületi biztonságra, az adatbiztonsági lehetőségek azonosítására és az SQL Server-környezet biztonságának példánnyal történő értékelésére szolgálnak.

  • Terület konfiguráció – Csak azokat a funkciókat engedélyezze, amelyekre a környezetének szüksége van, hogy minimalizálja a rosszindulatú felhasználók által megtámadható funkciók számát.
  • SQL Server (SSMS) sebezhetőségi felmérése – Az SQL sebezhetőségi felmérése az SSMS 17.4+- eszköz, amely segít felderíteni, nyomon követni és orvosolni a lehetséges adatbázis-biztonsági réseket. A biztonságirés-felmérés értékes eszköz az adatbázis biztonságának javításához, és adatbázisonként az adatbázis szintjén történik.
  • SQL Data Discovery and Classification (SSMS) – Az adatbázis-adminisztrátorok gyakran kezelik a kiszolgálókat és az adatbázisokat, és nincsenek tisztában az adatbázisban található adatok érzékenységével. Az adatfelderítési & besorolás lehetővé teszi az adatok bizalmassági szintjének felderítését, besorolását, címkézését és jelentéskészítését. A Data Discovery & besorolása SSMS 17.5-től kezdve támogatott.

Gyakori SQL-fenyegetések

Segít megismerni az SQL Servert veszélyeztető gyakori fenyegetéseket:

  • SQL-injektálás – Az SQL-injektálás olyan támadási forma, amely során rosszindulatú kódot szúrnak be az SQL Server példányához végrehajtás céljából átadott sztringekbe.
    • Az injektálási folyamat egy szöveges sztring megszüntetésével és egy új parancs hozzáfűzésével működik. Mivel a beszúrt parancshoz lehet, hogy végrehajtása előtt további sztringeket fűznek hozzá, a támadó a beszúrt sztringet egy megjegyzésjellel, például --, zárja le.
    • Az SQL Server minden fogadott szintaktikailag érvényes lekérdezést végrehajt.
  • Ne feledje, hogy oldalcsatornás támadások, kártevők & egyéb fenyegetések.

SQL-injektálási kockázatok

Az SQL-injektálás kockázatának minimalizálása érdekében vegye figyelembe a következő elemeket:

  • Tekintse át azokat az SQL-folyamatokat, amelyek sql-utasításokat készítenek az injektálási biztonsági résekhez.
  • Dinamikusan generált SQL-utasítások létrehozása paraméteres módon.
  • A fejlesztőknek és a biztonsági rendszergazdáknak minden olyan kódot át kell tekintenie, amely meghívja EXECUTE, EXECvagy sp_executesql.
  • Tiltsa le a következő bemeneti karaktereket:
    • ;: Lekérdezéselválasztó
    • ': Karakterlánc elválasztó
    • --: Egysoros megjegyzés-elválasztó.
    • /* ... */: Megjegyzéshatárolók.
    • xp_: Katalógus által bővített tárolt eljárások, például xp_cmdshell.
      • Nem ajánlott xp_cmdshell sql serveres környezetben használni. Használja inkább az SQLCLR-t, vagy keressen más alternatívákat a xp_cmdshell által esetleg felmerülő kockázatok miatt.
  • Mindig ellenőrizze, hogy a felhasználói bemenetek és a hibakimenetek megtisztítása a kiömlött és a támadó számára elérhető-e.

Oldalcsatornás kockázatok

Az oldalcsatornás támadások kockázatának minimalizálása érdekében vegye figyelembe a következőket:

  • Győződjön meg arról, hogy a legújabb alkalmazás- és operációsrendszer-javítások vannak alkalmazva.
  • Hibrid számítási feladatok esetén győződjön meg arról, hogy a legújabb belső vezérlőprogram-javítások minden helyszíni hardverre érvényesek.
  • Az Azure-ban a rendkívül érzékeny alkalmazások és munkaterhelések esetében további védelmet nyújthat a mellékcsatornás támadások ellen izolált virtuális gépek, dedikált gazdagépek vagy bizalmi számítási virtuális gépek használatával. Ilyen például a DC-sorozatú és virtuális gépek, amelyek 3. generációs AMD EPYC processzorokat használnak.

Infrastruktúra-fenyegetések

Vegye figyelembe a következő gyakori infrastruktúra-fenyegetéseket:

  • Találgatásos hozzáférés – a támadó több jelszóval próbál hitelesíteni a különböző fiókokban, amíg nem talál megfelelő jelszót.
  • Jelszófeltörés / jelszópermet - a támadók egyetlen gondosan kialakított jelszót próbálnak ki az összes ismert felhasználói fiókhoz (egy jelszó sok fiókhoz). Ha a kezdeti jelszószórás sikertelen, újra próbálkoznak egy másik gondosan kialakított jelszó használatával, általában két próbálkozás között meghatározott ideig várnak, hogy elkerüljék az észlelést.
  • Ransomware-támadások olyan célzott támadási típus, ahol a kártevőket adatok és fájlok titkosítására használják, megakadályozva a fontos tartalmakhoz való hozzáférést. A támadók ezután megpróbálnak pénzt kicsalni az áldozatoktól, általában kriptovaluták formájában, a visszafejtési kulcsért cserébe. A legtöbb zsarolóvírus-fertőzés olyan mellékletekkel rendelkező e-mailekkel kezdődik, amelyek megpróbálják telepíteni a zsarolóprogramokat, vagy olyan kizsákmányoló készleteket üzemeltető webhelyekről, amelyek megpróbálják biztonsági réseket használni a webböngészőkben és más szoftverekben a zsarolóprogramok telepítéséhez.

Jelszóval kapcsolatos kockázatok

Mivel nem szeretné, hogy a támadók könnyen kitalálják a fiókneveket vagy jelszavakat, az alábbi lépések segítenek csökkenteni a jelszavak felderítésének kockázatát:

  • Hozzon létre egy egyedi helyi rendszergazdai fiókot, amely nem a Rendszergazdanevet viseli.
  • Használjon összetett, erős jelszavakat az összes fiókjához. Az erős jelszó létrehozásáról további információt az Erős jelszó létrehozása című cikkben talál.
  • Az Azure alapértelmezés szerint a Windows-hitelesítést választja az SQL Server virtuális gép beállítása során. Ezért a sa bejelentkezés le van tiltva, és a beállítás egy jelszót rendel hozzá. Javasoljuk, hogy a sa bejelentkezés ne legyen használva vagy engedélyezve. Ha SQL-bejelentkezéssel kell rendelkeznie, használja az alábbi stratégiák egyikét:

    • Hozzon létre egy egyedi nevű SQL-fiókot, amely sysadmin tagsággal rendelkezik. Ezt a portálon teheti meg, ha engedélyezi az SQL-hitelesítést a telepítés során.

      Tipp

      Ha a kiépítés során nem engedélyezi az SQL-hitelesítést, manuálisan kell módosítania a hitelesítési módot SQL Server és Windows hitelesítési mód. További információ: Kiszolgálóhitelesítési mód módosítása.

    • Ha a sa bejelentkezést kell használnia, engedélyezze a bejelentkezést a kiépítés után, és rendeljen hozzá egy új erős jelszót.

Ransomware-kockázatok

A zsarolóprogramok kockázatainak minimalizálása érdekében vegye figyelembe az alábbiakat:

  • A legjobb stratégia az ransomware elleni védelemre az, hogy különös figyelmet fordítson az RDP és az SSH biztonsági résekre. Emellett vegye figyelembe a következő javaslatokat:
    • Tűzfalak használata és portok zárolása
    • Győződjön meg arról, hogy a legújabb operációs rendszer- és alkalmazásbiztonsági frissítések vannak alkalmazva
    • csoport által felügyelt szolgáltatásfiókok (gMSA)
    • A virtuális gépekhez való hozzáférés korlátozása
    • Igény szerinti (JIT) hozzáférés megkövetelése és Azure Bastion
    • A Surface Area Security javítása az eszközök, például a sysinternals és az SSMS helyi számítógépre történő telepítésének elkerülésével
    • Kerülje a windowsos szolgáltatások, szerepkörök és a nem szükséges szolgáltatások engedélyezését
    • Emellett rendszeres, teljes biztonsági mentést kell ütemezni, amely külön védett egy közös rendszergazdai fióktól, hogy ne tudja törölni az adatbázisok másolatait.

Kapcsolódó tartalom