حریم خصوصی دادهٔ تست با نصب ابزار Masking یا چسباندن برچسب Synthetic حل نمی‌شود. سؤال عملی این است: «آیا Dataset مشخص، برای Purpose و Test objective مشخص، در Environment و برای Recipientهای مشخص، تا زمان مشخص مجاز و از نظر ریسک بازشناسایی قابل‌قبول است؟» پاسخ باید نسخه‌دار، محدود و قابل‌ابطال باشد؛ نه یک تیک سبز دائمی.

این راهنما Test Data Privacy Use Authorization را می‌سازد: Applicability و Purpose، Inventory/Classify، Source/Provenance، Transform، Re-identification assessment، Utility، Security/Provisioning، Retention/Delete و Decision/Correction. این Artifact جای نظر حقوقی، DPO/Privacy، Security یا Data owner را نمی‌گیرد و انطباق GDPR/HIPAA را اثبات نمی‌کند.

مالکیت این مقاله و مرز با سایر راهنماها

این صفحه فقط «مجوز استفاده از یک Dataset تست و ریسک بازشناسایی در Context مصرف» را مالک است. برای Data Request، Fitness، Pack، Provision، Lease و Cleanup به قرارداد مدیریت Data Pack تست بروید. برای Factory، Faker، Property-based و Generation، راهنمای تولید دادهٔ تست مالک است. برای انتخاب/PoC محصول Masking/Subsetting/Synthetic، راهنمای انتخاب ابزار TDM را ببینید.

برای مقایسهٔ Strategyهای Real/Masked/Synthetic از دادهٔ تست واقعی یا مصنوعی، برای Operating model عمومی از راهنمای پایهٔ TDM، برای تست قابلیت‌های Consent/Deletion/Retention محصول از تست حریم خصوصی برای QA، برای Environment controls از مدیریت محیط تست و برای Data Lake/IAM/Threat model از امنیت دریاچهٔ داده استفاده کنید.

پاسخ کوتاه: آیا دادهٔ Production در تست ممنوع است؟

از این مقاله پاسخ حقوقی جهانی «بله/خیر» نمی‌گیرید. کپی Production نباید پیش‌فرض باشد؛ چون Purpose، کپی‌ها، گیرنده‌ها و Attack surface را گسترش می‌دهد. اما مجازبودن به Jurisdiction، Entity/role، نوع داده، Purpose/lawful basis، Notice/contract، Sector rule، Transfer و کنترل‌ها وابسته است. تیم QA باید کم‌ریسک‌ترین Dataset کافی را پیشنهاد و Applicability/Authorization را به افراد صلاحیت‌دار Route کند.

Privacy، Security، Confidentiality و Compliance یکی نیستند

Security از Confidentiality/Integrity/Availability و کنترل تهدید پشتیبانی می‌کند. Privacy دربارهٔ پردازش داده و پیامد آن برای افراد است. Confidentiality محدودیت افشاست. Compliance انطباق با Requirementهای شناسایی‌شده است. Encryption می‌تواند افشا را سخت کند، اما Purpose نامعتبر، Retention اضافی یا دسترسی بی‌دلیل را قانونی/اخلاقی نمی‌کند.

پشتوانهٔ رسمی و حد ادعا

مادهٔ ۵ متن رسمی GDPR در EUR-Lex اصولی مانند Purpose limitation، Data minimisation، Accuracy، Storage limitation و Security را بیان می‌کند. راهنمای رسمی HHS برای De-identification اطلاعات سلامت تحت HIPAA دو مسیر Expert Determination و Safe Harbor را توضیح می‌دهد و صریحاً می‌گوید حتی De-identified data ریسک شناسایی صفر ندارد. NIST SP 800-188 هدف، مدل اشتراک، Disclosure risk، بازشناسایی و Governance را کنار تکنیک می‌گذارد و هشدار می‌دهد هر ابزار Masking برای De-identification کافی نیست. این منابع برای ساخت کنترل اقتباس شده‌اند؛ شمول یا انطباق سازمان شما را تعیین نمی‌کنند.

HIPAA برای هر اپ سلامت نیست

وجود فیلد بیماری یا Appointment به‌تنهایی Applicability HIPAA را ثابت نمی‌کند. باید Covered entity/Business associate، PHI و نقش/جریان مشخص شوند. Safe Harbor و Expert Determination استانداردهای تعریف‌شده در همان Context هستند؛ حذف دستی چند فیلد یا «هیچ نامی نیست» جای آن‌ها را نمی‌گیرد. تیم ایرانی نیز نباید از یک FAQ عمومی نتیجهٔ حقوقی فرامرزی قطعی بسازد.

