امنیت دریاچه داده؛ دسترسی، حریم خصوصی و تست

یک Bucket خصوصی است، همهٔ فایل‌ها رمزگذاری شده‌اند و کاربران با MFA وارد می‌شوند؛ بااین‌حال Data Scientist می‌تواند از Notebook یک جدول شامل شماره موبایل و کد ملی را Export کند، Service Account قدیمی به Raw zone دسترسی Write دارد و Policy کاتالوگ از مسیر مستقیم Object Storage دور زده می‌شود. امنیت دریاچه داده با سه تیک Encryption، RBAC و Firewall اثبات نمی‌شود.

Data Lake یک زنجیرهٔ اعتماد است: Producer، Ingestion، Storage، Catalog، Processing engine، Notebook، BI/API، Share، Backup و Deletion. این راهنما کمک می‌کند دارایی و جریان داده را مدل کنید، مجوز را در همهٔ مسیرها اعمال کنید، محرمانگی/تمامیت/حریم خصوصی و بازیابی را بیازمایید و برای هر کنترل Evidence قابل ممیزی بسازید. مثال محوری، دریاچهٔ دادهٔ پرداخت ایرانی با ریال، PSP، شماره موبایل و دادهٔ هویتی است.

امنیت دریاچه داده دقیقاً چه چیزی را پوشش می‌دهد؟

NIST SP 1500-4r2 امنیت و حریم خصوصی Big Data را در قالب معماری و Use case بررسی می‌کند. نکتهٔ قابل انتقال آن است که Control باید در Interfaceهای میان Provider، Processor و Consumer دیده شود؛ نه فقط روی فایل نهایی.

ده جزء مرز سیستم

1. منبع و مالک داده؛
2. Agent، API، Queue یا Batch ingestion؛
3. Raw/Landing و Quarantine؛
4. Curated/Trusted و Published zone؛
5. Catalog، Schema، Tag و Lineage؛
6. Spark/SQL/ML engine و Cluster؛
7. Orchestrator، CI/CD و Secret store؛
8. Notebook، Workspace و Local cache؛
9. BI، API، Export و Cross-account share؛
10. Backup، Archive، Retention و Destruction.

نام‌هایی مانند Raw یا Gold خودشان Security boundary نیستند. باید بدانیم کدام Identity از کدام Channel چه Actionی را روی کدام Object/Row/Column انجام می‌دهد و Policy کجا Enforce می‌شود.

چهار خاصیت و یک شرط

• محرمانگی: داده فقط برای هدف و Principal مجاز آشکار شود.
• تمامیت: Source، Transform و Publish بدون تغییر غیرمجاز و قابل ردیابی باشند.
• دسترس‌پذیری: حذف، باج‌افزار، خرابی Key/Region یا Policy اشتباه قابل بازیابی باشد.
• حریم خصوصی: پردازش دادهٔ شخصی برای افراد Harm نامتناسب نسازد.
• قابلیت اثبات: Policy، Audit، Test و Exception نسخه‌دار نشان دهند کنترل واقعاً کار می‌کند.

Framework جای Threat model و الزام حقوقی نیست

NIST CSF 2.0 شش Function حاکمیت تا بازیابی را برای مدیریت ریسک ارائه می‌کند، اما استفاده از آن Compliance خودکار نمی‌سازد. قانون، قرارداد، محل داده، صنعت و نقش سازمان باید جدا بررسی شوند. برای مبانی ارزیابی ریسک و Rules of Engagement از راهنمای تست امنیت نرم‌افزار استفاده کنید.

تهدیدهای واقعی در Data Lake

ده سناریوی مهم

