استفاده از مجوزهای SQL Server برای داشتن یک سرور پایگاه اطلاعاتی مطمئن تر

/
/
/

استفاده از مجوزهای SQL Server
برای داشتن یک سرور پایگاه اطلاعاتی مطمئن تر

SQL Server 2005، اولین ورژن اصلی SQL Server بعد از انتشار یادداشت های بیل گیست در خصوص محاسبات مطمئن در سال ۲۰۰۲ بود. این یادداشت ها روند و دیدگاه آن شرکت را در مورد امنیت محصولاتش تغییر داد و ویژگی های امنیتی در SQL 2005 دست خوش یک تجدید نظر کلی شد. در نتیجه SQL Server 2012 و ۲۰۱۴ محصولات بسیار مطمئنی هستند که براساس ویژگی های اصلاح شده ساخته شده اند، ویژگی هایی که موجب می شوند نسخه¬های جدیدتر قدرتمندتر باشند. اما حفظ ایمنی، ضمن افزودن پایگاه اطلاعاتی و اجازه دسترسی به کاربران می تواند چالش برانگیز باشد.
یکی از قابل توجه ترین تغییرات در SQL Server 2005 ، عنصر اصلی مجوزهای واگذاری اختیار به سرور بود، که در نهایت منجر شد به تعیین روزهایی برای اختصاص نقش های سیستمی به کاربران جهت واگذاری تنها یک مجوز به آن ها ، همراه با محدودیت های امنیتی جدی دیگر. حال، سیستم مجوزها بسیار گرانولار شده است و به شما امکان می دهد حداقل مجوزهای لازم برای یک principal (آبجکت هایی که در صورت داشتن مجوز می توانند به منابع دسترسی داشته باشند) که جهت انجام کارش لازم است را تعیین کنید و این همان ایده ایست که اصل امنیتی Least Privilege یا اصل حداقل بودن امتیازات را شکل می دهد.
هنگام استفاده از مجوزها باید سه نکته مد نظر قرار داد:
چه کسی باید این مجوز را دریافت کند؟
در خصوص چه آبجکتی باید به آنها مجوز واگذار شود؟
نوع مجوزهایی که باید به آنها واگذر گردد، کدامست؟
ایده اصلی واگذاری مجوزها در این است که به برخی Principal ها یک نوع مجوز خاص در خصوص آبجکت یا آبجکت های موجود در نمونه SQL Server، واگذار شود.
همانند هر چیز دیگری در SQL Server، نقشه و طراحی مجوزها بر عهده خود شماست تا حداکثر محافظت از داده ها و سرورهای شما به عمل بیاید، ضمن این که تعادلی بین نیاز افراد و فرآیند دسترسی به داده ها جهت رفع نیاز آنان برقرار گردد. این کار در واقع نوعی متعادل سازی است، ولی برای اجرای Least Privilege در SQL Server نقش حیاتی دارد.
Principal ها: چه کسی مجوز دریافت می کند؟
SQL Server دارای Principal های مختلفی است که امکان واگذاری مجوز به آنها در خصوص یک آبجکت وجود دارد. Principalهای موجود شامل اینها هستند: کاربران واقعی که از طریق ویندوز یا SQL Server تائید اعتبار می شوند، مپینگ-های محتلف Principalها در حوضه¬های متفاوت،همچنین اپلیکیشن ها، کلیدهای نامتقارن و حتی گواهینامه های امنیتی.
Principalهای سطح ویندوز
حوزه ویندوز یا لاگین محلی گروه ویندوز
Principalهای سطح SQL Server
لاگین SQL Server، مستقل یا مپ شده در یک گواهینامه، لاگین ویندوز یا کلید نامتقارن

