הגדרת UEFI/Secure Boot לשרתים: פתרון מלא

הגדרת Secure Boot בשרתים: מה נשבר ולמה

שרשרת האמון של UEFI מאמתת חתימה בכל שלב: הקושחה מאמתת את טוען האתחול, טוען האתחול — את הליבה והמודולים לפי מפתחות במאגר שלו. די בכך שרכיב אחד ייצא מהתבנית הזאת, והמכונה לא עולה — ולא בעמדת בדיקה, אלא בצומת ייצור. לכן הגדרת Secure Boot אינה מצטמצמת למתג בקושחה: זו מדיניות מפתחות שצריכה לשרוד כל עדכון.

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

מודול ליבה לא חתום נותן תוצאה דומה אך רכה יותר: המערכת עולה, אבל בלי דרייבר של מדף דיסקים או מתאם רשת, והאבחון מוביל הצידה מהסיבה האמיתית.

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

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

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

מה נותנת שרשרת אמון מנוהלת בזמן אתחול

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

האפקט המעשי — נעלם סוג שלם של איומים: bootkit לא משתלט לפני מערכת ההפעלה, כי קוד לא חתום פשוט לא רץ, ובקרת שלמות הליבה לא מאפשרת לטעון מודול מחוץ לרשימה המורשית.

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

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

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

השוואת מצבים: מפתח מהיצרן, מפתח עצמאי, מאגר

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

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

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

שלבי יישום: מביקורת הצי ועד מסירת נהלים

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

1. ביקורת אתחול של צי השרתים. עבור כל צומת אוספים את מצב הקושחה, טוען האתחול, רשימת מודולי הליבה הנטענים ומקורות החתימה שלהם. בתום — מטריצה «פלטפורמה / קושחה / מה מונע הפעלת אימות», ולפיה מתכננים את תור העבודות.
2. סכימת שרשרת אמון. מחליטים אם להשתמש במפתחות פלטפורמה או במפתחות עצמאיים, היכן הם נשמרים ולמי יש זכות חתימה. את הסכימה מקבעים לפני הכתיבה הראשונה לקושחה — אחרת חזרה לאחור וחקירת אירועים הופכות לבלתי ניתנות לשחזור.
3. חתימת תמונות ומודולים. חותמים את טוען האתחול, הליבה והמודולים החיצוניים שבלעדיהם השרת לא ממלא את תפקידו. כאן גם מתארים איך לעדכן מפתחות בלי השבתה.
4. קבוצת פיילוט של שרתים. מפעילים את האימות על כמה צמתים מדגמים ואתרים שונים — обязательно כולל הישן והלא-סטנדרטי ביותר: דווקא הוא מראה היכן הסכימה אינה מחזיקה.
5. בדיקת תרחיש התאוששות. שוברים בכוונה: מחליפים חתימה, מאבדים גישה למפתח, חוזרים לתמונה קודמת. ההתאוששות צריכה לעבור לפי הוראה כתובה, ולא לפי הזיכרון של התורן.
6. פריסת פרופילי קושחה. פרופיל אחיד עובר ארון אחר ארון עם עצירה בסטייה הראשונה. במקביל מודדים את זמן החלת הפרופיל ואת זמן החזרה למצב הקודם.
7. מסירת נהלים. מוסרים מטריצת תאימות, סדר סבב מפתחות והוראות למשמרת התורנים — עם בדיקה על אירוע תרגול, כדי שהמסמכים לא יישארו תיאוריה.

בתום העבודה: תצורות קושחה, מפתחות ונהלים

Secure Boot מופעל — זה מצב של מכונה אחת. הערך מופיע כשנשאר סט ארטיפקטים שלפיו משחזרים את התצורה בצומת חדש, מוסרים למשמרת התורנים ובודקים בעת הקבלה. להלן מה שהמזמין מקבל לידיו לאחר העבודות.

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

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

מקרה בוחן של צי שרתים: אתחול מבוקר ללא השבתות

מצב התחלתי

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

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

מה שינו ומה יצא

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

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

חלק השרתים עם אימות חתימה מופעל עלה מ-40% ל-100%. העלאת שרת חדש לפעולה התקצרה מחצי יום ל-25–30 דקות: ההגדרות מגיעות יחד עם התמונה. אירועי אתחול בחצי שנה — אפס, ועדכון הצי בלי השבתה הפך לנורמה: קבוצה יוצאת להפעלה מחדש רק אחרי העברת השירותים לצמתים שכנים.

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

כאשר אימות האמון מופעל, הקושחה דוחה כל טוען אתחול שחתימתו אינה במאגר המפתחות המורשים שלה. לכן שרת לא נטען אחרי הפעלת האימות בדרך כלל לא בגלל חומרה: השרשרת «קושחה → טוען אתחול → ליבה» מורכבת מרכיבים לא חתומים — טוען אתחול בהרכבה עצמית, מודולי ליבה של צד שלישי, מדיה להתקנה מיושנת. בהמשך הסיבה נקראת לפי הסימן.

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

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

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

ספקות טכניים נפוצים לפני הפעלת המצב

Secure Boot משתלב בשרשרת האתחול ונוגע בעדכון ליבה, התקנה ברשת ומכונות וירטואליות. אספנו שאלות שמועלות לרוב בשיחת ועידה עם צוות המזמין — עם תשובות המהנדסים.

איך זה תואם אתחול שרתים מהרשת?

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

מה קורה בתוך מכונות וירטואליות?

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

האם יהיה צורך להחליף חומרה?

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

מה יקרה בעת סבב מפתחות?

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

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

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

• הרכב צי השרתים והאתרים. דגמים ודורות חומרה, גרסאות קושחה, פילוח לפי מרכזי נתונים וסביבות: ייצור, בדיקות, גיבוי.
• דרישות ביקורת ורגולציה. אילו בדיקות הצי צריך לעבור, מה בדיוק מתועד בדוח ובאיזו תדירות מסתכלים עליו.
• מודולים ותמונות לא סטנדרטיים. דרייברים עצמאיים, היפרוויזור, כרטיסי רשת ומדיות אתחול שאולי אין להם חתימת יצרן.
• מפתחות ושרשרת אמון. היכן נמצאים כעת מפתחות החתימה, מי הבעלים, האם נדרש סבב ומעבר למפתח עצמאי במקום מפתח מהיצרן.
• גישה לקונסולות ניהול. חשבונות לניהול מחוץ לרצועה (out-of-band) ו-API שדרכם מפעילים את המצב בכל צומת בצי.
• חלונות לשינויים. מתי מותרות הפעלות מחדש, באיזה סדר עוברים באתרים ועד מתי צריכה להישמר היכולת לחזור לאחור.
• המצב הנוכחי של Secure Boot. האם המצב מופעל, באיזו צורה, אילו צמתים כבר חתומים ואילו נופלים בניסיון להפעיל.

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

אם נדרש יישום Secure Boot כולל — ניקח את כל המחזור: הכנת מפתחות, חתימת תמונות, הפעלה מדורגת של המצב ובדיקת אתחול לאחריו.