چرا یک OTP برای پوشش Wi-Fi، VPN و یک رجیستری کافی نیست

ورود یکپارچه یک هویت و پرسش‌های کمتر را وعده می‌دهد، اما این وعده در پروتکل سوم می‌شکند. تله این است که فرض کنیم یک احراز هویت موفق توکنی تولید می‌کند که هر پروتکل دیگری می‌تواند ارائه دهد. ورود به Wi-Fi، ورود به VPN و یک رجیستری کانتینر هر یک تبادل متفاوتی اجرا می‌کنند، با مخاطبان و عمرهای متفاوت. اشتراک‌گذاری حساب یک تصمیم دایرکتوری است؛ اشتراک‌گذاری اعتبارنامه یک تصمیم پروتکل است، و پروتکل‌ها به‌ندرت توافق می‌کنند.

سه تبادل، سه مالک

Wi-Fi سازمانی یک روش EAP را درون 802.1X اجرا می‌کند که معمولاً یک سرویس RADIUS با دیدگاه خودش از کاربر یا دستگاه آن را پایان می‌دهد. دروازه VPN از طریق جریان پشتیبانی‌شده خودش احراز هویت می‌کند و سپس نشستی با زمان‌سنج احراز مجدد خودش نگه می‌دارد. رجیستری به درخواست احرازنشده با چالشی پاسخ می‌دهد که یک سرویس توکن، یک مخاطب و یک دامنه را نام می‌برد، و کلاینت اعتبارنامه‌اش را با توکنی کوتاه‌عمر مبادله می‌کند.

این‌ها سه نمای یک نشست نیستند. هر یک بازبین خودش، عمر خودش و مسیر ابطال خودش را دارد، به همین دلیل تغییر گذرواژه در دایرکتوری می‌تواند یکی را سالم و دیگری را شکسته بگذارد. با آن‌ها مانند سه یکپارچه‌سازی رفتار کنید که تصادفاً یک دایرکتوری کاربران را به اشتراک می‌گذارند.

آنچه SSO مرورگر حمل می‌کند و آنچه نمی‌کند

نشست مرورگر در یک ارائه‌دهنده هویت واقعاً سودمند است: برنامه‌هایی که به آن تغییر مسیر می‌دهند، ورودی را که کاربر قبلاً کامل کرده به ارث می‌برند. این کار می‌کند چون آن برنامه‌ها همان پروتکل‌های تغییر مسیر و توکن را صحبت می‌کنند و همان مخاطب را می‌پذیرند. درخواست‌دهنده‌ای که EAP صحبت می‌کند هیچ تغییر مسیری برای دنبال کردن ندارد، و کلاینت Docker که چالش رجیستری دریافت می‌کند توکن هویت OIDC نمی‌خواهد. ارائه‌دهنده هویت فقط می‌تواند برای پروتکل‌هایی ضمانت کند که برای صحبت کردن آن‌ها ساخته شده است.

دیدن این شکست در گزارش‌ها آسان است، وقتی بدانید کجا را نگاه کنید. ارائه‌دهنده هویت ورود موفق را گزارش می‌کند در حالی که اتصال Wi-Fi هنوز شکست می‌خورد، یا رجیستری پس از تبادل توکنی که مرورگر هرگز ندید 401 برمی‌گرداند. دو موفقیت و یک شکست تناقض نیستند؛ آن‌ها سه احراز هویت جداگانه‌اند.

جایی که یک گواهی جایگزین کد تکراری می‌شود

برای دستگاه‌های مدیریت‌شده، EAP مبتنی بر گواهی مرحله انسانی را بدون حذف هویت برمی‌دارد: دستگاه گواهی‌ای ارائه می‌دهد، سرویس RADIUS آن را با مرجع صادرکننده بررسی می‌کند، و ابطال در همان مرجع رخ می‌دهد نه در یک راز مشترک. بهای آن کار چرخه عمر است، چون گواهی‌ها منقضی می‌شوند و باید پیش از آن تمدید شوند.

رجیستری‌ها تقسیم‌بندی معادلی دارند. کاربر تعاملی می‌تواند یک بار وارد شود و بگذارد یک کمک‌کننده اعتبارنامه توکن حاصل را ذخیره کند، در حالی که خودکارسازی باید از اعتبارنامه سرویس با دامنه محدود یا هویت بار کاری استفاده کند. هیچ‌یک از این دو نباید کد یکبارمصرف یک انسان باشد که در یک خط لوله کپی شده است. کمک‌کننده توکنی برای مخاطب مشخصی از رجیستری ذخیره می‌کند، پس با ویرایش یک فایل پیکربندی نمی‌توان آن را به دروازه VPN هدایت کرد.

docker login registry.example.com

هزینه نگهداری را مقایسه کنید، نه تعداد پرسش‌ها را

اعتبارنامه مشترک ارزان به نظر می‌رسد چون کار تا زمانی که شکست نخورد نامرئی است. در عوض بشمارید که هر گزینه در یک سال چه هزینه‌ای دارد: ثبت‌نام، تمدید، ابطال، شعاع اثر یک نشت، و شمار سامانه‌هایی که وقتی کسی می‌رود لمس می‌شوند. ناوگان گواهی ساختش گران‌تر و بهره‌برداری‌اش در مقیاس ارزان‌تر است؛ کد کپی‌شده شروعش هیچ هزینه‌ای ندارد و بازکردنش همه چیز.

سپس به تفکیک هر مسیر انتخاب کنید، نه به صورت کلی. Wi-Fi می‌تواند به گواهی‌ها برود، VPN می‌تواند SSO پشتیبانی‌شده با MFA را نگه دارد، و رجیستری می‌تواند از توکن‌هایی با دامنه‌های صریح استفاده کند. برای هر یک مالک، مخاطب، دامنه، انقضا و مسیر ابطال را ثبت کنید، و پرسش‌ها جای درست خود می‌افتند نه همه‌جا به‌طور همزمان. این ثبت همچنین پاسخ است وقتی یک حسابرس می‌پرسد کدام سامانه‌ها هنوز به گذرواژه اعتماد می‌کنند.