در قسمت‌های قبل دیدیم که Data Classification مشخص می‌کند چه داده‌ای حساس است و Data Lifecycle نشان می‌دهد این داده در چه مراحلی ایجاد، ذخیره، استفاده، اشتراک‌گذاری و منتقل می‌شود.

اما یک سؤال مهم باقی می‌ماند:

DLP در عمل چگونه از خروج اطلاعات جلوگیری می‌کند؟

پاسخ این سؤال در معماری DLP قرار دارد.

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

در معماری‌های مدرن، DLP معمولاً با قابلیت‌هایی مانند Data Discovery، Data Classification، Identity، UEBA، CASB، Cloud Security، SIEM و DSPM نیز یکپارچه می‌شود.

به‌صورت ساده، می‌توان منطق کلی معماری DLP را این‌گونه خلاصه کرد:

Data Discovery → Data Classification → Policy Engine → Monitoring → Enforcement → Audit & Response

DLP از چه داده‌ای محافظت می‌کند؟

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

به همین دلیل، معماری DLP باید بتواند داده را در سه وضعیت اصلی و در کانال‌های مختلف کنترل کند.

۱. Data at Rest؛ داده‌های ذخیره‌شده

Data at Rest به اطلاعاتی گفته می‌شود که در یک محل ذخیره شده‌اند و در حال انتقال نیستند.

نمونه‌ها:

• فایل‌های سرور سازمانی

• پایگاه‌های داده

• فایل‌های موجود روی لپ‌تاپ

• فضای ذخیره‌سازی Cloud

• فایل‌سرورها

• مخازن اسناد

در این وضعیت، DLP بیشتر روی Data Discovery، Classification و Access Control تمرکز می‌کند.

سؤال‌های اصلی عبارت‌اند از:

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

• چه مقدار داده حساس وجود دارد؟

• چه کسی به آن دسترسی دارد؟

• آیا داده‌های قدیمی همچنان قابل دسترسی هستند؟

• آیا نسخه‌های اضافی یا بدون مالک وجود دارند؟

• آیا داده در محیط Cloud نیز ذخیره شده است؟

۲. Data in Motion؛ داده‌های در حال انتقال

Data in Motion به داده‌ای گفته می‌شود که از یک نقطه به نقطه دیگر منتقل می‌شود.

نمونه‌ها:

• ایمیل

• Attachment

• ترافیک وب

• آپلود فایل

• انتقال به Cloud

• پیام‌رسان‌های سازمانی

• انتقال اطلاعات به سرویس‌های خارجی

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

برای مثال، اگر کاربر فایلی حاوی اطلاعات مشتریان را به یک آدرس Gmail شخصی ارسال کند، سیستم می‌تواند محتوا، فرستنده، گیرنده، سطح Classification، مقصد و کانال انتقال را بررسی کرده و بر اساس Policy تصمیم بگیرد.

۳. Data in Use؛ داده‌های در حال استفاده

Data in Use زمانی است که کاربر یا یک برنامه مستقیماً با داده تعامل دارد.

نمونه‌ها:

• باز کردن فایل

• Copy/Paste

• چاپ

• Screenshot

• کپی روی USB

• انتقال فایل بین برنامه‌ها

• استفاده از داده در یک نرم‌افزار یا مرورگر

این بخش یکی از مهم‌ترین نقاط کنترل در Endpoint DLP است؛ زیرا کاربر ممکن است از قبل مجوز دسترسی به یک فایل را داشته باشد، اما نحوه استفاده از آن داده همچنان می‌تواند ریسک ایجاد کند.

DLP در کجا از داده محافظت می‌کند؟

یک معماری DLP مدرن باید بتواند چندین مسیر خروج داده را پوشش دهد.

کاربر ممکن است یک فایل حساس را:

• روی لپ‌تاپ ذخیره کند؛

• از طریق ایمیل ارسال کند؛

• در Microsoft Teams یا Slack به اشتراک بگذارد؛

• روی Google Drive یا OneDrive آپلود کند؛

• روی USB کپی کند؛

• از طریق مرورگر به یک سرویس Cloud منتقل کند؛

• یا محتوای آن را در یک ابزار هوش مصنوعی وارد کند.

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

این همان تفاوت اساسی میان DLP سنتی و معماری مدرن حفاظت از داده است:

DLP سنتی می‌پرسد: داده از کدام کانال خارج می‌شود؟

DLP مدرن می‌پرسد: چه داده‌ای، توسط چه کسی، از کجا، به کجا و تحت چه شرایطی منتقل می‌شود؟

