10110010011101001011001101101110101018200.devFrom Enterprise.Systems

חובות האבטחה שכבר חלות עליכם כמפתחים עצמאיים

The 8200.dev Teamקריאה של 8 דק׳

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

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

תחת GDPR, פרילנסר שמעבד נתוני לקוח הוא מעבד — עם חובות ישירות

אם לקוח באיחוד האירופי (או לקוח שהמשתמשים שלו באיחוד האירופי) מוסר לכם מידע אישי — מסד נתוני משתמשים להעברה, מערכת ייצור לניפוי, ייצוא לניתוח — אתם כמעט תמיד פועלים כמעבד נתונים תחת ה-GDPR, ובחלק מההתקשרויות (כשאתם מחליטים מה לאסוף ולמה) כבעלי שליטה. אף אחד מהמעמדות אינו דורש חברה. הגדרות ה-GDPR בסעיף 4 נקשרות ל״אדם טבעי או משפטי״ — אדם עם מחשב נייד עונה להגדרה.

המעמד הזה נושא חובות ישירות ואישיות:

  • סעיף 28 דורש שהעיבוד שלכם עבור לקוח יוסדר בחוזה — הסכם עיבוד הנתונים שהלקוחות הארגוניים שלכם ממשיכים לשלוח אינו תיאטרון בירוקרטי; הוא דרישה חוקית משניכם, והוא כובל אתכם להתחייבויות אבטחה מוגדרות.
  • סעיף 32 דורש מכם ליישם ״אמצעים טכניים וארגוניים הולמים״ לאבטחת המידע האישי שאתם מעבדים — הולמים ביחס לסיכון, ובכלל זה שליטה במי ובמה שיכולים לגשת אליו.
  • סעיף 33 דורש ממעבד להודיע לבעל השליטה ״ללא עיכוב בלתי סביר״ לאחר שנודע לו על אירוע אבטחת מידע אישי — מה שמניח מראש שאתם בעמדה שבה יכול להיוודע לכם אירוע כזה.
  • סעיף 82 מקנה לנושאי המידע זכות לפיצוי ממעבדים על נזק שנגרם מעיבוד שמפר את התקנה, וסעיף 83 מגבה את המסגרת כולה בקנסות מנהליים שיכולים להגיע, בהפרות החמורות ביותר, עד עשרים מיליון אירו או ארבעה אחוזים מהמחזור השנתי העולמי — הגבוה מביניהם.

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

תקנת הבינה המלאכותית האירופית מוסיפה חובות למפעילי מערכות בינה מלאכותית

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

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

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

הלקוחות הארגוניים שלכם כבר מפוקחים — והחובות שלהם זולגות אליכם

גם אם לעולם לא תיגעו במידע אישי אירופי ולעולם לא תפרסו מערכת בינה מלאכותית, יש מקור שלישי לחובות אבטחה שחל כמעט על כל פרילנסר שעובד עם עסקים בכל גודל: חוזים. לקוחות ארגוניים פועלים תחת דוחות SOC 2, הסמכות ISO 27001, דרישות מעבד לפי סעיף 28 ל-GDPR ותוכניות ניהול ספקים שהמבקרים שלהם באמת בודקים. התוכניות האלה אינן מבחינות בין ספק של 500 עובדים לספק של אדם אחד. ספק הוא ספק.

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

כמה אירוע אבטחה באמת עולה למפתח עצמאי

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

אז מה בעצם חשוף בחשבון שלכם ברגע זה?

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

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

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

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

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

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

שיתוףX / TwitterLinkedIn

מאמרים קשורים