نگهبان ورودی یک ساختمان فقط یک کار دارد: مطمئن شود شما همان کسی هستید که ادعا میکنید. اما بعد از ورود، حکم دیگری اجرا میشود؛ اینکه با کارت دسترسیتان اجازه دارید کدام طبقه و کدام اتاق را باز کنید. این دو کنترل در نگاه اول یکی به نظر میرسند، اما در نرمافزار دو مفهوم جدا با وظایف، ابزارها و خطاهای مخصوص خودند: احراز هویت (Authentication) و مجوز دسترسی (Authorization).
آمیختن این دو، از شایعترین ریشههای حوادث امنیتی در سامانههای وب است؛ نه چون فناوری نداریم، بلکه چون تصمیم میگیریم «چون وارد شده، پس مجاز است». در این مقاله این دو مفهوم را جدا میکنیم، با مثال اپ بانکی نشان میدهیم هرکدام کجا اجرا میشود و در جدولی متمرکز کنار هم میگذاریم تا مرزشان همیشه به یاد بماند.
احراز هویت: اثبات «کی هستم؟»
احراز هویت فرآیند اثبات هویتِ ادعاشده است. در سامانههای وب معمولاً با ترکیبی از عوامل انجام میشود: چیزی که میدانید (رمز عبور)، چیزی که دارید (کد یکبارمصرف یا دستگاه تأیید) و چیزی که هستید (اثر انگشت یا چهره). هرچه عوامل مستقلتر باشند، جعل هویت سختتر میشود و همین منطق پشت ورود دومرحلهای است.
در اپ بانکی، همان لحظهای که رمز و رمز دوم را میزنید، در حال احراز هویت هستید. خروجی این مرحله یک مدرک گذراست — معمولاً توکن یا نشست — که در درخواستهای بعدی نشان میدهد «این درخواست از سوی فلان کاربرِ تأییدشده است». این مدرک عمر مشخصی دارد و باید بتواند در صورت نیاز، بهسرعت باطل شود.
مجوز دسترسی: پاسخ «اجازه دارم چه کار کنم؟»
مجوز دسترسی تعیین میکند کاربرِ احرازشده روی هر منبع چه کاری مجاز است. این تعیین معمولاً با نقشها (Role) و مجوزها (Permission) صورت میگیرد: نقش بستهای از مجوزهاست و کاربر نقش میگیرد. مشتری، اپراتور پشتیبانی و مدیر شعبه ممکن است همه با یک اپ بانکی کار کنند، اما نقشهای متفاوتشان به پنجرههای متفاوتی راه میدهد.
نکته ظریف این است که بررسی مجوز باید همهجا اجرا شود: در منو و ظاهر اپ برای تجربه کاربری تمیزتر، اما مهمتر از آن در سرور، برای هر درخواست و روی هر منبع. بررسی مجوز در سرور تنها جایی است که واقعاً محافظت میکند؛ پنهانکردن دکمه در ظاهر فقط دکوری روی در است که قفل پشتش ندارد.
مرز میان این دو را با یک تصویر ساده نگه دارید: احراز هویت سوال پاسپورت است و مجوز دسترسی سوال ویزا. پاسپورت میگوید شما چه کسی هستید؛ ویزا میگوید به کدام شهر و برای چه کاری اجازه ورود دارید. هیچ سفارتی با نشاندادن پاسپورت معتبر، نبود ویزا را جبران نمیکند؛ در نرمافزار هم توکن معتبر، جای بررسی مجوز را نمیگیرد.
مقایسه در یک نگاه
| معیار | احراز هویت (Authentication) | مجوز دسترسی (Authorization) |
|---|---|---|
| پرسش اصلی | تو کیستی؟ | چه حقی داری؟ |
| زمان اجرا | یکبار در آغاز تعامل و تجدید دورهای | برای هر درخواست و هر منبع |
| ورودی | رمز، کد یکبارمصرف، ویژگی زیستی | هویت تأییدشده، نقش و مجوز، منبع هدف |
| خروجی | مدرک اعتبار مانند توکن یا نشست | اجازه یا رد اجرا |
| خطای نمونه در وب | کد ۴۰۱: هویت نامعلوم یا منقضی | کد ۴۰۳: هویت روشن، اما اجازه نداری |
| پیامد نقض | ورود غیرمجاز با هویت دیگران | دسترسی به داده دیگران با هویت خود |
| مثال در اپ بانکی | ورود با رمز و رمز دوم | دیدن مانده حساب خود، اما نه حساب دیگران |
چرا آمیختن این دو به بحران میانجامد؟
خطای رایج این باور است که با هویت، امنیت تمام میشود. اما بسیاری از سوءاستفادههای درونسیستمی از کسانی میآید که هویتشان کاملاً معتبر است و مرزشان را دور میزنند. مثال کلاسیک: کاربری که شناسه حساب را در درخواست عوض میکند و برگه صورتحساب حساب دیگری دریافت میکند؛ چون سرور فقط «وارد بودن» را بررسی کرده بود، نه «مالک بودن منبع» را. این الگو که به ارجاع مستقیم ناامن (Insecure Direct Object Reference) معروف است، به سادگی با بررسی مجوز روی هر منبع بسته میشود.
هویت درست، اجازه نامحدود نیست؛ هر منبع، هر بار، بازبینی میخواهد.
مثال کاربردی: سه کاربر، یک اپ بانکی
فرض کنید سه نفر همزمان از یک اپ بانکی استفاده میکنند: مشتری، اپراتور پشتیبانی و مدیر ارشد. هر سه در گام نخست احراز هویت میشوند و از این پس فقط مجوزها میانشان فرق میگذارد:
- مشتری فقط حسابهای خودش را میبیند؛ درخواست مانده حساب حساب دیگری حتی با دستکاری در درخواست، با کد ۴۰۳ رد میشود.
- اپراتور پشتیبانی با نقش محدود میتواند جزئیات حساب مشتریان را برای رفع مشکل ببیند، اما اجازه انتقال وجه ندارد و هر اقدام حساس، ثبت در گزارش حسابرسی دارد.
- مدیر ارشد به گزارشها و تنظیمات دسترسی وسیعتری دارد، اما برای اقدامهای خاص به تأیید دوم نیاز است؛ نقش بالا یعنی مجوزهای بیشتر، نه معافیت از قواعد.
این مثال نشان میدهد احراز هویت یکبار و مجوزها هزاران بار در روز اجرا میشوند؛ امنیت واقعی در همین تکرار بیسروصداست.
خطاهای رایج و راهحلها
- مخفیکردن دکمهها در ظاهر بدون محافظت سرور: رابط کاربری را تمیز کنید، اما قاعده را در سرور قفل کنید؛ هر مسیر API بیمحافظ، دری نیمهباز است.
- نقشهای پهن و مبهم «برای اینکه کارها دیرتر متوقف شوند»: اصل حداقل دسترسی (Least Privilege) را رعایت کنید و نقشها را کوچک، شفاف و قابل توضیح نگه دارید.
- بررسی مالکیت فقط در صفحات اصلی و فراموشی در APIها و سرویسهای پسزمینه: هر مسیری که به داده میرسد، یک نقطه بررسی مجوز است.
- عدم ثبت رخدادهای مجوز: هر ردشدن و هر اجازهگیری حساس را ثبت کنید تا بررسی پس از حادثه ممکن باشد و الگوهای مشکوک دیده شوند.
کاربرد عملی
در طراحی هر سامانه جدید، دو پرسش را جدا کنید: کاربر چگونه خودش را ثابت میکند؟ و پس از ورود، مرزش کجاست؟ فهرست نقشها را روی کاغذ بنویسید، برای هر قابلیت مشخص کنید کدام نقشها مجازند و این تصمیم را در سرور اعمال کنید.
فرض کنید قابلیت جدیدی برای دانلود صورتحساب اضافه میشود؛ پیش از هر کدی مشخص کنید کدام نقشها مجاز به دانلود هستند، آیا فقط صورتحسابهای خود کاربر است یا بازه سازمانی هم دارد و این بررسی در کدام لایه اعمال میشود. همین تکپاراگراف تصمیم، بعداً دهها ساعت بازبینی امنیتی را کم میکند.
در بازبینیهای دورهای هم نمونهبرداری کنید: با نقشی کماختیار وارد شوید و ببینید آیا واقعاً مسیر پنهانی به داده دیگران باقی مانده است. این تمرین ساده، بیشتر روزنهها را پیش از سوءاستفاده نشان میدهد.
نکات کلیدی این مقاله
- احراز هویت پاسخ «کی هستم» و مجوز دسترسی پاسخ «چه حقی دارم» است؛ هیچکدام جایگزین دیگری نمیشود.
- خروجی احراز هویت یک مدرک گذراست؛ اما بررسی مجوز در هر درخواست و روی هر منبع تکرار میشود.
- نقش و مجوز ابزار سازماندهی دسترسیاند و اصل حداقل دسترسی مرزها را محافظهکارانه نگه میدارد.
- بررسی مجوز فقط در سرور معنا دارد؛ مخفیکردن عناصر ظاهری بهتنهایی محافظت نیست.
- کدهای ۴۰۱ و ۴۰۳ پژواک همین تفکیکاند: هویت نامعلوم در برابر اجازه ناکافی.
سوالات متداول
اگر کاربری احراز هویت شده باشد، یعنی مجاز است؟
نه. احراز هویت فقط میگوید هویت اثبات شده است. اینکه آن هویت روی منبع مشخص چه حقی دارد، موضوع جداگانهای است که در هر درخواست باید بررسی شود.
تفاوت کدهای ۴۰۱ و ۴۰۳ در یک جمله چیست؟
۴۰۱ میگوید «نمیدانم تو کی هستی» و یعنی مدرک هویت کافی یا معتبر نیست؛ ۴۰۳ میگوید «تو را میشناسم، اما اجازه این کار را نداری» و یعنی مرحله مجوز رد شده است.
اگر سامانه ما فقط یک نوع کاربر داشته باشد، باز هم به نقش و مجوز نیاز داریم؟
بله. حتی با یک نوع کاربر، باید بررسی مالکیت منبع انجام شود: کاربر واردشده فقط به دادههای خودش دسترسی داشته باشد. این حداقلیترین شکل مجوز دسترسی است و حذفش یعنی باز گذاشتن درِ دادههای همه.
