راهنمای جامع و تخصصی Windows Privileges در SQL Server از مبانی تا پیاده‌سازی در معماری‌های Enterprise (نسخه ۲۰۲۶)

SQL Server تنها یک نرم‌افزار مدیریت پایگاه داده نیست که پس از نصب روی Windows بدون نیاز به تنظیمات تکمیلی آماده بهره‌برداری باشد. این موتور دیتابیس برای اجرای پایدار، مدیریت حافظه، دسترسی کنترل‌شده به فایل‌های Database، انجام عملیات Backup و Restore، تعامل با سرویس‌های سیستم‌عامل و استفاده صحیح از منابع سرور، به یک Security Context مناسب در Windows نیاز دارد.

. این موتور دیتابیس برای اجرای پایدار، مدیریت صحیح حافظه، دسترسی کنترل‌شده به فایل‌های Database، انجام عملیات Backup و Restore، برقراری ارتباط با سرویس‌های سیستم‌عامل و استفاده بهینه از منابع سرور، به یک بستر امنیتی مناسب در سطح Windows نیاز دارد.

بخشی از این بستر امنیتی توسط Windows Privileges یا مجوزهای سطح سیستم‌عامل فراهم می‌شود. این مجوزها مشخص می‌کنند Account مربوط به سرویس SQL Server چه قابلیت‌هایی در سطح سیستم‌عامل Windows دارد و چه عملیات‌هایی را می‌تواند انجام دهد  و چگونه می‌تواند با منابع مختلف سیستم تعامل کند.

تنظیم نادرست Windows Privileges می‌تواند باعث بروز مشکلات مختلفی در محیط‌های عملیاتی SQL Server شود؛ از کاهش کارایی در پردازش Queryهای سنگین و ایجاد فشار غیرضروری روی حافظه گرفته تا خطا در عملیات Backup، مشکل در اجرای سرویس‌ها، اختلال در سناریوهای High Availability مانند Failover Cluster و افزایش ریسک‌های امنیتی ناشی از اعطای دسترسی‌های بیش از نیاز.

به همین دلیل، مدیریت صحیح Windows Privileges باید به عنوان بخشی از طراحی استاندارد SQL Server در محیط‌های سازمانی در نظر گرفته شود. انتخاب Service Account مناسب، رعایت اصل Least Privilege و اختصاص دقیق مجوزهای مورد نیاز، نقش مهمی در افزایش امنیت، پایداری و Performance سرورهای SQL Server دارد.

مقدمه‌ای بر Windows Privileges و اهمیت آن در SQL Server

SQL Server فقط یک نرم‌افزار مدیریت پایگاه داده نیست که پس از نصب روی Windows بدون تنظیمات امنیتی خاص آماده استفاده باشد. این موتور دیتابیس برای اجرای صحیح، دسترسی به منابع سیستم‌عامل، مدیریت حافظه، کار با فایل‌های Database، انجام عملیات Backup و ارتباط با سرویس‌های مختلف، به یک Security Context مناسب در Windows نیاز دارد.

این Security Context شامل چند بخش مختلف است:

• Service Account که SQL Server با آن اجرا می‌شود
• Windows Privilegeهای اختصاص داده شده به Account
• Permissionهای مربوط به File System و Registry
• دسترسی‌های شبکه و Domain
• تنظیمات امنیتی اعمال شده از طریق Group Policy

Windows Privilegeها یکی از اجزای مهم این ساختار هستند. این مجوزها مشخص می‌کنند یک Account در سطح سیستم‌عامل چه قابلیت‌هایی دارد؛ برای مثال امکان قفل کردن صفحات حافظه، انجام عملیات مدیریتی روی Volumeها یا اجرای برخی عملیات خاص مرتبط با Processها.

بخش قابل توجهی از مشکلات عملیاتی SQL Server در محیط‌های سازمانی، تنها به تنظیمات داخلی Database Engine مربوط نمی‌شود و ممکن است ریشه در تنظیمات اشتباه سطح سیستم‌عامل داشته باشد. مواردی مانند کاهش Performance، خطا در ایجاد یا افزایش فایل‌های Database، مشکل در عملیات Backup، اختلال پس از Failover و حتی افزایش ریسک‌های امنیتی، می‌توانند نتیجه طراحی نادرست Service Account یا Windows Privileges باشند.

به همین دلیل، مدیریت صحیح Windows Privileges باید بخشی از طراحی استاندارد SQL Server در محیط‌های Enterprise باشد و مانند تنظیمات Database، Backup، High Availability و Performance Tuning با دقت مدیریت شود.

تعریف دقیق Windows Privilege

در مدل امنیتی Windows، Privilege به قابلیتی گفته می‌شود که به یک Account اجازه انجام یک عملیات خاص در سطح سیستم‌عامل را می‌دهد.

Privilegeها معمولاً در بخش User Rights Assignment ویندوز مدیریت می‌شوند و تعیین می‌کنند یک Account چه توانایی‌هایی در سطح سیستم دارد.

برای مثال:

• Lock Pages in Memory به یک Account اجازه می‌دهد صفحات حافظه مشخصی را در RAM نگه دارد.
• Perform Volume Maintenance Tasks امکان استفاده از Instant File Initialization را برای SQL Server فراهم می‌کند.
• Bypass Traverse Checking اجازه عبور از مسیرهای File System را بدون نیاز به مشاهده تمام پوشه‌های والد فراهم می‌کند.

Privilege با Permission تفاوت اساسی دارد.

Permission مشخص می‌کند یک Account روی یک Object مشخص چه کاری می‌تواند انجام دهد. برای مثال یک Service Account ممکن است روی مسیر زیر Permission نوشتن داشته باشد:

D:\SQLBackup

اما Privilege مشخص می‌کند همان Account در سطح سیستم‌عامل چه قابلیت‌هایی دارد.

به بیان ساده:

Permission درباره دسترسی به یک منبع مشخص است، اما Privilege درباره توانایی انجام یک عملیات خاص در سطح Windows است.

چرا SQL Server به Windows Privileges نیاز دارد؟

SQL Server به عنوان یک Windows Service اجرا می‌شود و برای تعامل با منابع سیستم‌عامل، نیازمند مجوزهای خاصی است. این مجوزها در لایه‌های مختلف عمل می‌کنند:

لایه‌های تعامل SQL Server با Windows

1. لایه فایل سیستم: دسترسی به فایل‌های MDF، NDF، LDF و Backup
2. لایه حافظه: مدیریت Buffer Pool و جلوگیری از Paging
3. لایه شبکه: برقراری ارتباط با سایر سرورها و Domain
4. لایه Process: اجرای Jobها، SSIS و Componentهای جانبی
5. لایه امنیتی: مدیریت Tokenها و Impersonation

اهمیت موضوع در معماری‌های Enterprise

در محیط‌های سازمانی بزرگ، انتخاب و پیکربندی صحیح Privilegeها اهمیت دوچندان پیدا می‌کند. یک تنظیم نادرست می‌تواند منجر به:

• نشت اطلاعات حساس از طریق Privilege Escalation
• اختلال در عملیات Backup و Recovery
• کاهش Performance به دلیل Paging شدن حافظه
• عدم امکان Failover صحیح در محیط‌های Cluster
• عدم انطباق با استانداردهای امنیتی مانند ISO 27001، PCI-DSS و SOC 2

انواع Service Account در SQL Server و ویژگی‌های امنیتی هرکدام

قبل از بررسی Privilegeها، باید بستر اجرای SQL Server را بشناسیم. SQL Server با یکی از انواع حساب‌های زیر اجرا می‌شود و هرکدام ویژگی‌های خاص خود را دارند.

Local System Account

Local System یکی از قدرتمندترین Contextهای اجرایی Windows است و معمولاً دسترسی گسترده‌ای روی سیستم محلی دارد.

ویژگی‌ها و معایب

• دسترسی کامل به منابع محلی
• هویت شبکه‌ای به عنوان Computer Account در Domain
• برای سناریوهای SQL Server Failover Cluster Instance انتخاب مناسبی نیست.
• ریسک امنیتی بسیار بالا در صورت نفوذ

Local Service Account

Local Service یک حساب داخلی با سطح دسترسی محدود است که برای سرویس‌هایی طراحی شده که نیاز به دسترسی گسترده به سیستم ندارند. در SQL Server معمولاً استفاده از Local Service مناسب نیست، زیرا SQL Server در بسیاری از سناریوهای سازمانی نیاز به ارتباط با منابع خارج از سیستم محلی دارد.

Network Service Account

Network Service هنگام دسترسی به منابع شبکه، هویت سیستم را استفاده می‌کند. این حساب نسبت به Local System محدودتر است، اما همچنان برای بسیاری از محیط‌های Enterprise انتخاب مناسبی نیست، مخصوصاً زمانی که چندین سرور، Domain Controller، Storage یا سرویس‌های وابسته وجود دارند.

Virtual Account

Virtual Accountها از Windows Server 2008 R2 معرفی شدند و برای ساده‌تر کردن مدیریت سرویس‌ها طراحی شدند. نمونه‌هایی مانند:

• NT SERVICE\MSSQLSERVER
• NT SERVICE\MSSQL$INSTANCE_NAME

مزایا و محدودیت‌ها

این حساب‌ها توسط Windows مدیریت می‌شوند و نیاز به مدیریت رمز عبور ندارند. برای محیط‌های ساده گزینه مناسبی هستند، اما محدودیت اصلی آن‌ها در سناریوهایی است که سرویس SQL Server باید با منابع خارجی یا چند سرور ارتباط داشته باشد زیرا در این معماری نیاز به هویت مشترک و قابل مدیریت بین Nodeها وجود دارد.

Managed Service Account (MSA) و Group MSA (gMSA)

در محیط‌های Enterprise مبتنی بر Active Directory، gMSA یکی از گزینه‌های مناسب برای مدیریت Service Accountها محسوب می‌شود.

مزایای اصلی gMSA

• مدیریت خودکار Password Rotation
• حذف نیاز به ذخیره رمز عبور سرویس
• کاهش خطای انسانی
• هماهنگی بهتر با سیاست‌های امنیتی سازمان
• مناسب برای سرویس‌هایی که روی چند سرور اجرا می‌شوند.

در معماری‌هایی مانند SQL Server Failover Cluster Instance، Always On Availability Group و سرویس‌های چند سروری، استفاده از gMSA می‌تواند مدیریت Service Account را ساده‌تر و امن‌تر کند.

Dedicated Domain Account

یکی دیگر از روش‌های رایج در سازمان‌ها، استفاده از یک Domain Account اختصاصی برای SQL Server Service است. در این روش معمولاً برای هر سرویس SQL Server یک حساب جداگانه ایجاد می‌شود:

• DOMAIN\svc_sql_prod
• DOMAIN\svc_sql_cluster

مزایا و چالش‌ها

مزایای این روش شامل کنترل دقیق دسترسی‌ها، امکان اعمال Group Policy، مدیریت ساده‌تر در محیط‌های بزرگ و قابلیت استفاده در سناریوهای Cluster است. اما باید توجه داشت که استفاده از Domain Account نیازمند مدیریت صحیح رمز عبور است و نگهداری Passwordهای ثابت و بدون Rotation می‌تواند یک ضعف امنیتی ایجاد کند.

مدیریت صحیح Service Account در SQL Server

یکی از نکات مهم در مدیریت Service Account این است که تغییر Account سرویس SQL Server نباید مستقیماً از طریق Windows Services انجام شود.

روش صحیح استفاده از SQL Server Configuration Manager است. این ابزار علاوه بر تغییر Account سرویس، تنظیمات مرتبط با SQL Server Service SID، مجوزهای مورد نیاز سرویس و وابستگی‌های مربوط به Instance را نیز مدیریت می‌کند.

تغییر مستقیم Service Account از مسیر:

services.msc

ممکن است باعث شود برخی Permissionهای مورد نیاز سرویس به درستی اعمال نشوند و مشکلاتی مانند:

• عدم دسترسی به فایل‌های Database
• خطا در راه‌اندازی سرویس
• مشکل در دسترسی به Registry
• خطا در سرویس‌های وابسته مانند SQL Server Agent

ایجاد شود.

بهترین روش:

SQL Server Configuration Manager
→ SQL Server Services
→ Properties
→ Log On

و سپس تغییر Service Account از همین بخش است.

