• شنبه تا چهارشنبه 8:30-17 پنجشنبه 8:30-12:30
  • info@imennet.net
مشاوره رایگان 02188970170
ZTNA چیست و چه تفاوتی با VPN سنتی دارد؟

در چند سال اخیر با رشد دورکاری، سرویس های ابری، شعب پراکنده و استفاده گسترده از موبایل و لپتاپ های شخصی، مدل قدیمی دسترسی از راه دور دیگر به تنهایی جوابگو نیست. بسیاری از سازمان ها هنوز برای اتصال کاربران بیرون از شبکه به منابع داخلی از VPN سنتی استفاده می کنند؛ راهکاری که در اصل یک تونل امن تا داخل شبکه می سازد و کاربر را تقریبا مثل یک دستگاه داخلی وارد محدوده شبکه می کند. این روش اگرچه برای سناریوهای کلاسیک مفید بوده، اما در برابر تهدیدهای امروز مثل حرکت جانبی مهاجم (Lateral Movement)، سرقت اعتبارنامه ها و دسترسی بیش از حد (Over-Privileged Access) ریسک های جدی ایجاد می کند.

اینجاست که ZTNA یا Zero Trust Network Access مطرح می شود؛ رویکردی مدرن برای کنترل دسترسی که به جای اعتماد پیش فرض به کاربر یا دستگاه، همه چیز را بر پایه اصل “هرگز اعتماد نکن، همیشه راستی آزمایی کن” می چیند. در ZTNA، دسترسی کاربران به جای ورود کلی به شبکه، به صورت دسترسی دقیق به همان اپلیکیشن یا سرویس مشخص تعریف می شود و تصمیم گیری دسترسی با توجه به هویت کاربر، وضعیت امنیتی دستگاه، موقعیت، ریسک نشست و سیاست های سازمان به شکل پویا انجام می گیرد. نتیجه این است که سطح حمله کوچک تر می شود، منابع داخلی کمتر در معرض دید قرار می گیرند و مدیریت امنیت شبکه برای تیم IT شفاف تر و قابل کنترل تر خواهد بود.

تعریف ZTNA و ارتباط آن با Zero Trust

ZTNA مخفف عبارت Zero Trust Network Access و به معنای «دسترسی شبکه با اعتماد صفر» است. این فناوری یک مدل امنیتی برای دسترسی کاربران، دستگاه ها و سرویس ها به اپلیکیشن های سازمانی محسوب می شود. در ZTNA، هیچ کاربر، دستگاه یا اتصال شبکه ای به صورت پیش فرض قابل اعتماد در نظر گرفته نمی شود؛ حتی اگر کاربر از داخل شبکه سازمان یا یک VPN معتبر متصل شده باشد.

ZTNA یکی از راهکارهای اجرایی مهم در معماری گسترده تر Zero Trust است. معماری اعتماد صفر بر این اصل استوار است که هر درخواست دسترسی باید به صورت مستقل بررسی، تایید و محدود شود. بنابراین، ZTNA به جای فراهم کردن دسترسی گسترده به کل شبکه داخلی، فقط ارتباط کاربر با اپلیکیشن، سرویس یا منبع موردنیاز او را برقرار می کند.

برای مثال، کارشناس مالی می تواند فقط به سامانه حسابداری دسترسی داشته باشد، بدون اینکه بتواند سرورها، پنل های مدیریتی یا سایر بخش های شبکه داخلی را مشاهده یا اسکن کند. این رویکرد، سطح حمله را کاهش می دهد و احتمال حرکت جانبی مهاجم در شبکه را محدود می کند.

اجزای اصلی معماری ZTNA