GDPR دامنهٔ «هر دادهٔ اروپایی در دنیا» نیست

Nationality یا دامنهٔ ایمیل، Applicability را به‌تنهایی تعیین نمی‌کند. Establishment، Offering/Monitoring، Data subject، Controller/Processor roles، Processing و Transfer باید بررسی شوند. Pseudonymised personal data می‌تواند همچنان Personal data باشد. «شرکت ایرانی پس حتماً/هرگز مشمول نیست» هر دو پاسخ ضعیف‌اند؛ Determination با منبع و Reviewer صلاحیت‌دار ثبت شود.

چرخهٔ Privacy Use Authorization

  1. Request: Purpose، Objective و Propertyهای لازم.
  2. Determine: Applicability، roles و Authority.
  3. Inventory/Classify: تمام Store/Field/File/Derivative.
  4. Minimize: کمترین Field/Row/Precision/History.
  5. Select: Source family و کم‌ریسک‌ترین Strategy کافی.
  6. Transform: Policy نسخه‌دار با Failure handling.
  7. Assess: Threat/Recipient/Auxiliary data/Re-identification.
  8. Validate: Privacy و Utility با Oracle مستقل.
  9. Authorize: Review/Condition/Expiry/Exception.
  10. Provision: Manifest/Lease/Destination/Run binding.
  11. Monitor/Revoke: Egress/Copy/Incident/Change.
  12. Delete/Correct: Coverage/Evidence/Reissue/Affected runs.

Authorization identity و چرخهٔ عمر

`AuthorizationID`، DatasetID، Version، Status، Supersedes، Owner، CreatedAt، AsOf، ReviewAt و ExpiresAt را Pin کنید. وضعیت‌ها می‌توانند `PROPOSED / HOLD / CONDITIONALLY_AUTHORIZED / AUTHORIZED / REVOKED / EXPIRED / SUPERSEDED` باشند. «یک‌بار Mask شد» مجوز همیشگی برای هر Test/Recipient نیست.

AuthorizationID: TPUA-SYN-IR-017
DatasetID: PACK-SYN-CHECKOUT-042
Version: 1.0
Status: PROPOSED
AsOf: 2026-08-13T00:00:00Z
Purpose: تست Retry/Idempotency در Harness قطع از شبکه
ExpiresAt: 2026-09-12T00:00:00Z
Decision: NOT_YET_AUTHORIZED

Test Data Request را از «داده واقعی می‌خواهم» آغاز نکنید

Test purpose، Test objective، Required properties، Population/Volume، Environment، Recipients، Duration، Output و Out-of-scope را بنویسید. «Realistic» Requirement نیست. برای Retry شاید State transition و duplicate Event لازم باشد، نه نام/موبایل/تاریخ تولد/تاریخچهٔ خرید واقعی.

Purpose را به Property قابل‌آزمون تبدیل کنید

برای هر Property بپرسید چرا لازم است و چه Oracle دارد: Referential relation، Distribution، Rare state، Sequence، Locale، Volume یا Long-tail text. اگر Test با Rule-based synthetic پوشش می‌گیرد، Source مشتق از Production توجیه اضافه می‌خواهد. «شاید بعداً لازم شود» Purpose معتبر/محدود نیست.

Applicability Matrix، نه لیست مخفف‌ها

پرسشEvidenceOwner
کدام Jurisdiction/sector/contract؟Scope determination نسخه‌دارLegal/Privacy qualified reviewer
Controller/Processor/Custodian/Recipient کیست؟Role/data-flow mapPrivacy/Data owner
چه نوع داده و Subject؟Inventory/classificationData steward
Purpose/basis/notice/transfer چیست؟Requirement refsQualified authority
تیم QA چه می‌سنجد؟Test evidence، نه legal verdictTest owner

`gdpr=true` یا `hipaa=true` بدون دلیل، تاریخ، Reviewer و Scope قابل ممیزی نیست. Unknown را حفظ کنید. مقالهٔ عمومی یا خروجی AI نباید Qualified determination نامیده شود.

Inventory باید خارج از ستون‌های واضح را ببیند

