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

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

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

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

נקודות כניסה להתקפות על שרשרת אספקת התוכנה

ההסבר בתרשים כולל שתי קבוצות של איומים:

  • האותיות A עד H מציינות וקטורי תקיפה בשרשרת האספקה של התוכנה, שמתוארים כאיומים במסגרת Supply-chain Levels for Software Artifacts (SLSA).
  • המספרים 1 עד 4 מציינים וקטורים נוספים של תקיפות שלא מתוארים ישירות במסגרת SLSA.

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

בקטעי המשנה במסמך הזה מתוארים האיומים בהקשר של מקור, בנייה, פריסה ותלות.

איומים ממקורות

האיומים האלה משפיעים על השלמות של קוד המקור.

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

    • הגדרת מדיניות לתחנות עבודה למפתחים. ‫Cloud Workstations מספקת תחנות עבודה מנוהלות ומוגדרות מראש שאפשר להתאים אישית בהתאם לדרישות שלכם.
    • סריקה מקומית של קוד. התכונה Cloud Code source protect (תצוגה מקדימה פרטית) מספקת משוב אבטחה בזמן אמת, כולל מידע על פגיעויות ורישיונות של תלות. מפתחים יכולים גם להשתמש ב-On-Demand Scanning API כדי לסרוק קובצי אימג' של קונטיינרים ולחפש בהם נקודות חולשה במערכת ההפעלה ובחבילות השפה.
    • הדרכה בנושא שיטות לאבטחת הקוד.

  • ‫A: שולחים קוד לא תקין למאגר קוד המקור. האיסור הזה כולל לא רק קוד זדוני, אלא גם קוד שיוצר בטעות נקודות חולשה שניתן לנצל כדי לבצע מתקפה, כמו פרצת אבטחה XSS‏ (cross-site scripting). האמצעים לצמצום הסיכון כוללים:

    • דרישה לבדיקה אנושית של שינויים בקוד המקור.
    • שימוש בכלים לסריקת קוד ולניתוח קוד שמשתלבים עם סביבות פיתוח משולבות (IDE) ומערכות לניהול גרסאות.

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

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

מידע נוסף על הגנה על המקור

איומים על בנייה

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

  • ‫C: בנייה עם מקור שלא מגיע ממערכת בקרת המקורות המהימנה. אמצעים לצמצום הסיכון הזה כוללים:
    • שימוש בשירותי build, כמו Cloud Build, שמפיקים מידע על מקורות הנתונים כדי שתוכלו לוודא שגרסאות ה-build שלכם משתמשות במקור מהימן.
    • הצבת תשתית CI/CD בהיקף רשת כדי למנוע זליגת נתונים מהגרסאות שלכם. בשביל Google Cloud שירותים, צריך להשתמש ב-VPC Service Controls.
    • אחסון ושימוש בעותקים מהימנים של תלות בקוד פתוח שאתם צריכים במאגר פרטי של ארטיפקטים, כמו Artifact Registry.
  • ‫D: פריצה למערכת ה-build. אמצעים לצמצום הסיכון הזה:
    • כדי לפעול לפי העיקרון של הרשאות מינימליות, צריך להגביל את הגישה הישירה למערכת build רק לאנשים שזקוקים לה. ב- Google Cloud , אפשר להקצות תפקידים מוגדרים מראש או ליצור תפקידים בהתאמה אישית.
    • שימוש בשירותי בנייה מנוהלים כמו Cloud Build. ‫Cloud Build מריץ גרסאות build זמניות על ידי הגדרת סביבת מכונה וירטואלית לכל גרסת build והשמדתה אחרי ה-build.
    • כדי למנוע זליגת נתונים מהגרסאות שלכם, כדאי למקם את תשתית ה-CI/CD בפרימטר של הרשת. בשביל Google Cloud שירותים, צריך להשתמש ב-VPC Service Controls.
  • ‫F: אריזה ופרסום של תוכנה שנבנתה מחוץ לתהליך הרשמי. מערכות build שיוצרות וחותמות על אישור המקור של Build מאפשרות לכם לוודא שהתוכנה שלכם נוצרה על ידי מערכת build מהימנה.
  • ‫G: פריצה למאגר שבו מאחסנים את התוכנה עבור משתמשים פנימיים או חיצוניים. אמצעים לצמצום הסיכון הזה:
    • אחסון ושימוש בעותקים מהימנים של תלות בקוד פתוח שאתם צריכים במאגרי ארטיפקטים פרטיים, כמו Artifact Registry.
    • אימות של מקורות הבנייה והמקורות.
    • הגבלת הרשאות ההעלאה לחשבונות ייעודיים שהם לא חשבונות של בני אדם ולמנהלי מאגרים. ב- Google Cloud, חשבונות שירות פועלים בשם של שירותים ואפליקציות.

איומים על הפריסה ועל זמן הריצה

  • H: פתרון בעיות שקשורות לתלות באמצעות ציון טווח גרסאות או תג שלא מצורף באופן קבוע לגרסת build ספציפית עלול להוביל לכמה בעיות:

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

  • ‫2: פגיעה בתהליך הפריסה. אם אתם משתמשים בתהליך של פריסה רציפה, פריצה לתהליך הזה עלולה להוביל לשינויים לא רצויים בתוכנה שאתם מספקים למשתמשים. כדי לצמצם את הסיכון, אפשר להגביל את הגישה לשירות הפריסה ולבדוק את השינויים בסביבות שלפני הייצור. ‫Cloud Deploy יכול לעזור לכם לנהל את תהליך הפריסה הרציפה והקידום בין סביבות.

  • ‫3: פריסת תוכנה שנפרצה או שלא עומדת בדרישות. אפשר לצמצם את הסיכון הזה באמצעות אכיפה של מדיניות הפריסה. אתם יכולים להשתמש ב-Binary Authorization כדי לוודא שקובצי האימג' של הקונטיינרים עומדים בקריטריונים של המדיניות ולחסום פריסה של קובצי אימג' של קונטיינרים ממקורות לא מהימנים.

  • ‫4: נקודות חולשה והגדרות שגויות בתוכנה שפועלת.

    • נקודות חולשה חדשות מתגלות באופן קבוע, ולכן ממצאים חדשים יכולים לשנות את רמת סיכון האבטחה של האפליקציות שלכם בסביבת הייצור.
    • יש הגדרות שמגדילות את הסיכון לגישה לא מורשית, כמו הרצה בתור משתמש Root או מתן אפשרות להסלמת הרשאות (privilege escalation) בהרצה של קונטיינר.

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

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

במאמרים הגנה על קובצי build והגנה על פריסות אפשר לקרוא מידע נוסף על הגנה על קוד המקור ועל פריסות.

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

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

בתרשים, E מציין שימוש בתלות לא תקינה בבנייה. תלות בעייתית יכולה לכלול:

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

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

צמצום האיומים

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

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

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

המאמרים הבאים