Principalهای سطح پایگاه اطلاعاتی
نقش اپلیکیشن
نقش پایگاه اطلاعاتی
کاربر پایگاه اطلاعاتی، به صورت اختیاری مپ شده در یک گواهینامه ، لاگین ویندوز یا یک کلید نامتقارن
نقش عمومی
همانند ویندوز، یک Principal می تواند یک کاربر مجزا یا مجموعه ای از کاربران باشد که در ویندوز group (گروه) و در SQL Server، role (نقش) خوانده می شود.
شما معمولا می خواهید کاربران را به صورت گروه در ویندوز (که بعدا به یک نقش در SQL Server تبدیل می شوند) یا نقش در SQL Server تعیین کنید و بعد مجوزها را به آن یک نقش واگذار نمائید. این کار موجب می شود تا مدیریت مجوزها بسیار ساده تر شود، بخصوص زمانی که شما با گروه ها و سلسله مراتبی از آبجکت ها سر و کار دارید.
آبجکت مجوز
آبجکت Securable همانند هر آبجکت تعریف شده توسط کاربر در SQL Server است، آبجکت هایی که می توانند با استفاده از مجوزهای واگذار شده به یک Principal، مورد دسترسی قرار بگیرند و کنترل شوند. سه حوضه در خصوص آبجکت های Securable وجود دارند- سرور، پایگاه اطلاعاتی و طرح (Schema)- که سلسه مراتبی از آبجکت های Securable را در نمونه SQL Server (تصویر ۱) شکل می دهند. این تصویر آبجکت های بسیار متداول را نشان می دهد که باید در هر حوضه از آنها محافظت کنید (اما نه همه آن ها را). همینطور این تصویر نشان می دهد که چگونه ۲ آبجکت یعنی پایگاه اطلاعاتی و طرح، محفظه هایی برای آبجکت های دیگر هستند.

