راهنمای جامع توابع رمزنگاری در SQL Server؛ هش، رمزگذاری و امضای دیجیتال

مقدمه

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

این راهنما هفت موضوع HASHBYTES، ENCRYPTBYKEY، DECRYPTBYKEY، ENCRYPTBYPASSPHRASE، DECRYPTBYPASSPHRASE، SIGNBYCERT و VERIFY_SIGNATURE را در یک نقشه روشن قرار می‌دهد. برای هر موضوع صفحه مستقل با ده مثال اجرایی، خطاهای رایج، نکات Performance، FAQ و سؤال مصاحبه فراهم شده است.

فهرست دسترسی سریع زیر مستقیماً به مقاله کامل هر قابلیت می‌رود. همه نمونه‌های Password و Secret آموزشی‌اند و نباید بدون جایگزینی و بررسی مجوز در Production اجرا شوند.

چهار هدف متفاوت امنیت داده

محرمانگی یعنی فرد یا فرایند فاقد مجوز نتواند محتوای واضح را بخواند. ENCRYPTBYKEY و ENCRYPTBYPASSPHRASE برای تبدیل متن به ciphertext به‌کار می‌روند و توابع متناظر Decrypt آن را بازیابی می‌کنند. محرمانگی بدون مدیریت مجوز و Secret پایدار نیست؛ زیرا هر حسابی که به مسیر رمزگشایی دسترسی داشته باشد می‌تواند متن را ببیند.

تمامیت یعنی تغییر محتوا قابل کشف باشد. HASHBYTES اثر انگشت بایتی می‌سازد و SIGNBYCERT امضایی ایجاد می‌کند که با کلید عمومی Certificate قابل بررسی است. هش به‌تنهایی هویت تولیدکننده را ثابت نمی‌کند؛ امضا نیز داده را مخفی نمی‌کند. این تفاوت برای اسناد مالی و فرمان‌های حساس حیاتی است.

دسترس‌پذیری یعنی سازمان بتواند پس از Restore، Failover یا تعویض کلید همچنان داده مجاز را بخواند. Backup گواهی، Private Key و Database Master Key، نگهداری Passwordها در محل امن و تمرین Restore اجزای خود امنیت‌اند. رمزنگاری بدون طرح بازیابی می‌تواند به از دست رفتن دائمی داده منجر شود.

حداقل‌سازی سطح حمله نیز هدف چهارم است. VerifySignature در Full-Text Engine کنترل می‌کند فقط باینری‌های امضاشده مورد اعتماد بارگذاری شوند. این Property با امضای داده ردیفی یکسان نیست و نام مشابه نباید باعث ساخت تابع خیالی VERIFY_SIGNATURE() شود.

جدول مقایسه توابع و موضوع‌ها

