יכול להיות שחלק מהמידע בדף הזה או כולו לא רלוונטי ל-Cloud de Confiance by S3NS. פרטים נוספים מופיעים במאמר מה ההבדל מ-Google Cloud.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

מדריך לתפוגה של אישורים להפעלה מאובטחת של Microsoft

כמה אישורים של Microsoft Secure Boot יפוגו בשנת 2026, ולכן במאמר הזה מוסבר איך לעדכן את המופעים של מכונות וירטואליות מוגנות ב-Compute Engine כדי שהם יסתמכו על האישורים המעודכנים של Microsoft Secure Boot ל-UEFI (ממשק קושחה מאוחד וניתן להרחבה) Secure Boot. שני האישורים הקריטיים ביותר שמתקרבים למועד התפוגה שלהם הם Microsoft Corporation UEFI CA 2011 (תוקף האישור יפוג ב-27 ביוני 2026), שמשמש לחתימה על טועני אתחול של צד שלישי כמו Linux Shim, ו-Microsoft Windows Production PCA 2011, שתוקף האישור יפוג ב-19 באוקטובר 2026, ומשמש לחתימה על טוען האתחול של Windows.

הפעלה מאובטחת של UEFI היא תקן אבטחה שמשמש מכונות וירטואליות מוגנות כדי לוודא שרק תוכנה וקושחה מהימנות פועלות במהלך תהליך האתחול של המכונה הווירטואלית. כדי לתמוך בהפעלה מאובטחת במערכות הפעלה שונות, מיקרוסופט מנהלת אישורי UEFI ומאחסנת אותם במשתנים Key Exchange Key ‏ (KEK) ו-Allowed Signature Database ‏ (db) בקושחה של המופע.

אישורים של הפעלה מאובטחת ותאריכי תפוגה

שם האישור	תפקיד	תאריך תפוגה
Microsoft Corporation UEFI CA 2011	חתימה על טועני אתחול של צד שלישי, כמו Linux Shim	‫27 ביוני 2026
Microsoft Windows Production PCA 2011	חתימה על תוכנת האתחול של Windows	‫19 באוקטובר 2026
Microsoft Corporation KEK CA 2011	משמש לעדכון ה-DB וה-DBX	‫24 ביוני 2026

תוקף האישור הזה רלוונטי רק אם מופע החישוב שלכם עומד בשני התנאים המוקדמים הבאים:

תאריך היצירה: יצרתם את מופע המחשוב לפני 7 בנובמבר 2025 (התאריך שבו Compute Engine עדכן את אישורי אתחול מאובטח שמוגדרים כברירת מחדל בקושחת UEFI) ולא עדכנתם אותו.
מצב הפעלה מאובטחת: הפעלתם הפעלה מאובטחת במופע. Cloud de Confiance by S3NS ההפעלה המאובטחת לא מופעלת כברירת מחדל כשיוצרים מופע של מכונה וירטואלית מוגנת.

מופעים שיוצרים ב-7 בנובמבר 2025 ואילך כבר כוללים את האישורים המעודכנים במשתני הקושחה שלהם, בתנאי שהם משתמשים בתמונה שמסתמכת על קבוצת אישורי ברירת המחדל.

אם המופע שלכם לא עומד בשני התנאים המוקדמים, תפוגת האישור לא משפיעה עליו, ואין צורך לבצע פעולה כלשהי.

במאמר הזה מוסבר איך לזהות מקרים מושפעים ולבצע את העדכונים הנדרשים.

Cloud de Confiance by S3NS השלמנו את השקת האישורים החדשים ב-7 בנובמבר 2025. מופעים שתיצרו בתאריך הזה או אחריו מתמונות שמסתמכות על קבוצת ברירת המחדל של האישורים יכללו את האישורים המעודכנים במשתני ה-NVRAM/הקושחה שלהם (db ו-KEK) ולא ידרשו פעולה נוספת. עם זאת, יכול להיות שחלק מהמופעים שיצרתם בשבועות שלפני התאריך הזה יכללו גם את האישורים החדשים. כדי לבדוק אם המערכת שלכם עדכנית, אתם יכולים להשתמש בפקודות שבקטע אימות במסמך הזה.

הערה: תאריך התפוגה של אישור Secure Boot לא משפיע על הדברים הבאים:

מקרים שבהם ההפעלה המאובטחת לא מופעלת. שימו לב שאם אתם משתמשים ברישומים של הגדרות פלטפורמת vTPM (במיוחד PCR7) לאיטום סודות, כל עדכון של משתני UEFI או יצירה מחדש של המופע עדיין ישנו את המדידות של PCR7 גם אם האתחול המאובטח מושבת, למרות שהגדרות כאלה הן נדירות מאוד.
מופעים שמופעלת בהם מערכת הפעלה שמותאמת לקונטיינרים (COS).
מקרים שבהם משתמשים במשתני אתחול מאובטח מותאמים אישית (כמו PK,‏ KEK או db מותאמים אישית) ומטעין האתחול חתום באמצעות אישור מותאם אישית משלכם ולא באמצעות אישור UEFI CA 2011 של Microsoft Corporation שתוקפו פג. אם אתם משתמשים במפתחות מותאמים אישית אבל עדיין מסתמכים על רשות האישורים של מיקרוסופט שתוקף האישור שלה פג כדי לחתום על טוען האתחול, כדאי לעיין בדרישות לעדכון המפתחות במאמר Instances with custom PK or KEK configurations.

