هش‌کردن شماره تلفن، مشتری را ناشناس نمی‌کند

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

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

یک فهرست صدتایی، محدودیت هش ساده را نشان می‌دهد

صد نشانی ساختگی از user01@example.invalid تا user100@example.invalid در نظر بگیرید. برای هرکدام هش SHA-256 بسازید. کسی که همین صد نامزد را می‌شناسد، لازم نیست تابع هش را معکوس کند: صد ورودی معلوم را هش می‌کند و خروجی‌ها را با فایل مقایسه می‌کند. در آزمون آموزشی محلی ما، هر صد مقدار از همین فهرست بازیابی شد؛ نه با شکستن الگوریتم، بلکه با امتحان‌کردن ورودی‌های ممکن.

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

گزارش ENISA درباره نام‌مستعارسازی حمله واژه‌نامه‌ای، جست‌وجوی فراگیر و حدس مبتنی بر اطلاعات قبلی را از هم باز می‌کند. مسئله ما نیز همین تفاوت است: یک‌طرفه‌بودن تابع با غیرقابل‌حدس‌بودن ورودی یکی نیست. آزمایش دفاعی را فقط با داده ساختگی یا داده‌ای انجام دهید که مجوز صریح بررسی آن را دارید.

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

ناشناس‌سازی و نام‌مستعارسازی دو ادعای متفاوت‌اند

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

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

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

پیش از انتخاب روش، دلیل نگه‌داشتن شناسه را بپرسید

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

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

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

پیوند مجاز را در یک مثال کوچک مشخص کنید

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

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

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

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

کلید محرمانه چه چیزی را تغییر می‌دهد؟

HMAC علاوه بر پیام، کلید محرمانه می‌گیرد؛ این سازوکار در RFC 2104 تعریف شده است. برای سناریوی این مقاله، HMAC-SHA-256 با کلید تصادفی محافظت‌شده یک گزینه برای بررسی است. مثال‌های الگوریتمی قدیمی آن سند را به‌عنوان توصیه امروز کپی نکنید. ساخت تابع خانگی با چسباندن کلید و متن هم جای استفاده از کتابخانه معتبر را نمی‌گیرد.

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

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

مستندات Google Cloud هش کلیددار یک‌طرفه را از رمزگذاری برگشت‌پذیر جدا می‌کند. گزینه تنظیم زمینه در جدول آن خدمت برای AES-SIV و رمزگذاری حافظ قالب آمده، نه گزینه HMAC آن رابط. طرح دامنه‌بندی ما یک پیشنهاد معماری جداست؛ نام یک قابلیت محصول را به روشی دیگر تعمیم ندهید. استناد، توصیه خرید یا ادعای دسترسی به خدمت نیست.

باقیِ ردیف ممکن است نام شخص را دوباره لو بدهد

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

راهنمای نهایی NIST SP 800-188 حذف شناسه مستقیم را کنار رسیدگی به شناسه‌های غیرمستقیم و انتخاب شیوه اشتراک داده قرار می‌دهد. بنابراین بازبینی ما باید کل بسته خروجی را ببیند. در صورت کفایت برای سؤال، زمان را به بازه تبدیل کنید، محل را کلی‌تر کنید یا شرح آزاد غیرضروری را کنار بگذارید؛ سپس افت فایده تحلیل را بسنجید.

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

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

فایل آماده ارسال را با آزمون‌های مشخص تحویل بگیرید

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

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

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

پایان عمر شناسه را هم پیش از ارسال تعیین کنید

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

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

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

یادداشت منابع — بررسی‌شده در ۲۷ سپتامبر ۲۰۲۶

مثال صد نشانی ساختگی و آزمون برابری درون دامنه و تفاوت میان دامنه‌ها با کتابخانه رمزنگاری Node.js اجرا شدند؛ این‌ها آزمون آموزشی‌اند، نه ارزیابی امنیت محصول یا ناشناس‌بودن داده واقعی. جدول‌ها، معماری و پیشنهادهای پذیرش، تحلیل ژرف هستند. متن جای بررسی متخصص امنیت و الزامات حقوقیِ کاربرد و کشور مربوط را نمی‌گیرد.

• ICO، نام‌مستعارسازی — راهنمای جاری بریتانیا بدون تاریخ ثابت در صفحه، با هشدار بازنگری پس از تغییر قانون؛ دیده‌شده در تاریخ بررسی.
• ENISA، روش‌ها و رویه‌های نام‌مستعارسازی — تاریخ انتشار صفحه ۳ دسامبر ۲۰۱۹؛ گزارش پیوست با تاریخ نوامبر ۲۰۱۹. مبنای فنی خطر حدس و پیوند.
• NIST SP 800-188 — نسخه نهایی سپتامبر ۲۰۲۳؛ راهنمای داده‌های دولتی، نه گواهی یک محصول تجاری.
• RFC 2104، تعریف HMAC — فوریه ۱۹۹۷، سند اطلاعاتی؛ استناد به سازوکار کلیددار، نه تأیید الگوریتم‌های قدیمی مثال آن.
• Google Cloud، نام‌مستعارسازی — آخرین به‌روزرسانی درج‌شده ۲۴ سپتامبر ۲۰۲۶؛ تفاوت هش یک‌طرفه، رمزگذاری برگشت‌پذیر و دامنه گزینه زمینه در محصول.