مقدمه و مسیر یادگیری

VERIFY_SIGNATURE یکی از قابلیت‌های تخصصی SQL Server در حوزه امنیت داده است. استفاده درست از آن فقط حفظ Syntax نیست؛ باید نوع بایت‌های ورودی، محل نگهداری خروجی، سطح مجوز، رفتار تابع در برابر NULL و هزینه پردازشی را هم شناخت. این مقاله از تعریف پایه شروع می‌کند و با مثال‌های مستقل، سناریوی سازمانی، خطاهای رایج و نکات بهینه‌سازی ادامه می‌یابد.

در T-SQL تابع اسکالر رمزنگاری به نام VERIFY_SIGNATURE وجود ندارد. VerifySignature نام یک Property در موتور Full-Text است که با FULLTEXTSERVICEPROPERTY خوانده و با sys.sp_fulltext_service مدیریت می‌شود. برای داده امضاشده با SIGNBYCERT باید VerifySignedByCert را فراخوانی کرد. هدف این راهنما آن است که Query نمونه به یک طراحی قابل اداره تبدیل شود؛ یعنی برنامه بتواند شکست را تشخیص دهد، تغییر تنظیم یا کلید را مدیریت کند و در زمان Restore نیز داده یا کنترل امنیتی از دست نرود.

برای دیدن جایگاه این موضوع در کنار سایر قابلیت‌ها، راهنمای جامع توابع رمزنگاری SQL Server را مطالعه کنید. در آن مقاله تفاوت هش، رمزنگاری متقارن، Passphrase، امضای دیجیتال و تنظیم VerifySignature مقایسه شده است.

تعریف و نحو VERIFY_SIGNATURE

در T-SQL تابع اسکالر رمزنگاری به نام VERIFY_SIGNATURE وجود ندارد. VerifySignature نام یک Property در موتور Full-Text است که با FULLTEXTSERVICEPROPERTY خوانده و با sys.sp_fulltext_service مدیریت می‌شود. برای داده امضاشده با SIGNBYCERT باید VerifySignedByCert را فراخوانی کرد.

نکته امنیتی: نمونه‌های مقاله برای آموزش هستند. Passwordها و Secretهای نمایشی را در محیط Production استفاده نکنید و قبل از هر تغییر Server-wide یا ساخت شیء امنیتی، Change Management سازمان را رعایت کنید.

Syntax

FULLTEXTSERVICEPROPERTY ( 'VerifySignature' )

EXEC sys.sp_fulltext_service
    @action = N'verify_signature',
    @value = 1;

پارامترها و خروجی

• VerifySignature: نام Property سرویس Full-Text برای محدودکردن بارگذاری به باینری‌های امضاشده و مورد اعتماد.
• مقدار 1: بررسی امضا فعال است و حالت پیش‌فرض امن محسوب می‌شود.
• مقدار 0: بررسی غیرفعال است و در محیط تولید توصیه نمی‌شود.
• برای اعتبارسنجی امضای داده، تابع مستقل و صحیح VerifySignedByCert است.

FULLTEXTSERVICEPROPERTY یک int برمی‌گرداند: 1 یعنی بررسی باینری‌های امضاشده فعال، 0 یعنی غیرفعال و NULL معمولاً نشان‌دهنده ورودی نامعتبر یا خطاست. این مقدار هیچ Signature ردیفی را اعتبارسنجی نمی‌کند.

مدل امنیت، مجوز و چرخه عمر

خاموش‌کردن verify_signature اجازه می‌دهد Full-Text باینری‌های بدون بررسی اعتماد را بارگذاری کند و سطح حمله را بالا می‌برد. تغییر این گزینه Server-wide است، مجوز بالا می‌خواهد و باید فقط با Change Management، ارزیابی افزونه‌ها و برنامه بازگشت انجام شود.

در طراحی حرفه‌ای VERIFY_SIGNATURE مالک فنی، مالک داده و مسئول امنیت باید مشخص باشند. حساب برنامه فقط حداقل مجوز لازم را دریافت می‌کند و حساب استقرار یا DBA برای ایجاد اشیای امنیتی از مسیر کنترل‌شده استفاده می‌شود. هیچ Secret، Password، متن واضح حساس یا Private Key نباید در Source Control، خروجی خطا و لاگ عمومی ثبت شود.

چرخه عمر شامل ایجاد، فعال‌سازی، نسخه‌بندی، تعویض، Backup، Restore، ابطال و حذف کنترل‌شده است. تست بازیابی باید ثابت کند که Backup صرفاً وجود ندارد، بلکه واقعاً قابل استفاده است. در سامانه‌های چندمحیطی نیز کلیدها و Secretهای Development، Test و Production باید مستقل باشند.