تابع یا موضوع	کاربرد اصلی	نوع خروجی یا نکته مهم	لینک آموزش کامل
HASHBYTES	تولید هش رمزنگاری‌شده	خروجی تابع از نوع varbinary است؛ SHA2_256 دقیقاً ۳۲ بایت و SHA2_512 دقیقاً ۶۴ بایت می‌سازد. نمایش HEX با CONVERT و Style شماره 2 برای گزارش و عیب‌یابی خواناتر است.	آموزش کامل HASHBYTES
ENCRYPTBYKEY	رمزنگاری با کلید متقارن	تابع یک مقدار varbinary با حداکثر طول ۸۰۰۰ بایت برمی‌گرداند. اگر کلید باز نباشد، ورودی نامعتبر باشد یا عملیات ممکن نشود، معمولاً نتیجه NULL است؛ بنابراین کنترل خروجی قبل از ذخیره ضروری است.	آموزش کامل ENCRYPTBYKEY
DECRYPTBYKEY	رمزگشایی با کلید متقارن	خروجی DECRYPTBYKEY از نوع varbinary با حداکثر ۸۰۰۰ بایت است. برای بازیابی متن باید آن را صریحاً به nvarchar یا varchar مناسب تبدیل کنید؛ نوع اشتباه می‌تواند خروجی ناخوانا یا بریده بسازد.	آموزش کامل DECRYPTBYKEY
ENCRYPTBYPASSPHRASE	رمزنگاری با عبارت عبور	خروجی varbinary با حداکثر ۸۰۰۰ بایت است. طول ciphertext از متن بیشتر خواهد بود و ستون مقصد باید ظرفیت مناسب داشته باشد. ورودی یا شرایط نامعتبر ممکن است NULL برگرداند.	آموزش کامل ENCRYPTBYPASSPHRASE
DECRYPTBYPASSPHRASE	رمزگشایی با عبارت عبور	خروجی varbinary است و برای استفاده متنی باید به نوع اولیه تبدیل شود. Passphrase یا Authenticator اشتباه معمولاً NULL می‌دهد؛ بنابراین NULL باید به‌عنوان وضعیت امنیتی و عملیاتی مدیریت شود.	آموزش کامل DECRYPTBYPASSPHRASE
SIGNBYCERT	امضای دیجیتال با گواهی	خروجی یک امضای varbinary است که باید کنار داده یا در جدول Audit ذخیره شود. امضا داده را مخفی نمی‌کند؛ خواندن متن همچنان ممکن است، اما تغییر آن با VerifySignedByCert کشف می‌شود.	آموزش کامل SIGNBYCERT
VERIFY_SIGNATURE	کنترل امضای باینری‌های Full-Text و رفع ابهام نام	FULLTEXTSERVICEPROPERTY یک int برمی‌گرداند: 1 یعنی بررسی باینری‌های امضاشده فعال، 0 یعنی غیرفعال و NULL معمولاً نشان‌دهنده ورودی نامعتبر یا خطاست. این مقدار هیچ Signature ردیفی را اعتبارسنجی نمی‌کند.	آموزش کامل VERIFY_SIGNATURE

معماری سلسله‌مراتب کلید در SQL Server

در رمزنگاری کلید متقارن، Database Master Key معمولاً از Certificate محافظت می‌کند و Certificate نیز از کلید AES نگهداری می‌کند. این زنجیره اجازه می‌دهد مجوز بازکردن و استفاده از کلید مدیریت شود. بازبودن Symmetric Key به Session وابسته است؛ تغییر نقش با EXECUTE AS لزوماً آن را نمی‌بندد و Connection Pooling باید در طراحی برنامه در نظر گرفته شود.

کلید متقارن برای حجم زیاد سریع است، اما قابلیت جست‌وجوی معمول روی ciphertext را از بین می‌برد. اگر Lookup برابر لازم است، گاهی یک ستون Hash کمکی یا قابلیت Always Encrypted با Enclave بررسی می‌شود. انتخاب باید بر پایه مدل تهدید باشد، زیرا افزودن شاخص قابل جست‌وجو ممکن است اطلاعات الگوی تکرار را افشا کند.

عبارت عبور ایجاد اشیای کلید را حذف می‌کند، اما مشکل Secret Distribution را حذف نمی‌کند. اگر ده سرویس عبارت مشترک داشته باشند، تعویض و ابطال آن دشوار می‌شود. Secret Store، نسخه‌بندی، Rotation و ثبت مصرف‌کننده‌ها برای ENCRYPTBYPASSPHRASE ضروری‌اند.

HASHBYTES: تولید هش رمزنگاری‌شده

HASHBYTES از ورودی یک اثر انگشت یک‌طرفه می‌سازد. این خروجی برای کشف تغییر، تطبیق محتوا و ساخت شناسه فنی مفید است، اما راه برگشت به متن اولیه ندارد و جایگزین رمزنگاری قابل بازیابی نیست. برای ذخیره گذرواژه تنها هش مستقیم کافی نیست؛ مهاجم می‌تواند با جدول‌های ازپیش‌محاسبه‌شده حمله کند. مدیریت هویت باید از الگوریتم کند و Salt منحصربه‌فرد در لایه برنامه استفاده کند. HASHBYTES بیشتر برای یکپارچگی و تطبیق داده سازمانی مناسب است.

خروجی و نکته مهم: خروجی تابع از نوع varbinary است؛ SHA2_256 دقیقاً ۳۲ بایت و SHA2_512 دقیقاً ۶۴ بایت می‌سازد. نمایش HEX با CONVERT و Style شماره 2 برای گزارش و عیب‌یابی خواناتر است.

