چطور داده‌های کاربران را در اپ ساخته‌شده با هوش مصنوعی‌تان محافظت کنید (بدون یک تیم امنیت)

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

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

همان وقت بود که قضیه برایش روشن شد: دیگر یادداشت‌های خودش را نگه نمی‌داشت. داشت یادداشت‌های دیگران دربارهٔ مشتری‌های آن‌ها را نگه می‌داشت — جزئیات سلامت، دشواری‌های شخصی، نام‌ها. اگر آن داده‌ها لو می‌رفت، شرمساری او نبود. شرمساری آن‌ها بود.

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

با توجه به اینکه واقعاً چه داده‌های کاربری نگه می‌دارید شروع کنید

بیشتر سازندگان این را دست‌کم می‌گیرند. «من فقط یک فرم ثبت‌نام دارم» معمولاً یعنی شما این‌ها را دارید:

  • آدرس‌های ایمیل — به‌اندازهٔ کافی برای اسپم کردن یا فیشینگ کسی.
  • نام‌های متصل به رفتار — اینکه چه خریدند، چه نوشتند، کی وارد می‌شوند.
  • هر چه کاربرانتان در جعبه‌های متن آزاد تایپ می‌کنند — و مردم هر چیزی را در یک فیلد یادداشت تایپ می‌کنند: شماره تلفن، جزئیات پزشکی، حقوق، گلایه از رئیسشان.

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

عادت ۱: کمتر جمع کنید

ارزان‌ترین داده برای محافظت، داده‌ای است که هیچ‌وقت جمع نکردید. پیش از محافظت از هر چیزی، فهرست را کوچک کنید.

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

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

عادت ۲: کنترل کنید چه کسی چه چیزی را می‌بیند

دو نسخه از این پرسش هست، و به هر دو نیاز دارید.

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

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

عادت ۳: این پنج پرسش را از اپ‌سازتان بپرسید

لازم نیست پاسخ‌ها را عمیقاً بفهمید. لازم است بپرسید، و پاسخ‌ها باید «بله»‌های مطمئن باشند. این‌ها را یکی‌یکی در اپ‌ساز هوش مصنوعی‌تان بچسبانید:

  1. «رمزهای عبور کاربران به‌صورت هش‌شده ذخیره می‌شوند، یا هر کسی می‌تواند بخواندشان؟» تنها پاسخ قابل قبول شامل واژهٔ «هش‌شده» است. اگر اپتان رمزهایی ذخیره می‌کند که هر کسی بتواند بخواند، همین امروز درستش کنید — معمولاً یک اصلاح تک‌پرامپتی است، و بیشتر اپ‌سازهای امروزی این را به‌طور پیش‌فرض درست انجام می‌دهند.
  2. «آیا اتصال به اپ رمزنگاری‌شده است (HTTPS)؟» دنبال قفل در مرورگر خودتان بگردید. اگر آدرس اپتان با https:// شروع می‌شود، این یکی تمام است.
  3. «اگر کسی فایل پایگاه داده را به دست می‌آورد، می‌توانست فیلدهای حساس را بخواند؟» این دربارهٔ رمزنگاری در حالت سکون است. بیشتر پلتفرم‌های هاستینگ آن را به‌طور خودکار انجام می‌دهند — به هر حال بپرسید و پاسخ را بنویسید.
  4. «کدام سرویس‌های شخص ثالث داده‌های کاربران را دریافت می‌کنند؟» ابزارهای ایمیل، تحلیلگرها، پردازشگرهای پرداخت. شما آن‌ها را حذف نمی‌کنید — دارید فهرستتان را کامل می‌کنید، چون هر سرویسی که داده‌های کاربرانتان را نگه می‌دارد بخشی از سطح مسئولیت شماست.
  5. «آیا پشتیبانی (backup) هست، و چه کسی به آن دسترسی دارد؟» پشتیبان‌ها کپی‌های داده‌های شما هستند، و کپی‌ها هم نیاز به محافظت دارند. (اگر اصلاً پشتیبان راه نینداخته‌اید، از اینجا شروع کنید.)