مثال‌های عملی مستقل

ده مثال زیر جنبه‌های متفاوت VERIFY_SIGNATURE را از مقدار ثابت تا داده نمونه، NULL، حالت مرزی، خطای رایج، گزارش سازمانی و سنجش Performance پوشش می‌دهند. اشیایی با پیشوند Article صرفاً آزمایشی هستند و پیش از اجرا باید نام‌گذاری و سیاست Password محیط خود را جایگزین کنید.

مثال 1: خواندن وضعیت VerifySignature

وضعیت فعلی موتور Full-Text را بدون هیچ تغییر Server-wide می‌خوانیم.

SELECT FULLTEXTSERVICEPROPERTY('VerifySignature') AS VerifySignatureState;

نکته کاربردی: این Read-only Query برای کنترل پیکربندی مناسب است.

مثال 2: تبدیل مقدار عددی به وضعیت خوانا

برای داشبورد DBA خروجی 0، 1 یا NULL به برچسب فارسی تبدیل می‌شود.

SELECT CASE FULLTEXTSERVICEPROPERTY('VerifySignature')
         WHEN 1 THEN N'فعال و امن'
         WHEN 0 THEN N'غیرفعال و نیازمند بررسی'
         ELSE N'نامشخص یا خطا'
       END AS VerifySignatureStatus;

نکته کاربردی: حالت NULL را نادیده نگیرید؛ ممکن است Property نامعتبر یا سرویس در دسترس نباشد.

مثال 3: بررسی همزمان نصب Full-Text

پیش از تفسیر Property، نصب مؤلفه Full-Text نیز کنترل می‌شود.

SELECT FULLTEXTSERVICEPROPERTY('IsFulltextInstalled') AS IsInstalled,
       FULLTEXTSERVICEPROPERTY('VerifySignature') AS VerifySignatureState;

نکته کاربردی: اگر Full-Text نصب نیست، Alert عملیاتی باید با نیاز واقعی سامانه هماهنگ شود.

مثال 4: کنترل LoadOSResources در کنار امضا

وابستگی امنیتی بارگذاری منابع سیستم‌عامل و بررسی امضا در یک ردیف دیده می‌شود.

SELECT FULLTEXTSERVICEPROPERTY('LoadOSResources') AS LoadOSResources,
       FULLTEXTSERVICEPROPERTY('VerifySignature') AS VerifySignatureState;

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

مثال 5: ساخت Check سلامت بدون تغییر تنظیم

در صورت انحراف از مقدار امن، Query یک خطای قابل تشخیص برای Job مانیتورینگ ایجاد می‌کند.

IF COALESCE(FULLTEXTSERVICEPROPERTY('VerifySignature'),-1) <> 1
    THROW 51001,N'VerifySignature موتور Full-Text فعال نیست یا وضعیت نامشخص است.',1;
SELECT N'Baseline امن برقرار است' AS Result;

نکته کاربردی: این کنترل Fail Closed است و برای Pipeline ارزیابی پیکربندی مناسب خواهد بود.

مثال 6: ثبت Snapshot زمان‌دار برای Audit

زمان UTC، نام سرور و مقدار Property در یک خروجی قابل ذخیره تولید می‌شود.

SELECT @@SERVERNAME AS ServerName,SYSUTCDATETIME() AS CheckedAtUtc,
       FULLTEXTSERVICEPROPERTY('VerifySignature') AS VerifySignatureState;

نکته کاربردی: تاریخچه تغییر به تشخیص Drift و همبستگی با Incident کمک می‌کند.

مثال 7: بررسی مجوز تغییر تنظیم

بدون تغییر وضعیت، عضویت کاربر در نقش‌های مجاز بررسی می‌شود.

SELECT IS_SRVROLEMEMBER(N'sysadmin') AS IsSysAdmin,
       IS_SRVROLEMEMBER(N'serveradmin') AS IsServerAdmin,
       FULLTEXTSERVICEPROPERTY('VerifySignature') AS CurrentState;

نکته کاربردی: اجرای sys.sp_fulltext_service به serveradmin یا sysadmin محدود است.

مثال 8: دستور امن فعال‌سازی با Guard

فقط اگر مقدار دقیقاً 0 باشد، گزینه به مقدار امن 1 برمی‌گردد؛ اجرای این مثال تغییر Server-wide دارد.

