Authelia چه مسئله‌ای را حل می‌کند؟
Authelia سرور احراز هویت و ورود یکپارچه برای برنامه‌های وب است. کاربرد اصلی آن زمانی روشن می‌شود که چند سرویس داخلی یا شخصی پشت یک پراکسی معکوس دارید و می‌خواهید ورود کاربران و الزام عامل دوم را از یک نقطه مدیریت کنید. پروژه در مستندات رسمی خود، هم نقش همراه پراکسی و هم نقش ارائه‌دهندهٔ OpenID Connect را توضیح می‌دهد. این دو شیوهٔ اتصال یکسان نیستند و انتخاب میان آن‌ها باید بر اساس قابلیت برنامه و مرز اعتماد شبکه انجام شود. این مطلب راهنمای ارزیابی و بهره‌برداری است و ادعا نمی‌کند که یک نصب مشخص ممیزی یا امن‌سازی شده است.
برای مثال، یک گروه پژوهشی ممکن است داشبورد، ویکی و سامانهٔ فایل داشته باشد. اگر هر برنامه سازوکار ورود مستقل داشته باشد، خروج یک عضو از گروه به چند تغییر جداگانه نیاز پیدا می‌کند. تمرکز ورود می‌تواند کار را قابل پیگیری‌تر کند، اما تنها وقتی مفید است که مالکیت حساب، عضویت گروه و مجوز داخل هر برنامه نیز روشن باشد. ورود موفق به درگاه مرکزی نباید به معنی مجوز انجام هر کاری در همهٔ برنامه‌ها باشد. این جداسازی میان شناسایی کاربر و اختیار او، مبنای طراحی سالم است.
جریان درخواست و جایگاه پراکسی
در معماری متکی به پراکسی، درخواست کاربر ابتدا به پراکسی معکوس می‌رسد. پراکسی اطلاعات لازم برای تصمیم احراز هویت و مجوز را به Authelia می‌فرستد و بر اساس پاسخ، درخواست اصلی را عبور می‌دهد یا متوقف می‌کند. طبق مستند معماری، محتوای اصلی درخواست برنامه از Authelia عبور نمی‌کند. این ویژگی را نباید با مستقل بودن امنیت از پراکسی اشتباه گرفت؛ برعکس، صحت مسیریابی و اجرای تصمیم در پراکسی بخش مهمی از حفاظت است. مستندات پروژه HTTPS را برای وب‌سایت‌های حفاظت‌شده لازم می‌دانند.
در طراحی عملی، ابتدا مسیرهای رسیدن به برنامه را ترسیم کنید. نام عمومی، نشانی خصوصی، پورت میزبان، آدرس کانتینر و ورودی احتمالی از شبکهٔ مدیریت باید معلوم باشند. اگر کاربران بتوانند مستقیماً به backend دسترسی پیدا کنند، داشتن صفحهٔ ورود زیبا روی مسیر اصلی کافی نیست. هدف طراحی این است که مسیرهای مجاز از نقطهٔ اجرای سیاست عبور کنند و مسیرهای دیگر با کنترل شبکه یا سازوکار معتبر برنامه محدود شوند. این کار برای هر سرویس انجام می‌شود؛ محافظت از یک دامنه لزوماً زیرسامانهٔ دیگری روی پورت متفاوت را پوشش نمی‌دهد.
انتخاب روش اتصال برنامه
برنامه‌ای که OpenID Connect را پشتیبانی می‌کند می‌تواند از Authelia به عنوان ارائه‌دهندهٔ هویت استفاده کند. در این حالت برنامه باید برای همان روش ثبت و تنظیم شود. مستند رسمی می‌گوید Authelia در نقش ارائه‌دهنده عمل می‌کند و در حال حاضر نقش Relying Party را بر عهده ندارد. بنابراین نباید صرف مشاهدهٔ واژهٔ OIDC نتیجه گرفت که هر زنجیرهٔ دلخواه اتصال به ارائه‌دهندهٔ دیگر آماده است. پیش از تصمیم، راهنمای یکپارچه‌سازی همان محصول و نسخه را بررسی کنید.
در برنامه‌های دارای ورود مبتنی بر سرآیند مورد اعتماد، مسئولیت مهم دیگری ایجاد می‌شود: فقط جزء مورد اعتماد باید بتواند هویت را به برنامه اعلام کند. سرآیندی که کاربر بیرونی می‌فرستد نباید بدون پاک‌سازی و بازسازی معتبر پذیرفته شود. مدل تهدید پروژه به اعتماد شبکه و خطر سرآیندهای بدون امضا اشاره می‌کند. برای یک سامانهٔ جدید، ابتدا امکان استفاده از سازوکار استاندارد خود برنامه را بررسی کنید؛ اگر سرآیند انتخاب می‌شود، محدودیت دسترسی مستقیم و تنظیم دقیق پراکسی را جزو معیار پذیرش قرار دهید.
از سیاست کلی به قواعد قابل آزمون
Authelia قواعد کنترل دسترسی را با معیارهایی مانند دامنه، مسیر، موضوع کاربر یا گروه، روش HTTP و شبکه ترکیب می‌کند. این قابلیت برای تفکیک منابع مفید است، اما پیچیدگی قواعد باید متناسب با نیاز واقعی بماند. فهرست طولانی استثناها بدون توضیح، پس از مدتی فهمیدن علت دسترسی یک کاربر را دشوار می‌کند. برای هر قاعده بنویسید چه کسی، به چه منبعی، با چه سطح احراز هویت و به چه دلیل دسترسی دارد. همین توضیح کوتاه هنگام بازبینی یا تغییر مسئول تیم ارزش عملی دارد.
پیشنهاد عملی این است که پیش از پیکربندی، ماتریس کوچکی از نقش‌ها و منابع تهیه کنید. مدیر سامانه، عضو عادی و مهمان را از هم جدا کنید و برای هر کدام هم آزمون اجازه و هم آزمون رد داشته باشید. در یک ویکی، خواندن صفحهٔ عمومی و ویرایش تنظیمات ممکن است دو موضوع متفاوت باشند. همچنین دسترسی به صفحهٔ اصلی با دسترسی به endpointهای API یکسان نیست. قواعد باید با مسیرهای واقعی برنامه تطبیق داده شوند، نه با حدس از ظاهر رابط کاربری.
عامل دوم و تجربهٔ روزمرهٔ کاربر
پروژه چند روش عامل دوم را مستند کرده و برای ثبت وسیلهٔ دوم نیز فرایند تأیید هویت دارد. انتخاب روش باید به توان کاربران و سناریوی بازیابی حساب توجه کند. اگر همهٔ کاربران تنها یک وسیله داشته باشند، گم شدن همان وسیله می‌تواند کار روزانه را متوقف کند. از سوی دیگر، مسیر بازیابی بیش از حد آسان ممکن است ارزش عامل دوم را کاهش دهد. طرح مناسب باید به کاربر توضیح دهد چه چیزی را ثبت کند، در صورت فقدان وسیله با چه کسی تماس بگیرد و چه نوع تأییدی لازم خواهد بود.
برای استقرار اولیه، یک گروه کوچک از کاربران نماینده را انتخاب کنید: فردی با رایانهٔ سازمانی، فردی با تلفن همراه و کسی که از شبکهٔ دورکار متصل می‌شود. زمان ورود، وضوح پیام خطا و امکان بازگشت به برنامهٔ اولیه را بررسی کنید. اگر یک خطای ساده باعث شود کاربران روش‌های دور زدن کنترل را جست‌وجو کنند، مشکل فقط آموزشی نیست و ممکن است طراحی فرایند نیاز به اصلاح داشته باشد. راهنمای کوتاه و مبتنی بر وضعیت واقعی سازمان معمولاً از ارسال مجموعه‌ای از پیوندهای فنی مؤثرتر است.
نشست، خروج و تغییر عضویت
مدل تهدید Authelia نشست‌های دارای محدودیت زمانی را توضیح می‌دهد. در بهره‌برداری باید مدت نشست را با حساسیت منابع متناسب کرد. انقضای بسیار کوتاه برای ابزار کم‌خطر می‌تواند مزاحمت ایجاد کند و زمان بسیار بلند برای پنل حساس، پنجرهٔ سوءاستفاده از دستگاه رهاشده را افزایش دهد. تنظیمات را با گروه‌های واقعی کاربر آزمایش کنید و دربارهٔ اثر بستن مرورگر، خروج از درگاه و خروج از برنامه فرض نکنید؛ هر مسیر را مشاهده و مستند کنید.
آزمون تغییر عضویت نیز لازم است. یک حساب آزمایشی را از گروه دارای مجوز خارج کنید و بررسی کنید در چه زمانی دسترسی تازه و نشست موجود تغییر می‌کند. هدف این آزمون، کشف فاصلهٔ میان تصمیم اداری و اثر فنی آن است. اگر لغو دسترسی فوری برای بعضی منابع ضروری است، فرایند عملیاتی باید همان الزام را پوشش دهد. صرف حذف نام از یک فهرست، بدون بررسی cache، نشست و مجوز داخل برنامه، مدرک کافی برای پایان دسترسی نیست.
وابستگی‌ها و پایداری سرویس
سامانهٔ ورود مرکزی به نقطه‌ای حساس در دسترس‌پذیری تبدیل می‌شود. پیش از انتقال همهٔ سرویس‌ها، وابستگی‌های نصب خود را فهرست کنید: منبع هویت، ذخیره‌سازی، سرویس ایمیل، حل نام، گواهی TLS و هر جزء مدیریت نشست که در طرح انتخاب شده است. این فهرست باید از پیکربندی واقعی استخراج شود. برای هر وابستگی مشخص کنید خرابی آن چه اثری بر ورود تازه، نشست موجود و بازیابی حساب دارد. آزمون خرابی کنترل‌شده از حدس دربارهٔ رفتار اجزا قابل اعتمادتر است.
مسیر مدیریت اضطراری را نیز طراحی کنید، اما آن را به در پشتی عمومی تبدیل نکنید. بهتر است دسترسی لازم برای تعمیر سامانه در شبکهٔ مدیریت محدود، با حساب مستقل و ثبت رویداد باقی بماند. اگر خرابی سرویس ورود، دسترسی مدیر به همان سرویس را هم قطع کند، زمان بازیابی طولانی می‌شود. از طرف دیگر، استثنای دائمی و گسترده برای مدیر می‌تواند همهٔ قواعد را کم‌اثر کند. محدوده، مسئول، شرایط استفاده و بازبینی این مسیر باید روشن باشد.
نگهداری رازها و نسخهٔ پشتیبان
پیکربندی هویت معمولاً به اطلاعات حساسی وابسته است. قرار دادن رازها در مخزن عمومی، نمونهٔ آموزشی یا گزارش پشتیبانی می‌تواند پیامد وسیعی داشته باشد. برای محیط خود محل نگهداری، سطح دسترسی، روش توزیع و مسئول تعویض رازها را تعیین کنید. پیام خطا یا خروجی اشکال‌زدایی را پیش از ارسال بیرونی بازبینی کنید. حذف مقدار از فایل جاری نیز به معنی حذف آن از تاریخچهٔ مخزن یا نسخه‌های پشتیبان نیست؛ در افشای واقعی، تعویض اعتبارنامه بخش ضروری پاسخ است.
نسخهٔ پشتیبان باید امکان بازسازی سرویس را فراهم کند، نه فقط نگهداری یک فایل تنظیمات. اقلام لازم به backendهای انتخابی وابسته‌اند و باید از مستندات نسخهٔ مورد استفاده استخراج شوند. بازیابی را در محیط جدا با نام‌ها و دسترسی‌های آزمایشی انجام دهید تا اشتباهاً اعلان یا تغییر واقعی برای کاربران ایجاد نشود. زمان لازم برای راه‌اندازی، داده‌های از دست رفته و وابستگی‌های فراموش‌شده را ثبت کنید. پشتیبانی که هیچ‌گاه بازگردانی نشده، هنوز یک فرض دربارهٔ قابلیت بازیابی است.
پایش و بررسی خطا
برای عملیات روزانه، موفقیت ورود، خطاهای غیرعادی، سلامت وابستگی‌ها و زمان پاسخ را کنار هم ببینید. افزایش شکست ورود ممکن است ناشی از حمله، خطای تنظیم، خرابی منبع هویت یا مشکل کاربر باشد. انتخاب واکنش بدون تفکیک این علت‌ها می‌تواند کاربران مجاز را مسدود کند. گزارش باید زمان، سرویس مقصد و شناسهٔ لازم برای پیگیری را داشته باشد، ولی رمز عبور، cookie و توکن نباید بی‌دلیل وارد ثبت رویداد شوند. مدت نگهداری گزارش نیز باید مشخص باشد.
در عیب‌یابی، از یک درخواست آزمایشی مشخص شروع کنید و مسیر آن را از مرورگر تا پراکسی و تصمیم احراز هویت دنبال کنید. تغییر هم‌زمان چند تنظیم معمولاً فهم علت مشکل را دشوار می‌کند. ابتدا انتظار را بنویسید، سپس مشاهدهٔ واقعی و تفاوت آن را ثبت کنید. در محیط تولید، تغییر کوچک با امکان بازگشت و زمان‌بندی روشن انجام دهید. نمونه‌های اینترنتی ممکن است برای نسخه یا پراکسی دیگری نوشته شده باشند؛ راهنمای رسمی همان یکپارچه‌سازی باید مرجع اصلی باقی بماند.
معیار انتخاب و تحویل به تیم
Authelia برای تیمی جذاب است که سرویس‌های وب خودمیزبان دارد و می‌تواند پراکسی، هویت و نگهداری سامانه را مدیریت کند. اگر نیاز اصلی شما مجموعهٔ بزرگی از اتصال‌های سازمانی یا فرایندهای پیچیدهٔ چرخهٔ عمر حساب است، پیش از انتخاب فهرست نیازها را با امکانات مستند محصول تطبیق دهید. هیچ عنوان کلی مانند SSO جای این بررسی را نمی‌گیرد. هزینهٔ واقعی شامل زمان نگهداری، آموزش کاربر، آزمون بازیابی و پاسخ به قطعی نیز هست، حتی اگر استفاده از نرم‌افزار هزینهٔ مجوز جداگانه نداشته باشد.
تحویل قابل قبول باید شامل نقشهٔ مسیر درخواست، فهرست برنامه‌های متصل، ماتریس مجوز، روش بازیابی و مسئول به‌روزرسانی باشد. یک آزمون ورود موفق و یک تصویر از صفحهٔ ورود برای این تحویل کافی نیست. کاربر بدون مجوز، حساب حذف‌شده، نشست منقضی و خرابی وابستگی را نیز در برنامهٔ آزمون بگنجانید. نتیجهٔ این بررسی‌ها به تیم نشان می‌دهد کدام ادعا واقعاً آزموده شده و کدام مورد هنوز نیازمند کار است. پیشنهادهای این مقاله تحلیل عملیاتی تحریریه‌اند و جای مستند نسخه و ارزیابی محیط واقعی را نمی‌گیرند.