Source system، Store، Table/Field، Free text، JSON payload، File/Attachment، Log/Trace، Backup/Snapshot، Cache، Export، Notebook، Search index، Message queue، CI artifact و مشتقات را فهرست کنید. حذف `name` در Database وقتی PDF، Debug log یا Object storage همان هویت را نگه می‌دارد، Privacy control کامل نیست.

Classification چندبعدی است

Personal data، Special-category/health/financial، Credential/Secret، Direct identifier، Quasi-identifier، Sensitive attribute و Unknown class را جدا کنید. شمارهٔ سفارش ممکن است مستقیم نام نباشد اما از سیستم دیگر به فرد Link شود. Amount/region/time/rare diagnosis در ترکیب می‌تواند Singling-out را ممکن کند.

Unknown class باید Gate را ببندد

Free text، Blob، Vendor payload یا Field تازه اگر Classify نشده است، «غیرحساس» نیست. مسیر امن می‌تواند Exclude، Quarantine، Manual review محدود یا Transform تخصصی باشد. Default عبور آزاد، کنترل را به Schema drift می‌بازد.

Purpose limitation و Secondary use

Original purpose، Proposed test purpose، Compatibility/authority، Notice/Consent constraints، Contract و Secondary-use review را ثبت کنید. Data collected برای پشتیبانی مشتری، خودکار برای Training مدل یا Demo تست مجاز نمی‌شود. Consent نیز تنها مبنای ممکن نیست و QA نباید Lawful basis اختراع کند.

Data minimisation چهار بُعد دارد

حداقل Field، Row/Population، Precision و History/Time range را جدا کم کنید. Subset فقط Row count را کاهش می‌دهد و ممکن است Rare person را قابل‌شناسایی‌تر کند. کم‌کردن Precision تاریخ/مکان می‌تواند Privacy را بهتر ولی Oracle تست را خراب کند؛ Trade-off با Acceptance سنجیده شود.

Source family را برچسب بزنید

`RULE_SYNTHETIC / MODEL_SYNTHETIC / MASKED_DERIVED / PSEUDONYMISED_DERIVED / DE_IDENTIFIED_ASSESSED / PUBLIC_LICENSED / MANUAL_FICTIONAL` یکسان نیستند. Source Snapshot، Provenance، Custodian، Extraction authority، Integrity، Freshness، Schema version و Gaps را ثبت کنید. Label نباید بیش از Evidence ادعا کند.

Masking با Anonymisation مترادف نیست

Masking نام عمومی Transform است: Replace، Shuffle، Generalize، Suppress، Tokenize یا نمایش محدود. ممکن است Reversible/Consistent باشد و Linkage را حفظ کند. Anonymisation نتیجه‌ای وابسته به Risk/Context است، نه نام Algorithm. NIST نیز می‌گوید هر ابزار صرفاً Masking قابلیت کافی برای De-identification ندارد.

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

اگر Mapping/key/additional information وجود دارد یا داده با منابع قابل‌دسترس دوباره به فرد نسبت داده می‌شود، «ناشناس قطعی» نگویید. Key separation، Access، Rotation، Retention و Incident route لازم است. Pseudonymisation می‌تواند ریسک را کم کند؛ Applicability یا تمام تعهدها را خودکار حذف نمی‌کند.

Encryption Transform هویت نیست

Encryption at rest/in transit در برابر برخی افشاها محافظت می‌کند، اما مصرف‌کنندهٔ مجاز داده را Decrypt می‌کند. دادهٔ رمز‌شده لزوماً Anonymous نیست. Key management، Principal، Audit و Revocation بخشی از Security context‌اند، نه جایگزین Minimisation/Authorization.

Subsetting Privacy control کافی نیست

Subset سطح کپی را کم می‌کند اما رکوردهای باقی‌مانده ممکن است واقعی و قابل Link باشند. Sampling نادرست حتی Uniqueness را بالا می‌برد. Closure روابط، Selection bias، rare rows، Transform بعدی و Outputها را بررسی کنید. «کوچک‌تر» برابر «کم‌ریسک در همهٔ ابعاد» نیست.

Synthetic data ذاتاً خصوصی نیست

Rule-based fictional که هیچ دادهٔ شخص واقعی را ورودی نمی‌گیرد مرز روشن‌تری دارد؛ ولی Model-based synthetic می‌تواند از Training source الگو/رکورد نادر را حفظ یا Memorize کند. Prompt، sample، embedding، checkpoint و Evaluation output نیز داده‌اند. `synthetic=true` باید به Generation basis و Evidence وصل شود.

