security policy در Sql Server

🧠 مفهوم Security Policy در SQL Server

در SQL Server، Security Policy یک مکانیزم برای تعریف و اعمال محدودیت‌های دسترسی به داده‌ها است.

این قابلیت در واقع بخشی از Row-Level Security (RLS) است و به شما این امکان را می‌دهد که سیاست‌های امنیتی سطح سطر را تعریف کرده و فقط به کاربران خاص اجازه مشاهده یا ویرایش داده‌های خاص بدهید.

🔐 ویژگی‌های Security Policy در SQL Server  

1. پیاده‌سازی سطح سطر (Row-Level Security - RLS)

Security Policy قابلیت پیاده‌سازی امنیت در سطح سطرها را دارد، به این معنا که می‌توان تعیین کرد چه کاربری به کدام سطرها در یک جدول دسترسی داشته باشد. مثلاً کاربر "Ali" فقط رکوردهایی را می‌بیند که مربوط به خودش است.

📌 مزیت: بدون نیاز به تغییر در اپلیکیشن، محدودیت‌های دقیق بر اساس داده اعمال می‌شود.

2. استفاده از توابع Table-Valued برای اعمال منطق امنیتی

در این قابلیت، شما منطق دسترسی را در قالب یک تابع Table-Valued Function تعریف می‌کنید. این تابع مشخص می‌کند که کدام سطرها برای کاربر فعلی قابل مشاهده یا ویرایش هستند.

📌 مزیت: جداسازی کامل منطق امنیت از منطق برنامه، امکان تست و تغییر ساده‌تر آن.

3. اعمال خودکار و شفاف (Transparent Enforcement)

Security Policy به‌صورت خودکار روی کوئری‌ها اعمال می‌شود، بدون اینکه کاربر یا توسعه‌دهنده مجبور باشد آن را در هر کوئری لحاظ کند. مثلاً:

SELECT * FROM Orders;

به‌صورت خودکار فیلتر بر اساس Policy را اجرا می‌کند.

📌 مزیت: خطای انسانی در اعمال محدودیت‌های دسترسی از بین می‌رود.

4. قابل اعمال بر عملیات SELECT، INSERT، UPDATE

شما می‌توانید از دو نوع Predicate استفاده کنید:

FILTER Predicate: محدود کردن داده‌هایی که کاربر می‌تواند ببیند (SELECT).

BLOCK Predicate: محدود کردن سطرهایی که کاربر می‌تواند وارد یا تغییر دهد (INSERT, UPDATE, DELETE).

📌 مزیت: کنترل کامل بر خواندن، نوشتن و حذف داده‌ها.

5. قابلیت فعال‌سازی و غیرفعال‌سازی (STATE ON/OFF)

Policyها را می‌توان بدون حذف، فقط غیرفعال کرد:

ALTER SECURITY POLICY MyPolicy WITH (STATE = OFF);

📌 مزیت: امکان تست یا بررسی بدون نیاز به حذف و بازسازی policy.

6. سازگاری با چندین Policy در یک جدول

امکان استفاده از چند Policy روی یک جدول وجود دارد. مثلاً یک Policy برای فیلتر و دیگری برای جلوگیری از Insert کردن داده توسط کاربران خاص.

📌 مزیت: انعطاف بالا در طراحی امنیت چندلایه.

7. بدون نیاز به تغییر ساختار جدول یا View

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

📌 مزیت: ساده‌سازی توسعه و نگهداری پایگاه داده.

8. پشتیبانی از چند tenant (multi-tenancy)

در برنامه‌هایی که چند مشتری (tenant) دارند، Security Policy می‌تواند تضمین کند که هر کاربر فقط داده‌های خود را ببیند.

📌 مزیت: مناسب برای اپلیکیشن‌های SaaS و محیط‌های اشتراکی با امنیت بالا.

9. هماهنگی با نقش‌ها و کاربران ویندوزی یا SQL Server

می‌توان در توابع امنیتی از توابع داخلی مثل USER_NAME(), SUSER_SNAME(), SESSION_CONTEXT() استفاده کرد تا دسترسی را بر اساس کاربر جاری یا نقش تعیین کرد.

📌 مزیت: امکان یکپارچه‌سازی آسان با سیستم‌های احراز هویت موجود.

10. قابل استفاده همراه با دیگر ویژگی‌های امنیتی

