סריקת אבטחת IaC: מה מוצאים במניפסטים לפני פריסה
סודות במניפסטים הם הפגם הנפוץ והיקר ביותר. מפתח גישה לרישום אימג'ים, טוקן של שירות חיצוני או סיסמת מסד נתונים, שנכתבים ישירות בתיאור ה-Pod או במשתני הסביבה של הבנייה, עוברים להיסטוריית המאגר, שם הם חיים זמן רב יותר מהמניפסטים עצמם.
לא די למחוק שורה בקומיט הבא: הערך נשאר בגרסאות קודמות ובמטמון הבונה, ולכן יש להחליף את הסוד עצמו, לבטל הרשאות שהונפקו ולהבין מי עוד השתמש בו.
הרשאות גישה עודפות מונחות כבר בשלב התיאור, ומשם הן משוכפלות בכל פריסה. חשבון שירות עם הרשאות אדמין של האשכול במקום שבו נדרשים רק קריאה וכתיבה של ענף אחד; קונטיינר שרץ כ-root; תפקיד שמורשה לפנות לכתובות חיצוניות, אף שדי לו ברשת הפנימית.
קו נפרד — שירותים שפתוחים החוצה כברירת מחדל: נקודת כניסה בלי הגבלת מקורות, אחסון נגיש לציבור, פורט דיבאג שנשכחו לסגור לפני שחרור.
סוג שלישי של פגמים — פער בין תיאור התשתית למצבה בפועל. תיקון ידני בעת תקלה סוגר את האירוע, אך נשאר בלתי מורגש: תוכנית היישום הבאה מציגה "אין שינויים", בעוד הסביבה כבר חיה לפי כללים אחרים.
בפריסה הבאה סביבה כזו או מוחקת את התיקונים הידניים, או נשברת בגללם — והשחזור נעשה לפי הזיכרון, לא לפי התיאור.
המחיר של כל אחד מהפגמים האלה מוכפל במהירות הפריסה: ככל שהשחרורים תכופים יותר, כך גדל הסיכוי להעביר סוד או הרשאה מיותרת לפרודקשן. בדיקות בתוך הצינור תופסות זאת לפני היישום — נפרט כיצד בנויה סריקת אבטחת IaC ומה בדיוק היא עוצרת בדרך לסביבה.
מה נותן בקרת תצורות: מהירות, כשלים, זמן השבתה
המשמעות של בדיקות מובנות אינה בעצם הסריקה, אלא באילו מספרים משתנים לאחר הפעלתן. אנחנו מסתכלים על ארבעה מדדים: זמן הבנייה, שיעור הפריסות שהיה צריך להחזיר לאחור, זמן השחזור לאחר יישום כושל וסך זמן ההשבתה. בקרת תצורות משפיעה על כל הארבעה אם היא מובנית בצינור, ולא מוצאת לשלב ידני נפרד.
מהירות הבנייה כמעט אינה נפגעת: נבדקים רק מודולים שהשתנו, התוצאה נשמרת במטמון בין הרצות, וכללים כבדים רצים במקביל לשאר השלבים. תוספת זמן הבנייה מסתכמת בכמה אחוזים בודדים — זה פחות באופן ניכר מזמן הבדיקה הידנית של שגיאה אחת בתצורה.
ההשפעה העיקרית — סוג הכשלים שפשוט מפסיק להגיע לסביבת הבדיקות. פורטים פתוחים החוצה, אחסון נגיש לציבור, תפקידים עם הרשאות עודפות, מפתחות גלויים בתוך תבניות — פגמים כאלה נתפסים בשלב בדיקת השינויים, ולא בשלב התפעול.
זמן השחזור מתקצר מאותה סיבה: התצורה חיה כמערכת קבצים מנוהלת גרסאות, ולכן יישום כושל מוחזר למצב הקודם, ולא מתוקן ידנית בסביבה חיה. זמן ההשבתה בגלל שגיאת תצורה עובר מטווח של שעות לטווח של דקות — הסביבה חוזרת למצב תקין באותה ריצה אוטומטית.
צפיות הפריסה היא תוצאה של מערכת בדיקות אחידה לסביבת הבדיקות ולסביבת העבודה. סחיפת תצורה נראית לפני היישום, ולכן פער בין סביבות מפסיק להיות הפתעה ברגע השחרור, והירידה בכשלים הופכת למדידה, לא להצהרתית.
מצבי בדיקה: השוואת גישות ומגבלותיהן
מצב אחד אינו סוגר את המעגל: הגישות נבדלות זו מזו במועד הפעולה ובמצב שהן בכלל רואות. בדיקה בזמן הבנייה קוראת תיאורים לפני היישום, בקרת פערים משווה בין המצב בפועל לזה המוצהר בסביבה, ביקורת מסתכלת על המעגל שכבר נפרס לפי לוח זמנים, וסקירה ידנית נשענת על הקשר שאינו מתבטא בכלל.
| מצב | מה מגלה | היכן מוגבל |
|---|---|---|
| בדיקה בזמן הבנייה | פורטים פתוחים, פרמטרים אסורים, שגיאות קישור בתיאורים לפני היישום | אינה רואה תיקונים שנעשו במעגל ביד |
| בקרת פערים | סטייה של המצב בפועל מהמוצהר | אינה מבחינה בין שינוי מכוון לשינוי מקרי |
| ביקורת תצורות תקופתית | סטיות מצטברות בהגדרות ומשאבים מיושנים | בין הרצות הסטייה נשארת בלתי מורגשת |
| סקירה ידנית של תיאורים | שגיאות משמעות שאי אפשר לתאר בכלל | אינה ניתנת להרחבה ותלויה בקשב של הבודק |
המסקנה מההשוואה פשוטה: אי אפשר לסגור את המעגל במצב אחד. הבנייה חוסמת את רוב השגיאות לפני הפריסה, בקרת הפערים תופסת את מה שחמק ממנה, הביקורת משלימה סטיות איטיות, והסקירה נשארת לשינויים שבהם נדרש הקשר אנושי.
את הכללים מחזיקים באופן הצהרתי — מערכת מדיניות אחת פועלת גם בזמן הבנייה וגם בסביבה חיה, למשל דרך Checkov בשילוב עם משימות לפי לוח זמנים.
שלבי הטמעה: ממלאי ועד מסירה לתפעול
הטמעת בדיקות אבטחה בתיאורי תשתית אינה מתחילה מהפעלת סורק בבנייה. קודם מתעדים מה בדיוק בודקים: מאגרים עם מניפסטים פעילים, מודולים לשימוש חוזר, תבניות סביבה. אחרת כבר בריצה הראשונה מתקבלות מאות התראות על ענפים ארכיוניים, הכלל מעצבן את הצוות ומכבים אותו כעבור שבוע.
- מלאי תצורות. אוספים רשימה של מאגרים, ענפים ומודולים שבאמת מיושמים בסביבות חיות. ארכיוני וניסיוני מסמנים בנפרד — הוא לא נכנס לכללים ולא לדיווח.
- תרשים כללים ורמות חומרה. לכל סוג משאב מחליטים מה חוסם את הבנייה, מה נותן אזהרה, ומה נשלח רק לדוח. את התרשים מתאמים עם הצוותים מראש, כדי שכלל לא ישתנה ביום השחרור.
- הגדרת כללים וחריגים. מפעילים מערכת בדיקות, מגדירים חריגים לפי נתיבים ותגיות משאבים, ואת תצורת הסורק מחזיקים במאגר — אז שינויים עוברים סקירה כמו קוד רגיל.
- בדיקה בסביבת בדיקות. מריצים על עותק של מניפסטים אמיתיים, מודדים מספר התראות, זמן בדיקה ושיעור חיובי שווא. בנפרד בודקים עד כמה הבדיקה מאריכה את הבנייה — אם זה מורגש, מוציאים כללים כבדים לשלב נפרד.
- דיכוי רעש. סטיות לגיטימיות סוגרים בחריגים ממוקדים עם הערה ותאריך בחינה מחדש, ולא כיבוי של הכלל כולו. כך רשימת ההתראות נשארת קצרה ובאמת קוראים אותה.
- מסירה לתפעול. מחברים את הבדיקה לצינור הראשי, ממנים אחראים לניתוח דוחות, מוסרים תיעוד ומנתחים עם הצוותים ממצאים טיפוסיים.
לאחר המסירה שלבים 3 ו-5 חוזרים על עצמם עם הופעת סוגי משאבים חדשים — תרשים הכללים חי יחד עם התשתית, ולא קופא בתאריך ההטמעה.
תוצרים במסירה: מודולי IaC, מדיניות ונהלים
סריקת תיאורי תשתית מסתיימת לא בדוח, אלא בסט תוצרים שהצוות שלכם ממשיך לנהל בעצמו. הכול נשאר במאגר שלכם לצד תיאור הסביבות — בלי תלות במהנדסים שלנו או בשירותים סגורים.
- מודולי IaC לשימוש חוזר: בלוקים לתיאור רשתות, אחסון, תפקידים ומסדי נתונים עם פרמטרים אחידים — שירות חדש נפרס מתבנית מוכנה, ולא בהעתקת קובץ של מישהו אחר.
- ספריית כללים מכוילת למעגל שלכם: אילו בדיקות חוסמות את הבנייה, אילו פועלות כאזהרה ובמה מוצדק כל חריג.
- מדיניות גישה לסביבות, לסודות ולמאגרי אימג'ים: תפקידים, תחומי אחריות וסדר הענקת הרשאות — מהנדס חדש נכנס למעגל לפי הנחיות, לא לפי התכתבות.
- נהלי תגובה: מי מנתח התראה, באיזה מקרה הבנייה נעצרת, ובאיזה מקרה נרשמת סטייה עם מועד תיקון ואחראי.
- תיעוד תצורה: מפת סביבות, קשרים בין שירותים ונקודות שבהן תוצאת הבדיקה מוטמעת בצינור הבנייה והאספקה.
- תרשימי תשתית שנבנו מהתיאור ויומן ערכי בסיס — רואים כמה ממצאים היו בהתחלה ואילו סוגים נעלמו.
התוצרים נמסרים עם היסטוריית שינויים וזכות עריכה לצוות שלכם. המהנדסים שלנו נשארים בקשר לניתוח ממצאים שנויים במחלוקת ולהרחבת ספריית הכללים.
מקרה בוחן: איך הסירו דליפת סודות מהתצורות
הלקוח — צוות מוצר עם כמה עשרות מאגרים שבהם התשתית מתוארת באופן הצהרתי. סודות נכנסו לתצורות מתוך אינרציה: סיסמה למסד נתונים נרשמה ישירות במשתני הסביבה של המניפסט, מפתחות לשירותים חיצוניים — בפרמטרים של המודול. הבדיקה הייתה ידנית: לפני שחרור מהנדס עבר בעיניים על ההבדלים בתצורות.
זה לקח 3-4 שעות לשחרור, והפגמים בכל זאת חמקו. ברבעון תועדו 5-6 דליפות סודות שהגיעו למעגל העבודה. ניתוח אירוע אחד לקח 6-10 שעות: קודם להבין איזה מפתח דלף והיכן השתמשו בו, אחר כך לבטל ולהחליף אותו, ואז לבדוק אם היו פניות. כ-40% מהפגמים שנמצאו היו חוזרים — אותו סוג שגיאה צף במאגר חדש כעבור כמה שבועות.
הבדיקות הוטמעו בצינור הבנייה והאספקה. Gitleaks רץ על כל בקשת מיזוג וחוסם שינוי אם שורה דומה למפתח או טוקן; המפתח מקבל מיד קובץ ומספר שורה. במקביל, ניתוח סטטי של תצורות תופס פורטים פתוחים, הרשאות עודפות וכרכים לא מוצפנים לפני שהם מגיעים לענף הראשי. כלל נפרד סגר את היסטוריית הקומיטים — סודות ישנים כבר לא נמשכים לשחרורים חדשים.
כעבור חודשיים ניתוח אירוע לקח 20-30 דקות במקום 6-10 שעות: ההתראה מגיעה עם הקשר מוכן, ולא כשאלה "איפה זה נמצא". פגמים חוזרים ירדו לבערך 5% — כלל שנוסף פעם אחת למדיניות המשותפת עובד בכל המאגרים בבת אחת. הביקורת הידנית לפני שחרור הוסרה לחלוטין, והשעות האלה עברו למשימות פיתוח.
במה נבדלות בדיקות בזמן בנייה מבדיקות בסביבת הרצה?
בדיקה בזמן בנייה עובדת עם תיאור התשתית כקוד: מניפסטים, תבניות ומודולים. היא עונה על השאלה מה בדיוק אנחנו מתכוונים לפרוס — כללי גישה פתוחים, הרשאות עודפות של תפקידים, כרכים לא מוצפנים, הפניות לאימג'ים לא מאומתים. בקרה כזו זולה: היא מתבצעת לפני היישום ועוצרת שינוי מסוכן בשלב הבדיקה, בלי לדרוש גישה למעגל העבודה.
גבולות הכיסוי של בקרה סטטית נוקשים: היא רואה רק את מה שמתואר בקוד. משאב שנוצר ידנית דרך לוח בקרה, חשבון שנוסף מחוץ לתיאור, או כלל שתוקן ישירות במעגל — לא נכנסים לניתוח, והפער בין התיאור למצב בפועל נשאר בלתי נראה עד ההשוואה הבאה.
בדיקה בסביבת הרצה קוראת את המצב בפועל: אילו תפקידים קיימים, אילו כללים פתוחים, אילו כרכים מותקנים, מה באמת רץ. היא תופסת סחיפת תצורה ודרכי עקיפה, אבל לא יכולה למנוע דבר — השינוי כבר הוחל, ואנחנו מגיבים בדיעבד.
לכן הבחירה במצב בקרה אינה "או", אלא "וגם", והמשימות של המצבים שונות. הבנייה אחראית על מניעה, הסביבה — על גילוי פערים ואישור שהנפרס תואם לתיאור שנבדק. שכבה שלישית — השוואה קבועה בין התיאור למצב בפועל: היא מראה היכן המעגל סטה מהקוד ומחזירה מקומות כאלה לשליטה.
ספקות טכניים: התראות שווא וכיסוי כללים
"הסורק יעשה רעש, נטבע בהתראות" ו"התשתית שלנו כבר נפרסה ידנית" — אלה ההתנגדויות שאנחנו שומעים לרוב. ושתיהן נסגרות בכיוונון עדין של כללים, לא בוויתור על בדיקות.
מתחילים בסט בסיסי: פורטים ציבוריים, היעדר הצפנה, גישה פתוחה לאחסון. את השאר מפעילים לפי קצב הניתוח — כך הרעש לא מפריע למה שבאמת מוביל לכשל.
הכללים מפיצים התראות שווא — מה עושים עם זה?
כל התראה מנתחים ומסווגים לשלוש קבוצות: שגיאה אמיתית, חריג בגלל הקשר, ניסוח לא מדויק של הכלל. עבור השנייה רושמים חריגים לפי נתיב ותג משאב, עבור השלישית — מתקנים סף או מכבים עם סימון במרשם. הרעש יורד למקרים בודדים.
אפשר להטמיע בהדרגה בלי לחסום שחרורים?
כן. בהתחלה הבדיקות פועלות במצב אזהרה ולא עוצרות את הצינור. אחר כך החסימה מופעלת לסביבות בדיקה, ורק לאחר שסט הכללים התייצב — לסביבות פרודקשן.
התשתית כבר נפרסה — לתאר הכול מחדש?
לא. משאבים קיימים מייבאים למצב: הם ממשיכים לעבוד, אבל עוברים לניהול של תיאורים. בהמשך הבדיקות פועלות על שינויים ומכסות בהדרגה את מה שכבר נפרס.
מה עושים עם סודות במאגר?
כלל נפרד מחפש מפתחות וטוקנים בתיאורים ובמשתנים. את מה שנמצא לא רק מסמנים: מבטלים את המפתח, מעבירים אותו למאגר סודות, ובקוד שמים הפניה. את היסטוריית הקומיטים מנקים — קובץ שנמחק נשאר בה.
נדון במשימה: מאיפה להתחיל הטמעת בדיקות
כדי שהשיחה תהיה עניינית, כדאי לאסוף מראש כמה תוצרים — אז בפגישה הראשונה נסמן את היקף הביקורת של המצב הנוכחי ואת סדר העבודות, ולא נברר דברים בסיסיים. להלן מה שלרוב מזרז את תחילת ההטמעה של סריקת אבטחת IaC בצינור הבנייה.
- רשימת סביבות: פיתוח, בדיקות, טרום-פרודקשן, פרודקשן, כמה חשבונות ואשכולות, היכן תצורות מנוהלות ידנית והיכן כבר מתוארות בקוד.
- תרשים הצינור הנוכחי: באיזה שלב רצות הבדיקות, מה חוסם את הבנייה ומה עובר כאזהרה.
- מקומות בעייתיים ידועים: אירועים בגלל פערי תצורות, סחיפה בין סביבות, כללים שעוקפים ידנית.
- רשימת כלים לתיאור תשתית: מודולים, תבניות, דרך אחסון המצב — כדי להבין מה לחבר ראשון.
- דרישות להרשאות ולתגובה: מי מנתח ממצאים, מה נחשב חוסם, לאן נשלחים דוחות ואיך מעצבים חריגים.
- מגבלות שחרורים: חלונות שבהם אפשר לשנות את הצינור, ועיכוב בנייה מותר.
- אחראים: מי בעל קוד התשתית ומקבל החלטות בכללים שנויים במחלוקת.
זה יספיק כדי לחזור עם תוכנית הטמעה: שלבים, עדיפות סביבות, חלוקת תפקידים ונקודות בקרה. תארו את המשימה בצורה נוחה — נחזור עם הערכה ותוכנית עבודה.