IF FULLTEXTSERVICEPROPERTY('VerifySignature')=0
BEGIN
    EXEC sys.sp_fulltext_service @action=N'verify_signature',@value=1;
END;
SELECT FULLTEXTSERVICEPROPERTY('VerifySignature') AS StateAfterGuard;

نکته کاربردی: پیش از اجرای تولیدی Change Ticket و ارزیابی اثر روی فیلترهای ثالث لازم است.

مثال 9: اصلاح نام تابع خیالی در Query

به‌جای VERIFY_SIGNATURE() که تابع اسکالر معتبری نیست، Property صحیح خوانده می‌شود.

-- روش نادرست: SELECT VERIFY_SIGNATURE();
-- روش صحیح و قابل اجرا:
SELECT FULLTEXTSERVICEPROPERTY('VerifySignature') AS VerifySignatureState;

نکته کاربردی: نام underscore در sp_fulltext_service و نام CamelCase در FULLTEXTSERVICEPROPERTY به یک مفهوم تنظیمی اشاره دارند.

مثال 10: اعتبارسنجی واقعی امضای داده با تابع درست

برای جلوگیری از اشتباه مفهومی، پیام با SIGNBYCERT امضا و با VERIFYSIGNEDBYCERT بررسی می‌شود.

IF NOT EXISTS (SELECT 1 FROM sys.symmetric_keys WHERE name = N'##MS_DatabaseMasterKey##')
    CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Article-Demo-Master-Key#1405!';
IF CERT_ID(N'Article_Verify_Cert') IS NULL
    CREATE CERTIFICATE Article_Verify_Cert WITH SUBJECT = N'گواهی آزمایشی امضای دیجیتال';
DECLARE @Body nvarchar(100)=N'داده امضاشده';
DECLARE @Sig varbinary(8000)=SIGNBYCERT(CERT_ID(N'Article_Verify_Cert'),@Body);
SELECT VERIFYSIGNEDBYCERT(CERT_ID(N'Article_Verify_Cert'),@Body,@Sig) AS IsDataSignatureValid;

نکته کاربردی: این تابع اعتبار محتوای ردیفی را می‌سنجد و کاملاً جدا از VerifySignature موتور Full-Text است.

خطاهای رایج و روش عیب‌یابی

در عیب‌یابی VERIFY_SIGNATURE ابتدا یک نمونه کوچک با مقدار ثابت بسازید و سپس همان Session، Database Context، نوع داده و مجوز حساب برنامه را بازسازی کنید. Error Message، مقدار NULL، طول بایتی ورودی و خروجی و وضعیت اشیای امنیتی را ثبت کنید، اما داده محرمانه را در Log قرار ندهید.

• 1. فراخوانی خیالی VERIFY_SIGNATURE() به‌عنوان تابع. برای رفع آن قرارداد داده و پیش‌شرط تابع را صریح کنترل کنید.
• 2. یکی‌دانستن VerifySignature با VerifySignedByCert. برای رفع آن قرارداد داده و پیش‌شرط تابع را صریح کنترل کنید.
• 3. تنظیم مقدار 0 برای رفع سریع خطای افزونه. برای رفع آن قرارداد داده و پیش‌شرط تابع را صریح کنترل کنید.
• 4. نادیده‌گرفتن LoadOSResources و اعتماد باینری‌ها. برای رفع آن قرارداد داده و پیش‌شرط تابع را صریح کنترل کنید.
• 5. تغییر Server-wide بدون ثبت و تأیید. برای رفع آن قرارداد داده و پیش‌شرط تابع را صریح کنترل کنید.

روش اشتباه رایج این است که با COALESCE یک NULL امنیتی به رشته خالی تبدیل شود و فرایند موفق تلقی گردد. مسیر درست باید میان «داده واقعاً تهی»، «مجوز ناکافی»، «کلید یا Secret نامعتبر» و «ورودی خراب» تفاوت بگذارد و در رخداد مشکوک Fail Closed باشد.

Performance Considerations

این Property تابع پردازش ردیفی نیست و معمولاً اثر آن در زمان بارگذاری فیلترها و Word Breakerها دیده می‌شود. آن را در مانیتورینگ پیکربندی با فاصله منطقی بخوانید؛ اجرای مکرر در Queryهای کسب‌وکار هیچ ارزشی ندارد.

برای ساخت Baseline، زمان CPU، Duration، تعداد Logical Read، اندازه Log و نرخ تراکنش را پیش و پس از افزودن VERIFY_SIGNATURE اندازه بگیرید. Query Store برای تغییر Plan و Extended Events برای خطا و زمان‌های غیرعادی مفید است؛ ثبت payload حساس در Session پایش ممنوع است.