• Bucket/Container یا Snapshot عمومی و Cross-account share ناخواسته؛
• Policy با Principal/Action/Resource wildcard یا Admin دائمی؛
• سرقت Credential سرویس Ingestion، Notebook یا CI؛
• دورزدن Row/Column policy با دسترسی مستقیم به Object؛
• Query یا Export انبوه توسط کاربر مجاز برای هدف غیرمجاز؛
• فایل مخرب، Schema poisoning، Formula/SQL/Code injection یا Parser exploit در Ingestion؛
• Dependency/Container/Notebook package آلوده و Egress داده؛
• دستکاری Event، Partition، Catalog یا Lineage و تولید تحلیل غلط؛
• حذف/رمزگذاری Object، Key یا Catalog و ناتوانی Restore؛
• PII در Log، Temp file، Result cache، Training artifact یا Test environment.

ریسک را قابل آزمون بنویسید

قالب مفید: «اگر [Threat actor] از [شرط/ضعف] در [مرز] استفاده کند، ممکن است [دارایی/افراد] دچار [اثر] شوند.» مثال: «اگر Credential سرویس BI افشا شود و Policy فقط در Catalog اعمال شده باشد، مهاجم می‌تواند فایل Raw پرداخت را مستقیم بخواند و شماره موبایل کاربران را استخراج کند.» سپس ریسک را به Owner، Control و Test وصل کنید. روش کامل در تست مبتنی بر ریسک آمده است.

Insider یک برچسب ساده نیست

کاربر مجاز ممکن است اشتباه، حساب تصاحب‌شده، فشار کاری یا قصد سوء داشته باشد. کنترل متناسب شامل Least privilege، Separation of duties، Just-in-time access، Approval، Query/Export limit، Audit مستقل و DLP است. مانیتورینگ نباید به نظارت بی‌ضابطهٔ کارکنان تبدیل شود؛ هدف، دسترسی و Retention لاگ هم باید تعریف شود.

حاکمیت، Inventory و چرخهٔ عمر داده

Inventory از Source تا Derivative

برای Dataset ثبت کنید: Owner/Steward، Source، Purpose، Subject/region، Classification، Schema، Zone، Consumer، Transform، Share، Retention، Legal hold و Disposal. Catalog کامل تضمین نمی‌کند Tag درست است؛ Discovery خودکار با Sampling و تأیید مالک داده ترکیب شود.

طبقه‌بندی باید Control را تغییر دهد

Public/Internal/Confidential/Restricted فقط Label نیست. هر Class باید Encryption/key، Allowed identity/channel, export، logging، retention، backup و Incident urgency مشخص داشته باشد. Classification در Column و Dataset کافی نیست اگر Join دو دادهٔ کم‌حساس، هویت فرد را آشکار کند.

جمع‌آوری تا حذف

1. قبل از Ingest، Purpose، Minimization و کیفیت Consent/Authority؛
2. در Ingest، Source authentication، Schema و Quarantine؛
3. در Storage، Ownership، Policy، Key و immutability؛
4. در Process، workload identity، isolation و approved code؛
5. در Consume، purpose-aware access، masking و export؛
6. در Share، قرارداد، expiry، revocation و onward-use؛
7. در Retention، حذف از مشتقات، Cache، Backup و Index با Evidence.

Data lake مجوز «همه‌چیز را نگه دار» نیست

ارزش احتمالی آینده، Purpose مشخص نیست. حجم بیشتر Blast radius، هزینهٔ Discovery و پیچیدگی حذف را افزایش می‌دهد. Raw zone هم Retention و Owner می‌خواهد. NIST Privacy Framework ابزاری برای مدیریت Privacy risk است و صریحاً استفاده از Framework را تضمین Compliance نمی‌داند.

هویت و کنترل دسترسی چندلایه

Principalها را تفکیک کنید

• انسان: Analyst، Data Scientist، Engineer، Support، Auditor و Admin؛
• Workload: Ingestion، Transform، BI، ML training و Cleanup؛
• External: Vendor، Partner، Customer tenant و Cross-account role؛
• Emergency: Break-glass با Approval، زمان محدود و Review.

