הגדרת בדיקה אוטומטית של CIS Benchmarks מקצה לקצה

מדוע בדיקה ידנית של CIS Benchmarks אינה ניתנת להרחבה

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

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

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

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

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

מה נותנת בדיקה אוטומטית של קונפיגורציות

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

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

כמה זמן מתפנה לצוות

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

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

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

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

אפשרויות בדיקה: סוכננית, ללא סוכן, היברידית

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

כיצד לבחור מצב לצי המערכות

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

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

שלבי ההטמעה: ממלאי ועד רגולציות

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

1. מלאי: רשימת הצמתים, תפקידיהם, הסביבות והבעלים — בלי מרשם זה אי אפשר להתקדם הלאה.
2. התאמת רמת הקפדנות לכל תפקיד ופסילת כללים שאינם רלוונטיים מלכתחילה בקונפיגורציה שלנו.
3. מדידת מצב ההתחלה: הרצה במצב דוח נותנת רשימת פערים עם דרגת החומרה שלהם.
4. הגדרת פרופילים וחריגות: כל סטייה מתועדת בכתב, עם נימוק.
5. תיקון הפערים דרך הקונפיגורציה, ולא בעריכה ידנית על הצומת — התוצאה חייבת להיות ניתנת לשחזור.
6. בדיקה לאחר שינויים ועדכונים: ההרצה חוזרת בכל מהדורה.
7. רגולציית הבדיקות: לוח זמנים, אחראים, סף פערים מותרים וסדר הסלמה.

הגדרת פרופילים וחריגות

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

בדיקה לאחר שינויים ועדכונים

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

מה נשאר בסיום: פרופילים, מדיניויות, דוחות

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

פרופילים וכללי חריגות

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

רגולציית בדיקות סדירות

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

תארו את התשתית שלכם — נחזור עם הערכת היקף ותוכנית עבודה.

מקרה בוחן: הסרנו פערי קונפיגורציה במאות צמתים

הצי של הלקוח — 300+ צמתים בכמה צוותים: שרתים קלאסיים ואשכולות קונטיינרים. לפני ביקורת חיצונית השוו המהנדסים ידנית את הקונפיגורציות לתקן CIS Benchmarks: המחזור ארך כשלושה שבועות, הפערים במועד הדוח — 38% מהצמתים, וכ-45 הערות חזרו מבדיקה לבדיקה. הן נסגרו, אך בפריסה הבאה הצומת שב שוב להגדרות הבסיסיות.

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

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

כיצד נבנתה העבודה עם חריגות

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

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

מה לעשות אם CIS Benchmarks כבר הוטמע חלקית?

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

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

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

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

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

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

ספקות טכניים ומגבלות הבדיקות

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

יש לנו סטיות מבוססות מהכללים

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

האם קונטיינרים ומכונות וירטואליות נבדקים באופן שונה?

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

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

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

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

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

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

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