SQL Server Service Account چیست؟ بررسی کامل Network Service، Local System، gMSA و Virtual Account

چرا SQL Server Service Account اهمیت دارد؟

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

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

بسیاری از مدیران سیستم و حتی برخی مدیران پایگاه داده، هنگام نصب SQL Server تنها به این موضوع توجه می‌کنند که سرویس اجرا شود و اتصال به Database Engine برقرار باشد. اما انتخاب نادرست Service Account می‌تواند در آینده مشکلات جدی ایجاد کند، از جمله:

• خطا در اجرای Backup روی مسیرهای شبکه
• مشکل در Kerberos Authentication
• اختلال در Always On Availability Group
• مشکل در Failover Cluster
• افزایش سطح دسترسی غیرضروری
• ایجاد ریسک امنیتی در صورت نفوذ به SQL Server
• مشکل در مدیریت Password سرویس‌ها

در معماری‌های قدیمی، بسیاری از نصب‌های SQL Server با حساب‌هایی مانند Local System یا یک حساب Domain Administrator انجام می‌شدند. این روش‌ها اگرچه ممکن است در کوتاه‌مدت کار کنند، اما با اصول امنیتی مدرن مانند Least Privilege سازگار نیستند.

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

• حداقل دسترسی مورد نیاز را داشته باشند
• مدیریت Password آن‌ها ساده باشد
• قابلیت کار در محیط Domain را داشته باشند
• امکان Audit و کنترل امنیتی روی آن‌ها وجود داشته باشد

به همین دلیل مفاهیمی مانند Virtual Account و Group Managed Service Account یا همان gMSA اهمیت زیادی پیدا کرده‌اند.

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

Service Account در SQL Server چیست؟

Service Account یک حساب کاربری مخصوص اجرای سرویس‌ها در سیستم‌عامل Windows است. هر سرویس Windows برای اجرا شدن نیاز به یک Security Context دارد. این Security Context مشخص می‌کند سرویس با چه هویتی فعالیت کند و چه مجوزهایی داشته باشد.

SQL Server نیز مانند سایر سرویس‌های Windows با یک Account مشخص اجرا می‌شود.

برای مثال هنگام نصب SQL Server ممکن است سرویس Database Engine با یکی از حساب‌های زیر اجرا شود:

NT SERVICE\MSSQLSERVER

یا:

DOMAIN\sqlservice

یا:

DOMAIN\gmsa_sql$

هرکدام از این گزینه‌ها رفتار متفاوتی در دسترسی به فایل‌ها، شبکه و Active Directory دارند.

در SQL Server چند سرویس اصلی وجود دارد که می‌توانند Service Account جداگانه داشته باشند:

سرویس‌های SQL Server که دارای Service Account هستند

SQL Server Database Engine

این سرویس اصلی SQL Server است و مسئول اجرای موتور دیتابیس، مدیریت Queryها، Buffer Pool، Transactionها و Storage Engine است.

معمولاً با نام زیر شناخته می‌شود:

SQL Server (MSSQLSERVER)

یا در Named Instance:

SQL Server (INSTANCE_NAME)

SQL Server Agent

SQL Server Agent برای اجرای Jobها استفاده می‌شود.

مواردی مانند:

• Backup Job
• Maintenance Plan
• اجرای Stored Procedure زمان‌بندی شده
• Alert و Operator

توسط این سرویس اجرا می‌شوند.

SQL Server Integration Services

SSIS برای انتقال و پردازش داده‌ها استفاده می‌شود.

اگر Packageها نیاز به دسترسی به:

• File Share
• Excel File
• FTP Server
• منابع خارجی

داشته باشند، Service Account اهمیت زیادی پیدا می‌کند.

SQL Server Analysis Services

برای مدل‌های تحلیلی، Cubeها و پردازش‌های OLAP استفاده می‌شود.

SQL Server Reporting Services

برای اجرای گزارش‌ها و اتصال به منابع داده استفاده می‌شود.

چرا انتخاب Service Account برای SQL Server مهم است؟

انتخاب Service Account تنها یک تنظیم هنگام نصب نیست، بلکه بخشی از طراحی امنیتی SQL Server محسوب می‌شود.

تاثیر Service Account بر امنیت

فرض کنید SQL Server با حسابی اجرا شود که دسترسی کامل Administrator روی سرور دارد.

اگر به هر دلیلی:

• آسیب‌پذیری SQL Server مورد سوءاستفاده قرار گیرد
• یک Login با سطح دسترسی بالا هک شود
• یک Query مخرب اجرا شود

مهاجم ممکن است بتواند از سطح SQL Server عبور کرده و به سطح سیستم‌عامل برسد.

به همین دلیل اصل مهم زیر مطرح می‌شود:

SQL Server باید همیشه با کمترین سطح دسترسی مورد نیاز اجرا شود.

این اصل با عنوان:

Least Privilege Principle

شناخته می‌شود.

