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


Ismerkedés az adatbázismotor engedélyeivel

Vonatkozik a következőkre:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalitikai Platform System (PDW)SQL adatbázis a Microsoft Fabric-ben

Ez a cikk áttekint néhány alapvető biztonsági fogalmat, majd ismerteti az engedélyek tipikus implementálását. Az adatbázismotor engedélyei kiszolgálószinten , bejelentkezések és kiszolgálói szerepkörök révén, adatbázisszinten pedig adatbázis-felhasználókon és adatbázis-szerepkörökön keresztül kezelhetők.

Az SQL Database és az SQL Database a Microsoft Fabricben ugyanazokat a lehetőségeket biztosítja az egyes adatbázisokon belül, de a kiszolgálószintű engedélyek nem érhetők el.

Note

A Microsoft Entra ID-t korábban Azure Active Directorynak (Azure AD) nevezték.

Biztonsági tagok

A biztonsági identitás az az identitás, amelyet az SQL Server használ az engedélyek műveletek elvégzésére való kiosztásához. A biztonsági tagok általában személyek vagy személyek csoportjai, de lehetnek más entitások is, amelyek úgy tesznek, mintha emberek lennének. A biztonsági objektumok létrehozása és kezelése a cikkben bemutatott Transact-SQL példákkal, vagy az SQL Server Management Studio használatával történhet.

Logins

A bejelentkezések egyéni felhasználói fiókok az SQL Server adatbázismotorba való bejelentkezéshez. Az SQL Server és az SQL Database támogatja a Windows-hitelesítésen alapuló bejelentkezéseket, valamint az SQL Server-hitelesítésen alapuló bejelentkezéseket. A kétféle bejelentkezésről további információt a Hitelesítési mód kiválasztása című témakörben talál.

Rögzített kiszolgálói szerepkörök

Az SQL Serverben a rögzített kiszolgálói szerepkörök előre konfigurált szerepkörök, amelyek a kiszolgálószintű engedélyek kényelmes csoportját biztosítják. A bejelentkezések a ALTER SERVER ROLE ... ADD MEMBER parancs segítségével vehetők fel a szerepkörökbe. További információ: ALTER SERVER ROLE. Az SQL Database nem támogatja a rögzített kiszolgálói szerepköröket, de két szerepkörrel rendelkezik az master adatbázisban (dbmanager és loginmanager), amelyek kiszolgálói szerepkörökként működnek.

Felhasználó által definiált kiszolgálói szerepkörök

Az SQL Serverben saját kiszolgálói szerepköröket hozhat létre, és kiszolgálószintű engedélyeket rendelhet hozzájuk. A kiszolgálói szerepkörökbe az utasítással ALTER SERVER ROLE ... ADD MEMBER lehet bejelentkezni. További információ: ALTER SERVER ROLE. Az SQL Database nem támogatja a felhasználó által definiált kiszolgálói szerepköröket.

Adatbázis-felhasználók

Ahhoz, hogy hozzáférést biztosítson egy adatbázishoz való bejelentkezéshez, létre kell hoznia egy adatbázis-felhasználót az adatbázisban, és leképezheti az adatbázis-felhasználót egy bejelentkezésre. Az adatbázis felhasználóneve általában megegyezik a bejelentkezési névvel konvenció szerint, bár nem kell megegyeznie. Minden adatbázis-felhasználó egyetlen bejelentkezésre van leképzve. A bejelentkezések csak egy felhasználóra képezhetők le az adatbázisban, de több különböző adatbázisban is leképezhetők adatbázis-felhasználóként.

Olyan adatbázis-felhasználók is létrehozhatóak, amelyek nem rendelkeznek megfelelő bejelentkezéssel. Ezeket a felhasználókat tartalmazott adatbázis-felhasználóknak nevezzük. A Microsoft támogatja a tartalmazott adatbázis-felhasználók használatát, mivel megkönnyíti az adatbázis áthelyezését egy másik kiszolgálóra. A bejelentkezéshez hasonlóan a tárolt adatbázis-felhasználók Windows- vagy SQL Server-hitelesítést is használhatnak. További információ: Az adatbázis hordozhatóvá tétele tartalmazott adatbázisokhasználatával.

A hitelesítés módjában és az általuk képviselt felhasználókban 12-féle különbség van. A felhasználók listájának megtekintéséhez tekintse meg a CREATE USER (FELHASZNÁLÓ LÉTREHOZÁSA) című témakört.

