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

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

SIGNBYCERT با کلید خصوصی Certificate یک امضای دیجیتال برای داده می‌سازد. مصرف‌کننده با کلید عمومی همان گواهی و تابع VerifySignedByCert بررسی می‌کند که محتوا بعد از امضا عوض نشده و امضا به همان گواهی مربوط است. هدف این راهنما آن است که Query نمونه به یک طراحی قابل اداره تبدیل شود؛ یعنی برنامه بتواند شکست را تشخیص دهد، تغییر تنظیم یا کلید را مدیریت کند و در زمان Restore نیز داده یا کنترل امنیتی از دست نرود.

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

تعریف و نحو SIGNBYCERT

SIGNBYCERT با کلید خصوصی Certificate یک امضای دیجیتال برای داده می‌سازد. مصرف‌کننده با کلید عمومی همان گواهی و تابع VerifySignedByCert بررسی می‌کند که محتوا بعد از امضا عوض نشده و امضا به همان گواهی مربوط است.

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

Syntax

SIGNBYCERT ( certificate_ID, cleartext [ , password ] )

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

• certificate_ID: شناسه گواهی موجود در Database که از CERT_ID گرفته می‌شود.
• cleartext: داده متنی که باید امضا شود.
• password: فقط در صورت محافظت کلید خصوصی گواهی با Password مرتبط استفاده می‌شود.

خروجی یک امضای varbinary است که باید کنار داده یا در جدول Audit ذخیره شود. امضا داده را مخفی نمی‌کند؛ خواندن متن همچنان ممکن است، اما تغییر آن با VerifySignedByCert کشف می‌شود.

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

کلید خصوصی دارایی حساس است و مجوز CONTROL روی Certificate باید بسیار محدود باشد. Backup گواهی و Private Key، نگهداری Password آن خارج از Repository و ثبت زمان و هویت عملیات امضا بخش اصلی طراحی تولیدی است.

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

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

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

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

مثال 1: ساخت امضای پایه برای پیام

گواهی آزمایشی ساخته و یک پیام با کلید خصوصی آن امضا می‌شود.

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_Signing_Cert') IS NULL
    CREATE CERTIFICATE Article_Signing_Cert WITH SUBJECT = N'گواهی آزمایشی امضای دیجیتال';
DECLARE @Message nvarchar(100)=N'فرمان تأییدشده';
SELECT SIGNBYCERT(CERT_ID(N'Article_Signing_Cert'),@Message) AS DigitalSignature;

نکته کاربردی: امضا متن را پنهان نمی‌کند و فقط اصالت و تمامیت آن را قابل بررسی می‌سازد.

مثال 2: امضا و اعتبارسنجی Round-trip

پیام امضا و بلافاصله با کلید عمومی همان Certificate بررسی می‌شود.

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_Signing_Cert') IS NULL
    CREATE CERTIFICATE Article_Signing_Cert WITH SUBJECT = N'گواهی آزمایشی امضای دیجیتال';
DECLARE @Message nvarchar(100)=N'سند شماره ۱';
DECLARE @Signature varbinary(8000)=SIGNBYCERT(CERT_ID(N'Article_Signing_Cert'),@Message);
SELECT VERIFYSIGNEDBYCERT(CERT_ID(N'Article_Signing_Cert'),@Message,@Signature) AS IsValid;

نکته کاربردی: مسیر Verify به Private Key نیاز ندارد ولی VIEW DEFINITION روی Certificate لازم است.

مثال 3: کشف دستکاری پس از امضا

امضا برای مبلغ اولیه ساخته می‌شود و سپس متن تغییرکرده اعتبارسنجی می‌گردد.

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_Signing_Cert') IS NULL
    CREATE CERTIFICATE Article_Signing_Cert WITH SUBJECT = N'گواهی آزمایشی امضای دیجیتال';
DECLARE @Original nvarchar(100)=N'Amount=1000';
DECLARE @Signature varbinary(8000)=SIGNBYCERT(CERT_ID(N'Article_Signing_Cert'),@Original);
SELECT VERIFYSIGNEDBYCERT(CERT_ID(N'Article_Signing_Cert'),N'Amount=9000',@Signature) AS IsValid;

نکته کاربردی: هر تغییر بایتی در داده canonical باید اعتبار امضا را از بین ببرد.

مثال 4: ذخیره امضا کنار سند

جدول نمونه متن، امضا و زمان ثبت را کنار هم نگه می‌دارد.

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_Signing_Cert') IS NULL
    CREATE CERTIFICATE Article_Signing_Cert WITH SUBJECT = N'گواهی آزمایشی امضای دیجیتال';
