توسعه نرم‌افزار سازگار با KVKK و GDPR: چک‌لیست از معماری تا تست

حفاظت از داده‌های شخصی اغلب به عنوان موضوعی مربوط به دپارتمان حقوقی در نظر گرفته می‌شود؛ متن‌های آگاهی‌رسانی نوشته می‌شوند، بندی به قرارداد اضافه می‌شود و کار تمام‌شده تلقی می‌گردد. با این حال، بیشتر اصول الزامی توسط مقررات باید در معماری نرم‌افزار بازتاب یابند. این مقاله اصول مشترک قوانین KVKK شماره ۶۶۹۸ در ترکیه، قانون حفاظت از داده‌های شخصی در قبرس شمالی و GDPR در اتحادیه اروپا را به یک چک‌لیست برای تیم نرم‌افزاری تبدیل می‌کند. برای ارزیابی حقوقی، حتماً باید از پشتیبانی متخصصان استفاده شود؛ در اینجا جنبه‌های فنی مورد بحث قرار می‌گیرد.

1. انبار داده: کدام فیلد داده شخصی است؟

برای هر جدول و ستون در ساختار پایگاه داده، اطلاعات مربوط به «آیا داده شخصی است، حساس است، با چه هدفی پردازش می‌شود و چه مدت نگهداری می‌شود» باید ثبت شود. این انبار، مبنای تکالیف ثبت‌نام مشابه VERBİS و درخواست‌های صاحبان داده است. روش عملی: نظرات ستونی در ساختار و یک جدول جداگانه برای فرهنگ لغت داده‌ها.

comment on column employees.national_id is 'kişisel veri; amaç: bordro; saklama: iş ilişkisi + yasal süre';
comment on column employees.health_note is 'özel nitelikli; amaç: işyeri hekimi; erişim: yalnızca sağlık rolü';

2. محدودسازی هدف و به حداقل رساندن داده‌ها

افزودن یک فیلد در طراحی فرم با این فرض که «شاید روزی به کار آید»، رایج‌ترین آغازگر نقض مقررات است. هر فیلد باید هدفی داشته باشد؛ فیلدهای بی‌هدف نباید جمع‌آوری شوند. برای فیلدهای حساسی مانند موقعیت مکانی، عکس و داده‌های بیومتریک، توجیهی جداگانه و کنترل دسترسی مجزا مورد نیاز است.

3. مدت نگهداری و حذف خودکار

مدت نگهداری نباید در یک سند، بلکه باید در سیستم تعریف شود. وظایف ناشناس‌سازی یا حذف خودکار برای رکوردهای منقضی‌شده ایجاد می‌شود؛ فرایند حذف به‌گونه‌ای برنامه‌ریزی می‌شود که شامل نسخه‌های پشتیبان نیز بشود (باید با مدت نگهداری نسخه پشتیبان سازگار باشد).

4. کنترل دسترسی: در سطح پایگاه داده

کاربرد قابل اعتماد اصل «فقط افراد مجاز دسترسی دارند»، زنده بودن این قانون در داده‌هاست. با استفاده از قابلیت PostgreSQL Row Level Security، هر پرس‌وجو بر اساس محدوده مجوز کاربر فیلتر می‌شود؛ خطایی در کد برنامه نمی‌تواند داده‌های غیرمجاز را فاش کند. دسترسی‌های مدیر نیز باید زمان‌دار و دارای توجیه باشند.

5. رمزنگاری: در حال انتقال و در حالت ذخیره

• استفاده از پروتکل TLS در حال انتقال الزامی است؛ پروتکل‌ها و رمزهای قدیمی غیرفعال شوند.
• رمزنگاری در سطح دیسک یا پایگاه داده در حالت ذخیره؛ برای فیلدهای حساس می‌توان رمزنگاری ستونی اضافی را بررسی کرد.
• رمزهای عبور هرگز به صورت متن ساده ذخیره نمی‌شوند، بلکه با الگوریتم‌های هشینگ به‌روز و کند (مانند Argon2 یا bcrypt) نگهداری می‌شوند.
• مدیریت کلید: کلیدها در کد و انبار ذخیره نمی‌شوند، بلکه در یک سیستم مدیریت اطلاعات محرمانه جداگانه نگهداری می‌شوند.