Credential مشترک، Long-lived key و استفاده از Human account برای Job، Attribution و Revocation را خراب می‌کند. Workload identity کوتاه‌عمر و Bound به محیط/Job را ترجیح دهید.

RBAC، ABAC و Purpose

RBAC برای وظایف پایدار ساده است؛ ABAC/Tag policy برای Dataset/tenant/classification مقیاس‌پذیرتر، اما به Tag integrity وابسته است. Row/Column/Cell filters برای همهٔ Engine و Channelها یکسان نیستند. Matrix زیر را بسازید:

Catalog و Storage هر دو را تست کنید

در برخی معماری‌ها درخواست باید هم Policy متادیتا و هم Policy Storage را بگذراند. مستند مجوزهای AWS Lake Formation این دو لایه را برای IAM/Lake Formation توضیح می‌دهد. اصل Vendor-neutral این است: Deny در SQL/BI کافی نیست اگر URL، SDK، Mount، temporary credential یا copied object مسیر جایگزین باشد.

Grant، تغییر نقش و Revocation

Joiner/Mover/Leaver، Group nesting، inherited policy، cross-account share، expiring exception و cached credential را بیازمایید. Revocation SLO تعریف کنید: چه مدت بعد از حذف نقش، Session/Token/Result cache دیگر داده را نمی‌دهد؟ Permission review باید Actual effective access را ببیند، نه فقط فایل IaC.

حفاظت از Storage، Key، تمامیت و پردازش

Object Storage امن

Public access را به‌صورت مرکزی مسدود، ACLهای پراکنده را در صورت عدم نیاز حذف، TLS را enforce، Policy wildcard و Cross-account را تحلیل و Inventory/Versioning/Retention/Object lock را بر اساس Threat model تنظیم کنید. راهنمای امنیت Amazon S3 این موارد و Audit با Inventory/CloudTrail را توضیح می‌دهد؛ نام سرویس را به Cloud دیگر تعمیم ندهید، کنترل را تعمیم دهید.

رمزنگاری و مدیریت کلید

At-rest و In-transit را در Source→Broker→Compute→Sink→Consumer تست کنید. Key policy، Separation of duties، rotation، disable/delete protection، backup و audit را ببینید. Encryption مانع سوءاستفادهٔ Principal مجاز، Query export، اشتراک غلط یا افشای Metadata نمی‌شود. «AES-۲۵۶» بدون Mode/Key lifecycle/Boundary فقط نام الگوریتم است.

تمامیت و Provenance

Source identity، schema/version، immutable ingest ID، hash/control total، append-only audit، atomic publish و Reconciliation بسازید. Lineage می‌گوید سامانه چه مسیری را ثبت کرده، نه اینکه داده صحیح یا مسیر کامل است. آزمون‌های CDC، Duplicate و Publish در راهنمای تست ETL تشریح شده‌اند.

Pipeline و Supply chain

• فایل/Message را Untrusted فرض و Parser، decompression bomb، path/name، schema و size limit را کنترل کنید.
• Query/Template/Notebook parameter را جدا و از concatenation ناامن دور نگه دارید.
• Dependency، Container، package repository و CI runner را Pin/Scan/Sign کنید.
• Secret در code، notebook output، log، image layer و job config قرار نگیرد.
• Job runner فقط Dataset و Sink لازم را ببیند و Egress محدود باشد.

اسکن یک Signal است؛ Triage و Reachability لازم‌اند. چارچوب عملی در تحلیل استاتیک کد و ابزارهای تست امنیت آمده است.

Notebook و محیط تحلیل

Notebook کد، Credential، Result و امکان Egress را کنار هم می‌آورد. Sharing، public link، package install، local disk، clipboard/download، idle session، kernel isolation و outbound network را بررسی کنید. Masked view وقتی کاربر به underlying table یا cached result دسترسی دارد Control مؤثر نیست.

حریم خصوصی، De-identification و اشتراک

