چرا یک قاعده VPN نمی~تواند جلوی بارگذاری یک فایل را بگیرد
دسترسی به یک سرویس و کنترل اینکه کدام فایل~ها از آن خارج می~شوند دو نیاز جداگانه است. قاعده را جایی بگذارید که فایل دیده می~شود: ایمیل، برنامه یا عامل نقطه پایانی.
یک تیم کوچک دسترسی از راه دور به سامانههای کاری خود میخواهد و در همان نفس میخواهد که برخی پیوستها دیگر شرکت را ترک نکنند. هر دو درخواست مثل یک تغییر VPN به نظر میرسند. آنها دو نیاز با دو نقطه اعمال متفاوت هستند و قاعدهای که اولی را برآورده میکند برای دومی هیچ کاری نمیکند. اول کنش و داده را نامگذاری کنید، بعد مؤلفهای را انتخاب کنید که واقعاً میتواند آنها را ببیند.
یک درخواست، دو نیاز
نیاز اول به دسترسیپذیری مربوط است: کدام کاربران و دستگاهها میتوانند به کدام سرویس اتصال باز کنند. نیاز دوم به رفتار پس از برقراری آن اتصال مربوط است: کدام اسناد را میتوان پیوست، جایگذاری یا بارگذاری کرد. تونل روی اولی کار میکند و بنا به طراحی نسبت به دومی کور است.
یک کنترل در سطح IP بستهها را هدایت میکند. این کنترل بارگذاری چندبخشی را تجزیه نمیکند، فایلی PDF را بازرسی نمیکند و تصمیم نمیگیرد که آیا یک صفحهگسترده شمارهحساب دارد یا نه. انتظار این کار از آن خطای پیکربندی نیست؛ خطای دستهبندی است.
پیش از جستوجوی محصول، نیاز را با همین شکل بلند بگویید. «کاربران میتوانند به درگاه فایل برسند» و «کاربران نمیتوانند فهرستهای مشتری را به درگاه فایل بارگذاری کنند» دو جمله متفاوت هستند و تنها دومی سیاست محتوا را توصیف میکند.
مؤلفهای را انتخاب کنید که فایل را میبیند
اعمال باید جایی رخ دهد که فایل خوانا است. برای ایمیل، این معمولاً سکوی ایمیل یا درگاه آن است که از قبل پیوستها را مدیریت میکند و میتواند آنها را پیش از تحویل ارزیابی کند. برای بارگذاریهای مرورگر به یک سرویس تأییدشده، ممکن است خود برنامه تنها طرفی باشد که محتوا را میبیند. برای یک لپتاپ مدیریتشده که فایلها را به رسانههای جداشدنی کپی میکند، عامل نقطه پایانی آن عمل را میبیند.
| Where the file moves | Component that can see it |
|---|---|
| Email attachment | Mail gateway or mail platform policy |
| Upload to a web application | The application, or an inspection proxy that terminates TLS |
| Copy to USB or local folder | Endpoint agent on the device |
| Anything inside the tunnel | Nothing, unless one of the above is present |
برخی بستههای تجاری دسترسی از راه دور، عامل نقطه پایانی، کنترل وب و ماژول جلوگیری از نشت داده را با هم دارند. آن مؤلفهها میتوانند سیاست محتوا را اعمال کنند، اما این توانایی به ماژول تعلق دارد نه به تونلسازی. پیش از وعده دادن نتیجه، بخوانید که بسته واقعاً چه چیزی شامل میشود.
نمای کلی جلوگیری از نشت داده در Purview مایکروسافت مدل مفیدی برای مقایسه است: سیاستها را بر اساس انواع اطلاعات حساس، مکانها و فعالیتها توصیف میکند. این واژگان درباره محتوا و کنشهاست، نه پیشوندهای IP.
TLS از تونل جان سالم به در میبرد، پس برایش برنامه داشته باشید
رمزنگاری برنامه بین کارخواه و سرویس چانهزنی میشود و تونل VPN آن بایتها را بدون باز کردن حمل میکند. بنابراین یک درگاه در مسیر بهطور خودکار توانایی دستهبندی یک پیوست را به دست نمیآورد، هر مقدار از مسیر که در اختیار داشته باشد.
برای بازرسی محتوا در مسیر به مؤلفهای نیاز دارید که TLS را با گواهی مورد اعتماد پایان دهد، و این یک تصمیم معماری مهم با پیامدهای حریم خصوصی و عملیاتی خودش است. این یک کادر تیک در نمایه VPN نیست. کارخواهها باید به گواهی بازرسی اعتماد کنند، برنامههایی که گواهیها را پین میکنند میشکنند و اپراتور توانایی خواندن ترافیکی را به دست میآورد که پیشتر نمیتوانست. همینها دلیلهایی است که این تصمیم متعلق به مالک امنیت است نه کسی که تونل را اداره میکند.
به همین دلیل پاسخ صادقانه به «آیا VPN میتواند این بارگذاری را مسدود کند» معمولاً نه است و پس از آن یک جایگزین مشخص میآید. جایگزین میتواند محدودیتهای سطح برنامه، یک قاعده ایمیل یا سیاست نقطه پایانی باشد و هر یک مالکی دارد که میتواند آن را تغییر دهد.
پیش از قاعده، آزمون پذیرش را بنویسید
یک قاعده محتوا به دو نمونه نیاز دارد نه یکی: کنشی مجاز که باید به کار ادامه دهد و کنشی ممنوع که باید متوقف شود. هر دو را از برنامهها و دستگاههای در محدوده آزمایش کنید، چون سیاستی که فقط در یک مرورگر کار میکند همان سیاستی نیست که کسی خواسته است.
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/upload
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/uploadدرخواست اول باید توسط هر مؤلفهای که قاعده را دارد رد شود و دومی باید موفق شود. اگر هر دو موفق شوند، کنترل در مسیر نیست. اگر هر دو شکست بخورند، سرویس را خراب کردهاید نه محافظت، و این نتیجه رایجتر قاعدهای است که بدون یک نمونه مجاز نوشته شده است.
از پیش تصمیم بگیرید کاربر چه میبیند، چه کسی میتواند استثنا بدهد و مدیر کجا بعداً تصمیم را تأیید میکند. بارگذاری مسدودشده بدون پیام یک تیکت پشتیبانی تولید میکند و قاعدهای که هیچکس نمیتواند حسابرسی کند یک بحث تولید میکند. هر دو با یک جمله مستندسازی که پیش از اجرای سیاست نوشته شود قابل اجتناب است.
در پایان، دو نیاز را در دو تیکت جداگانه با دو مالک جداگانه نگه دارید. جمع کردن آنها زیر «VPN» تضمین میکند که از تیم شبکه خواسته شود یک مسئله محتوا را حل کند و اینکه مسئله محتوا وقتی تونل بالا آمد حلشده اعلام شود.