Hardening של מערכת ההפעלה: היכן התצורה סוטה מהמדיניות
שרתים נדיר שנפרסים מדימוי אחד. חלק מהמכונות נבנו לפי תבנית ייחוס, חלק מדימויים של מהדורות קודמות, וצמתים בודדים נערכו ידנית למשימה מסוימת.
מעל זה מצטברות במשך שנים התאמות: ביטלו דרישות לסיבוכיות סיסמאות כדי שלא יפריעו לפריסה אוטומטית, החלישו כללי סינון עבור אינטגרציה, הרחיבו הרשאות במקום להגדיר חשבון שירות.
כך נוצר פער בתצורות. מדיניות האבטחה הבסיסית קבועה בתקנון, אבל מצבו בפועל של המארח אינו תואם אותה — ואין דרך לבדוק זאת בלי מעבר רצוף על כל המכונות.
הרשאות בלתי נשלטות עובדות באותו אופן: נותנים הרשאות ידנית למשימה חד-פעמית, כמעט אף פעם לא מבטלים אותן בחזרה, ותשובה מדויקת למי יש אותן עכשיו אין גם למנהל המערכת וגם לתמיכה.
הגדרת אבטחת שרתים במצב כזה נשענת על הזיכרון של מהנדס מסוים. כבר בדיקה חיצונית או ביקורת ראשונה חושפת עשרות סטיות בכל מכונה: שירותי רשת מיותרים, חשבונות ללא תפוגה, דמונים שרצים בהרשאות עודפות.
הניתוח נמשך שבועות, כי לא די לסגור את הסטייה — צריך להבין מה הנחה אותה ומה יישבר בפרודקשן לאחר התיקון.
Hardening של מערכת ההפעלה אינו פעולה חד-פעמית אלא מצב שבו ניתן לבדוק את המצב בכל רגע. נסביר איך זה נסגר: תקן אחיד לכל המכונות, החלה הצהרתית של ההגדרות דרך תפקידי אוטומציה, ובדיקה תקופתית של המצב בפועל מול המדיניות.
מה נותן פרופיל אבטחה אחיד לשרתים
פרופיל אבטחה אחיד הוא סט הגדרות ייחוס: כללי אימות ותפוגת סיסמאות, הרשאות על תיקיות, הרכב השירותים הפעילים, מדיניות תיעוד וסינון יציאות רשת. כבסיס אנחנו לוקחים את דרישות CIS — רמות 1 ו-2, ומהן מוחקים במפורש את מה שאינו רלוונטי לתפקיד הצומת. בלי שלב זה הפרופיל שובר יישומים עובדים, ומשביתים אותו כבר בשבוע הראשון.
סטנדרטיזציה של שרתים מוציאה את רשימת הבדיקה הידנית מתהליך העלאת הצומת. סט תפקידים ותסריטים של Ansible מוחל על כל הצי בהרצה אחת, מצב כל שרת נבדק מול הייחוס, והפערים יוצאים כרשימה.
זמן העלאת שרת מתקצר מימים של אישורים והגדרה ידנית לעשרות דקות, וקליטת מהנדס חדש מצטמצמת לשאלה אחת: הוחל התסריט או לא.
מכאן — סוג כשל שטופל, לא תקלה בודדת. כל עוד הצמתים מוגדרים באופן זהה, התקלה משוחזרת בסביבת בדיקה ומתוקנת בעריכה במקום אחד בפרופיל, ולא בחיפוש הבדלים בין שרתים «דומים».
מהייחוס נעלמים שירותים מיותרים, חשבונות אורח ואלגוריתמי הצפנה מיושנים — הסיבות האופייניות לכשלים בבדיקות פשוט לא עוברות את ההחלה.
מוכנות לבדיקה מפסיקה להיות שעת חירום. דוח הסטיות נלקח באותו תסריט במצב בדיקה, בלי שינויים בשרתים: הביקורת מקבלת רשימת עובדות, לא הבטחות. שיעור הצמתים שסטו מהייחוס וזמן העלאת השרת הופכים למדדים תפעוליים — לפיהם רואים אם הצי נשמר במצב ייחוס בין הבדיקות.
דרכים להביא את מערכת ההפעלה לתקן: השוואת גישות
רשימת דרישות התקן זהה לכולם, אבל הדרכים להשיג אותה נבדלות באופן קיצוני — גם במאמץ וגם במידה שאפשר בכלל להוכיח את התוצאה לבודק. הגדרה ידנית של שרתים לפי רשימת בדיקה סוגרת סעיפים פורמלית, אבל מצב הצומת חי חיים משלו: מישהו תיקן פרמטר, חבילה התעדכנה — וההתאמה אבדה בלי שום אות.
ארבע גישות בפועל
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| הגדרה ידנית לפי רשימת דרישות | צמתים בודדים, סביבות בדיקה, ניסויים חד-פעמיים | סחיפת תצורה, התוצאה אינה משוחזרת, הביקורת נשענת על הזיכרון של המבצע |
| דימוי מערכת ייחוס | שרתים זהים נפרסים מאפס, צמתים ניתנים להחלפה | שינוי דורש בנייה מחדש ופריסה מחדש, צי קיים איננו מושפע מהדימוי |
| תיאור הצהרתי של המצב באמצעות תפקידים (Ansible) | צי של עשרות צמתים, נדרשים שחזוריות וחזרה לאחור | דורש משמעת: מלאי, משימות אידמפוטנטיות, ניהול גרסאות של תפקידים |
| סורקי בדיקת התאמה ללא אוטומציה של שינויים | נדרשים דיווח ובקרת סטיות | מראים פערים אבל לא מתקנים אותם; הדוח מתעד חתך, לא מצב |
בפועל הכי חזקה עובדת השילוב: תפקידים הצהרתיים מביאים את הצומת לייחוס, הסורק מאשר את התוצאה ונשאר בדיקה תקופתית לסחיפה. דימוי הייחוס משלים אותה למכונות חדשות, והגדרה ידנית נשארת רק במקום שבו האוטומציה יקרה מהצומת עצמו.
שלבי יישום: מביקורת ועד מסירת תקנונים
תקן CIS אינו סט הגדרות אחד אלא כמה רמות מחמירות, ואסור להחיל אותו בעיוורון: חלק מהדרישות נוגעות באינטגרציות מכוילות וביישומים לא סטנדרטיים. לכן את העבודה מנהלים בהדרגה, תוך תיעוד מצב המערכת לפני ואחרי כל שלב.
- מלאי שרתים: אוספים תפקידי צמתים, ייעוד, מקטעי רשת, אחראים; מסמנים היכן המדיניות חלה במלואה והיכן נדרשים חריגים.
- סכימת פרופילים: ממיינים את הצי למחלקות — צומת בסיסי, שרת ווב, מסד נתונים, בקר תחום — ולכל אחת קובעים רמת מחמירות משלה.
- הכנת תיאורים: כותבים תפקידי Ansible אידמפוטנטיים עם משימות המחולקות לפי תגיות, כדי להריץ גם פרופיל שלם וגם כלל בודד.
- בדיקה בסביבת בדיקה: פורסים עותק של הצומת, מריצים את הפרופיל, בודקים מה נשבר — תיעוד, עיגון, חשבונות שירות.
- הפעלה בסביבת ייצור: בקבוצות של כמה צמתים, תחילה במצב בדיקה ללא שינויים; שומרים חזרה לאחור מוכנה ומבצעים אותה בפקודה אחת.
- קבלה: משווים את הדוח לכל כלל מול רמת היעד, מתעדים חריגים מוצדקים, בודקים שהמצב נשמר לאחר אתחול.
- מסירת תיעוד: תקנוני שינויים, תיאור תפקידים ופרופילים, סדר חיבור צומת חדש והאחראי על בחינת המדיניות.
בתוצאה מתקבל לא כיוונון חד-פעמי אלא תהליך חוזר: שרת חדש מובא לתקן באותו סט תפקידים, והסטיות נראות בדוח ולא צפות כבר בבדיקה הראשונה.
תוצרים בסיום: תצורות, סכימות, תקנונים
לאחר מסירת הפרויקט נשארות לצוות שלכם לא התאמות חד-פעמיות בשרתים אלא ייחוס ניתן לשחזור: תיאורי הגדרות שלפיהם מכונה חדשה מובאת לאותו מצב בפקודה אחת. להלן רשימת התוצרים שאנחנו מוסרים עם העבודה, כל אחד בצורה שמתאימה לעריכה בלי מעורבות שלנו.
- פרופילי hardening. תיאורי הגדרות מחולקים לפי תפקידים ל-Linux ול-Windows: פרמטרים של ליבה ומערכת הרשת, הרכב שירותים, מדיניות סיסמאות וחסימות, כללי תיעוד. לכל סעיף — קישור ל-CIS וסימון אילו יישומים בירושה נפגעים ממנו.
- מדיניות גישה. כניסה במפתחות ובאישורים, איסור כניסה ישירה תחת חשבונות שירות, הגבלת העלאת הרשאות, תפוגת מושבים.
- סכימות קישור בין צמתים. מפה: מה מדבר עם מה, באילו יציאות, היכן נקודות השליטה ויחסי האמון, אילו ערוצים מוצפנים.
- מטריצת הפרדת תפקידים. מי יכול מה — לקרוא תצורות, להחיל פרופילים, לערוך חריגים. הזכות לשנות את הייחוס נפרדת מהזכות להחיל אותו.
- תקנון ביצוע שינויים. בקשה, נימוק, בדיקה בסביבת בדיקה, החלה, חזרה לאחור. שם גם סדר בחינת הייחוס: תדירות ואחראי.
- דוחות וחריגים. תוצאות בדיקות לפני ואחרי, רשימת כללים שהושבתו במודע עם נימוק ותנאים שבהם מפעילים אותם.
- סדר חזרה לאחור. מה לעשות אם לאחר החלת הפרופיל הצומת מאבד זמינות או שהשירות לא עולה.
מקרה בוחן: צמצום הסטיות מהייחוס פי שישה
הצי של הלקוח — כשלוש מאות צמתים: כמה משפחות Linux וענפים שונים של Windows, חלק מהמכונות בענן וחלק על חומרה משלהם.
את ההגדרות תיקנו ידנית תוך כדי משימות, פרופיל ייחוס אחיד לא היה קיים, והביקורת לפני שחרור הראתה בממוצע 47 סטיות לצומת — מהרשאות שירותים וחשבונות מיותרים ועד יציאות פתוחות החוצה. הכנסת מכונה חדשה לייצור ארכה יומיים ועדיין פספסה פערים מול הגדרות של צמתים שכנים.
איך הביאו לייחוס
אספו ייחוס בצורת תפקידים של Ansible: דרישות כלליות הועברו למשתנים, וההבדלים בין משפחות מערכות ההפעלה — לסטים נפרדים של משימות, כך שפרופיל התאמה אחד יכסה את כל הצי המעורב. כל כלל הוא אידמפוטנטי ותחילה מורץ במצב בדיקה: רואים מה בדיוק ישתנה בצומת מסוים לפני ההחלה.
חריגים לא משתיקים אלא חיים ברשימה נפרדת עם נימוק, בעלים ומועד בחינה — אחרת הייחוס מתרחק מהמציאות במהרה.
מדדים לפני ואחרי
אחרי שלושה מחזורי הבאה לייחוס, נותרו 8 סטיות לצומת, ושיעור המכונות שעוברות בדיקה מהניסיון הראשון עלה מ-31% ל-94%. הרכבת צומת חדש התקצרה מיומיים ל-35 דקות: הוא עולה מתבנית ומיד מובא לייחוס, והעריכות הידניות לאחר ההתקנה נעלמו.
לפני השחרור כבר לא נדרש שלב הכנה נפרד — הבדיקה מתבצעת באותו סט כללים כמו ההגדרה, והפערים נכנסים אוטומטית לדוח.
החזרה לאחור נשארת נשלטת: לפני שינויים נלקח מצב התצורה, ולכן החזרה לגרסה הקודמת אורכת דקות ולא שעות של ניתוח. כעת נסביר איך אותה גישה עוברת לצי עם חומרה לא סטנדרטית ומיושנת.
במה שונה hardening של מערכת ההפעלה Windows מ-Linux
ההבדל מתחיל במודל הרשאות הגישה. ב-Windows הרשאות קשורות למזהה חשבון: גישה לאובייקט מתוארת ברשימת בקרת גישה, הרשאות ניתנות לקבוצות, והירושה נקבעת על ידי היררכיית התחום.
ב-Linux אותה הגבלה מורכבת משלושה רבדים — הרשאות בעלים וקבוצה על קובץ, הרשאות נפרדות להרצה כסופר-משתמש, ובקרה מנדטורית שמצמצת את יכולות התהליך גם לאחר כניסה מוצלחת.
שירותים ותיעוד בנויים אחרת. ב-Windows תהליכי רקע מרוכזים במנהל שירותים אחד, לכל אחד חשבון משלו, והאירועים נכתבים ליומן משותף עם קודים מספריים וקטגוריות ביקורת. ב-Linux אלה דמונים ויחידות עצמאיות עם כתיבה ליומן המערכת או לתת-מערכת הביקורת של הליבה. משמעות האירועים זהה, אבל ספים וכללי מתאם לפלטפורמות נבנים בנפרד.
גם החלת ההגדרות שונה. Windows שואבת תצורה ממדיניות קבוצתית שעוברת בירושה לפי רמות: יש לבדוק את המדיניות האפקטיבית, לא רק את הערך שנקבע. Linux קוראת פרמטרים מקבצי תצורה, וכאן עובדת הגישה ההצהרתית — תפקיד מתאר מצב סופי, והרצה חוזרת לא שוברת דבר.
הייחוס עצמו נשאר משותף. הדרישות למדיניות סיסמאות, לחסימה לאחר סדרת כניסות כושלות, לביקורת כניסות ושינויי הרשאות, לסט מינימלי של שירותים ולהפרדת הרשאות מנוסחות באותו אופן — שונים רק המימוש ואופן הבדיקה.
אנחנו מחזיקים פרופיל אחד עם שתי רמות מחמירות, ותחת כל מערכת כותבים מימוש משלה להבאה לייחוס. הרצה תקופתית נותנת דוח על פערים: מה ובאיזה צומת סטה מהייחוס. כך צי הטרוגני — Linux ו-Windows באותה תשתית — מנוהל בתקנון אחיד, ולא בשני סטים לא קשורים של הוראות.
ספקות טכניים נפוצים לפני התחלה
ספקות לפני התחלה בדרך כלל לא נוגעים לכלי עצמו אלא לאיך הוא יסתדר עם תשתית חיה, שבה חלק מהשרתים עובדים שנים ומפחיד לגעת בהם. אספנו ארבע שאלות שנשאלות כמעט בכל ניתוח, ואת התשובות לגופן.
האם היישום ידרוש עצירת שירותים?
הולכים ממדידה לתיקונים. תחילה מלאי ובדיקת מצב במצב קריאה בלבד — התצורות לא משתנות, השירותים לא מופעלים מחדש. לאחר מכן השינויים מוחלים בקבוצות עם הגבלת מקביליות, והאתחול מבוצע בחלון מוסכם ובצומת אחד בכל פעם.
הבדיקות נותנות התראות שווא — מה לעשות איתן?
חלק מדרישות הייחוס אינן ישימות: למשל, איסור מודולי ליבה לשירות שלא עובד בלעדיהם. סעיפים כאלה לא משביתים בשקט — מנסחים חריג עם נימוק, תפקיד וצומת. החריג חי באותו תיאור תצורה ולא הולך לאיבוד בהרצה הבאה.
הגדרות בירושה מתנגשות עם התקן?
מתארים אותן כסטיות מפורשות עם סיבה ובעלים, ולא כותבים מחדש בעיוורון. העדיפות — תפקוד היישום: הייחוס מוחל תחילה בסביבת בדיקה, הפערים מנותחים, ורק אז הכלל עובר לפרודקשן.
מי מתחזק את הייחוס לאחר עדכוני מערכת ההפעלה?
הייחוס נשמר כקוד במאגר עם היסטוריית עריכות ובדיקה בצינור — עדכון הוא עריכת קובץ אחד, לא מעבר ידני על שרתים. בדיקת ההתאמה מתבצעת לפי לוח זמנים ומראה פערים לכל צומת; כללים לגרסאות מערכת הפעלה חדשות מתווספים בלי לעצור את העבודה.
נדון במשימה: אילו נתונים נדרשים להערכה
ההערכה של הבאת הצי לפרופיל CIS תלויה לא במספר השרתים אלא בהטרוגניות הסביבה. כל עוד לא רואים כמה ענפי הפצות שונים יש, אילו תפקידים נושאים הצמתים ומה כבר מתואר בתפקידים הקיימים, כל מספר לגבי לוחות זמנים יהיה ניחוש. לכן לפני ההערכה אוספים נתוני מקור על הסביבה — מהם גדל תוכנית עבודה עם חלוקה לקבוצות.
- מלאי צמתים: משפחות וענפי Linux, מהדורות Windows, מספר השרתים והתבניות שמהן הם נפרסים.
- תפקידים וייעוד: שכבת ווב, מסד נתונים, ברוקרים, בקרי תחום — מזה תלויים סטי הכללים והחריגים המותרים.
- מצב האוטומציה: האם יש מלאי ותפקידים משלנו, במה מתמלא רשימת הצמתים — בקובץ סטטי או בשאילתה למערכת ניהול תצורות.
- פרופיל בדיקה: רמת CIS בסיסית או מוגברת, המדורים הישימים, כללים שאסור להפעיל בגלל יישומים מיושנים.
- גישות: חשבון שירות עם העלאת הרשאות, אופן החיבור לצי, צומת ביניים, סדר החלפת מפתחות.
- חלונות וחזרה לאחור: האם אפשר לשנות תצורה בקבוצות, היכן הפעלה מחדש של שירותים דורשת אישור, האם יש תמונת מצב לפני הרצה.
- בדיקת התוצאה: באיזה סורק מאשרים התאמה ובאיזו צורה נדרש דוח לביקורת.
בהמשך נדון במשימה לגופה: משווים פערים בנתונים, מבהירים כללים שנויים במחלוקת וחוזרים עם הערכת לוחות זמנים ותוכנית עבודה — תחילה קבוצת פיילוט, אחר כך שאר הצי.