DLP Policy چیست و چگونه از نشت اطلاعات جلوگیری می‌کند؟ در این قسمت از مجموعه جامع DLP، با ساختار Policy، Condition، Rule، Action، Exception، Context، اولویت‌بندی قوانین، حالت Audit و Block و روش طراحی یک سیاست مؤثر برای جلوگیری از نشت اطلاعات آشنا می‌شویم.

DLP Policy چیست؟

در قسمت‌های قبلی دیدیم که DLP وظیفه دارد داده‌های حساس را شناسایی، پایش و در برابر استفاده یا انتقال غیرمجاز کنترل کند.

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

DLP از کجا می‌فهمد چه چیزی باید مجاز باشد و چه چیزی باید متوقف شود؟

پاسخ، DLP Policy است.

DLP Policy مجموعه‌ای از قواعد و شرایط امنیتی است که مشخص می‌کند:

• چه داده‌ای حساس محسوب می‌شود؟
• چه کاربری مجاز به استفاده از آن است؟
• داده از چه مسیری می‌تواند منتقل شود؟
• مقصد مجاز یا غیرمجاز کجاست؟
• چه شرایطی باعث ایجاد هشدار می‌شود؟
• چه فعالیتی باید ثبت شود؟
• چه زمانی کاربر باید دلیل فعالیت خود را اعلام کند؟
• چه زمانی عملیات باید به‌طور کامل مسدود شود؟

به بیان ساده:

Classification مشخص می‌کند «چه چیزی حساس است» و DLP Policy مشخص می‌کند «با آن چه رفتاری باید انجام شود».

DLP Policy چگونه تصمیم می‌گیرد؟

یک Policy معمولاً از چند جزء اصلی تشکیل می‌شود:

Condition → Context → Action → Exception → Alert & Response

یعنی ابتدا DLP بررسی می‌کند آیا یک فعالیت شرایط مشخص‌شده را دارد یا خیر؛ سپس Context فعالیت را در نظر می‌گیرد و در صورت تطابق، Action مربوط به آن Rule را اجرا می‌کند.

برای مثال:

داده مشتریان + کاربر داخلی + مقصد خارجی + حساب شخصی → Block

اما اگر همان داده به یک سامانه مورد تأیید سازمان ارسال شود:

داده مشتریان + کاربر مجاز + مقصد سازمانی تأییدشده → Allow / Monitor

بنابراین DLP Policy صرفاً براساس «محتوای فایل» تصمیم نمی‌گیرد.

Context اهمیت بسیار زیادی دارد.

اجزای اصلی DLP Policy

۱. Condition؛ شرط

Condition مشخص می‌کند Policy دقیقاً به دنبال چه وضعیتی است.

مثلاً:

• وجود اطلاعات PII
• وجود شماره کارت
• وجود کد منبع
• وجود اطلاعات مالی
• وجود فایل با Classification = Confidential
• ارسال به مقصد خارجی
• Copy روی USB
• Upload به Cloud
• ارسال Email به دامنه خارج از سازمان

در راهکارهای DLP مدرن، Conditionها می‌توانند براساس محتوای داده و همچنین ویژگی‌های فعالیت تعریف شوند.

۲. Data Condition؛ چه داده‌ای؟

اولین سؤال Policy باید این باشد:

چه داده‌ای باید محافظت شود؟

برای مثال:

این بخش باید مستقیماً با Data Classification ارتباط داشته باشد.

اگر سازمان نداند چه داده‌ای حساس است، Policy احتمالاً یا بیش از حد سخت‌گیر خواهد شد یا داده‌های مهم را از دست خواهد داد.

۳. Context؛ داده در چه شرایطی استفاده می‌شود؟

این قسمت یکی از تفاوت‌های مهم DLP مدرن با قوانین ساده مبتنی بر Regex است.

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

آیا باید آن را همیشه Block کند؟

خیر.

ممکن است:

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

در مقابل:

• کاربر از واحد نامرتبط باشد.
• مقصد خارجی باشد.
• کانال شخصی باشد.
• انتقال روی USB شخصی انجام شود.

در این حالت ریسک بسیار بالاتر است.

بنابراین Policy باید بتواند Context را نیز در نظر بگیرد.

مهم‌ترین Contextها

• هویت کاربر
• گروه کاربری
• واحد سازمانی
• دستگاه
• محل فعالیت
• مقصد
• کانال انتقال
• زمان
• نوع برنامه
• نوع شبکه
• سطح Classification
• نوع داده
• رفتار قبلی کاربر