جدول مقایسه‌ای انواع Service Account

اصل Least Privilege؛ ستون فقرات امنیت SQL Server

یکی از مهم‌ترین اصول امنیتی در طراحی SQL Server، اصل Least Privilege یا حداقل دسترسی است. بر اساس این اصل، Service Account باید فقط مجوزهایی را داشته باشد که برای اجرای صحیح SQL Server ضروری هستند.

اشتباهات رایج در محیط‌های عملیاتی

اعطای دسترسی‌های زیر یک طراحی نادرست محسوب می‌شود:

• Local Administrator
• Domain Administrator
• Full Control روی کل سیستم
• دسترسی‌های غیرضروری روی File System

فرآیند طراحی صحیح بر اساس Least Privilege

1. شناسایی نیازمندی‌ها: بررسی دقیق نیازمندی‌های SQL Server و سرویس‌های وابسته
2. مستندسازی: ثبت تمام Privilegeهای اختصاص داده شده
3. پیاده‌سازی: اعطای فقط مجوزهای ضروری
4. بازبینی دوره‌ای: بررسی منظم تنظیمات و حذف موارد غیرضروری
5. مانیتورینگ: رصد لاگ‌های امنیتی برای شناسایی رفتارهای غیرعادی

ارتباط Least Privilege با استانداردهای امنیتی

رعایت این اصل برای انطباق با استانداردهای زیر ضروری است:

• PCI-DSS: الزام به حداقل دسترسی برای سیستم‌های پردازش کارت
• ISO 27001: کنترل A.9.2 در مورد مدیریت دسترسی کاربران
• SOC 2: اصل Trust Service Criteria در مورد Security
• GDPR: حفاظت از داده‌های شخصی از طریق کنترل دسترسی

بررسی تخصصی SeBackupPrivilege

این Privilege بیشتر در ابزارهای Backup سطح سیستم‌عامل و محصولات Enterprise Backup کاربرد دارد و کنترل دسترسی بر اساس Permissionهای سرویس SQL Server روی مقصد Backup انجام می‌شود. این Privilege بیشتر در ابزارهای Backup سطح سیستم‌عامل و محصولات Enterprise Backup کاربرد دارد.

مفهوم SeBackupPrivilege در Windows

SeBackupPrivilege یک User Right در Windows است که برای Accountهایی طراحی شده که وظیفه پشتیبان‌گیری از سیستم را بر عهده دارند. این Privilege اجازه می‌دهد یک فرآیند بتواند فایل‌ها را برای عملیات Backup باز کند، حتی اگر Account مربوطه Permission معمولی Read روی آن فایل یا پوشه نداشته باشد.

کاربرد در ابزارهای Backup سازمانی

این رفتار برای ابزارهای Backup سازمانی اهمیت زیادی دارد، زیرا نرم‌افزار Backup باید بتواند از منابع مختلف سیستم نسخه پشتیبان تهیه کند. برای مثال یک Backup Operator ممکن است نیاز داشته باشد از فایل‌هایی Backup بگیرد که کاربران عادی اجازه مشاهده یا خواندن آن‌ها را ندارند.

ارتباط SeBackupPrivilege با SQL Server Backup

در SQL Server، عملیات Backup معمولاً توسط Database Engine انجام می‌شود. زمانی که دستور زیر اجرا می‌شود:

BACKUP DATABASE Sales
TO DISK = 'D:\Backup\Sales.bak'

فایل Backup توسط Process مربوط به SQL Server ایجاد می‌شود. بنابراین Accountای که سرویس SQL Server با آن اجرا می‌شود باید بتواند به مسیر مقصد Backup دسترسی داشته باشد.

تفاوت Permission فایل با Windows Privilege

یکی از اشتباهات رایج در مدیریت SQL Server این است که Permissionهای File System و Windows Privilegeها یکسان در نظر گرفته شوند. این دو مفهوم متفاوت هستند:

NTFS Permission

مشخص می‌کند یک Account در حالت عادی چه کاری روی یک فایل یا پوشه می‌تواند انجام دهد. برای مثال:

SQL Service Account → Write Permission روی پوشه Backup

Windows Privilege

مشخص می‌کند یک Account در شرایط خاص سیستم‌عامل چه توانایی‌هایی دارد. SeBackupPrivilege نمونه‌ای از همین نوع دسترسی است که برای دور زدن کنترل‌های معمول دسترسی در عملیات Backup طراحی شده است.

آیا SQL Server Service Account همیشه به SeBackupPrivilege نیاز دارد؟

خیر. در اکثر محیط‌های استاندارد SQL Server، اختصاص SeBackupPrivilege به Service Account ضروری نیست. روش معمول و پیشنهادی این است که برای مسیرهای مورد استفاده SQL Server، Permission مناسب NTFS تعریف شود:

D:\SQLBackup → SQL Server Service Account → Modify Permission

در این حالت SQL Server بدون نیاز به Privilege اضافی می‌تواند عملیات Backup و Restore را انجام دهد.

سناریوهایی که SeBackupPrivilege اهمیت پیدا می‌کند

استفاده از ابزارهای Backup سازمانی

بسیاری از نرم‌افزارهای Backup Enterprise برای انجام عملیات خود از Windows Backup Framework استفاده می‌کنند. این ابزارها ممکن است نیاز داشته باشند بدون تغییر Permissionهای فایل، از منابع مختلف Backup تهیه کنند.

Backup از محیط‌های بزرگ با ساختار Permission پیچیده

در سازمان‌های بزرگ، File Serverها و Storageها معمولاً دارای ساختارهای پیچیده Permission هستند. تغییر Permission برای هر عملیات Backup می‌تواند مدیریت را دشوار کند.

SQL Server Integration با سیستم‌های Backup خارجی

برخی معماری‌ها در کنار SQL Server از سیستم‌های Backup مرکزی استفاده می‌کنند. در این حالت معمولاً مسئولیت Backup فقط بر عهده SQL Server نیست و یک سرویس خارجی وظیفه مدیریت Backup را انجام می‌دهد.

ریسک امنیتی SeBackupPrivilege

