הגנה על המקור

במסמך הזה מתוארות שיטות מומלצות לניהול קוד מקור של תוכנה.

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

רוב הצוותים משתמשים היום בניהול גרסאות, אבל יש הרבה דרכים להגדיר מערכת לניהול גרסאות ואת השילובים שלה עם חלקים אחרים בצינור CI/CD.

במסמך הזה מפורטים שיקולים בנושא אבטחת שרשרת האספקה של תוכנות, שצריך לקחת בחשבון כשמגדירים מערכת לניהול גרסאות. במאמר הזה מתוארות שיטות מומלצות מתוך Supply-chain Levels for Software Artifacts (רמות שרשרת אספקה עבור ארטיפקטים של תוכנה), מסגרת להגנה על שרשרת אספקת התוכנה. המסגרת כוללת דרישות בכמה רמות כדי לעזור לכם ליישם שינויים באופן הדרגתי, כולל דרישות לגבי מקורות.

מערכת לניהול גרסאות עם היסטוריית שינויים וגרסאות שלא ניתן לשנות היא דרישה ברמה 2 של SLSA. מומלץ להתחיל עם התאמה לרמה 2 של SLSA כרמת בסיס לשרשרת אספקת התוכנה.

ברמה 3 של SLSA, פלטפורמות המקור והבנייה עומדות בדרישות אבטחה מחמירות יותר, כולל היסטוריית מקור מאומתת ומדיניות שימור מקור. ברמה 4 של SLSA נוספות דרישות לגבי מקורות, כולל בדיקות של שני אנשים.

שימוש בניהול גרסאות למטרות נוספות מעבר לקוד המקור של האפליקציה

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

• השפעה על הזמינות והאבטחה של תשתית המחשוב
• דרישה לשיתוף פעולה כדי להשלים את התהליך
• נדרש תהליך אישור שניתן לחזור עליו
• דרישה של היסטוריית שינויים

דוגמאות:

• תשתית כקוד: ארגונים שרוצים לנהל את התשתית שלהם בצורה מאובטחת וניתנת להרחבה משתמשים בתשתית כקוד כמתודולוגיה מרכזית. לדוגמה, אפשר לאחסן במערכת לניהול גרסאות מודולים של Terraform שיוצרים מאגרי Artifact Registry.
• ניהול הגדרות: ניהול הגדרות דומה ל-infrastructure-as-code, אבל הוא מתמקד בניהול הגדרות של אפליקציות באמצעות כלים כמו Ansible,‏ Puppet ו-Chef. אתם מאחסנים ומנהלים את קובצי התצורה של האפליקציה במערכת לניהול גרסאות.
• תצורות של מסדי נתונים וסקריפטים להעברה: אחסון של התצורה והסקריפטים של מסדי הנתונים של המוצרים ושל מסדי הנתונים של Analytics או של רישום ביומן.
• ‫Jupyter notebooks: יש מגוון דרכים לעבוד עם מחברות שאוחסנו ב-GitHub, כולל התוסף ל-JupyterLab,‏ Colaboratory ו-Vertex AI Workbench.
• מדיניות אבטחה: אחסון קובצי מדיניות לאכיפה אוטומטית של מדיניות. לדוגמה, אפשר לאחסן מדיניות של Gatekeeper שמאפשרת או אוסרת התנהגות פריסה ב-GKE או מדיניות של Sentinel שמונעת מ-Terraform הקצאת משאבים של תשתית שמפירה את המדיניות.

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

הגדרת מאגר

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

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

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

כדי לפתור את הבעיות האלה, כדאי לפעול לפי השיטות המומלצות הבאות:

• הגדרת מאגרי מידע באמצעות תהליך אוטומטי, חוזר ומודע לאבטחה. לדוגמה, אפשר להגדיר מודולים של Terraform שמשלבים את דרישות האבטחה של האפליקציה שאליה מתייחס המאגר. אפליקציות ברמת אבטחה גבוהה דורשות יותר מאשרי מיזוג שונים מאפליקציות ברמת אבטחה נמוכה יותר.
• ליצור דרך לאדמינים של מאגרים לבחור מתוך קבוצה של תבניות הגדרה של מאגרים שמניעות הגדרה של מאגרים חדשים, במקום להגדיר כל מאגר מאפס. התבניות האלה צריכות לשקף את רמות האבטחה השונות של האפליקציות שלכם, ולהיות מסונכרנות עם זהויות המשתמשים שנדרשות לכל רמת אבטחה. בפועל, זה בדרך כלל אומר שצריך להשתמש במערכת היררכית לניהול זהויות והרשאות גישה (IAM) שמשקפת את האפליקציות והתשתית בארגון ואת המשתמשים שאחראים עליהן.
• לדרוש ניהול זהויות מרכזי עם אימות רב-שלבי (MFA) למשתמשי המאגר.
  • ניהול זהויות מרכזי מבטיח שכאשר משתמשים עוזבים את הארגון או עוברים לצוותים חדשים, אתם שומרים על הרשאות מינימליות לניהול המקור.
  • אימות רב-שלבי מפחית באופן משמעותי את הסיכון לפישינג ולסוגים אחרים של מתקפות על המקור. אימות דו-שלבי הוא אחת מהדרישות ברמה 4 של SLSA למאשרי קוד.
• הגבילו את הגישה לבעלי מאגרי מידע למספר קטן של עובדים מהימנים. יכול להיות שיהיה צורך לשלב ניהול גרסאות עם מערכת לניהול זהויות, ולהעביר את היכולת להגדיר מדיניות לרמה גבוהה יותר בארגון. אם אפשר, כדאי להסיר את האפשרות של בעלי מאגרים לבצע מיזוגים בלי בודק שני.

סקר קוד

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

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

כדי לצמצם את הסיכון, אפשר:

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