Security Policy می‌تواند با ویژگی‌هایی مانند Dynamic Data Masking، Encryption و Permission Management ترکیب شود تا یک لایه امنیتی کامل ایجاد شود.

📌 مزیت: ایجاد سیستم امنیتی جامع با چند سطح حفاظتی.

✅ مزایای استفاده از Security Policy در SQL Server 

1. افزایش امنیت در سطح سطر (Row-Level Security)

Security Policy باعث می‌شود تنها داده‌هایی که کاربر اجازه دارد، برای او قابل مشاهده یا ویرایش باشد. این موضوع در حفاظت از اطلاعات حساس، مانند حقوق کارمندان یا سوابق مالی کاربران، بسیار حیاتی است.

📌 مثال: کارمند بخش فروش فقط اطلاعات مشتریان منطقه خودش را می‌بیند، نه همه مشتری‌ها.

2. اجرای شفاف و خودکار (Transparent Enforcement)

کوئری‌ها نیازی به تغییر ندارند. سیاست امنیتی به‌طور خودکار به تمام SELECT، UPDATE، DELETE و INSERT اعمال می‌شود. کاربر بدون آن‌که متوجه شود، فقط داده‌های مجاز را می‌بیند.

📌 مثال: دستور SELECT * FROM Sales برای دو کاربر مختلف نتایج متفاوتی دارد، بدون تغییر در کوئری.

3. جدا بودن منطق امنیت از منطق برنامه

با استفاده از Security Policy، منطق امنیتی به‌صورت جداگانه تعریف می‌شود و در داخل برنامه کاربردی یا کوئری‌ها نیاز به کنترل دستی نیست.

📌 مزیت: کدهای برنامه ساده‌تر، قابل نگهداری‌تر و ایمن‌تر می‌شوند.

4. یکپارچگی با احراز هویت SQL و ویندوز

Security Policy از توابع سیستمی مثل USER_NAME(), SUSER_SNAME(), SESSION_CONTEXT() پشتیبانی می‌کند که امکان ارتباط مستقیم بین سیاست امنیتی و هویت کاربر را فراهم می‌کند.

📌 مثال: کاربرانی که از طریق Active Directory وارد می‌شوند، به‌صورت خودکار محدود می‌شوند.

5. بدون نیاز به ایجاد View یا تغییر ساختار جدول

برخلاف روش‌های سنتی که نیاز به ایجاد View برای اعمال فیلتر دارند، Security Policy مستقیماً روی جدول اصلی اعمال می‌شود.

📌 مزیت: کاهش پیچیدگی در طراحی دیتابیس و بهبود عملکرد کلی سیستم.

6. سازگار با محیط‌های چندمشتری (Multi-Tenant)

در اپلیکیشن‌هایی مانند SaaS که چندین مشتری از یک دیتابیس استفاده می‌کنند، Security Policy تضمین می‌کند که داده‌های هر مشتری برای دیگران قابل مشاهده نیست.

📌 مثال: کاربران فروشگاه A نمی‌توانند اطلاعات مشتریان فروشگاه B را ببینند.

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

وقتی فیلترها در برنامه‌ها یا Viewها نوشته می‌شوند، احتمال فراموشی یا اشتباه زیاد است. Security Policy این فیلترها را سیستماتیک و مرکزی می‌کند.

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

8. قابل تغییر و تست بدون حذف Policy

شما می‌توانید یک Policy را غیرفعال (STATE = OFF) کنید، آن را تغییر دهید و مجدداً فعال کنید. این قابلیت در فرآیند توسعه، تست یا رفع اشکال بسیار مفید است.

📌 مثال: در زمان عیب‌یابی یا بازنگری قوانین امنیتی، نیازی به حذف Policy ندارید.

9. سازگار با انواع عملیات (SELECT, INSERT, UPDATE, DELETE)

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

📌 مثال: کاربری فقط می‌تواند داده‌های منطقه خودش را ویرایش کند، نه مناطق دیگر.

10. کاهش بار امنیت در سمت کلاینت

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

📌 مزیت: اگر کلاینت دچار باگ یا نفوذ شود، داده‌های محافظت‌شده همچنان در سطح SQL Server ایمن می‌مانند.

11. افزایش انعطاف‌پذیری در مدیریت سطوح دسترسی

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

📌 مثال: کاربران "مدیر فروش" می‌توانند کل کشور را ببینند، اما "کارشناس فروش" فقط استان خودش را.