Rögzített adatbázis-szerepkörök

A rögzített adatbázis-szerepkörök olyan előre konfigurált szerepkörök, amelyek az adatbázisszintű engedélyek kényelmes csoportját biztosítják. Az adatbázis-felhasználók és a felhasználó által definiált adatbázis-szerepkörök az utasítással ALTER ROLE ... ADD MEMBER vehetők fel a rögzített adatbázis-szerepkörökbe. További információ: ALTER ROLE.

Felhasználó által definiált adatbázis-szerepkörök

Az CREATE ROLE engedéllyel rendelkező felhasználók új , felhasználó által definiált adatbázis-szerepköröket hozhatnak létre, amelyek a közös engedélyekkel rendelkező felhasználók csoportjait jelölik. Az engedélyek általában a teljes szerepkör számára vannak megadva vagy megtagadva, ami leegyszerűsíti az engedélyek kezelését és monitorozását. Az adatbázis-felhasználók az utasítással vehetők fel az ALTER ROLE ... ADD MEMBER adatbázis-szerepkörökbe. További információ: ALTER ROLE.

Egyéb vezetők

Az itt nem tárgyalt biztonsági tagok közé tartoznak az alkalmazásszerepkörök, valamint a tanúsítványokon vagy aszimmetrikus kulcsokon alapuló bejelentkezések és felhasználók.

A Windows-felhasználók, a Windows-csoportok, a bejelentkezések és az adatbázis-felhasználók közötti kapcsolatokat bemutató ábráért lásd: Adatbázis-felhasználó létrehozása.

Tipikus forgatókönyv

Az alábbi példa az engedélyek konfigurálásának gyakori és ajánlott módját mutatja be.

Windows Active Directoryban vagy Microsoft Entra-azonosítóban

  1. Hozzon létre egy felhasználót minden egyes személy számára.
  2. Hozzon létre windowsos csoportokat, amelyek a munkaegységeket és a munkafüggvényeket jelölik.
  3. Adja hozzá a Windows-felhasználókat a Windows-csoportokhoz.

Ha a felhasználó számos adatbázishoz csatlakozik

  1. Hozzon létre egy bejelentkezést a Windows-csoportokhoz. (Ha SQL Server-hitelesítést használ, hagyja ki az Active Directory lépéseit, és itt hozzon létre SQL Server-hitelesítési bejelentkezéseket.)

  2. A felhasználói adatbázisban hozzon létre egy adatbázis-felhasználót a Windows-csoportokat képviselő bejelentkezéshez.

  3. A felhasználói adatbázisban hozzon létre egy vagy több felhasználó által definiált adatbázisszerepkört, amelyek mindegyike hasonló függvényt jelöl. Előfordulhat például, hogy pénzügyi elemzői és értékesítési elemzői szerepkörrel rendelkezik.

  4. Adja hozzá az adatbázis felhasználóit egy vagy több felhasználó által definiált adatbázis-szerepkörhöz.

  5. Adjon engedélyeket a felhasználó által definiált adatbázis-szerepköröknek.

Ha a felhasználó csak egy adatbázishoz csatlakozik

  1. A felhasználói adatbázisban hozzon létre egy tartalmazott adatbázis-felhasználót a Windows-csoporthoz. (Ha SQL Server-hitelesítést használ, hagyja ki az Active Directory lépéseit, és hozzon létre tartalmazott adatbázis-felhasználó SQL Server-hitelesítést itt.)

  2. A felhasználói adatbázisban hozzon létre egy vagy több felhasználó által definiált adatbázisszerepkört, amelyek mindegyike hasonló függvényt jelöl. Előfordulhat például, hogy pénzügyi elemzői és értékesítési elemzői szerepkörrel rendelkezik.

  3. Adja hozzá az adatbázis felhasználóit egy vagy több felhasználó által definiált adatbázis-szerepkörhöz.

  4. Adjon engedélyeket a felhasználó által definiált adatbázis-szerepköröknek.

Ezen a ponton általában az a jellemző, hogy egy Windows-felhasználó tagja egy Windows-csoportnak. A Windows-csoport rendelkezik bejelentkezéssel az SQL Serverben vagy az SQL Database-ben. A bejelentkezés egy felhasználói identitásra van leképezve a felhasználói adatbázisban. A felhasználó egy adatbázis-szerepkör tagja. Most engedélyeket kell hozzáadnia a szerepkörhöz.

