تفاوت Network DLP، Endpoint DLP و Cloud DLP؛ راهنمای انتخاب معماری حفاظت از داده

در قسمت سوم این مجموعه، معماری داخلی DLP، موتورهای تشخیص، Policy Engine و فرآیند تصمیم‌گیری از شناسایی داده تا واکنش بررسی شد.

اما یک سؤال مهم برای طراحی معماری امنیت سازمان باقی می‌ماند:

هر نوع DLP دقیقاً کجا قرار می‌گیرد و چه بخشی از مسیر داده را می‌تواند کنترل کند؟

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

بنابراین سازمان نمی‌تواند صرفاً با انتخاب یک نقطه کنترلی انتظار داشته باشد تمام مسیرهای خروج داده پوشش داده شوند.

در معماری‌های رایج DLP، سه مدل اصلی اهمیت ویژه‌ای دارند:

1. Network DLP
2. Endpoint DLP
3. Cloud DLP

اما تفاوت این سه مدل فقط در محل نصب نرم‌افزار نیست؛ هرکدام دید متفاوتی نسبت به داده دارند و نقاط قوت و محدودیت‌های متفاوتی ایجاد می‌کنند.

Network DLP؛ حفاظت از داده هنگام عبور از شبکه

Network DLP روی داده‌هایی تمرکز دارد که از مسیرهای شبکه سازمان عبور می‌کنند.

در معماری سنتی، Network DLP معمولاً در نقاطی مانند:

• Internet Gateway
• Mail Gateway
• Proxy
• Web Gateway
• Network Perimeter
• نقاط خروجی سازمان

قرار می‌گیرد.

هدف اصلی این معماری پاسخ به یک سؤال است:

آیا داده حساس در حال عبور از یک مسیر شبکه‌ای است که نباید از آن خارج شود؟

Network DLP چگونه عمل می‌کند؟

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

Network DLP می‌تواند بسته به معماری سازمان:

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

برای مثال:

Customer Data + External Destination + Unauthorized Channel → Block

اما اگر همان انتقال از طریق یک مقصد مورد تأیید سازمان انجام شود، Policy می‌تواند نتیجه متفاوتی داشته باشد.

مزایای Network DLP

مزیت	توضیح
دید متمرکز	امکان نظارت بر مسیرهای خروجی شبکه از نقاط مرکزی
پوشش تعداد زیاد کاربران	بدون نیاز به نصب Agent روی تمام دستگاه‌ها
کنترل ارتباطات خارجی	مناسب برای Web، Email و سایر مسیرهای شبکه
مدیریت مرکزی Policy	امکان اعمال سیاست‌های یکپارچه در Gateway
مناسب برای محیط‌های سنتی	عملکرد مناسب در معماری‌های On-Premise و Perimeter-Based

 

محدودیت‌های Network DLP

مهم‌ترین محدودیت Network DLP این است که:

اگر ترافیک از نقطه‌ای عبور نکند که سازمان بتواند آن را مشاهده کند، Network DLP نیز دیدی نسبت به آن نخواهد داشت.

این مسئله در معماری‌های امروزی اهمیت زیادی دارد.

رمزگذاری

بخش زیادی از ارتباطات امروزی با TLS رمزگذاری می‌شود.

در نتیجه، مشاهده محتوای واقعی ترافیک ممکن است به قابلیت‌هایی مانند:

• TLS Inspection
• Proxy
• Secure Web Gateway
• Integration با کنترل‌های امنیتی دیگر

نیاز داشته باشد.

دورکاری

کاربری که خارج از شبکه سازمان و بدون VPN به سرویس Cloud متصل می‌شود، الزاماً از مسیر Network DLP سازمان عبور نمی‌کند.

SaaS

کاربر ممکن است مستقیماً از لپ‌تاپ خود به یک سرویس SaaS متصل شود.

در این شرایط، Network DLP سنتی ممکن است دید کاملی نسبت به فعالیت نداشته باشد.

بنابراین Network DLP در محیط‌های مدرن همچنان ارزشمند است، اما نمی‌تواند به‌تنهایی تمام سطح حمله داده را پوشش دهد.

Endpoint DLP؛ کنترل داده روی دستگاه کاربر

