جایگزینی یک پورتال قدیمی فایل VPN: کنترلها را حفظ کنید
یک کلاینت فایل بومی و یک پورتال پروکسی مجوزها، بازیابی و هویت را در مکانهای متفاوت اعمال میکنند. آنها را در چهار عملیاتی که کاربران نیاز دارند مقایسه کنید.
پورتال قدیمی بدون کلاینت یک دکمه حذف، یک ستاره علاقهمندی و یک مسیر اشتراکگذاری داشت که در یک ایمیل چسبانده میشد. تنها یکی از آنها یک کنترل است. جایگزینی پورتال یعنی تصمیمگیری درباره اینکه کاربران راه دور هنوز به کدام عملیات نیاز دارند و هر یک کجا اعمال میشود، نه بازسازی چیدمان صفحهای که تصادفاً کار میکرد. دو شکل جایگزین بیشتر موارد را پوشش میدهند و در نقاط متفاوتی شکست میخورند.
دکمه مجوز نیست
با فهرست عملیات شروع کنید: خواندن، بارگذاری، تغییر نام، حذف. تصمیم بگیرید کدام نقشها هر یک را دریافت میکنند، سپس آن تصمیم را در سرویس فایل اعمال کنید نه در رابط. پنهان کردن یک کنترل حذف در پورتال جدید مجوز پشتصحنه را دستنخورده باقی میگذارد و هر کسی با یک کلاینت بومی و همان حساب هنوز میتواند فایل را بردارد.
حذف سزاوار تصمیم جداگانهای است چون همان عملیاتی است که کاربران از آن پشیمان میشوند. بپرسید یک مورد حذفشده واقعاً از کجا قابل بازیابی است و فرض نکنید که پاسخ سطل بازیافت لپتاپ یا سطل بازیافت خود پورتال است. اشتراک شبکه بهطور کلی حذفها را از سطل بازیافت محلی عبور نمیدهد.
روی یک اشتراک با پشتیبانی Windows، Volume Shadow Copy مکانیزم عکس فوری و هماهنگی مورد استفاده نرمافزار پشتیبانگیری را فراهم میکند، اما حضور آن چیزی درباره حفظ نسخههایی که میتوانید بازیابی کنید نمیگوید. مالک سرویس فایل باید سیاست نسخهها را تأیید کند و پیش از بازنشستگی پورتال یک بازیابی را نشان دهد.
گزینه A: یک کلاینت فایل بومی روی تونل
یک درایو نقشهنگاریشده یا کلاینت SMB عملیاتی را که کاربران از قبل میشناسند حفظ میکند و مجوزها در هر درخواست توسط سرور فایل اعمال میشوند. هویتی که اهمیت دارد هویت سرویس فایل است، بنابراین دسترسی از تغییر محصول VPN جان سالم به در میبرد تا زمانی که تونل هنوز ترافیک را حمل کند و حساب هنوز وجود داشته باشد.
هزینه این است که کلاینت باید مستقیماً به سرویس برسد. حل نام، دسترسپذیری پورت و روش احراز هویت همگی بخشی از طراحی دسترسی راه دور میشوند و پورتالی که قبلاً اتصال را پروکسی میکرد هر یک از این الزامات را پنهان مینمود. کاربران روی دستگاههای مدیریتنشده هم اشتراکی نصبشده در مدیر فایل خود دریافت میکنند که سطحی گستردهتر از یک تب مرورگر است. برای این بار پشتیبانی پیش از مهاجرت بودجه بگذارید، چون در روز اول میرسد نه پس از یک دوره مهلت.
بازیابی قویترین استدلال برای این شکل است: نسخههای قبلی و مجوزهای بازیابی بومی پلتفرم هستند و میز پشتیبانی میتواند همان رویهای را که در محل استفاده میکند به کار ببرد.
گزینه B: یک پروکسی یا دروازه برنامه
پورتالی که فایل را میآورد و به مرورگر پخش میکند سرویس فایل را بیرون از مسیر شبکه کاربر نگه میدارد. این وقتی مفید است که دستگاه نمیتواند به تونل بپیوندد یا زمانی که سازمان میخواهد هر درخواست در یک نقطه تنگنا ثبت شود. معامله این است که پروکسی در هر عملیات شرکتکننده میشود و باید هویت کاربر را تا سرویس فایل حمل کند بهجای اینکه برای همه چیز از حساب سرویس خودش استفاده کند.
رفتار حذف و تغییر نام باید پیادهسازی شود نه به ارث برسد. اگر پروکسی یک کنش حذف ارائه میدهد، آن کنش پشتصحنه را با هویتی صدا میزند و ردپای حسابرسی باید کاربر را نام ببرد نه دروازه را. اگر پروکسی نمیتواند تغییر نام دهد، پیش از آنکه کاربران در میانه یک پروژه کشف کنند بگویید.
بازنویسی پیوند جایی است که این شکل بیصدا معنا را تغییر میدهد. URLی که پورتال پروکسی میکند همان شیء URLی نیست که مرورگر مستقیماً باز میکند و تبدیل یکی به دیگری میتواند زمینه احراز هویتی را که آن را کارآمد کرده بود بردارد.
نامها، هویتها و پیوندهای میان آنها
سرور و مسیر اشتراک تأییدشده را توزیع کنید نه فهرست مرور دامنه. مرور به سرویسهای کشف وابسته است که ممکن است از تونل عبور نکنند و مسیری که کار میکند چون لپتاپ کاربر میتواند یک دامنه را برشمارد مسیری است که روی دستگاه مدیریتنشده بعدی میشکند.
ورود یکپارچه را برنامه به برنامه بررسی کنید. توکنی که برای پورتال صادر میشود نباید به سرویس فایلی که هرگز آن را اعتبارسنجی نکرده بازپخش شود و پارامترهای پرسوجویی که شناسهها را حمل میکنند نباید فقط به این دلیل که در نشانک قدیمی ظاهر شدهاند در یک پیوند عمومی کپی شوند. هر برنامه تأییدشده را مرز اعتماد خودش بدانید.
| Requirement | Native client | Proxy portal |
|---|---|---|
| Permission enforcement | File service, per request | Proxy identity, then file service |
| Restore path | Platform versions and backups | Proxy trash plus backend restore |
| Device requirements | Tunnel and client | Browser only |
| Audit identity | File server logs | Proxy logs, if it forwards the user |
بر اساس فهرست الزامات انتخاب کنید
هیچیک از دو شکل کاملاً برنده نیست. نیروی کاری با لپتاپهای مدیریتشده و تونل کارآمد از کلاینت بومی بیشتر بهره میبرد، چون بازیابی و مجوزها از پلتفرم میآیند نه از یک بازپیادهسازی. جمعیت مختلطی از پیمانکاران و دستگاههای شخصی میتواند پروکسی را توجیه کند، به شرط آنکه زیرساخت هویت واقعی باشد و یک حساب سرویس مشترک نباشد.
مقایسه را در برابر چهار عملیات و پاسخ بازیابی بنویسید، سپس پورتال قدیمی را تنها پس از اجرای یک بازیابی از مسیر جدید بازنشسته کنید. آن آزمون بخشهایی از طراحی را تمرین میدهد که یک ورود موفق هرگز لمس نمیکند.