حریم خصوصی بر اساس طراحی

حریم خصوصی با طراحی (GDPR)

1) درباره چیست و چرا

حفظ حریم خصوصی توسط طراحی (PbD) اصلی است که طبق آن حفظ حریم خصوصی از همان ابتدا در یک محصول تعبیه شده است: در نیازهای تجاری، معماری، کد، فرایندها و عملیات. از نظر GDPR، این امر در «حریم خصوصی با طراحی و به طور پیش فرض» آشکار می شود (به حداقل رساندن هزینه ها، تنظیمات پیش فرض تا حد امکان خصوصی، شفافیت و پاسخگویی).

• به حداقل رساندن جمع آوری و پردازش اطلاعات شخصی (PD).
• اطمینان از قانونی بودن، شفافیت، صحت، محدودیت اهداف و مهلت.
• کاهش خطرات (فنی و قانونی)، ساده سازی ممیزی و اثبات انطباق.

2) نقش GDPR، چارچوب قانونی و اصول

2. 1 نقش ها

کنترل کننده-تعریف اهداف/ابزار پردازش.
پردازنده-پردازش اطلاعات شخصی از طرف کنترل تحت قرارداد DPA.
موضوع داده: فردی که اطلاعات شخصی متعلق به او است.
DPO (افسر حفاظت از داده ها): در صورت تقاضا - نظارت و مشاوره مستقل.

2. 2 دلایل قانونی (انتخاب و سند)

رضایت، قرارداد، منافع قانونی، وظیفه قانونی، منافع حیاتی، وظیفه عمومی. برای هر - هدف، داده ها، نگهداری، لغو (برای رضایت).

2. 3 اصول پردازش (ماده 5)

قانون، انصاف، شفافیت

محدودیت هدف

به حداقل رساندن داده ها

دقت اندازه گیری

محدودیت ذخیره سازی

صداقت و محرمانه بودن

مسئولیت پذیری - توانایی اثبات انطباق.

3) فرآیند PbD در SDLC (چارچوب مرجع)

1. شروع: تدوین اهداف پردازش و زمینه های قانونی، تخصیص صاحبان داده ها و نقطه DPO.
2. نقشه برداری از داده ها (نقشه برداری داده ها): منابع → زمینه → مدل محرمانه → که در آن جریان → که می خواند → که در آن ذخیره می شوند → مدت.
3. ارزیابی ریسک/DPIA: LINDDUN-مدل تهدیدات حریم خصوصی، ارزیابی تاثیر، اقدامات کاهش.
4. راه حل های معماری: انتخاب حداقل سازی، pseudonymization، رمزگذاری، طرح های تمایز.
5. مورد نیاز برای UX/consents/notifications: متون روشن، رضایت دانه، تنظیم پیش فرض.
6. پیاده سازی: پیش فرض های خصوصی، تله متری امن، ورود به سیستم بدون راز/PII.
7. تأیید: تست های حریم خصوصی، تجزیه و تحلیل استاتیک، تست های واحد خصوصی، پروتکل های DPIA.
8. عملیات: فرآیندهای DSAR، نگهداری و استقرار، نظارت بر حادثه، بررسی فروشندگان.
9. بررسی منظم: هنگام تغییر اهداف/فن آوری، DPIA را دوباره انجام دهید.

4) الگوهای مهندسی PbD

4. 1 به حداقل رساندن و تجزیه

فقط فیلدهای مورد نیاز را جمع آوری کنید از پروفایل های پیشرفته استفاده کنید.
شناسه و محتوای جداگانه: کلید پیوند را به طور جداگانه ذخیره کنید (نشانه/مرجع).

4. 2 نام مستعار و ناشناس

نام مستعار - شناسه واقعی را به طور جداگانه ذخیره کنید. لایه کاری نشانه را می بیند.
ناشناس سازی: استفاده از k-anonymity، l-diversity، t-closure ؛ برای تجزیه و تحلیل - حریم خصوصی دیفرانسیل (ε -budget).

4. 3 کنترل دسترسی و جداسازی نقش

PoLP, ABAC/RBAC, تفکیک وظایف, خطوط جداگانه برای مدیران و تحلیلگران.
اون ها. اقدامات: mTLS، SSO/OIDC، نشانه های محدوده، حساب های موقت برای دسترسی به اطلاعات شخصی.

4. 4 رمزگذاری و جداسازی

در حمل و نقل: TLS 1. 3/mTLS ؛ در حالت استراحت: AEAD/پاکت + KMS/HSM.

کلید های جداگانه برای مستاجر/مجموعه داده ؛ حذف رمز ارز برای «حق فراموش شدن»

4. 5 نگهداری و حذف

