הקשחת CIS Benchmark: היכן נשברת הגדרה ידנית
CIS Benchmark אינו רשימת בדיקה אחת, אלא מערכת של פרופילים בדרגות חומרה שונות: Level 1 מכסה דרישות בסיסיות בלי סיכון לשבור שירות יישומי, Level 2 מוסיף מגבלות נוקשות — איסור התחברות כ-root בסיסמה, עיגון מחיצות עם noexec, ביקורת חובה של קריאות מערכת.
בתוך הפרופיל — מאות נקודות בקרה: מפרמטרי ליבה וכללי sshd_config ועד הרשאות לקבצי תצורה והגדרות תיעוד יומנים. בהגדרה ידנית המהנדס עובר את הרשימה בעיניים ובידיים: חלק מהסעיפים נדחה „עד לחלון”, וחלק מיושם באופן שונה במכונות דומות.
מכאן נובעות סטיות אופייניות בתצורה. בצומת אחד נשארת התחברות כ-root, בצומת אחר תלוי פורט פתוח של שירות ש„היה צריך לשבוע”, ובשלישי נחלשו הרשאות לקבצים עם פרמטרי חיבור. בנפרד כל פער נראה כזוטות, וביחד הם יוצרים משטח תקיפה שאינו מופיע באף דוח תאימות.
היקר מכל הוא פער ההגדרות בין סביבות. את סביבת הבדיקות מרכיבים לפי תבנית אחת, את הפרודקשן מתקנים ידנית למשימה מסוימת, וצומת חדש באשכול עולה מתמונת בסיס ולא מקבל אף כלל.
אפשר להשוות זאת רק לפי מצב בפועל, ועד רגע הבדיקה סביבת הבדיקות והפרודקשן נפרדים עד כדי כך שאי אפשר להשוות את תוצאות הסריקה זו לזו.
חלון הפגיעות גדל מאותו שורש. בין יציאת העדכון להחלתו המכונות נשארות במצב פגיע ידוע, והרצה ידנית לפי רשימת בדיקה לא מספיקה פיזית לכסות את כל הצמתים בתדירות הנדרשת. לכן בהמשך נפרט כיצד זה נסגר: הפרופיל מתואר כקוד ומיושם באופן זהה בכל מכונה.
ניהול תצורות: אפקט מדיד של הטמעה
תקן תצורה אחיד הוא תיאור בר-הרצה, לא מסמך: הרכב החבילות, פרמטרי הליבה, הרשאות לקבצים, מערך השירותים וכללי הגישה לרשת נמצאים במאגר ומיושמים על הצומת אוטומטית. בדיקת התאמה ל-CIS Benchmark מפסיקה להיות השוואה ידנית של רשימת בדיקה והופכת למשימה שגרתית שמחזירה את הצומת לתקן.
סטיות וזמן פריסה
לפני ההטמעה פערים מצטברים באופן בלתי מורגש: בחלק מהשרתים נשארות חשבונות מיותרים, פרמטרי אימות מוחלשים, פורטים נשכחים. אנחנו שומרים על שיעור סטיות בטווח של אחוזים בודדים — ההרצה משווה את ההגדרות בפועל לתקן ומחזירה רשימת פערים לכל צומת, ולא „בסך הכול הכול טוב”.
תיקון בתקן נפרס על כל המלאי במעבר אחד: שינוי טיפוסי, שבעבודה ידנית נמשך ימים של מעבר בין שרתים, מיושם תוך עשרות דקות. זהו בדיוק קיצור חלון הפגיעות — בין יציאת התיקון להופעתו בכל הצמתים עוברות שעות.
חזרתיות הסביבה ושחזור
חזרתיות משמעה שסביבת הבדיקות והסביבה הייצורית נבנות מאותו תיאור, והפער ביניהן נתפס לפני השחרור, לא בקרב. זמן השחזור לאחר תקלה נקבע לא לפי ניתוח יומנים, אלא לפי פריסת הצומת מהתקן: שעות של הרכבה ידנית מתכווצות לדקות, והצומת חוזר בדיוק למצב שהיה בשליטה.
מדד נפרד הוא שיעור התקריות שהסיבה להן היא הגדרה, לא קוד. במלאי מנוהל כשלים כאלה יוצאים מהזרם, והניתוח עובר לשכבה היישומית. דוח לכל צומת נשאר ראיה לביקורת: מה שונה, באמצעות מה הוחל והאם הוא תואם לתקן.
מצבי בדיקה: ביקורת, תיקון אוטומטי וכפייה
המצב קובע מה הפלטפורמה עושה עם הסטייה שנמצאה: רק מתעדת, מחזירה את הצומת לתקן או לא מאפשרת סטייה כלל.
פרופיל הרמה הראשונה מרכז דרישות בסיס — שירותים מיותרים כבויים, הרשאות לקבצי מערכת תקינות, יומנים וכללי גישה מוגדרים; הוא כמעט לא פוגע בשירותים יישומיים, ולכן מפעילים אותו על כל המלאי.
פרופיל הרמה השנייה מוסיף מגבלות נוקשות — צמצום מנגנונים תואמים, איסור שיטות אימות מיושנות, סגמנטציה; פרופיל כזה מריצים תחילה בסביבת בדיקות, אחרת אפשר לאבד גישה לצומת או להפיל את הבנייה.
בחירת המצב היא בחירת מחיר הטעות. ביקורת מציגה תמונה אמיתית ואינה נוגעת בסביבת העבודה; תיקון אוטומטי של סטיות מחזיר את הצומת לתקן, אבל בשירותים חיים דורש חלון ותוכנית חזרה; תאימות כפויה בודקת את התצורה לפני החלתה וחוסמת הפעלה לא תואמת.
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| דוח בלבד (ביקורת) | מעבר ראשון על המלאי, מלאי, הכנה למעבר; פרודקשן שבו שינויים מותרים רק בחלון | לא משנה דבר: הסטיות נשארות ומצטברות בין הרצות |
| דוח + תיקון אוטומטי של סטיות | צמתים כבר בפעילות, יש חלון תחזוקה, נדרש מעבר מהמצב בפועל לתקן | התיקונים מתבצעים על מערכת פעילה; חלק מסעיפי פרופיל הרמה השנייה דורש טיפול ידני |
| תאימות כפויה | בניית תמונות, אספקת מכונות חדשות, סביבות עם בקרה מתמדת | עוצר את התהליך בעת סטייה; שגיאה בפרופיל חוסמת את השחרור כולו |
בפועל משלבים בין המצבים: תאימות כפויה שמים על בניית תמונות ואספקת צמתים חדשים, תיקון אוטומטי — על מכונות שכבר פועלות, ודוחות לפי הרמה הראשונה והשנייה נאספים לתמונה אחידה ומושווים בין הסביבות — כך רואים היכן התקן נפרד מהמציאות.
הקשחת שרתים: שלבי הטמעת פרופילים תקניים
סדר העבודה זהה גם לעשרה מכונות וגם לאלף: תחילה מלאי, אחר כך סכמה והגדרה, ולבסוף בדיקה. פרופיל CIS Benchmark אינו סקריפט חד-פעמי, אלא מערכת כללים מנוהלת גרסאות שחייבת לשרוד בנייה מחדש של השרת ועדכון מערכת.
- מלאי: אוספים את הרכב המלאי, תפקידי המכונות, גרסאות המערכת והשירותים, תלויות חוץ. מכך תלויים רמת הפרופיל ורשימת הכללים שמלכתחילה מתנגשים עם התוכנה היישומית.
- תוכנית הטמעה: מחלקים את הכללים לכלל-מערכתיים, תפקידיים ויישומיים, ומציינים מה מיושם אוטומטית ומה דורש תיאום עם בעל השירות.
- אוטומציה של הגדרות: מתארים את הכללים כקוד, כדי שהתצורה תשחזר את עצמה במכונות חדשות ולא תיפרד אחרי בנייה מחדש. תיקונים ידניים בשרתים כבר לא נדרשים.
- סביבת בדיקה: מריצים את הפרופיל בסביבה לא-ייצורית שמשחזרת תפקידים אמיתיים, מוציאים בדוח סורק „בוצע / לא בוצע” ומנתחים פערים.
- קבוצת פיילוט של שרתים: מפעילים שירותים לא קריטיים ועוקבים אחרי זמינות ויומני כשלים. כללים ששוברים את העבודה מנסחים כחריגים מנומקים עם תאריך בדיקה חוזרת, ולא מכבים בשקט.
- קבלת הפרופיל: הרצה חוזרת של הסורק על כל המלאי, שיעור הכללים שבוצעו וסטיות שיוריות נרשמים בפרוטוקול.
- העברה לתפעול: נוהל עדכון הפרופיל לגרסאות חדשות של התקן, בקרת סחיפת תצורות והליך חזרה ברור.
כך פרופיל התקן הופך לתהליך מנוהל עם כיסוי כללים מדיד, ולא לקמפיין פעם בשנה.
תצורות, מדיניות גישה ותיעוד בפלט
הקשחה לפי פרופיל תקן CIS Benchmark נותנת תוצאה רק אם היא ניתנת לשחזור. לכן כל פרמטר שהוגדר נשאר לא סימון „בוצע” בדוח, אלא תיאור שאפשר להחיל שוב — בצומת חדש, בבנייה מחדש או בשחזור לאחר תקלה. להלן ערכה שאנו מוסרים ללקוח יחד עם העבודות.
- תצורות צמתים בצורה הצהרתית. פרמטרי ליבה, הרכב שירותים, הרשאות לקבצים, כללי תיעוד יומנים והגדרות כניסה — עם ציון איזה סעיף בפרופיל סוגר כל ערך.
- חריגים עם נימוק. כל מה שסטה במכוון מהתקן לשם תאימות עם המערכת היישומית מוצג בנפרד: אחרת הבדיקה האוטומטית הראשונה נראית כמו תקלה.
- מדיניות גישה ותפקידים. מטריצת „תפקיד → פעולות → תחום פעולה”, הפרדת הרשאות של מנהל ובעל האפליקציה, כניסה במפתחות במקום סיסמאות ארוכות-חיים, סדר מתן גישה זמנית.
- סכמת תשתית וגבולות אמון. מה נמצא היכן, אילו צמתים נחשבים לתקן, היכן נקודות הכניסה ומה מגביל תנועה בין סגמנטים.
- נוהל תגובה לסטיות. לאן מגיע האות, איזה סף נחשב לקביל, מי ובכמה זמן מטפל בפער, כיצד נרשמת ומבוטלת סטייה זמנית.
- תיעוד תפעול. פריסת צומת מאפס, עדכון התקן ביציאת ענף חדש של הפרופיל, חזרה לתצורה קודמת והשלכותיה.
- דוח מצב לפני ואחרי. שיעור הסעיפים שנסגרו, רשימת החריגים שהתקבלו, סטיות חוזרות — בסיס למחזור הבדיקה הבא.
עם ערכה כזו, הכנסת צומת חדש נעשית לפי תרחיש אחד, והפערים נראים בבדיקה מתוכננת, לא ברגע התקרית.
מקרה בוחן: צמצמנו את שיעור הסטיות מ-38% ל-4%
מה היה לפני
מלאי של ~400 שרתים חי עם הגדרות שתוקנו ידנית ב-SSH: מישהו סגר פורט מיותר, מישהו לא. השוואה עם פרופיל Level 1 של CIS Benchmark הראתה 38% צמתים עם סטיות — וזה לא מספר חד-פעמי, אלא מצב שחזר על עצמו בכל הרצה.
פריסת שינוי אחד ארכה עד יומיים: התיקונים עברו דרך בקשות, חלק מהצמתים נפלו מהמדגם ונפרדו מהתקן. בנפרד הצטבר סוג של כשלים — אחרי אתחול השירות לא עלה, כי כלל שנוסף פעם ביד לא נכנס לפרופיל התקן.
מה שינינו ומה נהיה
ההגדרות הועברו למצב של קוד: תפקידי Ansible לכל פרופיל, תבניות פרמטרים במאגר, הרצה אידמפוטנטית על המלאי וסורק שמשווה את המצב בפועל לתקן ומחזיר הפרש שורה-שורה.
כל שינוי עובר בדיקה ונפרס בהרצה אחת — על כל המלאי זה כארבעים דקות במקום יומיים, והחזרה לאחור היא החזרת הגרסה הקודמת של ההגדרות.
4% הנותרים אינם חוסר גמור, אלא חריגים מנוהלים: מערכות ישנות שבהן הפרמטר שובר את האפליקציה. כל חריג מתואר עם סיבה ובעלים ונבדק בכל הרצה, כדי שהרשימה לא תתפשט. תקריות בגלל הגדרות נעלמו מהסיכום: ברבעון שאחרי ההטמעה היו אפס לעומת חמש בממוצע לפני.
מה עושים אם חלק מהשרתים כבר מוגדרים ידנית?
הגדרות ידניות אינן כאוס, אלא הקשר מצטבר: מישהו החליש דרישות הצפנה בגלל שירות אינטגרציה ישן, מישהו הרחיב הרשאות של חשבון שירות כדי שסוכן הניטור לא ייפול. להחיל פרופיל CIS Benchmark על מלאי כזה „בכוח” פירושו לקבל כשלים של שירותים פעילים כבר ביממה הראשונה.
לכן את ההרצה הראשונה עושים במצב בדיקה בלבד: מערכת ניהול התצורות וסורק המדיניות אוספים דוח על פערים בלי לשנות אף פרמטר בשרתים.
את הדוח מפרקים לשלוש קבוצות: פערים אמיתיים, סטיות מכוונות ומקרים שנויים במחלוקת. את הראשונים סוגרים בשינוי רגיל דרך תפקיד, ואת השניים והשלישיים מעבירים לקובץ החריגים של הפרופיל — עם בעלים, סיבה ותאריך בדיקה חוזרת. חריג בלי בעלים ותאריך לא פותחים: אחרת התקן תוך חודשים הופך לרשימת היתרים ומפסיק להבטיח משהו.
בהמשך המלאי מתקדם בגלים לפי תפקידים. תחילה סביבת בדיקה וקבוצה קטנה של שרתים, אחר כך סגמנטים לפי ייעוד: צמתי ווב, בסיסי נתונים, שירותי ביניים. מכונות חדשות מקבלות את התקן מיד בעת פריסה מתמונה, והקיימות נמשכות אליו בחלונות תחזוקה מתוכננים.
בין הגלים משווים התנהגות לפי מדדים ויומנים, וכל שינוי מוחזר ממערכת ניהול התצורות — חלון החזרה נשאר פתוח.
נקודה חשובה: הגדרות שתוקנו במשך שנים ביד מועברות לקוד. אחרת הן שוב ייפרדו, ובעוד חצי שנה נחזור לאותו דוח. כל חריג חי עד לתאריך בקרה, שאחריו או שמסירים את הסיבה, או שהוא מאושר מחדש עם נימוק.
התוצאה הנראית לעין של עבודה כזו — שיעור המלאי שחי בפועל לפי התקן גדל מגל לגל, ומספר הסטיות מצטמצם, בלי שהשירותים נעצרים באף איטרציה. התקן הופך לנקודת ייחוס, לא לפרויקט חד-פעמי.
ספקות נפוצים של מהנדסים לפני תחילת העבודה
החמרה לפי CIS Benchmark היא מאות בקרות ברשימת בדיקה אחת, ומיושמת בעיוורון היא באמת שוברת סביבה ייצורית: איסור עיגון תיקייה לקבצים זמניים קורע תרחישי בנייה, הגבלת מספר תהליכים במקביל מפילה תור מטפלים, וכיבוי גרסאות הצפנה ישנות מנתק תקשורת עם שירות חיצוני שאי אפשר לעדכן.
לכן לא מחילים את הפרופיל כולו. תחילה הרצה במצב בדיקה בלבד — מקבלים מפת תאימות: מה כבר בוצע, מה סוטה מדרישות האפליקציה, ומה ייסגר בלי השפעה על השירותים. בהמשך השינויים מתבצעים בשלבים, עם תיעוד תמונת מצב לפני כל שלב.
האם האפליקציות לא ייפלו אחרי ההחמרה?
לפני ההחלה, בקרות עם השפעה אפשרית מורצות על עותק של הסביבה תחת עומס אמיתי. פערים מנוסחים כחריגים עם נימוק ותאריך בדיקה חוזרת — האפליקציה עובדת, ורק סעיפים בודדים נשארים לא מכוסים, לא כל הפרופיל.
איך מחזירים לאחור אם השירות נפגע?
כל שלב הוא תפקיד נפרד עם החלה חוזרת, ולכן החזרה לאחור היא או החזרת תמונת מצב, או כיבוי תפקיד אחד. משחזרים תוך דקות, בלי ניתוח ידני של יומנים ותיקון תצורות מהזיכרון.
מי מעדכן את הפרופיל כשהתקן נבחן מחדש?
הפרופיל חי במערכת בקרת גרסאות כקוד. עדכון הוא משימה נפרדת: משווים בקרות חדשות לרשימת החריגים, מריצים בדיקה על עותק הסביבה ורק אחר כך מוציאים לשרתי הייצור.
נדבר על המשימה: מה צריך להערכה מדויקת
דיוק ההערכה בהקשחת ההגנה לפי CIS Benchmark תלוי לא בעובי התיעוד, אלא בשאלה אם אנחנו רואים את מצב המלאי בפועל. מספיק מלאי, גישה לקריאת תצורות והבנה של המגבלות — זה מספיק כדי לחזור עם תוכנית שלבים ותחזית של מאמץ.
- רשימת שרתים עם תפקידים: איזה מארח, איזו משימה הוא פותר, היכן הוא נמצא.
- מערכות הפעלה וענפי הפצות לכל צומת — מכך תלוי מערך הבדיקות.
- שיטת ניהול התצורה: תיקונים ידניים, סקריפטים או תפקידי ניהול — והיכן נמצאים קבצי המקור.
- סביבות והקשר ביניהן: ייצורית, קדם-ייצורית, בדיקות, וכן חלונות תחזוקה שבהם מותרים שינויים.
- גישות: חשבון עם קריאת תצורה והרשאות הרמה לתרחישי בדיקה, חיבור דרך bastion או ערוץ מאובטח.
- רמת CIS שנבחרה — בסיסית או מוגברת — והשירותים שאסור לכבות בלי לאבד פעילות.
- דרישות רגולטור או תקן פנימי שצריך דוח עבורן, וצורתו.
- נקודת חזרה: תמונות מצב וגיבויים, זמן שחזור צומת מהם.
הרשימה המלאה אינה חובה — נתחיל ממלאי וסביבת פיילוט אחת. אחרי הרצת בדיקות לפי הפרופיל הבסיסי נראה את אחוז הסטיות בפועל, ונפרק את העבודה לשלבים: מהכנת תפקידים ועד דוח תאימות.