با وجود اینکه نام این Privilege فقط به Backup اشاره می‌کند، از دید امنیتی یک مجوز حساس محسوب می‌شود. دارنده این Privilege می‌تواند محدودیت‌های معمول File System را در عملیات Backup نادیده بگیرد و به فایل‌هایی دسترسی پیدا کند که کاربران معمولی اجازه خواندن آن‌ها را ندارند.

بررسی وجود SeBackupPrivilege

برای بررسی Privilegeهای Account سرویس SQL Server می‌توان از ابزارهای مدیریتی Windows استفاده کرد:

Local Security Policy
  → Security Settings
    → Local Policies
      → User Rights Assignment
        → Back up files and directories

در محیط Domain، این تنظیم ممکن است از طریق Group Policy اعمال شده باشد و بررسی Local Policy به تنهایی کافی نباشد.

نکته مهم در محیط‌های Cluster

در SQL Server Failover Cluster Instance یا معماری‌های چند Node، باید مشخص شود Account دارای این Privilege روی تمام Nodeها تنظیم شده است. عدم هماهنگی بین Nodeها می‌تواند باعث شود یک عملیات Backup یا Maintenance روی یک Node موفق و روی Node دیگر با خطا مواجه شود.

بررسی تخصصی SeChangeNotifyPrivilege

SeChangeNotifyPrivilege یکی از Privilegeهای عمومی Windows است که در بسیاری از عملیات‌های File System مورد استفاده قرار می‌گیرد.

مفهوم Bypass Traverse Checking در Windows

برای درک SeChangeNotifyPrivilege ابتدا باید تفاوت بین مشاهده مسیر و دسترسی به فایل را بدانیم. فرض کنید ساختار زیر وجود دارد:

D:\SQLData\Production\Database1.mdf

برای رسیدن به فایل Database1.mdf، سیستم‌عامل باید از پوشه‌های زیر عبور کند:

• D:\SQLData\Production\Database1.mdf

در حالت معمول، یک کاربر ممکن است Permission مشاهده محتویات پوشه SQLData را نداشته باشد، اما اگر روی فایل نهایی دسترسی مناسب داشته باشد، با داشتن SeChangeNotifyPrivilege می‌تواند از مسیر عبور کند.

چرا SQL Server به SeChangeNotifyPrivilege نیاز دارد؟

اکثر Service Accountهای ویندوز به صورت پیش‌فرض این Privilege را دریافت می‌کنند و SQL Server نیز معمولاً از همین تنظیم پیش‌فرض استفاده می‌کند.

• باز کردن فایل‌های Database
• دسترسی به Transaction Log
• ایجاد فایل‌های موقت
• خواندن فایل‌های تنظیمات
• دسترسی به مسیرهای Backup
• ارتباط با فایل‌های Trace و Extended Events

وضعیت پیش‌فرض SeChangeNotifyPrivilege در Windows

برخلاف برخی Privilegeهای حساس مانند Lock Pages in Memory، SeChangeNotifyPrivilege در Windows به شکل پیش‌فرض برای بسیاری از حساب‌های سیستمی فعال است. گروه‌های پیش‌فرض مانند Administrators، Users، Local Service و Network Service معمولاً این حق کاربری را دارند.

حذف SeChangeNotifyPrivilege چه مشکلاتی ایجاد می‌کند؟

در بسیاری از سازمان‌ها برای افزایش امنیت، مدیران سیستم اقدام به محدود کردن User Rights Assignment می‌کنند. حذف SeChangeNotifyPrivilege از SQL Server Service Account ممکن است باعث مشکلاتی مانند:

• خطا در باز کردن فایل‌های Database
• مشکل در دسترسی به مسیرهای Nested
• شکست برخی عملیات Maintenance
• خطاهای مربوط به File Access

تفاوت SeChangeNotifyPrivilege با Permissionهای NTFS

یکی از موارد مهم در مدیریت SQL Server این است که SeChangeNotifyPrivilege جایگزین Permissionهای فایل نیست. برای مثال، اگر SQL Server Service Account روی مسیر D:\SQLData هیچ Permissionای نداشته باشد، داشتن SeChangeNotifyPrivilege باعث نمی‌شود بتواند فایل‌های دیتابیس را باز کند. این Privilege فقط اجازه عبور از مسیرها را فراهم می‌کند.

SeChangeNotifyPrivilege در SQL Server Failover Cluster Instance

در محیط‌های FCI، اهمیت این Privilege بیشتر می‌شود. اگر تنظیمات User Rights Assignment بین Nodeها متفاوت باشد، ممکن است سرویس روی یک Node بدون مشکل اجرا شود اما پس از Failover روی Node دیگر با خطای دسترسی مواجه شود.

بررسی تخصصی SeIncreaseQuotaPrivilege

یکی از Windows Privilegeهایی که در برخی سناریوهای خاص SQL Server اهمیت پیدا می‌کند، SeIncreaseQuotaPrivilege است. این مجوز در Windows با عنوان Adjust memory quotas for a process شناخته می‌شود و به یک Process یا Service اجازه می‌دهد سهمیه‌های مرتبط با مصرف منابع سیستم‌عامل را برای یک Process دیگر تنظیم کند.

مفهوم Quota در Windows

Windows برای کنترل مصرف منابع توسط Processها مکانیزم‌های مختلفی دارد. Quota در اینجا به معنی محدودیت یا سهمیه‌ای است که سیستم‌عامل برای برخی منابع در نظر می‌گیرد. هدف از وجود Quota جلوگیری از این است که یک Process بتواند تمام منابع سیستم را بدون کنترل مصرف کند.

منابع تحت کنترل Quota

• حافظه‌های مرتبط با Kernel Objectها
• Handleها
• Pageهای تخصیص داده شده
• منابع داخلی مدیریت‌شده توسط Windows

آیا SQL Server Service Account به SeIncreaseQuotaPrivilege نیاز دارد؟

در بیشتر نصب‌های استاندارد SQL Server، پاسخ منفی است. SQL Server Database Engine معمولاً برای اجرای Query، مدیریت Buffer Pool، پردازش Transactionها و کار با فایل‌های Database نیازی به این Privilege ندارد.

تفاوت مدیریت Memory در SQL Server و Windows Quota

یکی از اشتباهات رایج این است که مشکلات حافظه SQL Server با افزایش Privilegeهای Windows حل شود. در حالی که این دو موضوع متفاوت هستند:

مدیریت حافظه در SQL Server

SQL Server Memory Engine تصمیم می‌گیرد:

• چه مقدار حافظه برای Buffer Pool استفاده شود
• چه مقدار برای Execution Planها اختصاص داده شود
• چه زمانی Memory آزاد شود

مدیریت Quota در Windows

Windows Quota مربوط به محدودیت‌های سطح سیستم‌عامل است. اضافه کردن SeIncreaseQuotaPrivilege باعث بهبود عملکرد SQL Server نمی‌شود.

سناریوهای خاص مرتبط با SQL Server

SQL Server Agent و اجرای Jobهای پیچیده

SQL Server Agent برای اجرای Jobها از Subsystemهای مختلف استفاده می‌کند:

• CmdExec
• PowerShell
• SSIS Package
• Replication Agent

در این شرایط، Processهایی خارج از Database Engine ایجاد می‌شود. اگر اجرای این Processها نیازمند تغییر Quota یا مدیریت خاص منابع باشد، باید بررسی شود که کدام Account مسئول اجرای آن بخش است.

SQL Server Integration Services

در محیط‌هایی که SSIS استفاده می‌شود، Packageها ممکن است خارج از Process اصلی SQL Server اجرا شوند. در این معماری‌ها، Service Account مربوط به SSIS یا Agent باید جداگانه بررسی شود.

تفاوت SeIncreaseQuotaPrivilege با Lock Pages in Memory

گاهی این دو Privilege به دلیل ارتباط با Memory اشتباه گرفته می‌شوند. اما کاربرد آن‌ها کاملاً متفاوت است:

• SeIncreaseQuotaPrivilege: برای مدیریت سهمیه منابع Process در Windows استفاده می‌شود
• Lock Pages in Memory: برای جلوگیری از Paging شدن حافظه اختصاص داده شده به SQL Server Buffer Pool استفاده می‌شود

بررسی تخصصی SeCreateTokenPrivilege

در میان Windows Privilegeهای موجود در سیستم‌عامل، برخی مجوزها ارتباط مستقیمی با مدیریت هویت و امنیت Processها دارند. SeCreateTokenPrivilege یکی از حساس‌ترین User Rightهای Windows محسوب می‌شود که وظیفه آن ایجاد Security Token جدید برای Processها است.

مفهوم Security Token در Windows

در Windows، هر Process هنگام اجرا دارای یک Token است که مشخص می‌کند Process با چه هویتی اجرا شده، چه Permissionهایی دارد و به چه منابعی می‌تواند دسترسی پیدا کند. این Token شامل اطلاعاتی مانند موارد زیر است:

• شناسه کاربر یا Service Account
• گروه‌های امنیتی عضو
• Privilegeهای فعال
• سطح Integrity
• محدودیت‌های امنیتی

عملکرد SeCreateTokenPrivilege

SeCreateTokenPrivilege با عنوان Create a token object در Windows شناخته می‌شود. این مجوز اجازه می‌دهد یک Account بتواند Security Token جدید ایجاد کند. ایجاد Token جدید یک عملیات بسیار حساس است، زیرا Token تعیین می‌کند یک Process با چه سطح دسترسی اجرا شود.

آیا SQL Server به SeCreateTokenPrivilege نیاز دارد؟

خیر. SQL Server Database Engine برای عملکرد عادی خود به این Privilege نیاز ندارد. عملیات اصلی SQL Server مانند اجرای Query، مدیریت Buffer Pool، پردازش Transaction، مدیریت Lockها، خواندن و نوشتن فایل‌های Database و اجرای Stored Procedureها نیازی به ایجاد Security Token جدید ندارند.

تفاوت SeCreateTokenPrivilege با Impersonate

یکی از مواردی که باعث اشتباه در این حوزه می‌شود، شباهت مفهومی بین ایجاد Token و Impersonation است:

• SeCreateTokenPrivilege: مربوط به ایجاد Token جدید است
• Impersonate a client after authentication: مربوط به استفاده از هویت دریافت شده از یک Client است

ریسک امنیتی SeCreateTokenPrivilege

این Privilege در دسته مجوزهای حساس Windows قرار می‌گیرد. اگر یک حساب سرویس دارای این مجوز باشد و یک آسیب‌پذیری در آن سرویس وجود داشته باشد، مهاجم ممکن است بتواند از این قابلیت برای افزایش سطح دسترسی استفاده کند.

بررسی تخصصی SeAssignPrimaryTokenPrivilege

SeAssignPrimaryTokenPrivilege یکی از Windows Privilegeهایی است که ارتباط مستقیمی با نحوه اجرای Processها در Windows دارد. این مجوز به یک Account اجازه می‌دهد Primary Token یک Process را تغییر دهد یا یک Token مشخص را به عنوان هویت اصلی یک Process قرار دهد.

مفهوم Primary Token در Windows

هر Process در Windows هنگام اجرا دارای یک Primary Token است. این Token مشخص می‌کند:

• Process با کدام Account اجرا شده است
• چه گروه‌های امنیتی دارد
• چه Privilegeهایی در اختیار آن قرار گرفته است
• به چه منابعی اجازه دسترسی دارد

عملکرد SeAssignPrimaryTokenPrivilege

این Privilege در Windows با عنوان Replace a process level token شناخته می‌شود. وظیفه اصلی آن اجازه دادن به یک Account برای جایگزین کردن Primary Token یک Process است. این قابلیت معمولاً در سرویس‌هایی استفاده می‌شود که نیاز دارند Processهای دیگری را با یک هویت متفاوت ایجاد کنند.

تفاوت Primary Token و Impersonation Token

در Windows دو نوع Token مهم وجود دارد:

Primary Token

هویت اصلی یک Process را مشخص می‌کند.

Impersonation Token

زمانی استفاده می‌شود که یک Thread موقتاً با هویت کاربر دیگری اجرا شود. SQL Server در برخی سناریوها مانند Windows Authentication و Delegation ممکن است با مفهوم Impersonation درگیر شود، اما این موضوع به معنی نیاز داشتن Service Account به SeAssignPrimaryTokenPrivilege نیست.

سناریوهای خاص SQL Server Agent