مطالعه مقاله تخصصی HASHBYTES با ۱۰ مثال عملی

ENCRYPTBYKEY: رمزنگاری با کلید متقارن

ENCRYPTBYKEY داده را با کلید متقارنِ موجود در سلسله‌مراتب رمزنگاری پایگاه داده تبدیل می‌کند. کلید متقارن برای حجم زیاد سریع‌تر از رمزنگاری نامتقارن است و معمولاً توسط Certificate محافظت می‌شود. بازبودن کلید به Session وابسته است، نه Security Context. کمترین مجوز، ثبت چرخه عمر کلید، Backup گواهی و Master Key و جداسازی نقش‌های خواندن و رمزگشایی از اصول حیاتی‌اند. Authenticator احتمال جابه‌جایی ciphertext میان ردیف‌ها را کم می‌کند.

خروجی و نکته مهم: تابع یک مقدار varbinary با حداکثر طول ۸۰۰۰ بایت برمی‌گرداند. اگر کلید باز نباشد، ورودی نامعتبر باشد یا عملیات ممکن نشود، معمولاً نتیجه NULL است؛ بنابراین کنترل خروجی قبل از ذخیره ضروری است.

مطالعه مقاله تخصصی ENCRYPTBYKEY با ۱۰ مثال عملی

DECRYPTBYKEY: رمزگشایی با کلید متقارن

DECRYPTBYKEY ciphertext ساخته‌شده با کلید متقارن باز در Session را به بایت‌های اولیه برمی‌گرداند. تابع نام کلید نمی‌گیرد، زیرا اطلاعات لازم در ciphertext وجود دارد و SQL Server کلید باز مناسب را پیدا می‌کند. اعطای SELECT روی جدول نباید به‌تنهایی به معنای اجازه رمزگشایی باشد. دسترسی به Certificate، کلید و رویه رمزگشایی را محدود کنید و داده واضح را در Log، جدول موقت طولانی‌عمر یا خروجی عمومی قرار ندهید.

خروجی و نکته مهم: خروجی DECRYPTBYKEY از نوع varbinary با حداکثر ۸۰۰۰ بایت است. برای بازیابی متن باید آن را صریحاً به nvarchar یا varchar مناسب تبدیل کنید؛ نوع اشتباه می‌تواند خروجی ناخوانا یا بریده بسازد.

مطالعه مقاله تخصصی DECRYPTBYKEY با ۱۰ مثال عملی

ENCRYPTBYPASSPHRASE: رمزنگاری با عبارت عبور

ENCRYPTBYPASSPHRASE بدون ایجاد شیء کلید در Database، از یک عبارت عبور برای رمزنگاری استفاده می‌کند. سادگی آن برای ابزارهای کوچک جذاب است، ولی توزیع، نگهداری، تعویض و Audit عبارت عبور بر عهده معماری برنامه می‌ماند. عبارت عبور را در متن Query، Source Control، Job Step و فایل تنظیمات ساده قرار ندهید. Secret Store و تزریق امن در Session یا Stored Procedure کنترل‌شده مناسب‌تر است. برای سامانه بزرگ، سلسله‌مراتب کلید SQL Server یا Always Encrypted معمولاً قابلیت اداره بهتری دارد.

خروجی و نکته مهم: خروجی varbinary با حداکثر ۸۰۰۰ بایت است. طول ciphertext از متن بیشتر خواهد بود و ستون مقصد باید ظرفیت مناسب داشته باشد. ورودی یا شرایط نامعتبر ممکن است NULL برگرداند.

مطالعه مقاله تخصصی ENCRYPTBYPASSPHRASE با ۱۰ مثال عملی

DECRYPTBYPASSPHRASE: رمزگشایی با عبارت عبور

DECRYPTBYPASSPHRASE مکمل ENCRYPTBYPASSPHRASE است و با عبارت عبور درست، ciphertext را بازیابی می‌کند. تابع از اشیای کلید Database استفاده نمی‌کند و همین موضوع هم سادگی و هم مسئولیت بیشتر برای مدیریت Secret ایجاد می‌کند. متن واضح را فقط در کوچک‌ترین محدوده لازم تولید کنید. Stored Procedure باید نتیجه را به مصرف‌کننده مجاز برگرداند، از چاپ Secret یا plaintext جلوگیری کند و رخداد شکست رمزگشایی را بدون ثبت خود داده حساس گزارش دهد.

