איך להגן על נתוני המשתמשים באפליקציה שבניתם עם בינה מלאכותית (בלי צוות אבטחה)

מאמנת שאנחנו מכירים בנתה אפליקציה למעקב אחר לקוחות עם כלי לבניית אפליקציות עם בינה מלאכותית במהלך סוף שבוע. רשומות פגישות, מטרות, נקודות בקרה על התקדמות — כל מה שהיא נהגה לשמור במחברת, עכשיו ניתן לחיפוש ומאורגן. זה עבד כל כך טוב ששתי חברות-מאמנות ביקשו להשתמש בזה גם.

ואז זה היכה בה: היא כבר לא שמרה את ההערות שלה. היא החזיקה הערות של אנשים אחרים על הלקוחות שלהם — פרטי בריאות, מאבקים אישיים, שמות. אם הנתונים האלה היו דולפים, זו לא הייתה המבוכה שלה. היא הייתה שלהם.

אתם לא צריכים צוות אבטחה כדי לטפל בזה באחריות. אתם צריכים שלושה הרגלים ואת הנכונות לשאול את הכלי כמה שאלות ישירות. המדריך הזה מכסה איך להגן על נתוני המשתמשים באפליקציה שבניתם עם בינה מלאכותית, ברמה שבאמת חשובה למוצר קטן.

תתחילו מלשים לב אילו נתוני משתמש אתם באמת מחזיקים

רוב הבונים מזלזלים בזה. “יש לי רק טופס הרשמה” בדרך כלל אומר שיש לכם:

• כתובות מייל — מספיק כדי לשלוח ספאם או לעשות פישינג למישהו.
• שמות מחוברים להתנהגות — מה הם קנו, מה הם כתבו, מתי הם מתחברים.
• כל מה שהמשתמשים שלכם מקלידים בתיבות טקסט חופשי — ואנשים יקלידו כל דבר בשדה הערות: מספרי טלפון, פרטים רפואיים, משכורות, תלונות על הבוס שלהם.

קחו עשר דקות וכתבו כל פיסת מידע שהאפליקציה שלכם שומרת על אדם. לא את שדות מסד הנתונים — את המשמעות האנושית. “מייל”, “אילו תוספים הם לוקחים”, “הערות שהמאמן שלהם כתב עליהם”. הרשימה הזו היא שטח האחריות שלכם. כל השאר בפוסט הזה עוסק בלהפוך אותו לקטן ובטוח יותר.

הרגל 1: אספו פחות

הנתונים הזולים ביותר להגנה הם נתונים שמעולם לא אספתם. לפני שאתם מגינים על משהו, כווצו את הרשימה.

עברו על הרשימה שהרגע עשיתם ושאלו על כל פריט: האם אני משתמש בזה? האפליקציה של המאמנת ביקשה תאריך לידה בהרשמה כי תבנית ההרשמה של הכלי כללה אותו. היא מעולם לא השתמשה בו באף מקום. משפט אחד לכלי שלה — “תסיר את תאריך הלידה מההרשמה ותמחק את העמודה” — וקטגוריה שלמה של נתונים רגישים נעלמה.

דברים נפוצים שאפליקציות אוספות ולעולם לא משתמשות בהם: תאריכי לידה, מספרי טלפון, כתובות פיזיות, מגדר, “איך שמעת עלינו”. אם אתם לא משתמשים בזה החודש, תמיד אפשר לבקש את זה בהמשך. אתם לא יכולים לבטל דליפה.

הרגל 2: שלטו במי יכול לראות מה

יש שתי גרסאות של השאלה הזו, ואתם צריכים את שתיהן.

בתוך האפליקציה: האם משתמש אחד יכול לראות את הנתונים של משתמש אחר? אם לאפליקציה שלכם יש לקוחות ומאמנים, האם לקוח א’ יכול אי פעם לראות את ההערות של לקוח ב’? כתבנו מדריך שלם על הרשאות משתמשים באפליקציה שבניתם עם בינה מלאכותית, אבל הגרסה הקצרה: תארו את הכלל לכלי שלכם בשפה פשוטה (“מאמן רואה רק את הלקוחות שלו; לקוחות רואים רק את עצמם”) ואז בדקו את זה בעצמכם עם שני חשבונות. התחברו כמשתמש אחד, נסו להגיע לנתונים של משתמש אחר על ידי לחיצות מסביב. חמש דקות, שני חשבונות בדיקה. הבדיקה הבודדת הזו תופסת את הדליפה הנפוצה ביותר באפליקציות קטנות.

מחוץ לאפליקציה: מי יכול לראות את מסד הנתונים עצמו? זה אתם, פלטפורמת הכלי שלכם, וכל מי ששיתפתם איתו פרטי התחברות. וזה מביא אותנו לשאלות.

הרגל 3: שאלו את הכלי שלכם את חמש השאלות האלה

אתם לא צריכים להבין את התשובות לעומק. אתם צריכים לשאול, והתשובות צריכות להיות “כן” בטוחים. הדביקו את אלה לכלי שלכם אחת בכל פעם:

1. “האם סיסמאות המשתמשים מאוחסנות מגובבות (hashed), או שכל אחד יכול לקרוא אותן?” התשובה היחידה המקובלת כוללת את המילה “hashed”. אם האפליקציה שלכם שומרת סיסמאות שכל אחד יכול לקרוא, תקנו את זה היום — זה בדרך כלל תיקון של הנחיה אחת, ורוב הכלים המודרניים עושים את זה נכון כברירת מחדל.
2. “האם החיבור לאפליקציה מוצפן (HTTPS)?” חפשו את המנעול בדפדפן שלכם עצמו. אם הכתובת של האפליקציה שלכם מתחילה ב-https://, סיימתם עם זו.
3. “אם מישהו היה משיג את קובץ מסד הנתונים, האם הוא היה יכול לקרוא את השדות הרגישים?” זה עניין של הצפנה במנוחה. רוב פלטפורמות האחסון מטפלות בזה אוטומטית — שאלו בכל זאת וכתבו את התשובה.
4. “אילו שירותי צד שלישי מקבלים נתוני משתמש?” כלי מייל, אנליטיקה, מעבדי תשלומים. אתם לא מסירים אותם — אתם הופכים את הרשימה שלכם לשלמה, כי כל שירות שמחזיק את הנתונים של המשתמשים שלכם הוא חלק משטח האחריות שלכם.
5. “האם יש גיבוי, ומי יכול לגשת אליו?” גיבויים הם עותקים של הנתונים שלכם, ועותקים צריכים הגנה גם הם. (אם לא הקמתם גיבויים בכלל, תתחילו כאן.)

שמרו את התשובות במסמך. המסמך הזה הוא תחילת מצב האבטחה שלכם, ותשמחו שהוא קיים בפעם הראשונה שלקוח — או עורך הדין של לקוח — שואל.

כשמישהו אומר “תמחק את הנתונים שלי”

מישהו בסופו של דבר יעשה זאת, והחוק ברוב המקומות (GDPR באירופה, חוקים דומים במקומות אחרים) אומר שאתם חייבים באמת לעשות את זה. תחליטו עכשיו מה התשובה שלכם:

• האם אתם יכולים למחוק משתמש אחד וכל מה שמחובר אליו? בקשו מהכלי שלכם להוסיף את זה — “תבנה פעולת ניהול שמוחקת משתמש ואת כל הנתונים שלו” — לפני שאתם צריכים את זה תחת לחץ זמן.
• האם מחיקתם באפליקציה גם מסירה אותם מכלי המייל ומהאנליטיקה שלכם? בדקו את הרשימה שלכם משאלה 4.
• גיבויים עדיין יכילו אותם לזמן מה. זה נורמלי ובדרך כלל בסדר — רק דעו את זה, כדי שתוכלו לומר את זה בכנות.

לענות על בקשת מחיקה תוך יום כי התכוננתם נראה מקצועי. להתרוצץ במשך שבועיים נראה בדיוק כמו מה שזה.

כתבו את עמוד הפרטיות בשפה פשוטה

דלגו על 4,000 המילים של ז’רגון משפטי מיוצר לעת עתה. כתבו חמישה משפטים כנים: מה אתם אוספים, למה, מי עוד נוגע בזה (כלי המייל שלכם, מעבד התשלומים שלכם), כמה זמן אתם שומרים את זה, ואיך לבקש מחיקה. שימו את זה ב-/privacy וקשרו אותו מעמוד ההרשמה שלכם.

זה לא ייעוץ משפטי, ואם אתם מטפלים בנתונים באמת רגישים — בריאות, ילדים, כספים — תוציאו את הכסף על שעה עם עורך דין. אבל עמוד ברור וכן מנצח עמוד מרשים-למראה שאף אחד לא יכול לקרוא, וכתיבתו מאלצת אתכם באמת לדעת את התשובות שלכם.

הרף נמוך ממה שאתם חוששים, וגבוה מאפס

אתם לא מתגוננים מפני מעצמות. אתם מתגוננים מפני הכשלים המשעממים והנפוצים: שדה נתונים שנשאר שאף אחד לא היה צריך, כלל הרשאות שאף אחד לא בדק, טבלת סיסמאות שמישהו שכח לגבב. הגנה על נתוני משתמשים ברמה הזו אינה כישור מומחים — כל אחד מהכשלים האלה ניתן לתיקון עם הנחיה בשפה פשוטה ובדיקה של חמש דקות.

המאמנת מההתחלה עשתה את כל זה בצהריים אחד: מחקה שני שדות לא בשימוש, הריצה את בדיקת שני החשבונות (ותפסה דליפה אחת — לקוחות יכלו לראות את השמות הפרטיים של זה את זה בתפריט נפתח), שאלה את חמש השאלות, כתבה את עמוד הפרטיות שלה. האפליקציה שלה לא נראתה שונה אחר כך. אבל כשחברתה שאלה “הדבר הזה בטוח להערות הלקוחות שלי?”, הייתה לה תשובה אמיתית.

קחו את הצהריים. המשתמשים שלכם נתנו לכם את הנתונים שלהם מתוך אמון — כך נראה לשמור עליו.