Endpoint DLP کنترل را از سطح شبکه به خود دستگاه کاربر منتقل می‌کند.

این راهکار معمولاً روی:

• Laptop
• Desktop
• Workstation
• Terminal

فعال می‌شود و فعالیت‌هایی را که می‌توانند باعث خروج داده شوند، کنترل می‌کند.

مهم‌ترین تفاوت Endpoint DLP با Network DLP این است که:

Network DLP داده را هنگام عبور از مسیر شبکه می‌بیند؛ Endpoint DLP می‌تواند فعالیت مرتبط با داده را روی خود دستگاه مشاهده کند.

Endpoint DLP چه چیزهایی را کنترل می‌کند؟

کانال / فعالیت	قابلیت Endpoint DLP
USB	کنترل یا مسدودسازی Copy
Print	کنترل چاپ اسناد حساس
Copy/Paste	جلوگیری از انتقال اطلاعات به برنامه‌های غیرمجاز
File Transfer	کنترل جابه‌جایی فایل
Browser Upload	کنترل Upload به سرویس‌های خارجی
Cloud Sync	کنترل انتقال به فضای ابری
Screenshot	در راهکارهایی که این قابلیت را ارائه می‌کنند
Email Client	کنترل فعالیت ایمیلی روی Endpoint

البته همه محصولات Endpoint DLP الزاماً تمام این قابلیت‌ها را با یک سطح پوشش ارائه نمی‌کنند و هنگام انتخاب محصول باید Feature Matrix آن بررسی شود.

چرا Endpoint DLP برای دورکاری اهمیت دارد؟

فرض کنید کارمند از خانه با لپ‌تاپ سازمانی خود کار می‌کند.

او یک فایل Confidential را باز می‌کند و سپس آن را روی یک USB شخصی Copy می‌کند.

در این سناریو:

Network DLP ممکن است هیچ دیدی نسبت به انتقال نداشته باشد.

اما Endpoint DLP می‌تواند فعالیت Copy به USB را روی همان دستگاه مشاهده و بر اساس Policy واکنش نشان دهد.

همین موضوع برای انتقال فایل به سرویس‌های Cloud شخصی نیز اهمیت دارد.

بنابراین در محیط‌هایی که:

• Remote Work
• BYOD
• Laptopهای سازمانی
• SaaS
• Cloud
• اینترنت مستقیم

رواج دارند، Endpoint DLP می‌تواند یک لایه مهم در معماری حفاظت از داده باشد.

Cloud DLP؛ وقتی داده دیگر داخل شبکه سازمان نیست

یکی از مهم‌ترین تغییرات معماری امنیت اطلاعات، انتقال داده از Data Centerهای سنتی به Cloud و SaaS است.

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

• Microsoft 365
• Google Workspace
• Salesforce
• Box
• Slack
• AWS
• Microsoft Azure
• Snowflake
• سایر سرویس‌های SaaS و Cloud

قرار داشته باشند.

در چنین محیطی، این فرض که:

«داده حساس داخل شبکه سازمان قرار دارد»

دیگر کافی نیست.

Cloud DLP برای کنترل داده در محیط‌های Cloud و SaaS طراحی شده است.

Cloud DLP چه چیزی را کنترل می‌کند؟

Cloud DLP می‌تواند در سناریوهایی مانند موارد زیر نقش داشته باشد:

• شناسایی فایل‌های حساس در Cloud
• تشخیص داده‌های بیش از حد در معرض دسترسی
• بررسی Sharing
• شناسایی Public Link
• کنترل انتقال داده بین سرویس‌ها
• شناسایی داده حساس در SaaS
• اعمال Policy روی داده‌های Cloud
• کنترل برخی مسیرهای خروج داده از سرویس‌های ابری

برای مثال:

Confidential File + Public Sharing Link → Block / Remove Sharing

یا:

Sensitive Data + Unauthorized Cloud Destination → Alert / Block

Cloud DLP و مشکل Shadow IT

یکی از مهم‌ترین چالش‌های Cloud، Shadow IT است.

Shadow IT زمانی اتفاق می‌افتد که کاربران بدون هماهنگی رسمی با تیم فناوری اطلاعات از سرویس‌ها یا ابزارهای خارج از فهرست تأییدشده سازمان استفاده کنند.

