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

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

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

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

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

ההסבר לתרשים כולל שני סוגים של איומים:

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

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

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

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

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

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

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

  • א: שולחים קוד פגום למאגר המקורות. האיסור הזה כולל לא רק קוד זדוני, אלא גם קוד שיוצר בטעות נקודות חולשה שניתן לנצל כדי לבצע מתקפה, כמו פרצת אבטחה 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 תכונות אבטחה בתהליכי הפיתוח, הבנייה והפריסה כדי לשפר את רמת האבטחה של שרשרת אספקת התוכנה. אתם יכולים להטמיע את השירותים בהדרגה, על סמך סדר העדיפויות והתשתית הקיימת שלכם.

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