خروجی و نکته مهم: خروجی varbinary است و برای استفاده متنی باید به نوع اولیه تبدیل شود. Passphrase یا Authenticator اشتباه معمولاً NULL می‌دهد؛ بنابراین NULL باید به‌عنوان وضعیت امنیتی و عملیاتی مدیریت شود.

مطالعه مقاله تخصصی DECRYPTBYPASSPHRASE با ۱۰ مثال عملی

SIGNBYCERT: امضای دیجیتال با گواهی

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

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

مطالعه مقاله تخصصی SIGNBYCERT با ۱۰ مثال عملی

VERIFY_SIGNATURE: کنترل امضای باینری‌های Full-Text و رفع ابهام نام

در T-SQL تابع اسکالر رمزنگاری به نام VERIFY_SIGNATURE وجود ندارد. VerifySignature نام یک Property در موتور Full-Text است که با FULLTEXTSERVICEPROPERTY خوانده و با sys.sp_fulltext_service مدیریت می‌شود. برای داده امضاشده با SIGNBYCERT باید VerifySignedByCert را فراخوانی کرد. خاموش‌کردن verify_signature اجازه می‌دهد Full-Text باینری‌های بدون بررسی اعتماد را بارگذاری کند و سطح حمله را بالا می‌برد. تغییر این گزینه Server-wide است، مجوز بالا می‌خواهد و باید فقط با Change Management، ارزیابی افزونه‌ها و برنامه بازگشت انجام شود.

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

مطالعه مقاله تخصصی VERIFY_SIGNATURE با ۱۰ مثال عملی

انتخاب قابلیت بر اساس سناریو

نیاز	انتخاب اولیه	ملاحظه معماری
تشخیص تغییر محتوا	HASHBYTES با SHA2	هویت تولیدکننده را ثابت نمی‌کند.
رمزنگاری ستونی قابل مدیریت	ENCRYPTBYKEY و DECRYPTBYKEY	Backup و چرخه عمر کلید الزامی است.
ابزار کوچک با Secret مشترک	ENCRYPTBYPASSPHRASE و DECRYPTBYPASSPHRASE	Secret Distribution ریسک اصلی است.
اثبات اصالت و تمامیت سند	SIGNBYCERT و VERIFYSIGNEDBYCERT	امضا محرمانگی ایجاد نمی‌کند.
اعتماد باینری‌های Full-Text	VerifySignature	Property سطح Server است، نه تابع ردیفی.
دور نگه‌داشتن plaintext از موتور	Always Encrypted	نیازمند Driver و طراحی کلید سمت Client است.

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

شش مثال کاربردی ترکیبی

نمونه‌های زیر نمای کلی هستند؛ در صفحات مستقل هر موضوع ده مثال با جزئیات بیشتر ارائه شده است.

مثال 1: ساخت هش SHA2-256

برای اثر انگشت محتوا از الگوریتم مدرن SHA2 استفاده می‌شود.

SELECT HASHBYTES('SHA2_256',N'محتوای سند') AS ContentHash;

نتیجه نمونه	کاربرد
varbinary(32)	هش یک‌طرفه است و متن را رمز نمی‌کند.

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

مثال 2: رمزنگاری و بازیابی با Passphrase

یک Round-trip ساده برای ابزار محدود نمایش داده می‌شود.

DECLARE @C varbinary(8000)=ENCRYPTBYPASSPHRASE(N'Demo#1405!',N'پیام');
SELECT CONVERT(nvarchar(20),DECRYPTBYPASSPHRASE(N'Demo#1405!',@C)) AS PlainText;

نتیجه نمونه	کاربرد
PlainText برابر «پیام»	Passphrase تولیدی باید خارج از Query نگهداری شود.

نکته فنی: Passphrase تولیدی باید خارج از Query نگهداری شود.

مثال 3: رمزنگاری با کلید متقارن