6. ثبت رویداد (لاگ) و رد پای حسابرسی

اینکه چه کسی، چه زمانی و با چه هدفی به داده‌های شخصی دسترسی داشته است باید ثبت شود. با این حال، لاگ‌ها نیز حاوی داده‌های شخصی هستند: محتوای لاگ نباید حاوی داده‌های غیرضروری (مانند شماره ملی کامل) باشد و مدت نگهداری و مجوز دسترسی خود لاگ‌ها باید تعریف شود.

سازگاری یک متن نیست، بلکه یک رفتار است: سیستم داده‌ها را به اندازه نیاز جمع‌آوری می‌کند، به اندازه نیاز نگه می‌دارد، به فرد مناسب نشان می‌دهد و اقدامات خود را ثبت می‌کند.

7. آمادگی فنی برای حقوق صاحبان داده

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

8. اشخاص ثالث و انتقال داده

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

9. رویه توسعه امن

استانداردهای OWASP Top 10 و OWASP ASVS پوشش‌دهنده آسیب‌پذیری‌های برنامه‌ای هستند که منبع اصلی نشت داده‌های شخصی محسوب می‌شوند: کنترل دسترسی شکسته، تزریق، طراحی ناامن، پیکربندی اشتباه. بررسی کد، اسکن وابستگی‌ها و تست خودکار خط مشی‌های مجوز، بررسی منظم این موارد را تضمین می‌کنند.

10. داده‌های تست و دمو

کپی کردن داده‌های شخصی واقعی در محیط تست، یک عادت رایج و پرخطر است. محیط‌های تست باید با داده‌های مصنوعی یا ناشناس‌سازی شده کار کنند؛ این رویکرد همچنین دسترسی غیرضروری تیم توسعه را حذف می‌کند.

چک‌لیست خلاصه

1. انبار داده و طبقه‌بندی مبتنی بر ستون
2. عدم وجود فیلدهای بی‌هدف
3. مدت نگهداری در سیستم، حذف/ناشناس‌سازی خودکار
4. کنترل دسترسی در سطح پایگاه داده
5. رمزنگاری در حال انتقال و ذخیره، ذخیره امن رمز عبور
6. ثبت حسابرسی (با قوانین نگهداری خاص خود)
7. مسیر خروجی و حذف برای درخواست‌های صاحبان داده
8. انبار اشخاص ثالث و ارزیابی انتقال
9. توسعه امن مبتنی بر OWASP
10. داده‌های تست ناشناس

رضایت و آگاهی‌رسانی: چگونه در رابط کاربری نمایش داده می‌شود؟

در مواردی که مبنای حقوقی «رضایت صریح» است، ثبت رضایت باید در سیستم نگهداری شود: چه زمانی، با چه متنی، برای چه هدفی، از چه کانالی دریافت شده و در صورت پس گرفته شدن، چه زمانی انجام شده است. متن‌های آگاهی‌رسانی باید دارای نسخه باشند و نسخه دیده‌شده توسط کاربر ثبت شود. چک‌باکس‌های از پیش علامت‌گذاری‌شده، رضایت‌های ادغام‌شده با فیلدهای اجباری و الگوهای «با ادامه دادن، قوانین را پذیرفته‌اید» ممکن است رضایت را نامعتبر سازند؛ طراحی رابط کاربری باید با مشاور حقوقی بررسی شود.

به حداقل رسانی در انتقال داده و یکپارچه‌سازی‌ها

یکپارچه‌سازی‌ها اغلب با منطق «ارسال کل رکورد» راه‌اندازی می‌شوند. در حالی که سرویس پیامک تنها به شماره تلفن و متن پیام نیاز دارد، و بخش حسابداری فقط به مبلغ و مرکز هزینه محتاج است. فهرست فیلدهای ارسالی برای هر یکپارچه‌سازی مستند می‌شود؛ این فهرست پیوست فنی قرارداد پردازش داده است. در پاسخ‌های API نیز نباید فیلدهای غیرضروری برگردانده شوند: اگر برای یک صفحه فهرست شماره شناسایی لازم نیست، API نباید آن را ارائه دهد.