12. قابل استفاده در ترکیب با سایر ویژگی‌های امنیتی

Security Policy به‌راحتی با ویژگی‌هایی مانند:

Dynamic Data Masking

Column-Level Encryption

Auditing
قابل ترکیب است و یک زیرساخت امنیتی جامع ایجاد می‌کند.

🔁 مقایسه Security Policy با روش‌های دیگر کنترل دسترسی

 

🌟 آیا می‌خواهید به یک متخصص پایگاه داده تبدیل شوید و در دنیای فناوری اطلاعات بدرخشید؟

با دوره آموزشی SQL Server ما، شما می‌توانید به راحتی و با روشی عملی، تمام مهارت‌های لازم را یاد بگیرید!

این دوره به شما آموزش می‌دهد که چگونه داده‌ها را به بهترین شکل مدیریت کنید، گزارش‌های قدرتمند بسازید و به تحلیل‌های عمیق دست یابید.

با محتوای جذاب و پروژه‌های واقعی، شما نه تنها تئوری را یاد می‌گیرید، بلکه توانایی‌های عملی خود را نیز تقویت می‌کنید.

پس فرصت را از دست ندهید! همین امروز به جمع یادگیرندگان ما بپیوندید و اولین قدم را به سوی آینده شغلی روشن‌تر بردارید!

 ⇐همین حالا شروع کنید و به دنیای داده‌ها بپیوندید!

 

🛠️ آموزش کامل Security Policy در SQL Server

1. ساخت جدول نمونه:
 

CREATE TABLE Sales (
    Id INT PRIMARY KEY,
    CustomerId INT,
    Amount MONEY,
    Region NVARCHAR(50)
);

2. ساخت تابع امنیتی:
 

CREATE FUNCTION dbo.fn_securitypredicate(@Region AS NVARCHAR(50))
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS fn_securitypredicate_result
WHERE @Region = USER_NAME();  -- فرض بر این است که نام کاربر معادل Region باشد

3. تعریف Security Policy:

CREATE SECURITY POLICY SalesSecurityPolicy
ADD FILTER PREDICATE dbo.fn_securitypredicate(Region)
ON dbo.Sales
WITH (STATE = ON);

4. تست و مشاهده نتیجه:

 INSERT INTO Sales (Id, CustomerId, Amount, Region) VALUES
(1, 2, 250000, N'Tehran'),
(2, 1002, 180000, N'Tabriz'),
(3, 1003, 320000, N'Tehran') 

 SELECT * FROM Sales;  -- فقط رکوردهایی را نشان می‌دهد که Region با USER_NAME برابر باشد.

چون  SecurityPolicy فعال است در جدول بدیل امنیتی چیزی نمایش نمیدهد.

5. غیرفعال کردن Policy:
 

ALTER SECURITY POLICY SalesSecurityPolicy
WITH (STATE = OFF);

دوباره مجدد تست میکنیم

 SELECT * FROM Sales;  -- فقط رکوردهایی را نشان می‌دهد که Region با USER_NAME برابر باشد.

💼 مثال‌های کاربردی security policy در Sql Server

مثال 1: محدود کردن دسترسی بر اساس نقش کاربر
 

-- تابع بررسی نقش

CREATE FUNCTION dbo.fn_role_based_security(@UserName AS NVARCHAR(50))
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS fn_securitypredicate_result
WHERE @UserName IN ('sales_north', 'manager');

📝 تمرین security policy در Sql Server برای دانشجویان

یک جدول به نام EmployeeData بسازید که شامل Id, Name, Department باشد.

تابعی ایجاد کنید که دسترسی را تنها به کاربرانی بدهد که نام آن‌ها با مقدار Department مطابقت دارد.

Security Policy مربوطه را بنویسید.

تست کنید که کاربری که با نام "IT" لاگین کرده فقط کارمندان بخش IT را می‌بیند.

📌 جمع‌بندی

Security Policy در SQL Server ابزاری قدرتمند برای پیاده‌سازی امنیت سطح سطر است.

این ویژگی با استفاده از توابع و سیاست‌های از پیش تعریف‌شده، کنترل دقیقی بر دسترسی کاربران به داده‌ها فراهم می‌آورد.

در مقایسه با روش‌های سنتی مانند View یا Application-level Filtering، این روش بسیار امن‌تر و قابل نگهداری‌تر است.

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