بهینه‌سازی باید با حفظ مدل امنیت انجام شود. حذف Authenticator، نگهداری متن واضح یا بازکردن بیش‌ازحد مجوزها شاید آزمایش را سریع‌تر نشان دهد، ولی ریسک را به‌شدت بالا می‌برد. نتیجه قابل قبول توازنی مستند میان محرمانگی، تمامیت، دسترس‌پذیری و هزینه است.

Best Practices و کاربرد واقعی

• مقدار 1 را Baseline امن قرار دهید.
• وضعیت را با مانیتورینگ پیکربندی کنترل کنید.
• باینری Full-Text را از منبع معتبر نصب کنید.
• CRL Cache را طبق سیاست امنیتی نگه دارید.
• تغییر را تنها با serveradmin یا sysadmin مجاز انجام دهید.
• برای امضای داده از VerifySignedByCert استفاده کنید.

تیم DBA می‌تواند وضعیت VerifySignature و LoadOSResources را در گزارش پیکربندی روزانه ثبت کند. اگر مقدار از Baseline منحرف شد، هشدار تولید شود و به‌جای تغییر خودکار، فرایند Incident و بررسی افزونه Full-Text آغاز گردد.

در اجرای سازمانی VERIFY_SIGNATURE بهتر است منطق در Stored Procedure یا Service مشخص متمرکز شود تا همه برنامه‌ها قرارداد یکسانی برای نوع داده، خطا و نسخه امنیتی داشته باشند. تست خودکار باید نتیجه صحیح، ورودی دستکاری‌شده، مجوز ناکافی و بازیابی پس از Restore را پوشش دهد.

سؤالات متداول

1. VERIFY_SIGNATURE در SQL Server دقیقاً چه کاری انجام می‌دهد؟

در T-SQL تابع اسکالر رمزنگاری به نام VERIFY_SIGNATURE وجود ندارد. VerifySignature نام یک Property در موتور Full-Text است که با FULLTEXTSERVICEPROPERTY خوانده و با sys.sp_fulltext_service مدیریت می‌شود. برای داده امضاشده با SIGNBYCERT باید VerifySignedByCert را فراخوانی کرد. در یک پروژه واقعی باید ورودی، خروجی، مجوز و رفتار خطا پیش از استفاده نهایی با نسخه SQL Server مقصد آزمایش شود.

2. نوع خروجی VERIFY_SIGNATURE چیست و چگونه باید ذخیره شود؟

FULLTEXTSERVICEPROPERTY یک int برمی‌گرداند: 1 یعنی بررسی باینری‌های امضاشده فعال، 0 یعنی غیرفعال و NULL معمولاً نشان‌دهنده ورودی نامعتبر یا خطاست. این مقدار هیچ Signature ردیفی را اعتبارسنجی نمی‌کند. انتخاب نوع ستون کوتاه یا تبدیل ضمنی از خطاهای مهم طراحی است؛ Schema باید بر پایه حداکثر خروجی قابل انتظار ساخته شود.

3. استفاده تجاری از VERIFY_SIGNATURE چه ارزشی ایجاد می‌کند؟

این قابلیت می‌تواند بخشی از کنترل محرمانگی، تمامیت یا پایش امنیتی سامانه باشد و ریسک تغییر یا افشای داده را کاهش دهد. ارزش تجاری زمانی واقعی است که کنار کنترل دسترسی، Audit، Backup و فرایند پاسخ‌گویی به رخداد پیاده‌سازی شود.

4. هزینه اجرای پروژه VERIFY_SIGNATURE چگونه برآورد می‌شود؟

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

5. VERIFY_SIGNATURE چه تفاوتی با HASHBYTES یا Always Encrypted دارد؟

HASHBYTES یک‌طرفه است و برای بازگرداندن متن طراحی نشده؛ قابلیت‌های رمزنگاری سمت سرور داده را در موتور قابل پردازش می‌کنند؛ Always Encrypted می‌تواند کلید و plaintext را از Database Engine دور نگه دارد. انتخاب درست تابع به مدل تهدید و نیاز عملیاتی بستگی دارد.

6. چه زمانی برای VERIFY_SIGNATURE به مشاوره SQL Server نیاز داریم؟

وقتی داده حساس تولیدی، چند برنامه مصرف‌کننده، چرخش کلید، الزامات قانونی یا دسترس‌پذیری بالا مطرح است، بازبینی معماری ارزش زیادی دارد. مشاوره باید خروجی‌های قابل تحویل مانند Threat Model، ماتریس مجوز، Runbook بازیابی و آزمون Performance داشته باشد.