تصویر ۱: سلسله مراتب آبجکت های Securable در نمونه SQL Server
درک این سلسله مراتب بسیار مهم است چرا که می توانید هر آبجکت به نمایش در آمده در تصویر را به طور جداگانه با مجوزها محافظت نمائید. بخصوص در مورد آبجکت های منحصر به فردی مانند Securableها، Certificateها (گواهینامه ها) و Tableها(جدول ها). اما اهمیت این موضوع بیشتر به آبجکت های محفظه پایگاه اطلاعاتی و طرح باز می گردد. هر یک از آن آبجکت ها شامل آبجکت های دیگر هستند. معنی امنیت این است که شما بتوانید مجوزهایی را در آن محفظه تنظیم کنید تا بعدا برای تمام آبجکت های داخل محفظه اعمال شود.
برای مثال، شما میتوانید مجوز SELECT را به طرح واگذارء کنید و Principal ، آن مجوز را برای تمام جدول های داخل طرح دریافت خواهد کرد. بنابراین همانند نقش ها که مجوزهای مربوط به Principalها را جمع آوری می کنند، آبجکت های محفظه هم مجوزهای مربوط به آبجکت¬ها را جمع آوری می کنند.
حتی می توانید گرانولارتر عمل کنید و SELECT را به یک طرح واگذار نمایید، اما آن مجوز را فقط برای یکی از جدول هایش Deny یا رد کنید به این ترتیب، باز هم مدیریت طرح بسیار آسان تر از زمانی خواهد بود که مجبورید بازای هر آبجکت یک مجوز به هر Principal واگذار نمائید.
دستورهای مجوز
حال که اطلاعاتی را در مورد Principalها و آبجکت های Securable کسب کردید، زمان آن رسیده تا درباره خود مجوزها و نحوه ی واگذاری آنها صحبت کنیم. شما میتوانید این کارها را با استفاده از ابزارهای زیادی که در SQL Server Management Studio(SSMS) وجود دارند و یا با نوشتن دستورهای T-SQL انجام دهید.
سه دستور مجوز وجود دارند که میتوانید از آن¬ها استفاده نمائید. دستور GRANT که مجوزی درخصوص یک آبجکت Securable را به یک Principal واگذار می کند. دستور REVOKE آنچه که دستور GRANT انجام می دهد را خنثی می کند: یعنی مجوز مربوط به آبجکتی را که قبلاً به یک Principal واگذار شده بود، لغو می کند. اگر زمانی که دستور REVOKE اجرا می شود، Principal مجوز نداشته باشد، همچنان بدون مجوز باقی می ماند و هیچ خطایی رخ نمی دهد. مهم است بدانید که یک مجوز لغو شده (revoke) میتواند همچنان از سوی اعضای داخل یک نقش که دارای مجوز هستند به ارث برسد. این کار منجر به ایجاد موقعیت های بهم پیچیده می شود، بنابراین بهترین کار این است که غیر از نقش¬ها، واگذاری مجوز به کاربران فردی، لاگین ها یا Principalهای مجزا به ندرت صورت بگیرد.
دستور مجوز سوم DENY است. دستور DENY نیز مجوز را لغو می کند اما با این تفاوت که امکان به ارث رسیدن مجوز از طریق اعضای نقش به Principal وجود ندارد. وقتی مجوزی را رد می کنید(Deny)، آن Principal دیگر آن مجوز را ندارد. رد مجوزها به شما امکان میدهد تا مجوزها را به شکل بسیار گرانولارتر دریافت نمائید. مثل این که به تمام افرادی که در یک اداره هستند مجموعه از مجوزها از طریق اعضای آن¬ها در یک نقش، واگذار شود. اما از سوی دیگر شما می توانید با رد مجوزهای مربوط به برخی از کاربران خاص یا نقشی که تنها زیر مجموعه ای از کاربران به آن تعلق دارند، طرح را تنظیم نمائید و از توانایی کاربرانی که عضوی از نقش های چندگانه هستند، بهره مند شوید.
توجه داشته باشید که با استفاده از این سه دستور می توان به راحتی مجموعه ای از مجوزهای در هم پیچیده و یا ترکیبی ساخت که البته نگهداری و درک مجوزها را سخت تر می کند. اگر ساخت مجوز ساده باشد راحت تر می توانید امنیت آن را حفظ کنید.
استفاده از مجوزها در سطح نمونه سرور
حال دانش مجوزها را به کار می گیریم و نگاهی به برخی از کدهای T-SQL می اندازیم که در عمل های مختلف به اجرا در می آیند . این کد مجوزها را در سطح سرور و پایگاه اطلاعاتی آزمایش می کند.
کد با ساخت لاگین سرور Bonsai(با یک پسورد قوی) و یک Bonsai کاربر مپ شده در لاگین در پایگاه اطلاعاتی AdventureWorks2012 آغاز می گردد. از هر پایگاه اطلاعاتی که می خواهید می توانید استفاده کنید اما در بخش هایی از کد از آبجکت ها و داده های داخل پایگاه اطلاعاتی استفاده می شود.
CREATE LOGIN Bonsai WITH PASSWORD = ‘EDxQk!R209*:ZJ5’;

GO

USE AdventureWorks2012;
GO

CREATE USER Bonsai FOR LOGIN Bonsai WITH DEFAULT_SCHEMA = Production;
GO
سپس کد یک نقش سرور تعریف شده توسط کاربر به نام LimitedAdmin را می سازد که بیشترین (نه همه ی) حق امتیازهای Sysadmin را در نمونه SQL Server دریافت می کند. این نقش ابتدا مجوز CONTROL SERVER را دریافت می کند و از آن نقش sysadmin می سازد. سپس کد برخی از مجوزها ، از جمله توانایی ساخت یا تغییر نقش های سرور و لاگین ها را رد می کند. شاید بزرگترین موفقیتی که در حیطه قدرت این کد می توان به آن اشاره کرد، رد مجوز برای تغییر پایگاه اطلاعاتی است که شامل توانایی ساخت پایگاه های اطلاعاتی جدید می شود.
بنابراین این نقش دارای مجوزهایی در سطح نمونه سرور است.
USE master;
GO

CREATE SERVER ROLE LimitedAdmin;
GO

GRANT CONTROL SERVER TO LimitedAdmin;
GO

DENY ALTER ANY SERVER ROLE TO LimitedAdmin;
DENY ALTER ANY LOGIN TO LimitedAdmin;
DENY ALTER ANY DATABASE TO LimitedAdmin;

