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