برای مثال:

کاربر فایل کاری را از سیستم سازمانی خود در یک فضای ابری شخصی Upload می‌کند.

از نگاه کاربر:

«فقط می‌خواهم فایل را از خانه باز کنم.»

اما از دید امنیت اطلاعات:

«یک نسخه از داده سازمان از کنترل مستقیم سازمان خارج شده است.»

گزارش ۲۰۲۵ Netskope نشان داد ۲۶٪ کاربران مورد بررسی هر ماه داده را به اپلیکیشن‌های شخصی ارسال، آپلود یا در آن‌ها منتشر می‌کردند؛ این گزارش Google Drive و Microsoft OneDrive شخصی را نیز در میان مقصدهای مهم انتقال داده قرار می‌دهد.

بنابراین Cloud DLP باید صرفاً به فایل‌های داخل Cloud سازمان محدود نشود و در صورت امکان، ارتباط میان کاربر، دستگاه، اپلیکیشن، مقصد و داده را نیز در نظر بگیرد.

یک آمار مهم درباره ریسک داده در Cloud

مطالعه 2025 State of Data Security Report شرکت Varonis روی داده‌های واقعی ۱۰۰۰ سازمان انجام شد و نزدیک به ۱۰ میلیارد منبع Cloud را بررسی کرد.

نتیجه قابل توجه این بود که:

۹۰٪ سازمان‌های بررسی‌شده دارای داده حساس Cloud در معرض دسترسی بودند.

این عدد به معنای وقوع Breach در ۹۰٪ سازمان‌ها نیست.

منظور از آن، وجود داده حساس در وضعیتی است که دسترسی به آن بیش از سطح مطلوب Exposure ایجاد می‌کند.

همین موضوع نشان می‌دهد Cloud DLP را نباید صرفاً یک ابزار برای «Block کردن Upload» در نظر گرفت؛ بخش مهمی از مسئله، شناخت محل داده، سطح دسترسی و نحوه اشتراک‌گذاری آن است.

مقایسه Network DLP، Endpoint DLP و Cloud DLP

کدام DLP برای کدام سناریو مناسب است؟

انتخاب معماری باید بر اساس مسیر واقعی داده انجام شود، نه صرفاً نام محصول.

آیا Endpoint DLP از Network DLP بهتر است؟

پاسخ کوتاه:

خیر.

این دو برای حل یک مسئله یکسان طراحی نشده‌اند.

Network DLP برای سازمانی ارزشمند است که می‌خواهد مسیرهای خروجی شبکه را در یک نقطه مرکزی کنترل کند.

Endpoint DLP برای سازمانی اهمیت بیشتری پیدا می‌کند که باید فعالیت کاربر و داده را روی دستگاه کنترل کند.

بنابراین مقایسه «کدام بهتر است؟» چندان دقیق نیست.

سؤال درست این است:

کدام نقطه از مسیر داده برای سازمان من بیشترین ریسک را ایجاد می‌کند؟

اگر پاسخ Email Gateway باشد، Network/Email DLP اهمیت بیشتری دارد.

اگر پاسخ USB و Laptop باشد، Endpoint DLP اولویت دارد.

اگر پاسخ Microsoft 365، Google Workspace یا سایر SaaSها باشد، Cloud DLP اهمیت بیشتری پیدا می‌کند.

یک سناریوی واقعی؛ چرا یک DLP کافی نیست؟

فرض کنید یک کارمند به یک فایل حاوی اطلاعات مشتریان دسترسی دارد.

مرحله اول: Endpoint

فایل روی Laptop کاربر قرار دارد.

کاربر آن را باز می‌کند و سپس تلاش می‌کند روی USB شخصی Copy کند.

Endpoint DLP می‌تواند این فعالیت را کنترل کند.

مرحله دوم: Cloud

کاربر به جای USB، فایل را در فضای ابری شخصی Upload می‌کند.

اکنون مسئله وارد حوزه Cloud و Web شده است.

Cloud/Web DLP و کنترل‌های Endpoint می‌توانند در این نقطه نقش داشته باشند.

مرحله سوم: Sharing

کاربر فایل را در یک سرویس ابری قرار داده و لینک عمومی ایجاد می‌کند.