SQL Server Agent یکی از سرویس‌هایی است که بیشتر از Database Engine با اجرای Processهای جانبی درگیر است. برای مثال اجرای PowerShell Script، Command Line، SSIS Package و ابزارهای مدیریتی خارجی. در این حالت Processهای دیگری توسط Agent ایجاد می‌شود.

راهکار صحیح

راهکار صحیح معمولاً استفاده از Proxy Account، Credential یا حساب سرویس جداگانه است، نه اضافه کردن Privilegeهای حساس به Account اصلی SQL Server Agent.

ریسک امنیتی SeAssignPrimaryTokenPrivilege

این Privilege در دسته مجوزهای حساس Windows قرار می‌گیرد. تغییر Primary Token می‌تواند باعث شود یک Process با هویت متفاوت اجرا شود. در محیط‌های Enterprise، اعطای این مجوز به حساب‌های عمومی یا Service Accountهای کاربردی می‌تواند باعث افزایش ریسک Privilege Escalation شود.

بررسی تخصصی SeLockMemoryPrivilege (Lock Pages in Memory)

یکی از مهم‌ترین و پرکاربردترین Windows Privilegeها در محیط SQL Server، SeLockMemoryPrivilege یا همان Lock Pages in Memory است. این مجوز نقش حیاتی در Performance سرورهای SQL Server سازمانی ایفا می‌کند.

مفهوم Paging در Windows

Windows برای مدیریت حافظه فیزیکی، از تکنیک Paging استفاده می‌کند. در این روش، بخشی از حافظه اختصاص داده شده به Processها ممکن است به فایل Pagefile.sys روی دیسک منتقل شود. این عملیات که Paging Out نامیده می‌شود، می‌تواند تأثیر منفی شدیدی بر Performance سرورهای دیتابیس بگذارد.

چرا SQL Server به Lock Pages in Memory نیاز دارد؟

SQL Server از حافظه برای موارد زیر استفاده می‌کند:

• Buffer Pool: ذخیره صفحات داده برای دسترسی سریع
• Plan Cache: نگهداری Execution Planها
• Procedure Cache: نگهداری Stored Procedureهای کامپایل شده
• Workspace Memory: برای عملیات Sort و Hash

در شرایط Memory Pressure، Windows ممکن است برخی صفحات حافظه Processها را مدیریت کند که می‌تواند روی رفتار SQL Server اثر بگذارد.

چه زمانی Lock Pages in Memory ضروری است؟

این Privilege در شرایط زیر توصیه می‌شود:

• مخصوصاً در سرورهای دارای حافظه بالا، محیط‌های OLTP حساس و سیستم‌هایی که Memory Pressure دارند.
• محیط‌های OLTP با بار کاری سنگین
• سرورهایی که Response Time حساس دارند
• محیط‌هایی که Memory Pressure به صورت دوره‌ای رخ می‌دهد

نحوه فعال‌سازی Lock Pages in Memory

مراحل گام‌به‌گام

1. باز کردن Local Security Policy
2. رفتن به مسیر: Security Settings → Local Policies → User Rights Assignment
3. پیدا کردن گزینه Lock pages in memory
4. اضافه کردن Service Account مربوط به SQL Server
5. Restart سرویس SQL Server Instance

بررسی فعال‌سازی از طریق SQL Server Error Log

پس از فعال‌سازی، باید در SQL Server Error Log به دنبال پیام زیر بگردید:

Using locked pages for buffer pool.

اگر این پیام وجود نداشته باشد، یعنی Privilege به درستی اعمال نشده است.

ارتباط با Large Page Support

در SQL Serverهای مدرن، امکان استفاده از Large Pages نیز وجود دارد که می‌تواند Performance را بیشتر بهبود دهد.

Trace Flag 834 مربوط به Large Pages است، اما:

• همیشه توصیه نمی‌شود
• روی همه Workloadها مفید نیست
• ممکن است باعث مشکلات Memory Allocation شود

نباید کنار Lock Pages به شکل Best Practice عمومی بیاید.

بررسی تخصصی SeManageVolumePrivilege (Perform Volume Maintenance Tasks)

SeManageVolumePrivilege یا Perform Volume Maintenance Tasks یکی دیگر از Privilegeهای مهم برای SQL Server است که تأثیر مستقیمی بر Performance عملیات ایجاد فایل دارد.

مفهوم Instant File Initialization (IFI)

وقتی SQL Server یک فایل دیتابیس یا لاگ جدید ایجاد می‌کند یا فایل موجودی را گسترش می‌دهد، به صورت پیش‌فرض باید کل فضای اختصاص داده شده را با صفر پر کند (Zero Initialization). این عملیات می‌تواند برای فایل‌های بزرگ زمان‌بر باشد.

Instant File Initialization این امکان را می‌دهد که SQL Server بدون پر کردن فایل با صفر، فضای مورد نیاز را اختصاص دهد. این کار باعث تسریع چشمگیر عملیات زیر می‌شود:

• ایجاد Database جدید
• افزایش اندازه فایل‌های Data موجود (MDF و NDF)
• ایجاد یا افزایش فایل‌های Database مربوط به TempDB
• IFI می‌تواند روی برخی عملیات Restore که شامل ایجاد فایل‌های Data هستند تأثیرگذار باشد، اما رفتار آن به نوع عملیات Restore و شرایط محیط بستگی دارد.

ارتباط با SeManageVolumePrivilege

برای فعال‌سازی IFI، Service Account مربوط به SQL Server باید Privilege Perform Volume Maintenance Tasks را داشته باشد. بدون این مجوز، SQL Server مجبور است از روش سنتی Zero Initialization استفاده کند.

ملاحظات امنیتی Instant File Initialization

Instant File Initialization باعث می‌شود SQL Server برای فایل‌های Data، به جای Zero Initialization، فضای مورد نیاز را سریع‌تر اختصاص دهد. این موضوع می‌تواند زمان ایجاد Database، افزایش حجم فایل‌های Data و برخی عملیات Restore را به شکل قابل توجهی کاهش دهد.

با این حال، چون فضای اختصاص داده شده برای فایل‌های Data با صفر بازنویسی نمی‌شود، در برخی سناریوهای خاص ممکن است اطلاعات باقی‌مانده از داده‌های قبلی روی Storage قابل بازیابی باشد.