7. رایج‌ترین علت خطا یا NULL در VERIFY_SIGNATURE چیست؟

فراخوانی خیالی VERIFY_SIGNATURE() به‌عنوان تابع، یکی‌دانستن VerifySignature با VerifySignedByCert، تنظیم مقدار 0 برای رفع سریع خطای افزونه از علت‌های متداول‌اند. عیب‌یابی را با نوع داده، طول واقعی، وضعیت اشیای امنیتی، مجوز کاربر و اجرای یک نمونه حداقلی در همان Session شروع کنید.

8. اثر VERIFY_SIGNATURE بر Performance چقدر است؟

این Property تابع پردازش ردیفی نیست و معمولاً اثر آن در زمان بارگذاری فیلترها و Word Breakerها دیده می‌شود. آن را در مانیتورینگ پیکربندی با فاصله منطقی بخوانید؛ اجرای مکرر در Queryهای کسب‌وکار هیچ ارزشی ندارد. نتیجه را با STATISTICS TIME، Query Store یا ابزار پایش مناسب روی بار مشابه تولید بسنجید و از تعمیم یک آزمایش کوچک خودداری کنید.

9. بهترین روش امنیتی هنگام استفاده از VERIFY_SIGNATURE چیست؟

مقدار 1 را Baseline امن قرار دهید، وضعیت را با مانیتورینگ پیکربندی کنترل کنید، باینری Full-Text را از منبع معتبر نصب کنید. علاوه بر آن، اصل کمترین دسترسی، جداسازی محیط‌ها و آزمون Restore باید به‌صورت مستند و دوره‌ای اجرا شود.

10. VERIFY_SIGNATURE با کدام نسخه‌های SQL Server سازگار است؟

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

سؤالات مصاحبه SQL Server

1. چرا VERIFY_SIGNATURE به‌تنهایی یک راهکار امنیتی کامل نیست؟

زیرا امنیت به مدیریت هویت، مجوز، کلید یا Secret، ثبت رخداد، Backup، چرخه تغییر و مدل تهدید وابسته است و یک تابع فقط یکی از کنترل‌ها را اجرا می‌کند.

2. چگونه نوع داده ورودی و خروجی VERIFY_SIGNATURE را کنترل می‌کنید؟

تبدیل را صریح می‌کنم، طول بایتی را با DATALENGTH می‌سنجم، Unicode را از varchar جدا می‌کنم و تست Round-trip یا اعتبارسنجی خودکار می‌نویسم.

3. برای جلوگیری از افت Performance چه می‌کنید؟

ابتدا با Predicate ایندکس‌پذیر دامنه ردیف را کم می‌کنم، عملیات امنیتی را فقط روی داده لازم انجام می‌دهم و هزینه CPU، حافظه و Log را با بار واقعی اندازه می‌گیرم.

4. برنامه بازیابی قابلیت VERIFY_SIGNATURE چیست؟

وابستگی‌ها و نسخه‌ها را مستند، Backup امن تهیه، Restore را در محیط جدا تمرین و معیار RTO و RPO را با مالک کسب‌وکار هماهنگ می‌کنم.

5. چه تست‌هایی پیش از Production لازم است؟

تست مقدار صحیح، NULL، طول مرزی، ورودی Unicode، مجوز ناکافی، داده دستکاری‌شده، همزمانی، Failover و بازیابی از Backup را اجرا می‌کنم.

چک‌لیست نهایی

1. Syntax و محدودیت VERIFY_SIGNATURE با نسخه مقصد کنترل شده است.
2. نوع و طول ورودی و خروجی صریح است.
3. مجوزها بر اساس اصل کمترین دسترسی تنظیم شده‌اند.
4. Secret یا plaintext در Log و کد منبع وجود ندارد.
5. تست NULL، Unicode، مرز طول و داده دستکاری‌شده اجرا شده است.
6. Benchmark و معیار قابل قبول Performance ثبت شده است.
7. Backup، Restore، چرخش و Runbook رخداد آزمایش شده‌اند.

جمع‌بندی

VERIFY_SIGNATURE زمانی ارزش واقعی دارد که در یک معماری قابل اداره به‌کار رود. تعریف درست نوع داده، کنترل خطا، مجوز حداقلی، پایش بدون افشای محتوا و برنامه بازیابی، Query آموزشی را به قابلیت امن Production تبدیل می‌کند.

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