Engedélyek hozzárendelése

A legtöbb engedélymegkivonat formátuma a következő:

<authorization> <permission> ON <securable>::<name> TO <principal>;
  • <authorization> kell lennie GRANT, REVOKEvagy DENY.

  • A <permission> határozza meg, hogy mely művelet engedélyezett vagy tiltható. Az engedélyek pontos száma eltér az SQL Server és az Azure SQL Database között. Az engedélyekről további információt az Engedélyek (Adatbázismotor) című témakörben talál, és a cikk későbbi részében a diagramra is hivatkozhat.

  • ON <securable>::<name> a védhető elem típusa (kiszolgáló, kiszolgálóobjektum, adatbázis vagy adatbázisobjektum) és neve. Bizonyos engedélyek nem igényelnek <securable>::<name> , mert egyértelmű vagy nem megfelelő a környezetben. Az engedélyhez például CREATE TABLE nincs szükség a <securable>::<name> záradékra (GRANT CREATE TABLE TO Mary; lehetővé teszi, hogy Mary táblákat hozzon létre).

  • <principal> az a biztonsági tag (bejelentkezés, felhasználó vagy szerepkör), amely megkapja vagy elveszíti az engedélyt. Biztosítson engedélyeket a szerepköröknek, amikor csak lehetséges.

Az alábbi példautasítás engedélyt ad a UPDATE jogosultságra, a Parts sémában található Production táblán vagy nézeten, a PartsTeam nevű szerepkörnek.

GRANT UPDATE ON OBJECT::Production.Parts TO PartsTeam;

Az alábbi példautasítás a UPDATE sémában lévő Production engedélyt adja meg, valamint kiterjeszti azt bármely, a sémában található táblára vagy nézetre, a ProductionTeam nevű szerepkör számára. Ez hatékonyabb és eladhatóbb megközelítés az engedélyek hozzárendelésére, mint az egyes objektumszinten történő kezelés.

GRANT UPDATE ON SCHEMA::Production TO ProductionTeam;

Az GRANT utasítás használatával engedélyeket adnak a biztonsági alanyoknak (bejelentkezések, felhasználók és szerepkörök). A parancs használatával az engedélyek explicit módon megtagadva lesznek DENY . A korábban megadott vagy megtagadott engedélyek az utasítással REVOKE törlődnek. Az engedélyek összesítő jellegűek, a felhasználó megkapja a bejelentkezéshez, csoporttagságokhoz és minden más részhez adott összes engedélyt; azonban az engedély megtagadása felülír minden megadást.

Caution

Gyakori hiba az, hogy megpróbálják eltávolítani a GRANT azzal, hogy DENY használnak, ahelyett, hogy REVOKE használatával tennék. Ez problémákat okozhat, ha egy felhasználó több forrásból kap engedélyeket, ami gyakori forgatókönyv lehet. Az alábbi példa az alapelvet mutatja be.

A Sales csoport a SELECT utasításon keresztül megkapja a OrderStatus táblára vonatkozó GRANT SELECT ON OBJECT::OrderStatus TO Sales; engedélyeket. A Jae felhasználó a Sales szerepkör tagja. Jae engedélyt kapott SELECT a OrderStatus táblára a saját felhasználóneve alatt az utasításon GRANT SELECT ON OBJECT::OrderStatus TO Jae; keresztül. Feltételezzük, hogy a rendszergazda módosítani szeretné a GRANT szerepkört a Sales szerepkörre.

  • Ha a rendszergazda megfelelően végrehajtja a REVOKE SELECT ON OBJECT::OrderStatus TO Sales; parancsot, Jae megőrzi a SELECT hozzáférést a OrderStatus táblához az egyéni GRANT utasításon keresztül.

  • Ha a rendszergazda helytelenül hajtja végre a DENY SELECT ON OBJECT::OrderStatus TO Sales;, akkor Jae, a Sales szerepkör tagjaként, meg van fosztva az SELECT engedélytől, mert a DENY a Sales felülírja az egyéni GRANT.

Note

Az engedélyek a Management Studióval konfigurálhatók. Keresse meg a biztonságos objektumot az Object Explorerben, kattintson a jobb gombbal a biztonságosra, majd válassza a Tulajdonságok lehetőséget. Válassza az Engedélyek lapot. Az engedélyoldal használatával kapcsolatos segítségért tekintse meg az Engedélyek vagy a Biztonságossá tétel lapját.