یک راهکار ZTNA معمولا از چند جزء کلیدی تشکیل می شود که با همکاری یکدیگر، دسترسی امن و مبتنی بر سیاست را فراهم می کنند:

  • کاربر یا دستگاه درخواست کننده: کارمند، پیمانکار یا سرویس خودکاری که درخواست دسترسی به یک منبع سازمانی دارد.
  • ارائه دهنده هویت (Identity Provider): سامانه ای مانند Active Directory، Azure AD یا Okta که هویت کاربر، نقش سازمانی و وضعیت احراز هویت او را تایید می کند.
  • عامل یا کلاینت ZTNA: نرم افزاری روی دستگاه کاربر که اطلاعات وضعیت امنیتی دستگاه را جمع آوری می کند و ارتباط امن با سرویس ZTNA را برقرار می سازد. برخی راهکارها امکان دسترسی بدون عامل را نیز ارائه می دهند.
  • موتور سیاست گذاری و کنترل دسترسی: بخشی که بر اساس هویت، نقش کاربر، سطح ریسک، وضعیت دستگاه، موقعیت جغرافیایی و سیاست های امنیتی تصمیم می گیرد دسترسی مجاز است یا خیر.
  • کانکتور یا درگاه ZTNA: این جزء در نزدیکی اپلیکیشن یا داخل محیط سازمان، دیتاسنتر یا فضای ابری قرار می گیرد و ارتباط امن و خروجی محور با سرویس ZTNA ایجاد می کند. در نتیجه، اپلیکیشن داخلی مستقیما در اینترنت قابل مشاهده نیست.
  • اپلیکیشن یا منبع محافظت شده: سرویس هایی مانند CRM، ERP، سامانه منابع انسانی، داشبورد مدیریتی، سرورهای داخلی یا اپلیکیشن های وب سازمانی.

اجزا -اصلی معماری ztna

مطالعه کنید: مزایای برون سپاری پشتیبانی شبکه

مدل دسترسی مبتنی بر هویت، دستگاه و Context

مدل دسترسی در ZTNA فقط به وارد کردن نام کاربری و رمز عبور محدود نیست. این راهکار پیش از ایجاد ارتباط با اپلیکیشن، مجموعه ای از سیگنال های امنیتی را ارزیابی می کند تا مشخص شود درخواست در همان لحظه قابل اعتماد است یا خیر.

هویت مشخص می کند چه کسی درخواست دسترسی داده است؛ مثلا آیا کاربر عضو واحد مالی است و نقش او اجازه استفاده از سامانه حسابداری را دارد؟ وضعیت دستگاه بررسی می کند دستگاه موردنظر شرایط امنیتی لازم را دارد یا نه؛ مانند فعال بودن آنتی ویروس، به روز بودن سیستم عامل، رمزگذاری دیسک یا نبود نشانه های آلودگی.

Context نیز شرایط درخواست را در نظر می گیرد؛ از جمله موقعیت جغرافیایی، ساعت اتصال، نوع شبکه، IP، سطح ریسک نشست و رفتار غیرعادی کاربر.

در نتیجه، ZTNA می تواند برای یک کاربر مشخص در یک دستگاه سالم و از موقعیت مجاز، دسترسی به یک اپلیکیشن خاص را صادر کند؛ اما همان درخواست را از دستگاه شخصی ناامن، کشور غیرمنتظره یا در شرایط مشکوک مسدود یا با احراز هویت چندمرحله ای (MFA) محدود کند. این کنترل پویا، تفاوت اصلی مدل دسترسی ZTNA با VPN سنتی است که معمولا پس از اتصال، دسترسی گسترده تری به شبکه فراهم می کند.

VPN سنتی چیست و چه محدودیت هایی دارد؟

VPN مخفف Virtual Private Network به معنی «شبکه خصوصی مجازی» است. کارکرد اصلی VPN این است که آدرس پروتکل اینترنت (IP) شما را پوشش می‌ دهد و یک اتصال خصوصی و امن از دل یک اتصال وای‌ فای عمومی یا ناامن ایجاد می‌ کند. برای هر کاربری که به سرویس‌ های اینترنت عمومی متصل می‌ شود، VPN یکی از بهترین ابزارها برای حفظ حریم خصوصی، ناشناس ماندن و رمزگذاری داده‌ ها است.

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

VPN چگونه کار می‌ کند؟

یک راهکار VPN با ایجاد یک تونل رمزگذاری شده (Encrypted Tunnel) برای تمام داده‌ های ارسالی و دریافتی، از اطلاعات شما در برابر مشاهده یا رهگیری غیرمجاز محافظت می‌ کند.