این مسئله در گزارش 2025 Data Security Report شرکت Fortinet نیز به‌وضوح دیده می‌شود.

بر اساس این گزارش، میزان استفاده سازمان‌های مورد بررسی از فناوری‌های مختلف حفاظت از داده به شکل زیر بوده است:

 

 

منبع: Fortinet / Cybersecurity Insiders، 2025 Data Security Report.

گزارش رسمی 2025 Data Security Report

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

Endpoint DLP یکی از مهم‌ترین اجزای معماری DLP است.

این قابلیت روی دستگاه‌هایی مانند Laptop، Desktop، Workstation و Terminal اجرا می‌شود و فعالیت‌هایی را که می‌توانند منجر به خروج داده شوند، بررسی می‌کند.

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

USB

کاربر تلاش می‌کند یک فایل Confidential را روی حافظه USB کپی کند.

Print

کاربر قصد چاپ یک سند حساس را دارد.

Copy/Paste

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

Screen Capture

کاربر از یک اطلاعات حساس Screenshot تهیه می‌کند.

Local File Transfer

کاربر فایل حساس را به یک مسیر محلی یا دستگاه دیگری منتقل می‌کند.

بر اساس Policy سازمان، Endpoint DLP می‌تواند:

• فعالیت را اجازه دهد؛

• فعالیت را ثبت کند؛

• به کاربر هشدار دهد؛

• از کاربر درخواست Justification کند؛

• یا عملیات را مسدود کند.

گزارش 2025 Data Security Report شرکت Fortinet نشان می‌دهد ۴۸ درصد سازمان‌های مورد بررسی از Endpoint DLP استفاده می‌کردند؛ این رقم بالاترین میزان استفاده در میان دسته‌های DLP بررسی‌شده در این گزارش بوده است.

Email DLP؛ کنترل یکی از مسیرهای مهم خروج داده

ایمیل همچنان یکی از کانال‌های مهم انتقال اطلاعات سازمانی است و به همین دلیل Email DLP جایگاه مهمی در معماری حفاظت از داده دارد.

Email DLP می‌تواند محتوای ایمیل و Attachmentها را بررسی کرده و بر اساس Policy سازمان درباره نحوه برخورد با آن تصمیم بگیرد.

فرآیند ساده را می‌توان این‌گونه نمایش داد:

User → Email + Attachment → Content Inspection → Classification → Policy Engine → Allow / Warn / Block

برای مثال، فرض کنید کاربری تلاش می‌کند فایل حاوی اطلاعات مشتریان را به حساب Gmail شخصی خود ارسال کند.

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

• نوع داده

• سطح Classification

• فرستنده

• گیرنده

• Attachment

• مقصد

• کانال انتقال

• شرایط انجام فعالیت

سپس Policy Engine بر اساس این اطلاعات تصمیم می‌گیرد که عملیات مجاز باشد، هشدار داده شود یا مسدود شود.

Network DLP؛ کنترل داده در حال حرکت

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

این بخش مستقیماً با مفهوم Data in Motion ارتباط دارد.

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

اما این معماری با یک چالش مهم مواجه است:

رمزگذاری.

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

• TLS Inspection

• Proxy

• Secure Web Gateway

• Integration با سایر کنترل‌های امنیتی

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

بنابراین Network DLP بدون معماری مناسب برای مشاهده و کنترل ترافیک رمزگذاری‌شده، نمی‌تواند تمام مسیرهای خروج داده را پوشش دهد.

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

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

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

• Microsoft 365

• Google Workspace

• AWS

• Azure

• Salesforce

• Box

• Slack

• Snowflake

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

بنابراین این فرض قدیمی که:

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

دیگر قابل اتکا نیست.

گزارش 2025 State of Data Security شرکت Varonis که داده‌های ۱۰۰۰ سازمان را بررسی کرده، نشان می‌دهد ۹۰ درصد سازمان‌های مورد بررسی دارای داده حساس Cloud در معرض دسترسی بوده‌اند.

این مطالعه نزدیک به ۱۰ میلیارد منبع Cloud و بیش از ۲۰ پتابایت داده را بررسی کرده است.

نکته مهم این است که این رقم به معنای وقوع Breach در ۹۰ درصد سازمان‌ها نیست؛ بلکه به Exposure و ریسک دسترسی به داده اشاره دارد.

این موضوع نشان می‌دهد حفاظت از داده در Cloud باید بخشی از معماری DLP و Data Security باشد، نه یک قابلیت جانبی.

DLP و Shadow AI؛ مرز جدید نشت داده

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