حال وقت آن رسیده تا قدرت نقش LimitedAdmin را آزمایش کنیم. برای اینکار، ما از کد لیست ۱ استفاده می کنیم که سعی می کند ۴ عمل را انجام دهد: ساخت نقش سرور، ساخت لاگین، ساخت پایگاه اطلاعاتی و فعال کردن کد SQL CLR در نمونه. ما مجوزها را در سه عمل اول رد کرده ایم اما عمل چهارم باید کار کند چرا که sysadmins دارای امکان تغییر تنظیمات سیستم می باشد و ما آن مجوز را در نقش رد نمی کنیم.
CREATE SERVER ROLE TempRole;
CREATE LOGIN TempLogin WITH PASSWORD = ‘AK8l*9%fwy/xvH’;
CREATE DATABASE TempDatabase;

EXEC SP_CONFIGURE ‘show advanced options’ , ‘1’;
GO
RECONFIGURE;
GO
EXEC SP_CONFIGURE ‘clr enabled’, ‘1’
GO
RECONFIGURE;
GO
لیست ۱:کدی که برای آزمایش مجوزهای کاربر LimitedAdmin استفاده می شود

برای آزمایش قابلیت های LimitedAdmin، ما از لاگین Bonsai که قبلاً ساخته شده، استفاده خواهیم کرد؛ مفاد اجرایی را مطابق آنچه که در پائین آمده تغییر می دهیم و سپس دستورها را در لیست ۱ به اجرا در می آوریم. از آنجائیکه هنوز Bonsai را به نقش LimitedAdmin اضافه نکرده ایم، او هنوز هم یک لاگین معمولی بدون مجوزهای زیاد است و همانطور که در تصویر ۲ می بینید، تمام دستورها ناکام می مانند. این تصویر نوعی تست کنترل ارائه می دهد که خاطر نشان می کند کاربر اصلی هیچ نوع مجوزی در سطح سرور ندارد.

EXECUTE AS LOGIN = ‘Bonsai’;

تصویر ۲: آزمایش مجوزهای Bonsai قبل از آنکه او عضوی از نقش LimitedAdmin شود
سپس مجوزهای sysadmin را با استفاده از دستور زیر ارجاع می دهیم
REVERT;
حال این فرآیند را تکرار می کنیم، اما ابتدا با استفاده از دستور زیر Bonsai را به گروه LimitedAdmin می افزائیم، بنابراین Bonsai علاوه بر مجورهای قبلی ، مجوزهای این نقش را هم دارد. (در این مثال او هیچ مجوزی ندارد.)
ALTER SERVER ROLE LimitedAdmin ADD MEMBER Bonsai;
حال، وقتی مفاد اجرایی را به Bonsai تغییر می دهیم، سه عمل اول همچنان ناکام می مانند، اما با فعال سازی کد SQL CLR به خوبی کار می کند. گرچه ما مجوز CONTROL SERVER را به نقش LimitedAdmin واگذار کردیم و این تقریبا تمام کارهایی که میتوانید در یک نمونه سرور انجام دهید را پوشش می دهد، همچنین برخی از مجوزها را رد کردیم.
اگر نمی خواهید نقش LimitedAdmin امکان تغییر تنظیمات سرور مانند فعال سازی کد SQL CLR را داشته باشد، می توانید مجوز SETTINGS را با دستور زیر رد کنید.
DENY ALTER SETTINGS TO LimitedAdmin;
حال، اجرای دستورها در لیست ۱ کاملا ناموفق خواهد بود، چرا که LimitedAdmin یک sysadmin بسیار محدود است، اما این مثال نشان می دهد که چه کارهایی می توانید با مجوزهای گرانولار در سطح سرور انجام دهید. و بخاطر بسپارید که نباید کار را با واگذاری مجوز CONTROL SERVER آغاز نمائید. می توانید به جای واگذاری مجوزهای شخصی بزرگ و بعد رد آنها، از مجوزهای کوچکتر آغاز کنید و به این نقش تنها مجوزهایی را واگذار کنید که اعضا برای انجام کارهایشان به آن نیاز دارند.