לגבי מופעי מחשוב שנוצרו לפני 7 בנובמבר 2025 ואין להם את האישורים המעודכנים, צריך לפעול לפי המדריך לעדכון KEK ו-db כדי לעדכן את האישורים. אם מסיבה כלשהי לא ניתן לעשות זאת, כדאי לשקול ליצור מחדש את המופעים.

איך פקיעת התוקף של אישור ההפעלה המאובטחת משפיעה על מכונה וירטואלית מוגנת

אם האפשרות הזו מופעלת, המכונה הווירטואלית המוגנת אוכפת הפעלה מאובטחת באמצעות קושחת UEFI, ששומרת על קבוצה של אישורים מהימנים (במשתנה db) כדי לאמת את החתימות של קובצי ההפעלה של רצף האתחול. לדוגמה, אם עדכון של מערכת ההפעלה מחליף תוכנת אתחול בתוכנת אתחול שנחתמה רק על ידי Microsoft UEFI CA 2023, והקושחה של מופע המחשוב לא נותנת אמון בסמכות של האישור הזה, האימות של האתחול המאובטח נכשל והאתחול המאובטח מפסיק את תהליך האתחול.

לפרטים נוספים על המעבר הזה, אפשר לעיין בהנחיות של מיקרוסופט ושל ספקי מערכות הפעלה אחרים:

ההשפעה על מערכת ההפעלה

אם הפעלתם את ההפעלה המאובטחת במכונה וירטואלית מוגנת שנוצרה לפני 7 בנובמבר 2025, מומלץ לוודא שהאישורים משנת 2023 מותקנים. אחרת, אם תחיל עדכון שמכיל תוכנת אתחול שחתום רק על ידי אישור Microsoft UEFI CA משנת 2023 (ולא חתום כפול עם האישור משנת 2011), עלולות להיות בעיות באתחול של מכונה. אם לא תבצעו פעולה, יכול להיות שלא תוכלו להחיל בעתיד עדכונים של טוען האתחול או של ליבת המערכת שמכילים קבצים בינאריים שנחתמו רק באמצעות האישור משנת 2023. הערה: ספקי מערכות ההפעלה מתכננים לחתום על עדכונים של טוען האתחול ושל shim באמצעות אישורים משנת 2011 ומשנת 2023, ולכן לא צפויים כשלים באתחול או חסימות של עדכונים באופן מיידי. לגבי מופעי מחשוב שנוצרו לפני 7 בנובמבר 2025: לקוחות Windows עשויים לראות את מזהה האירוע 1801 ("צריך לעדכן את אישורי ה-CA/המפתחות של אתחול מאובטח") ביומן האירועים של המערכת אם הם לא יישמו את עדכוני האישורים.

תמונות ציבוריות שסופקו על ידי Google: כדי לעדכן את האישורים של מסד הנתונים ושל KEK, צריך לפעול לפי המדריך לעדכון KEK ומסד הנתונים. לחלופין, אפשר ליצור מחדש מכונות וירטואליות שפועלות לטווח ארוך ושנוצרו לפני 7 בנובמבר 2025.
תמונות בהתאמה אישית או תמונות מיובאות: רוב התמונות בהתאמה אישית או התמונות המיובאות מסתמכות על אישורי אתחול מאובטח שמוגדרים כברירת מחדל. אם לא ביטלתם באופן מפורש את ההגדרה של משתני db או KEK Secure Boot כשנוצרה התמונה, התמונה משתמשת במערך מפתחות ברירת המחדל ולא נדרשת פעולה ברמת התמונה. ‫Compute Engine מספק אוטומטית את האישורים המעודכנים כשיוצרים מכונה מכל תמונה שמסתמכת על הגדרות ברירת המחדל האלה.

צריך לבצע פעולה רק אם הגדרתם במפורש משתנים מותאמים אישית של db או KEK Secure Boot (לדוגמה, כדי לכלול אישור של ספק אבטחה מצד שלישי לצד אישורי ברירת המחדל של מיקרוסופט) במטא-נתונים של התמונה במהלך תהליך build התמונה. הסיבה לכך היא שציון משתנה מותאם אישית db או KEK מבטל לחלוטין את ברירות המחדל (והמערכת מתעלמת ממפתחות ציבוריים שמוגדרים כברירת מחדל), ולכן יכול להיות שבמשתנים המותאמים אישית שלכם חסרים האישורים המעודכנים 'Microsoft UEFI CA 2023' או 2023 KEK. אם ההגדרה של התמונה המותאמת אישית לא כוללת את האישורים המעודכנים האלה, צריך ליצור מחדש את התמונה המוגנת או לעדכן אותה כך שתכלול אותם. הוראות מפורטות מופיעות במאמר בנושא יצירת תמונות של מכונות וירטואליות מוגנות בהתאמה אישית.

