120 lines
12 KiB
Markdown
120 lines
12 KiB
Markdown
# مشخصات درس‌نامه: امنیت پایگاه داده با Row Level Security (RLS)
|
||
- **شناسه در سیلابس:** `L7.8`
|
||
- **فصل:** فصل ۷: داده و بک‌اند (Ch 7)
|
||
- **نوع محتوا:** 📘 درس‌نامه متنی
|
||
- **زمان تقریبی مطالعه:** ۱۲ دقیقه
|
||
- **پیش‌نیازهای مستقیم:** `L7.7` (احراز هویت)
|
||
|
||
---
|
||
|
||
## ۱. اهداف یادگیری (Learning Objectives - Bloom's Taxonomy)
|
||
دانشجو پس از مطالعهٔ این درس‌نامه باید بتواند:
|
||
- [ ] **درک کند (Understand):** سازوکار امنیت در سطح ردیف (Row Level Security - RLS) در پایگاه داده PostgreSQL چیست و چرا به عنوان دیوار آتشین و غیرقابل نفوذ دیتابیس عمل می‌کند.
|
||
- [ ] **تحلیل/ارزیابی کند (Evaluate):** خطر هولناک غیرفعال بودن RLS را تحلیل کند و بداند چرا بدون RLS، هر فرد متفرقه‌ای با داشتن کلید عمومی `anon key` می‌تواند کل داده‌های پروژه را با یک درخواست ساده پاک کند.
|
||
- [ ] **به‌کار ببندد (Apply):** قابلیت RLS را روی جداول پروژه محوری (`projects` و `site_settings`) در پیشخوان Supabase یا با دستورات SQL فعال سازد.
|
||
- [ ] **به‌کار ببندد (Apply):** دو سیاست امنیتی استاندارد را پیاده‌سازی کند: **سیاست خواندن عمومی برای همه کاربران (Public Read via SELECT)** و **سیاست نگارش، ویرایش و حذف منحصراً برای ادمین لاگین‌شده (`auth.role() = 'authenticated'`)**.
|
||
- [ ] **به‌کار ببندد (Apply):** عملکرد قوانین امنیتی را با باز کردن سایت در تب ناشناس (Incognito) و تلاش برای ویرایش غیرمجاز تست و راستی‌آزمایی کند.
|
||
|
||
---
|
||
|
||
## ۲. محدوده و مرزهای محتوا (Scope & Boundaries)
|
||
|
||
### آنچه باید پوشش داده شود (In-Scope):
|
||
1. **کابوس بزرگ وب بدون RLS:**
|
||
* از آنجا که کلید عمومی `anon key` در کدهای فرانت‌اند مرورگر قرار دارد، اگر RLS فعال نباشد، هر هکر یا کاربری می‌تواند با ابزارهایی مثل Postman یا دستور `curl`، یک درخواست `DELETE` به سرور بفرستد و در یک ثانیه تمام کارهای پورتفولیو را پاک کند!
|
||
* دیوار آتشین RLS کاری می‌کند که خود موتور دیتابیس PostgreSQL پیش از اجرای هر عملیاتی بپرسد: «آیا این کاربر اجازه این کار را دارد؟»
|
||
2. **سازوکار امنیت در سطح ردیف (Row Level Security چیست؟):**
|
||
* قوانینی که مستقیماً در لایه عمیق پایگاه داده (نه در فرانت‌اند) تعریف و اعمال می‌شوند.
|
||
* حتی اگر کسی کدهای فرانت‌اند شما را دور بزند، دیتابیس بدون مجوز اجازه عبور نخواهد داد.
|
||
3. **تعریف سیاست‌های امنیتی (Security Policies) برای پروژه پورتفولیو:**
|
||
* **سیاست‌های جدول پروژه‌ها (`projects`):**
|
||
* **قانون ۱ (خواندن برای عموم آزاد):** همه افراد در جهان باید بتوانند نمونه‌کارها را ببینند:
|
||
```sql
|
||
CREATE POLICY "Public projects are viewable by everyone"
|
||
ON projects FOR SELECT
|
||
USING (true);
|
||
```
|
||
* **قانون ۲ (فقط ادمین لاگین‌شده حق ویرایش دارد):** فقط کاربری که با موفقیت در Supabase Auth لاگین کرده اجازه ثبت، ویرایش و حذف دارد:
|
||
```sql
|
||
CREATE POLICY "Only authenticated admin can insert, update, delete"
|
||
ON projects FOR ALL
|
||
TO authenticated
|
||
USING (true);
|
||
```
|
||
* **سیاست‌های جدول تنظیمات سئو (`site_settings`):**
|
||
* خواندن تنظیمات برای عموم آزاد (`FOR SELECT USING (true)`).
|
||
* ویرایش تنظیمات فقط توسط ادمین تاییدشده (`FOR UPDATE TO authenticated`).
|
||
4. **اسکریپت کامل فعال‌سازی RLS با SQL:**
|
||
* دستورات صریح فعال‌سازی:
|
||
```sql
|
||
ALTER TABLE projects ENABLE ROW LEVEL SECURITY;
|
||
ALTER TABLE site_settings ENABLE ROW LEVEL SECURITY;
|
||
```
|
||
5. **تست و سنجش امنیت در عمل:**
|
||
* باز کردن صفحه اصلی در تب ناشناس مرورگر: همه پروژه‌ها به درستی نمایش داده می‌شوند (تست موفق قانون SELECT).
|
||
* تلاش برای ارسال درخواست ایجاد یا حذف بدون ورود: دریافت خطای قاطع `403 Forbidden / Row Level Security Violation`.
|
||
6. **کال‌اوت‌های Quera:**
|
||
* `<details class="violet">`: چرا امنیت در سطح پایگاه داده (Database-Level Security) هزاران بار نفوذناپذیرتر از چک‌های ظاهری در کدهای جاوااسکریپت است؟
|
||
* `<details class="red">`: پرچم قرمز مرگبار؛ هرگز پروژه‌ای را در وضعیت «RLS Disabled» روی اینترنت رها نکنید؛ این کار معادل رها کردن گاوصندوق باز در خیابان است!
|
||
|
||
### آنچه نباید وارد آن شویم (Out-of-Scope):
|
||
- تعریف رول‌های پیچیده چندسطحی سازمانی (RBAC با چندین سطح دسترسی نظیر سوپرادمین، نویسنده، ویرایشگر).
|
||
- تنظیمات فایروال شبکه یا DDoS Protection سرور (فصل ۱۱ امنیت و انتشار).
|
||
|
||
---
|
||
|
||
## ۳. مفاهیم کلیدی و کلمات تخصصی (Key Concepts & Terms)
|
||
|
||
| اصطلاح انگلیسی | معادل فارسی مصوب | توضیح یک‌خطی ساده |
|
||
| :--- | :--- | :--- |
|
||
| Row Level Security (RLS) | امنیت در سطح ردیف | مکانیزم امنیتی در دیتابیس که دسترسی به تک‌تک سطرهای جدول را بر اساس هویت کاربر فیلتر می‌کند |
|
||
| Security Policy | خط‌مشی / سیاست امنیتی | قانون صریحی در دیتابیس که تعیین می‌کند چه کسی حق اجرای SELECT، INSERT، UPDATE یا DELETE را دارد |
|
||
| Authenticated Role | نقش کاربری احراز هویت‌شده | برچسب امنیتی در دیتابیس برای کاربرانی که لاگین موفق با نشست فعال داشته‌اند |
|
||
| Database Firewall | دیوار آتشین پایگاه داده | سپر دفاعی مستقر در هسته دیتابیس برای رد خودکار درخواست‌های غیرمجاز |
|
||
| 403 Forbidden | خطای دسترسی غیرمجاز | کد وضعیت وب برای پاسخ به کاربرانی که بدون داشتن مجوز لازم قصد دستکاری منابع را دارند |
|
||
|
||
---
|
||
|
||
## ۴. جایگاه‌های تصاویر و نمودارها (Visual & Diagram Placeholders)
|
||
> **راهنمای ایجنت نویسنده:** تمام تصاویر باید در پوشهٔ `images/` قرار گرفته و در قالب جدول تک‌خانه‌ای وسط‌چین با کپشن تفصیلی درج شوند:
|
||
|
||
1. **تصویر کاور درس:** `images/cover.png`
|
||
* **موضوع:** کاور مدرن با تم تیره و یک سپر دیجیتال نئونی که دور استوانه دیتابیس PostgreSQL تنیده شده و امواج غیرمجاز را دفع می‌کند.
|
||
2. **استعاره نگهبان امنیتی RLS جلوی در دیتابیس:** `images/rls-bouncer-analogy.png`
|
||
* **موضوع:** تصویر استعاری: نگهبان امنیتی جلوی جدول (درخواست‌های بدون لاگین را به سمت در خروج هدایت می‌کند و به ادمین احراز هویت‌شده اجازه ورود می‌دهد).
|
||
3. **مقایسه دیتابیس با و بدون RLS:** `images/unprotected-vs-rls-protected.png`
|
||
* **موضوع:** اینفوگرافیک مقایسه‌ای: سمت چپ دیتابیس بدون RLS (خطر پاک شدن کل اطلاعات توسط هر فرد) در برابر سمت راست دیتابیس قفل‌شده با RLS.
|
||
4. **نشانگر سبز RLS در پنل Table Editor سوپابیس:** `images/supabase-rls-green-badge.png`
|
||
* **موضوع:** اسکرین‌شات تمیز از هدر جدول در Supabase با نشان دادن برچسب سبز `RLS Enabled` و لیست سیاست‌های فعال.
|
||
5. **اسکریپت SQL سیاست‌های امنیتی پورتفولیو:** `images/sql-policies-code-block.png`
|
||
* **موضوع:** تصویر کادر کدهای SQL سیاست‌های خواندن عمومی و نگارش اختصاصی ادمین با هایلایت سینتکس تمیز.
|
||
|
||
---
|
||
|
||
## ۵. بخش‌بندی و ساختار محتوایی پیشنهادی درس‌نامه (`README.md`)
|
||
|
||
1. **تیتر اصلی:** `# امنیت پایگاه داده با Row Level Security: ساخت دژ تسخیرناپذیر`
|
||
2. **مقدمه:** چرا بدون RLS، انتشار یک اپلیکیشن متصل به دیتابیس معادل خودکشی سایبری است؟
|
||
3. **جدول کاور درس**
|
||
4. **کابوس بزرگ: افشای کلید عمومی بدون سپر امنیتی:** ریشه نیاز مبرم به RLS.
|
||
5. **سازوکار Row Level Security (RLS) در PostgreSQL:** امنیت در عمق دیتابیس، نه در جاوااسکریپت کلاینت.
|
||
6. **سیاست‌های امنیتی پروژه پورتفولیوی پویا:**
|
||
* قانون خواندن عمومی کارهای پورتفولیو برای همه (SELECT Policy).
|
||
* قانون انحصار ویرایش و حذف فقط برای ادمین تاییدشده (Authenticated Policy).
|
||
* سیاست‌های جدول تک‌سطری سئو.
|
||
7. **باکس نکته پیشرفته Quera (`<details class="violet">`):** چرا چک‌های امنیتی فرانت‌اند هرگز کافی نیستند؟
|
||
8. **اجرای اسکریپت فعال‌سازی و قفل‌گذاری RLS در SQL Editor:** کپی و اجرای کوئری در چند ثانیه.
|
||
9. **آزمون نفوذپذیری و تست زنده امنیت:**
|
||
* راستی‌آزمایی در تب ناشناس مرورگر.
|
||
* اثبات مسدود شدن درخواست‌های غیرمجاز با خطای ۴۰۳.
|
||
10. **باکس هشدار قرمز Quera (`<details class="red">`):** هرگز پروژه‌ای را با RLS خاموش به پروداکشن نبرید!
|
||
11. **جشن پایان فصل هفتم:** اعلام آماده‌سازی ۱۰۰٪ فرانت‌اند، دیتابیس، احراز هویت و امنیت برای ورود به پروژه عملی اول (فصل ۸).
|
||
|
||
---
|
||
|
||
## ۶. معیارهای پذیرش (Acceptance Criteria for Reviewer)
|
||
- [ ] مفهوم RLS و خطرات غیرفعال بودن آن به زبانی رسا و هشداردهنده تبیین شده باشد.
|
||
- [ ] سیاست‌های امنیتی برای دو جدول `projects` و `site_settings` با کدهای کامل SQL ارائه گردند.
|
||
- [ ] تمایز دسترسی عمومی خواندن با دسترسی اختصاصی نگارش ادمین شفاف شده باشد.
|
||
- [ ] آزمون عملی تست سیاست‌ها با تب ناشناس مرورگر در متن گنجانده شود.
|