سیاست های صریح TTL در هر زمینه/هدف ؛ پاکسازی خودکار در خطوط لوله ؛ حذف «دو فاز» (منطقی → فیزیکی).
برای پشتیبان گیری - کلید های جداگانه و پنجره های ذخیره سازی کوتاه برای عکس های شخصی.

4. 6 تله متری خصوصی و ورود به سیستم

پیشفرض PII نیست ؛ استفاده از نشانه/هش کردن با نمک.
ماسک کردن/نشانه گذاری فیلدهای حساس بر روی تولید کننده.

4. 7 UX حریم خصوصی و رضایت

رضایت گرانولی بر اساس طبقه بندی (تجزیه و تحلیل، بازاریابی، شخصی سازی).
«پیش فرض های خصوصی»: همه چیز مهم نیست - خاموش تا زمانی که موافقت کرد.
پاک کردن گزینه «برداشت رضایت» و اطلاع رسانی فقط در زمان استفاده جدید.

5) DPIA و LINDDUN (کوتاه)

DPIA (Data Protection Impact Assessment): مورد نیاز در معرض خطر (نظارت در مقیاس بزرگ، ارزیابی، تکنولوژی جدید). این شامل شرح پردازش، ضرورت/تناسب، ارزیابی ریسک، اقدامات کاهش است.
LINDDUN угрозы: ارتباط، شناسایی، عدم انکار، تشخیص، افشای اطلاعات، ناآگاهی، عدم انطباق. برای هر تهدید - اقدامات متقابل (به حداقل رساندن، pseudonymization، DP، شفافیت، مدیریت رضایت، حسابرسی).

6) نقل و انتقالات مرزی

مکان های ذخیره سازی/دسترسی فروشنده را شناسایی کنید.
استفاده از SCC (مقررات قراردادی استاندارد) و انجام ارزیابی تاثیر انتقال.
اقدامات فنی: رمزگذاری end-to-end، رمزنگاری مشتری برای داده های بسیار حساس، محدودیت دسترسی از راه دور.

7) فروشندگان و پردازنده (مدیریت فروشنده)

پردازنده های DPA/nested، اقدامات فنی و سازمانی، زیر پردازنده ها - تحت کنترل.

بررسی ها و ممیزی های منظم ؛ حق بازرسی ؛ برنامه صادرات اطلاعات

8) حقوق موضوع داده (DSAR)

دسترسی، اصلاح، حذف، محدودیت، قابلیت حمل، اعتراض، نه AADM (پروفایل/اتوماسیون) شی.
SLA و اتوماسیون: ردیابی درخواست، اثبات شناسایی، ورود به سیستم پاسخ.
قلاب های فنی در محصول: جستجوی سریع و صادرات توسط شناسه ؛ حذف آبشار توسط حفظ.

9) راه حل های خودکار و پروفایل (ماده 22)

اگر تصمیمات با «تاثیر قابل توجهی» به طور خودکار ساخته شده است - برای اطمینان از حق دخالت انسان، توضیح، شفافیت علائم.
مسیر ورود و نسخه مدل ؛ مکانیسم درخواست تجدید نظر.

10) امنیت پردازش (ماده 32) و حوادث (ماده 33/34)

اقدامات ریسک گرا: رمزگذاری، یکپارچگی، انعطاف پذیری، برنامه های بازیابی (RTO/RPO).
حوادث PD: → فرآیند تشخیص تریاژ → ارزیابی ریسک → اطلاع از تنظیم کننده ≤ 72 ساعت (در صورت لزوم) و افراد (در صورت خطر بالا).
playbook جداگانه، لیست تماس DPO/وکلا، قالب های اطلاع رسانی.

11) حفظ حریم خصوصی و ML/تجزیه و تحلیل

مجموعه حاکمیت داده: خط داده، مجوز/زمینه، موافقت می کند.
تکنیک ها: حریم خصوصی دیفرانسیل، یادگیری فدرال، تجمع امن، به حداقل رساندن ویژگی های.
حفاظت در برابر حملات: عضویت/وارونگی مدل - ارزیابی نشت به طور منظم، تنظیمات ε، سر و صدا/کلیپ.
داده های مصنوعی - فقط با تأیید عدم بازگرداندن افراد.

12) نمودارهای معماری (الگوها)

12. 1 «حلقه دوگانه» معماری شناسه

Loop A (PDS - Personal Data Store): اطلاعات شناسایی واقعی (RID)، دسترسی - به شدت محدود، کلید/رمزگذاری/حسابرسی.
طرح کلی B (عملیاتی): داده های کسب و کار با نشانه ؛ ارتباطات از طریق یک کارگزار توکن با محدودیت ها و ممیزی ها.

12. 2 خدمات رضایت

یک سرویس متمرکز که نسخه های رضایت و تاریخ را ذخیره می کند.
SDK: 'can _ use (category, purpose)' - در پرواز حل می شود ؛ همه چيز ثبت شده.

