شناخت نیاز
کاربران، دستگاهها و سرویس‌های لازم برای کار را ثبت کنید.
کنترل دسترسی کاربران و فیلترینگ چیست؟
کنترل دسترسی تعیین میکند چه کاربر یا دستگاهی مجاز به استفاده از کدام منبع است. فیلترینگ وب، دسترسی به سایت‌ها یا دستههای محتوا را طبق سیاست تنظیم میکند. هدف سازمانی، حفظ امکان انجام کار در کنار محدودکردن دسترسی نامناسب است؛ یک فهرست طولانی سایت‌های مسدود، به‌تنهایی سیاست کامل ایجاد نمیکند.
این راهنما دربارهٔ سیاست دسترسی اینترنت و ارتباط با منابع شبکه است. مدیریت ایجاد حساب، عضویت گروه و مجوز پوشه موضوع جداگانه‌ای است که در راهنمای مدیریت دسترسی کاربران آمده است. اجرای کنترل روی شبکه باید با آن مجوزها هماهنگ باشد، نه جایگزین آن‌ها.
طراحی سیاست
دامنهٔ کنترل، گروه‌ها، استثناها و مسئولیت‌ها را تعیین کنید.
پایلوت و اصلاح
کار واقعی و مسدودسازی را با کاربران منتخب آزمون کنید.
تحویل و بازبینی
نتیجه، راهنمای کاربر و روال رسیدگی به خطا را مستند کنید.
چه زمانی سیاست دسترسی اینترنت سازمانی لازم است؟
وقتی همهٔ کاربران به یک سطح دسترسی نامشخص رسیده‌اند، نیاز کارکنان با مهمانان یکسان در نظر گرفته شده یا مسدودسازی سایت‌ها کار روزمره را مختل میکند، سیاست دسترسی باید بررسی شود. محدودیت باید با نقش و نیاز واقعی هماهنگ باشد؛ نه اینکه یک قاعده برای تمام افراد و همهٔ موقعیت‌ها اعمال شود.
- منابع داخلی: مشخص‌کردن اینکه هر بخش چه ارتباطی با سرورها و خدمات لازم دارد.
- استفاده از وب: تنظیم دسترسی به دسته‌ها یا مقصدهای تأییدشده، با امکان رسیدگی به خطا.
- دستگاه‌های متفاوت: تفکیک سیاست تجهیزات سازمانی، مشترک، شخصی و مهمان.
- کار خارج دفتر: بررسی اینکه کنترل در محل واقعی استفاده هم اعمال میشود یا نه.
معیار تحویل دو بخش دارد: کاربر مجاز باید بتواند کارش را انجام دهد و دسترسی خارج از دامنهٔ او محدود شود. فقط زیادبودن تعداد قواعد یا گزارش‌های مسدودسازی، معیار موفقیت نیست.
سیاست دسترسی را قبل از انتخاب ابزار تعریف کنید
برای هر گروه، منابع لازم، نوع کار، محل استفاده و مسئول تأیید را ثبت کنید. اتصال به شبکهٔ داخلی نباید به‌تنهایی مجوز همهٔ منابع باشد؛ معماری Zero Trust در NIST نیز اعتماد ضمنی صرفاً بر اساس محل شبکه یا مالکیت دستگاه را مبنا قرار نمیدهد.
سیاست باید مشخص کند چه چیزی مجاز، محدود یا نیازمند تأیید است. مالک هر استثنا و زمان بازبینی آن معلوم باشد. اگر سیاست وابسته به ساعت کار یا محل اتصال است، رفتار مورد انتظار در شرایط متفاوت ثبت شود. جزئیات را با مدیران واحدها و مسئول فنی هماهنگ کنید؛ یک نیاز کاری ناشناخته نباید تازه پس از مسدودسازی کشف شود.
کنترل مصرف اینترنت با کنترل دسترسی یکسان نیست. ممکن است خدمتی مجاز باشد اما برای جلوگیری از فشار روی ارتباط، مدیریت مصرف لازم داشته باشد. این موضوع با بخش پهنای باند، اینترنت و ارتباطات امن بررسی شود؛ کمبود سرعت الزاماً دلیل مسدودکردن یک خدمت نیست.
تفاوت فیلترینگ DNS، URL و کنترل برنامه
فیلترینگ DNS؛ کنترل در سطح نام دامنه
DNS نام دامنه را به آدرس شبکه مرتبط میکند. فیلتر در این لایه میتواند تصمیم بگیرد درخواست یک دامنه پاسخ داده شود یا نه، اما مسیر یک صفحه را مانند URL کامل بررسی نمیکند. در توضیح Cloudflare دربارهٔ DNS و URL filtering نیز تفاوت مسدودکردن کل سایت و کنترل صفحهٔ مشخص بیان شده است.
مسیر استفادهٔ دستگاهها از خدمت DNS و دامنهٔ پوشش آن باید با طرح شبکه هماهنگ باشند. فعال‌بودن یک فهرست روی یک Resolver، به‌تنهایی ثابت نمیکند تمام دستگاهها تحت همان سیاست‌اند. وابستگی برنامه‌ها و حل نام داخلی را هم بررسی کنید؛ برای مبانی، راهنمای DHCP و DNS سازمانی مکمل است.
فیلترینگ URL و دسته‌بندی محتوای وب
در بسترهای دارای قابلیت مناسب، کنترل وب میتواند بر مقصد، دستهٔ محتوا یا مسیر URL اعمال شود. میزان دید و روش کنترل، به محصول، نوع ترافیک و تنظیمات بستگی دارد. دربارهٔ HTTPS، فرض نکنید هر ابزار قادر به دیدن تمام مسیر یا محتوای ارتباط است؛ قابلیت و پیش‌نیاز واقعی باید از مستندات همان بستر بررسی شوند.
دسته‌بندی همیشه با نیاز کاری منطبق نیست. سایتی ممکن است برای یک واحد لازم باشد ولی در دسته‌ای محدود قرار گرفته باشد. برای نمونه، مستندات فیلترینگ وب Microsoft Defender سیاست‌های دسته‌بندی و امکان تعریف استثنا برای سایت مشخص را توضیح می‌دهد. قابلیت و تقدم سیاست‌ها باید در همان نسخه و طرح مجوز بررسی شوند.
کنترل برنامه و ارتباط منابع داخلی
برنامهٔ سازمانی ممکن است از چند مقصد و خدمت استفاده کند؛ کنترل یک وبسایت، کل رفتار آن برنامه را پوشش نمیدهد. ارتباط شبکه با منابع داخلی و تشخیص برنامه باید متناسب با توان بستر طراحی شوند. این لایه با فایروال سازمانی و قواعد ارتباط مرتبط است؛ بازبودن مسیر، جای ورود معتبر و مجوز خود برنامه را نمی‌گیرد.
سیاست به کاربر اعمال میشود یا به دستگاه؟
پیش از اجرا روشن کنید ابزار، کاربر را تشخیص می‌دهد یا بر اساس دستگاه، گروه تجهیزات یا بخش شبکه تصمیم می‌گیرد. این مدل‌ها معادل هم نیستند. در یک رایانهٔ مشترک، چند نفر ممکن است از یک دستگاه استفاده کنند؛ همچنین تغییر آدرس IP میتواند نسبت آدرس و کاربر را عوض کند. انتساب سیاست باید قابل اتکا و آزمون‌پذیر باشد.
در نمونهٔ Microsoft Defender for Endpoint، سیاست‌های فیلترینگ وب می‌توانند به گروه دستگاه اعمال شوند؛ امکانات دامنه‌بندی در محصولات و طرح‌های مختلف یکسان نیست. این مثال، توصیهٔ خرید محصول یا تأیید سیاست مبتنی بر هویت برای همهٔ ابزارها نیست.
- عضویت گروه و مسئول تغییر آن مشخص باشند.
- حساب مشترک و دستگاه مشترک در آزمون جدا بررسی شوند.
- رفتار دستگاه ناشناخته یا کاربر شناسایی‌نشده تعریف شود.
- تغییر نقش، جابه‌جایی دستگاه و پایان همکاری در روال بازبینی قرار گیرند.
استثناها و مسدودشدن اشتباه سایت‌ها
برای درخواست رفع محدودیت، اطلاعات لازم و غیرمحرمانه را دریافت کنید: زمان رخداد، نشانی عمومی سایت، خدمت موردنیاز و پیام خطا. مسئول بررسی باید تشخیص دهد علت، دسته‌بندی، قاعده، وضعیت دستگاه یا مشکل ارتباط است. نتیجه با کاربر و مالک نیاز کاری هماهنگ شود.
اگر استثنا پذیرفته شد، دامنهٔ آن محدود، دلیل و مالک مشخص و زمان بازبینی ثبت شود. بازکردن یک دستهٔ بزرگ برای رفع مشکل یک سایت، میتواند دامنهٔ سیاست را بی‌دلیل تغییر دهد. پس از اصلاح، هم کارکرد خدمت و هم باقی‌ماندن محدودیت‌های موردنظر آزموده شوند.
پیام مسدودسازی باید برای کاربر قابل فهم باشد و مسیر رسیدگی را نشان دهد، بدون نمایش تنظیمات محرمانهٔ شبکه. تعریف این روال از تماس‌های پراکنده و تغییرهای موردی بدون ثبت جلوگیری میکند. برای پیگیری منظم درخواست‌ها، سامانهٔ تیکتینگ سازمانی قابل بررسی است.
کنترل دسترسی دورکاران و مهمانان
محل اجرای سیاست مهم است. کنترلی که فقط روی خروجی اینترنت دفتر قرار دارد، الزاماً کاربر خارج دفتر را پوشش نمیدهد. عامل روی دستگاه یا بستر ارتباط کنترل‌شده، در صورت پشتیبانی و پذیرش سیاست سازمان، باید از محل واقعی کار آزموده شود؛ فقط ورود موفق به VPN نتیجهٔ آزمون کامل نیست.
دستگاه شخصی و مهمان، شرایط مدیریت یکسانی با دستگاه سازمانی ندارند. دامنهٔ کنترل، منابع مجاز و اطلاعاتی که ثبت می‌شوند روشن باشند. مهمان معمولاً نیاز یکسانی با کاربر سامانهٔ مالی ندارد؛ جداسازی مسیر و محدودیت منابع داخلی باید طراحی شوند. جزئیات روش اتصال در راهنمای ایجاد دسترسی دورکاری آمده است.
گزارشگیری و حریم خصوصی در سیاست سازمانی
هدف گزارش را قبل از جمع‌آوری داده تعیین کنید: رسیدگی به خطا، بررسی عملکرد سیاست یا رخداد امنیتی. مشخص کنید چه داده‌ای ثبت میشود، چه مدت نگهداری میشود و چه افرادی حق مشاهده دارند. جمع‌آوری بیشتر، لزوماً تصمیم بهتر ایجاد نمیکند؛ دادهٔ لازم برای هدف تعریف‌شده و حفاظت از گزارش‌ها مهم است.
کاربران باید از دامنهٔ سیاست و روش رسیدگی آگاه باشند. تنظیمات بازرسی ارتباط رمز‌شده، در صورت نیاز و پشتیبانی، باید با بررسی فنی و تأیید مسئولان مربوط انتخاب شوند؛ نه به‌عنوان گزینهٔ همگانی و بدون توضیح. رمزنگاری ارتباطات را عمومی غیرفعال نکنید و رمزها، کد ورود و محتوای محرمانه را در گزارش یا درخواست عادی پشتیبانی قرار ندهید.
دسترسی مدیر به گزارش‌ها از اختیار تغییر قواعد تفکیک و مطابق نقش تعریف شود. برای گزارش دورهای، فقط داشتن نمودار کافی نیست؛ یافته باید مسئول پیگیری و اقدام مشخص داشته باشد. این مقاله، بررسی حقوقی یا تأیید انطباق سیاست با مقررات نیست؛ الزامات سازمان باید جدا ارزیابی شوند.
مراحل اجرای کنترل دسترسی و فیلترینگ شبکه
- نیازسنجی: ثبت نقش‌ها، دستگاهها، منابع، سایت‌های کاری و محل استفاده.
- طراحی: انتخاب لایهٔ کنترل، دامنهٔ سیاست، گروهبندی، استثناها و گزارش موردنیاز.
- آماده‌سازی: بررسی سازگاری، مجوز، بکاپ تنظیمات، اطلاع‌رسانی و مسیر بازگشت.
- پایلوت: آزمون کار روزمره و محدودیت‌ها با گروه منتخب و مقصدهای بی‌خطر آزمایشی.
- اصلاح و توسعه: رسیدگی به خطاها و اعمال مرحله‌ای سیاست تأییدشده.
- پذیرش: ثبت نتایج، محدودیت‌های باقی‌مانده، راهنمای کاربر و مسئول نگهداری.
برای آزمون محدودیت، از مقصد آزمایشی بی‌خطر در دامنهٔ مجاز پروژه استفاده کنید؛ بازکردن عمدی سایت آلوده یا استفاده از اطلاعات حساس لازم نیست. اعمال و لغو استثنا، تغییر گروه، استفاده از دستگاه مشترک و دسترسی خارج دفتر نیز در دامنهٔ توافق‌شده بررسی شوند.
اگر پس از تغییر یک برنامه از کار افتاد، ابتدا رخداد و وابستگی آن را بررسی کنید. خاموش‌کردن عمومی حفاظت، جای عیب‌یابی نیست. مسیر بازگشت باید مشخص کند چگونه سیاست جدید با ثبت نتیجه برگردانده میشود، بدون اینکه تنظیمات معتبر قبلی از بین بروند.
هزینه کنترل دسترسی و فیلترینگ سازمانی
کاربران و دستگاهها، محل‌های استفاده، لایهٔ کنترل، مجوز، اتصال به هویت سازمان، گزارشگیری و نگهداری در برآورد اثر دارند. طراحی اولیه و مهاجرت را از هزینهٔ اشتراک و پشتیبانی دورهای جدا کنید. دامنهٔ تحویل باید مشخص کند چه منابع و دستگاه‌هایی پوشش داده می‌شوند و چه مواردی خارج از محدوده‌اند.
پیشنهادها را فقط با نام محصول یا تعداد قواعد مقایسه نکنید. قابلیت گروهبندی، رسیدگی به خطا، حفاظت گزارش و آزمون روی دستگاه‌های واقعی هم مهم‌اند. قیمت روز و شرایط مجوز هنگام تهیهٔ پیشنهاد بررسی شوند؛ این راهنما مبلغ ثابت یا صرفه‌جویی تضمین‌شده ارائه نمیکند.
چک‌لیست تحویل سیاست دسترسی و فیلترینگ
- ثبت دامنه، گروه‌ها، منابع مجاز و مسئول تأیید هر سیاست
- آزمون کارکرد خدمات مجاز و محدودیت مقصدهای آزمایشی توافق‌شده
- نتیجهٔ آزمون دستگاه مشترک، مهمان و دورکار در صورت شمول پروژه
- روال ثبت، تأیید، لغو و بازبینی استثناها
- پیام قابل فهم برای کاربر و مسیر رسیدگی به مسدودسازی اشتباه
- دامنهٔ گزارش، مدت نگهداری، سطح دسترسی مدیران و حفاظت داده
- بکاپ تنظیمات، راهنمای نگهداری، مجوزها و مسئول بازبینی دورهای
بررسی سیاست دسترسی در ویوان نت
برای شروع، تعداد کاربران و دستگاهها، واحدهای کاری، منابع موردنیاز و مشکل فعلی را در بخش پشتیبانی ویوان نت توضیح دهید. رمز، گزارش حاوی اطلاعات شخصی یا فایل تنظیمات محرمانه را در درخواست اولیه ارسال نکنید. پس از نیازسنجی، محدودهٔ طراحی، آزمون و نگهداری قابل تعریف است.
سناریوی آموزشی: سیاست متفاوت برای واحد مالی و فروش
فرض کنید واحد مالی به منابع داخلی مشخص نیاز دارد و واحد فروش از سایت‌های کاری بیرونی استفاده میکند. یک سیاست مشترک، بخشی از کار فروش را مسدود کرده است. هدف، رفع نیاز تأییدشده بدون بازکردن بی‌ضابطهٔ همهٔ مقصدهاست.
ابتدا نیازها و دامنهٔ گروه‌ها ثبت می‌شوند و معلوم میشود ابزار سیاست را به کاربر اعمال میکند یا به دستگاه. در پایلوت، سایت کاری و منابع داخلی مجاز آزموده می‌شوند؛ یک مقصد آزمایشی بی‌خطر هم برای بررسی محدودیت به‌کار می‌رود. استثنای سایت فروش با دلیل، مالک و بازبینی مشخص ثبت میشود.
استفاده از رایانهٔ مشترک و جابه‌جایی کاربر نیز بررسی میشود تا سیاست به گروه اشتباه اعمال نشود. پس از پذیرش، راهنمای کاربر و روال رسیدگی تحویل داده می‌شوند. این سناریو پروژهٔ واقعی ویوان نت نیست و امنیت کامل یا نتیجهٔ عددی تضمین نمیکند.
این راهنما از مجموعهٔ امنیت شبکه و اطلاعات ویوان نت است. برای شناخت مجموعه، معرفی ویوان نت را ببینید.
پرسش‌های متداول دربارهٔ کنترل دسترسی و فیلترینگ
کنترل دسترسی کاربران با فیلترینگ وب چه تفاوتی دارد؟
کنترل دسترسی مشخص میکند چه کاربر یا دستگاهی به کدام منبع و خدمت مجاز است. فیلترینگ وب، دسترسی به وبسایتها یا دستههای محتوا را تنظیم میکند. این دو مکملاند؛ بستن یک وبسایت، مجوز فایل یا حساب برنامه را تعیین نمیکند.
فیلترینگ DNS میتواند فقط یک صفحه از سایت را مسدود کند؟
DNS بر نام دامنه کار میکند و مسیر صفحه را مبنای تصمیم قرار نمیدهد. برای کنترل مسیر URL باید قابلیت مناسب در بستر وب بررسی شود. انتخاب روش به نیاز، نوع ترافیک و امکانات محصول بستگی دارد؛ همهٔ ابزارها دید یکسانی ندارند.
آیا میتوان برای واحدهای مختلف سیاست متفاوت تعریف کرد؟
در بسترهای پشتیبانیشده ممکن است، اما باید روشن باشد سیاست به کاربر، گروه هویتی، دستگاه یا بخش شبکه اعمال میشود. قابلیت گروهبندی و شرایط مجوز محصول بررسی و روی دستگاه مشترک و کاربران منتخب آزموده شوند.
اگر سایتی که برای کار لازم است اشتباه مسدود شود چه کنیم؟
زمان رخداد، نشانی عمومی سایت، گروه کاربر و پیام خطا بررسی شوند. پس از تأیید نیاز، استثنای محدود با مالک و زمان بازبینی تعریف و آزمون شود. بازکردن یک دستهٔ کامل یا غیرفعال‌کردن عمومی حفاظت، راهکار دائمی مناسبی نیست.
آیا سیاست فیلترینگ برای کارکنان دورکار هم اجرا میشود؟
به محل اجرای کنترل و مسیر ارتباط بستگی دارد. کنترل فقط روی شبکهٔ دفتر، پوشش خارج دفتر را تضمین نمیکند. عامل روی دستگاه یا بستر دسترسی کنترل‌شده، در صورت پشتیبانی و پذیرش سیاست سازمان، باید از محل واقعی دورکاری آزموده شود.
هزینه کنترل دسترسی و فیلترینگ شبکه به چه چیزهایی بستگی دارد؟
تعداد کاربران و دستگاهها، محل کار، روش اعمال سیاست، امکانات محصول، مجوز، اتصال به هویت سازمان، گزارشگیری و پشتیبانی مؤثرند. هزینهٔ طراحی و اجرا از اشتراک و نگهداری دورهای جدا برآورد شود؛ قیمت بدون نیازسنجی قابل اتکا نیست.
منابع فنی و مطالعهٔ بیشتر
منابع برای مبانی و نمونهٔ قابلیت محصولات‌اند. انتخاب و دامنهٔ سیاست باید با نسخه، مجوز و مستندات بستر واقعی تطبیق داده شوند؛ مقاله به ابزار مشخصی محدود نیست.