רווחים:
- יכולת לבקש הרשאות עם הצדקה, הקשר ותרחיש דחייה, תוך שימוש בעקרון המינימום הזכויות
- יכולת לאחסן נתונים רגישים מוצפנים עם Keychain/Keystore, להחיל מזעור נתונים ולשלוט בנטייה של בינה מלאכותית להוסיף יותר מדי הרשאות
- יכולת לנהל את זרימת נתוני המשתמש לענן או לשירות הבינה המלאכותית כהחלטת פרטיות, לקבל את הסכמת המשתמש ולהשתמש בטכניקות אבטחה רק למטרות מורשות והגנתיות
האפליקציה לנייד פועלת במכשיר הפרטי ביותר של המשתמש: היא יודעת את מיקומו, אנשי הקשר, התמונות, נתוני הבריאות, המיקרופון שלו. גישה זו היא כוח גדול, וכוח פירושו אחריות. פרטיות ואבטחה אינן "תכונה נוספת" בפיתוח נייד, אלא עיקרון השזור בארכיטקטורה מההתחלה; זה נקרא פרטיות לפי עיצוב. יתרה מכך, זו לא רק בחירה אתית, אלא חובה חוקית (KVKK, GDPR) וחנות (App Store, Google Play). ביחידה זו נלמד כיצד לבקש הרשאות בצורה נכונה, לעבד נתונים בצורה מאובטחת, להשתמש ב-AI כעוזר בתחום זה ולהגן על עצמנו מהמלכודות שלו. ישנה בעיה קריטית נוספת בהקשר של AI: נתוני משתמשים העוברים לדגמי AI (במיוחד לענן) הם החלטת פרטיות בפני עצמה.
אומנות בקשת הרשות: הפחות זכות
העיקרון הבסיסי של אבטחה הוא המינימום פריבילגיה (לא לבקש יותר הרשאות ממה שדורשת עבודה). האפליקציה שלך צריכה לבקש רק את ההרשאה שהיא באמת צריכה, בזמן שהיא צריכה אותה. אם אין תכונת מצלמה, לא תתבקש הרשאת מצלמה; אם המיקום נדרש רק כאשר המפה פתוחה, הרשאת "תוך שימוש" מספיקה, לא "תמיד". הרשאות מוגזמות גורמות לנזק משולש: היא מערערת את אמון המשתמשים, מובילה לדחיית חנות ומגדילה את הסיכון לדליפת נתונים.
תזמון והסבר נכונים לבקשת רשות הם קריטיים. בקש מהמשתמש רשות בהקשר ובנימוק, כגון "נדרשת גישה למצלמה כדי לסרוק את הקבלה שלך". iOS דורש תיאור זה ב- Info.plist; תיאור ריק או מטעה הוא דחיית חנות.
סוג הרשאה
גישה גרועה
גישה טובה
תזמון
בקש הכל בעת ההשקה
הנחיה בעת השימוש בתכונה
היקף
"תמיד מיקום"
"מיקום בזמן השימוש"
תיאור
ריק או גנרי
הצדקה קונקרטית, ספציפית
מצב דחייה
אפליקציה קורסת/קורסת
מוזמן להציע אלטרנטיבות
טיפ: האפליקציה שלך אמורה להיות מסוגלת להמשיך לפעול כאשר ההרשאה נדחתה. אם המשתמש דוחה את המצלמה, הציעו אפשרות "כניסה ידנית". הטלת "אפשר את זה או שהאפליקציה לא תעבוד" היא גם ניסיון רע וגם בעיה בחנות. בקש תמיד את תרחיש הדחייה בעת הדפסת קוד הרשאה ל-AI.
הסכמה וקוד פרטיות עם AI: שיקולים
בינה מלאכותית מייצרת במהירות קוד לבקשת הרשאה, אבל יש לה שתי מלכודות אופייניות. ראשית, הוספת הרשאות נוספות מהנדרש: מיקום, אנשי קשר יכולים לשים בכמות גדולה הרשאות אחסון "למקרה". שנית, דילוג על תרחיש הדחייה: פשוט כתוב את הסטטוס "מותר" והתעלם מהדחייה. על כל אישור שנוצר תישאל "האם זה באמת נחוץ?" ו"מה קורה אם נדחה?" שאל את השאלות שלך.
זהירות: הקוד לדוגמה שנוצר על ידי AI עשוי לאחסן נתוני משתמש ללא הצפנה או לשדר אותם בצורה לא מאובטחת. יש לשמור נתונים רגישים (סיסמה, בריאות, כספים) באחסון מאובטח במכשיר (מחזיק מפתחות - iOS, Keystore - אנדרואיד; אזור כספת מוצפן של מערכת ההפעלה) ולהעביר אותם ברשת באמצעות חיבור מוצפן (HTTPS/TLS). AI לא תמיד עושה זאת באופן ספונטני; שאל בצורה ברורה ואמת.
מזעור נתונים ושליחת נתונים ל-AI
נתונים שאתה לא אוסף לא יכול לדלוף. מזעור נתונים (איסוף רק את הנתונים הדרושים בפועל) הוא הכלי החזק ביותר לפרטיות. בתכונות בינה מלאכותית, עיקרון זה חשוב כפליים: בעת שליחת נתונים ל-LLM בענן או לשירות AI חיצוני, הנתונים הללו אינם בשליטתך. לפני שליחת הערת בריאות של משתמש, תוכן שיחה או מידע אישי לענן, שאל שלוש שאלות: (1) האם הנתונים האלה באמת נחוצים? (2) האם ניתן לעבד אותו במכשיר? (3) אם הוא אמור להישלח, האם המשתמש יודע ומאשר זאת? זוהי דרישה משפטית וגם אתית להודיע בבירור למשתמש שהנתונים שלו עוברים לשירות AI.
שימוש בטוח ומיקוד הגנה
אזהרה מנקודת מבט של IT ואבטחה: הטכניקות הנלמדות במודול זה מיועדות לשימוש מורשה והגנתי בלבד. זה לגיטימי לבדוק את האבטחה של האפליקציה שלך, להגן על נתוני המשתמש ולסגור נקודות תורפה. הנדסה לאחור של אפליקציה של מישהו אחר ללא רשות, איסוף נתוני משתמשים ללא הסכמה, או שימוש בבינה מלאכותית ליצירת תוכנות זדוניות הוא לא חוקי ולא אתי. כשאתה מבקש מ-AI עזרה באבטחה, הישאר תמיד במסגרת של הגנה על המערכת שלך.
שלושה מיני תיקים
מקרה 1 - שלילת חופשה עודפת. אפליקציית הערה ביקשה הרשאות מצלמה, מיקרופון, מיקום ויצירת קשר בעת ההפעלה עם הקוד שהופק על ידי AI. גוגל פליי דחתה את המהדורה, תוך ציטוט של "הרשאות לא רלוונטיות לפונקציה". השחרור אושר כאשר הצוות שחרר רק את הרשאת האחסון שבה נעשה שימוש בפועל. לקח: כל חופשה נוספת היא סיכון.
מקרה 2 - אחסון ללא סיסמה. אפליקציית בריאות שמרה את מדידות המשתמש בקובץ טקסט רגיל כמו בדוגמה של AI. בביקורת אבטחה נמצא שכל מי שהשיג את המכשיר יכול לקרוא את כל נתוני הבריאות. הנתונים הועברו לאחסון מוצפן באמצעות מאגר מפתחות/מחזיק מפתחות. לקח: נתונים רגישים תמיד נשארים מוצפנים.
מקרה 3 - דחיפה בלתי מוקדמת לענן. אפליקציה שלחה הערות יומיות של משתמשים ל-LLM בענן כדי לסכם אותן, אבל היא לא סיפרה למשתמש. כאשר דווח על כך בעיתונות, חל אובדן אמון ובדיקה משפטית. הצוות הוסיף הודעה ברורה ואישור, כמו גם אפשרות במכשיר. לקח: המשתמש חייב לדעת ולאשר שהנתונים עוברים ל-AI.
הנחיה חלשה / הנחיה חזקה
הנחיה חלשה: "בקש הרשאת מיקום."
הנחיה עוצמתית: "בקש הרשאת מיקום ב-iOS/Swift עם העיקרון של הרשאות מינימום. - רק הרשאת 'כאשר בשימוש', לא 'תמיד' - תיאור Info.plist: 'כדי להראות חנויות בקרבת מקום' - אם הרשאה נדחתה: מציע אפשרות לבחור עיר ידנית, לקרוס - אם ההרשאה נדחתה בעבר, הפנה מחדש לדחיית ההגדרות מאשר תוסיף יותר הרשאה."
תבניות הניתנות להעתקה
תבנית לבקשת הרשאה: "בקש הרשאת [סוג הרשאה] עבור [פלטפורמה].- היקף מינימלי (בעת שימוש/לפי הצורך)- בהקשר, עם הסבר מנומק- חלופה מנומסת במקרה של דחייה, לעולם אל תתרסק- תן גם ערך Info.plist / Manifest אל תוסיף הרשאות נוספות; נמק כל הרשאה."
תבנית ביקורת הרשאות: "בדוק את ההרשאות שהאפליקציה שלי מבקשת: [רשימת הרשאות + מאפיינים]. לכל הרשאה: האם היא באמת נחוצה? האם יספיק היקף מצומצם יותר? האם זה יוביל לדחיית חנות? סמן מיותר."
תבנית אחסון נתונים מאובטח: "אחסן בצורה מאובטחת נתונים רגישים ([סוג]) עבור [פלטפורמה]:- מוצפן באמצעות מחזיק מפתחות/מפתחות- אין לשמור בזיכרון לזמן ארוך שלא לצורך- אל תדלוף לתוך יומנים וגיבויים ספק קוד ושלבי אימות."
תבנית לשליחת נתונים לבינה מלאכותית: "אני שוקל לשלוח את הנתונים הבאים לשירות בינה מלאכותית בענן: [נתונים]. הערכת: האם זה באמת הכרחי? האם ניתן לעבד אותם במכשיר? אם נשלח, אילו שדות יש להסוות? כיצד יש לקבל את הסכמת המשתמש? המלץ על העיצוב המאובטח ביותר מבחינת פרטיות".
טעויות נפוצות
- מבקש רשות יותר ממה שצריך. סכנה משולשת של אמון, אישור חנות ואבטחה.
- בקשת הרשאות בכמות גדולה בעת ההפעלה. בקשת רשות ללא הקשר נדחית; לבקש את התכונה באופן מיידי.
- לא כותב את תסריט הדחייה. האפליקציה הקורסת כאשר ההרשאה נדחתה היא גם גרועה וגם נדחתה.
- אחסון נתונים רגישים ללא סיסמה. בריאות, כספים וסיסמאות חייבות להישמר באחסון מאובטח.
- שליחת נתונים לענן/AI מבלי ליידע את המשתמש. הפרה משפטית ואתית; נדרשת הודעה ואישור.
- שימוש לא מורשה בטכניקות אבטחה. זה לגיטימי רק למטרות הגנה על המערכת שלך.
לסיכום
הפרטיות והאבטחה תוכננו מההתחלה, לא הוסיפו מאוחר יותר. העיקרון הבסיסי הוא המינימום פריבילגיה: בקשו רק את הרשות הנדרשת, כשצריך, בצידוק, והצעו חלופה אדיבה במקרה של סירוב. נתונים רגישים מאוחסנים באחסון מוצפן ומועברים באמצעות חיבור מוצפן. מזעור נתונים הוא ההגנה החזקה ביותר: נתונים שאתה לא אוסף לא יכול לדלוף. שליחת נתונים ל-AI, במיוחד לענן, היא החלטת פרטיות בפני עצמה; נחיצותו מוטלת בספק, במידת האפשר, מועדף במכשיר, מודיעים למשתמש ומתקבל אישורו. כל קוד המיוצר נבדק מול הנטיות של AI להוסיף הרשאות מופרזות ולאחסן בצורה לא מאובטחת. טכניקות אבטחה משמשות למטרות מורשות והגנתיות בלבד.
משימת יישום
ערכו רשימה של ההרשאות שאפליקציה (פרויקט משלכם או דמיוני) מבקשת ובקשו מה-AI לבדוק אילו מהן מיותרות או חורגות עם "תבנית ביקורת ההרשאות". צמצם או הסר הרשאה אחת לפחות וכתוב את תרחיש ההכחשה עבור תכונה זו. בנוסף, אם אתה שולח נתוני משתמש לענן, קבע את העיצוב המאובטח ביותר באמצעות "תבנית החלטה של שליחת נתונים ל-AI" וכתוב את טקסט אישור המשתמש.
רשימת בדיקה
- [ ] ביקשתי כל רשות בהצדקה, עם עיקרון הזכות הקטנה ביותר.
- [ ] ביקשתי הרשאות בהקשר, בזמן הפיצ'ר, לא בכמות גדולה בהשקה
- [ ] כתבתי סקריפט דחייה עבור כל הרשאה, ללא קריסות
- [ ] אחסנתי נתונים רגישים מוצפנים באמצעות מחזיק מפתחות/מאגר מפתחות
- [ ] הקטנתי את הנתונים שעוברים לענן/AI והוספתי אישור משתמש
- [ ] השתמשתי בטכניקות אבטחה רק במערכת שלי למטרות הגנה