مراحل کارکرد آن به شرح زیر است:

  1. تغییر مسیر ترافیک: VPN اتصال دستگاه شما را به جای ارائه‌ دهنده خدمات اینترنت (ISP)، از طریق یک سرور خصوصی ایمن هدایت می‌ کند.
  2. رمزگذاری داده‌ ها: داده‌ ها با استفاده از فرآیند رمزگذاری به کدهای نامفهوم و غیرقابل خواندن تبدیل می‌ شوند. این کدهای نامفهوم تنها با کلید اختصاصی که برای دستگاه شما و سرور تعریف شده است، قابل رمزگشایی هستند.
  3. تونل‌ سازی و انتقال: داده‌های رمزگذاری شده در طول مسیر انتقال بین دستگاه شما و سرور VPN (تونلینگ) محافظت می‌ شوند. سرور پس از دریافت داده‌ ها، آن‌ ها را رمزگشایی کرده و به مقصد نهایی (مثلاً یک وب‌سایت) ارسال می‌ کند. این فرآیند مانع از آن می‌شود که هکرها یا سازمان‌ های نظارتی بتوانند محتوای داده‌ ها را رهگیری و رمزگشایی کنند.

نقش پشتیبانی شبکه در مدیریت و پیاده‌ سازی VPN

پیاده‌سازی، نگهداری و عیب‌ یابی ارتباطات VPN یکی از وظایف کلیدی در پشتیبانی شبکه سازمان‌ ها است. کارشناسان پشتیبانی شبکه معمولاً این فناوری را از طریق دو پروتکل امنیتی اصلی پیاده‌ سازی و مدیریت می‌ کنند:

  • پروتکل IPSec (امنیت پروتکل اینترنت): که از کلیدهای از پیش اشتراک‌ گذاری‌شده روی کلاینت‌ ها و سرورها برای رمزگذاری ترافیک استفاده می‌ کند و معمولاً در اتصالات شعبه به شعبه کاربرد دارد.
  • پروتکل SSL (لایه سوکت‌ های امن): که از رمزنگاری کلید عمومی برای تبادل ایمن کلیدهای رمزگذاری استفاده می‌ کند و برای دسترسی کاربران دورکار مناسب‌ تر است.

همچنین متخصصان پشتیبانی شبکه برای بهینه‌ سازی پهنای باند و امنیت، از قابلیت تونل‌ سازی تقسیم‌ شده (Split Tunneling) استفاده می‌ کنند؛ قابلیتی که به کاربران اجازه می‌ دهد بخشی از ترافیک حساس خود را از مسیر امن VPN عبور دهند و برای ترافیک عمومی اینترنت، دسترسی مستقیم را حفظ کنند. علاوه بر این، در برخی سازمان‌ ها تیم پشتیبانی شبکه ممکن است به دلایل امنیتی یا افزایش بهره‌ وری، مسدودکننده‌ های VPN (VPN Blockers) را روی فایروال نصب کند تا از دسترسی کارکنان به سایت‌ های غیرمجاز مانند شبکه‌ های اجتماعی جلوگیری کند.

مشکلات امنیتی VPN در محیط های Hybrid و Cloud