اکنون مسئله اصلی، Cloud Exposure است.

Cloud DLP می‌تواند Sharing و Policy مربوط به داده حساس را بررسی کند.

مرحله چهارم: Email

کاربر لینک فایل را برای یک آدرس خارجی ارسال می‌کند.

در این نقطه Email DLP می‌تواند انتقال اطلاعات را بررسی کند.

بنابراین یک زنجیره ساده ایجاد می‌شود:

Endpoint → Cloud → Sharing → Email

اگر سازمان فقط یکی از این نقاط را کنترل کند، نقاط دیگر همچنان می‌توانند Blind Spot ایجاد کنند.

آمار واقعی؛ مشکل اصلی فقط کمبود ابزار نیست

گزارش 2025 Data Security Report که توسط Fortinet و Cybersecurity Insiders منتشر شده، تصویری جالب از پراکندگی ابزارهای حفاظت از داده ارائه می‌کند.

در این بررسی:

• ۴۸٪ سازمان‌ها Endpoint DLP داشتند.
• ۴۶٪ Email DLP داشتند.
• ۴۱٪ از Cloud DLP یا CASB استفاده می‌کردند.
• ۳۷٪ Network DLP داشتند.
• فقط ۲۸٪ از Data Discovery، Data Classification یا DSPM استفاده می‌کردند.

نکته مهم‌تر این بود که هیچ‌یک از این فناوری‌ها در بیش از ۵۰٪ سازمان‌های مورد بررسی استفاده نمی‌شدند.

این آمار یک پیام معماری مهم دارد:

سازمان‌ها معمولاً چند کنترل امنیتی دارند، اما این کنترل‌ها الزاماً یک معماری یکپارچه تشکیل نمی‌دهند.

حتی Fortinet گزارش کرده تنها ۴۷٪ سازمان‌های مورد بررسی، راهکار DLP فعلی خود را در جلوگیری از خروج داده حساس مؤثر می‌دانستند.

مشکل معماری‌های جزیره‌ای

فرض کنید سازمان سه محصول جداگانه دارد:

Endpoint DLP + Email DLP + Cloud DLP

اما هرکدام Console، Policy و Alert مستقل دارند.

در این حالت ممکن است:

Endpoint بگوید:

User uploaded file.

Cloud بگوید:

Sensitive file detected.

Email DLP بگوید:

External recipient detected.

اما هیچ سیستم مرکزی متوجه نشود که:

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

اینجاست که مفهوم Unified DLP اهمیت پیدا می‌کند.

Unified DLP؛ حرکت از ابزارهای جداگانه به یک معماری واحد

Unified DLP به رویکردی اشاره دارد که در آن Policy و دید امنیتی در نقاط مختلف حفاظت از داده تا حد امکان یکپارچه می‌شوند.

در چنین معماری‌ای، سازمان می‌تواند داده را در نقاط مختلف دنبال کند:

Endpoint → Network → Email → Cloud → SaaS

و Policyهای حفاظت از داده را به جای تعریف کاملاً جداگانه، در یک مدل هماهنگ‌تر مدیریت کند.

هدف Unified DLP صرفاً خرید یک محصول جدید نیست.

هدف اصلی این است:

Policy باید تا حد امکان همراه داده و Context آن حرکت کند.

برای مثال:

Confidential Data

اگر روی Endpoint باشد، یک Policy دارد.

اگر وارد Email شود، همان منطق حفاظتی باید ادامه پیدا کند.

اگر در Cloud ذخیره شود، همان حساسیت باید در Sharing نیز لحاظ شود.

و اگر کاربر بخواهد آن را وارد یک ابزار AI کند، سازمان باید بتواند همان ریسک را در یک Context جدید ارزیابی کند.

DLP و Shadow AI؛ مسیر جدید خروج داده

هوش مصنوعی یک مسیر جدید برای انتقال داده ایجاد کرده است.

کاربر ممکن است یک سند سازمانی را برای:

• خلاصه‌سازی
• ترجمه
• تحلیل
• تولید گزارش
• Debug کردن کد
• استخراج اطلاعات

در یک ابزار AI Upload یا Paste کند.