Synthetic privacy validation

Training source، Model/version، Prompt input، Seed، Constraints، Memorization test، Nearest-neighbor، Rare-combination، Membership/inference threat و Provenance label را ثبت کنید. یک Threshold جهانی پیشنهاد نمی‌شود؛ Assessor باید Method/Population/Recipient/auxiliary data را Contract کند. Utility بالا می‌تواند با Disclosure risk بالا هم‌زمان باشد.

Transform Policy نسخه‌دار

PolicyID: MASK-SYN-017 v3
Direct identifiers: suppress/replace
Quasi-identifiers: generalize per approved bands
Sensitive attributes: preserve only required test partitions
Free text/files/logs: exclude or dedicated scan+transform
Consistency: scoped to DatasetID, not global person token
Collision: measured against domain constraints
Referential integrity: independent validator
Reversibility/key: NONE for fictional fixture
Failure: FAIL_CLOSED + quarantine + owner notification

Transform failure باید Fail closed باشد

Unknown column، unparsable payload، Schema drift، oversized file، timeout، partial batch، collision یا referential break را Silent pass نکنید. Row/field/file coverage، failure count، quarantine و Retry identity لازم است. «Job موفق بود» بدون Denominator نمی‌گوید همهٔ داده تبدیل شد.

Re-identification risk به Context وابسته است

Dataset به‌تنهایی «ایمن» نیست. Anticipated recipient، Motivated intruder، Auxiliary data، Release model، Query/download، Contract، Skill/compute، زمان و داده‌های عمومی تازه، Risk را تغییر می‌دهند. Assessment برای enclave داخلی قابل انتقال خودکار به فایل Downloadable یا Vendor خارجی نیست.

پنج مسیر افشا را جدا بسنجید

  • Singling out: یک رکورد/فرد از دیگران جدا می‌شود.
  • Linkability: رکوردها یا Datasetها به هم وصل می‌شوند.
  • Inference: ویژگی حساس از سایر ویژگی‌ها استنباط می‌شود.
  • Membership: حضور فرد در Source/Training استنباط می‌شود.
  • Direct leakage: Identifier/Secret در Field، متن، فایل یا Log باقی مانده است.

Rare rows و ترکیب‌ها

سن بالا، Location کوچک، زمان دقیق، مبلغ خاص، بیماری نادر یا Sequence غیرمعمول ممکن است به‌تنهایی عمومی به نظر برسد اما در ترکیب Unique شود. فقط اسکن Regex نام/ایمیل کافی نیست. Record uniqueness، Population reference و Auxiliary datasets باید در Threat model دیده شوند.

Risk threshold را پس از دیدن نتیجه نسازید

Method، Assessor، Metric/qualitative criteria، Threshold، Recipient، Release context، Evidence و Expiry پیش از نتیجه Pin شوند. «Risk کم است» بدون تعریف و Authority تصمیم نیست. HHS نیز برای Expert Determination یک عدد جهانی ارائه نمی‌کند؛ Context و قضاوت تخصصی مستند مهم‌اند.

Temporal risk و Expiry

دادهٔ کمکی، قدرت محاسبات، Publication و Datasetهای دیگر تغییر می‌کنند. Assessment باید AsOf/ReviewAt/ExpiresAt و Triggerهای بازبینی داشته باشد: Recipient/Environment تازه، Schema/Policy/Model change، دادهٔ عمومی تازه، Incident یا خروج از enclave. مجوز منقضی خودکار Pass نیست.

Release model بخشی از Privacy control است

Protected enclave، Query interface با limit، Aggregate output، Downloadable file و Public release ریسک متفاوت دارند. Network boundary، Egress، Copy limit، Clipboard/print، Monitoring، Contractual controls و Recipient training را ثبت کنید. «فایل فقط داخلی است» بدون Effective access و خروجی‌سنجی کافی نیست.

Utility را مستقل اعتبارسنجی کنید

Privacy transform می‌تواند Schema، Domain، Relation، Distribution، Edge case، Sequence، Performance characteristic یا Oracle را خراب کند. Utility validation با Privacy assessment یکی نیست. Dataset می‌تواند کم‌ریسک ولی بی‌فایده، یا مفید ولی غیرمجاز باشد؛ تنها حالت دو Gate سبز به Authorization نزدیک می‌شود.

Referential integrity برای Privacy کافی نیست