استفاده از VPN به معنی ناامن بودن ذاتی آن نیست؛ VPN همچنان با رمزگذاری مناسب، MFA، کنترل های دسترسی و پیکربندی صحیح می تواند بخشی از معماری امنیت شبکه باشد. با این حال، در محیط های Hybrid و Cloud، مدل دسترسی شبکه محور VPN محدودیت هایی دارد که باید در طراحی امنیتی سازمان در نظر گرفته شوند:

  • دسترسی گسترده در سطح شبکه: پس از اتصال VPN، کاربر ممکن است به چندین Subnet، پورت یا منبع داخلی دسترسی داشته باشد؛ حتی اگر فقط به یک اپلیکیشن نیاز دارد. این موضوع با اصل حداقل سطح دسترسی (Least Privilege) همخوانی کامل ندارد.

  • ریسک حرکت جانبی مهاجم: اگر حساب کاربری، توکن نشست یا دستگاه متصل به VPN به خطر بیفتد، مهاجم می تواند برای شناسایی سرویس ها و حرکت به سمت منابع دیگر در شبکه تلاش کند. میزان موفقیت این حمله به Segmentation و سیاست های فایروال داخلی بستگی دارد.

  • افزایش سطح حمله دروازه VPN: گیت وی VPN معمولا از اینترنت در دسترس است و به یک نقطه مهم برای حملات Brute Force، Credential Stuffing، سوءاستفاده از آسیب پذیری های تجهیزات VPN و حملات DoS تبدیل می شود.

  • اتکای زیاد به احراز هویت اولیه: در بسیاری از پیاده سازی های VPN، ارزیابی اصلی در ابتدای ایجاد تونل انجام می شود. اگر شرایط دستگاه یا ریسک نشست پس از اتصال تغییر کند، اعمال کنترل های پیوسته و دقیق تر معمولا محدودتر از مدل ZTNA است.

  • دیده شدن منابع داخلی: در مدل های شبکه محور، بخشی از آدرس ها و سرویس های داخلی برای کاربر متصل قابل دسترس یا قابل شناسایی می شوند. این موضوع می تواند امکان Reconnaissance و نقشه برداری شبکه را افزایش دهد.

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

  • پیچیدگی اعمال سیاست یکپارچه در Hybrid Cloud: تعریف و نگهداری قوانین VPN، فایروال، ACL، Route و Segment برای منابع پراکنده در دیتاسنتر، چند Cloud و SaaS می تواند پیچیده و مستعد خطای پیکربندی شود.

  • مشکلات کارایی و تجربه کاربر: در Full Tunnel، عبور تمام ترافیک از دیتاسنتر یا گیت وی مرکزی می تواند باعث افزایش تاخیر، مصرف پهنای باند و ایجاد گلوگاه شود. در Split Tunnel نیز تفکیک نادرست مسیرها یا ضعف کنترل Endpoint می تواند ریسک امنیتی ایجاد کند.

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

به طور خلاصه، VPN سنتی ارتباط را در مسیر انتقال داده ایمن می کند، اما لزوما دسترسی را در سطح اپلیکیشن و بر اساس ریسک لحظه ای محدود نمی سازد. به همین دلیل، سازمان ها در کنار VPN یا به جای آن، از ZTNA برای اجرای دسترسی دقیق تر، کاهش سطح حمله و نزدیک شدن به مدل Zero Trust استفاده می کنند.

تفاوت ZTNA و VPN سنتی چیست؟

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

تفاوت در مدل دسترسی و سطح Exposure

تفاوت بنیادین ZTNA و VPN در مرزهای دسترسی (Access Boundary) و نحوه مواجهه با تهدیدات شبکه است:

  • مدل دسترسی (Access Model):
  • VPN سنتی: دسترسی در سطح شبکه (Network-level) ایجاد می‌ کند. کاربر پس از اتصال به دروازه VPN، یک آدرس IP داخلی دریافت کرده و وارد سگمنت یا محدوده خاصی از شبکه سازمان می‌ شود.
  • ZTNA: دسترسی در سطح اپلیکیشن (Application-level) برقرار می‌ کند. کاربر هیچ‌گاه مستقیماً به شبکه متصل نمی‌ شود؛ بلکه بین دستگاه او و تک‌تک اپلیکیشن‌ های مجاز، ارتباط مستقیم و ایزوله‌ ای در لایه کاربرد ایجاد خواهد شد.
  • سطح قرارگیری در معرض حمله (Exposure):
  • VPN سنتی: گیت‌ وی VPN باید در اینترنت عمومی قرار بگیرد تا کاربران بتوانند به آن وصل شوند. این پورت‌های باز، درگاه را در معرض اسکن بدافزارها و حملات DoS قرار می‌ دهند. همچنین در صورت نفوذ به VPN، مهاجم امکان اسکن و شناسایی منابع دیگر را در شبکه خواهد داشت.
  • ZTNA: اپلیکیشن‌ ها و منابع داخلی پشت کانکتورهای ZTNA پنهان می‌شوند و هیچ پورت باز یا آدرس IP عمومی در اینترنت ندارند. از دید بیرونی، این منابع کاملاً نامرئی یا اصطلاحاً Dark Network هستند.