Masking مساوی ناشناس‌سازی نیست

Pseudonymized/tokenized data هنوز ممکن است با Vault یا Join دوباره به فرد متصل شود. Synthetic data نیز می‌تواند رکورد حفظ‌شده یا الگوی نادر را نشت دهد. Risk بازشناسایی را با Quasi-identifier، Linkability، uniqueness و دسترسی مهاجم ارزیابی کنید. دادهٔ تست را با اصول مدیریت داده تست بسازید.

Purpose و Secondary use

دسترسی فنی به جدول، مجوز هر تحلیل نیست. Dataset card باید Purpose مجاز/ممنوع، Population، Bias، Retention و Approval را بگوید. Query/Export پرریسک می‌تواند نیازمند Project tag، ticket، time-bound role یا محیط امن باشد.

اشتراک داخلی و خارجی

برای Share ثبت کنید: گیرنده، Dataset/version، Fields/Rows، Purpose، expiry، onward sharing، region، revocation و deletion evidence. Copy ساخته‌شده بعد از Revocation منبع باقی می‌ماند؛ معماری Share-by-reference و Export هرکدام ریسک متفاوت دارند.

حذف End-to-End

Deletion را در Raw، Curated، derived table، feature store، model/training artifact، index، cache، notebook export، backup و شریک دنبال کنید. Backup immutable ممکن است حذف فوری را نپذیرد؛ Policy restore-and-redelete و محدودیت قانونی/عملی باید پیشاپیش روشن باشد.

روش تست امنیت Data Lake

۱. Test Basis و مجوز

Scope، حساب‌ها، Dataset مصنوعی، تکنیک مجاز، سقف Query/Export، Stop condition و Evidence handling را مکتوب کنید. تست DDoS، Exfiltration یا حذف واقعی بدون محیط و اختیار صریح انجام نشود.

۲. Control matrix

برای هر Risk، Control، Enforcement point، Prevent/Detect/Recover، Owner، Config/Policy version، Test و Evidence بنویسید. «Encryption enabled» Test نیست؛ «Principal بدون KMS decrypt، Object را از سه Channel نمی‌خواند و Deny audit ثبت می‌شود» قابل آزمون است.

۳. تست مثبت و منفی دسترسی

• Persona × Dataset × Action × Channel × Condition را پوشش دهید.
• Catalog/SQL، Storage API، temporary URL، mount، BI export و notebook را جدا اجرا کنید.
• Same-tenant/cross-tenant، row/column filter و aggregation inference را بسنجید.
• Expired/revoked token، group change و service identity اشتباه را امتحان کنید.
• Deny باید امن، قابل مشاهده و بدون افشای Metadata اضافی باشد.

۴. Config/Policy as code

Public access، encryption، TLS، wildcard، key policy، logging، versioning، retention و network egress را در Pull Request و روی Actual state اسکن کنید. IaC plan کافی نیست؛ Drift و inherited organization policy را نیز بخوانید.

۵. Ingestion و پردازش خصمانه

با فایل کنترل‌شدهٔ malformed، oversized، nested، wrong schema، duplicate، path-like name و formula/code-like fields رفتار را بسنجید. Quarantine باید مانع Publish شود، Original evidence را امن نگه دارد و Alert بسازد. Payload بی‌خطر انتخاب کنید؛ هدف اثبات Control است، نه آسیب.

۶. Audit و Detection

Read/Write/Delete/Share/Policy/Key/Export و Deny را اجرا و بررسی کنید چه کسی، چه زمان، از کدام Channel، روی چه Dataset و با چه Result ثبت شده است. Log دسترسی خودش دادهٔ حساس است؛ Tamper resistance، clock، retention و دسترسی را بیازمایید. Alert را از رخداد تا Owner/Acknowledgement دنبال کنید.

۷. Recovery و Ransomware