AES_256 در سلسله‌مراتب کلید Database استفاده می‌شود.

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_Encryption_Cert') IS NULL
    CREATE CERTIFICATE Article_Encryption_Cert WITH SUBJECT = N'گواهی آزمایشی مقاله رمزنگاری';
IF NOT EXISTS (SELECT 1 FROM sys.symmetric_keys WHERE name = N'Article_AES256_Key')
    CREATE SYMMETRIC KEY Article_AES256_Key
    WITH ALGORITHM = AES_256
    ENCRYPTION BY CERTIFICATE Article_Encryption_Cert;
OPEN SYMMETRIC KEY Article_AES256_Key DECRYPTION BY CERTIFICATE Article_Encryption_Cert;
DECLARE @C varbinary(8000)=ENCRYPTBYKEY(KEY_GUID(N'Article_AES256_Key'),N'راز سازمانی');
SELECT CONVERT(nvarchar(50),DECRYPTBYKEY(@C)) AS PlainText;
CLOSE SYMMETRIC KEY Article_AES256_Key;

نتیجه نمونه	کاربرد
PlainText برابر «راز سازمانی»	باز و بسته‌کردن کلید در همان Session انجام می‌شود.

نکته فنی: باز و بسته‌کردن کلید در همان Session انجام می‌شود.

مثال 4: استفاده از Authenticator ردیف

ciphertext به شناسه مشتری متصل می‌شود.

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_Encryption_Cert') IS NULL
    CREATE CERTIFICATE Article_Encryption_Cert WITH SUBJECT = N'گواهی آزمایشی مقاله رمزنگاری';
IF NOT EXISTS (SELECT 1 FROM sys.symmetric_keys WHERE name = N'Article_AES256_Key')
    CREATE SYMMETRIC KEY Article_AES256_Key
    WITH ALGORITHM = AES_256
    ENCRYPTION BY CERTIFICATE Article_Encryption_Cert;
OPEN SYMMETRIC KEY Article_AES256_Key DECRYPTION BY CERTIFICATE Article_Encryption_Cert;
DECLARE @C varbinary(8000)=ENCRYPTBYKEY(KEY_GUID(N'Article_AES256_Key'),N'09120000000',1,N'Customer:10');
SELECT CONVERT(nvarchar(20),DECRYPTBYKEY(@C,1,N'Customer:10')) AS Mobile;
CLOSE SYMMETRIC KEY Article_AES256_Key;

نتیجه نمونه	کاربرد
شماره موبایل اولیه	Authenticator کپی ciphertext بین ردیف‌ها را سخت‌تر می‌کند.

نکته فنی: Authenticator کپی ciphertext بین ردیف‌ها را سخت‌تر می‌کند.

مثال 5: امضا و کنترل دستکاری

سند با 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 @D nvarchar(100)=N'سند نهایی';
DECLARE @S varbinary(8000)=SIGNBYCERT(CERT_ID(N'Article_Signing_Cert'),@D);
SELECT VERIFYSIGNEDBYCERT(CERT_ID(N'Article_Signing_Cert'),@D,@S) AS IsValid;

نتیجه نمونه	کاربرد
IsValid برابر 1	امضا تمامیت را می‌سنجد و محرمانگی ایجاد نمی‌کند.

نکته فنی: امضا تمامیت را می‌سنجد و محرمانگی ایجاد نمی‌کند.

مثال 6: پایش VerifySignature موتور Full-Text

تنظیم امنیتی Server بدون تغییر خوانده می‌شود.

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

نتیجه نمونه	کاربرد
معمولاً VerifySignature برابر 1	این Property با اعتبارسنجی امضای داده متفاوت است.

نکته فنی: این Property با اعتبارسنجی امضای داده متفاوت است.

خطاهای رایج در پروژه‌های رمزنگاری