استفاده از مجوزها در سطح پایگاه اطلاعاتی
شما میتوانید از مجوزهای گرانولار SQL Server در سطح پایگاه اطلاعاتی نهایت بهره را ببرید. در این قسمت از مقاله، ما یک نقش پایگاه اطلاعاتی تعریف شده توسط کاربر می سازیم و به وجه دیگر مجوزها پی می بریم. شما می توانید کنترل کنید که چه کسانی اجازه دارند عمل های مختلفی را بر روی آبجکت های خاص پایگاه اطلاعاتی انجام دهند.
در این مورد، کد با رفتن به پایگاه اطلاعاتی AdverntureWorks 2012 آغاز می شود و سپس نقش تعریف شده توسط کاربر ProdDataEntry را می سازد و Bonsai را به این نقش می افزاید.
USE AdventureWorks2012;
GO

CREATE ROLE ProdDataEntry AUTHORIZATION dbo;
ALTER ROLE ProdDataEntry ADD MEMBER Bonsai;
GO
سپس باید مجوزهایی را به این نقش واگذار کنیم و یک مجوز را نیز لغو خواهیم داد. ایده ای که در این کار نهفته این است که اعضای این نقش باید بتوانند رکوردها را در چند جدول در داخل طرح Production، درج و بروزرسانی کنند. اینجاست که موضوع کنترل مجوزهای داده شده به عمل ها مطرح می شود. دستورهای زیر مجوزهای INSERT و UPDATE را به جدول های Production.UnitMeasure و Production.ProductCategory و نیز مجوز SELECT را به جدول ProductCategory واگذار می کنند. قصد ما این بود که نشان دهیم چگونه می توانید عمل ها را بر روی داده های خود به شکل بسیار گرانولارتری کنترل نمائید.
GRANT INSERT ON Production.UnitMeasure TO ProdDataEntry;
GRANT UPDATE ON Production.UnitMeasure TO ProdDataEntry;

GRANT INSERT ON Production.ProductCategory TO ProdDataEntry;
GRANT UPDATE ON Production.ProductCategory TO ProdDataEntry;
GRANT SELECT ON Production.ProductCategory TO ProdDataEntry;
این کد سپس مجوز EXECUTE را به رویه ذخیره شده dbo.uspGetEmployeeManagers واگذار می کند، اما همین مجوز را از رویه dbo.uspGetManagerEmployees لغو می کند. این نشان می دهد که چگونه آبجکت های مختلف، مجوزهای مختلف دارند. به خاطر داشته باشید که اگر Bonsai از سوی اعضای نقش دیگر، مجوز EXECUTE را در uspGetManagerEmployees داشته باشد، می تواند این رویه را اجرا نماید. این نشان می دهد که چگونه Revoke با Deny متفاوت است.
GRANT EXECUTE ON dbo.uspGetEmployeeManagers TO ProdDataEntry;
REVOKE EXECUTE ON dbo.uspGetManagerEmployees TO ProdDataEntry;

زمانی که کد بعنوانBonsai اجرا می شود، می توانیم از کد لیست ۲ برای آزمایش مجوزها استفاده نمائیم. قبل از خواندن ادامه مقاله، کد را بخوانید تا ببینید آیا میتوانید بفهمید کدام دستورها موفق و کدام ناکام می ماند.
لیست ۲: کدی برای آزمایش مجوزهای ProdDataEntry نقش پایگاه اطلاعاتی تعریف شده توسط کاربر

EXECUTE AS USER = ‘Bonsai’;

— Snippet 1
INSERT INTO Production.UnitMeasure (UnitMeasureCode, Name)
VALUES (‘BAR’, ‘Standard Bar’);
— Snippet 2
SELECT * FROM Production.UnitMeasure WHERE UnitMeasureCode = ‘BAR’;

— Snipped 3
INSERT INTO Production.ProductCategory (Name)
VALUES (‘Navigation’);
— Snippet 4
SELECT * FROM Production.ProductCategory WHERE Name = ‘Navigation’;