DECLARE @SignedDocs TABLE(ID int PRIMARY KEY,Body nvarchar(200),Signature varbinary(8000),SignedAt datetime2);
DECLARE @Body nvarchar(200)=N'صورت‌جلسه هیئت‌مدیره';
INSERT @SignedDocs VALUES(10,@Body,SIGNBYCERT(CERT_ID(N'Article_Signing_Cert'),@Body),SYSUTCDATETIME());
SELECT ID,DATALENGTH(Signature) AS SignatureBytes,SignedAt FROM @SignedDocs;

نکته کاربردی: هویت امضاکننده و نسخه Certificate را نیز در Audit تولیدی ذخیره کنید.

مثال 5: امضای متن فارسی Unicode

رشته nvarchar فارسی امضا و با همان بایت‌ها اعتبارسنجی می‌شود.

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_Signing_Cert') IS NULL
    CREATE CERTIFICATE Article_Signing_Cert WITH SUBJECT = N'گواهی آزمایشی امضای دیجیتال';
DECLARE @Body nvarchar(200)=N'تأیید نهایی قرارداد شماره ۴۲';
DECLARE @Sig varbinary(8000)=SIGNBYCERT(CERT_ID(N'Article_Signing_Cert'),@Body);
SELECT VERIFYSIGNEDBYCERT(CERT_ID(N'Article_Signing_Cert'),@Body,@Sig) AS PersianSignatureValid;

نکته کاربردی: تبدیل ناخواسته nvarchar به varchar می‌تواند بایت‌ها و در نتیجه اعتبار امضا را تغییر دهد.

مثال 6: رفتار با مقدار NULL

تابع برای متن NULL آزمایش می‌شود و وضعیت خروجی گزارش می‌گردد.

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_Signing_Cert') IS NULL
    CREATE CERTIFICATE Article_Signing_Cert WITH SUBJECT = N'گواهی آزمایشی امضای دیجیتال';
DECLARE @Body nvarchar(100)=NULL;
SELECT SIGNBYCERT(CERT_ID(N'Article_Signing_Cert'),@Body) AS NullSignature;

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

مثال 7: امضای رکورد مالی با قالب canonical

شناسه، مبلغ و تاریخ با قالب ثابت به یک payload تبدیل و امضا می‌شوند.

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_Signing_Cert') IS NULL
    CREATE CERTIFICATE Article_Signing_Cert WITH SUBJECT = N'گواهی آزمایشی امضای دیجیتال';
DECLARE @ID int=701,@Amount decimal(18,2)=45000.00,@DocDate date='2026-07-20';
DECLARE @Payload nvarchar(300)=CONCAT(N'ID=',@ID,N'|AMOUNT=',CONVERT(nvarchar(30),@Amount),N'|DATE=',CONVERT(nchar(10),@DocDate,23));
SELECT @Payload AS CanonicalPayload,SIGNBYCERT(CERT_ID(N'Article_Signing_Cert'),@Payload) AS Signature;

نکته کاربردی: ترتیب فیلدها، جداکننده و قالب عدد و تاریخ باید نسخه‌بندی شود.

مثال 8: تشخیص Certificate اشتباه

پیام با گواهی اول امضا و با گواهی دوم بررسی می‌شود.

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_Signing_Cert') IS NULL
    CREATE CERTIFICATE Article_Signing_Cert WITH SUBJECT = N'گواهی آزمایشی امضای دیجیتال';
IF CERT_ID(N'Article_Other_Cert') IS NULL CREATE CERTIFICATE Article_Other_Cert WITH SUBJECT=N'گواهی دوم آزمایش';
DECLARE @Body nvarchar(100)=N'پیام';
DECLARE @Sig varbinary(8000)=SIGNBYCERT(CERT_ID(N'Article_Signing_Cert'),@Body);
SELECT VERIFYSIGNEDBYCERT(CERT_ID(N'Article_Other_Cert'),@Body,@Sig) AS IsValidWithOtherCert;

نکته کاربردی: شناسه یا Thumbprint نسخه گواهی را کنار امضا نگه دارید تا انتخاب گواهی قطعی باشد.

مثال 9: اعتبارسنجی مجموعه اسناد و گزارش موارد خراب

دو سند می‌سازیم که امضای یکی عمداً با محتوای دیگری ناسازگار است.

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_Signing_Cert') IS NULL
    CREATE CERTIFICATE Article_Signing_Cert WITH SUBJECT = N'گواهی آزمایشی امضای دیجیتال';