استفاده از MD5 یا SHA1 برای طراحی امنیتی جدید و تصور امنیت کافی.
نگهداری Password یا Passphrase داخل Source Control، Job Step یا متن Query.
بازکردن دسترسی رمزگشایی برای نقش گزارش عمومی و بی‌اثرکردن اصل کمترین دسترسی.
نداشتن Backup مستقل و آزموده‌شده از Certificate و Private Key.
رمزگشایی همه ردیف‌ها پیش از Filter و ایجاد هزینه CPU و خطر نشت انبوه.
تبدیل ناهماهنگ varchar و nvarchar که Hash یا Signature متفاوت می‌سازد.
نادیده‌گرفتن Authenticator و امکان جابه‌جایی ciphertext میان ردیف‌ها.
یکی‌دانستن TLS، TDE، Always Encrypted و رمزنگاری ستونی؛ هر کدام مرز تهدید متفاوت دارند.

عیب‌یابی باید در محیط کنترل‌شده و با داده غیرحساس انجام شود. Extended Events، Query Store، STATISTICS TIME و DMVهای مجوز می‌توانند اطلاعات فنی بدهند، اما Session پایش نباید پارامتر، plaintext یا Secret را ثبت کند.

Performance، پایش و بهینه‌سازی

توابع رمزنگاری و Hash CPU مصرف می‌کنند و ciphertext معمولاً از متن اولیه بزرگ‌تر است. هزینه روی یک ردیف ممکن است ناچیز باشد، اما در Batch میلیونی یا گزارش همزمان قابل توجه می‌شود. Baseline را پیش از تغییر ثبت کنید و همان Dataset، Plan، همزمانی و سخت‌افزار را پس از تغییر مقایسه کنید.

مهم‌ترین الگو این است که Predicateهای ایندکس‌پذیر روی ستون‌های غیرحساس ابتدا مجموعه را محدود کنند و سپس Decrypt یا Verify انجام شود. اجرای تابع روی ستون در WHERE می‌تواند Scan ایجاد کند. برای جست‌وجوی برابر، Hash ازپیش‌محاسبه‌شده با Salt یا Pepper مناسب و تحلیل نشت الگو بررسی می‌شود.

عملیات بازکردن کلید را برای یک واحد کاری Batch کنید و کلید را بی‌دلیل باز نگذارید. مدت Transaction، رشد Log، فشار TempDB و هزینه Replication یا Availability Group را هم بسنجید. هدف فقط کوتاه‌شدن Duration نیست؛ طراحی باید در Failover و Restore نیز درست بماند.

Best Practices سازمانی

داده را بر اساس حساسیت و مالک کسب‌وکار طبقه‌بندی کنید.
Threat Model و مرز اعتماد SQL Server، برنامه و DBA را مشخص کنید.
الگوریتم و قابلیت را با نسخه مقصد و سیاست سازمان تطبیق دهید.
نوع ورودی canonical، Unicode، طول و رفتار NULL را مستند کنید.
مجوزها را حداقلی و مسیر رمزگشایی را متمرکز کنید.
Backup کلید و گواهی را رمزگذاری و Restore را دوره‌ای تمرین کنید.
Rotation، Revocation و نسخه‌بندی Secret را قبل از Go-live طراحی کنید.
Performance و ظرفیت را با بار نماینده اندازه‌گیری کنید.
Audit را بدون ثبت plaintext و Secret پیاده‌سازی کنید.
Runbook رخداد، مالک پاسخ‌گویی و معیار توقف سرویس را تعیین کنید.

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

1. تفاوت هش و رمزنگاری در SQL Server چیست؟

هش یک‌طرفه و مناسب تشخیص تغییر است؛ رمزنگاری با داشتن کلید یا Passphrase قابل بازیابی است. انتخاب اشتباه می‌تواند یا محرمانگی را از بین ببرد یا داده لازم را غیرقابل بازیابی کند.

2. برای طراحی جدید کدام الگوریتم هش مناسب‌تر است؟

در قابلیت HASHBYTES معمولاً SHA2_256 یا SHA2_512 انتخاب می‌شود. MD5 و SHA1 برای طراحی امنیتی جدید توصیه نمی‌شوند و سازگاری نسخه مقصد باید بررسی شود.

3. کلید متقارن چه مزیتی نسبت به Passphrase دارد؟

کلید متقارن در سلسله‌مراتب امنیتی Database قابل مدیریت، مجوزدهی، Backup و چرخش است؛ Passphrase ساده‌تر اما توزیع و نگهداری آن کاملاً بر عهده معماری برنامه می‌ماند.