تاثیر Service Account بر دسترسی شبکه

SQL Server فقط روی فایل‌های محلی کار نمی‌کند.

در محیط‌های سازمانی معمولاً نیاز به دسترسی به منابع دیگر وجود دارد:

• ذخیره Backup روی NAS
• اتصال به File Server
• Linked Server
• Replication
• Always On Availability Group
• SSIS Package
• دسترسی به Active Directory

نوع Service Account تعیین می‌کند SQL Server هنگام اتصال به یک منبع شبکه، با چه هویتی معرفی شود.

برای مثال:

اگر SQL Server با:

NT AUTHORITY\NETWORK SERVICE

اجرا شود، هنگام دسترسی به شبکه معمولاً از Computer Account استفاده می‌کند:

DOMAIN\SQLSERVER01$

اما اگر با یک Domain Account اجرا شود:

DOMAIN\svc_sql

همان حساب در شبکه شناخته خواهد شد.

تاثیر Service Account بر Kerberos و SPN

در محیط‌های Enterprise، احراز هویت SQL Server معمولاً با Kerberos انجام می‌شود.

Kerberos برای عملکرد صحیح نیاز به ثبت Service Principal Name یا SPN دارد.

Service Account مناسب کمک می‌کند:

• SPN به درستی ثبت شود
• Authentication سریع‌تر و امن‌تر باشد
• مشکل Double Hop ایجاد نشود
• Linked Serverها بدون خطا کار کنند

برای مثال در Always On Availability Group یا محیط‌های Multi-Tier، انتخاب Service Account اهمیت بسیار بالایی دارد.

انواع Service Account قابل استفاده برای SQL Server

در Windows چند نوع Account وجود دارد که می‌توان برای اجرای SQL Server استفاده کرد:

• Local System
• Local Service
• Network Service
• Virtual Account
• Managed Service Account
• Group Managed Service Account
• Domain User Account

هرکدام کاربرد، مزایا و محدودیت‌های خاص خود را دارند.

Local System Account چیست؟

Local System یکی از قدیمی‌ترین و قدرتمندترین حساب‌های داخلی Windows است که برای اجرای سرویس‌های سیستمی استفاده می‌شود.

نام این Account در Windows:

NT AUTHORITY\SYSTEM

است.

این حساب یک User معمولی نیست، بلکه یک Identity داخلی سیستم‌عامل محسوب می‌شود و تقریباً بالاترین سطح دسترسی ممکن روی همان سرور را دارد.

زمانی که یک سرویس با Local System اجرا می‌شود، Windows اجازه دسترسی بسیار گسترده‌ای به منابع محلی سیستم به آن می‌دهد.

سطح دسترسی Local System در Windows

Local System تقریباً دسترسی کامل روی سیستم محلی دارد.

مهم‌ترین دسترسی‌های آن:

به همین دلیل اگر یک سرویس با Local System اجرا شود، در صورت آسیب‌پذیری آن سرویس، امکان سوءاستفاده با سطح دسترسی بسیار بالا وجود خواهد داشت.

رفتار Local System در شبکه

یکی از نکات مهم درباره Local System این است که هنگام اتصال به منابع شبکه، با هویت خود سیستم معرفی می‌شود.

برای مثال فرض کنید SQL Server روی سروری با نام زیر نصب شده است:

SQLSERVER01

اگر سرویس SQL Server با Local System اجرا شود و بخواهد به یک File Share متصل شود:

\\FILESERVER01\Backup

Windows معمولاً درخواست را با Computer Account ارسال می‌کند:

DOMAIN\SQLSERVER01$

بنابراین باید روی File Server برای Computer Account مجوز داده شود.

مزایای Local System

Local System چند مزیت دارد:

• نیاز به Password ندارد
• Password Expire نمی‌شود
• همیشه در دسترس است
• برای سرویس‌های داخلی Windows مناسب است
• مدیریت آن ساده است

معایب Local System برای SQL Server

با وجود سادگی، استفاده از Local System برای SQL Server معمولاً توصیه نمی‌شود.

دلایل اصلی:

سطح دسترسی بیش از حد

SQL Server برای انجام وظایف خود به Full Access روی سیستم‌عامل نیاز ندارد.

دادن چنین سطح دسترسی‌ای برخلاف اصول امنیتی است.

افزایش سطح حمله

اگر یک مهاجم بتواند از طریق SQL Server به اجرای Code روی سیستم برسد، سرویس SQL Server با هویت بسیار قدرتمند SYSTEM اجرا می‌شود.

مشکل در Audit

در محیط‌های Enterprise، کنترل اینکه کدام سرویس با چه سطح دسترسی‌ای فعالیت می‌کند اهمیت زیادی دارد.

استفاده از Local System باعث می‌شود سرویس‌ها Identity مشترک داشته باشند.

آیا استفاده از Local System برای SQL Server مناسب است؟

برای محیط‌های:

• Development
• آزمایشگاهی
• Serverهای موقت