הפעולות המומלצות לביצוע

אם יש לכם מופעי מחשוב שנוצרו לפני 7 בנובמבר 2025 עם Secure Boot מופעל, כדאי לעיין בדרישות, במגבלות ובגורמים המורכבים הבאים לפני שתתכננו את נתיב העדכון:

דרישות לפני העדכון:
- אימות הגישה למפתח השחזור: אם המופעים שלכם משתמשים בהצפנה מלאה של הדיסק (FDE, כולל BitLocker ב-Windows או LUKS ב-Linux), אתם צריכים לוודא שיש לכם גישה למפתחות השחזור לפני שתעדכנו את האישורים או תיצרו מחדש את המופעים. שינוי משתני UEFI משנה את מדידות האתחול ויפעיל הנחיות לשחזור.
- ניהול סודות של vTPM: אם המופעים שלכם משתמשים ב-vTPM Platform Configuration Registers (במיוחד PCR7) לאיטום סודות, אתם צריכים לבטל את האיטום או לגבות את הסודות האלה לפני העדכון כדי למנוע אובדן גישה קבוע.
גורמים ומגבלות מורכבים:
- דרישה לעדכון הסדר: כדי למנוע כשלי אימות של CA ולמנוע לולאות אתחול של המערכת, צריך להתקין את האישורים החדשים db ו-KEK לפני שמחילים עדכונים חדשים של ליבת המערכת או של shim.
- החזרה לגרסה קודמת של קושחה: שחזור מופע לתמונת מכונה מדור קודם שצולמה לפני 7 בנובמבר 2025, משחזר את הקושחה הישנה ומסיר את האמון באישורים משנת 2023. אם מבצעים חזרה לגרסה קודמת, צריך להחיל מחדש את עדכוני האישורים.

הוראות מפורטות לגבי לוחות זמנים, שלבי ביקורת ותהליכי העברה מופיעות בהמשך.

ההשפעה על הגדרות אורח ספציפיות

ההסבר על ההשפעה של תפוגת האישור על כל הגדרה רלוונטי רק אם המופע שלכם עומד בשני התנאים המוקדמים הנדרשים (יצרתם אותו לפני 7 בנובמבר 2025, והאפשרות 'אתחול מאובטח' מופעלת בו):