تفاوت ZTNA و VPN سنتی

مطالعه کنید: تکنیک های امن سازی شبکه

تفاوت در احراز هویت و ارزیابی مداوم Trust

فرآیند اعتبارسنجی در این دو فناوری تفاوت‌ های ساختاری با یکدیگر دارند:

  1. احراز هویت در زمان اتصال (Point-in-Time) در برابر احراز هویت مداوم (Continuous Evaluation):

در VPN، احراز هویت فقط یک‌ بار و در زمان شروع اتصال (Tunnel Establishment) انجام می‌ شود. اگر پس از اتصال، دستگاه کاربر آلوده به باج‌ افزار شود یا هویت نشست سرقت رود، VPN به دلیل معتبر بودن تونل، متوجه تغییر شرایط نخواهد شد. در مقابل، ZTNA به صورت مداوم (Continuous Trust Verification) وضعیت هویت، رفتار کاربر و سلامت دستگاه را پایش می‌ کند و در صورت بروز کوچک‌ ترین تغییر مشکوک، دسترسی را قطع یا محدود می‌ کند.

  1. ارزیابی بافت و زمینه درخواست (Context-Awareness):

بسیاری از سرویس‌ های VPN سنتی اطلاعات محدودی از وضعیت سلامت دستگاه شخصی کاربر (مانند فعال بودن فایروال محلی یا آنتی‌ویروس) در حین اتصال دارند. اما ZTNA وضعیت دستگاه، موقعیت جغرافیایی، ساعت کاری و سطح ریسک نشست را به عنوان معیارهای اصلی مجاز بودن دسترسی بررسی می‌ کند.

  1. اصل حداقل دسترسی (Least Privilege Access):

در ZTNA، دسترسی بر اساس نقش و وظیفه (RBAC) به حداقل منابع ممکن محدود می‌ شود؛ در حالی که در VPN، اعمال چنین کنترل‌ های دقیقی نیاز به فایروال‌ های داخلی پیچیده و مدیریت ده‌ ها رول ACL دارد.

تفاوت در امنیت، مقیاس پذیری و تجربه کاربری

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

 

شاخص مقایسه VPN سنتی ZTNA (Zero Trust Network Access)
فلسفه امنیتی اتصال اول، احراز هویت دوم (اعتماد پیش‌ فرض) احراز هویت اول، اتصال دوم (اعتماد صفر)
محدوده دسترسی کل زیرشبکه یا سگمنت متصل‌ شده فقط اپلیکیشن یا سرویس مشخص و تعریف‌ شده
نمایانی منابع در اینترنت درگاه VPN در اینترنت نمایان و قابل اسکن است منابع کاملاً پنهان و غیرقابل اسکن هستند
مسیر عبور ترافیک ترافیک دورکاران باید به سمت گیت‌ وی مرکزی هدایت شود (Tromboning Effect) ترافیک به صورت بهینه و مستقیم به اپلیکیشن متصل می‌ شود
امنیت در محیط‌ های ابری پیچیدگی بالا در اتصال شبکه‌های Multi-Cloud مدیریت یکپارچه و مستقل از محل قرارگیری اپلیکیشن
تجربه کاربری (UX) نیاز به روشن/خاموش کردن مداوم کلاینت و تاخیر در اتصال اتصال بدون وقفه، شفاف (Seamless) و خودکار برای کاربر
کنترل دستگاه‌ های شخصی (BYOD) ریسک بالا به دلیل ورود مستقیم دستگاه غیرسازمانی به شبکه ریسک بسیار پایین به دلیل ایزوله بودن دسترسی در لایه اپلیکیشن
مقیاس‌ پذیری سخت‌افزاری وابسته به پهنای باند و قدرت پردازش سخت‌افزار گیت‌ وی VPN مقیاس‌پذیر در بستر ابر (Cloud-Scale) بدون نیاز به ارتقای فیزیکی