ممکن است قابل قبول باشد.

اما برای:

• Production Database
• سیستم‌های مالی
• ERP
• Data Warehouse
• Always On

توصیه نمی‌شود.

Network Service Account چیست؟

Network Service یکی دیگر از Accountهای داخلی Windows است که برای اجرای سرویس‌ها طراحی شده است.

نام آن:

NT AUTHORITY\NETWORK SERVICE

است.

Network Service برخلاف Local System دسترسی کمتری روی سیستم محلی دارد و برای بسیاری از سرویس‌هایی که نیاز به ارتباط شبکه دارند طراحی شده است.

تفاوت Network Service با Local System

مهم‌ترین تفاوت این دو Account در سطح دسترسی است.

Local System:

Local Machine = تقریباً Full Control

اما Network Service:

Local Machine = محدود
Network = با هویت Computer Account

عمل می‌کند.

سطح دسترسی Network Service

Network Service دارای دسترسی‌های محدود روی سیستم محلی است.

به صورت پیش‌فرض:

این طراحی باعث می‌شود ریسک امنیتی نسبت به Local System کمتر شود.

احراز هویت Network Service در شبکه

یکی از مهم‌ترین ویژگی‌های Network Service نحوه Authentication آن است.

فرض کنید:

نام SQL Server:

SQL01

Domain:

CONTOSO

Service Account:

NT AUTHORITY\NETWORK SERVICE

وقتی SQL Server به شبکه متصل می‌شود، معمولاً با این Identity دیده می‌شود:

CONTOSO\SQL01$

این همان Computer Account سرور است.

بنابراین اگر SQL Server نیاز به Backup روی File Server داشته باشد:

\\Backup01\SQL

باید مجوز زیر داده شود:

CONTOSO\SQL01$

نه:

NT AUTHORITY\NETWORK SERVICE

مزایای Network Service برای SQL Server

Network Service نسبت به Local System امن‌تر است.

مزایا:

• بدون Password
• مدیریت آسان
• سطح دسترسی کمتر
• مناسب برای برخی سرویس‌های داخلی

معایب Network Service

با وجود امنیت بهتر، محدودیت‌هایی دارد.

کنترل کمتر روی Identity

در محیط‌های بزرگ، استفاده از Computer Account برای دسترسی‌ها مدیریت را سخت‌تر می‌کند.

مناسب نبودن برای چندین SQL Server

در محیط‌هایی که چند SQL Server وجود دارد، کنترل Permissionها دشوار می‌شود.

برای مثال:

SQL01$
SQL02$
SQL03$

باید جداگانه مدیریت شوند.

محدودیت در سناریوهای Enterprise

در محیط‌هایی مانند:

• Always On Availability Group
• Failover Cluster Instance
• Kerberos Delegation

معمولاً Domain Service Account یا gMSA انتخاب بهتری است.

Local Service Account چیست؟

Local Service کم‌سطح‌ترین Account داخلی Windows است.

نام:

NT AUTHORITY\LOCAL SERVICE

است.

این Account برای سرویس‌هایی طراحی شده که:

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

سطح دسترسی Local Service

Local Service تقریباً مانند یک User با دسترسی بسیار پایین رفتار می‌کند.

ویژگی‌ها:

• دسترسی محدود به سیستم‌عامل
• بدون Password
• عدم دسترسی مدیریتی
• استفاده محدود در شبکه

در شبکه، معمولاً با Anonymous Credential یا دسترسی بسیار محدود شناخته می‌شود.

آیا Local Service برای SQL Server مناسب است؟

خیر.

SQL Server معمولاً نیاز دارد:

• فایل‌های Database را مدیریت کند
• Log Fileها را بنویسد
• Backup اجرا کند
• با منابع دیگر ارتباط داشته باشد

Local Service برای چنین کاری طراحی نشده است.

استفاده از آن باعث ایجاد مشکلات Permission خواهد شد.

Virtual Account در SQL Server چیست؟

Virtual Account یکی از مهم‌ترین تغییرات معرفی‌شده در Windows Serverهای جدید است.

این قابلیت از نسخه Windows Server 2008 R2 و SQL Server 2008 R2 به بعد معرفی شد.

Virtual Accountها به صورت خودکار هنگام نصب SQL Server ساخته می‌شوند.

نمونه:

برای Default Instance:

NT SERVICE\MSSQLSERVER

برای Named Instance:

NT SERVICE\MSSQL$INSTANCE01

ساختار Virtual Account

Virtual Account یک Account واقعی در Active Directory نیست.

یعنی:

• در Users and Computers دیده نمی‌شود
• Password ندارد
• توسط Windows مدیریت می‌شود

هر سرویس Identity مخصوص خودش را دارد.

مثلاً:

SQL Server Database Engine:

NT SERVICE\MSSQLSERVER

SQL Server Agent:

NT SERVICE\SQLSERVERAGENT