پاسخ‌ها را در یک سند ذخیره کنید. آن سند آغاز وضعیت امنیتی شماست، و اولین باری که مشتری‌ای — یا وکیل مشتری‌ای — بپرسد، خوشحال خواهید بود که وجود دارد.

وقتی کسی می‌گوید «داده‌هایم را حذف کن»

سرانجام کسی این را خواهد گفت، و قانون در بیشتر جاها (GDPR در اروپا، قوانین مشابه در جاهای دیگر) می‌گوید باید واقعاً انجامش دهید. همین حالا تصمیم بگیرید پاسخ شما چیست:

  • آیا می‌توانید یک کاربر و هر چیز متصل به او را حذف کنید؟ از اپ‌ساز هوش مصنوعی‌تان بخواهید این را اضافه کند — «یک اقدام مدیریتی بساز که یک کاربر و همهٔ داده‌هایش را حذف کند» — پیش از آنکه زیر فشار مهلت به آن نیاز پیدا کنید.
  • آیا حذف آن‌ها در اپ، آن‌ها را از ابزار ایمیل و تحلیلگرتان هم حذف می‌کند؟ فهرست پرسش ۴ را بررسی کنید.
  • پشتیبان‌ها مدتی همچنان آن‌ها را خواهند داشت. این طبیعی است و عموماً مشکلی ندارد — فقط بدانیدش، تا بتوانید صادقانه بگوییدش.

پاسخ دادن به یک درخواست حذف در یک روز چون آماده بوده‌اید، حرفه‌ای به نظر می‌رسد. دست‌وپا زدن به مدت دو هفته دقیقاً همان چیزی به نظر می‌رسد که هست.

صفحهٔ حریم خصوصی به زبان ساده را بنویسید

از آن متن حقوقیِ ۴٬۰۰۰ کلمه‌ایِ تولیدشده فعلاً بگذرید. پنج جملهٔ صادقانه بنویسید: چه چیزی جمع می‌کنید، چرا، چه کس دیگری به آن دست می‌زند (ابزار ایمیلتان، پردازشگر پرداختتان)، چقدر نگهش می‌دارید، و چطور درخواست حذف بدهند. آن را در /privacy بگذارید و از صفحهٔ ثبت‌نامتان به آن لینک بدهید.

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

استاندارد پایین‌تر از آن است که می‌ترسید، و بالاتر از صفر است

شما در حال دفاع در برابر دولت‌-‌ملت‌ها نیستید. دارید در برابر شکست‌های کسل‌کننده و رایج دفاع می‌کنید: یک فیلد دادهٔ باقی‌مانده که کسی به آن نیاز نداشت، یک قانون دسترسی که کسی آزمایشش نکرد، یک جدول رمز عبور که کسی فراموش کرد هشش کند. محافظت از داده‌های کاربران در این سطح یک مهارت تخصصی نیست — هر کدام از آن شکست‌ها با یک پرامپت به زبان ساده و یک آزمون پنج‌دقیقه‌ای قابل درست شدن است.

مربیِ آغاز این مطلب همهٔ این‌ها را در یک بعدازظهر انجام داد: دو فیلد بی‌استفاده را حذف کرد، آزمون دو‌حسابی را اجرا کرد (و یک نشتی گرفت — مشتری‌ها می‌توانستند نام کوچک یکدیگر را در یک منوی کشویی ببینند)، پنج پرسش را پرسید، صفحهٔ حریم خصوصی‌اش را نوشت. اپش بعدش هیچ فرقی نکرده بود. ولی وقتی دوستش پرسید «این چیز برای یادداشت‌های مشتری‌ام امن است؟»، یک پاسخ واقعی داشت.

آن بعدازظهر را بگذارید. کاربرانتان داده‌هایشان را بر پایهٔ اعتماد به شما دادند — نگه داشتنش این شکلی است.