Engedélyhierarchia

Az engedélyek szülő-gyermek hierarchiával rendelkeznek. Vagyis ha engedélyt ad SELECT egy adatbázisra, az engedély az adatbázis összes (gyermek) sémájára vonatkozó engedélyt is magában foglalja SELECT . Ha engedélyt ad SELECT egy sémára, az automatikusan magában foglalja SELECT engedélyt a séma összes (gyermek) táblájára és nézetére. Az engedélyek tranzitívak: ha engedélyt ad SELECT egy adatbázishoz, az az összes (gyermek) sémára, valamint az összes (unoka) táblára és nézetre vonatkozó engedélyt tartalmazza SELECT .

Az engedélyek között is vannak fedő engedélyek. Egy CONTROL objektum engedélye általában minden más engedélyt biztosít az objektumhoz.

Mivel a szülő-gyermek hierarchia és a lefedő hierarchia is ugyanazon az engedélyen működhet, az engedélyrendszer bonyolulttá teheti. Vegyük például egy táblát (Region), egy sémában (Customers), egy adatbázisban (SalesDB).

  • CONTROL A tábla Region engedélyei tartalmazzák a tábla Regionösszes többi engedélyét , beleértve ALTERa , SELECT, INSERT, , UPDATE, DELETE, és néhány egyéb engedélyt.

  • SELECT a Customers sémához tartozó Region tábla rendelkezik a SELECT engedéllyel a Region táblán.

Ezek közül a hat utasítás közül bármelyikkel elérhető SELECT engedély a Region táblára.

GRANT SELECT ON OBJECT::Region TO Jae;

GRANT CONTROL ON OBJECT::Region TO Jae;

GRANT SELECT ON SCHEMA::Customers TO Jae;

GRANT CONTROL ON SCHEMA::Customers TO Jae;

GRANT SELECT ON DATABASE::SalesDB TO Jae;

GRANT CONTROL ON DATABASE::SalesDB TO Jae;

A legkisebb engedély megadása

A korábban (GRANT SELECT ON OBJECT::Region TO Jae;) felsorolt első engedély a legrészletesebb. Ez az utasítás a lehető legkisebb engedély, amely megadja a SELECT. Az alárendelt objektumokra vonatkozó engedélyek nem járnak vele. Érdemes mindig a lehető legkevesebb engedélyt megadni, de érdemes megfontolni a magasabb szinteken történő engedélyezést, hogy egyszerűbb legyen az engedélyezési rendszer.

Tehát ha Jae-nek a teljes sémához engedélyre van szüksége, adja meg SELECT egyszer a séma szintjén, ahelyett, hogy a tábla vagy a nézet szintjén többször megadnál SELECT . Az adatbázis kialakítása jelentősen befolyásolhatja a stratégia sikeres voltát. Ez a stratégia akkor működik a legjobban, ha az adatbázis úgy van kialakítva, hogy az azonos engedélyekkel rendelkező objektumok egyetlen sémába legyenek belefoglalva.

Tip

Adatbázis és objektumainak tervezésekor az elejétől kezdve tervezze meg, hogy az alkalmazások és a felhasználók hogyan férnek hozzá ezekhez az objektumokhoz. Ezekkel az információkkal séma használatával szabályozhatja a táblákhoz, nézetekhez, függvényekhez és tárolt eljárásokhoz való hozzáférést. A sémák lehetővé teszik a hozzáférési típusok egyszerűbb csoportosítását.

Engedélyek diagramja

Az alábbi képen az engedélyek és azok egymáshoz való viszonya látható. A magasabb szintű engedélyek némelyike (például CONTROL SERVER) sokszor szerepel a listán. Ebben a cikkben a plakát túl kicsi ahhoz, hogy elolvassa. Letöltheti a teljes méretű Adatbázis-motor jogosultságok plakátját PDF formátumban .

Képernyőkép az adatbázismotor engedélyeinek PDF-fájljáról.

Az adatbázismotor-tagok, valamint a kiszolgáló- és adatbázis-objektumok közötti kapcsolatokat bemutató ábrát az Engedélyhierarchia (adatbázismotor) című témakörben talál.