— Snippet 5
INSERT INTO HumanResources.Department
(Name, GroupName)
VALUES
(‘Advertising’, ‘Sales and Marketing’);
GO

— Snippet 6
DECLARE @rc INT;
EXECUTE @rc = dbo.uspGetEmployeeManagers 113;
GO

— Snippet 7
DECLARE @rc INT;
EXECUTE @rc = dbo.uspGetManagerEmployees 113;
GO
REVERT;

تکه کد ۱ موفق می شود چرا که Bonsai دارای مجوز INSERT در جدول UnitMeasure است اما تکه کد ۲ ناکام می ماند چرا که Bonsai مجوز SELECT ندارد. و این کمی عجیب است اما هیچ چیز مانع انجام کارهایی که می توانید با مجوزها انجام دهید، نمی شود. تکه کد سوم و چهارم هر دو موفق هستند چرا که این نقش هر دو مجوز Insert و SELECT را در جدول ProductCategory دارد. تکه کد ۵ ناکام می ماند، چرا که این نقش هیچ مجوزی در جدول HumanResource.Department ندارد. تکه کد ۶ موفق است چرا که این نقش دارای مجوز EXECUTE در رویه ذخیره شده uspGetEmployeeManagers می باشد، اما تکه کد ۷ ناکام می ماند چرا که مجوز رویه uspGetManagerEmployees از قبل لغو شده بود.
SQL Server متادیتا یا فراداده های مربوط به مجوزها را در دسترس قرار می دهد و لیست ۳ روش هایی را نشان می دهد که می توانید به آن فراداده ها دسترسی پیدا کنید. اولین دستور، مجوزهایی که نقش ProdDataEntry در پایگاه اطلاعاتی AdventureWorks2012 پس از اجرای کد قبلی دارد را لیست می کند. سه دستور دیگر نشان می دهند که چگونه میتوانید از sys.fn_builtin_permissions برای دریافت لیست مجوزهای درونی در نمونه سرور، در سطح سرور، و در سطح پایگاه اطلاعاتی، استفاده نمائید. این یک روش فوق العاده برای یافتن تمام مجوزهایی است که در دسترس هستند. این مجوزها زیادند.
لیست ۳: کدی برای دسترسی به برخی از فراداده های مجوزها
USE AdventureWorks2012;
GO

SELECT D B_NAME() AS ‘Database’, p.name, p.type_desc, dbp.state_desc,
dbp.permission_name, so.name, so.type_desc
FROM sys.database_permissions dbp
LEFT JOIN sys.objects so ON dbp.major_id = so.object_id
LEFT JOIN sys.database_principals p ON dbp.grantee_principal_id = p.principal_id
WHERE p.name = ‘ProdDataEntry’
ORDER BY so.name, dbp.permission_name;

SELECT * FROM sys.fn_builtin_permissions(DEFAULT);
SELECT * FROM sys.fn_builtin_permissions(‘SERVER’) ORDER BY permission_name;
SELECT * FROM sys.fn_builtin_permissions(‘DATABASE’) ORDER BY permission_name;

پیش بروید و از مجوزها استفاده کنید
ایمنی موضوعی است که از SQL Server 2005 دست خوش یک تحول و تجدید نظر کلی گردید و ورژن های پس از آن هر یک با ویژگی های بهتری ساخته می شوند.
مجوزها بسیار گرانولارتر از نسخه های اولیه SQL Server هستند و شما میتوانید کنترل زیادی بر روی آنچه که افراد در نمونه سرور شما انجام می دهند، داشته باشید. وجود گزینه های مربوط به Principalها، آبجکت های Securable و مجوزها، درک موضوع واگذاری، لغو و رد مجوزها را کمی دشوار ساخته است. اما برای داشتن یک سرور پایگاه اطلاعاتی مطمئن و ایمن تر درک این موضوع بسیار حائز اهمیت است و باید گفت واگذاری مجوزهای سطح admin به نقش ها و یا کاربران برای راحت شدن کارها هرگز ایده خوبی نیست.
—————————
مهسا قنبری

نظر بدهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

It is main inner container footer text