5,000 אפליקציות בלי הגנות מספקות: הסיכון העסקי של הווייב קודינג
בניית אפליקציה הפכה לפעולה פשוטה יחסית. עובד מתאר לבינה מלאכותית מה הוא צריך, ובתוך שעות מקבל מערכת שפעם הייתה דורשת מתכנתים, תקציב וזמן פיתוח ממושך. אלא שהקלות הזאת יוצרת סיכון חדש לעסקים: עובדים מקימים מערכות שמתחברות למידע רגיש, לעיתים בלי שמחלקת המחשוב מודעת לקיומן ובלי בדיקות אבטחה מסודרות. הבעיה כבר מקבלת ביטוי בשטח. בדיקה של כ-380 אלף נכסים דיגיטליים איתרה יותר מ-5,000 אפליקציות עם הגנות גישה חסרות או חלשות במיוחד. בקרוב ל-2,000 מהן נמצא מידע שנראה פרטי או עסקי רגיש.
התופעה נקראת וייב קודינג, פיתוח תוכנה באמצעות הוראות בשפה טבעית. פלטפורמות כמו לאבאבל, בייס44 ורפליט מאפשרות כמעט לכל עובד לבנות כלי לניהול לקוחות, לעיבוד נתונים או להפעלת שירות פנימי. האפשרות לבנות אפליקציות בלי ידע בתכנות מקצרת תהליכים ומוזילה עלויות, אבל האחריות לאבטחת המידע עדיין מחייבת ידע ופיקוח.
הסכנה מתבררת כשמסתכלים על הדרך שבה האפליקציות פועלות. מנהל מכירות, למשל, יכול לבנות מערכת שמציגה נתוני לקוחות ולחבר אותה ישירות למסד הנתונים של החברה. הממשק נראה תקין, הגרפים עובדים והעובדים משתמשים בו. אלא שהרשאות שהוגדרו בצורה שגויה עלולות לאפשר גם לגורם חיצוני לצפות ברשימת הלקוחות, בפרטי ההתקשרות ובנתונים העסקיים.
בבדיקה של חברת הסייבר הישראלית רדאקסס אותרו אפליקציות שבהן הופיעו לכאורה מידע רפואי, תכתובות עם לקוחות, תוכניות עסקיות ורשומות כספיות. חלק מהמקרים אומתו בבדיקה עיתונאית, ובחלקם נותרה אי-ודאות לגבי אמיתות המידע שנחשף. כמה מבעלי האפליקציות אישרו שהמידע היה גלוי ופעלו להגבלת הגישה אליו.
מחקר אקדמי נוסף, שהתעדכן בספטמבר, בחן 200 אפליקציות פעילות שנבנו באמצעות כלי בינה מלאכותית. החוקרים מצאו חולשת אבטחה אחת לפחות ב-91% מהן, ובסך הכול זיהו 1,186 חולשות. חלק גדול מהבעיות עסק בניהול הרשאות, באימות משתמשים ובאפשרות להזין מידע זדוני למערכות. מדובר במדגם מוגדר ובבדיקות מסוג מסוים, אבל הממצאים ממחישים עד כמה הפער בין תוכנה שעובדת לבין תוכנה מאובטחת עשוי להיות משמעותי.
אחת הבעיות המרכזיות היא שבינה מלאכותית מסוגלת לייצר מערכת שמבצעת היטב את המשימה שהתבקשה, גם כשהגנות המידע שלה חלקיות. למשל, אפליקציה יכולה לדרוש שם משתמש וסיסמה בכניסה, ובכל זאת לאפשר למשתמש להגיע לרשומות של לקוחות אחרים. בעיה נוספת היא שמירת מפתחות גישה לשירותים חיצוניים בתוך קוד שהדפדפן מקבל. חשיפה של מפתח כזה עשויה לאפשר שימוש במערכות נוספות שאליהן מחוברת האפליקציה.
מבחינת הארגונים, זה גם שינוי בדרך שבה נוצרים סיכוני סייבר. בעבר, התקנת מערכת חדשה לוותה בדרך כלל בבחינת ספק, בהגדרת הרשאות ובאישור של אנשי המחשוב. כיום עובד יכול להקים מערכת באמצעות חשבון אישי, לחבר אותה לנתוני החברה ולהתחיל להשתמש בה באותו יום. כשעובד כזה עוזב את הארגון, האפליקציה עשויה להמשיך לפעול ולהחזיק בגישה למידע רגיש. במקרה של חשיפה, העלויות עלולות לכלול חקירה, טיפול בלקוחות, השבתת שירותים והליכים משפטיים.
ההתמודדות מחייבת שינוי בפיקוח על פיתוח תוכנה בארגון. הצעד הראשון הוא מיפוי האפליקציות שפועלות בארגון והמידע שאליו הן מחוברות. בהמשך נדרשים מנגנוני הזדהות אחידים, הרשאות בהתאם לתפקיד, תיעוד של גישה לנתונים ובדיקות אבטחה לפני פרסום אפליקציה. חברות סייבר כבר מפתחות פתרונות שמיועדים לאבטחת קוד שנכתב באמצעות AI.
במערכת לניהול לקוחות, למשל, אפשר לקבוע שמנהל צוות יראה את כלל הלקוחות במחלקה, ואילו עובד יקבל גישה ללקוחות שבאחריותו. ההגבלה צריכה להתבצע גם במסד הנתונים עצמו, כך שכל אפליקציה שמתחברת אליו תפעל לפי אותן הרשאות. בנוסף, שינוי שמאפשר הורדת נתונים או חיבור למערכת נוספת יחייב בדיקת אבטחה ואישור מתאים, גם כשהקוד כולו נוצר באמצעות בינה מלאכותית.