حفظ Foreign key می‌گوید Relation فنی نشکسته؛ نمی‌گوید Person غیرقابل‌شناسایی یا Purpose مجاز است. برعکس، Token consistent across Datasetها ممکن است تست Join را ممکن کند ولی Linkability را بالا ببرد. Scope consistency را به Test objective محدود کنید.

Security baseline برای Pack مجاز

Identity، MFA، RBAC/ABAC، Separation of duties، Encryption in transit/at rest، Key management، Secret scan، Vulnerability state، Audit log، Alerting و Break-glass را بررسی کنید. Least privilege یک شعار نیست: Principal→Resource→Action→Condition→Expiry و Negative test لازم دارد.

Environment پایین‌تر نباید Control پایین‌تر باشد

Test/Dev محیط «کم‌اهمیت» نیست؛ اغلب User بیشتر، Tool بیشتر و Monitoring کمتر دارد. Production-like بودن دلیل کپی Secret/Identity/PII نیست. Egress، Vendor plugin، Notebook، CI artifact، Screenshot و Debug log را در Boundary واقعی ببینید.

Provisioning با Privacy Manifest

PackID/DatasetID/AuthorizationID
SourceFamily + Snapshot + TransformPolicy + RiskAssessment
ApprovedDestination + Recipients + Namespace + Lease
DeliveryChannel + Checksum + ConsumerReceipt + RunBinding
Copy/Egress policy + Expiry + Revoke route
Cleanup scope + DeletionEvidence target
NotAuthorized: local copy | Production write | external upload

Consumer باید Receipt و Conditions را بپذیرد. Run binding نشان دهد تست همان Pack مجاز را مصرف کرده است. Copy دستی روی لپ‌تاپ یا ارسال در پیام‌رسان، Provisioning ثبت‌شده را دور می‌زند.

Retention از کدام Event شروع می‌شود؟

Created، Provisioned، First use، Last run یا Test closure؟ Start event، Period، Legal hold/exception، Expiry signal و Owner را تعریف کنید. Retention «۳۰ روز» بدون نقطهٔ شروع قابل اجرا نیست. Derivative/Export/Log/Backup نیز Coverage می‌خواهند.

Delete با SQL روی جدول اصلی تمام نمی‌شود

Pack، Clone، Snapshot، Cache، Index، Queue، File، Artifact، Notebook، Log، Backup و مشتق‌ها را پوشش دهید. Deletion evidence، Exception، Backup expiry/restore behavior و Canary restore test لازم است. «حذف شد» بدون Scope/Result/Unknown، ادعای ناقص است.

Revoke و Incident route

Contact، Detection، Containment، Evidence preservation، Notification route، Affected-pack search، Credential/key rotation، Revoke و Post-incident review را آماده کنید. اگر Transform ناقص یا Recipient خارج Scope شد، Authorization/Lease/Access باید قابل ابطال باشد؛ فقط ارسال ایمیل کافی نیست.

Decision gate چندامضایی، نه Approval نمایشی

Reviewسؤال محدود
PrivacyPurpose/Minimisation/Risk/rights مسیر دارد؟
SecurityThreat/Access/Egress/Incident کنترل شده؟
Data ownerSource/authority/classification درست است؟
Legal/qualifiedApplicability/basis/transfer/contract چگونه تعیین شد؟
Test ownerUtility/Oracle/Scope برای Objective کافی است؟
ApproverDecision/conditions/expiry/exception روشن است؟

Decision می‌تواند `HOLD / REJECT / CONDITIONALLY_AUTHORIZE / AUTHORIZE` باشد. Dissent، Condition، Exception و Evidence pack حفظ شود. QA می‌تواند Evidence فنی بدهد؛ نباید خود را وکیل، DPO، HIPAA expert یا Authority همهٔ نقش‌ها معرفی کند.

Exception محدود و منقضی‌شونده

اگر کم‌ریسک‌ترین Strategy نیاز تست را برآورده نکرد، Exception باید Reason، Alternatives، Residual risk، Scope، Owner، Approver، Conditions، Monitoring، Expiry و Exit plan داشته باشد. «Deadline نزدیک است» مجوز خام نیست. Exception دائمی، Policy تازه‌ای است که Review خودش را می‌خواهد.

Schema/Policy/Model change مجوز را بی‌اثر می‌کند

Field تازه، Transform policy، Model/Prompt، Recipient، Environment، Release model یا Auxiliary data تازه می‌تواند Findings را تغییر دهد. Change event باید Reassessment و Affected Pack/Run/Decision analysis را Trigger کند. نسخهٔ قبلی را Silent edit نکنید.