DECLARE @Docs TABLE(ID int,Body nvarchar(100),Signature varbinary(8000));
DECLARE @A nvarchar(100)=N'سند الف',@B nvarchar(100)=N'سند ب';
INSERT @Docs VALUES(1,@A,SIGNBYCERT(CERT_ID(N'Article_Signing_Cert'),@A)),(2,@B,SIGNBYCERT(CERT_ID(N'Article_Signing_Cert'),@A));
SELECT ID FROM @Docs WHERE VERIFYSIGNEDBYCERT(CERT_ID(N'Article_Signing_Cert'),Body,Signature)=0;

نکته کاربردی: گزارش مغایرت باید بدون بازنویسی خودکار سند، Incident امنیتی ایجاد کند.

مثال 10: اندازه‌گیری هزینه امضای Batch

صد پیام امضا می‌شوند و زمان CPU برای خط پایه ثبت می‌شود.

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_Signing_Cert') IS NULL
    CREATE CERTIFICATE Article_Signing_Cert WITH SUBJECT = N'گواهی آزمایشی امضای دیجیتال';
SET STATISTICS TIME ON;
DECLARE @Signed TABLE(ID int,Signature varbinary(8000));
INSERT @Signed
SELECT TOP(100) ROW_NUMBER() OVER(ORDER BY(SELECT NULL)),SIGNBYCERT(CERT_ID(N'Article_Signing_Cert'),CONVERT(nvarchar(20),ROW_NUMBER() OVER(ORDER BY(SELECT NULL))))
FROM sys.all_objects;
SELECT COUNT(*) AS SignedRows FROM @Signed WHERE Signature IS NOT NULL;
SET STATISTICS TIME OFF;

نکته کاربردی: امضا را در نقطه نهایی‌شدن سند انجام دهید و از تولید دوباره آن در SELECT جلوگیری کنید.

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

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

• 1. تصور اینکه امضا متن را محرمانه می‌کند. برای رفع آن قرارداد داده و پیش‌شرط تابع را صریح کنترل کنید.
• 2. امضای رشته‌ای با قالب ناپایدار. برای رفع آن قرارداد داده و پیش‌شرط تابع را صریح کنترل کنید.
• 3. ذخیره‌نکردن نسخه گواهی. برای رفع آن قرارداد داده و پیش‌شرط تابع را صریح کنترل کنید.
• 4. اعطای دسترسی گسترده به Private Key. برای رفع آن قرارداد داده و پیش‌شرط تابع را صریح کنترل کنید.
• 5. نداشتن Backup قابل بازیابی. برای رفع آن قرارداد داده و پیش‌شرط تابع را صریح کنترل کنید.

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

Performance Considerations

امضای مبتنی بر گواهی از هش ساده و رمزنگاری متقارن سنگین‌تر است. معمولاً Hash یا payload نهایی را یک بار در نقطه تثبیت سند امضا می‌کنند، نه اینکه امضا در هر SELECT دوباره ساخته شود. روی نرخ واقعی اسناد Benchmark بگیرید.

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

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

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

• قالب canonical داده را پیش از امضا تثبیت کنید.
• گواهی امضا را از گواهی‌های کاربردهای دیگر جدا کنید.
• امضا و شناسه نسخه گواهی را ذخیره کنید.
• مجوز کلید خصوصی را حداقلی کنید.
• اعتبارسنجی را در مسیر خواندن حساس اجرا کنید.
• چرخه تعویض و ابطال گواهی را مستند کنید.

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

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

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

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

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

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

خروجی یک امضای varbinary است که باید کنار داده یا در جدول Audit ذخیره شود. امضا داده را مخفی نمی‌کند؛ خواندن متن همچنان ممکن است، اما تغییر آن با VerifySignedByCert کشف می‌شود. انتخاب نوع ستون کوتاه یا تبدیل ضمنی از خطاهای مهم طراحی است؛ Schema باید بر پایه حداکثر خروجی قابل انتظار ساخته شود.

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

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

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

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

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

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

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

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

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

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

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

امضای مبتنی بر گواهی از هش ساده و رمزنگاری متقارن سنگین‌تر است. معمولاً Hash یا payload نهایی را یک بار در نقطه تثبیت سند امضا می‌کنند، نه اینکه امضا در هر SELECT دوباره ساخته شود. روی نرخ واقعی اسناد Benchmark بگیرید. نتیجه را با STATISTICS TIME، Query Store یا ابزار پایش مناسب روی بار مشابه تولید بسنجید و از تعمیم یک آزمایش کوچک خودداری کنید.

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

قالب canonical داده را پیش از امضا تثبیت کنید، گواهی امضا را از گواهی‌های کاربردهای دیگر جدا کنید، امضا و شناسه نسخه گواهی را ذخیره کنید. علاوه بر آن، اصل کمترین دسترسی، جداسازی محیط‌ها و آزمون Restore باید به‌صورت مستند و دوره‌ای اجرا شود.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

جمع‌بندی

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

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