نشت داده CPR دانمارک؛ ۸٫۸ میلیون نفر از راه یک شرکت مجاز

اداره CPR دانمارک (CPR-administrationen)، متولی رجیستر ملی جمعیت این کشور، روز ۱۳ مهر (۵ اکتبر) اعلام کرد افراد غیرمجاز به نام، نشانی و شماره CPR حدود ۸٫۸ میلیون نفر از ثبت‌شدگان این سامانه دست یافته‌اند. به روایت نهادهای دانمارکی، نشت داده CPR دانمارک از راه رخنه به محیط این سامانه رخ نداد: مهاجمان از دسترسی قانونی یک شرکت خصوصی دانمارکی به آن سوءاستفاده کردند. برای تیم‌های مهندسی، همین جمله مهم‌ترین بخش ماجراست: دسترسی مجاز هم یک سطح حمله است، همان‌طور که در پرونده ۵۴۳٬۶۹۹ اعتبارنامه زنده در مخزن‌های عمومی GitHub دیدیم.

نشت داده CPR دانمارک چه داده‌ای و از چند نفر را در بر گرفت؟

اعلامیه CPR می‌گوید دسترسی غیرمجاز «نام، نشانی، شماره CPR و موارد دیگر» حدود ۸٫۸ میلیون ثبت‌شده را در بر گرفته است. اطلاعیه وزارت پژوهش، آموزش و دیجیتال‌سازی دانمارک تصریح می‌کند این ۸٫۸ میلیون شامل افراد زنده، مهاجرت‌کرده و فوت‌شده است.

به نوشته همین اطلاعیه، رجیستر CPR امروز حدود ۱۱ میلیون ثبت‌شده دارد؛ بنابراین این ۸٫۸ میلیون، همه ثبت‌شدگان نیست. برای مقایسه، به نوشته TechCrunch جمعیت کنونی دانمارک حدود ۶ میلیون نفر است. CPR همچنین تصریح کرده نام و نشانی افرادی که «حفاظت نام و نشانی» (navne- og adressebeskyttelse) را ثبت کرده‌اند در این دسترسی نبوده است.

روش: درخواست خودکار انبوه، نه رخنه به محیط

Datatilsynet، نهاد حفاظت از داده دانمارک، می‌گوید در گزارشی که از رجیستر CPR دریافت کرده آمده است «شمار بسیار زیادی درخواست خودکار به سامانه CPR با هدف شناسایی شماره‌های معتبر CPR» انجام شده است. یعنی الگوی حمله، شمارش (Enumeration) از راه یک کانال مجاز بوده است.

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

خط زمانی رخداد: از فعالیت نامتعارف تا اعلام عمومی

واکنش نهادهای دانمارک

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

کریستینا اگلوند (Christina Egelund)، وزیر پژوهش، آموزش و دیجیتال‌سازی دانمارک، در اطلاعیه وزارت این رخداد را «بسیار جدی» خوانده و گفته است به همین دلیل کمیته کسب‌وکار و دیجیتال‌سازی مجلس دانمارک (Folketing) را در جریان گذاشته است. نام شرکت تا زمان نوشتن این خبر منتشر نشده است.

چرا شماره CPR برای کلاهبرداران ارزش دارد

شماره CPR شناسه ملی دانمارکی‌هاست و در سرویس‌های دولتی و بانکی به کار می‌رود. به همین دلیل ترکیب نام، نشانی و شماره CPR، مصالح آماده‌ای برای مهندسی اجتماعی (Social Engineering) و جعل هویت است. وزارت در همان اطلاعیه یادآوری کرده هیچ‌کس نباید گذرواژه یا اطلاعات محرمانه را در تماس تلفنی یا ایمیل در اختیار دیگری بگذارد، حتی اگر طرف مقابل نام، نشانی و شماره CPR او را بداند؛ همان خطری که در راهنمای تشخیص پیامک‌های فیشینگ هم به آن پرداخته‌ایم.

درس مهندسی: خوانش تحریریه DevNA

این بخش خوانش تحریریه DevNA است، نه بخشی از اعلام CPR یا Datatilsynet. اما الگوی ماجرا برای هر تیمی که داده را از راه API به شریک تجاری می‌دهد آشناست:

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

این الگو در راهنمای OWASP Top 10 زیر دو عنوان آشنا می‌نشیند: «کنترل دسترسی ناقص» (A01) و «شکست در ثبت رویداد و هشدار» (A09). اگر هنوز با سطوح دسترسی در API کار نکرده‌اید، تفاوت REST و GraphQL و gRPC نقطه شروع خوبی است.