Engedélyek vs. rögzített kiszolgálói és rögzített adatbázis-szerepkörök

A rögzített kiszolgálói szerepkörök és a rögzített adatbázis-szerepkörök engedélyei hasonlóak, de nem teljesen megegyeznek a részletes engedélyekkel. A sysadmin rögzített kiszolgálói szerepkör tagjai például minden engedéllyel rendelkeznek az SQL Server-példányhoz, ahogy az CONTROL SERVER engedélyekkel rendelkező bejelentkezésekhez is.

Az engedély megadása CONTROL SERVER azonban nem teszi a bejelentkezést a sysadmin rögzített kiszolgálói szerepkör tagjának, és a sysadmin rögzített kiszolgálói szerepkörhöz való bejelentkezés nem adja meg kifejezetten a CONTROL SERVER bejelentkezési engedélyt. Néha egy tárolt eljárás ellenőrzi az engedélyeket a rögzített szerepkör ellenőrzésével, és nem a részletes engedély ellenőrzésével.

Az adatbázis leválasztásához például tagságra van szükség a db_owner rögzített adatbázis-szerepkörben. Az ezzel egyenértékű CONTROL DATABASE engedély nem elég. Ez a két rendszer párhuzamosan működik, de ritkán kommunikálnak egymással. A Microsoft a rögzített szerepkörök helyett az újabb, részletesebb engedélyrendszer használatát javasolja, amikor csak lehetséges.

Engedélyek figyelése

Az alábbi nézetek biztonsági információkat adnak vissza. A biztonsággal kapcsolatos nézeteket a Biztonsági katalógus nézetei (Transact-SQL) című témakörben talál.

View Description
sys.server_principals 1 Bejelentkezések és felhasználó által definiált kiszolgálói szerepkörök egy kiszolgálón
sys.database_principals Felhasználók és felhasználó által definiált szerepkörök az adatbázisban
sys.server_permissions 1 Bejelentkezésekhez és felhasználó által meghatározott rögzített kiszolgálói szerepkörökhöz megadott engedélyek
sys.database_permissions Felhasználóknak és felhasználó által meghatározott rögzített adatbázis-szerepköröknek adott engedélyek
sys.database_role_members Adatbázis-szerepkör tagsága
sys.server_role_members 1 Kiszolgálói szerepkör tagság

1 Ez a nézet nem érhető el az SQL Database-ben.

Examples

Az alábbi állítások hasznos információkat adnak vissza az engedélyekről.

A. Az egyes felhasználók adatbázis-engedélyeinek listája

Az adatbázisban (SQL Server és SQL Database) megadott vagy elutasított explicit engedélyek visszaadásához futtassa az alábbi Transact-SQL utasítást az adatbázisban.

SELECT perms.state_desc AS State,
       permission_name AS [Permission],
       obj.name AS [on Object],
       dp.name AS [to User Name]
FROM sys.database_permissions AS perms
     INNER JOIN sys.database_principals AS dp
         ON perms.grantee_principal_id = dp.principal_id
     INNER JOIN sys.objects AS obj
         ON perms.major_id = obj.object_id;

B. Kiszolgálói szerepkörök tagjainak listázása

A kiszolgálói szerepkörök tagjainak visszaadásához (csak SQL Server esetén) futtassa az alábbi utasítást.

SELECT roles.principal_id AS RolePrincipalID,
       roles.name AS RolePrincipalName,
       server_role_members.member_principal_id AS MemberPrincipalID,
       members.name AS MemberPrincipalName
FROM sys.server_role_members AS server_role_members
     INNER JOIN sys.server_principals AS roles
         ON server_role_members.role_principal_id = roles.principal_id
     LEFT OUTER JOIN sys.server_principals AS members
         ON server_role_members.member_principal_id = members.principal_id;

C. Az adatbázisszintű szerepkörök tagjai közé tartozó összes adatbázis-tag listázása

Az adatbázis-szerepkörök (SQL Server és SQL Database) tagjainak visszaadásához futtassa az alábbi utasítást az adatbázisban.

SELECT dRole.name AS [Database Role Name],
       dp.name AS [Members]
FROM sys.database_role_members AS dRo
     INNER JOIN sys.database_principals AS dp
         ON dRo.member_principal_id = dp.principal_id
     INNER JOIN sys.database_principals AS dRole
         ON dRo.role_principal_id = dRole.principal_id;