۴. Action؛ وقتی Policy Match شد چه اتفاقی بیفتد؟

پس از تطبیق Conditionها، DLP باید تصمیم بگیرد چه کاری انجام دهد.

مهم‌ترین Actionها عبارت‌اند از:

Allow

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

Audit / Monitor

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

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

Warn

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

Justification

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

برای مثال:

«لطفاً دلیل ارسال این فایل به مقصد خارجی را وارد کنید.»

Encrypt

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

Quarantine

داده یا فعالیت برای بررسی بیشتر در وضعیت قرنطینه قرار می‌گیرد.

Block

عملیات به‌طور کامل متوقف می‌شود.

بنابراین:

DLP بالغ فقط Block نمی‌کند؛ متناسب با سطح ریسک، واکنش مناسب انتخاب می‌کند.

۵. Exception؛ چه زمانی Policy نباید اجرا شود؟

یکی از مهم‌ترین بخش‌های طراحی DLP Policy، Exception است.

فرض کنید سازمان یک Policy دارد:

هر فایل حاوی اطلاعات مشتری که به خارج از سازمان ارسال شود → Block

اما واحد حقوقی سازمان باید گاهی همین اطلاعات را برای یک شریک تجاری تأییدشده ارسال کند.

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

بنابراین می‌توان تعریف کرد:

Customer Data + External Destination → Block

اما:

Customer Data + Approved Partner → Allow / Monitor

Exceptionها باید بسیار دقیق طراحی شوند.

استفاده بیش از حد از Exception می‌تواند Policy را بی‌اثر کند.

۶. Rule چیست و چه تفاوتی با Policy دارد؟

این دو اصطلاح گاهی به جای یکدیگر استفاده می‌شوند اما از نظر طراحی بهتر است آن‌ها را جدا کنیم.

Policy

چارچوب کلی حفاظت از یک نوع داده یا یک هدف امنیتی است.

Rule

منطق اجرایی داخل Policy است.

برای مثال:

Policy: حفاظت از اطلاعات مشتریان

می‌تواند شامل Ruleهای زیر باشد:

Rule 1

Customer Data + External Email → Warn

Rule 2

Customer Data + Personal Email → Block

Rule 3

Customer Data + Approved Partner → Monitor

Rule 4

Customer Data + USB → Block

یک Policy می‌تواند شامل چندین Rule مختلف باشد و هر Rule شرایط و واکنش مشخص خود را داشته باشد.

۷. چرا Priority در DLP Policy مهم است؟

فرض کنید یک فایل دارای اطلاعات بسیار حساس است و هم‌زمان با دو Rule مطابقت دارد:

Rule A

Confidential → Warn

Rule B

Restricted + External Destination → Block

اگر اولویت‌بندی صحیح نباشد، ممکن است Rule عمومی‌تر زودتر اجرا شود و نتیجه مورد انتظار سازمان حاصل نشود.

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

یک منطق ساده:

Restricted → Block

Confidential → Warn / Justification

Internal → Monitor

Public → Allow

این مدل صرفاً نمونه است و Policy واقعی باید براساس Risk Appetite، معماری سازمان و نیازهای کسب‌وکار طراحی شود.

۸. DLP Policy نباید فقط براساس نوع فایل باشد

یکی از اشتباهات رایج این است که Policy به شکل زیر طراحی شود:

اگر فایل Excel بود → Block

این منطق بسیار ضعیف است.

زیرا یک فایل Excel می‌تواند شامل:

• داده عمومی
• اطلاعات مالی
• اطلاعات مشتری
• گزارش داخلی
• داده حساس

باشد.

بنابراین:

File Type ≠ Data Sensitivity

Policy بهتر است براساس ترکیبی از موارد زیر تصمیم بگیرد:

Content + Classification + User + Destination + Channel + Context

برای مثال:

Excel + Customer Data + External Destination + Personal Account → Block

در حالی که:

Excel + Customer Data + Internal Approved System → Allow

این تفاوت، Policy را از یک Rule ساده به یک کنترل امنیتی واقعی تبدیل می‌کند.

---

۹. نمونه Policy برای اطلاعات مشتریان

فرض کنیم سازمان اطلاعات مشتریان را در سطح Confidential طبقه‌بندی کرده است.

Policy

هدف: جلوگیری از خروج اطلاعات مشتریان