۱. چالش مقیاس‌ پذیری (Scalability)

در VPN سنتی، با افزایش تعداد پرسنل دورکار، پهنای باند و پردازش گیت‌ وی فیزیکی سازمان به گلوگاه تبدیل می‌ شود و برای ارتقا نیاز به خرید تجهیزات گران‌ قیمت سخت‌ افزاری است. ZTNA عمدتاً ابری (Cloud-delivered) است و به راحتی با افزایش یا کاهش تعداد کاربران مقیاس‌ پذیر خواهد بود.

۲. بهینه‌ سازی تجربه کاربری (User Experience)

کاربران VPN معمولاً با قطعی‌ های مکرر، نیاز به احراز هویت مجدد و افت سرعت اینترنت (به ویژه در حالت Full Tunnel) مواجه هستند. ZTNA با هدایت هوشمند ترافیک و احراز هویت نامحسوس در پس‌ زمینه، تجربه کاربری بسیار روان‌ تری ارائه می‌ دهد.

۳. مدیریت متمرکز در محیط‌ های هیبریدی

در معماری‌ های ابری ترکیبی (Hybrid Cloud)، هدایت ترافیک کاربران به دیتاسنتر محلی فقط برای رسیدن به یک اپلیکیشن ابری (مانند Office 365) بی‌ معنی است. ZTNA این چالش را با اعمال سیاست‌ های یکپارچه بدون نیاز به هدایت غیرضروری ترافیک (Hairpinning) حل می‌ کند.

مزایا و چالش های پیاده سازی ZTNA

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

مزایای امنیتی و عملیاتی

مهم ترین مزیت ZTNA این است که دسترسی را از سطح شبکه به سطح اپلیکیشن منتقل می کند. به بیان ساده، کاربر به جای ورود به یک Subnet یا شبکه داخلی، فقط به همان سرویس مشخصی متصل می شود که برای انجام وظیفه خود به آن نیاز دارد.

  1. کاهش سطح حمله و پنهان سازی اپلیکیشن ها

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

  2. اجرای اصل حداقل سطح دسترسی

    ZTNA امکان تعریف سیاست های دقیق بر اساس کاربر، نقش سازمانی، گروه، نوع دستگاه و اپلیکیشن را فراهم می کند. برای نمونه، کاربر واحد منابع انسانی می تواند تنها به پورتال HR دسترسی داشته باشد، بدون آنکه به سرور فایل، داشبوردهای مدیریتی یا سایر سیستم های شبکه دسترسی پیدا کند.

  3. کاهش ریسک حرکت جانبی مهاجم

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

  4. کنترل دسترسی پویا و مبتنی بر Context

    سیاست دسترسی می تواند علاوه بر هویت کاربر، عوامل دیگری مانند وضعیت امنیتی Endpoint، نسخه سیستم عامل، فعال بودن EDR، موقعیت جغرافیایی، IP، زمان اتصال و سطح ریسک نشست را نیز ارزیابی کند. در نتیجه، دسترسی یک کاربر ثابت نیست و با تغییر شرایط می تواند محدود، مشروط یا مسدود شود.

  5. مدیریت ساده تر دسترسی در Hybrid Cloud

    سازمان هایی که اپلیکیشن های خود را بین دیتاسنتر، Cloud خصوصی، Cloud عمومی و SaaS توزیع کرده اند، می توانند سیاست های دسترسی را مستقل از محل استقرار سرویس تعریف کنند. این ویژگی، وابستگی به تنظیمات پیچیده Route، ACL و VPN Site-to-Site را در بسیاری از سناریوها کاهش می دهد.

  6. بهبود تجربه کاربری و عملکرد

    در بسیاری از راهکارهای ZTNA، کاربر بدون اتصال دستی به VPN و بدون عبور دادن همه ترافیک از دیتاسنتر مرکزی، به اپلیکیشن مجاز دسترسی پیدا می کند. این موضوع می تواند تاخیر، مصرف پهنای باند و مشکلات ناشی از Full Tunnel را کاهش دهد؛ البته نتیجه نهایی به طراحی سرویس، محل PoPها و نوع اپلیکیشن وابسته است.

  7. دیدپذیری و ثبت رویداد دقیق تر

    ZTNA معمولا لاگ های دقیق تری از هویت کاربر، دستگاه، اپلیکیشن مقصد، زمان درخواست، سیاست اعمال شده و علت رد یا پذیرش دسترسی ارائه می دهد. این داده ها برای تیم SOC، بررسی رخداد، انطباق امنیتی و تحلیل رفتار کاربران کاربردی هستند.