این جداسازی باعث افزایش امنیت می‌شود.

مزایای Virtual Account

مهم‌ترین مزایا:

عدم نیاز به Password

Administrator لازم نیست Password ذخیره یا تغییر دهد.

مدیریت خودکار

Windows مدیریت Lifecycle آن را انجام می‌دهد.

جداسازی سرویس‌ها

هر سرویس Identity جداگانه دارد.

امنیت بهتر نسبت به Local System

سطح دسترسی محدودتر است.

محدودیت Virtual Account

مهم‌ترین محدودیت Virtual Account زمانی مشخص می‌شود که SQL Server نیاز به دسترسی خارجی داشته باشد.

مثلاً:

Backup:

\\NAS01\SQLBackup

یا:

Linked Server به سیستم دیگر.

در این حالت Virtual Account معمولاً نمی‌تواند مانند یک Domain Account واقعی احراز هویت کند.

در چنین سناریوهایی استفاده از gMSA یا Domain Account بهتر است.

Managed Service Account چیست؟

قبل از بررسی gMSA بهتر است ابتدا مفهوم Managed Service Account یا MSA را بررسی کنیم.

در محیط‌های Domain-Based، یکی از مشکلات قدیمی مدیران سیستم، مدیریت Password حساب‌هایی بود که برای اجرای سرویس‌ها استفاده می‌شدند.

برای مثال یک سازمان ممکن بود یک حساب مانند:

CONTOSO\svc_sql

برای SQL Server ایجاد کند.

بعد از مدتی مشکلاتی مانند موارد زیر ایجاد می‌شد:

• Password باید طبق Policy تغییر کند
• پس از تغییر Password سرویس SQL Server متوقف می‌شود
• Credentialهای ذخیره‌شده باید به‌روزرسانی شوند
• احتمال افشای Password وجود دارد
• مدیریت تعداد زیادی Service Account دشوار می‌شود

Microsoft برای حل این مشکل مفهوم Managed Service Account را معرفی کرد.

ساختار Managed Service Account

MSA یک حساب ویژه در Active Directory است که:

• توسط Domain Controller مدیریت می‌شود
• Password آن توسط سیستم تولید و نگهداری می‌شود
• Administrator نیاز به دانستن Password ندارد
• امکان استفاده برای اجرای سرویس‌ها وجود دارد

نمونه:

CONTOSO\SQLService$

علامت $ در انتهای نام نشان‌دهنده یک Managed Account است.

محدودیت Managed Service Account

MSA نسبت به Domain User معمولی امنیت بیشتری دارد، اما یک محدودیت مهم دارد:

یک MSA فقط برای یک سیستم قابل استفاده است.

برای مثال:

SQL01

می‌تواند از:

CONTOSO\SQLService$

استفاده کند.

اما همان Account را نمی‌توان هم‌زمان روی:

SQL02
SQL03
SQL04

استفاده کرد.

در محیط‌های Enterprise که تعداد زیادی SQL Server وجود دارد، این محدودیت مشکل ایجاد می‌کند.

برای حل این مشکل Microsoft نسخه توسعه‌یافته MSA را معرفی کرد.

Group Managed Service Account یا gMSA چیست؟

gMSA مخفف:

Group Managed Service Account

است.

این فناوری از Windows Server 2012 معرفی شد و برای محیط‌های سازمانی بزرگ طراحی شده است.

gMSA در واقع نسخه Enterprise از Managed Service Account است که امکان استفاده یک Service Account در چندین سرور را فراهم می‌کند.

معماری gMSA در Active Directory

در gMSA یک Account در Active Directory ساخته می‌شود.

برای مثال:

gmsa_sql_engine$

این Account:

• Password مشخصی که Administrator بداند ندارد
• توسط Domain Controller مدیریت می‌شود
• امکان استفاده روی چند سرور مجاز را دارد

مثلاً:

SQL01
SQL02
SQL03

می‌توانند از یک gMSA مشترک استفاده کنند.

نحوه عملکرد Password در gMSA

یکی از مهم‌ترین ویژگی‌های gMSA مدیریت خودکار Password است.

در حالت معمول:

Administrator باید:

1. Password تولید کند
2. Password را ذخیره کند
3. قبل از Expire شدن تغییر دهد
4. سرویس‌ها را Update کند

اما در gMSA:

• Domain Controller Password را تولید می‌کند
• Password به صورت دوره‌ای تغییر می‌کند
• Service بدون دخالت Administrator از Password جدید استفاده می‌کند

Administrator هیچ‌وقت Password واقعی را مشاهده نمی‌کند.

این موضوع یک مزیت امنیتی بسیار مهم است.

چرا gMSA برای SQL Server اهمیت دارد؟

SQL Server در محیط‌های Enterprise معمولاً تنها یک سرویس ساده نیست.

معمولاً با موارد زیر در ارتباط است:

• Active Directory
• File Server
• Cluster
• Availability Group
• Backup Infrastructure
• Monitoring Systems
• Reporting Services

