فصل 22 از 24 درس 1 از 1

امنیت در SQL Server

امنیت در SQL Server

بخشی از آموزش جامع SQL Server

محتوای درس امنیت در SQL Server

SQL Server | Login، User، Role و Least Privilege

امنیت SQL Server از Authentication در سطح Instance و Authorization در سطح Database/Object تشکیل می‌شود. Application Runtime باید تنها Permissionهای لازم برای عملیات واقعی خود را دریافت کند.

متن این فصل با رویکرد مرجع فنی و قابل استفاده در پروژه واقعی تنظیم شده است؛ مثال‌ها در امتداد مدل StoreDb نوشته شده‌اند و اصطلاحات اصلی SQL Server و T-SQL به‌صورت یکدست به‌کار می‌روند.

1. مفاهیم و قراردادهای اصلی

امنیت SQL Server از Authentication در سطح Instance و Authorization در سطح Database/Object تشکیل می‌شود. Application Runtime باید تنها Permissionهای لازم برای عملیات واقعی خود را دریافت کند.

در طراحی پایگاه داده، Syntax تنها بخشی از مسئله است. نوع داده، Constraint، الگوی دسترسی، Transaction و هزینه اجرای Query باید هم‌زمان با نیاز Domain در نظر گرفته شوند.

مفهومکارکرد
Loginهویت سطح Server
Userهویت داخل Database
Roleگروه Permission
GRANTاعطای مجوز
DENYمنع صریح
REVOKEحذف Grant/Deny

2. ساختار و Syntax پایه

Login و User اختصاصی برای Application ساخته می‌شود و Permission از طریق Role اعطا می‌گردد. حساب Migration/DBA از Runtime جداست و Connection با Encryption مناسب انجام می‌شود.

CREATE ROLE StoreAppReader;
GO

GRANT SELECT ON SCHEMA::catalog TO StoreAppReader;
GRANT SELECT ON SCHEMA::sales TO StoreAppReader;
GO

ALTER ROLE StoreAppReader ADD MEMBER StoreAppUser;

3. سناریوی StoreDb

اگر Application فقط Procedureهای مشخص را اجرا می‌کند، EXECUTE روی همان Procedureها اعطا و DML مستقیم Tableها محدود می‌شود. این طراحی سطح حمله را کاهش می‌دهد.

نمونه‌های این فصل بر مدل فروشگاهی StoreDb بنا شده‌اند تا ارتباط مفاهیم میان فصل‌ها حفظ شود و Queryها در یک Context یکپارچه قابل بررسی باشند.

GRANT EXECUTE ON dbo.usp_GetProductById TO StoreAppRole;
GRANT EXECUTE ON dbo.usp_CreateOrder TO StoreAppRole;

DENY DELETE ON sales.Customers TO StoreAppRole;

4. اصول طراحی و Performance

طراحی پایدار باید هم صحت داده و هم هزینه اجرای عملیات را پوشش دهد. انتخاب ساده‌تر زمانی ترجیح دارد که Contract داده را روشن‌تر و رفتار Optimizer را قابل پیش‌بینی‌تر نگه دارد.

  • Least Privilege پیشفرض باشد.
  • Credential Runtime از Migration جدا شود.
  • Permissionها از طریق Role مدیریت شوند.
  • TLS و Backup Protection بخشی از Security باشند.

5. خطاهای رایج و نکات ایمنی

دستورهای SQL می‌توانند مستقیماً داده و ساختار را تغییر دهند؛ بنابراین بازبینی Context، تعداد Rowهای هدف و اثر Transaction قبل از اجرای تغییرات اهمیت عملی دارد.

  • اجرای Application با sa یا sysadmin.
  • Password داخل Source Code.
  • GRANT CONTROL برای حل سریع Permission Error.
  • فرض اینکه Dynamic Data Masking معادل Encryption است.

6. چک‌لیست نهایی فصل

  • Login/User/Role Scope درست است.
  • Runtime حداقل Permission را دارد.
  • حساب‌های حساس جدا شده‌اند.
  • Connection Encryption و Secret Storage بررسی شده‌اند.

7. جمع‌بندی

خروجی این فصل باید به تصمیمی قابل اتکا در طراحی یا Query منجر شود؛ صحت داده، قابلیت نگهداری و رفتار Performance سه معیار ثابت برای ارزیابی نمونه‌ها هستند.