جدول مقایسه ZTNA و VPN برای تصمیم گیری فنی

انتخاب بین ZTNA و VPN سنتی به نوع اپلیکیشن ها، معماری شبکه، وضعیت کاربران دورکار، سطح بلوغ مدیریت هویت و نیازهای عملیاتی سازمان بستگی دارد. VPN همچنان برای برخی دسترسی های شبکه محور، سیستم های قدیمی و سناریوهای مدیریتی کاربرد دارد؛ اما ZTNA برای ارائه دسترسی محدود، مبتنی بر هویت و اپلیکیشن محور در محیط های Hybrid و Cloud گزینه مناسب تری است.

معیار تصمیم گیری ZTNA VPN سنتی نتیجه عملی
مدل دسترسی دسترسی در سطح اپلیکیشن یا سرویس مشخص دسترسی در سطح شبکه، Subnet یا Routeهای تعریف شده برای اجرای Least Privilege، ZTNA مناسب تر است.
دامنه دسترسی کاربر کاربر فقط منابع مجاز خود را می بیند کاربر پس از اتصال ممکن است به چند منبع شبکه دسترسی داشته باشد ZTNA ریسک دسترسی بیش از حد را کاهش می دهد.
احراز هویت مبتنی بر Identity Provider، MFA و Policyهای پویا معمولا در زمان ایجاد Tunnel انجام می شود؛ امکان MFA نیز وجود دارد هر دو می توانند MFA داشته باشند، اما ZTNA معمولا کنترل Context محور دقیق تری ارائه می دهد.
ارزیابی وضعیت دستگاه قابل اتصال به EDR، MDM/UEM و Device Posture Check بسته به محصول VPN و NAC موجود، معمولا محدودتر یا پیچیده تر است برای BYOD و Endpointهای مدیریت شده، ZTNA مزیت بیشتری دارد.
ارزیابی مداوم ریسک امکان بازبینی دسترسی در طول Session بر اساس ریسک، هویت و وضعیت دستگاه اغلب تمرکز بر تایید اولیه اتصال است ZTNA برای کنترل نشست های پرریسک مناسب تر است.
کاهش حرکت جانبی مهاجم بالا، چون کاربر به کل شبکه وارد نمی شود وابسته به Segmentation، ACL و Firewall داخلی ZTNA به تنهایی جایگزین Segmentation نیست، اما حرکت جانبی را محدودتر می کند.
نمایانی منابع داخلی اپلیکیشن ها معمولا از اینترنت و کاربران غیرمجاز پنهان می مانند Gateway VPN باید برای کاربران مجاز قابل دسترس باشد هر دو به Hardening نیاز دارند؛ در ZTNA سطح Exposure منابع داخلی معمولا کمتر است.
پشتیبانی از اپلیکیشن های وب و SaaS بسیار مناسب، به ویژه برای اپلیکیشن های داخلی و Cloud قابل استفاده است، اما ممکن است ترافیک به صورت غیرضروری از Gateway مرکزی عبور کند برای SaaS و Web Appها، ZTNA معمولا تجربه و مسیر بهتری فراهم می کند.
پشتیبانی از Legacy Application وابسته به توانایی Vendor در پشتیبانی از پروتکل های خاص معمولا برای دسترسی شبکه ای به سیستم های قدیمی انعطاف پذیرتر است پیش از مهاجرت، وابستگی های اپلیکیشن های قدیمی باید تست شوند.
دسترسی ادمین و عملیات شبکه برای دسترسی محدود به ابزار یا سرور مشخص مناسب است برای مدیریت گسترده شبکه، تجهیزات و Subnetها کاربردی تر است بسیاری از سازمان ها برای برخی دسترسی های ادمین، VPN را حفظ می کنند.
مقیاس پذیری کاربران دورکار معمولا Cloud-delivered و مناسب افزایش کاربران و شعب پراکنده وابسته به ظرفیت Gateway، پهنای باند و معماری HA در سازمان های با نیروی دورکار گسترده، ZTNA فشار کمتری به دیتاسنتر مرکزی وارد می کند.
تجربه کاربری دسترسی شفاف تر و اغلب بدون اتصال دستی به Tunnel کامل نیازمند اتصال VPN و گاهی قطع و وصل یا افت کارایی برای کاربران عادی که فقط به چند اپلیکیشن نیاز دارند، ZTNA ساده تر است.
پیچیدگی پیاده سازی اولیه نیازمند طراحی IAM، گروه ها، Policy، Device Posture و Integration است برای سناریوهای پایه، پیاده سازی سریع تری دارد VPN برای نیاز فوری ساده تر است؛ ZTNA به طراحی معماری دقیق تری نیاز دارد.
هزینه و مدل لایسنس معمولا اشتراکی و بر اساس کاربر، قابلیت یا ترافیک هزینه تجهیزات، نگهداری، ظرفیت و لایسنس مقایسه باید بر مبنای TCO، نه فقط قیمت اولیه، انجام شود.

