במאמר הזה מוסבר איך Google מנהלת פרצות אבטחה ותיקונים ב-Apigee hybrid. אלא אם צוין אחרת, Apigee כולל גם את מישור הניהול וגם את מישור הנתונים.
אחריות משותפת לתיקון באגים
הטלאים הם באחריות משותפת של Google והלקוח. ב-Apigee X וב-Apigee Hybrid יש חלוקת אחריות שונה, כי מישור הנתונים ב-Apigee Hybrid מנוהל באופן מלא על ידי הלקוח. מידע על האחריות המשותפת ב-Apigee Hybrid זמין במאמר בנושא מודל האחריות המשותפת ב-Apigee Hybrid.
איך מתגלים נקודות חולשה
Google נוקטת גישה פרואקטיבית לאבטחת מערכות תוכנה, תוך שימוש בעקרונות של 'אבטחה כברירת מחדל' והטמעה של שיטות שונות לחיזוק האבטחה.
לדוגמה, אפליקציות מבוססות-קונטיינר מפעילות את התכונות השונות של Apigee API Management Platform. האפליקציות בקונטיינרים נפרסות ב-Kubernetes. תמונות הקונטיינר מבוססות על תמונות בסיס מינימליות (לדוגמה, תמונות בסיס ללא הפצה) כדי להשיג אבטחה מקסימלית וביצועים משופרים.
עם זאת, גם במערכות תוכנה שתוכננו בצורה הכי טובה יכולות להיות נקודות חולשה. כדי למצוא את נקודות החולשה האלה ולתקן אותן לפני שגורמים זדוניים יוכלו לנצל אותן, Google השקיעה משאבים רבים בתחומים שונים.
סורקי אבטחה
Google מזהה ומתקנת נקודות חולשה באופן יזום בסוגים שונים של קובצי אימג' של קונטיינרים:
- קונטיינרים של צד ראשון: קובצי אימג' של קונטיינרים שנוצרו והופצו על ידי Google כחלק מפלטפורמת Apigee. אלה אפליקציות קנייניות של Google שמפעילות את פלטפורמת Apigee API Management, כולל פונקציות ליבה כמו ניתוב תנועה, ניהול מכסות וניהול מפתחות.
- קונטיינרים של צד שלישי: קובצי אימג' של קונטיינרים שנבנו על ידי קהילת הקוד הפתוח, אבל מופצים על ידי 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 Continuous Monitoring. האישור הזמני של Google Cloud ל-ATO (Authority to Operate) בהתאם ל-FedRAMP לא כולל רכיבי מישור נתונים היברידיים של Apigee (בניהול הלקוח), אבל אנחנו שואפים לאותם פרקי זמן לתיקון במוצרים האלה.
נקודות חולשה שזוהו על ידי סריקה יזומה
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 היברידי, הלקוחות מקבלים קבצים בינאריים של Apigee להפעלה במרכזי הנתונים שלהם או בפלטפורמות הענן המועדפות עליהם. כחלק מסטנדרטים של לקוח להשקת תוכנה בייצור במרכזי הנתונים שלו, הוא עשוי להריץ סדרה של בדיקות אבטחה. הבדיקות האלה יכולות לכלול בדיקות חדירה, סריקת קונטיינרים, סריקת קוד סטטי וכו'. הבדיקות האלה עשויות לדווח על נקודות חולשה אפשריות בתוכנת Apigee. לפני שהלקוחות מפעילים את החבילות האלה במרכזי הנתונים שלהם, הם צריכים לקבוע אם אפשר לנצל את הפריטים שדווחו, ולכן הם מהווים סיכון אבטחה.
פגיעות עם הוכחת היתכנות לניצול
אם הלקוח מזהה פגיעות שאפשר לנצל ויש לו הוכחת היתכנות (POC) לגבי ניצול הפגיעות, הוא צריך לדווח על הבעיה הזו דרך תוכנית התמריצים של Google לאיתור פגיעות, שזמינה בכתובת goo.gle/vulnz. הפעולה הזו תדווח על הבעיה לצוות האבטחה של Google, שיאמת את הוכחת ההיתכנות ויקבע את חומרת הבעיה ואת ההשפעה הפוטנציאלית שלה. הבעיה תועבר לטיפול ברמה גבוהה יותר ב-Apigee. יכול להיות שהלקוח עומד בדרישות לקבלת תגמול במסגרת תוכנית VRP.
נקודת חולשה שזוהתה על ידי כלי אוטומטי
אם הלקוח יצר דוח על נקודות חולשה אפשריות במוצר Apigee על סמך סריקה סטטית או כלי או טכניקה אחרים, אבל אין לו הוכחות לגבי דרכים לנצל את הבעיות, הוא יכול לדווח על הפריטים האלה לתמיכה דרך פורטל התמיכה של Google Cloud. הלקוח יכול לדווח על הבעיה לתמיכה ולקבל מספר כרטיס למעקב, כדי לראות עדכונים ותשובות לדוח. צוות התמיכה יעביר את הבעיות שדווחו לטיפול ברמה גבוהה יותר בתוך Google, בהתאם לצורך.
מזהי CVE
הלקוחות צריכים לכלול כמה שיותר מידע על הפגיעות, ובאופן ספציפי לכלול את מזהה ה-CVE, שם הספרייה או החבילה, שם תמונת הקונטיינר וכו'. מספרי CVE מאפשרים לנו לדעת שאנחנו בודקים את אותה נקודת חולשה. אם תספקו רק תיאור של הבעיה או מספר מעקב קנייני אחר, לא נוכל לקשר את הבעיה בין כלי זיהוי או תהליכי דיווח שונים. ללא CVE, יכול להיות ש-Google לא תוכל להגיב לפריט הספציפי.
תשובה
לקוחות שמדווחים על פריטים לתמיכה עם ציון חומרה קריטי או גבוה יכולים לצפות לתשובה דרך מערכת הכרטיסים לתמיכה. לגבי פריטים שדווחו ל-VRP, אפשר לעיין בכללים ובמסמכים שסופקו על ידי התוכנית.