نمونه ثبت لاگ: عدم ثبت اطلاعات بیش از حد نیاز

// بد: اطلاعات شخصی را در لاگ ثبت می‌کند
logger.info('Personel güncellendi', { employee });

// خوب: فقط شناسه و نام فیلدهای تغییر یافته
logger.info('Personel güncellendi', { employee_id: employee.id, fields: ['phone', 'address'], actor: user.id });

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

ارزیابی تأثیر حفاظت از داده‌ها: چه زمانی لازم است؟

مقررات GDPR برای پردازش‌های پرخطر (پایش سیستماتیک، داده‌های حساس، پروفایل‌سازی در مقیاس بزرگ) ارزیابی تأثیر حفاظت از داده‌ها (DPIA) را درخواست می‌کند؛ در KVKK نیز رویکردی مشابه مبتنی بر ریسک در تصمیمات هیئت مدیره و راهنماها دیده می‌شود. از منظر تیم نرم‌افزاری، این به معنای انجام ارزیابی ریسک با تیم حقوقی پیش از آغاز طراحی در پروژه‌هایی است که شامل ردیابی موقعیت مکانی، بیومتریک یا پشتیبانی تصمیم مبتنی بر هوش مصنوعی هستند. این ارزیابی مستقیماً بر تصمیمات معماری (کدام داده جمع‌آوری نشود، پس از چه مدتی حذف شود) تأثیر می‌گذارد.

انتقال به خارج از کشور: سرور کجاست؟

سرویس‌های ابری، ارائه‌دهندگان ایمیل و ابزارهای تحلیلی ممکن است داده‌ها را در کشورهای دیگر پردازش کنند. در ترکیه، قانون KVKK انتقال به خارج از کشور را به شرایط خاصی مشروط می‌کند؛ در GDPR نیز مکانیزم‌هایی مانند تصمیمات کفایت یا بندهای استاندارد قراردادی برای انتقال به کشورهای ثالث وجود دارد. نتیجه ملموس برای تیم نرم‌افزاری: موقعیت پردازش داده‌ی هر سرویس خارجی باید در انبار داده ثبت شده باشد و تغییر موقعیت (تغییر منطقه توسط ارائه‌دهنده) به عنوان یک تغییر اساسی مدیریت شود.

آمادگی برای گزارش‌دهی حوادث

در صورت وقوع نشت داده، باید ظرف چند ساعت مشخص شود که کدام داده‌ها تحت تأثیر قرار گرفته‌اند. برای این منظور: طبقه‌بندی داده‌ها بر اساس جدول، قابل پرس‌وجو بودن ثبت‌های دسترسی و توانایی استخراج فهرست افراد تحت تأثیر ضروری است. این آمادگی شبیه به یک بدهی فنی به نظر می‌رسد؛ اما در لحظه بحران، ارزشمندترین دارایی است.

رعایت قوانین، نه یک بار بلکه به طور مستمر

هر ویژگی جدید ممکن است یک حوزه داده جدید، یکپارچه‌سازی جدید یا گزارش جدیدی را به همراه داشته باشد. چک‌لیست نباید فقط یک بار در ابتدای پروژه، بلکه باید در هر نسخه با بازنگری کوتاه اعمال شود: «آیا این نسخه داده‌های شخصی جدیدی جمع‌آوری می‌کند؟ آیا به سرویس خارجی جدیدی ارسال می‌کند؟ آیا مدت نگهداری تعریف شده است؟» سه سوال برای بیشتر نسخه‌ها کافی است.

در سیستم‌های پردازش داده‌های شخصی Cy Logic (منابع انسانی، حضور و غیاب، CRM، پورتال)، این فهرست ورودی مرحله طراحی است، نه فرمی که در پایان پروژه پر شود.