همجنین بخوانید: بررسی امنیت در مدل های OSI

برای تصمیم گیری فنی، ابتدا باید مشخص شود کاربران واقعا به چه چیزی نیاز دارند: شبکه یا اپلیکیشن. اگر اغلب کاربران فقط به سامانه هایی مانند ERP، CRM، داشبوردهای داخلی، پورتال منابع انسانی یا ابزارهای SaaS نیاز دارند، ZTNA انتخاب منطقی تری است؛ زیرا دسترسی را محدودتر و قابل مشاهده تر می کند. اما اگر تیم های فنی به Subnetهای مختلف، تجهیزات شبکه، فایل سرورها یا اپلیکیشن های قدیمی با وابستگی های متعدد دسترسی دارند، VPN ممکن است همچنان بخشی از معماری دسترسی باقی بماند.

در عمل، انتخاب سازمان ها اغلب «ZTNA یا VPN» نیست، بلکه یک مهاجرت مرحله ای از VPN به ZTNA است. در این مدل، اپلیکیشن های وب، کاربران دورکار و پیمانکاران ابتدا به ZTNA منتقل می شوند و VPN فقط برای سناریوهای خاص، موقت یا شبکه محور نگه داشته می شود.

نتیجه گیری: آیا ZTNA جایگزین VPN می شود؟

ZTNA در بسیاری از سناریوهای مدرن دسترسی از راه دور، گزینه ای دقیق تر و امن تر از VPN سنتی است. چون به جای اتصال کاربر به کل شبکه، فقط دسترسی به اپلیکیشن یا سرویس مجاز را فراهم می کند. همین تفاوت باعث می شود ZTNA با معماری Zero Trust، اصل حداقل سطح دسترسی و کاهش سطح حمله سازگاری بیشتری داشته باشد.

با این حال، VPN هنوز در برخی سناریوهای شبکه محور مانند دسترسی به تجهیزات، Subnetها یا بعضی اپلیکیشن های Legacy کاربرد دارد. بنابراین در اغلب سازمان ها، ZTNA لزوما جایگزین کامل VPN نمی شود، اما برای بخش بزرگی از دسترسی های Hybrid و Cloud، انتخاب مناسب تر و آینده نگرانه تری است.

نظرات کاربران
گروه‌های مقالات
اطلاعات تماس

میدان فاطمی خیابان گمنام بین ششم و هفتم پلاک ۳۴ واحد ۳

02188970170 09128581120 info@imennet.net