12. 3 سیاست های نگهداری به عنوان کد

پیکربندی YAML - موجودیت → فیلد → TTL → عمل انقضا (ناشناس/حذف/درشت).
زمانبندی کارها را انجام می دهد، گزارش دهی برای DPO در دسترس است.

13) دستور العمل های کوچک

def collect(field, purpose):
if not is_required(field, purpose):
return None # do not collect v = read_input (field)
return truncate(v, policy. max_length(field))

yaml dataset: users fields:
email: { ttl: P18M, on_expire: pseudonymize }
phone: { ttl: P12M, on_expire: delete }
session_logs: { ttl: P3M, on_expire: aggregate }
consent: { ttl: P7Y, on_expire: archive }

analytics:
default: deny legal_basis: consent scope: anonymous_metrics marketing:
default: deny legal_basis: consent scope: email,push

GET /privacy/export? subject_id=... -> zip:
- profile. json (metadata, legal basis)
- activity. ndjson (events, aggregates)
- consents. json (consent history)
- processors. json (list of processors and transfers)

14) مستند سازی و پاسخگویی

ROPA (سوابق فعالیت های پردازش) - ثبت عملیات: هدف، مبنای قانونی، دسته بندی داده ها/موضوعات، انتقال، دوره نگهداری، اقدامات.
سیاست ها: حریم خصوصی، کوکی ها، اطلاعیه های اطلاعات در محصول (به زبان ساده).
آموزش کارکنان و بررسی سالانه.

15) خطاهای مکرر

جمع آوری «فقط در مورد» و ذخیره سازی «برای همیشه».
رضایت به عنوان تنها زمین، اگر چه قرارداد/منافع مشروع مناسب است.
«خالی» آگهی کوکی بدون سوئیچ واقعی.
بدون نقشه برداری داده ها و برای DSAR آماده نیست.
سیاهههای مربوط با PII، پشتیبان گیری محافظت نشده، مخلوط کردن REED و داده های عملیاتی.
هیچ کنترلی بر تامین کنندگان و نقل و انتقالات مرزی وجود ندارد.

16) چک لیست

• هدف از پردازش و اساس قانونی تعیین می شود ؛ به روز شده توسط ROPA.
• نقشه برداری داده ها و DPIA انجام (در صورت لزوم).
• minimization اجرا، aliasing، رمزگذاری (در مسیر/در حالت استراحت).
• Consents دانه ای هستند، با UX روشن ؛ پیش فرض ها خصوصی هستند.
• شما سیاست های نگهداری را به عنوان کد تنظیم کرده اید ؛ حذف/ناشناس بررسی شده است.
• سیاهههای مربوط/تله متری - بدون PII ؛ ماسک امکان پذیر است.
• DSAR قلاب و صادرات آماده شده است.
• آموزش تیم و تایید DPO به پایان رسید.

• بررسی سه ماهه تجدید نظر و دلایل قانونی.
• ممیزی پردازنده/زیر پردازنده دوره ای.
• نظارت بر حوادث و آمادگی برای اطلاع رسانی ≤ 72 ساعت.
• تجدید نظر در DPIA با تغییرات فرآیند/تکنولوژی.
• ذخیره سازی مصنوعات انطباق (DPIA، ROPA، گزارش های آزمون).

17) سوالات متداول

س: آیا ممکن است به طور کامل «فرار» از رضایت ؟

A: گاهی اوقات بله (قرارداد/وظیفه قانونی/منافع قانونی)، اما تنها زمانی که به شدت لازم است و با ارزیابی تعادل منافع. بازاریابی و تجزیه و تحلیل غیر انتقادی - اغلب نیاز به رضایت.

س: آیا تحریم کافی است ؟

A: نه، هنوز اطلاعات شخصی است. برای خروج از حوزه GDPR، شما نیاز به ناشناس سازی قابل اعتماد (بررسی برای عدم امکان شناسایی مجدد).

س: در مورد ML و شخصی سازی چیست ؟

A: به حداقل رساندن ویژگی ها، استفاده از روش DP/فدرال، تصمیم گیری ورود به سیستم، اطمینان از حق مداخله انسان و غیر پروفایل.

س: چه کاری باید انجام دهید زمانی که کسب و کار و حریم خصوصی درگیری ؟

A: طراحی مجدد مجموعه (پروفایل پیشرفته)، تغییر به aggregates/synthetics، ارزیابی مجدد مبنای قانونی، ارائه گزینه بدون ردیابی.

• «مدیریت مخفی»
• «رمزگذاری در حالت استراحت»
• «در رمزگذاری حمل و نقل»
• «گزارش های حسابرسی و تغییر ناپذیر»
• «ثبت و بررسی درخواستها»
• «مدیریت کلید و چرخش»