یک کارمند ممکن است برای خلاصه‌سازی، تحلیل یا ویرایش یک سند، فایل سازمانی را در یک ابزار AI عمومی Upload کند.

از دید کاربر، این کار ممکن است بخشی از فعالیت روزمره باشد.

اما از دید امنیت داده، اتفاق مهم‌تری رخ داده است:

داده سازمان از یک محیط کنترل‌شده خارج شده است.

گزارش Varonis در سال ۲۰۲۵ نشان داد ۹۸ درصد سازمان‌های بررسی‌شده دارای Appهای تأییدنشده، از جمله Shadow AI، بوده‌اند.

همچنین این گزارش اعلام کرد ۹۹ درصد سازمان‌های بررسی‌شده داده حساس خود را در شرایطی داشتند که می‌توانست توسط ابزارهای AI نمایان شود.

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

SaaS، Cloud و ابزارهای AI نیز باید در مدل Data Protection سازمان دیده شوند.

Data Discovery؛ قبل از کنترل باید داده را پیدا کرد

یکی از مهم‌ترین اجزای معماری DLP، Data Discovery است.

سازمان نمی‌تواند برای داده‌ای که محل آن را نمی‌داند، Policy دقیق ایجاد کند.

Data Discovery به پرسش‌هایی مانند این پاسخ می‌دهد:

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

• چه مقدار داده حساس وجود دارد؟

• چه کسی به آن دسترسی دارد؟

• چند نسخه از داده وجود دارد؟

• آیا داده در Cloud قرار دارد؟

• آیا داده روی Endpointها وجود دارد؟

• آیا داده‌های قدیمی همچنان قابل دسترسی هستند؟

• آیا فایل‌های حساس بدون مالک یا بدون استفاده وجود دارند؟

این موضوع اهمیت زیادی دارد؛ زیرا ممکن است سازمان ابزار DLP قدرتمندی داشته باشد اما نداند دقیقاً چه داده‌ای باید تحت حفاظت قرار گیرد.

به بیان ساده:

اول ببین چه چیزی داری؛ بعد تصمیم بگیر چگونه باید از آن محافظت کنی.

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

یک سیستم DLP سازمانی از چند جزء اصلی تشکیل می‌شود.

Data Detection Engine

وظیفه این موتور تشخیص این است که آیا یک فایل، پیام یا داده حاوی اطلاعات حساس است یا خیر.

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

• Regex

• Keyword Matching

• Content Inspection

• Data Fingerprinting

• Classification

• Machine Learning

استفاده شود.

برای مثال، موتور تشخیص می‌تواند یک فایل Excel حاوی تعداد زیادی شماره کارت یا اطلاعات مشتریان را شناسایی کند.

Policy Engine

Policy Engine مغز تصمیم‌گیری DLP است.

این بخش اطلاعات مختلف را کنار هم قرار می‌دهد:

نوع داده + سطح حساسیت + کاربر + مقصد + کانال + شرایط

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

برای مثال:

Sensitive Data + Employee + Personal Gmail + Email + Confidential → BLOCK

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

Sensitive Data + Authorized User + Approved Partner + Encrypted Channel → ALLOW

این همان تفاوت بین DLP مبتنی بر Rule ساده و DLP مبتنی بر Context است.

Endpoint Agent

Endpoint Agent نرم‌افزاری است که روی دستگاه کاربر اجرا می‌شود و امکان کنترل فعالیت‌های مربوط به Data in Use را فراهم می‌کند.

این Agent می‌تواند فعالیت‌هایی مانند USB، Print، Copy/Paste، Screenshot و انتقال فایل را تحت نظارت قرار دهد.

بدون کنترل Endpoint، سازمان بخشی از دید خود نسبت به نحوه استفاده کاربران از داده را از دست می‌دهد.

Management Console

Management Console محل مدیریت مرکزی Policyها، مشاهده هشدارها، تحلیل رخدادها و گزارش‌گیری است.

از طریق این بخش می‌توان مواردی مانند:

• کاربران پرریسک

• Policyهای فعال

• تلاش‌های مسدودشده

• رخدادهای DLP

• روندهای نشت داده

• هشدارهای مهم

را بررسی کرد.

فرآیند تصمیم‌گیری DLP؛ از مشاهده تا واکنش

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

مرحله اول: Observe

سیستم فعالیت را مشاهده می‌کند:

• چه فایلی در حال استفاده است؟

• چه کسی به آن دسترسی دارد؟

• مقصد کجاست؟

• چه عملیاتی در حال انجام است؟