در چنین سناریویی، کنترل سنتی USB یا Email ممکن است هیچ نقشی نداشته باشد.

Netskope در گزارش ۲۰۲۵ خود اعلام کرده بود که ۹۰٪ سازمان‌های مورد بررسی از اپلیکیشن‌های GenAI استفاده می‌کردند و ۷۲٪ استفاده از GenAI را Shadow IT تشکیل می‌داد؛ همچنین مقدار داده ارسال‌شده به اپلیکیشن‌های GenAI طی یک سال بیش از ۳۰ برابر افزایش یافته بود.

در گزارش جدیدتر Netskope درباره Shadow AI و Agentic AI نیز مشخص شده بود که ۶۰٪ کاربران همچنان از اپلیکیشن‌های شخصی و مدیریت‌نشده AI استفاده می‌کردند.

بنابراین معماری DLP در سال‌های جدید باید مسیرهایی مانند:

Browser → SaaS AI → GenAI Platform → AI Agent

را نیز در مدل Data Protection خود در نظر بگیرد.

انتخاب معماری بر اساس وضعیت سازمان

هیچ نسخه واحدی برای تمام سازمان‌ها وجود ندارد.

سازمان عمدتاً On-Premise

تمرکز اولیه می‌تواند روی:

Network DLP + Endpoint DLP + Email DLP

باشد.

سازمان Hybrid

معماری مناسب‌تر:

Endpoint + Network + Email + Cloud DLP

به همراه Data Discovery و Classification است.

سازمان Cloud-First

تمرکز بیشتر روی:

Cloud DLP + SaaS Security + DSPM + Identity

خواهد بود.

سازمان با Remote Work گسترده

Endpoint DLP اهمیت بیشتری پیدا می‌کند؛ زیرا بسیاری از فعالیت‌های کاربران خارج از Perimeter سنتی انجام می‌شوند.

سازمان با استفاده گسترده از AI

علاوه بر DLP سنتی، باید:

Web/SaaS Controls + Cloud DLP + Identity + Endpoint + AI Usage Visibility

در معماری دیده شوند.

یک مدل ساده برای انتخاب DLP

می‌توان فرآیند انتخاب را با پنج سؤال شروع کرد:

سؤال اول

داده حساس کجاست؟

On-Premise؟ Endpoint؟ Cloud؟ SaaS؟

سؤال دوم

داده چگونه جابه‌جا می‌شود؟

Email؟ Web؟ USB؟ Cloud؟ Messaging؟ AI؟

سؤال سوم

کاربر از کجا به داده دسترسی دارد؟

شبکه سازمان؟ خانه؟ موبایل؟ Laptop؟

سؤال چهارم

مهم‌ترین مقصدهای خروج داده کدام‌اند؟

Personal Cloud؟ Gmail؟ SaaS؟ AI؟

سؤال پنجم

آیا Policyها در تمام این نقاط یکپارچه‌اند؟

اگر پاسخ خیر باشد، احتمال وجود Blind Spot در معماری افزایش پیدا می‌کند.

Network DLP، Endpoint DLP یا Cloud DLP؟

پاسخ را می‌توان در یک جمله خلاصه کرد:

Network DLP برای کنترل مسیرهای شبکه، Endpoint DLP برای کنترل فعالیت داده روی دستگاه و Cloud DLP برای حفاظت از داده در سرویس‌ها و محیط‌های Cloud مناسب است.

اما در سازمان‌های مدرن، این سه مدل معمولاً رقیب یکدیگر نیستند.

آن‌ها لایه‌های مکمل حفاظت از داده هستند.

به همین دلیل، سؤال اصلی هنگام طراحی معماری نباید این باشد که:

«کدام DLP را بخریم؟»

بلکه باید پرسید:

«داده ما از چه مسیرهایی عبور می‌کند و در هر مسیر چه کنترلی لازم دارد؟»

تحلیل بهراد یوسفی؛ DLP را بر اساس محصول انتخاب نکنید

اشتباه رایج در پروژه‌های DLP این است که سازمان ابتدا محصول را انتخاب می‌کند و بعد تلاش می‌کند معماری خود را با آن تطبیق دهد.

ترتیب درست باید برعکس باشد.

ابتدا باید مسیر داده مشخص شود:

Data → User → Device → Channel → Destination

بعد باید مشخص شود در هر نقطه چه ریسکی وجود دارد.

ممکن است یک سازمان به Endpoint DLP نیاز بسیار بیشتری نسبت به Network DLP داشته باشد؛ در حالی که برای سازمان دیگر، کنترل Gateway و Email مهم‌تر باشد.

در یک سازمان Cloud-First نیز ممکن است بخش بزرگی از سرمایه‌گذاری باید روی Cloud DLP، DSPM، Identity و کنترل SaaS انجام شود.

بنابراین «بهترین DLP» یک محصول مشخص نیست.

بهترین DLP، معماری‌ای است که با مسیر واقعی داده، مدل کاری کاربران و سطح ریسک سازمان تطبیق داشته باشد.

نکته مهم دیگر، یکپارچگی Policyهاست.

اگر سازمان برای Endpoint یک Policy، برای Email یک Policy و برای Cloud یک Policy کاملاً جدا داشته باشد، ممکن است در نقطه اتصال این سه محیط، داده از کنترل خارج شود.

به همین دلیل، حرکت بازار از DLPهای جزیره‌ای به سمت Unified Data Security یک تغییر صرفاً محصولی نیست؛ پاسخی به تغییر معماری IT سازمان‌هاست.

امروز داده ممکن است در یک Data Center شروع شود، روی Endpoint کاربر قرار بگیرد، از طریق Browser به یک SaaS منتقل شود و در نهایت وارد یک ابزار AI شود.

معماری DLP نیز باید بتواند همین مسیر را دنبال کند.

جمع‌بندی 

Network DLP، Endpoint DLP و Cloud DLP سه رویکرد متفاوت برای حفاظت از داده هستند.

Network DLP روی مسیرهای شبکه و Data in Motion تمرکز دارد.

Endpoint DLP امکان کنترل فعالیت‌های مرتبط با داده روی دستگاه کاربر را فراهم می‌کند.

Cloud DLP حفاظت از داده در محیط‌های Cloud و SaaS را هدف قرار می‌دهد.

هیچ‌کدام به‌تنهایی تمام مسیرهای نشت داده را پوشش نمی‌دهند.

در محیط‌های سنتی ممکن است Network DLP بخش مهمی از معماری باشد؛ اما با گسترش Remote Work، SaaS، Cloud و AI، Endpoint و Cloud نیز به لایه‌های مهم حفاظت از داده تبدیل شده‌اند.

از طرف دیگر، آمار Fortinet نشان می‌دهد استفاده سازمان‌ها از این کنترل‌ها همچنان پراکنده است و حتی Data Discovery، Classification و DSPM نسبت به کنترل‌های اجرایی سهم پایین‌تری دارند.

بنابراین آینده DLP فقط در افزایش تعداد Policyها یا Block کردن کانال‌های بیشتر نیست.

مسئله اصلی، ایجاد یک معماری است که بتواند:

داده + کاربر + دستگاه + کانال + مقصد + Context + Risk

را در کنار یکدیگر ببیند.

در نهایت:

Network DLP می‌بیند داده از کدام مسیر شبکه عبور می‌کند.

Endpoint DLP می‌بیند کاربر روی دستگاه چه کاری با داده انجام می‌دهد.

Cloud DLP می‌بیند داده در محیط Cloud چگونه ذخیره، اشتراک‌گذاری و منتقل می‌شود.

و معماری مدرن DLP زمانی شکل می‌گیرد که این دیدگاه‌ها به جای جزیره‌ای بودن، در یک مدل یکپارچه Data Security کنار هم قرار بگیرند.

منابع اصلی 

• Fortinet — 2025 Data Security Report 
• Varonis — 2025 State of Data Security Report — منبع آمار مربوط به داده حساس Cloud و ریسک AI.
• Netskope — 2025 Cloud and Threat Report — منبع آمار Personal Cloud Apps و انتقال داده به سرویس‌های شخصی.
• Netskope — 2025 Generative AI Cloud and Threat Report — منبع آمار GenAI و Shadow AI.
• Netskope — Shadow AI and Agentic AI 2025 — منبع آمار جدیدتر درباره Shadow AI، اپلیکیشن‌های AI و Agentic AI.