אבטחת IaC: tfsec ו-Checkov לסריקת Terraform

סריקת Terraform: היכן נשברת התשתית

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

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

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

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

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

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

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

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

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

המהנדסים שלנו מגדירים את Checkov יחד עם tfsec כך שממצאים כאלה יחסמו את השינוי לפני ההחלה, ולא יהפכו למשימה לימים הבאים.

סריקת Terraform: מצבי הרצה והמגבלות שלהם

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

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

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

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

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

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

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

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

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

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

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

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

מקרה בוחן: פגמי קונפיגורציה שנתפסו לפני הפריסה

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

מה הראה המדד לפני הטמעת הבדיקות

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

מה שינינו

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

מה קרה בסוף

פגמי קונפיגורציה שמגיעים לסביבה — מ-25% ל-2-3%, חזרות לאחור — מ-18% לפחות מ-4%. בירור ממצא אורך דקות במקום שעות: בדוח נראים הכלל, הקובץ והשורה. כל שינויי הקונפיגורציה מכוסים בבדיקות, כולל תיקונים של שורה אחת.

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

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

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

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

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

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

התראות שווא, ספים ותורשת כללים

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

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

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

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

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

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

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

לצורך הדיון במשימה כדאי להכין:

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

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