Rule 1 — مقصد خارجی

Condition:

Customer Data + External Recipient

Action:

Warn + Justification

Rule 2 — حساب شخصی

Condition:

Customer Data + Personal Email

Action:

Block

Rule 3 — USB شخصی

Condition:

Customer Data + Removable Media

Action:

Block

Rule 4 — سامانه مورد تأیید

Condition:

Customer Data + Approved Business Application

Action:

Allow + Audit

Rule 5 — حجم غیرعادی

Condition:

Large Volume of Customer Data + External Destination

Action:

Block + Alert

این مدل نشان می‌دهد DLP Policy صرفاً براساس «حساس بودن داده» تصمیم نمی‌گیرد؛ بلکه نوع رفتار و شرایط انتقال نیز اهمیت دارد.

۱۰. Policy برای Source Code

مالکیت فکری و Source Code نیز یکی از مهم‌ترین دارایی‌های سازمانی است.

برای مثال:

Source Code + Personal Cloud → Block

یا:

Source Code + USB → Block

اما:

Source Code + Approved Repository → Allow + Audit

در اینجا استفاده از Fingerprinting یا Content Inspection می‌تواند به شناسایی بهتر کدهای اختصاصی سازمان کمک کند.

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

۱۱. Policy برای Credentials و Secrets

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

مانند:

• API Key
• Access Token
• Private Key
• Password
• Secret
• Certificate

یک Policy نمونه:

Credential / Secret + External Destination → Block + High Severity Alert

در چنین سناریویی حتی Warn ممکن است کافی نباشد؛ زیرا افشای یک Secret می‌تواند به compromise مستقیم یک سامانه منجر شود.

۱۲. Audit Mode؛ چرا نباید از روز اول همه‌چیز را Block کنیم؟

یکی از خطرناک‌ترین اشتباهات در پیاده‌سازی DLP این است:

Install → Create Rules → Block Everything

این رویکرد می‌تواند باعث شود:

• فعالیت‌های قانونی کاربران متوقف شوند.
• تعداد Alertها افزایش پیدا کند.
• کاربران به دنبال روش‌های دور زدن Policy بروند.
• تیم امنیت با حجم زیادی از False Positive مواجه شود.

راهکار بهتر:

مرحله اول: Discover

داده و رفتار کاربران را شناسایی کنید.

مرحله دوم: Audit / Simulation

Policy را بدون مسدودسازی اجرا کنید.

مرحله سوم: Tune

False Positiveها و Exceptionها را اصلاح کنید.

مرحله چهارم: Warn / Policy Tips

به کاربران هشدار دهید.

مرحله پنجم: Selective Block

فقط سناریوهای پرریسک را Block کنید.

مرحله ششم: Continuous Improvement

Policy را براساس داده‌های واقعی بازتنظیم کنید.

۱۳. False Positive؛ دشمن خاموش DLP

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

برای مثال:

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

DLP تشخیص می‌دهد:

Financial Data + External Destination

و عملیات را Block می‌کند.

اما مقصد در واقع یک شریک رسمی سازمان است.

این یک False Positive است.

اگر چنین اتفاقی مرتب تکرار شود، ممکن است کاربران:

• درخواست Exceptionهای متعدد بدهند.
• اطلاعات را از مسیرهای غیررسمی منتقل کنند.
• Policy را دور بزنند.
• یا حتی به سمت Shadow IT بروند.

بنابراین هدف DLP فقط افزایش تعداد Blockها نیست.

هدف، کاهش ریسک واقعی است.

۱۴. User Override؛ آیا کاربر باید بتواند Policy را دور بزند؟

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

برای مثال:

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

کاربر دلیل را ثبت می‌کند و فعالیت ادامه پیدا می‌کند.

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

• ثبت رویداد
• ثبت هویت کاربر
• ثبت دلیل
• Monitoring
• Alert در سناریوهای حساس

باشد.

۱۵. Severity؛ همه تخلفات یکسان نیستند

Policy بهتر است برای رخدادها سطح شدت تعریف کند.

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

۱۶. یک Policy خوب باید چه سؤال‌هایی را پاسخ دهد؟

قبل از ایجاد هر Rule، تیم امنیت باید حداقل به این سؤال‌ها پاسخ دهد:

۱. چه داده‌ای؟

Customer Data؟ Source Code؟ Financial Data؟

۲. چه کسی؟

چه کاربری یا گروهی؟

