במאמר הזה מוסבר איך 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 גם מוצא ומתקן באופן קבוע נקודות חולשה במכונה וירטואלית מבוססת-Kernel (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 הזמני של Google Cloud ב-FedRAMP, שדורש תיקון של נקודות חולשה ידועות בתוך מסגרות זמן ספציפיות בהתאם לרמת החומרה שלהן, כפי שמוצג ב מדריך לניהול ביצועים של ניטור רציף ב-FedRAMP. האישור הזמני של Google Cloud ל-ATO ב-FedRAMP לא כולל רכיבי מישור נתונים של Apigee Hybrid (בניהול הלקוח), אבל אנחנו שואפים לאותם מסגרות זמן לתיקון במוצרים האלה.
נקודות חולשה שזוהו על ידי סריקה יזומה
Google מזהה נקודות חולשה באבטחה באמצעות סריקה יזומה של הקבצים הבינאריים ושל התשתית הבסיסית שמארחת את פלטפורמת Apigee. Apigee מפרסמת עדכוני תיקון באופן קבוע כדי לטפל בנקודות החולשה האלה בזמן, בהתאם לחומרה של CVE(ים) בסיסיים. תיקון פגיעות כולל שדרוג לגרסה חדשה של Apigee Hybrid – שדרוג לגרסה משנית או שדרוג לגרסת תיקון, בהתאם לאופי הפגיעות. הפגיעויות האלה מטופלות בדרך כלל במסגרת מהדורות תיקון חודשיות ל-Apigee hybrid, ונכללות בעדכוני התוכנה הרגילים של צי השרתים המנוהל שלנו במקרה של Apigee X. תיקוני אבטחה מפורטים בהערות לגבי הגרסה של Apigee X ושל Apigee Hybrid.
כדי לתקן חלק מהפגיעויות צריך רק לשדרג את מישור הבקרה, ו-Google מבצעת את השדרוג הזה באופן אוטומטי ב-Apigee. כדי לתקן פגיעויות אחרות צריך להפיץ קבצים בינאריים חדשים למישור הנתונים. במקרה של Apigee X, Google דואגת להפצת הקבצים הבינאריים החדשים לכל המערך. לקוחות שמריצים את Apigee Hybrid צריכים להחיל את גרסת התיקון על אשכולות Apigee Hybrid כדי להטמיע את הקבצים הבינאריים המעודכנים.
כדי להגן על האשכולות מפני נקודות חולשה בכל רמות החומרה, מומלץ להחיל את הגרסה האחרונה של התיקון לכל גרסה משנית נתונה של Apigee hybrid. למי שמפעיל Apigee hybrid ב-Anthos, Google ממליצה לשדרג את רכיבי Anthos לפחות פעם בחודש.
נקודות חולשה שדווחו על ידי לקוחות
ב-Apigee Hybrid, הלקוחות מקבלים קבצים בינאריים של Apigee להפעלה במרכזי הנתונים שלהם או בפלטפורמות הענן המועדפות עליהם. כחלק מסטנדרטים של לקוח להשקת תוכנה בייצור במרכזי הנתונים שלו, הוא עשוי להריץ סדרה של בדיקות אבטחה. הבדיקות האלה יכולות לכלול בדיקות חדירה, סריקת קונטיינרים, סריקת קוד סטטי וכו'. הבדיקות האלה עשויות לדווח על נקודות חולשה אפשריות בתוכנת Apigee. לפני שהלקוחות מפעילים את החבילות האלה במרכזי הנתונים שלהם, הם צריכים לקבוע אם אפשר לנצל את הפריטים שדווחו, ולכן הם מהווים סיכון אבטחה.
פגיעות עם הוכחת היתכנות לניצול
אם הלקוח מזהה פגיעות שאפשר לנצל ויש לו הוכחת היתכנות (POC) לגבי ניצול הפגיעות, הוא צריך לדווח על הבעיה הזו דרך תוכנית התמריצים של Google לאיתור פגיעות, שזמינה בכתובת goo.gle/vulnz. הפעולה הזו תדווח על הבעיה לצוות האבטחה של Google, שיאמת את הוכחת ההיתכנות ויקבע את חומרת הבעיה ואת ההשפעה הפוטנציאלית שלה. הבעיה תועבר לטיפול ברמה גבוהה יותר ב-Apigee. יכול להיות שהלקוח עומד בדרישות לקבלת תגמול במסגרת תוכנית VRP.
נקודת חולשה שזוהתה על ידי כלי אוטומטי
אם הלקוח יצר דוח על נקודות חולשה אפשריות במוצר Apigee על סמך סריקה סטטית או כלי או טכניקה אחרים, אבל אין לו הוכחות לגבי דרכים לנצל את הבעיות, הוא יכול לדווח על הפריטים האלה לתמיכה באמצעות פורטל התמיכה של Google Cloud. הלקוח יכול לדווח על הבעיה לתמיכה ולקבל מספר כרטיס למעקב, כדי לראות עדכונים ותשובות לדוח. צוות התמיכה יעביר את הבעיות שדווחו לטיפול ברמה גבוהה יותר, בהתאם לצורך.
מזהי CVE
הלקוחות צריכים לכלול כמה שיותר מידע על הפגיעות, ובאופן ספציפי לכלול את מזהה ה-CVE, שם הספרייה או החבילה, שם תמונת הקונטיינר וכו'. מספרי CVE מאפשרים לנו לדעת שאנחנו בודקים את אותה פגיעות. אם תספקו רק תיאור של הבעיה או מספר מעקב קנייני אחר, לא נוכל לקשר את הבעיה בין כלי זיהוי או תהליכי דיווח שונים. ללא מספר CVE, יכול להיות ש-Google לא תוכל להגיב לפריט הספציפי.
תשובה
לקוחות שמדווחים על פריטים לתמיכה עם ציון חומרה קריטי או גבוה יכולים לצפות לתשובה דרך מערכת הכרטיסים לתמיכה. לגבי פריטים שדווחו ל-VRP, אפשר לעיין בכללים ובמסמכים שסופקו על ידי התוכנית.