به همین دلیل در محیط‌هایی با الزامات امنیتی بسیار سخت‌گیرانه، فعال‌سازی IFI باید با سیاست‌های امنیتی سازمان هماهنگ شود.

نکته مهم:

IFI روی فایل‌های Data مانند MDF و NDF اعمال می‌شود. فایل‌های Transaction Log با پسوند LDF همچنان طبق مکانیزم معمول Initialize می‌شوند، زیرا ساختار Log برای تضمین قابلیت Recovery و حفظ یکپارچگی Transactionها نیازمند فرآیند جداگانه است.

نحوه فعال‌سازی Perform Volume Maintenance Tasks

1. باز کردن Local Security Policy
2. رفتن به مسیر: Security Settings → Local Policies → User Rights Assignment
3. پیدا کردن گزینه Perform volume maintenance tasks
4. اضافه کردن Service Account مربوط به SQL Server
5. Restart سرویس SQL Server

بررسی فعال‌سازی IFI

برای بررسی وضعیت IFI می‌توان از DMV زیر استفاده کرد:

SELECT SERVERPROPERTY('IsInstantFileInitializationEnabled') AS IFI_Status;

بررسی تخصصی SeProfileSingleProcessPrivilege

SeProfileSingleProcessPrivilege یکی از Privilegeهای کمتر شناخته‌شده است که در سناریوهای خاص SQL Server اهمیت پیدا می‌کند.

کاربرد این Privilege

این مجوز به یک Account اجازه می‌دهد اطلاعات Performance مربوط به یک Process خاص را جمع‌آوری کند. این قابلیت برای ابزارهای Monitoring و Profiling استفاده می‌شود.

ارتباط با SQL Server

SQL Server به صورت پیش‌فرض به این Privilege نیاز ندارد. اما در شرایط زیر ممکن است ضروری شود:

• استفاده از ابزارهای Profiling سطح پایین
• جمع‌آوری Performance Counterهای خاص
• استفاده از برخی ابزارهای Third-party Monitoring

توصیه کلی

در اکثر محیط‌ها، اعطای این Privilege به SQL Server Service Account ضروری نیست و باید فقط در صورت نیاز واقعی و مستند شده، اختصاص داده شود.

جدول مقایسه‌ای جامع Privilegeها

برای درک بهتر و تصمیم‌گیری سریع‌تر، جدول زیر تمام Privilegeهای بررسی شده را مقایسه می‌کند:

پیاده‌سازی در معماری‌های FCI و Always On

در معماری‌های High Availability مانند Failover Cluster Instance (FCI) و Always On Availability Group، مدیریت Privilegeها پیچیدگی بیشتری پیدا می‌کند.

چالش‌های خاص FCI

در FCI، SQL Server ممکن است بین Nodeهای مختلف جابه‌جا شود. بنابراین:

• تمام Privilegeها باید روی تمام Nodeها به صورت یکسان تنظیم شوند
• Service Account باید روی تمام Nodeها دسترسی‌های لازم را داشته باشد
• Group Policy باید به گونه‌ای تنظیم شود که تغییرات روی تمام Nodeها اعمال شود

ملاحظات Always On Availability Group

در AG، هر Instance به صورت جداگانه اجرا می‌شود اما نیاز به ارتباط با سایر Instanceها دارد. بنابراین:

• Service Account باید دسترسی شبکه‌ای مناسب داشته باشد
• Endpointها نیازمند تنظیمات خاص امنیتی هستند
• Privilegeهای مرتبط با شبکه باید به دقت مدیریت شوند

بهترین روش برای محیط‌های Cluster

1. استفاده از gMSA برای مدیریت متمرکز
2. اعمال تنظیمات از طریق Group Policy
3. مستندسازی تمام Privilegeها
4. بازبینی دوره‌ای تنظیمات روی تمام Nodeها
5. تست Failover پس از هر تغییر امنیتی

چک‌لیست امنیتی و عملیاتی

این چک‌لیست را می‌توانید برای ارزیابی وضعیت Privilegeها در سرورهای SQL Server خود استفاده کنید:

پایه

• Service Account از نوع مناسب (gMSA یا Dedicated Domain) است
• Service Account عضو گروه Administrators نیست
• SeChangeNotifyPrivilege فعال است
• SeLockMemoryPrivilege فعال شده است (برای سرورهای با RAM بالا)
• SeManageVolumePrivilege فعال شده است (برای IFI)
• SeCreateTokenPrivilege اختصاص داده نشده است
• SeAssignPrimaryTokenPrivilege اختصاص داده نشده است

پیشرفته

• تمام Privilegeها مستند شده‌اند
• تنظیمات از طریق Group Policy مدیریت می‌شوند
• در محیط Cluster، تنظیمات روی تمام Nodeها یکسان است
• لاگ‌های امنیتی به صورت دوره‌ای بررسی می‌شوند
• فرآیند Password Rotation برای Domain Accountها تعریف شده است
• تست Failover پس از تغییرات امنیتی انجام شده است

انطباق با استانداردها

• اصل Least Privilege رعایت شده است
• تغییرات امنیتی ثبت و قابل ردیابی هستند
• بازبینی دوره‌ای (حداقل هر ۶ ماه) انجام می‌شود
• مستندات امنیتی به‌روز هستند

عیب‌یابی (Troubleshooting) مشکلات رایج

در این بخش به بررسی مشکلات رایج و راه‌حل‌های آن‌ها می‌پردازیم.

مشکل: Backup با خطای Access Denied مواجه می‌شود

علت احتمالی

• عدم دسترسی Service Account به مسیر Backup
• عدم وجود SeBackupPrivilege (در سناریوهای خاص)

راه‌حل

1. بررسی NTFS Permission روی مسیر Backup
2. اعطای Modify Permission به Service Account
3. در صورت نیاز، بررسی SeBackupPrivilege

مشکل: Performance پایین پس از Failover

علت احتمالی

• عدم یکسان‌سازی Lock Pages in Memory بین Nodeها
• عدم یکسان‌سازی سایر Privilegeها

راه‌حل

1. بررسی Privilegeها روی Node فعلی و قبلی
2. یکسان‌سازی تنظیمات از طریق Group Policy
3. Restart سرویس SQL Server