4. Authenticator چه مشکلی را حل می‌کند؟

Authenticator ciphertext را به یک مقدار پایدار مانند شناسه ردیف متصل می‌کند و جابه‌جایی رمز میان ردیف‌ها را قابل کشف می‌سازد. این قابلیت جایگزین Authorization نیست.

5. آیا SIGNBYCERT داده را مخفی می‌کند؟

خیر. امضای دیجیتال برای اصالت و تمامیت است؛ متن همچنان خوانا می‌ماند. برای محرمانگی باید کنترل دسترسی یا رمزنگاری مناسب جداگانه داشت.

6. VERIFY_SIGNATURE برای امضای داده است؟

خیر. VerifySignature نام Property موتور Full-Text برای بررسی باینری‌هاست. تابع صحیح بررسی داده امضاشده با Certificate، یعنی VERIFYSIGNEDBYCERT، مفهوم دیگری دارد.

7. برای پروژه تجاری رمزنگاری SQL Server از کجا شروع کنیم؟

با طبقه‌بندی داده، Threat Model، فهرست مصرف‌کنندگان، الزامات قانونی و هدف بازیابی شروع کنید. سپس Proof of Concept، Benchmark و Runbook پیاده‌سازی و Restore تهیه شود.

8. چرا تابع رمزنگاری گاهی NULL برمی‌گرداند؟

کلید باز نیست، مجوز یا Authenticator هماهنگ نیست، Passphrase اشتباه است، ورودی NULL یا محدودیت طول رخ داده است. مسیر خطا باید این وضعیت‌ها را بدون افشای Secret تفکیک کند.

9. رمزنگاری چه اثری روی Performance دارد؟

مصرف CPU، افزایش اندازه داده و کاهش قابلیت جست‌وجوی مستقیم از آثار رایج است. Filter پیش از Decrypt، Batch مناسب و Benchmark روی بار واقعی راهنمای تصمیم‌اند.

10. آیا این قابلیت‌ها در همه نسخه‌ها یکسان‌اند؟

خیر. الگوریتم‌ها، محدودیت طول، سرویس‌های ابری و Permissionها می‌توانند تفاوت داشته باشند. مستند نسخه مقصد و آزمون Stage مبنای نهایی سازگاری است.

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

چرا HASHBYTES جایگزین رمزنگاری نیست؟

چون یک‌طرفه است و برای بازیابی plaintext طراحی نشده است؛ کاربرد اصلی آن اثر انگشت و تشخیص تغییر است.

چرا Authenticator مهم است؟

ciphertext را به زمینه ردیف متصل می‌کند و جابه‌جایی میان موجودیت‌ها را قابل کشف می‌سازد.

چرا Filter باید قبل از Decrypt باشد؟

برای کاهش عملیات CPU، حفظ استفاده از ایندکس و محدودکردن دامنه افشای متن واضح.

تفاوت SIGNBYCERT با ENCRYPTBYKEY چیست؟

اولی اصالت و تمامیت را فراهم می‌کند و دومی برای محرمانگی قابل بازیابی است.

برنامه بازیابی کلید چه اجزایی دارد؟

Backup امن، Password خارج از Backup، مستند وابستگی، تست Restore و زمان‌بندی Rotation و Revocation.

جمع‌بندی و مسیر ادامه

طراحی امن با انتخاب هدف شروع می‌شود: Hash برای تمامیت، Encryption برای محرمانگی، Signature برای اصالت و Propertyهای Full-Text برای اعتماد به باینری‌های موتور. هیچ تابعی جای طبقه‌بندی داده، مجوز حداقلی، Backup و عملیات پاسخ‌گویی به رخداد را نمی‌گیرد.

برای پیاده‌سازی، ابتدا یک Proof of Concept با داده غیرحساس بسازید، خروجی و Performance را اندازه بگیرید، Restore را تمرین کنید و سپس با Change Management به محیط تولید بروید. پیوندهای زیر دسترسی مستقیم به مقاله تخصصی هر موضوع را فراهم می‌کنند.

توابع رمزنگاری SQL Server؛ آموزش جامع هش، AES و امضای دیجیتال

آموزش جامع توابع رمزنگاری در SQL Server