Correction و Reissue

Change log، Affected packs/runs/decisions، Correction، Reissue، Recipient notice و Archive را ثبت کنید. اگر Datasetی که «Synthetic امن» نامیده شده مشتق از دادهٔ واقعی یا دارای Memorization یافت شد، Label، Authorization، دسترسی و تصمیم‌های مبتنی بر آن باید بررسی/ابطال شوند.

قالب Test Data Privacy Use Authorization

Identity: authorization/dataset/version/status/owner/asOf/review/expiry
Request: purpose/objective/properties/population/volume/environment/recipients/duration/output
Applicability: jurisdictions/roles/subjects/locations/transfers/contracts/rules/reviewer
Inventory: systems/stores/fields/free text/files/logs/backups/caches/exports/derivatives
Classify: personal/special/health/financial/credentials/direct/quasi/sensitive/secret/unknown
Purpose: original/test/compatibility/basis/notice/consent/secondary use/minimum dimensions
Source: family/snapshot/provenance/custodian/authority/integrity/freshness/schema/gaps
Transform: policy/direct/quasi/text/files/consistency/collision/relation/reversibility/failure
Synthetic: basis/training/prompt/model/seed/memorization/neighbor/rare/membership/provenance
Risk: threat/recipient/auxiliary/singling/link/inference/membership/rare/time/threshold/assessor
Context: release/enclave/network/download/query/copy/egress/monitoring/contracts/training
Utility: schema/domain/relation/scenario/distribution/edges/sequence/performance/oracle
Security: identity/MFA/access/SoD/encryption/key/scan/vulnerability/audit/alert/break-glass
Provision: manifest/namespace/lease/destination/channel/checksum/receipt/run/no local/prod write
Lifecycle: retention/hold/expiry/revoke/cleanup/delete coverage/backups/evidence/restore/reassess
Incident: contact/detect/contain/evidence/notify/search/rotate/revoke/review
Decision: privacy/security/data/legal/test reviews/approver/decision/conditions/exception/dissent
Correction: change/affected packs-runs-decisions/correction/reissue/notice/archive
Limits: no anonymity/compliance/legal/zero-risk/utility/security/production/vendor/person proof

آزمایشگاه آفلاین Checkout ایرانی

Fixture کاملاً ساختگی و قطع از شبکه است: Order، PaymentAttempt، PSP Stub، Callback، Ledger، Reconciliation و Notification جعلی؛ Timeout پیش/پس از Fake commit، Retry، Duplicate، Late و Reordered event. Tenant/Order/Attempt/Event/Run/Build/Data/Dataset/Authorization/Decision شناسه‌های جعلی‌اند. Source از Ruleهای دستی ساخته شده و هیچ شخص/Production/Training dataset واقعی در آن نیست.

پول canonical فقط IRR ساختگی و «تومان» Presentation برچسب‌خورده است؛ ارقام فارسی/عربی/لاتین، ی/ی، ک/ک، ZWNJ و Bidi آزمون می‌شوند. Instantها UTC، نمایش `Asia/Tehran` و جلالی فقط Presentation است. هیچ شبکه، سازمان/فرد/کاربر/بیمار/سفارش/پرداخت/PSP/بانک/پول واقعی، PII/PHI، نام، کد ملی، موبایل، ایمیل، IP، حساب، PAN، CVV2، OTP، Cookie، Token، Credential، Log یا Screenshot واقعی وجود ندارد؛ توصیهٔ حقوقی/مالی/بانکی/سلامت/امنیت/Privacy نیست.

Checker سطحی چه می‌بیند؟

Fixture فقط پنج پرچم Masked، Synthetic label، Subset، Encryption و Least privilege دارد. Checker نام‌محور بدون دیدن Purpose/Context/Risk نتیجه می‌دهد:

fixture: SYN-TEST-DATA-PRIVACY-USE-01
superficial: PRIVACY_COMPLIANT

ممیزی ساختاری چه یافت؟

Validator بدون وابستگی خارجی، ۲۰۰ کنترل یکتای Identity، Request، Applicability، Inventory، Classification، Purpose، Source، Transform، Synthetic، Risk، Context، Utility، Security، Provision، Lifecycle، Incident، Decision، Correction و Limits را بررسی کرد. همه در Fixture سطحی غایب بودند:

uniqueStructuralControls: 200
audit: HOLD-200
independentNoRealPersonDataRule: PASS

قاعدهٔ ۲۰۱ام مستقل بود: `realPersonData=false` و به‌درستی Pass شد. پس ۲۰۰ Finding واقعی است؛ کنترل تکراری برای بزرگ‌کردن عدد وجود ندارد.

نسخهٔ اصلاح‌شده چه می‌گوید؟

پس از Pin کردن تمام قراردادهای ساختگی، نتیجه صفر شد:

corrected: READY_FOR_TEST_DATA_PRIVACY_USE_REVIEW-0
notProof: anonymisation | lawful processing | GDPR/HIPAA applicability/compliance |
          security | utility | zero re-identification risk | legal advice

صفرشدن فقط آمادگی ساختاری برای Review است؛ Anonymous بودن، Lawfulness، Applicability/Compliance، Security، Utility، نبود بازشناسایی یا نظر حقوقی را ثابت نمی‌کند.

ضدالگوهای حریم خصوصی دادهٔ تست

  • Production copy به‌عنوان سریع‌ترین Default.
  • هر استفادهٔ Production را «نقض مستقیم» نامیدن بدون Applicability.
  • GDPR برای هر شهروند/شرکت دنیا.
  • HIPAA برای هر داده یا اپ سلامت.
  • Consent به‌عنوان تنها basis.
  • Masking مساوی Anonymisation.
  • Pseudonymised مساوی خارج از Personal data.
  • Encryption مساوی De-identification.
  • Subset مساوی Privacy.
  • Synthetic label مساوی ریسک صفر.
  • AI synthetic بدون Training/Prompt review.
  • حذف نام و ایمیل به‌عنوان پایان کار.
  • نادیده‌گرفتن Quasi-identifier/rare rows.
  • Regex فقط روی Tableهای اصلی.
  • Free text/file/log/backup خارج Inventory.
  • Unknown field به‌عنوان non-sensitive.
  • Realistic به‌عنوان Requirement.
  • کپی کامل برای یک Edge case.
  • Transform success بدون coverage denominator.
  • Fail-open روی Schema drift.
  • Referential integrity به‌عنوان Privacy proof.
  • Threshold پس از دیدن Result.
  • Risk assessment بدون Recipient/context.
  • مجوز Enclave برای Download عمومی.
  • Assessment بی‌انقضا.
  • Least privilege بدون Effective-access test.
  • Test environment به‌عنوان مرز کم‌خطر.
  • Copy دستی/Notebook/CI artifact بدون Manifest.
  • Retention بدون Start event.
  • Delete فقط در Primary DB.
  • Approval یک نفر برای تمام Roleها.
  • Deadline به‌عنوان Exception دائمی.
  • Silent edit Policy/Authorization.
  • QA به‌عنوان تأییدکنندهٔ انطباق حقوقی.
  • Vendor claim به‌عنوان Evidence.
  • Risk/Privacy score برای امتیازدادن به فرد.

چک‌لیست Authorization Owner

  • Authorization/Dataset/Version/Status/Expiry روشن است.
  • Purpose/Objective/Properties/Recipients/Environment محدود است.
  • Applicability/roles/transfers/contracts Reviewer دارد.
  • Inventory تمام Store/File/Log/Backup/Derivative را می‌بیند.
  • Direct/Quasi/Sensitive/Secret/Unknown class جداست.
  • Original/Test purpose و Secondary use بررسی شده است.
  • Field/Row/Precision/History کمینه است.
  • Source family/snapshot/provenance/authority Pin شده است.
  • Transform policy و Failure handling نسخه‌دار است.
  • Text/File/Log و Schema drift Fail closed است.
  • Synthetic basis/training/prompt/model/seed روشن است.
  • Memorization/neighbor/rare/membership بررسی شده است.
  • Recipient/auxiliary/release/time در Threat model است.
  • Singling/linkability/inference/membership سنجیده شده است.
  • Method/threshold/assessor/expiry پیشاپیش Pin است.
  • Privacy و Utility Validator مستقل‌اند.
  • Identity/MFA/access/SoD/encryption/key/audit/alert آزمون شده است.
  • Manifest/Lease/Destination/Receipt/Run binding کامل است.
  • Local copy/Production write/Egress policy روشن است.
  • Retention start/period/hold/expiry/revoke تعریف شده است.
  • Delete coverage/backups/evidence/restore رفتار دارد.
  • Incident contact/contain/notify/search/rotate آماده است.
  • Privacy/Security/Data/Legal/Test reviews جداست.
  • Decision/Conditions/Exception/Dissent ثبت شده است.
  • Change/Reassessment/Correction/Reissue/Affected analysis وجود دارد.
  • NotProof و no-person-scoring صریح است.

