جمعآوری داده و حریم خصوصی کاربر
هر تیمی که تلمتری راه میاندازد، به یک وسوسه میرسد: همهچیز را جمع کنیم، شاید بعداً لازم شد.
استدلالش منطقی به نظر میرسد. ذخیرهسازی ارزان است، و دادهای که امروز جمع نکنید، فردا نمیشود بازسازیاش کرد.
مسئله این است که آن انبار داده سه هزینه دارد که در لحظهٔ تصمیم دیده نمیشوند: باید محافظت شود، باید توضیح داده شود، و اگر نشت کند خسارتش به اندازهٔ همان چیزی است که جمع کردهاید.
قاعدهای که همهٔ این مقاله از آن میآید: دادهٔ جمعنشده، دادهٔ نشتنشده است.
کمینهسازی، بهصورت عملی
کمینهسازی یعنی برای هر میدان داده یک سؤال: کدام تصمیم بدون این گرفته نمیشود؟
اگر جواب نداشت، جمعش نکنید. اگر جواب داشت، سؤال دوم: آیا شکل کمحساسیتتری از آن همان تصمیم را میسازد؟
نمونههایی که مکرراً پیش میآیند:
تاریخ تولد → گروه سنی. برای تحلیل رفتار، بازهٔ سنی همان کار را میکند و شناساییپذیریاش بهمراتب کمتر است.
موقعیت دقیق → شهر. اپلیکیشنی که مختصات دقیق را ثبت میکند تا بداند کاربرانش از کدام شهرند، صد برابر بیشتر از نیازش داده دارد. مگر اینکه کارکرد اصلی محصول به آن وابسته باشد، مثل بهینهسازی مسیر — و آنجا هم مدت نگهداری متفاوتی لازم دارد.
متن کامل ورودی کاربر → طول و اینکه معتبر بود یا نه. برای فهمیدن اینکه فرم کجا شکست میخورد، محتوای فیلد لازم نیست.
شمارهٔ تلفن → شناسهٔ مستعار. برای تحلیل، هیچوقت نیازی به خود شماره نیست.
شناسهٔ مستعار، و محدودیتش
شناسهٔ مستعار — یک شناسهٔ تصادفی بهجای هویت واقعی — ابزار اصلی این کار است. اما دو نکته که معمولاً گفته نمیشود:
مستعار، ناشناس نیست. اگر جدولی دارید که شناسه را به کاربر وصل میکند، داده همچنان شخصی است. این جدول باید همان سطح محافظت هویت واقعی را داشته باشد.
ترکیب چند فیلد بیضرر، شناسایی میکند. شهر، گروه سنی، و مدل دستگاه هر کدام بیضررند؛ ترکیبشان در یک شهر کوچک ممکن است به یک نفر برسد. هرچه ابعاد بیشتر، این ریسک بیشتر.
قاعدهٔ عملی: پیش از انتشار هر گزارش تجمیعی، بپرسید کوچکترین گروه در آن چند نفر است. اگر زیر یک آستانه است، آن برش را منتشر نکنید.
چیزهایی که هرگز نباید ثبت شوند
فهرست کوتاه است و رعایتش سختتر از چیزی است که به نظر میرسد:
رمز عبور، حتی در متن خطا. توکن و کلید. شمارهٔ کامل کارت و CVV. کد یکبارمصرف. محتوای پیام خصوصی. و در سامانههای درمانی، هر چیزی که به وضعیت سلامت اشاره دارد — امنیت دادهٔ بیمار.
مسئلهٔ واقعی این است که اینها معمولاً عمداً ثبت نمیشوند؛ از راه لاگ خطا وارد میشوند. یک استثنا که کل شیء درخواست را چاپ میکند، و رمز در لاگ است.
دو محافظ که کار میکنند:
پالایش در لایهٔ لاگ. فهرستی از نام فیلدهای حساس که پیش از نوشتن پوشانده میشوند، در همان لایهای که لاگ مینویسد نه در محل فراخوانی.
بررسی دورهای. یک جستوجوی ساده در لاگهای اخیر برای الگوهای شناختهشده. سالی چند بار، و همیشه چیزی پیدا میکند. جایش در دفترچهٔ اجرا است.
اصول کلیتر این بحث در ریسکهای رایج امنیتی آمده.
مدت نگهداری: تصمیمی که گرفته نمیشود
بیشتر سازمانها سیاست نگهداری ندارند، که در عمل یعنی سیاستشان «برای همیشه» است.
یک جدول سهستونی کافی است: نوع داده، مدت، و چه اتفاقی بعد از آن میافتد (حذف یا تجمیع).
نمونهای که در عمل جواب میدهد:
| داده | مدت | بعدش |
|---|---|---|
| لاگ خام درخواست | ۳۰ روز | حذف |
| رویداد محصولی با شناسهٔ مستعار | ۱۲ ماه | تجمیع بدون شناسه |
| سنجههای تجمیعی | نامحدود | — |
| ضبط جلسهٔ کاربر | ۷ روز | حذف |
نکتهای که این جدول را از یک سند به یک رویه تبدیل میکند: حذف باید خودکار باشد. سیاست نگهداریای که به کار دستی کسی وابسته است، سه ماه بعد اجرا نمیشود.
چارچوب کاملتر مالکیت و طبقهبندی داده در حاکمیت داده آمده.
ابزارهای شخص ثالث، و چیزی که با خودشان میبرند
افزودن یک قطعه کد تحلیلی به صفحه، تصمیم سادهای به نظر میرسد. در عمل سه چیز اتفاق میافتد:
دادهای که فکر میکردید داخلی است، به سرور کس دیگری میرود. کد شخص ثالث در صفحهٔ شما اجرا میشود و به هر چیزی که کاربر میبیند دسترسی دارد — امنیت سمت کاربر. و سرعت صفحه پایین میآید.
سه سؤال پیش از افزودن: چه دادهای بیرون میرود، کجا ذخیره میشود، و آیا همان سؤال با دادهای که خودتان دارید جواب داده نمیشود؟
برای سامانههای سازمانی که دادهٔ حساس دارند، جواب معمولاً یک سنجش داخلی سبک است، نه ابزار بیرونی. همان استدلالی که در اجرای مدل روی زیرساخت خودی هم برقرار است.
شفافیت، که سختترین بخش نیست
سیاست حریم خصوصیای که کسی نمیخواند، الزام حقوقی را برآورده میکند و اعتماد نمیسازد. آنچه اعتماد میسازد سه چیز است و هیچکدام گران نیست:
بگویید چه چیزی جمع میشود، به زبان ساده و نه در قالب فهرست حقوقی. بگویید چرا — یک جمله برای هر دسته. و بدهید راه خاموش کردن آنچه برای کارکرد محصول ضروری نیست.
آن سومی مهمتر از چیزی است که به نظر میرسد: تفکیک «تلمتری ضروری برای کارکرد» از «تحلیل اختیاری»، خودش شما را وادار میکند بدانید هر داده برای چیست.
و یک قاعدهٔ ساده برای تصمیمهای مرزی
وقتی مطمئن نیستید دادهای را جمع کنید یا نه، این سؤال معمولاً جواب میدهد:
اگر کاربر بپرسد «چرا این را دارید؟»، جواب در یک جمله قانعکننده است؟
اگر جواب «شاید بعداً لازم شود» است، جمعش نکنید. اگر جواب «برای اینکه بفهمیم کجا در فرایند ثبت سفارش گیر میکنید» است، جمعش کنید — و همان جمله را در سیاست حریم خصوصی بنویسید.