• کانال انتقال چیست؟

مرحله دوم: Identify

موتور تشخیص بررسی می‌کند:

• آیا داده حساس است؟

• چه نوع داده‌ای است؟

• سطح حساسیت آن چیست؟

• آیا داده با یک Classification مشخص مطابقت دارد؟

مرحله سوم: Evaluate

Policy Engine شرایط را ارزیابی می‌کند:

• آیا کاربر مجاز است؟

• مقصد مجاز است؟

• کانال مجاز است؟

• فعالیت با Policy سازمان مطابقت دارد؟

• آیا Context فعالیت پرریسک است؟

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

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

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

Allow

فعالیت مجاز است و عملیات بدون محدودیت انجام می‌شود.

Monitor

فعالیت ثبت و پایش می‌شود، اما الزاماً متوقف نمی‌شود.

Warn

به کاربر هشدار داده می‌شود.

Justification

کاربر باید دلیل انجام فعالیت را ثبت کند.

Quarantine

داده موقتاً از دسترس خارج می‌شود تا بررسی بیشتری انجام شود.

Encrypt

داده پیش از انتقال یا اشتراک‌گذاری رمزگذاری می‌شود.

Block

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

بنابراین DLP فقط یک سیستم Block نیست.

یک معماری بالغ باید بتواند متناسب با سطح ریسک، واکنش‌های مختلفی اعمال کند.

برای مثال:

Public → Allow

Internal → Monitor

Confidential → Warn / Justification

Restricted → Block

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

معماری کامل DLP

اگر تمام اجزای بالا را کنار هم قرار دهیم، معماری منطقی DLP را می‌توان این‌گونه نمایش داد:

 

                     DATA SOURCES
                          │
        ┌─────────────────┼─────────────────┐
        │                 │                 │
    Endpoint            Cloud            Network
        │                 │                 │
        └─────────────────┼─────────────────┘
                          ↓
                   DATA DISCOVERY
                          ↓
                  DATA CLASSIFICATION
                          ↓
                     POLICY ENGINE
                          ↓
                 CONTEXT / IDENTITY
                          ↓
                     RISK ANALYSIS
                          ↓
             ┌────────────┼────────────┐
             ↓            ↓            ↓
           ALLOW         WARN        BLOCK
             │            │            │
             └────────────┼────────────┘
                          ↓
                      MONITORING
                          ↓
                    AUDIT / SIEM
                          ↓
                       RESPONSE

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

یک شکاف مهم در معماری DLP

آمار Fortinet یک نکته مهم دیگر را نیز نشان می‌دهد.

در مطالعه این شرکت، استفاده از Endpoint DLP به ۴۸ درصد و Email DLP به ۴۶ درصد رسیده بود، در حالی که Data Discovery / Classification / DSPM تنها ۲۸ درصد بود.

این اختلاف یک مسئله مهم معماری ایجاد می‌کند:

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

به همین دلیل، DLP در معماری‌های مدرن نباید جدا از فناوری‌هایی مانند:

DSPM + Data Classification + Identity + UEBA + CASB + SIEM

طراحی شود.

DLP باید بخشی از یک معماری جامع Data Security باشد.

DLP سنتی در برابر DLP مدرن

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

DLP سنتی روی کانال تمرکز می‌کند؛ DLP مدرن روی داده، هویت، Context و Risk.

نقش هوش مصنوعی در تکامل DLP

هوش مصنوعی و Machine Learning می‌توانند DLP را از یک سیستم کاملاً Rule-Based به یک سیستم تحلیل‌محورتر تبدیل کنند.

برای مثال، یک سیستم سنتی ممکن است فقط مشاهده کند:

«کاربر ۵۰ فایل را کپی کرد.»

اما یک سیستم پیشرفته‌تر می‌تواند سؤالات بیشتری را بررسی کند:

• آیا این کاربر قبلاً چنین رفتاری داشته است؟

• آیا فایل‌ها حساس هستند؟

• آیا فعالیت خارج از ساعات معمول کاری انجام شده است؟

• مقصد انتقال چیست؟

• آیا دستگاه مورد استفاده شناخته‌شده است؟

• آیا حجم انتقال با الگوی رفتاری قبلی کاربر تفاوت دارد؟

در نتیجه، DLP می‌تواند به جای واکنش یکسان به تمام فعالیت‌ها، Risk و Context را نیز در تصمیم‌گیری وارد کند.