vTPM PCR secret sealing:
- מתי זה הופך לגורם: כשמשתמשים ב-vTPM Platform Configuration Registers (במיוחד PCR7) כדי לאטום סודות, כמו מפתחות פענוח.
- השפעה: עדכון של אישורים של אתחול מאובטח (באמצעות המדריך לעדכון KEK ו-db או באמצעות יצירה מחדש של המופע מתמונת מצב של דיסק) משנה את משתני ה-UEFI, וכך משנה את ערך המדידה PCR7 באתחול הבא. השינוי הזה מונע ממערכת ההפעלה או מהאפליקציות של האורח לבטל את החסימה או לפענח את הסודות האלה, אלא אם קודם מבטלים את החסימה או מגבים את הסודות לפני העדכון, ואז חוסמים אותם מחדש לערך החדש של PCR7.
- אם לא מושפעים: אם יצרתם את המכונה הווירטואלית ב-7 בנובמבר 2025 או אחריו, מתמונה שמסתמכת על אישורי ברירת המחדל, לא צריך לעדכן את האישורים, הערך של PCR7 לא משתנה והצפנת הסודות פועלת כרגיל.
מכונות וירטואליות של Windows באמצעות BitLocker או מצב וירטואלי מאובטח (VSM):
- מתי זה משפיע: כשמכונות וירטואליות של Windows משתמשות בהצפנה מלאה של הדיסק ב-BitLocker או ב-VSM, שניהם מסתמכים על הפעלה מאובטחת של UEFI ועל PCR7 כדי לאטום את מפתחות ההצפנה שלהם.
- ההשפעה: שינוי של אישורי UEFI Secure Boot או יצירה מחדש של המופע מצילום מצב משנה את מדידות האתחול של PCR7. בהפעלה מחדש הבאה, BitLocker מזהה את שינוי ההגדרה, לא מצליח לשחרר את המפתח באופן אוטומטי ומבצע אתחול למסך BitLocker Recovery שבו מוצגת בקשה למפתח השחזור.
- תיקון: לפני עדכון האישורים או העברת המופעים, צריך לוודא שמפתחות השחזור של BitLocker זמינים. לאחר מכן, פועלים לפי ההנחיות במאמר עדכון מסד הנתונים ומפתח הצפנת המפתח ב-Windows.
- מתי לא מושפע: תפוגת האישור לא משפיעה על מופעי Windows ללא BitLocker או VSM, או על מופעים ללא Secure Boot.
מכונות וירטואליות של Linux באמצעות FDE:
- מתי זה הופך לגורם: כשמופעלת הצפנה מלאה של הדיסק (FDE) במופעי Linux, כמו LUKS, שבהם אתם אוטמים את מפתחות הפענוח ל-PCR של vTPM (במיוחד PCR7).
- השפעה: עדכון האישורים של האתחול המאובטח או יצירה מחדש של המכונה הווירטואלית משנים את PCR7, ומונעים פענוח אוטומטי של נפח האתחול. המערכת נעצרת במהלך האתחול ומבקשת ביטוי סיסמה לפענוח.
- פתרון: לפני שמריצים עדכונים, מוודאים שיש לכם את מפתחות השחזור או את ביטויי הגישה לשחזור. לפני העדכון, מבטלים את הקישור או את ההצפנה של מפתחות LUKS מ-TPM ומקשרים או מצפינים אותם מחדש לערך החדש של PCR7 אחרי השלמת העדכון.
- מתי לא מושפעים: פקיעת התוקף של האישור לא משפיעה על מכונות וירטואליות של Linux שלא משתמשות בהצפנה מלאה של הדיסק (FDE) או בפענוח LUKS אטום של vTPM, או על מכונות וירטואליות שלא מופעל בהן אתחול מאובטח.
מופעים עם הגדרות מותאמות אישית של PK או KEK:
- מתי זה הופך לגורם: כשמופע משתמש במשתני Secure Boot מותאמים אישית (כמו PK או KEK מותאמים אישית) במערכת, אבל עדיין מסתמך על אישורים רגילים של מיקרוסופט במסד הנתונים (db) כדי לחתום על טוען האתחול.
- ההשפעה: נדרש עדכון רגיל של אישור db כדי להפעיל עדכונים עתידיים של טוען האתחול שנחתמו רק על ידי Microsoft UEFI CA 2023. עם זאת, מכיוון שאתם משתמשים במפתחות בהתאמה אישית, אי אפשר להחיל את קובצי העדכון הרגילים (DBUpdate3P2023.bin או kek2023update.bin) שמופיעים במדריך של Google. קושחת ה-UEFI בודקת את החתימה ודורשת שהעדכונים ייחתמו על ידי המפתח הפרטי של KEK (או PK) שקיים במערכת.
- פתרון: לפני שמחילים את קובצי העדכון של האישור, צריך לחתום עליהם באמצעות המפתחות הפרטיים שמשויכים ל-PK או ל-KEK המותאמים אישית, או לנהל את העדכונים האלה דרך רשות האישורים המותאמת אישית.
- מתי לא מושפעים: אם טוען האתחול חתום באמצעות רשות אישורים או מפתחות מותאמים אישית משלכם (כמו אישור db מותאם אישית, ולא אישור ברירת המחדל של Microsoft Corporation UEFI CA 2011 שתוקפו פג), אז פקיעת התוקף של אישורי ברירת המחדל של מיקרוסופט לא משפיעה עליכם, ואין צורך לבצע עדכונים.
מופעים שמתבצעת בהם חזרה לנקודת זמן קודמת לתמונה של מכונה מלפני נובמבר 2025:
- מתי זה משפיע: כשמשחזרים מכונה וירטואלית או מחזירים אותה למצב קודם לתמונה של מכונה שצולמה לפני 7 בנובמבר 2025, כשההפעלה המאובטחת מופעלת.
- השפעה: המופע שהוחזר למצב הקודם משחזר את התצורה הישנה של קושחת UEFI ואת מאגר האישורים שלא כולל את האישורים של 2023. כך המופע הופך לפגיע לכשלי אתחול עתידיים אחרי עדכונים עתידיים של טוען האתחול, ולכן צריך להחיל מחדש את עדכוני האישורים.
- מתי לא מושפע: חזרה לקובץ אימג' של מכונה לא משפיעה על המופע אם משביתים את האתחול המאובטח, או אם יצרתם את קובץ האימג' של המכונה ב-7 בנובמבר 2025 או אחריו, מקובץ אימג' שמסתמך על אישורים שמוגדרים כברירת מחדל.

זיהוי של מופעי מחשוב מושפעים ותכנון של עדכון

במהלך שנת 2026, מומלץ לזהות את מופעי המחשוב המושפעים ולבצע את הפעולות הבאות כדי להתכונן לעדכון:

זיהוי מופעים: אפשר להשתמש בפקודה gcloud compute instances list כדי לזהות מופעים שבהם מופעלת האפשרות Secure Boot ושנוצרו לפני תאריך הסיום:

gcloud compute instances list \
--filter="creationTimestamp < '2025-11-07' AND shieldedInstanceConfig.enableSecureBoot=true" \
--format="table(name, zone, creationTimestamp, shieldedInstanceConfig.enableSecureBoot:label=SECURE_BOOT)"