حذف Object/partition، corruption Catalog، disabled key و compromised role را در محیط مجاز شبیه‌سازی کنید. RPO/RTO، نسخهٔ سالم، Permission restore، Reconciliation و Revocation مهاجم را بسنجید. Backup که Restore نشده Evidence بازیابی نیست.

۸. Finding و Retest

Artifact/config hash، Principal، Policy path، Dataset مصنوعی، گام، Expected/Actual، Evidence mask‌شده، Blast radius، Severity، Fix و Retest را ثبت کنید. Severity با Priority و پذیرش ریسک یکی نیست؛ Exception باید Owner، دلیل، کنترل جبرانی و Expiry داشته باشد.

مثال: دریاچهٔ دادهٔ پرداخت ایرانی

سناریو تخیلی است. Data Lake شامل Order، PSP callback، Refund، Settlement، شماره موبایل، شناسه مشتری، Token کارت و لاگ پشتیبانی است. دادهٔ PAN کامل وارد Lake نمی‌شود؛ Token و Last4 نیز طبق Classification محافظت می‌شوند.

Zone و نقش‌ها

• Raw: فقط Ingestion writer و Settlement reader؛ immutable و retention کوتاه‌تر.
• Curated: مبلغ Canonical ریال، هویت Pseudonymized و کیفیت تأییدشده.
• Published: Aggregate روزانه بدون شناسه مستقیم برای BI.
• Quarantine: Callback نامعتبر؛ دسترسی محدود Security/Data owner.
• Support: فقط Tenant مربوط و شماره موبایل Mask‌شده؛ بدون Raw/Object/Export.
• Auditor: Read-only time-bound روی Evidence مصوب و Audit جدا.

Test pack پرریسک

1. Support از BI رکورد Tenant خودش را می‌بیند، Cross-tenant و Storage API Deny می‌شوند.
2. Data Scientist می‌تواند Aggregate بخواند اما National ID، phone و Export raw را نه.
3. Settlement job با Human token یا از Workspace توسعه اجرا نمی‌شود.
4. Callback با رقم فارسی/عربی، مبلغ تومان و Timestamp تهران Quarantine/Normalize درست دارد و Raw دستکاری نمی‌شود.
5. Policy catalog با signed URL، mount و direct object path دور زده نمی‌شود.
6. KMS key غیرفعال، Job را Fail-closed و Alert می‌کند؛ Plaintext fallback وجود ندارد.
7. Notebook package ناشناس و outbound destination غیرمجاز Block/Audit می‌شوند.
8. حذف Subject در مشتقات، Cache و Export inventory دنبال و Limit backup ثبت می‌شود.
9. حذف تصادفی Partition از نسخهٔ immutable بازیابی و Sum/Count/Key Reconcile می‌شود.

Evidence پذیرش

Policy evaluation، Deny/Allow data event، query audit، KMS event، Object version، Catalog tag، lineage link، alert ticket و reconciliation report باید به Run ID متصل باشند. Screenshot UI به‌تنهایی اثبات Effective access یا حذف نیست.

مانیتورینگ و پاسخ به رخداد

سیگنال‌های عملی

• تغییر Policy، Key، Public/share و Logging؛
• Read/Export حجیم یا غیرمعمول بر حسب نقش/زمان/Dataset؛
• Deny spike، credential use از Location/Environment غیرمنتظره؛
• Notebook/Job با Egress یا package جدید؛
• Deletion/version surge، backup failure و Catalog drift؛
• دادهٔ Restricted بدون Tag/Owner/retention.

Anomaly detection یک Signal است، نه اثبات حمله. Baseline drift، Job جدید و False positive باید Triage شوند.

Runbook رخداد داده