در چنین معماری‌هایی مدیریت دستی Accountها بسیار دشوار می‌شود.

gMSA این فرآیند را ساده‌تر و امن‌تر می‌کند.

مزایای استفاده از gMSA برای SQL Server

حذف مدیریت Password

مهم‌ترین مزیت gMSA حذف Password Management است.

دیگر نیازی نیست:

• Password را ذخیره کنید
• Password را در SQL Server Configuration Manager تغییر دهید
• نگران Expire شدن Credential باشید

افزایش امنیت

با حذف Password قابل مشاهده:

• احتمال Credential Leakage کاهش پیدا می‌کند
• حملات Password-Based کمتر می‌شود
• کنترل امنیتی بهتر می‌شود

مناسب برای محیط‌های بزرگ

در سازمان‌هایی با چندین SQL Server:

مثلاً:

SQL-PROD-01
SQL-PROD-02
SQL-DR-01
SQL-REPORT-01

می‌توان مدیریت Accountها را ساده کرد.

سازگار با Least Privilege

gMSA را می‌توان تنها برای سرویس‌های مشخص و روی سرورهای مشخص فعال کرد.

gMSA و SQL Server Always On Availability Group

یکی از بهترین سناریوهای استفاده از Group Managed Service Account یا gMSA، پیاده‌سازی SQL Server Always On Availability Group است.

در معماری Always On معمولاً چند SQL Server به عنوان Replica در کنار یکدیگر فعالیت می‌کنند. یکی از سرورها نقش Primary Replica و سایر سرورها نقش Secondary Replica را بر عهده دارند.

معماری نمونه:

در این معماری، تمام Replicaها باید بتوانند با یکدیگر ارتباط امن داشته باشند و سرویس SQL Server روی هر Node با یک هویت معتبر اجرا شود.

مشکل استفاده از Domain Account معمولی

در روش سنتی ممکن است یک حساب Domain مانند:

CONTOSO\svc_sql

برای اجرای SQL Server استفاده شود.

در این حالت مدیر سیستم باید موارد زیر را مدیریت کند:

• ذخیره و محافظت از Password
• تغییر Password طبق سیاست‌های امنیتی
• به‌روزرسانی Credential روی تمام Replicaها
• بررسی دسترسی‌ها پس از تغییر Password
• مدیریت SPN و Kerberos

در محیط‌هایی که تعداد Replicaها زیاد است، این فرآیند می‌تواند پیچیده و مستعد خطا شود.

مزایای استفاده از gMSA در Always On

با استفاده از gMSA، یک Identity مدیریت‌شده در Active Directory برای SQL Server ایجاد می‌شود.

برای مثال:

CONTOSO\gmsa_sql_engine$

سپس سرورهای مجاز مانند:

می‌توانند از همان Service Account استفاده کنند.

مزایای اصلی:

مدیریت خودکار Password

Password توسط Active Directory مدیریت و به صورت دوره‌ای تغییر داده می‌شود.

نیازی به:

• مشاهده Password
• ذخیره Password
• تغییر دستی Password

وجود ندارد.

سازگاری بهتر با Kerberos

Always On Availability Group معمولاً به تنظیمات صحیح Authentication و SPN نیاز دارد.

gMSA به دلیل داشتن هویت Domain، سازگاری بسیار خوبی با Kerberos دارد و مدیریت سناریوهای پیچیده‌تر را ساده‌تر می‌کند.

کاهش خطای انسانی

در معماری‌های بزرگ، مدیریت دستی چندین Service Account می‌تواند باعث خطا شود.

gMSA باعث می‌شود:

• هویت سرویس‌ها استاندارد شود
• مدیریت Credential ساده‌تر شود
• امنیت سرویس افزایش پیدا کند

جمع‌بندی

برای SQL Server Always On Availability Group:

در محیط‌های سازمانی که SQL Serverهای حیاتی، چند Replica و نیاز به High Availability وجود دارد، gMSA یکی از بهترین انتخاب‌ها برای Service Account SQL Server محسوب می‌شود.

gMSA و Kerberos Authentication

Kerberos یکی از بخش‌های مهم SQL Server Enterprise است.

سناریوهایی مانند:

• Linked Server
• SSIS
• Reporting Services
• Multi-Hop Authentication

به Kerberos وابسته هستند.

gMSA به دلیل اینکه یک Domain Identity واقعی است، سازگاری بسیار خوبی با Kerberos دارد.

در مقایسه:

پیش‌نیازهای استفاده از gMSA

برای استفاده از gMSA نیاز به موارد زیر دارید:

Active Directory Domain

gMSA بخشی از Active Directory است و روی Workgroup Server قابل استفاده نیست.

Windows Server مناسب

Domain Controller باید از نسخه‌های پشتیبان gMSA پشتیبانی کند.

PowerShell Active Directory Module

ساخت و مدیریت gMSA معمولاً با PowerShell انجام می‌شود.

