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


Az SQL Server-ügynök biztonságának megvalósítása

A következőkre vonatkozik:SQL ServerAzure SQL Felügyelt példány

Fontos

Felügyelt Azure SQL-példányesetében a legtöbb, de jelenleg nem minden SQL Server Agent-funkció támogatott. A részletekért tekintse meg a Az Azure SQL Managed Instance T-SQL különbségeit az SQL Server-hez képest.

Az SQL Server Agent lehetővé teszi az adatbázis-rendszergazda számára, hogy minden feladatlépést olyan biztonsági környezetben futtasson, amely csak a feladatlépés végrehajtásához szükséges engedélyekkel rendelkezik, amelyet egy SQL Server-ügynökproxy határoz meg. Egy adott feladatlépés engedélyeinek beállításához hozzon létre egy proxyt, amely rendelkezik a szükséges engedélyekkel, majd rendelje hozzá a proxyt a feladatlépéshez. Egy proxy több feladatlépéshez is megadható. Az azonos engedélyeket igénylő feladatlépésekhez ugyanazt a proxyt kell használnia.

Az alábbi szakasz bemutatja, hogy milyen adatbázis-szerepkört kell megadnia a felhasználóknak, hogy sql server-ügynökkel hozhatnak létre vagy hajthatnak végre feladatokat.

Hozzáférés biztosítása az SQL Server-ügynökhöz

Az SQL Server Agent használatához a felhasználóknak az alábbi rögzített adatbázis-szerepkörök egyikének vagy több tagjának kell lenniük:

  • SQLAgentUserRole

  • SQLAgentReaderRole

  • SQLAgentOperatorRole

Ezek a szerepkörök az msdb adatbázisban vannak tárolva. Alapértelmezés szerint egyetlen felhasználó sem tagja ezeknek az adatbázis-szerepköröknek. Az ilyen szerepkörökben való tagságot explicit módon kell megadni. Azok a felhasználók, akik a sysadmin rögzített kiszolgálói szerepkör tagjai, teljes hozzáféréssel rendelkeznek az SQL Server Agenthez, és nem kell ezen rögzített adatbázis-szerepkörök tagjának lenniük az SQL Server-ügynök használatához. Ha egy felhasználó nem tagja ezeknek az adatbázis-szerepköröknek vagy a sysadmin szerepkörnek, az SQL Server-ügynök csomópont nem érhető el számukra, amikor az SQL Server Management Studióval csatlakoznak az SQL Serverhez.

Ezeknek az adatbázis-szerepköröknek a tagjai megtekinthetik és végrehajthatják a saját feladataikat, és meglévő proxyfiókként futtatott feladatlépéseket hozhatnak létre. Az egyes szerepkörökhöz társított konkrét engedélyekkel kapcsolatos további információkért lásd SQL Server-ügynök rögzített adatbázis-szerepköreit.

A sysadmin rögzített kiszolgálói szerepkör tagjai jogosultak proxyfiókok létrehozására, módosítására és törlésére. A sysadmin szerepkör tagjai rendelkeznek engedéllyel olyan feladatlépések létrehozására, amelyek nem proxyt adnak meg, hanem az SQL Server-ügynök szolgáltatásfiókjaként futnak, amely az SQL Server Agent elindításához használt fiók.

Iránymutatások

Kövesse az alábbi irányelveket az SQL Server-ügynök implementációjának biztonságának javításához:

  • Hozzon létre dedikált felhasználói fiókokat kifejezetten proxyk számára, és csak ezeket a proxyfelhasználói fiókokat használja a feladat lépéseinek futtatásához.

  • Csak a proxyfelhasználói fiókokhoz szükséges engedélyeket adja meg. Csak az adott proxyfiókhoz rendelt feladatlépések futtatásához szükséges engedélyeket adja meg.

  • Ne futtassa az SQL Server Agent szolgáltatást olyan Microsoft Windows-fiók alatt, amely tagja a Windows Rendszergazdák csoportnak.

  • A proxyk csak olyan biztonságosak, mint az SQL Server hitelesítőadat-tárolója.

  • Ha a felhasználói írási műveletek írhatnak az NT Event logba, riasztásokat hozhatnak létre az SQL Server Agenten keresztül.

  • Ne adja meg az NT-rendszergazdai fiókot szolgáltatásfiókként vagy proxyfiókként.

  • Az SQL Server és az SQL Server Agent hozzáfér egymás eszközeihez. A két szolgáltatás egyetlen folyamattérrel rendelkezik, az SQL Server-ügynök pedig az SQL Server szolgáltatás sysadminja.

  • Ha egy TSX (célkiszolgáló) MSX -kiszolgálóval (főkiszolgálóval) jelentkezik be, az MSX sysadmins teljes vezérlést kap az SQL Server TSX-példánya felett.

  • Az ACE egy bővítmény, és nem tudja meghívni magát. A Chainer ScenarioEngine.exe (más néven Microsoft.SqlServer.Chainer.Setup.exe) meghívhatja az ACE-t. Más gazdafolyamatok is meghívhatják az ACE-t.

  • Az ACE az SSDP által birtokolt következő konfigurációs DLL-ektől függ, mivel a DLL-ek API-jait az ACE hívja meg:

    • SCO- – Microsoft.SqlServer.Configuration.Sco.dll, beleértve a virtuális fiókok új SCO-érvényesítéseit

    • fürt – Microsoft.SqlServer.Configuration.Cluster.dll

    • SFC - Microsoft.SqlServer.Configuration.SqlConfigBase.dll

    • bővítmény – Microsoft.SqlServer.Configuration.ConfigExtension.dll

Csatolt kiszolgálók

Bizonyos esetekben, például Felügyelt Azure SQL-példányesetén, egy olyan SQL Agent-feladat futtatásához, amely egy csatolt kiszolgálón keresztül hajt végre egy Transact-SQL (T-SQL) lekérdezést egy távoli kiszolgálón, le kell képeznie egy helyi bejelentkezést a távoli kiszolgálón lévő bejelentkezéshez.

A sp_addlinkedsrvlogin használatával leképezést hozhat létre a helyi kiszolgálón lévő bejelentkezés és a távoli kiszolgálón található bejelentkezés között, amely rendelkezik a T-SQL-lekérdezés végrehajtásához szükséges engedéllyel. Amikor az SQL Agent-feladat a csatolt kiszolgálón keresztül csatlakozik a távoli kiszolgálóhoz, végrehajtja a T-SQL-lekérdezést a távoli bejelentkezés kontextusában.

A következő táblázat leírja, hogyan képezzen le bejelentkezést az SQL Agent feladat tulajdonosa alapján az Azure SQL Managed Instance esetében.

SQL Agent-feladat tulajdonosa Hogyan lehet leképezni a bejelentkezést
Olyan felhasználó, aki nem sysadmin A helyi felhasználót, aki a(z) SQL Agent feladat tulajdonosa, képezze le a távoli bejelentkezéshez.
rendszergazda Állítsuk a @locallogin paramétert NULLaz összes helyi felhasználó távoli bejelentkezéséhez.

Jegyzet

A távoli kiszolgálón való bejelentkezés létrehozása szükséges az SQL Agent feladatokhoz, amikor a helyi kiszolgáló egy felügyelt Azure SQL-példány. Ha nem sikerül megfelelően megfeleltetni a felhasználókat, az a következő példákhoz hasonló hibákat eredményezhet:

  • Windows logins are not supported in this version of SQL Server
  • Linked servers cannot be used under impersonation without a mapping for the impersonated login