בדיקה של משתנים מותאמים אישית (אופציונלי): אם אתם משתמשים בתמונות מותאמות אישית או בתמונות שיובאו, צריך לוודא שהן מגדירות במפורש משתנים מותאמים אישית של db או KEK Secure Boot (שמבטלים לחלוטין את הגדרות ברירת המחדל). אם הם מסתמכים על אישורים שמוגדרים כברירת מחדל, לא צריך לבצע פעולה ברמת התמונה:
- כדי לבדוק מכונה וירטואלית, מריצים את הפקודה:
```
gcloud compute instances describe INSTANCE_NAME \
    --zone=ZONE \
    --format="yaml(shieldedInstanceInitialState)"
```
- כדי לבדוק תמונה של דיסק מקור, מריצים את הפקודה:
```
gcloud compute images describe IMAGE_NAME \
    --format="yaml(shieldedInstanceInitialState)"
```
אם הפלט ריק או מחזיר null, המופע או התמונה משתמשים באישורים שמוגדרים כברירת מחדל ולא נדרשת פעולה ברמת התמונה.
שמירה על תקינות נתונים: לפני שמבצעים שינויים, חשוב לוודא שיש לכם גיבויים עדכניים של הנתונים וגישה למפתחות שחזור של FDE או BitLocker.
עדכון אישורים: כדי לעדכן את אישורי ה-DB וה-KEK, פועלים לפי המדריך לעדכון KEK ו-DB. לחלופין, אפשר לבצע מיגרציה למופע Compute שיוצרים ב-7 בנובמבר 2025 או אחריו, שכולל את האישורים משנת 2023 (בתנאי שהמופע החדש משתמש בתמונה שמסתמכת על אישורי ברירת המחדל), על ידי ביצוע ההוראות במאמר יצירה מחדש של מופע Compute מקובץ snapshot של דיסק.

יצירה מחדש של מכונת חישוב מקובץ snapshot של דיסק

כשמצלמים תמונת מצב של דיסק ויוצרים ממנה מופע חדש, מופע המחשוב החדש מקבל בירושה מצב קושחה חדש (vTPM/NVRAM) שסומך על ברירות המחדל המעודכנות ומנקה אישורים ישנים.

לפני שיוצרים מחדש מופע של מחשוב מתמונה של מצב המערכת, צריך לוודא שבמערכת ההפעלה של האורח מותקנים כל העדכונים הדרושים (כמו מאמרי KB רלוונטיים של מיקרוסופט ל-Windows, או ה-Shim העדכני להפצות של Linux) כדי שהמערכת תסמוך על האישורים של 2023.

כדי לנהל את המיגרציה הזו, אפשר להשתמש ברצף הפקודות הבא של gcloud:

מזהים את דיסק האתחול: קובעים את השם של דיסק האתחול שמצורף למופע המחשוב של המקור:

SOURCE_DISK=$(gcloud compute instances describe SOURCE_INSTANCE_NAME \
    --zone=ZONE \
    --format="value(disks[0].source.basename())")

יוצרים קובץ snapshot של הדיסק: יוצרים קובץ snapshot של דיסק האתחול. כדי לשמור על תקינות נתונים, צריך להפסיק את מופע המחשוב לפני שמריצים את הפקודה הזו:
```
gcloud compute disks snapshot $SOURCE_DISK \
    --snapshot-names="migration-snapshot-$(date +%s)" \
    --zone=ZONE \
    --storage-location=REGION
```
יוצרים מכונת מחשוב חדשה: מקצים מכונת מחשוב חדשה באמצעות קובץ ה-snapshot כמקור האתחול. אם הפעלה מאובטחת מופעלת במופע המקור, צריך לכלול את הדגל --shielded-secure-boot כדי להפעיל הפעלה מאובטחת במופע החדש.
```
gcloud compute instances create NEW_INSTANCE_NAME \
    --zone=ZONE \
    --machine-type=MACHINE_TYPE \
    --create-disk=name=NEW_DISK_NAME,source-snapshot=SNAPSHOT_NAME,boot=yes \
    --shielded-secure-boot
```

הערה: מכונות וירטואליות שהוקצו באמצעות השיטה הזו מקבלות כתובות IP פנימיות וכתובות IP חיצוניות חדשות, אלא אם הן הוקצו באופן סטטי והוקצו מחדש באופן ספציפי. מטא-נתונים, תגים וחשבונות שירות ברמת המופע לא משוכפלים באופן אוטומטי, וצריך להגדיר אותם באופן מפורש במהלך היצירה מחדש.

אימות

אחרי עדכון הקושחה ומערכת ההפעלה של מופעי המחשוב, אפשר לוודא שהאישורים משנת 2023 קיימים. אם גם המשתנה KEK וגם המשתנה db מציגים את האישורים משנת 2023, המשמעות היא שהמופע שלכם מעודכן ולא נדרשת פעולה נוספת.

Linux

אפשר לאמת את מסדי הנתונים של החתימות ב-Linux באמצעות הפקודה efi-readvar מהחבילה efitools, או (בהפצות שבהן efitools לא זמין, כמו RHEL 8/9) באמצעות mokutil.

שיטה 1: שימוש ב-`efi-readvar`

אם efi-readvar לא מופיע, מתקינים את חבילת efitools. כדי להתקין ב-Linux, מריצים את הפקודה עבור ההפצה שלכם:

‫Debian/Ubuntu
```
sudo apt update && sudo apt install efitools
```
‫RHEL/CentOS/Fedora (Fedora בלבד; ‏efitools לא זמין במאגרי RHEL/CentOS)
```
sudo yum install efitools
```
SLES
```
sudo zypper install efitools
```

בודקים את האישורים במשתנים KEK ו-db:

sudo efi-readvar -v KEK | grep "KEK 2K CA 2023"
sudo efi-readvar -v db | grep "UEFI CA 2023"

שיטה 2: שימוש ב-`mokutil`

בהפצות כמו Red Hat Enterprise Linux‏ (RHEL) שבהן efitools לא זמין, אפשר להשתמש בכלי mokutil שמותקן כברירת מחדל:

sudo mokutil --kek | grep "KEK 2K CA 2023"
sudo mokutil --db | grep "UEFI CA 2023"

‏Windows (PowerShell)

מריצים את הפקודה הבאה בשורת פקודה של PowerShell עם הרשאות אדמין. כל פקודה צריכה להחזיר True.

# Check for Microsoft KEK 2K CA 2023
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'

# Check for UEFI CA 2023
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'UEFI CA 2023'

# Confirm general Secure Boot enrollment state
Confirm-SecureBootUEFI

פתרון בעיות

אם מופע לא מצליח לבצע אתחול בגלל שגיאת אתחול מאובטח אחרי יוני 2026, אפשר לנסות אחת מהאפשרויות הבאות כדי לשחזר אותו:

השבתה זמנית של אתחול מאובטח: האפשרות הזו מאפשרת לאתחל את המופע כדי להחיל עדכונים.

הערה: השבתה של אתחול מאובטח משנה את ערכי ה-PCR, במיוחד את הערך PCR7, וזה עשוי להשפיע על הפונקציונליות של איטום סודות או הצפנת דיסק.

כדי להשבית את Secure Boot, מריצים את הפקודה הבאה:
```
gcloud compute instances update INSTANCE_NAME --no-shielded-secure-boot
```
אחרי שמחילים את העדכונים הנדרשים על תוכנת האתחול או על ה-shim, מפעילים מחדש את האתחול המאובטח:
```
gcloud compute instances update INSTANCE_NAME --shielded-secure-boot
```
שחזור מגיבוי: שחזור המכונה מקובץ אימג' של מכונה שנוצר לפני שהתחילו בעיות האתחול.
יצירה מחדש של מכונה: יצירה מחדש של המכונה ושחזור נתונים מקובץ snapshot.

אם אתם ממשיכים להיתקל בבעיות או שאתם צריכים עזרה, אתם יכולים לפנות אל Cloud Customer Care.

שאלות נפוצות

בקטע הזה יש תשובות לשאלות נפוצות על התפוגה של אישור Microsoft Secure Boot.

מתי פג התוקף של אישורי Secure Boot?

התוקף של אישורי Secure Boot של מיקרוסופט יפוג בשנת 2026. פרטים נוספים:

שני האישורים הקריטיים ביותר שמתקרב מועד התפוגה שלהם הם Microsoft Corporation UEFI CA 2011 (תוקף האישור יפוג ביוני 2026), שמשמש לחתימה על טועני אתחול של צד שלישי כמו Linux Shim, ו-Microsoft Windows Production PCA 2011, שתוקף האישור יפוג באוקטובר 2026 ומשמש לחתימה על טוען האתחול של Windows.

על מי משפיעה פקיעת התוקף של האישור?

תוקף האישור הזה רלוונטי רק אם מופעלת מכונת חישוב שעומדת בשני התנאים המוקדמים הבאים:

יצרתם את המכונה לפני 7 בנובמבר 2025 – התאריך שבו Compute Engine עדכן את אישורי האתחול המאובטח שמוגדרים כברירת מחדל בקושחת UEFI – ולא עדכנתם אותה.
הפעלתם את האתחול המאובטח במופע.

השינוי לא ישפיע על מקרים שתיצרו ב-7 בנובמבר 2025 ואחריו, בתנאי שתיצרו אותם מתמונה שמסתמכת על קבוצת אישורים שמוגדרת כברירת מחדל.

אם המופע שלכם עומד בשני התנאים המוקדמים, תפוגת האישור משפיעה על ההגדרות הבאות בנסיבות מסוימות:

איטום סודות ב-vTPM PCR: אם המופע משתמש ב-Platform Configuration Registers (PCR) של מודול פלטפורמה מהימנה וירטואלית (vTPM) (במיוחד PCR7) כדי לאטום מפתחות הצפנה או סודות.
‫Windows BitLocker / VSM: אם מופעלת במכונה שלכם הצפנת דיסק באמצעות BitLocker או מצב אבטחה וירטואלי (VSM) עם הפעלה מאובטחת.
‫Linux FDE: אם מופעלת הצפנת דיסק מלאה (FDE) במופע Linux שלכם, שמוצפנת באמצעות PCR של vTPM (במיוחד PCR7).
שחזור של מופעים: אם תשחזרו את מכונת ה-VM או תחזירו אותה למצב הקודם שלה באמצעות תמונת מכונה שיצרתם לפני 7 בנובמבר 2025.

פירוט של ההשפעה ושלבי התיקון לכל אחת מההגדרות האלה מופיע במאמר השפעה על הגדרות ספציפיות של גלישה כאורח.

מי לא מושפע מפקיעת התוקף של האישור?

תוקף האישור לא משפיע עליכם אם אחד מהתנאים הבאים מתקיים:

ההפעלה המאובטחת מושבתת: אם ההפעלה המאובטחת לא מופעלת במכונה הווירטואלית המוגנת, היא לא מאמתת את אישורי ה-UEFI שתוקפם עומד לפוג ולא משתמשת בהם. ההגדרה 'אתחול מאובטח' מושבתת כברירת מחדל. עם זאת, חשוב לדעת שאם משתמשים ב-vTPM Platform Configuration Registers (במיוחד PCR7) לאיטום סודות, כל עדכון של משתני UEFI או יצירה מחדש של המופע עדיין ישנו את המדידות של PCR7 גם אם האתחול המאובטח מושבת, למרות שהגדרות כאלה הן נדירות מאוד.
נוצרה ב-7 בנובמבר 2025 או אחרי: יצרתם את המופע בתאריך הזה או אחריו, ולכן הקושחה שלו כבר כוללת את האישורים המעודכנים משנת 2023, בתנאי שיצרתם אותו מתמונה שמסתמכת על קבוצת אישורי ברירת המחדל.
אם אתם מריצים מערכת הפעלה שמותאמת לקונטיינרים (COS): העדכונים האלה של האישורים לא משפיעים על סביבות COS.
משתני PK,‏ KEK או db בהתאמה אישית: אם אתם מגדירים ומנהלים במפורש משתני Secure Boot PK,‏ KEK או db בהתאמה אישית משלכם, בלי להסתמך על אישורי ברירת המחדל של Microsoft UEFI (לדוגמה, אם טוען האתחול חתום באמצעות אישור db בהתאמה אישית משלכם ולא באמצעות אישור Microsoft Corporation UEFI CA 2011 שתוקפו פג), פקיעת התוקף של אישורי ברירת המחדל לא משפיעה עליכם.

אם ההגדרה המותאמת אישית שלכם עדיין מסתמכת על אישור Microsoft שתוקפו עומד לפוג כדי לחתום על טוען האתחול, אתם מושפעים מתפוגת התוקף. עם זאת, מכיוון שאתם משתמשים ב-PK או ב-KEK בהתאמה אישית, קובצי העדכון הרגילים (DBUpdate3P2023.bin או kek2023update.bin) שמופיעים במדריך הזה לא יפעלו כי UEFI דורש שהעדכונים ייחתמו על ידי המפתח הפרטי של KEK (או PK) שקיים במערכת. כדי להחיל את קובצי עדכון האישורים, צריך לחתום עליהם באמצעות המפתחות הפרטיים של PK או KEK בהתאמה.

האם התפוגה הזו משפיעה על Managed Service for Apache Spark (לשעבר Dataproc),‏ Dataflow או מופעים של Vertex AI Workbench?

תפוגת התוקף של האישור הזה לא משפיעה על Dataflow כי המופעים שלו פועלים כברירת מחדל במערכת הפעלה שמותאמת לקונטיינרים (COS). עדכוני האישורים האלה לא משפיעים על סביבות COS.

במקרים של Managed Service for Apache Spark (לשעבר Dataproc) ומופעים של Vertex AI Workbench, התפוגה הזו משפיעה עליכם רק אם המופעים שלכם עומדים בשתי דרישות החובה הבאות:

יצרתם את המקרים לפני 7 בנובמבר 2025.
הפעלתם את האתחול המאובטח במופעים. השירותים האלה לא מפעילים את האתחול המאובטח כברירת מחדל.

אם המופעים שלכם עומדים בשני התנאים המוקדמים, פקיעת התוקף של האישור תשפיע עליהם. עם זאת, אין השפעה מיידית כי ספקי מערכות ההפעלה מתכננים להשתמש בחתימה כפולה לעדכוני bootloader ו-shim בעתיד הנראה לעין. המופעים שלכם לא יושפעו, אלא אם תתקינו עדכון עתידי שחתום רק באמצעות האישור משנת 2023.

מה יקרה אם לא אבצע שום פעולה?

אם לא תבצעו שום פעולה, המופע ימשיך לאתחל ולפעול כרגיל עם הקבצים הבינאריים הקיימים. עם זאת, יכול להיות שלא תוכלו להחיל בעתיד עדכונים של bootloader או של ליבת מערכת ההפעלה שמכילים קבצים בינאריים שנחתמו רק באמצעות האישור משנת 2023. חשוב לציין שספקי מערכות הפעלה חותמים על עדכונים של טוען האתחול ושל shim בחתימה כפולה, גם באמצעות האישור משנת 2011 וגם באמצעות האישור משנת 2023, ולכן לא צפויים כשלים באתחול או חסימות של עדכונים באופן מיידי.

האם אי עדכון של אישורים ימנע את האתחול של מופעי Windows?

לא. אי-תיקון הבעיה לא ימנע את הפעלת מערכת Windows. עם זאת, יכול להיות שיופיע מזהה האירוע 1801 ("צריך לעדכן את רשות האישורים/המפתחות של אתחול מאובטח") ביומן האירועים של המערכת, ולא תוכלו להחיל עדכוני אבטחה חדשים של ליבת המערכת או של טוען האתחול שמכילים קבצים בינאריים שחתומים רק באמצעות האישור החדש משנת 2023.

