قاعده دسترسی بر پایه نام میزبان در هر لایه شبکه چه معنایی می‌تواند داشته باشد
نام یک سرویس را می‌توان در سطح DNS، مرورگر، پراکسی یا فایروال اعمال کرد. لایه‌ای را انتخاب کنید که هویتی را می‌بیند که می‌خواهید مدیریت کنید.
سه نفر یک چیز را با همان واژه‌ها می‌خواهند: مسدود کردن دسترسی به یک نام سرویس. یکی منظورش این است که مرورگر نباید سایت را باز کند، دیگری منظورش این است که یک کلاینت صوتی رومیزی نباید به سرور خود برسد، و سومی منظورش این است که گروهی از پیمانکاران نباید از یک برنامه داخلی خاص استفاده کنند. جمله یکسان است، و سازوکارهای اجرا تقریباً هیچ وجه مشترکی ندارند.
لایه را بر اساس شناسه‌ای انتخاب کنید که واقعاً می‌تواند ببیند، و سپس بر اساس کلاینت‌هایی که پوشش می‌دهد. شروع از یک فرمان فایروال که از قبل می‌شناسید همان راهی است که قواعد در نهایت چیزی را مسدود نمی‌کنند، یا بیش از حد مسدود می‌کنند.
نام هویتی نیست که هر لایه بتواند بررسی کند
Netfilter و فیلترهای بسته مشابه نشانی‌ها، پروتکل‌ها و درگاه‌ها را می‌بینند. آن‌ها نام میزبان‌ها را نمی‌بینند، و تا زمانی که بسته به آن‌ها برسد نام از قبل حل شده است. قاعده‌ای که علیه یک نشانی نوشته می‌شود قاعده‌ای درباره همان نشانی است، هر نامی که کاربر برای رسیدن به آن تایپ کرده باشد.
سیاست DNS زودتر در مسیر قرار دارد و پرس‌وجو را می‌بیند، که شیئی متفاوت از اتصال پس از آن است. این سیاست پاسخ‌هایی را کنترل می‌کند که یک حل‌کننده تحت کنترل برمی‌گرداند، نه اتصال‌هایی که از قبل باز بوده‌اند، و نه کلاینت‌هایی که برای دور زدن آن حل‌کننده پیکربندی شده‌اند. نشانی حل‌شده همچنین می‌تواند بین بازبینی سیاست و درخواست بعدی تغییر کند، و به همین دلیل پاسخ DNS یک بیانیه مجوز پایدار نیست.
لایه‌های بالاتر زمینه بیشتری می‌بینند و کلاینت کمتری را پوشش می‌دهند. این معامله تمام موضوع است، و توضیح می‌دهد چرا هیچ ردیف واحدی از جدول هرگز پاسخ درست نیست. ردیفی را انتخاب کنید که شناسه‌ای را می‌بیند که سیاست شما واقعاً درباره آن است. سپس پوششی را که آن ردیف ایجاب می‌کند بپذیرید.
هر لایه چه چیزی را می‌تواند شناسایی کند
جدول را از ستون میانی به بیرون بخوانید: شناسه‌ای که یک لایه می‌بیند سیاستی را تعیین می‌کند که می‌تواند صادقانه اجرا کند.
| Layer | Identifier it sees | What it cannot see |
|---|---|---|
| Packet filter | address, protocol, port | the name, or which other services share that address |
| DNS policy | the queried name and the answer handed back | connections made by clients that ignore the resolver |
| Managed browser | supported URL patterns on managed profiles | non-browser clients, or unmanaged devices |
| CONNECT proxy | host and port for tunnelled requests | the path inside an encrypted request |
یک لایه تنها زمانی به سیاست تعلق دارد که شناسه‌ای که می‌بیند با شناسه‌ای که مدیریت می‌کنید مطابقت داشته باشد. جدول همچنین توضیح می‌دهد چرا قاعده‌ای که در یک لایه نوشته شده به ندرت بدون تصمیم دوباره درباره آنچه محافظت می‌کند به لایه دیگری منتقل می‌شود.
جایی که قاعده بدیهی شکست می‌خورد
قاعده نشانی برای سرویسی با نشانی اختصاصی که شما کنترل می‌کنید دقیقاً درست است، و این مالکیت باید در سیاست نوشته شود. برای هر چیزی پشت یک نشانی مشترک تحویل محتوا دقیقاً نادرست است، جایی که همان قاعده سرویس‌های نامرتبط را لمس می‌کند و پاسخ DNS تازه‌شده قاعده را به مجوز نام میزبان تبدیل نمی‌کند.
سیاست مرورگر مدیریت‌شده محدودیت وب را مستقیم‌تر از فهرست نشانی کپی‌شده بیان می‌کند، اما برای مرورگرها و نمایه‌هایی اعمال می‌شود که سیستم مدیریت آن‌ها را اداره می‌کند.
آن قاعده مرورگر درباره کلاینت صوتی که UDP به میزبان دیگری می‌فرستد هیچ کاری نمی‌کند، و الگوهای آن توسط آن محصول تعریف می‌شود نه با قراردادهای نویسه عام که از جای دیگری گرفته شده باشد. پراکسی CONNECT نیز میزبان و درگاه را برای درخواست تونل‌شده دریافت می‌کند و نمی‌تواند مسیر داخل نشست رمزنگاری‌شده را بخواند. قاعده را حول آنچه پروتکل آشکار می‌کند طراحی کنید. سپس بنویسید چه چیزی را بدون پوشش می‌گذارد، زیرا همان شکاف جایی است که درخواست بعدی از آن می‌آید.
بر اساس کلاینت‌ها انتخاب کنید، نه بر اساس فرمان
بپرسید سیاست باید کدام کلاینت‌ها را پوشش دهد و کدام‌ها را ممکن است از دست بدهد. سیاست مرورگر مدیریت‌شده آنچه را سیستم مدیریت به آن می‌رسد پوشش می‌دهد و در مرز مرورگر متوقف می‌شود. سیاست حل‌کننده هر چیزی را که از حل‌کننده شما استفاده می‌کند پوشش می‌دهد، که مجموعه گسترده‌تری است، و برای کسانی که این کار را نمی‌کنند به‌صورت باز شکست می‌خورد.
برای سرویسی که خودتان اداره می‌کنید، مجوز در برنامه قوی‌تر از هر مرز شبکه‌ای است، زیرا از حساب پیروی می‌کند نه از مسیر. مسیر VPN فقط دسترس‌پذیری است و نه چیزی بیشتر: توانایی فرستادن بسته به یک سرویس مجوز استفاده از آن نیست. جایی که شناسه مهم یک کاربر یا مجوز کانال است، آن را همان‌جا اجرا کنید و قاعده شبکه را لایه دوم بدانید.
قاعده را بر حسب منبع بنویسید
سیاست قابل دفاع منبع، هویت‌ها، برنامه‌های در محدوده و مسیری را که آن‌ها را حمل می‌کند نام می‌برد، از جمله هر دو خانواده نشانی که در استفاده است. همچنین بیان می‌کند که با زیرساخت مشترکی که قاعده به‌طور اتفاقی تحت تأثیر قرار می‌دهد چه می‌شود.
این بیان تصمیمی می‌سازد که کسی بعداً می‌تواند آن را حسابرسی کند. قاعده‌ای که با نشانی حل‌شده امروز توجیه می‌شود نخستین بار که نشانی تغییر کند یک حادثه می‌سازد، و هیچ‌کس نمی‌تواند توضیح دهد چرا آن مسدودسازی هرگز درست بوده است.