مثلاً ارسال روزانه یک گزارش مالی توسط مدیر مالی به یک شریک تجاری تأییدشده، لزوماً نباید همان واکنشی را دریافت کند که ارسال همان داده‌ها در نیمه‌شب به یک فضای Cloud شخصی توسط کاربری است که قبلاً چنین رفتاری نداشته است.

DLP فقط یک ابزار نیست

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

DLP در واقع یک قابلیت سازمانی (Organizational Capability) است.

برای اجرای موفق آن باید مشخص شود:

1. داده‌های حساس سازمان کجا قرار دارند؟

2. مهم‌ترین مسیرهای خروج داده کدام‌اند؟

3. چه Endpointهایی باید تحت کنترل باشند؟

4. چه سرویس‌های Cloud و SaaS باید پایش شوند؟

5. چه Policyهایی باید اولویت داشته باشند؟

6. چه تیمی مسئول بررسی هشدارهاست؟

7. چه کسی Policyها را مدیریت می‌کند؟

8. در صورت Block شدن فعالیت کاربر، فرآیند رسیدگی چیست؟

9. چگونه False Positiveها مدیریت می‌شوند؟

10. داده‌های DLP چگونه با SIEM و سایر سیستم‌های امنیتی یکپارچه می‌شوند؟

بدون پاسخ به این پرسش‌ها، خرید یک محصول DLP الزاماً به معنای ایجاد یک معماری مؤثر حفاظت از داده نیست.

تحلیل بهراد یوسفی؛ چرا سازمان‌ها ابزار DLP می‌خرند اما معماری نمی‌سازند؟

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

سازمان ممکن است Endpoint DLP را نصب کند، Email DLP را فعال کند و چند Policy پیش‌فرض نیز ایجاد کند، اما اگر نداند چه داده‌ای واقعاً حساس است، چه کسانی به آن دسترسی دارند و مهم‌ترین مسیرهای خروج کدام‌اند، نتیجه می‌تواند مجموعه‌ای از هشدارهای بی‌ارزش و False Positiveهای متعدد باشد.

مشکل دیگر، ابزارمحوری بدون فرآیند است.

فرض کنید Network DLP در Gateway سازمان نصب شده، اما هیچ تیمی مسئول بررسی هشدارهای آن نیست. یا Endpoint Agent روی سیستم کاربران نصب شده، اما Helpdesk نمی‌داند هنگام Block شدن یک فعالیت چه فرآیندی را باید اجرا کند.

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

از طرف دیگر، معماری DLP باید با زیرساخت واقعی سازمان هماهنگ باشد. سازمان‌های زیادی دارای ترکیبی از زیرساخت‌های Legacy، سرویس‌های On-Premise، Cloud، SaaS و Endpointهای مختلف هستند. بنابراین نمی‌توان بدون شناخت این محیط، یک معماری یکسان را برای همه سازمان‌ها اجرا کرد.

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

این معماری باید حداقل به پنج سؤال پاسخ دهد:

1. داده‌های حساس سازمان کجا قرار دارند؟

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

3. چه کسانی با آن‌ها کار می‌کنند؟

4. مهم‌ترین نقاط خروج داده کدام‌اند؟

5. چه ترکیبی از Endpoint، Network، Email، Cloud DLP و DSPM مورد نیاز است؟

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

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

جمع‌بندی قسمت سوم

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

Endpoint DLP از داده روی دستگاه کاربر محافظت می‌کند.

Email DLP انتقال داده از طریق ایمیل را کنترل می‌کند.

Network DLP روی داده در حال حرکت تمرکز دارد.

Cloud DLP و CASB به حفاظت از داده در محیط‌های Cloud و SaaS کمک می‌کنند.

Data Discovery و Data Classification مشخص می‌کنند سازمان دقیقاً چه داده‌ای دارد و کدام داده ارزش حفاظتی بیشتری دارد.

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

در معماری مدرن، DLP دیگر فقط درباره جلوگیری از ارسال یک فایل از طریق ایمیل یا کپی آن روی USB نیست.

داده امروز می‌تواند از Endpoint به Cloud، از Cloud به SaaS و از SaaS به یک ابزار AI منتقل شود.

بنابراین سؤال اصلی دیگر این نیست که:

«داده از کدام کانال خارج شد؟»

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

«چه داده‌ای، توسط چه کسی، در چه شرایطی، از کجا به کجا در حال حرکت است؟»

این تغییر دیدگاه، DLP را از یک ابزار ساده برای جلوگیری از نشت فایل به یکی از اجزای مهم معماری جامع Data Security تبدیل می‌کند.

 

منابع:

Fortinet – 2025 Data Security Report

Varonis – 2025 State of Data Security Report