במאמר הזה מוסבר איך Google מנהלת את נקודות החולשה באבטחה ואת התיקונים ב-Apigee Hybrid. אלא אם צוין אחרת, Apigee כולל גם את מישור הניהול וגם את מישור הנתונים.
אחריות משותפת על תיקוני באגים
התקנת תיקונים היא באחריות משותפת של Google ושל הלקוח. ב-Apigee X וב-Apigee Hybrid יש תחומי אחריות משותפים שונים, כי מישור הנתונים של Apigee Hybrid מנוהל כולו על ידי הלקוח. למידע על תחומי האחריות המשותפים ב-Apigee Hybrid, קראו את המאמר מודל האחריות המשותפת ב-Apigee Hybrid.
איך מגלים נקודות חולשה
Google נוקטת גישה פרואקטיבית לאבטחת מערכות תוכנה, תוך שימוש בעקרונות תכנון של אבטחה כברירת מחדל והטמעה של שיטות שונות להקשחת האבטחה.
לדוגמה, אפליקציות בקונטיינרים מפעילות את התכונות השונות של פלטפורמת ניהול ה-API ב-Apigee. האפליקציות בקונטיינרים נפרסות ב-Kubernetes. קובצי האימג' של הקונטיינרים מבוססים על קובצי אימג' בסיסיים מינימליים (לדוגמה, קובצי אימג' בסיסיים ללא הפצה) כדי לספק אבטחה מקסימלית וביצועים משופרים.
עם זאת, גם במערכות התוכנה הכי טובות יכולות להיות נקודות חולשה. כדי למצוא את נקודות החולשה האלה ולתקן אותן לפני שמישהו ינצל אותן, Google השקיעה משאבים רבים בכמה חזיתות.
סורקי אבטחה
Google מזהה ומתקנת באופן יזום נקודות חולשה בסוגים שונים של קובצי אימג' של קונטיינרים:
- קונטיינרים של צד ראשון: קובצי אימג' של קונטיינרים שנוצרו והופצו על ידי Google כחלק מפלטפורמת Apigee. אלה אפליקציות קנייניות של Google שמפעילות את פלטפורמת ניהול ה-API ב-Apigee, כולל פונקציונליות עיקרית כמו ניתוב תנועה, ניהול מכסות וניהול מפתחות.
- קונטיינרים של צד שלישי: קובצי אימג' של קונטיינרים שנוצרו על ידי קהילת הקוד הפתוח, אבל מופצים על ידי Google כחלק מפלטפורמת Apigee. אלה בעיקר רכיבי קוד פתוח שמשמשים את הפלטפורמה למשימות תפעוליות נפוצות, כמו רישום ביומן, מעקב וניהול אישורים.
Google סורקת קונטיינרים באמצעות Container Registry Container Analysis כדי לגלות נקודות חולשה ותיקונים חסרים בקונטיינרים של צד ראשון ושל צד שלישי. אם יש תיקונים זמינים, Google מתחילה בתהליך התיקון וההפצה. הסריקות האלה מתבצעות באופן קבוע (כשמתפרסמות תמונות חדשות) וגם על פי דרישה (לפני גרסה חדשה) כדי למקסם את הסיכויים לזהות נקודות חולשה חדשות ולתכנן תיקון מוקדם או הפחתה.
מחקר אבטחה
בנוסף לסריקה האוטומטית, Google מגלה ומתקנת נקודות חולשה שלא ידועות לסורקים בדרכים הבאות:
- Google מבצעת ביקורות אבטחה ותאימות משלה, בדיקות חדירה לאפליקציות ולרשת, בדיקות פילוח וגילוי של נקודות חולשה באבטחה בכל רכיבי Apigee.
צוותים מיוחדים ב-Google וספקי אבטחה מהימנים מצד שלישי עורכים מחקרים משלהם בנושא התקפות. - Google משתפת פעולה עם שותפים אחרים בתחום ועם שותפים של תוכנות בקוד פתוח, שמשתפים מידע על נקודות חולשה, מחקרים בנושא אבטחה ותיקונים לפני הפרסום לציבור של נקודת החולשה.
מטרת שיתוף הפעולה הזה היא לתקן חלקים גדולים בתשתית האינטרנט לפני שהחולשה מתפרסמת לציבור. במקרים מסוימים, Google תורמת לקהילה הזו פרצות אבטחה שנמצאו. לדוגמה, במסגרת Project Zero של Google התגלו ופורסמו נקודות החולשה Spectre ו-Meltdown. צוות האבטחה של Google Cloud גם מוצא ומתקן באופן קבוע נקודות חולשה במכונה הווירטואלית מבוססת-הליבה (KVM).
תוכניות התגמולים על זיהוי נקודות חולשה באבטחה (VRP)
Google משתפת פעולה באופן פעיל עם קהילת המחקר בתחום האבטחה באמצעות מספר תוכניות תגמולים על זיהוי נקודות חולשה באבטחה. במסגרת תוכנית התגמולים הייעודית של Google Cloud על זיהוי נקודות חולשה באבטחה, אנחנו מעניקים פרסים משמעותיים, כולל 133,337 $על זיהוי נקודת החולשה הכי משמעותית בענן בכל שנה. התוכנית כוללת את כל יחסי התלות של תוכנת Apigee.
OSS
שיתוף הפעולה של Google בתחום האבטחה מתרחש בכמה רמות. לפעמים זה קורה באופן רשמי דרך תוכניות שבהן ארגונים נרשמים כדי לקבל התראות טרום-השקה על נקודות חולשה בתוכנות של מוצרים כמו Kubernetes ו-Envoy. שיתוף הפעולה מתרחש גם באופן לא רשמי, בגלל המעורבות שלנו בפרויקטים רבים של קוד פתוח, כמו ליבת Linux, סביבות זמן ריצה של קונטיינרים, טכנולוגיית וירטואליזציה ועוד.
נקודות חולשה פחות חמורות מתגלות ומתוקנות מחוץ לתהליכים האלה, אבל רוב נקודות החולשה הקריטיות באבטחה מדווחות באופן פרטי דרך אחד מהערוצים שצוינו למעלה. דיווח מוקדם נותן ל-Google זמן לפני שחולשת האבטחה הופכת לציבורית, כדי לחקור איך היא משפיעה על Apigee, לפתח תיקונים או אמצעי הגנה ולהכין עצות והודעות ללקוחות. כשאפשר, Google מתקנת את כל האשכולות (ב-Apigee X) לפני שהמידע על נקודת החולשה מתפרסם. ב-Apigee Hybrid, גרסאות תיקון זמינות באופן קבוע כדי לטפל בנקודות חולשה באבטחה בקובצי אימג' של קונטיינרים, ואנחנו ממליצים ללקוחות להישאר מעודכנים בגרסאות התיקון האחרונות.
איך נקודות החולשה מסווגות
אנחנו משקיעים הרבה בהקשחת האבטחה של כל המערכת של Apigee, כולל קובץ האימג' הבסיסי, ספריות של צד שלישי ותוכנות של אפליקציות של צד ראשון, בנוסף להגדרת ברירות מחדל טובות, הגדרות אבטחה מוקשחות ורכיבים מנוהלים. המאמצים המשולבים האלה עוזרים לצמצם את ההשפעה והסבירות של נקודות חולשה.
צוות האבטחה של Apigee מסווג את נקודות החולשה לפי Common Vulnerability Scoring System (CVSS).
בטבלה הבאה מתוארות קטגוריות החומרה של נקודות החולשה:
| רמת החומרה | תיאור |
| קריטית | נקודת חולשה שקל לנצל בכל האשכולות על ידי תוקף מרוחק לא מאומת, שמובילה לפגיעה מלאה במערכת. |
| גבוהה | נקודת חולשה שקל לנצל בהרבה אשכולות, שמובילה לאובדן הסודיות, התקינות או הזמינות. |
| בינוני | פרצת אבטחה שניתן לנצל בחלק מהאשכולות, שבהם אובדן הסודיות, התקינות או הזמינות מוגבל על ידי הגדרות נפוצות, קושי בניצול הפרצה עצמה, הגישה הנדרשת או אינטראקציה של המשתמש. |
| נמוכה | כל שאר נקודות החולשה. לא סביר שמישהו ינצל את הפרצה, או שההשלכות של ניצול הפרצה מוגבלות. |
איך אנחנו מעדכנים על נקודות חולשה ותיקונים
המטרה של Google היא לצמצם את נקודות החולשה שזוהו בפרק זמן שמתאים לסיכונים שהן מייצגות. Apigee נכלל ב-ATO הזמני של FedRAMP ב-Google Cloud, שמחייב לתקן נקודות חולשה ידועות בפרקי זמן ספציפיים בהתאם לרמת החומרה שלהן, כמו שמוצג ב- FedRAMP Continuous Monitoring Performance Management Guide. ה-ATO הזמני של Google Cloud ב-FedRAMP לא כולל רכיבים של מישור הנתונים של Apigee hybrid (בניהול הלקוח), אבל אנחנו שואפים לאותם לוחות זמנים לתיקון במוצרים האלה.
נקודות חולשה שזוהו בסריקה יזומה
Google מזהה נקודות חולשה באבטחה באמצעות סריקה יזומה של הקבצים הבינאריים ושל התשתית הבסיסית שמארחת את פלטפורמת Apigee. אנחנו מפיצים באופן קבוע עדכוני תיקונים ל-Apigee כדי לטפל בנקודות החולשה האלה בזמן, בהתאם לחומרת ה-CVE הבסיסיים. כדי לתקן נקודת חולשה, צריך לשדרג לגרסה חדשה של Apigee Hybrid – שדרוג לגרסה משנית או שדרוג לגרסת תיקון, בהתאם לאופי של נקודת החולשה. בדרך כלל, נקודות חולשה כאלה מטופלות במסגרת תיקונים חודשיים ל-Apigee Hybrid, ונכללות בעדכוני התוכנה הרגילים לצי המנוהל שלנו במקרה של Apigee X. תיקוני אבטחה מפורסמים בנתוני הגרסה של Apigee X ושל Apigee hybrid.
כדי לתקן חלק מנקודות החולשה, צריך רק לשדרג את מישור הבקרה, ו-Google מבצעת את השדרוג הזה באופן אוטומטי ב-Apigee. כדי לתקן נקודות חולשה אחרות, צריך להשיק קבצים בינאריים חדשים במישור הנתונים. ב-Apigee X, Google דואגת לפרוס את הקבצים הבינאריים החדשים בכל הצי. לקוחות שמריצים את Apigee Apigee hybrid צריכים להחיל את גרסת התיקון על אשכולות Apigee hybrid שלהם כדי להשיק את הקבצים הבינאריים המעודכנים.
כדי להגן על האשכולות מפני נקודות חולשה בכל רמות החומרה, מומלץ להחיל את גרסת התיקון האחרונה על כל גרסה משנית של Apigee hybrid. אם אתם מריצים את Apigee Hybrid ב-Anthos, מומלץ לשדרג את רכיבי Anthos לפחות פעם בחודש.
נקודות חולשה שדווחו על ידי לקוחות
ב-Apigee Hybrid, הלקוחות מקבלים קובצי Apigee בינאריים להרצה במרכזי הנתונים שלהם או בפלטפורמות הענן המועדפות עליהם. כחלק מתקני האבטחה של הלקוחות להשקת תוכנה בסביבת הייצור במרכזי הנתונים שלהם, הם יכולים להריץ סדרה של בדיקות אבטחה. הבדיקות האלה יכולות לכלול בדיקות חדירה, סריקת קונטיינרים, סריקת קוד סטטי וכו'. יכול להיות שבבדיקות האלה ידווחו נקודות חולשה אפשריות בתוכנת Apigee. לפני שהלקוחות מפעילים את החבילות האלה במרכזי הנתונים שלהם, הם צריכים לקבוע אם אפשר לנצל את הפריטים שדווחו, ולכן הם מהווים סיכון אבטחה.
פרצת אבטחה עם הוכחת היתכנות (PoC) לניצול לרעה
אם הלקוח מזהה נקודת חולשה שניתן לנצל ויש לו הוכחת היתכנות (POC) שמדגימה איך לנצל את נקודת החולשה, הוא צריך לדווח על הבעיה דרך תוכנית התגמולים על זיהוי נקודות חולשה באבטחה של Google, בכתובת goo.gle/vulnz. הדיווח על הבעיה יישלח לצוות האבטחה של Google, שיאמת את הוכחת ההיתכנות ויקבע את חומרת הבעיה ואת ההשפעה הפוטנציאלית שלה. לאחר מכן הבעיה תועבר לטיפול של Apigee. יכול להיות שהלקוח זכאי לפרס במסגרת תוכנית VRP.
נקודת חולשה שזוהתה על ידי כלי אוטומטי
אם הלקוח יצר דוח על נקודות חולשה אפשריות במוצר של Apigee על סמך סריקה סטטית או כלי או טכניקה אחרים, אבל אין לו הוכחת היתכנות(PoC) לגבי ניצול הבעיות, אפשר לדווח על הפריטים האלה לתמיכה דרך פורטל התמיכה של Google Cloud. כשמדווחים על הבעיה לתמיכה, הלקוח מקבל מספר כרטיס למעקב ויכול לראות עדכונים ותגובות לדיווח. צוות התמיכה יעביר את הבעיות שדווחו לטיפול ברמה גבוהה יותר בתוך הארגון, לפי הצורך.
מזהי CVE
הלקוחות צריכים לכלול כמה שיותר מידע על נקודת החולשה, ובמיוחד את מזהה ה-CVE, שם הספרייה או החבילה, שם קובץ האימג' של הקונטיינר וכו' לכל פריט. מספרי CVE מאפשרים לנו לדעת שאנחנו מסתכלים על אותה נקודת חולשה. אם תספקו רק תיאור של הבעיה או מספר מעקב קנייני אחר, לא נוכל לקשר בין הבעיה לבין כלי הזיהוי או תהליכי הדיווח. בלי CVE, יכול להיות ש-Google לא תוכל להגיב לפריט הספציפי.
תשובה
לגבי פריטים שדווחו לתמיכה עם ציון חומרה "קריטי" או "גבוה", הלקוחות יכולים לצפות לתגובה דרך מערכת כרטיסי התמיכה. לגבי פריטים שדווחו ל-VRP, עיינו בכללים ובמסמכים שסופקו על ידי התוכנית.