Linux-PAM چه مسئله‌ای را حل می‌کند؟
Linux-PAM چارچوبی است که به برنامه‌های سازگار اجازه می‌دهد بخشی از کارهای مرتبط با احراز هویت و مدیریت نشست را به ماژول‌ها بسپارند. بدون چنین لایه‌ای، هر برنامه باید روش بررسی هویت و سیاست‌های مرتبط را جداگانه پیاده کند. با PAM، برنامه‌ای مانند یک سرویس ورود می‌تواند از زنجیره‌ای از ماژول‌ها استفاده کند که مدیر سیستم تنظیم کرده است. این انعطاف مفید است، اما باعث می‌شود نتیجه نهایی تنها به یک فایل یا یک رمز وابسته نباشد. برای فهم شکست ورود باید بدانید برنامه چه مرحله‌ای را درخواست کرده و زنجیره آن مرحله چگونه تصمیم می‌گیرد.
PAM پایگاه کاربران نیست و به تنهایی سرویس فهرست هویت ایجاد نمی‌کند. ممکن است ماژولی از اطلاعات محلی استفاده کند و ماژول دیگر با سامانه هویت مرکزی ارتباط داشته باشد. همچنین همه برنامه‌ها الزاماً از PAM استفاده نمی‌کنند یا همه مراحل آن را یکسان فراخوانی نمی‌کنند. بنابراین جمله «PAM درست است» بدون نام سرویس و سناریو، دقیق نیست. باید مشخص باشد ورود کنسول، افزایش دسترسی، تغییر گذرواژه یا آغاز نشست کدام برنامه را بررسی می‌کنید. این مرزبندی، اولین قدم برای جلوگیری از تغییرهای حدسی و گسترده در تنظیمات حساس است.
چهار مرحله اصلی را جدا ببینیم
گروه auth به بررسی هویت مربوط است؛ account درباره مجاز بودن حساب در شرایط فعلی تصمیم می‌گیرد؛ password به تغییر توکن احراز هویت مربوط می‌شود؛ و session کارهای قبل یا بعد از ارائه نشست را پوشش می‌دهد. این تفکیک توضیح می‌دهد چرا درست بودن گذرواژه همیشه به معنی ورود موفق نیست. ممکن است هویت پذیرفته شود، اما حساب به دلیل سیاست زمانی یا وضعیت انقضا اجازه استفاده نداشته باشد. همچنین ممکن است مراحل هویتی موفق باشند ولی آماده‌سازی نشست با مشکل روبه‌رو شود. پیام کلی برنامه گاهی همه این موارد را به شکل مشابهی نمایش می‌دهد.
برای یادگیری، یک جریان ورود را روی کاغذ رسم کنید و در هر مرحله پرسش مربوط را بنویسید. «آیا این فرد همان کسی است که می‌گوید؟» با «آیا این حساب اکنون اجازه استفاده دارد؟» فرق می‌کند. سپس یک مورد مانند تغییر گذرواژه را بررسی کنید؛ آن عملیات ممکن است به قواعد متفاوتی نیاز داشته باشد. این تمرین کمک می‌کند هنگام خواندن فایل تنظیمات، هر خط را در گروه درست قرار دهید. افزودن ماژول به گروه نامناسب می‌تواند بی‌اثر باشد یا رفتار غیرمنتظره ایجاد کند، حتی اگر نام ماژول و مسیر فایل درست باشند.
سرویس، فایل تنظیمات و زنجیره ماژول‌ها
در روش متداول، فایل‌های سرویس در مسیر pam.d قرار دارند و نام فایل به سرویس مربوط است. هر خط نوع مرحله، روش کنترل نتیجه و ماژول را مشخص می‌کند. توزیع لینوکس ممکن است از فایل‌های مشترک و ابزار تولید تنظیمات استفاده کند. در چنین محیطی، ویرایش دستی بخشی که خودکار مدیریت می‌شود می‌تواند در به‌روزرسانی بعدی بازنویسی شود. پیش از تغییر، مشخص کنید فایل متعلق به کدام بسته یا ابزار مدیریتی است و روش پشتیبانی‌شده توزیع چیست. کپی تنظیمات از توزیع دیگر، حتی با نام ماژول مشابه، لزوماً نتیجه یکسانی نمی‌دهد.
زنجیره را باید با ترتیب واقعی اجرا بخوانید. اگر فایل دیگری وارد شده است، آن را نیز دنبال کنید و صرفاً به چند خط فایل اصلی نگاه نکنید. یک ماژول ممکن است نتیجه موفق، شکست یا وضعیت دیگری برگرداند و قواعد کنترل تعیین کنند پس از آن چه رخ دهد. در یک یادداشت فنی، فهرست مرحله‌ها و ترتیب آن‌ها را به زبان ساده بنویسید. این کار هنگام بازبینی تغییر بسیار مفید است، چون همکار می‌تواند تصمیم‌ها را دنبال کند بدون اینکه مجبور باشد از میان چند فایل، منطق کامل را دوباره استخراج کند.
معنای کنترل‌های رایج
در شکل ساده کنترل، required یعنی شکست ماژول در نتیجه نهایی اثر شکست دارد، ولی معمولاً بررسی بخش‌های بعدی ادامه می‌یابد. requisite در صورت شکست زودتر مسیر را متوقف می‌کند. sufficient می‌تواند در صورت موفقیت و نبود شکست لازم قبلی، نتیجه موفق را زودتر برگرداند. optional در زنجیره عادی نقش تعیین‌کننده مشابه required ندارد و باید در زمینه کامل خوانده شود. این توضیح خلاصه برای مدل ذهنی است؛ حالت‌های ترکیبی و کنترل‌های پیشرفته باید از مستندات نسخه خوانده شوند. تبدیل بی‌دلیل یک واژه به واژه دیگر، می‌تواند کل منطق دسترسی را عوض کند.
فرض کنید در یک طرح آموزشی دو بررسی وجود دارد: یکی هویت و دیگری شرط تکمیلی. اگر بررسی اول طوری تنظیم شود که موفقیت آن ادامه مسیر را کنار بگذارد، ممکن است شرط دوم هرگز در همان مسیر اجرا نشود. این مثال نشان می‌دهد ترتیب و کنترل، بخشی از سیاست امنیتی هستند. وجود نام ماژول در فایل به تنهایی ثابت نمی‌کند آن ماژول برای همه ورودها اجرا می‌شود. برای پذیرش طراحی، باید مسیرهای موفق و ناموفق را آزمایش کنید. به‌خصوص در طرح چندعاملی، اثبات کنید موفقیت عامل اول به تنهایی دسترسی نمی‌دهد.
احراز هویت مرکزی و حساب محلی
در سازمانی که هویت مرکزی دارد، باید رفتار حساب محلی و حساب مرکزی جدا تعریف شود. آیا کاربر محلی مجاز است؟ در صورت قطع ارتباط با سرویس هویت چه رخ می‌دهد؟ آیا اطلاعات قبلی برای کار آفلاین استفاده می‌شود؟ پاسخ این پرسش‌ها به ماژول و سامانه هویت انتخابی وابسته است و نباید از روی رفتار یک رایانه حدس زده شود. یک سیاست مبهم می‌تواند هنگام اختلال شبکه، هم باعث قفل شدن کاربران شود و هم در جهت مخالف، دسترسی ناخواسته بدهد. بنابراین حالت قطع سرویس باید بخشی از آزمایش باشد.
برای بررسی، از حساب‌های آزمایشی با نقش روشن استفاده کنید: یک حساب محلی محدود، یک حساب مرکزی مجاز و یک حسابی که طبق سیاست نباید وارد شود. نتیجه هرکدام را در حالت عادی ثبت کنید و سپس فقط در محیط آزمایش، نبود دسترسی به منبع هویت را شبیه‌سازی کنید. هدف، پیدا کردن روش دور زدن نیست؛ هدف این است که رفتار واقعی با سیاست نوشته‌شده مطابقت داشته باشد. اگر سیاست می‌گوید دسترسی قطع شود ولی ورود ادامه دارد، علت باید روشن شود. اگر مسیر بازیابی مجاز وجود دارد، آن را نیز جداگانه مستند و محدود نگه دارید.
تغییر گذرواژه و سیاست کیفیت
مرحله تغییر گذرواژه را با مرحله بررسی گذرواژه یکسان ندانید. ممکن است یک ماژول کیفیت عبارت تازه را بررسی کند و دیگری ذخیره‌سازی یا ارسال تغییر به منبع هویت را انجام دهد. ترتیب و نحوه انتقال اطلاعات بین این مرحله‌ها اهمیت دارد. اگر فقط صفحه ورود آزمایش شود، اشکال فرایند تغییر گذرواژه ممکن است پنهان بماند. برای محیطی با هویت مرکزی، باید مشخص باشد تغییر در کدام سامانه اعمال می‌شود و آیا همه سرویس‌ها همان منبع را مصرف می‌کنند. دو مخزن نامرتبط می‌توانند باعث تجربه گیج‌کننده برای کاربر شوند.
آزمون تغییر گذرواژه باید شامل حالت موفق و رد شدن طبق سیاست باشد. پس از تغییر موفق، در یک نشست تازه رفتار ورود را بررسی کنید و نتیجه را به حافظه نشست قبلی نسبت ندهید. همچنین پیام خطا باید برای کاربر قابل فهم باشد، بدون اینکه اطلاعات حساس زیادی آشکار کند. اگر کاربر فقط «خطا» می‌بیند، ممکن است بارها تلاش کند و مشکل دیگری مانند قفل موقت ایجاد شود. هماهنگی پیام برنامه، سیاست ماژول و راهنمای پشتیبانی، بخشی از کیفیت عملیاتی احراز هویت است و تنها به یک خط پیکربندی خلاصه نمی‌شود.
مرحله نشست و خطاهای پس از احراز هویت
گاهی کاربر احراز هویت می‌شود، اما محیط کار درست آماده نمی‌شود. اینجا باید به مرحله نشست و وابستگی‌های آن توجه کرد. آماده‌سازی محیط، اعمال محدودیت منابع یا کارهای مرتبط با پوشه کاربر می‌تواند در این مرحله نقش داشته باشد، بسته به ماژول‌های استفاده‌شده. اگر صفحه ورود دوباره نمایش داده می‌شود، نباید فوراً فرض کرد گذرواژه اشتباه بوده است. ثبت زمان و بررسی پیام‌های سرویس می‌تواند نشان دهد شکست پس از پذیرش هویت رخ داده است. این تفکیک از بازنشانی غیرضروری گذرواژه و تغییرهای نامرتبط جلوگیری می‌کند.
برای یک کاربر آزمایشی، ورود بدون محیط گرافیکی و ورود از سرویس مورد نظر را جدا مقایسه کنید، البته فقط در محدوده‌ای که سیاست اجازه می‌دهد. تفاوت نتیجه می‌تواند به تفاوت زنجیره سرویس‌ها یا آماده‌سازی نشست اشاره کند. وضعیت پوشه خانه، مالکیت و سرویس‌های لازم را نیز بررسی کنید. نباید برای رفع خطای نشست، همه کنترل‌های هویتی را ضعیف کرد. مشکل باید در همان مرحله‌ای حل شود که شواهد نشان می‌دهند. باز کردن دسترسی گسترده شاید علامت ظاهری را تغییر دهد، اما علت اصلی را برطرف نمی‌کند.
روش امن آزمایش تغییر
تغییر PAM می‌تواند مسیر مدیریت سیستم را تحت تأثیر قرار دهد، بنابراین محیط آزمایش و راه بازگشت واقعی لازم است. پیش از تغییر، نسخه فایل‌ها، وابستگی‌ها و روش دسترسی کنسول را ثبت کنید. نشست مدیریتی موجود را تا تأیید ورود جدید باز نگه دارید. داشتن یک پنجره ترمینال باز مفید است، اما جای کنسول یا مسیر بازیابی مستقل را در همه شرایط نمی‌گیرد. در ماشین دوردست، باید بدانید اگر سرویس ورود دیگر کار نکند چگونه فایل سالم را برمی‌گردانید. این پرسش باید پیش از تغییر پاسخ داشته باشد.
تغییر را کوچک نگه دارید و انتظار هر سناریو را از قبل بنویسید. سپس حساب مجاز، حساب نامجاز، گذرواژه نادرست و وضعیت خاص سیاست را آزمایش کنید. فقط بررسی موفقیت کافی نیست. اگر هدف اضافه کردن شرط دسترسی است، مهم‌ترین آزمون ممکن است همان حالتی باشد که باید رد شود. نتیجه را در اتصال تازه ببینید، زیرا نشست قبلی می‌تواند مجوز یا وضعیت خود را حفظ کرده باشد. پس از تأیید، اختلاف فایل‌ها را بازبینی کنید تا تغییر ناخواسته‌ای همراه اصلاح اصلی وارد نشده باشد.
عیب‌یابی با شواهد
برای یک شکست ورود، نام سرویس، نام حساب آزمایشی، زمان و نوع تلاش را ثبت کنید. سپس لاگ همان سرویس و پیام ماژول‌ها را بررسی کنید. نبود یک فایل ماژول، ناسازگاری آرگومان، خطای ارتباط با منبع هویت و رد شدن سیاست، علت‌های متفاوتی هستند. تغییر تصادفی کنترل‌ها برای عبور از خطا، تحلیل را سخت‌تر می‌کند. بهتر است نخست تشخیص دهید کدام مرحله شکست خورده و سپس همان مسیر را بررسی کنید. اگر نیاز به گزارش بیشتر دارید، آن را در محیط محدود و برای مدت لازم فعال کنید و از ثبت اطلاعات حساس جلوگیری کنید.
همچنین وضعیت حساب و منابع هویت را مستقل از PAM بررسی کنید. اگر نام کاربر در سیستم قابل حل نیست، ممکن است مسئله در مسیر دریافت اطلاعات هویتی باشد. اگر نام درست پیدا می‌شود ولی سیاست حساب رد می‌کند، دنبال دلیل همان رد شدن بروید. برای سامانه‌های مختلف، ابزار و مسیر لاگ متفاوت است؛ راهنمای توزیع و ماژول نصب‌شده مرجع دقیق‌تر از یک دستور عمومی اینترنتی است. در گزارش پشتیبانی، رمز واقعی کاربر را نخواهید و منتشر نکنید. حساب آزمایشی و پیام خطای پالایش‌شده معمولاً برای بازتولید کافی‌اند.
نگهداری بلندمدت سیاست
پیکربندی احراز هویت باید مانند کد حساس نگهداری شود: تغییر مشخص، دلیل روشن و آزمون قابل تکرار داشته باشد. پس از به‌روزرسانی بسته‌ها نیز رفتار کلیدی را بررسی کنید، مخصوصاً اگر فایل مشترک یا ابزار تولید تنظیمات تغییر کرده است. فهرستی کوتاه از سناریوهای پذیرش بسیار کمک می‌کند: کاربر مجاز وارد می‌شود، نامجاز رد می‌شود، تغییر گذرواژه طبق سیاست عمل می‌کند و مسیر بازیابی کار می‌کند. چنین فهرستی از مستند طولانی‌ای که هیچ‌کس اجرا نمی‌کند مفیدتر است و می‌تواند بخشی از تحویل سیستم باشد.
فهم PAM یعنی دیدن احراز هویت به صورت یک فرایند چندمرحله‌ای. رمز درست فقط بخشی از داستان است؛ وضعیت حساب، ترتیب ماژول‌ها و آماده‌سازی نشست نیز نتیجه را شکل می‌دهند. از خواندن زنجیره یک سرویس مشخص شروع کنید و هر خط را به پرسشی قابل فهم تبدیل کنید. سپس با حساب‌های آزمایشی، مسیرهای موفق و ناموفق را مشاهده کنید. این روش باعث می‌شود تغییر بعدی بر پایه مدل و شواهد باشد و هنگام رخداد، به جای دستکاری حدسی، بدانید دقیقاً کدام بخش نیاز به بررسی دارد.
