نکات کلیدی
- ورود هویت حساب را مشخص میکند. کنترل دسترسی بررسی میکند همان حساب اجازهٔ خواندن یا تغییر یک منبع مشخص را دارد یا نه.
- خیر. سرور باید مجوز را برای درخواست مربوط هم بررسی کند. پنهان‌کردن منو فقط بخشی از رابط است.
- خیر. شواهد از بررسی رابط نمونهٔ موجودند. درخواست مستقیم API، جداسازی مستأجر و همهٔ عملیات حساس ممیزی نشده‌اند.
وقتی یک وب‌اپ با فرم ورود و پنل مدیر می‌بینی، ممکن است فکر کنی دسترسی‌ها تمام شده‌اند. سؤال مهم‌تر این است: همکار عادی دقیقاً کدام درخواست مشتری را می‌بیند و آیا می‌تواند اطلاعاتِ حساب دیگری را تغییر دهد؟ برای جواب، به یک جدول مجوز و دو حساب آزمایشی نیاز داری؛ شکل دکمه‌های ورود جواب این سؤال را نمی‌دهد.
در نمونهٔ CRM کُندا که در ۲۴ مهر ۱۴۰۵ بررسی کردیم، حساب همکار در بخش اعضا پیام منع دسترسی دید. از طرف دیگر، یک رکورد با مسئول مشخص در حساب مدیر وجود داشت ولی در حساب آزمایشی همان همکار دیده نشد. این دو مشاهده کنار هم مهم‌اند: بستن مسیر غیرمجاز کافی نیست؛ مسیر مجاز هم باید کار کند. این راهنما روش تعریف و بررسی همین تفاوت را توضیح می‌دهد، نه نتیجهٔ یک ممیزی امنیتی کامل.
اول هویت، نقش و مالک را جدا بنویس
هویت می‌گوید کدام حساب وارد شده؛ نقش می‌گوید مدیر است یا همکار؛ مالکیت می‌گوید این رکورد به کدام حساب یا تیم مربوط است. در یک تیم خدماتی، همکار می‌تواند اجازهٔ دیدن مشتریان خودش را داشته باشد، اما مجاز به مدیریت اعضای تیم نباشد. اگر این سه مفهوم را در پرامپت به یک جملهٔ «ورود امن بساز» خلاصه کنی، تصمیم اصلی را مبهم گذاشته‌ای.
برای رکورد آزمایشی، یک مسئول مشخص انتخاب کن و از ابتدا بنویس انتظار داری چه کسی آن را ببیند. نام نمایشیِ مسئول هم همیشه شناسهٔ حساب نیست. اگر دو نفر نام یکسان داشته باشند یا نام حساب عوض شود، قواعد مالکیت نباید به متن روی کارت وابسته بمانند.
جدول مجوز، قبل از جدول مشتریان
برای دیدن همهٔ ستون‌ها، جدول را افقی جابه‌جا کن.
| عملیات | مدیر تیم | همکار مسئول | همکار دیگر | مهمان |
|---|---|---|---|---|
| دیدن مشتری نمونه | طبق سیاست تیم | بله | خیر | خیر |
| تغییر وضعیت مشتری | طبق سیاست تیم | اگر مجاز تعریف شده | خیر | خیر |
| تغییر مسئول | طبق سیاست تیم | فقط اگر صریحاً مجاز است | خیر | خیر |
| مدیریت اعضا | بله | خیر | خیر | خیر |
این جدول یک نمونهٔ سیاست است، نه الزام همهٔ CRMها. اگر همکاری مشترک می‌خواهی، همان را به‌صورت مشخص تعریف کن. مهم این است که یک خانهٔ نامعلوم، به مجوز ضمنی تبدیل نشود. تغییر نقش و تغییر مالک هم دو تصمیم متفاوت‌اند و باید جدا بررسی شوند.
پنهان‌کردن منو را با اجرای مجوز یکی نگیر
در رابط، گزینهٔ مدیریت اعضا را برای همکار نشان نده تا کاربر به بن‌بست نخورد. اما همان عملیات باید در سرور هم محدود باشد. OWASP بر رد دسترسی به‌صورت پیش‌فرض و بررسی مجوز در هر درخواست تأکید میکند. صرفِ نمایش صفحهٔ خطا، محل اجرای این کنترل را ثابت نمی‌کند.
اگر قرار است بازبین فنی این بخش را تأیید کند، جدول عملیات و حساب‌های ساختگی را به او بده. هدف، آزمودن همان پروژه و دادهٔ آزمایشی با مجوز مالک است؛ برای این کار لازم نیست دادهٔ مشتری واقعی یا حساب فرد دیگری را وارد کنی.
از خواندن به ساختن با کُندانقشها را از اولین درخواست مشخص کن
از یک جریان کوچک و دو نقش آزمایشی شروع کن؛ نتیجهٔ مجاز و ممنوع را جدا بسنج.
نمونهٔ CRM و بررسی فرم و نقش‌ها دو کنترل لازم داری: مجاز و غیرمجاز
با حساب مدیر، رکوردی با برچسب روشن «آزمایشی» بساز. آن را به همکار الف نسبت بده. انتظار مجاز را بررسی کن: الف رکورد را می‌بیند و عملی را که در جدول مجاز است انجام می‌دهد. سپس با همکار ب همان منبع را بررسی کن؛ انتظار غیرمجاز این است که دادهٔ الف به او داده نشود. آخر، حالت مهمان را هم جدا ثبت کن.
اگر همهٔ حساب‌ها فهرست خالی ببینند، نمی‌توانی نتیجه بگیری جداسازی درست است. یک سامانهٔ ازکارافتاده هم می‌تواند هیچ داده‌ای نشان ندهد. به همین دلیل، نمونه‌ای که باید دیده شود به‌اندازهٔ نمونهٔ ممنوع مهم است. زمان، نقش و نتیجهٔ هر دو کنترل را در گزارش بنویس.
اختلاف نمونهٔ CRM چه چیزی به ما یاد داد؟
در حساب مدیر، رکورد مربوط به مسئول «سارا» دیده شد؛ اما حساب آزمایشی همکار فهرست خالی داشت. این نتیجه برای تحویل کافی نبود. علت می‌تواند در نگاشت حساب، فیلتر فهرست یا سیاست مورد انتظار باشد؛ از تصویر نمی‌شود میان آن‌ها انتخاب کرد. در مقالهٔ اصلی هم ایراد را پنهان نکردیم و پرامپت اصلاح را اجراشده معرفی نکردیم.
برای ادامه، ابتدا شناسهٔ مسئول و حساب واردشده را در محیط مجاز تطبیق بده، بعد درخواست فهرست و پاسخ آن را بررسی کن. تغییر رنگ کارت یا نوشتن متن اطمینان‌بخش، این اختلاف را حل نمی‌کند.
پرامپت محدود برای تعریف دسترسی
برای وب‌اپ خدماتی، مدیر بتواند اعضا و مسئول رکورد را مدیریت کند. همکار فقط درخواست‌های مجاز خودش را ببیند. هویت حساب از نشست معتبر بیاید؛ نقش و مالکیت در سمت سرور هم بررسی شوند. دادهٔ آزمایشیِ مشخص برای یک نتیجهٔ مجاز و یک نتیجهٔ ممنوع آماده کن. اگر بخشی متصل نیست، آن را آماده معرفی نکن. صفحات عمومی و ظاهر نامرتبط را تغییر نده.
این متن نقطهٔ شروع است. پیش از ارسال، اسم نقش‌ها و عملیات مجاز را با جدول خودت جایگزین کن. بعد از ویرایش هم فقط پیام ابزار را نخوان؛ دو کنترل قبلی را دوباره انجام بده. اگر ابزار تغییری اعمال نکرده یا بخش سرور هنوز متصل نیست، وضعیت را در برگهٔ تحویل باز نگه دار.
پیش از دادهٔ واقعی، چه چیزی باید روشن باشد؟
ورود و خروج، دسترسی هر نقش، مالکیت رکورد، تغییر نقش و بازیابی داده را با سناریوی مشخص بررسی کن. پیام خطا هم نباید دادهٔ شخص دیگری را نشان دهد. دربارهٔ ثبت رویداد حساس و حذف دسترسی هم از بازبین فنی سؤال کن. این چک‌لیست جای ارزیابی امنیتی متناسب با حساسیت پروژه را نمی‌گیرد.
برای دیدن زمینهٔ مثال، راهنمای ساخت اپ بدون کدنویسی را بخوان. اگر هنوز تفاوت محیط بررسی و تحویل عمومی برایت مبهم است، پیش‌نمایش یا انتشار مرحلهٔ بعد را روشن میکند.
برای یک تمرین مشخص، مسیر تیکتینگ از ثبت تا بازگشایی را ببین؛ خواندن و تغییر همان شناسه را با نشست مالک، کارشناس مجاز و مشتری دیگر جدا بررسی کن.
پرسش‌های پرتکرار
ورود با کنترل دسترسی چه فرقی دارد؟
ورود هویت حساب را مشخص میکند. کنترل دسترسی بررسی میکند همان حساب اجازهٔ خواندن یا تغییر یک منبع مشخص را دارد یا نه.
آیا مخفی‌کردن صفحهٔ مدیریت کافی است؟
خیر. سرور باید مجوز را برای درخواست مربوط هم بررسی کند. پنهان‌کردن منو فقط بخشی از رابط است.
اگر فهرست همکار خالی باشد یعنی امنیت درست است؟
نه لزوماً. ممکن است مجوز درست باشد یا نگاشت مسئول به حساب اشتباه شده باشد. با یک رکورد ساختگی که باید مجاز باشد، هر دو حالت مجاز و غیرمجاز را بررسی کن.
آیا CRM این مقاله ممیزی امنیتی شده است؟
خیر. شواهد از بررسی رابط نمونهٔ موجودند. درخواست مستقیم API، جداسازی مستأجر و همهٔ عملیات حساس ممیزی نشده‌اند.
منابع
- راهنمای مجوزدهی OWASP (۲٬۰۲۶)
- مجوزها و مالکیت در منطق کسب‌وکار (۲٬۰۲۶)
بنیان‌گذار کُندا و راوی تجربهٔ ساخت.