Pilot سی‌روزه Privacy Use Authorization

  1. روز ۱–۷: یک Test objective کم‌خطر، Data flow/Inventory و کپی‌های فعلی را بدون گسترش دسترسی کشف کنید؛ Stop-the-bleeding برای Exportهای بی‌مالک.
  2. روز ۸–۱۵: Request/Applicability/Classification و کم‌ریسک‌ترین Strategy را روی Fixture ساختگی طراحی و Validator مستقل بسازید.
  3. روز ۱۶–۲۳: Pack محدود را در Destination کنترل‌شده با Lease/Egress/Deletion drill و Reviews لازم Pilot کنید.
  4. روز ۲۴–۳۰: Finding closure، Utility، Re-identification assumptions، Cleanup/restore و Incident tabletop را مرور و `KEEP / ADAPT / STOP` ثبت کنید.

Metricهای سیستم: درصد Pack با Authorization معتبر، Unknown classification aging، Transform coverage/failure، Exception age، Access revocation latency، Cleanup coverage و Reassessment overdue. «تعداد رکورد Mask شده»، «صفر Incident گزارش‌شده» یا امتیاز کارمند بدون Denominator/Countermetric می‌تواند کنترل نمایشی بسازد.

جمع‌بندی اجرایی

دادهٔ تست را با نام تکنیک مجاز نکنید. Purpose و Property لازم را محدود کنید؛ Applicability را به Reviewer صلاحیت‌دار بدهید؛ همهٔ کپی‌ها و مشتقات را Inventory/Classify کنید؛ کمترین Source/Transform کافی را انتخاب و Privacy/Utility را مستقل بسنجید؛ Re-identification را برای Recipient/Context/Time واقعی ارزیابی کنید؛ Authorization منقضی، Manifest/Lease، Egress، Incident، Delete evidence و Correction داشته باشید. «Masked/Synthetic/Encrypted» شروع سؤال است، نه پایان پاسخ.

پرسش‌های متداول حریم خصوصی دادهٔ تست

آیا استفاده از دادهٔ Production در محیط تست همیشه غیرقانونی است؟

پاسخ حقوقی جهانی ندارد و کپی Production نباید Default باشد. Jurisdiction، نقش‌ها، نوع داده، Purpose/basis، Notice/contract، Transfer و کنترل‌ها باید توسط افراد صلاحیت‌دار تعیین شوند. QA کم‌ریسک‌ترین Dataset کافی و Evidence فنی را فراهم می‌کند.

آیا Data Masking داده را Anonymous می‌کند؟

نه به‌طور خودکار. نتیجه به Direct/Quasi identifiers، دادهٔ کمکی، Recipient، Context، Reversibility و روش ارزیابی بستگی دارد. Masking policy باید Coverage و Risk assessment داشته باشد؛ نام ابزار یا حذف چند فیلد کافی نیست.

آیا دادهٔ Synthetic همیشه فاقد ریسک حریم خصوصی است؟

خیر. Rule-based fictional بدون ورودی شخص واقعی مرز روشن‌تری دارد؛ Model-based synthetic ممکن است Memorization، nearest-neighbor، rare-combination یا membership risk داشته باشد. Training/Prompt/Model/Output باید بررسی شود.

تفاوت HIPAA Safe Harbor و Expert Determination چیست؟

در راهنمای HHS، Safe Harbor حذف Identifierهای مشخص همراه با نبود Actual knowledge لازم را دنبال می‌کند؛ Expert Determination ارزیابی مستند فرد واجد دانش/تجربه برای ریسک بسیار کوچک در Context را می‌خواهد. Applicability و اجرای درست را متخصص صلاحیت‌دار تعیین می‌کند؛ این مقاله جای آن نیست.

اولین گام عملی برای حریم خصوصی دادهٔ تست چیست؟

از Test Data Request شروع کنید: Purpose، Objective، Propertyهای لازم، Environment، Recipient و Duration. سپس Applicability و Inventory/Classify را انجام دهید. خرید ابزار یا کپی Database پیش از فهم نیاز و کپی‌ها، مسئله را پنهان می‌کند.

دیدگاهتان را بنویسید