אילו תנאים ספציפיים גורמים לכשלים בהפעלה ב-Linux?

יכול להיות שתיכשל הפעלה ב-Linux בתנאים ספציפיים:

ההפעלה המאובטחת מופעלת במופע.
המשתנה db UEFI לא מתעדכן כדי לבטוח באישור 'Microsoft UEFI CA 2023'.
מערכת ההפעלה מעדכנת את טוען האתחול (או את ה-shim) שמסתמך אך ורק על האישור הזה (ולא חתום כפול עם האישור משנת 2011).

אם לא תפעילו עדכוני אישורים או עדכוני shim שמפנים לאישורים החדשים, מופע Linux ימשיך לאתחל בהצלחה.

איך אפשר לדעת אם המופע שלי כולל את האישורים המעודכנים?

כדי לקבוע אם המופע כולל את האישורים החדשים בקושחה שלו, צריך לעיין בפקודות שמפורטות בקטע אימות. אם חסרים אישורים, אפשר לעדכן אותם לפי המדריך לעדכון KEK ו-db, או ליצור מחדש את המופע.

האם הפעלה מחדש או אתחול של מכונה מושפעת פותרים את הבעיה?

לא. הפעלה מחדש או אתחול של מופע Compute לא מעדכנים את אישורי האתחול המאובטח שלו, אבל המופע ממשיך לבצע אתחול ולפעול כרגיל עם האישורים הקיימים שלו עד שמחילים עדכון של טוען האתחול או של ליבת מערכת ההפעלה, שמכיל קבצים בינאריים שחתומים רק עם האישור משנת 2023. אם תפעילו מחדש את מופע Compute, הוא ישמור את האישורים הישנים אם הוא נוצר במקור לפני 7 בנובמבר 2025. האישורים הם חלק מהקושחה של המופע (vTPM/NVRAM). לכן, צריך לפעול לפי המדריך לעדכון KEK ו-db או ליצור מחדש את המופע כדי להחיל את האישורים החדשים.

איך כדאי להתכונן לפקיעת התוקף של האישור?

כדי להתכונן, פועלים לפי השלבים הבאים:

זיהוי: בודקים את השימוש במכונות וירטואליות מוגנות, בהפעלה מאובטחת, בהצפנת דיסק מלאה (FDE), ב-BitLocker או בכל תוכנה שמסתמכת על ערכי PCR של vTPM.
מפתחות שחזור וגיבויים: חשוב לוודא שמפתחות השחזור (עבור FDE/BitLocker) והגיבויים האחרונים של הנתונים זמינים באופן מיידי.
ניהול תמונות: זיהוי תמונות מותאמות אישית מדור קודם והפסקת השימוש בהן או וידוא שהן כוללות את האישורים החדשים.
עדכון או העברה: אם רוצים לעדכן אישורים, אפשר לעיין במדריך לעדכון KEK ו-db. לחלופין, אפשר ליצור מחדש כל מופע של מחשוב שפועל לטווח ארוך ונוצר לפני 7 בנובמבר 2025, כי מופעים חדשים כבר כוללים את האישורים הנדרשים (בתנאי שיוצרים את המופע החדש מתמונה שמסתמכת על אישורי ברירת המחדל).

מהן השיטות המומלצות ליצירה מחדש של מופעים מושפעים או להעברתם?

השיטה הכי אמינה היא שימוש בתמונות מצב רגילות של הדיסק. תמונת מצב היא עותק ברמת הבלוק של הדיסק, והיא לא מכילה משתני UEFI או מטא-נתונים ברמת המופע. כדי לשחזר באמצעות תמונת מצב:

יוצרים קובץ snapshot של דיסק האתחול של המכונה.
יוצרים מכונת חישוב חדשה ובוחרים את ה-snapshot כמקור לדיסק האתחול.

לא מומלץ להשתמש בתמונות מכונה, בשיבוט מכונות או בשירות Backup and DR לצורך ההעברה הזו, כי הם משכפלים את הקושחה של המכונה ושומרים את האישורים הישנים לכל מכונת מחשוב של מקור שנוצרה לפני 7 בנובמבר 2025.

מה צריך לעשות אם המערכת מפסיקה אתחול אחרי יוני 2026?

אם לדעתכם הבעיה הזו גרמה לכשל באתחול, אפשר לעיין במאמר בנושא פתרון בעיות.

איך Cloud de Confiance by S3NS מטפל בתפוגה של אישורי Microsoft Secure Boot?

Cloud de Confiance by S3NS נכללים אוטומטית האישורים החדשים עבור מופעי מחשוב שנוצרו אחרי 7 בנובמבר 2025. רק לקוחות שרוצים להמשיך להפעיל את מופעי המחשוב שלהם שנוצרו לפני 7 בנובמבר 2025 יצטרכו להחיל עדכון עתידי, אבל אנחנו ממליצים לעבור למופע שייווצר ב-7 בנובמבר 2025 או אחריו (בהסתמכות על אישורים שמוגדרים כברירת מחדל).