مشکل: خطای Access Denied هنگام ایجاد فایل

علت احتمالی

• عدم فعال‌سازی IFI
• عدم وجود SeManageVolumePrivilege

راه‌حل

1. فعال‌سازی Perform Volume Maintenance Tasks
2. Restart سرویس SQL Server
3. بررسی فعال‌سازی IFI از طریق DMV

مشکل: خطاهای مربوط به دسترسی به فایل‌های Database

علت احتمالی

• حذف SeChangeNotifyPrivilege
• تنظیمات نادرست NTFS Permission

راه‌حل

1. بررسی وجود SeChangeNotifyPrivilege
2. بررسی NTFS Permission روی مسیرهای Database
3. بررسی Group Policyهای اعمال شده

مشکل: SQL Server Agent نمی‌تواند Job اجرا کند

علت احتمالی

• تنظیمات نادرست Proxy Account
• اعطای Privilegeهای اضافی به Service Account به جای استفاده از Proxy

راه‌حل

1. بررسی تنظیمات Proxy Account
2. استفاده از Credential برای عملیات خاص
3. حذف Privilegeهای غیرضروری از Service Account

سوالات متداول (FAQ)

آیا SQL Server Service Account باید عضو گروه Administrators باشد؟
خیر. این یک اشتباه رایج و خطرناک است. Service Account باید فقط Privilegeهای ضروری را داشته باشد و عضویت در Administrators یک نقض جدی اصل Least Privilege محسوب می‌شود.

تفاوت بین Permission و Privilege چیست؟
Permission در سطح Objectها (فایل، پوشه، Registry) تعریف می‌شود و مشخص می‌کند یک Account چه کاری می‌تواند روی آن Object انجام دهد. Privilege در سطح سیستم‌عامل تعریف می‌شود و توانایی‌های کلی یک Account را مشخص می‌کند.

آیا می‌توانم از Virtual Account برای SQL Server Cluster استفاده کنم؟
خیر. Virtual Account برای محیط‌های Standalone مناسب است. برای Cluster باید از gMSA یا Dedicated Domain Account استفاده کنید.

چگونه بفهمم Lock Pages in Memory فعال است؟
SQL Server Error Log را بررسی کنید. اگر پیام “Using locked pages for buffer pool” را مشاهده کردید، یعنی این قابلیت فعال است.

آیا IFI برای فایل‌های لاگ نیز فعال می‌شود؟
خیر. IFI فقط برای فایل‌های داده (MDF, NDF) فعال می‌شود. فایل‌های لاگ (LDF) به دلایل امنیتی همیشه Zero Initialization می‌شوند.

چند بار باید Privilegeها را بازبینی کنم؟
توصیه می‌شود حداقل هر ۶ ماه یک بار و پس از هر تغییر عمده در زیرساخت، Privilegeها بازبینی شوند.

آیا gMSA برای همه محیط‌ها مناسب است؟
gMSA برای اکثر محیط‌های Enterprise مناسب است، اما نیاز به Windows Server 2012 R2 یا بالاتر و Active Directory مناسب دارد. برای محیط‌های ساده و Standalone، Virtual Account نیز گزینه مناسبی است.

اگر Service Account را تغییر دهم، چه Privilegeهایی باید منتقل شوند؟
تمام Privilegeهایی که به Account قبلی اختصاص داده شده بود باید به Account جدید منتقل شوند. این شامل Lock Pages in Memory، Perform Volume Maintenance Tasks و سایر Privilegeهای ضروری است.

آیا می‌توانم Privilegeها را از طریق Script مدیریت کنم؟
بله، با استفاده از ابزارهایی مانند PowerShell، secedit و Group Policy می‌توان Privilegeها را به صورت خودکار مدیریت کرد. این روش برای محیط‌های بزرگ بسیار توصیه می‌شود.

تأثیر Lock Pages in Memory بر Performance چقدر است؟
در سرورهای با RAM بالا و بار کاری سنگین، تأثیر آن می‌تواند بسیار چشمگیر باشد. در برخی موارد، بهبود Performance تا ۴۰٪ مشاهده شده است.

نتیجه‌گیری

مدیریت صحیح Windows Privileges در SQL Server یکی از ارکان اصلی امنیت و Performance در محیط‌های Enterprise است. در این مقاله پیلار، به صورت جامع تمام جنبه‌های این موضوع را بررسی کردیم:

• انواع Service Account و ویژگی‌های هرکدام
• اصل Least Privilege و اهمیت آن
• بررسی تخصصی تمام Privilegeهای مرتبط با SQL Server
• پیاده‌سازی در معماری‌های FCI و Always On
• چک‌لیست‌های امنیتی و عملیاتی
• عیب‌یابی مشکلات رایج

گام‌های عملی برای شروع

1. چک‌لیست امنیتی این مقاله را دانلود و روی سرورهای خود پیاده کنید
2. Privilegeهای فعلی را مستند کنید
3. موارد غیرضروری را حذف کنید
4. Privilegeهای ضروری مانند Lock Pages in Memory را فعال کنید
5. فرآیند بازبینی دوره‌ای را تعریف کنید
6. تیم عملیاتی را آموزش دهید

برای مطالعه عمیق‌تر در هر یک از موضوعات مطرح شده، می‌توانید به مقالات تخصصی مرتبط در بخش‌های مختلف سایت مراجعه کنید. این مقاله به عنوان یک Hub مرکزی، شما را به منابع تخصصی‌تر هدایت می‌کند.

آیا تنظیمات امنیتی SQL Server شما مطابق استانداردهای Enterprise است؟

بسیاری از مشکلات Performance، خطاهای دسترسی و اختلالات عملیاتی SQL Server از تنظیمات نادرست Service Account و Windows Privileges ناشی می‌شوند.

تیم لاندا می‌تواند وضعیت امنیتی و عملیاتی SQL Server شما را بررسی کرده، تنظیمات Privilegeها، Service Accountها و دسترسی‌های سطح سیستم‌عامل را ارزیابی و بر اساس Best Practiceهای مایکروسافت بهینه‌سازی کند.

برای بررسی وضعیت SQL Server خود و دریافت مشاوره تخصصی با کارشناسان لاندا در تماس ✆ باشید.