KDS Root Key

برای تولید و مدیریت Passwordهای gMSA نیاز به KDS Root Key در Domain وجود دارد.

نمونه:

Add-KdsRootKey -EffectiveImmediately

ایجاد gMSA برای SQL Server

ابتدا مشخص می‌کنیم کدام سرورها اجازه استفاده از Account را دارند.

مثلاً:

New-ADServiceAccount `
-Name gmsa_sql `
-DNSHostName sql01.contoso.com `
-PrincipalsAllowedToRetrieveManagedPassword SQLServersGroup

سپس روی SQL Server:

Install-ADServiceAccount gmsa_sql

و بررسی:

Test-ADServiceAccount gmsa_sql

استفاده از gMSA در SQL Server

در SQL Server Configuration Manager هنگام تغییر Service Account:

به جای:

CONTOSO\username

از:

CONTOSO\gmsa_sql$

استفاده می‌شود.

Domain Service Account معمولی یا gMSA؟

یکی از سوال‌های رایج این است که آیا هنوز باید از Domain User Account معمولی استفاده کنیم؟

پاسخ بستگی به معماری دارد.

Domain Account معمولی

مزایا:

• ساده و شناخته‌شده
• سازگار با تمام نسخه‌ها
• کنترل کامل توسط Administrator

معایب:

• نیاز به مدیریت Password
• خطر افشای Credential
• نیاز به Rotation دستی

gMSA

مزایا:

• بدون مدیریت Password
• امنیت بالاتر
• مناسب Enterprise
• مناسب Always On

معایب:

• نیازمند Active Directory
• نیاز به طراحی اولیه
• برای محیط‌های کوچک ممکن است بیش از نیاز باشد

انتخاب پیشنهادی برای SQL Server

در محیط‌های مختلف:

در معماری‌های جدید، gMSA معمولاً انتخاب اول برای SQL Serverهای حیاتی سازمانی است.

مقایسه کامل Local System، Network Service، Virtual Account و gMSA

انتخاب Service Account مناسب برای SQL Server به عوامل مختلفی بستگی دارد. مواردی مانند معماری سازمان، تعداد SQL Serverها، نیاز به دسترسی شبکه، وجود Active Directory، سطح امنیت مورد نیاز و استفاده از قابلیت‌هایی مانند Always On Availability Group در انتخاب نهایی تاثیرگذار هستند.

هیچ Service Accountای برای تمام سناریوها بهترین گزینه نیست، اما تفاوت در سطح دسترسی، نحوه مدیریت هویت و قابلیت استفاده در معماری‌های Enterprise باعث می‌شود برخی گزینه‌ها برای محیط‌های سازمانی مناسب‌تر باشند.

مقایسه امنیتی Service Accountهای SQL Server

مقایسه Local System و Network Service

Local System و Network Service دو مورد از قدیمی‌ترین حساب‌های داخلی Windows هستند که برای اجرای سرویس‌ها استفاده می‌شوند.

تفاوت اصلی این دو Account در میزان دسترسی است.

Local System

قدرت بیشتر، ریسک امنیتی بیشتر

Local System بالاترین سطح دسترسی را روی سیستم محلی دارد. اگر SQL Server با این Account اجرا شود، Database Engine تقریباً با سطح دسترسی کامل سیستم‌عامل فعالیت می‌کند.

این موضوع در محیط Production یک ریسک امنیتی محسوب می‌شود، زیرا در صورت وجود آسیب‌پذیری در SQL Server، سطح دسترسی مهاجم می‌تواند تا سطح SYSTEM افزایش پیدا کند.

Network Service

قدرت کمتر، امنیت بهتر

Network Service نسبت به Local System محدودتر است و برای سرویس‌هایی طراحی شده که نیاز به ارتباط شبکه دارند اما نباید دسترسی کامل سیستم‌عامل را داشته باشند.

با این حال، Network Service یک محدودیت مهم دارد.

هنگامی که SQL Server با Network Service به منابع شبکه مانند File Server یا NAS متصل می‌شود، هویت آن در شبکه همان Computer Account سرور خواهد بود.

برای مثال:

در نتیجه در یک سازمان با چند SQL Server، Permissionها باید برای هر Computer Account جداگانه مدیریت شوند.

مقایسه Virtual Account و gMSA

Virtual Account و gMSA هر دو یک مشکل مهم را حل می‌کنند:

حذف مدیریت دستی Password

اما معماری آن‌ها کاملاً متفاوت است.

Virtual Account

نمونه:

NT SERVICE\MSSQLSERVER

Virtual Account یک Identity محلی است که توسط Windows ساخته و مدیریت می‌شود.

ویژگی‌ها:

• بدون Password
• مدیریت خودکار توسط سیستم‌عامل
• مناسب Serverهای مستقل
• مناسب محیط‌های کوچک و ساده

اما Virtual Account یک هویت واقعی در Active Directory نیست و برای سناریوهای پیچیده شبکه محدودیت دارد.

gMSA

نمونه:

CONTOSO\gmsa_sql$

gMSA یک Service Account واقعی در Active Directory است که Password آن توسط Domain Controller مدیریت می‌شود.

ویژگی‌ها:

• بدون نیاز به مدیریت Password
• مناسب چندین SQL Server
• سازگار با Kerberos
• مناسب Always On Availability Group
• مناسب Failover Cluster
• مناسب محیط‌های Enterprise

تفاوت اصلی Virtual Account و gMSA

در نتیجه، Virtual Account برای SQL Serverهای مستقل و محیط‌های ساده انتخاب مناسبی است، اما در معماری‌های Enterprise که چندین SQL Server، Cluster یا Availability Group وجود دارد، معمولاً gMSA انتخاب استانداردتر و امن‌تری محسوب می‌شود.

انتخاب Service Account برای SQL Server Production

در محیط Production، انتخاب Account باید بر اساس معماری انجام شود.

SQL Server مستقل بدون Domain

اگر SQL Server:

• عضو Domain نیست
• تنها یک سرور وجود دارد
• نیاز به منابع شبکه محدود است

Virtual Account می‌تواند گزینه مناسبی باشد.

مثال:

NT SERVICE\MSSQLSERVER

مزایا:

• بدون Password
• مدیریت آسان
• امنیت قابل قبول

SQL Server عضو Domain

در محیط Domain، گزینه‌های بیشتری وجود دارد.

معمولاً دو انتخاب مطرح است:

• Domain Service Account
• gMSA

برای سازمان‌های کوچک:

CONTOSO\svc_sql

می‌تواند کافی باشد.

اما باید موارد زیر رعایت شود:

• Password قوی
• عدم عضویت در Administrator Group
• تنظیم Password Policy مناسب
• Audit دوره‌ای

SQL Server Always On Availability Group

در Always On، چندین SQL Server درگیر هستند.

معماری معمول:

در این سناریو gMSA مزیت زیادی دارد.

دلایل:

• تمام Replicaها می‌توانند از یک Identity مدیریت‌شده استفاده کنند
• Password به صورت خودکار تغییر می‌کند
• Kerberos ساده‌تر تنظیم می‌شود
• مدیریت Credential کاهش پیدا می‌کند

SQL Server Failover Cluster Instance

در Failover Cluster نیز Service Account اهمیت زیادی دارد.

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

NODE01 | NODE02

در این شرایط استفاده از Accountهای محلی مانند Virtual Account مناسب نیست.

زیرا Identity باید بین Nodeها قابل استفاده باشد.

معمولاً:

• gMSA
• Domain Service Account

انتخاب مناسب‌تری هستند.

Backup روی File Share

یکی از رایج‌ترین مشکلات SQL Server مربوط به Backup روی مسیر شبکه است.

مثلاً:

BACKUP DATABASE Sales
TO DISK='\\BackupServer\SQL\Sales.bak'

موفقیت این عملیات به Identity سرویس SQL Server بستگی دارد.

SQL Server با Virtual Account

مثلاً:

NT SERVICE\MSSQLSERVER

ممکن است نتواند به Share دسترسی پیدا کند.

SQL Server با Network Service

در این حالت دسترسی باید به Computer Account داده شود:

DOMAIN\SQLSERVER01$

SQL Server با gMSA

مجوز به خود gMSA داده می‌شود:

DOMAIN\gmsa_sql$

این مدل در محیط‌های Enterprise قابل مدیریت‌تر است.

سطح دسترسی مورد نیاز SQL Server Service Account

یکی از اشتباهات رایج این است که تصور کنیم SQL Server برای اجرا نیاز به Administrator دارد.

این تصور اشتباه است.

SQL Server باید فقط Permissionهای مورد نیاز خود را داشته باشد.

دسترسی به فایل‌های Database

SQL Server باید بتواند:

• MDF را بخواند
• LDF را بنویسد
• TempDB را مدیریت کند
• فایل‌های Database را ایجاد کند

مسیرهای معمول:

C:\Program Files\Microsoft SQL Server\

یا:

D:\SQLData\

باید به Service Account مجوز مناسب داده شود.

معمولاً این Permissionها در زمان نصب SQL Server خودکار تنظیم می‌شوند.

دسترسی به Backup Folder

برای Backup محلی:

D:\Backup

Service Account باید:

• Write
• Read
• Modify

داشته باشد.

برای Backup شبکه:

\\BackupServer\SQLBackup

باید Permission روی Share و NTFS تنظیم شود.

Share Permission و NTFS Permission

برای File Share همیشه دو سطح Permission وجود دارد:

Share Permission

مثلاً:

SQL Backup Share

NTFS Permission

روی فولدر واقعی:

D:\SQLBackup

هر دو باید صحیح باشند.

دسترسی Registry

SQL Server برای اجرای صحیح نیاز به دسترسی‌های Registry دارد.

اما این Permissionها معمولاً توسط Installer ایجاد می‌شوند.

نباید به صورت دستی:

Full Control

به Service Account داده شود.

دسترسی Active Directory

در سناریوهایی مانند:

• Kerberos
• SPN
• Always On
• Replication

SQL Server نیاز به ارتباط با Active Directory دارد.

برای gMSA این فرآیند ساده‌تر است، زیرا Account ذاتاً Domain Identity دارد.

Service Principal Name یا SPN

SPN یکی از بخش‌های مهم در Authentication SQL Server است.

SQL Server برای Kerberos نیاز دارد SPN صحیح ثبت شود.

نمونه:

MSSQLSvc/sql01.contoso.com:1433

اگر Service Account اشتباه انتخاب شود:

• Kerberos فعال نمی‌شود
• اتصال به NTLM تغییر می‌کند
• Linked Server ممکن است خطا دهد

بررسی SPN SQL Server

برای بررسی SPN:

setspn -L DOMAIN\gmsa_sql$

یا:

setspn -L SQLSERVER01

چرا نباید SQL Server را با Administrator اجرا کنیم؟

یکی از بدترین روش‌های نصب SQL Server استفاده از:

DOMAIN\Administrator

به عنوان Service Account است.

مشکلات:

• Password بسیار حساس
• دسترسی بیش از حد
• ریسک امنیتی بالا
• مشکل Audit
• نقض استانداردهای امنیتی

در صورت هک SQL Server، مهاجم عملاً یک Administrator Domain در اختیار خواهد داشت.

SELECT 
    servicename,
    service_account,
    startup_type,
    status_desc
FROM sys.dm_server_services;

SQL Server Configuration Manager

services.msc

SQL Server Configuration Manager → SQL Server Services → SQL Server (Instance Name) → Propertie

Log On As

Built-in account

This account

CONTOSO\svc_sql

CONTOSO\gmsa_sql$

DOMAIN\svc_sql

CONTOSO\Domain Admin

CONTOSO\sqlservice

BUILTIN\Administrators

SQL Service = SYSTEM Privilege

BACKUP DATABASE ProductionDB
TO DISK='\\NAS01\Backup\DB.bak'

Operating system error 5(Access is denied.)

CONTOSO\gmsa_sql_engine$

CONTOSO\gmsa_sql_agent$

CONTOSO\gmsa_ssis$

CONTOSO\gmsa_ssrs$

Virtual Account

Virtual Account

Domain Service Account

Dedicated Domain Service Account

gMSA

NT SERVICE\MSSQLSERVER

DOMAIN\gmsa_sql$

\\FileServer01\SQLBackup

NT SERVICE\MSSQLSERVER

DOMAIN\gmsa_sql$

gmsa_sql_engine$

gmsa_sql_agent$

DOMAIN\gmsa_sql$

DOMAIN\old_sql_service

DOMAIN\gmsa_sql$

Operating system error 5(Access is denied.)

D:\SQLData

gmsa_sql

DOMAIN\gmsa_sql$

Install-ADServiceAccount gmsa_sql

Test-ADServiceAccount gmsa_sql

True

SELECT 
    auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

KERBEROS

NTLM

gmsa_sql_engine$

gmsa_sql_agent$

gmsa_sql_ssrs$

gmsa_sql_ssis$

SQL-PROD-01
SQL-PROD-02
SQL-DR-01

DOMAIN\gmsa_sql$

NT SERVICE\MSSQLSERVER

CONTOSO\svc_sql

BACKUP DATABASE Sales
TO DISK = '\\BackupServer\SQLBackup\Sales.bak'

SQL Data Folder
SQL Log Folder
Backup Folder
Temp Folder

SELECT 
    servicename,
    service_account,
    status_desc
FROM sys.dm_server_services;

SELECT 
    auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Windows Logs → Application

SQL Server Logs

CONTOSO\gmsa_sql$

CREATE LOGIN ApplicationUser
FROM WINDOWS;

DOMAIN\UserA

Operating system error 5(Access is denied.)

Cannot generate SSPI context

setspn -L DOMAIN\gmsa_sql$

setspn -X

gmsa_sql_engine$

gmsa_sql_agent$

SQL Agent Proxy

Get-Service | 
Where-Object {$_.Name -like "*SQL*"}

Get-CimInstance Win32_Service |
Where-Object {$_.Name -like "*SQL*"} |
Select Name, StartName

Get-ADServiceAccount -Identity gmsa_sql

Get-ADServiceAccount gmsa_sql |
Select PrincipalsAllowedToRetrieveManagedPassword

gmsa_sql_prod_engine$

gmsa_sql_prod_agent$

gmsa_sql_prod_ssrs$

gmsa_sql_prod_ssis$

gmsa_sql_dev_engine$
gmsa_sql_test_engine$
gmsa_sql_prod_engine$

Previous Account:
DOMAIN\old_sql_service