1. رخداد را Validate و Severity/Scope اولیه تعیین کنید.
2. Principal/token/share را متناسب Contain کنید، بدون نابودکردن Evidence.
3. Audit و Object/Query/Export history را حفظ کنید.
4. Dataset، Subject، مشتقات و گیرندگان را Scope کنید.
5. Secret/Key را با برنامه Rotate و دسترسی را بازطراحی کنید.
6. از نسخهٔ سالم Restore/Reconcile و سرویس را مرحله‌ای برگردانید.
7. Privacy/Legal/Contract notification را صاحب اختیار تعیین کند.
8. Root cause، Control gap و Regression test را ثبت کنید.

چک‌لیست انتشار و ممیزی

• Inventory، Owner، Purpose، Classification و Retention کامل‌اند.
• تمام Channelهای Catalog/Storage/Compute/Notebook/BI/Export در Matrix هستند.
• Human/Workload/Partner identity کوتاه‌عمر و قابل Attribution است.
• Least privilege، tenant isolation، row/column policy و direct-path bypass تست شده‌اند.
• Public/cross-account، wildcard، TLS، encryption و Key policy کنترل شده‌اند.
• Ingestion، Parser، Schema، Quarantine و Supply chain تست دارند.
• Notebook sharing/cache/download/egress و Secretها محدودند.
• Masking/Pseudonymization با Anonymization اشتباه نشده و Join risk دیده شده است.
• Read/Write/Delete/Share/Export/Deny audit و Alert end-to-end تأیید شده‌اند.
• Backup/Version/Key/Catalog recovery با Reconciliation تمرین شده است.
• Exceptionها Owner/Expiry و Residual risk دارند.
• Evidence نسخه‌دار به Release/Policy/Dataset وصل است.

برنامهٔ ۳۰روزه

هفتهٔ اول: Inventory و تهدید

یک Domain پرریسک انتخاب، Data flow و ده جزء مرز را رسم کنید. Dataset/Owner/Class/Purpose/Retention و پنج Risk statement بسازید.

هفتهٔ دوم: Effective access

Persona matrix را روی Catalog، Storage، BI و Notebook اجرا کنید. Public/share/wildcard/key policy و Drift را Baseline کنید.

هفتهٔ سوم: Pipeline، Audit و Privacy

Ingestionهای خصمانهٔ بی‌خطر، Export/egress، re-identification review و شش Audit event را تست کنید. Gapها را به Owner بدهید.

هفتهٔ چهارم: Recovery و Gate

یک Restore/Reconcile drill انجام دهید، Control matrix و Evidence schema را نهایی و Policy checks سریع را به CI اضافه کنید. نتیجه را Adopt/Adapt/Stop کنید.

ده ضدالگو

• امن دانستن Lake چون Bucket خصوصی و رمزگذاری شده است؛
• اعمال Policy فقط در Catalog و نادیده‌گرفتن direct object path؛
• یک Service Account مشترک برای همهٔ Jobها؛
• Admin دائمی به‌جای JIT و Break-glass؛
• نامیدن Zone به‌عنوان Security boundary بدون Enforcement؛
• Masking و Synthetic را تضمین حریم خصوصی دانستن؛
• جمع‌آوری نامحدود برای «استفادهٔ احتمالی آینده»؛
• ثبت Audit بدون تست Completeness/Alert/Retention؛
• Backup بدون Restore و Reconciliation؛
• ادعای Compliance صرفاً با انتخاب یک Framework.

سؤالات متداول

جمع‌بندی

امنیت Data Lake یک محصول یا تنظیم واحد نیست. از Inventory و Purpose شروع می‌شود، Effective access را در تمام Channelها می‌آزماید، Storage/Key/Pipeline/Notebook و Privacy را در چرخه عمر پوشش می‌دهد و با Audit، Recovery و Evidence بسته می‌شود. پرسش اصلی این نیست که «آیا RBAC و Encryption داریم؟»؛ این است که کدام Identity، برای چه هدفی، از چه مسیر و تا چه زمانی می‌تواند کدام داده را بخواند، تغییر دهد، صادر کند یا حذف کند—و چگونه آن را ثابت می‌کنیم؟