אבטחת מידע וקניין רוחני עם צוות פיתוח חיצוני

הלקוח חתם, והצוות החיצוני מתחיל מחר. מישהו אצלכם שולח לו הזמנה ל-repository, סיסמה לשרת הבדיקות ו-API key של מערכת התשלומים, בהודעה אחת, כי "צריך שיתחילו כבר". כולם מרוצים, וההודעה הזו מכילה בדיוק את מה שיהיה קשה לאסוף בחזרה.

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

מי הבעלים של הקוד, ובאיזה מסמך זה כתוב

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

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

הצד הטכני של אותה שאלה: הקוד יושב ב-repository שאתם מחזיקים, בארגון שלכם ב-GitHub, GitLab או Bitbucket, והצוות החיצוני מוזמן אליו. בקשו גם מסירה מסודרת בסוף: כל ה-repositories, סקריפטי ההרצה, הגדרות התשתית ורשימת התלויות, כך שמפתח חדש יוכל להמשיך בלי הצוות הקודם. הפוך (הצוות עובד ב-repository שלו ואתם מקבלים עותק בסוף) הוא מצב שכדאי להימנע ממנו, כי היסטוריית הקוד והגישה נשארות אצל מישהו אחר.

הרשאות, סודות וסביבות

הרשאות: כל אדם בחשבון משלו

כמה כללים שנראים מובנים מאליהם ומופרים לעיתים קרובות:

• חשבון אישי לכל מפתח. סיסמה משותפת לצוות אומרת שאי אפשר לדעת מי עשה מה, ושאי אפשר להסיר אדם אחד בלי להחליף לכולם.
• הרשאה לפי תפקיד. מפתח frontend לא צריך גישה למסד הנתונים של הייצור. מפתח שעובד על feature צריך כתיבה לענף שלו, ולא הרשאת מיזוג ל-main.
• אימות דו-שלבי בכל מערכת שתומכת בכך, ו-SSO אם יש לכם.
• ענף main מוגן: מיזוג רק דרך pull request עם review של מישהו מצידכם. זה מונע גם שגיאות וגם שינוי לא מבוקר.
• סקירת הרשאות מדי תקופה. אנשים עוברים בין משימות, ומי שקיבל גישה לצורך אחד שומר אותה הרבה אחרי שהצורך נעלם.

פריסה לייצור

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

סודות וסביבות

מפתחות, סיסמאות וטוקנים לא נכנסים לקוד ולא נשלחים בצ'אט. הם נשמרים במנגנון ייעודי (secrets manager או משתני סביבה בכלי ה-CI) ומועברים לכל סביבה בנפרד. כדאי להריץ סריקה אוטומטית שמזהה סודות שנכנסו בטעות ל-commit, ולהניח שסוד שנחשף פעם אחת, אפילו לשעה, מוחלף.

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

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

אנשים, כלי AI ועזיבה

מי המעסיק ומה חותמים

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

כלי AI ופרטיות הקוד

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

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

תהליך עזיבה: מכינים אותו ביום הראשון

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

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

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

בדיקה מהירה לפני שמתחילים

אם לא הגדרתם עדיין, בדקו שיש לכם תשובה לכל אחד מאלה:

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

השורה התחתונה

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

אם אתם בוחנים צוות שמצטרף אליכם ועובד בתוך התשתיות שלכם, כך נראה מודל הרחבת הצוות.