אתם יכולים להשתמש ב-Patch כדי להחיל תיקונים של מערכת ההפעלה (OS) על קבוצה של מכונות וירטואליות (VM) ב-Compute Engine. מכונות וירטואליות שפועלות לאורך זמן דורשות עדכוני מערכת תקופתיים כדי להגן מפני פגמים ונקודות חולשה.
לתכונה "תיקון" יש שני רכיבים עיקריים:
- דיווח על תאימות לתיקונים, שנותן תובנות על סטטוס התיקונים של המכונות הווירטואליות בהפצות של Windows ו-Linux. בנוסף לתובנות, אתם יכולים לראות גם המלצות למכונות הווירטואליות.
- פריסת תיקונים, שמאפשרת להפוך את תהליך העדכון של מערכת ההפעלה ותיקוני התוכנה לאוטומטי. פריסת תיקונים מתזמנת משימות תיקון. משימת תיקון פועלת במכונות וירטואליות ומחילה תיקונים.
יתרונות
שירות התיקונים מאפשר לכם לבצע את התהליכים הבאים:
- ליצור אישורים לתיקונים. אתם יכולים לבחור אילו תיקונים להחיל על המערכת מתוך קבוצת העדכונים המלאה שזמינה למערכת ההפעלה הספציפית.
- להגדיר לוח זמנים גמיש. אתם יכולים לבחור מתי להריץ עדכוני תיקונים (לוחות זמנים חד-פעמיים וחוזרים).
- להחיל הגדרות מתקדמות של תיקונים. אתם יכולים להתאים אישית את התיקונים על ידי הוספת הגדרות, כמו סקריפטים לפני ואחרי התיקון.
- לנהל את העדכונים או את הטמעות התיקונים האלה ממיקום מרכזי. אתם יכולים להשתמש בלוח הבקרה של Patch כדי לעקוב אחרי משימות התיקון וסטטוס התאימות ולדווח עליהם.
מערכות הפעלה נתמכות
בפרטים על מערכות ההפעלה תוכלו למצוא את הרשימה המלאה של מערכות ההפעלה והגרסאות שתומכות ב-Patch.
תמחור
איך פועל Patch
כדי להשתמש בתכונה Patch, צריך להגדיר את OS Config API ולהתקין את סוכן OS Config. הוראות מפורטות מופיעות במאמר הגדרת VM Manager. שירות OS Config מאפשר לנהל תיקונים בסביבה שלכם, וסוכן OS Config משתמש במנגנון העדכון של כל מערכת הפעלה כדי להחיל תיקונים. העדכונים נשלפים ממאגרי החבילות (שנקראים גם חבילת מקור ההפצה) או ממאגר מקומי של מערכת ההפעלה.
כלי העדכון הבאים משמשים להחלת תיקונים:
- Red Hat Enterprise Linux (RHEL), Rocky Linux ו-CentOS –
yum upgrade - Debian ו-Ubuntu –
apt upgrade - SUSE Linux Enterprise Server (SLES) –
zypper update - Windows – סוכן Windows Update
מקורות של תיקונים וחבילות
כדי להשתמש בתכונה Patch ב-VM Manager, למכונה הווירטואלית צריכה להיות גישה לעדכוני החבילות או לתיקונים. שירות התיקונים לא מארח או מתחזק עדכוני חבילות או תיקונים. במקרים מסוימים, יכול להיות שלמכונה הווירטואלית לא תהיה גישה לעדכונים. לדוגמה, אם למכונה הווירטואלית אין כתובות IP ציבוריות או אם אתם משתמשים ברשת VPC פרטית. במקרים כאלה, צריך לבצע שלבים נוספים כדי לאפשר גישה לעדכונים או לתיקונים. עומדות לרשותך כמה אפשרויות:
- Google ממליצה לארח מאגר מקומי משלכם או שירות Windows Server Update Service כדי לקבל שליטה מלאה על קו הבסיס של התיקונים.
- לחלופין, אתם יכולים להשתמש ב-Cloud NAT או בשירותי proxy אחרים כדי להפוך מקורות עדכון חיצוניים לזמינים למכונות הווירטואליות.
ניהול התיקונים מורכב משני שירותים: פריסת תיקונים ותאימות תיקונים. כל אחד מהשירותים מוסבר בקטעים הבאים.
סקירה כללית על פריסת תיקונים
כדי להתחיל פריסת תיקון, צריך לשלוח קריאה ל-VM Manager API (שנקרא גם OS Config API). אפשר לעשות את זה באמצעות מסוףGoogle Cloud , Google Cloud CLI או קריאה ישירה ל-API. לאחר מכן, ה-VM Manager API מודיע לסוכן OS Config שפועל במכונות הווירטואליות המטורגטות להתחיל בתיקון.
סוכן OS Config מריץ את התיקון בכל מכונה וירטואלית באמצעות הכלי לניהול תיקונים שזמין לכל הפצה. לדוגמה, במכונות וירטואליות של Ubuntu משתמשים בכלי השירות apt. כלי השירות מאחזר עדכונים (תיקונים) ממקור ההפצה של מערכת ההפעלה. בזמן שהתיקון מתבצע, סוכן OS Config מדווח על ההתקדמות ל-VM Manager API.
סקירה כללית על תאימות תיקונים
אחרי שמגדירים את VM Manager במכונה וירטואלית, מתרחשים בה הדברים הבאים:
- סוכן OS Config מדווח מדי פעם (בערך כל 10 דקות) על נתוני המלאי של מערכת ההפעלה .
- מערכת ה-backend של תאימות התיקונים קוראת את הנתונים האלה מדי פעם, מצליבה אותם עם המטא-נתונים של החבילה שהתקבלו מהפצת מערכת ההפעלה ושומרת אותם.
- Google Cloud לאחר מכן, מסוף מקבל את נתוני התאימות של התיקונים ומציג את המידע הזה במסוף.
איך נוצרים נתוני התאימות של התיקונים
מערכת הקצה העורפי של תאימות התיקונים מבצעת מדי פעם את המשימות הבאות:
- קריאת הדוחות שנאספים מנתוני המלאי של מערכת ההפעלה במכונה וירטואלית.
סורק נתוני סיווג ממקור נקודת החולשה לכל מערכת הפעלה, ומסדר את הנתונים האלה לפי חומרה (מהגבוהה לנמוכה).
בטבלה הבאה מפורטים מקורות נקודות החולשה שמשמשים לכל מערכת הפעלה.
מערכת הפעלה חבילת המקור של נקודת החולשה RHEL ו-CentOS https://access.redhat.com/security/data תוצאות סריקת נקודות החולשה של RHEL מבוססות על גרסת המשנה האחרונה של כל גרסה ראשית שהושקה. יכול להיות שיהיו אי-דיוקים בתוצאות הסריקה של גרסאות משניות ישנות יותר של RHEL.
Debian https://security-tracker.debian.org/tracker Ubuntu https://launchpad.net/ubuntu-cve-tracker SLES https://www.suse.com/support/update/ Rocky Linux https://errata.rockylinux.org/ Windows ה-backend של תאימות התיקונים מקבל את נתוני הסיווג מ-Windows Update Agent API. ממפה את הסיווגים האלה (שסופקו על ידי מקור נקודת החולשה) לסטטוס התאימות לתיקון של Google.
בטבלה הבאה מפורטת מערכת המיפוי שמשמשת ליצירת סטטוס התאימות של Google לתיקוני באגים.
קטגוריות של מקורות הפצה סטטוס התאימות של Google לתיקונים - קריטית
- דחוף
- WINDOWS_CRITICAL_UPDATE
קריטי (אדום) - חשוב
- גבוהה
- WINDOWS_SECURITY_UPDATE
חשוב/אבטחה (כתום) - כל השאר
אחר (צהוב) - אין עדכונים זמינים
עדכני (ירוק) המערכת בוחרת את נתוני החומרה הגבוהה ביותר לכל עדכון זמין ומציגה אותם בדף מרכז הבקרה של מסוף Google Cloud . אפשר גם לראות דוח מלא של כל העדכונים הזמינים למכונה הווירטואלית בדף הפרטים של המכונה הווירטואלית.
לדוגמה, אם נתוני המלאי של מערכת ההפעלה של מכונה וירטואלית עם RHEL 7 כוללים את נתוני החבילה הבאים:
- שם החבילה: package1
- הגרסה המותקנת: 1.4
- גרסת העדכון: 2.0
ה-backend של תאימות התיקונים סורק את נתוני הסיווג (מההפצה של המקור) ומאחזר את המידע הבא:
- גרסה 1.5 => קריטי, תיקון CVE-001
- גרסה 1.8 => נמוכה, מתקנת את CVE-002
- גרסה 1.9 => נמוכה, מתקנת את CVE-003
לאחר מכן, בלוח הבקרה של מסוף Google Cloud , המכונה הווירטואלית של RHEL 7 מתווספת לרשימת המכונות הווירטואליות שיש להן עדכון זמין של Critical. אם תבדקו את הפרטים של המכונה הווירטואלית הזו, תראו עדכון אחד של Critical שזמין (גרסה 2.0) עם 3 נקודות חולשה, CVE-001, CVE-002 ו-CVE-003.
תיקון בו-זמני
כשמפעילים משימת תיקון, השירות משתמש במסנן המכונות שסיפקתם כדי לקבוע אילו מכונות ספציפיות יתוקנו. מסנני מכונות מאפשרים לתקן כמה מכונות בו-זמנית. הסינון הזה מתבצע כשהטמעת התיקון מתחילה, כדי להביא בחשבון שינויים בסביבה אחרי שהמשימה תוזמנה.
תיקון מתוזמן
אפשר להפעיל תיקונים לפי דרישה, לתזמן אותם מראש או להגדיר אותם עם לוח זמנים קבוע. אפשר גם לבטל משימת תיקון שמתבצעת אם צריך להפסיק אותה באופן מיידי.
כדי להגדיר חלונות זמן לתחזוקת תיקונים, אתם יכולים ליצור פריסות של תיקונים בתדירות ובמשך זמן מסוימים. תזמון של משימות תיקון עם משך זמן מוגדר מבטיח שמשימות התיקון לא יתחילו מחוץ לחלון הזמן לתחזוקה שהגדרתם.
אתם יכולים גם לאכוף מועדים אחרונים להתקנת תיקונים, על ידי יצירת פריסות של תיקונים שצריך להשלים בזמן מסוים. אם המכונות הווירטואליות המטורגטות לא יעודכנו עד לתאריך הזה, הפריסה המתוזמנת תתחיל להתקין את התיקונים בתאריך הזה. אם כבר הותקנו תיקונים במכונות הווירטואליות, לא תתבצע בהן שום פעולה, אלא אם צוין סקריפט לפני או אחרי התיקון או שנדרשת הפעלה מחדש.
מה נכלל בהטמעת תיקון?
כשמשימת תיקון פועלת במכונה וירטואלית, מוחל שילוב של עדכונים בהתאם למערכת ההפעלה. אתם יכולים לבחור לעדכן חבילות או עדכונים ספציפיים, או לציין את מזהי ה-KB שאתם רוצים לעדכן במערכות ההפעלה של Windows.
אפשר גם להשתמש במשימת תיקון כדי לעדכן את כל הסוכנים של Google שמותקנים כחבילה רגילה להפצה הספציפית הזו. משתמשים בכלי העדכון של ההפצה הזו כדי לשלוח שאילתות לגבי החבילות הזמינות. לדוגמה, כדי לראות את הסוכנים הזמינים של Google למערכת ההפעלה Ubuntu, מריצים את הפקודה apt list --installed | grep -P 'google'.
Windows
במערכת ההפעלה Windows, אפשר להחיל את כל העדכונים הבאים או לבחור מביניהם:
- עדכוני הגדרות
- עדכוני דרייברים
- עדכונים לגבי חבילות תכונות
- עדכוני אבטחה
- עדכונים לגבי הכלים
RHEL/Rocky/CentOS
במערכות ההפעלה Red Hat Enterprise Linux, Rocky Linux ו-CentOS, אפשר להחיל את כל העדכונים הבאים או לבחור מביניהם:
- עדכוני מערכת
- עדכוני אבטחה
Debian/Ubuntu
במערכות Debian ו-Ubuntu, אפשר להחיל את כל העדכונים הבאים או לבחור מביניהם:
- עדכונים לגבי הפצה
- עדכונים של הכלי לניהול חבילות
SUSE
במערכות ההפעלה SUSE Enterprise Linux Server (SLES) ו-openSUSE, אפשר להחיל את כל העדכונים הבאים או לבחור מביניהם:
- עדכונים של חבילות מערכת
- תיקוני Zypper (תיקוני באגים ספציפיים ותיקוני אבטחה)
גישה לסיכום התיקונים של המכונות הווירטואליות
כדי לראות את סיכום התיקונים של המכונות הווירטואליות, אתם יכולים להשתמש באפשרויות הבאות:
כדי לראות את סיכום המידע על תיקונים לכל המכונות הווירטואליות בארגון או בתיקייה, השתמשו במרכז הבקרה של התיקונים במסוף Google Cloud . איך רואים את סיכום התיקונים של מכונות וירטואליות
כדי לראות את הסטטוס של משימות התיקונים, משתמשים בדף Patch jobs במסוף Google Cloud . אפשר גם להשתמש ב-Google Cloud CLI או ב-OS Config API. מידע נוסף זמין במאמר ניהול משימות תיקון.
כדי להציג מידע אחר, כמו עדכונים של חבילות מערכת ההפעלה ודוחות על נקודות חולשה, קראו את המאמר הצגת פרטים של מערכת ההפעלה.
מרכז הבקרה של Patch
במסוף Google Cloud יש לוח בקרה שבו אפשר לעקוב אחרי התאימות של התיקונים במכונות הווירטואליות.
פרטי מרכז הבקרה של Patch
בקטעים הבאים מוסבר איך המכונות הווירטואליות מקובצות בלוח הבקרה של Patch, ואיך מדווח סטטוס התאימות של התיקונים.
סקירה כללית על מערכת ההפעלה
בקטע הזה מוצג המספר הכולל של המכונות הווירטואליות, לפי מערכת הפעלה. כדי שמכונה וירטואלית תופיע ברשימה הזו, צריך להתקין בה את סוכן OS Config ולהפעיל בה את ניהול המלאי של מערכת ההפעלה.
אם במכונה וירטואלית מסוימת מופיע הערך No data במערכת ההפעלה, יכול להיות שאחד או יותר מהתרחישים הבאים נכונים:
- המכונה הווירטואלית לא מגיבה.
- סוכן OS Config לא מותקן.
- ניהול מלאי מערכת ההפעלה לא מופעל.
- מערכת ההפעלה לא נתמכת. כאן תוכלו למצוא רשימה של מערכות ההפעלה הנתמכות.
- המכונה הווירטואלית היא מכונה שמנוהלת על ידי Google, שבה VM Manager מושבת כברירת מחדל. הסטטוס הזה צפוי ולא נדרשת פעולה מצידכם. מידע נוסף זמין במאמר סטטוס התיקונים של מכונות וירטואליות בניהול Google.
סטטוס העמידה בדרישות של תיקון
בלוח הבקרה "תיקונים" מוצג כרטיס סטטוס תאימות לכל מערכת הפעלה:
סטטוס התאימות מחולק לארבע קטגוריות עיקריות:
- קריטי: יש עדכונים קריטיים זמינים למכונה וירטואלית.
- חשוב או אבטחה: יש עדכוני אבטחה או עדכונים חשובים זמינים למכונה הווירטואלית.
- אחר: יש עדכונים זמינים למכונה הווירטואלית, אבל אף אחד מהם לא מסווג כעדכון קריטי או כעדכון אבטחה.
- Up-to-date: אין עדכונים זמינים למכונה הווירטואלית.
סטטוס התיקונים במכונות וירטואליות שמנוהלות על ידי Google
במכונות וירטואליות מסוימות שמנוהלות על ידי Google בפרויקט שלכם, תמיד מדווח No data בלוח הבקרה של Patch, כי VM Manager מושבת בהן כברירת מחדל. הסטטוס הזה צפוי ולא נדרשת פעולה מצידכם. ב-VM Manager, כל המכונות הווירטואליות שמנוהלות על ידי Google בפרויקט שלכם נחשבות למכונות וירטואליות רגילות, והן נכללות בלוח הבקרה של Patch. בהתאם לשירות שיוצר את המכונה הווירטואלית, VM Manager מושבת כברירת מחדל או פועל באותו אופן כמו במכונות הווירטואליות שאתם מנהלים. כאשר VM Manager מושבת כברירת מחדל במכונה וירטואלית שמנוהלת על ידי Google, סוכן OS Config לא מופעל במכונה הווירטואלית, ו-VM Manager לא מריץ בה משימות הטמעת תיקון או כללי מדיניות של מערכת ההפעלה.
בטבלה הבאה מתואר איך מכונות וירטואליות שמנוהלות על ידי Google משתלבות עם VM Manager:
| פלטפורמה | סטטוס ההפעלה של VM Manager | ההתנהגות הצפויה |
|---|---|---|
| סביבה גמישה ב-App Engine | מושבת במטא-נתונים | סוכן OS Config לא מופעל במכונות הווירטואליות האלה, ולכן הן תמיד מדווחות על No data. VM Manager לא מריץ משימות תיקון או כללי מדיניות של מערכת ההפעלה במכונות הווירטואליות האלה. |
| מחבר גישה ל-VPC ללא שרת (serverless) | מושבת בקובץ האימג' של מערכת ההפעלה | סוכן OS Config לא מופעל במכונות הווירטואליות האלה, ולכן הן תמיד מדווחות על No data. VM Manager לא מריץ משימות תיקון או כללי מדיניות של מערכת ההפעלה במכונות הווירטואליות האלה. |
| Managed Service for Apache Spark ללא שרת (serverless) | מושבת בקובץ האימג' של מערכת ההפעלה | סוכן OS Config לא מופעל במכונות הווירטואליות האלה, ולכן הן תמיד מדווחות על No data. VM Manager לא מריץ משימות תיקון או כללי מדיניות של מערכת ההפעלה במכונות הווירטואליות האלה. |
| אשכולות של Managed Service for Apache Spark עם אימות אישי | מושבת בקובץ האימג' של מערכת ההפעלה | סוכן OS Config לא מופעל במכונות הווירטואליות האלה, ולכן הן תמיד מדווחות על No data. VM Manager לא מריץ משימות תיקון או כללי מדיניות של מערכת ההפעלה במכונות הווירטואליות האלה. |
| Cloud TPU עם ארכיטקטורת VM אחת | לא מושבתת | VM Manager פועל באותו אופן כמו במכונות וירטואליות שאתם מנהלים. |
| Google Kubernetes Engine (GKE) Autopilot | לא מושבתת | VM Manager פועל באותו אופן כמו במכונות וירטואליות שאתם מנהלים. |
מגבלות
לתכונה "תיקון" ב-VM Manager יש את המגבלות הבאות:
- אפשר לפרוס ולהריץ משימות תיקון רק למכונות וירטואליות בפרויקט אחד ב- Google Cloud . אי אפשר להריץ משימות תיקונים בפרויקטים של Google Cloud , גם אם המכונות הווירטואליות נמצאות ב-VPC משותף. עם זאת, אתם יכולים לראות את נתוני התאימות של התיקונים בפרויקטים שונים.
- כברירת מחדל, VM Manager לא מתקין תיקונים במכונות וירטואליות שהן חלק מקבוצת מופעי מכונה מנוהלים (MIG). אפשר לשנות את פעולת ברירת המחדל הזו כשיוצרים את משימת התיקון.
המגבלות הבאות חלות כשמתקינים תיקונים במכונות וירטואליות שהן חלק מ-MIG:
- כשקבוצת MIG מתקנת מכונה וירטואלית, היא יוצרת מחדש את המכונה הווירטואלית על סמך תבנית של הגדרות מכונה. יכול להיות שהפעולה הזו תחזיר את המכונה הווירטואלית למצב שבו התיקון לא הותקן.
- תיקון של מכונות וירטואליות יכול לגרום לתוצאות לא צפויות בקבוצת מכונות מנוהלת שמופעלת בה התאמה לעומס. מידרוג אוטומטי מוחק מכונות וירטואליות שתוקנו כשהעומס יורד, ויוצר מכונות וירטואליות חדשות שלא תוקנו באמצעות התבנית של הגדרות המכונה של ה-MIG כשהעומס עולה. לדוגמה, אם ניצול המעבד (CPU) הממוצע נמוך מהניצול שציינתם כיעד להתאמה אוטומטית לעומס, קבוצת ה-MIG יכולה להסיר חלק מה-VMs המתוקנים בזמן הצמצום האופקי בהתאם לעומס.
- VM Manager לא מפעיל משימות תיקון או כללי מדיניות של מערכת ההפעלה במכונות וירטואליות מסוימות שמנוהלות על ידי Google, כי סוכן OS Config לא מופעל בהן בכוונה. דוגמאות למכונות וירטואליות כאלה: סביבה גמישה ב-App Engine, חיבור לרשת VPC ומכונות של Managed Service for Apache Spark. המכונות הווירטואליות האלה תמיד מופיעות כ-No data בלוח הבקרה של Patch, וזה צפוי ולא נדרשת פעולה. מידע נוסף זמין במאמר סטטוס התיקונים של מכונות וירטואליות בניהול Google.