۳. از کجا؟

Endpoint؟ Cloud؟ Email؟

۴. به کجا؟

Internal؟ External؟ Personal Account؟

۵. از چه کانالی؟

USB؟ Email؟ Web؟ SaaS؟

۶. تحت چه شرایطی؟

زمان، دستگاه، مکان و Context چیست؟

۷. چه واکنشی؟

Allow؟ Monitor؟ Warn؟ Block؟

۸. چه کسی باید مطلع شود؟

SOC؟ Data Owner؟ Security Team؟

۹. آیا Exception وجود دارد؟

چه شرایطی باید از Rule مستثنی شود؟

۱۰. چگونه Policy را ارزیابی می‌کنیم؟

False Positive؟ تعداد Incident؟ Override؟ حجم داده Blockشده؟

۱۷. اشتباهات رایج در طراحی DLP Policy

اشتباه اول: Block Everything

سخت‌گیری بیشتر الزاماً به معنای امنیت بیشتر نیست.

اشتباه دوم: نبود Data Classification

اگر همه داده‌ها حساس باشند، در عمل هیچ داده‌ای اولویت مشخصی ندارد.

اشتباه سوم: Ruleهای بیش از حد پیچیده

Policy پیچیده‌ای که هیچ‌کس منطق آن را نمی‌فهمد، در زمان Incident نیز قابل مدیریت نیست.

اشتباه چهارم: Exceptionهای بی‌ضابطه

اگر برای هر کاربر و هر واحد Exception ساخته شود، Policy به‌تدریج بی‌اثر خواهد شد.

اشتباه پنجم: نادیده گرفتن Context

تشخیص اینکه یک فایل حساس است کافی نیست.

باید بدانیم:

چه کسی + چه زمانی + از کجا + به کجا + چگونه

اشتباه ششم: فعال کردن مستقیم Enforcement

Policy باید ابتدا در محیط کنترل‌شده و ترجیحاً Audit/Simulation آزمایش شود.

اشتباه هفتم: عدم بازبینی Policy

DLP Policy یک سند ثابت نیست.

با تغییر:

• معماری Cloud
• کاربران
• سامانه‌ها
• فرآیندهای سازمان
• قوانین
• سرویس‌های SaaS
• ابزارهای AI

باید Policy نیز بازبینی شود.

۱۸. DLP Policy و هوش مصنوعی

یکی از تغییرات مهم در طراحی Policy، ورود ابزارهای Generative AI به محیط سازمان است.

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

Copy → Paste → AI Tool

کند.

در نتیجه، Policy جدید باید بتواند سناریوهایی مانند:

Sensitive Data + External AI Service → Block / Warn

را نیز در نظر بگیرد.

AI یک کانال جدید برای جریان داده است؛ نه یک استثنا از معماری DLP.

۱۹. مدل پیشنهادی برای طراحی DLP Policy

برای سازمانی که می‌خواهد از صفر یک Policy Framework ایجاد کند، می‌توان مسیر زیر را پیشنهاد کرد:

Discover

↓

Classify

↓

Define Risk

↓

Design Conditions

↓

Add Context

↓

Define Actions

↓

Create Exceptions

↓

Audit

↓

Tune

↓

Enforce

↓

Monitor

↓

Review

این چرخه باید به‌صورت مستمر تکرار شود؛ زیرا داده‌ها، کاربران، سرویس‌های Cloud، ابزارهای SaaS و روش‌های انتقال اطلاعات دائماً تغییر می‌کنند.

۲۰. DLP Policy موفق چه شکلی است؟

یک Policy موفق الزاماً Policyای نیست که بیشترین تعداد فایل را Block کند.

Policy موفق باید بتواند:

• داده حساس را دقیق شناسایی کند.
• Context فعالیت را بفهمد.
• رفتارهای پرریسک را از فعالیت‌های عادی جدا کند.
• False Positive را کاهش دهد.
• فعالیت‌های قانونی کسب‌وکار را مختل نکند.
• رخدادهای مهم را ثبت و Alert کند.
• امکان اصلاح و بهینه‌سازی داشته باشد.

در واقع:

DLP Policy خوب، بین امنیت و عملیات سازمان تعادل ایجاد می‌کند.

جمع‌بندی

DLP بدون Policy عملاً مجموعه‌ای از قابلیت‌های فنی بدون منطق تصمیم‌گیری است.

Policy مشخص می‌کند:

چه داده‌ای → توسط چه کسی → از چه مسیری → به کجا → تحت چه شرایطی → با چه واکنشی

کنترل شود.

به همین دلیل، طراحی DLP Policy باید از Data Classification آغاز شود و به Context، Risk، Action، Exception و Monitoring برسد.

مدل ساده این فرآیند:

Classify → Define → Detect → Evaluate → Act → Monitor → Tune

است.

در معماری‌های مدرن، DLP دیگر یک سیستم ساده برای Block کردن فایل نیست؛ بلکه یک Policy-driven Data Security Control است که باید میان داده، هویت، مقصد، کانال و رفتار کاربر ارتباط برقرار کند.

و شاید مهم‌ترین اصل در طراحی آن این باشد:

هدف DLP جلوگیری از هر انتقال داده نیست؛ هدف، جلوگیری از انتقال پرریسک داده است.

تحلیل بهراد یوسفی؛ Policy خوب یعنی امنیت بدون فلج کردن سازمان

یکی از بزرگ‌ترین چالش‌های DLP این است که سازمان تصور می‌کند هرچه Policy سخت‌گیرانه‌تر باشد، امنیت بیشتر است.

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

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

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

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

بنابراین بلوغ واقعی DLP را نباید با تعداد Blockها اندازه گرفت.

سؤال مهم‌تر این است:

چند فعالیت پرریسک واقعی شناسایی و کنترل شده‌اند، بدون اینکه فرآیندهای قانونی سازمان مختل شوند؟

از نگاه من، سازمان بالغ باید DLP را به شکل یک چرخه مستمر ببیند:

Discover → Classify → Policy → Monitor → Learn → Tune

یعنی Policy باید از داده واقعی سازمان یاد بگیرد.

اگر یک Rule دائماً Override می‌شود، شاید مشکل از کاربر نباشد؛ شاید Policy اشتباه طراحی شده باشد.

اگر یک Rule هزاران Alert تولید می‌کند، شاید مشکل از حجم بالای تهدید نباشد؛ ممکن است Classification یا Condition بیش از حد عمومی باشد.

و اگر یک Policy هیچ Alertی تولید نمی‌کند، الزاماً به این معنا نیست که همه‌چیز امن است؛ ممکن است Rule اصلاً نقطه واقعی ریسک را پوشش نداده باشد.

به همین دلیل:

DLP Policy یک فایل تنظیمات نیست؛ یک فرآیند مدیریتی و امنیتی زنده است.

پرسش‌های متداول DLP Policy

آیا DLP Policy همان Data Classification است؟

خیر.

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

آیا DLP همیشه باید داده را Block کند؟

خیر. بسته به ریسک می‌توان از Allow، Audit، Monitor، Warn، Justification، Encrypt یا Block استفاده کرد.

آیا می‌توان یک Policy را برای تمام داده‌ها استفاده کرد؟

از نظر فنی ممکن است، اما معمولاً رویکرد مناسبی نیست. داده‌های Public، Internal، Confidential و Restricted ریسک یکسانی ندارند.

آیا DLP می‌تواند فعالیت کاربر را هم در نظر بگیرد؟

بله. در معماری‌های مدرن، Contextهایی مانند هویت کاربر، مقصد، کانال انتقال و نوع فعالیت می‌توانند در تصمیم Policy نقش داشته باشند.

بهترین روش شروع اجرای DLP Policy چیست؟

معمولاً بهتر است ابتدا Policy در حالت Audit یا Simulation اجرا شود، رفتار واقعی بررسی شود و پس از Tune کردن Ruleها، Enforcement برای سناریوهای پرریسک فعال شود.

اگر DLP بیش از حد False Positive تولید کند چه کنیم؟

Conditionها، Classification، Context و Exceptionها را بازبینی کنید. هدف Policy کاهش ریسک واقعی است، نه تولید بیشترین تعداد Alert.

منابع

NIST — Data Loss Prevention
https://csrc.nist.gov/glossary/term/data_loss_prevention

Microsoft Learn — Data Loss Prevention Policy Reference
https://learn.microsoft.com/lt-lt/purview/dlp-policy-reference

Microsoft Learn — Create and Deploy DLP Policies
https://learn.microsoft.com/en-ca/purview/dlp-create-deploy-policy

Microsoft Learn — Learn About Data Loss Prevention
https://learn.microsoft.com/en-ca/purview/dlp-learn-about-dlp