הטמעת Policy as Code עבור Terraform (Sentinel ו-OPA)

Policy as Code: מדוע בדיקות ידניות אינן מחזיקות את התשתית

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

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

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

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

Policy as Code מעביר את הכללים האלה מהתכתבות לקוד, שבודק את התוכנית לפני היישום. Sentinel ו-OPA מתארים איסורים באופן הצהרתי: תגיות חובה, אזורים מותרים, איסור על כללי רשת בלתי מוגבלים, דרישות להרשאות גישה.

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

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

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

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

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

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

גישות לשליטה בתשתית: השוואת אפשרויות

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

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

שלבי הטמעת Policy as Code: מביקורת ועד מסירה

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

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

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

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

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

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

מקרה בוחן: מבדיקות ידניות לשליטה אוטומטית בשינויים

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

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

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

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

חסימות לפני היישום גדלו ממקרים בודדים ל-95% מכלל ההפרות שהתגלו. שיעור החזרות אחורה של שינויים שנגרמו משגיאה בתצורה ירד מ-12% ל-3%.

זמן הבדיקה של שינוי אחד הצטמצם מ-40 דקות של סקירה ידנית ל-3 דקות של בדיקה ממוחשבת, ובמקביל נפח הכללים גדל מ-15 ל-60, ומספר הפריטים הידניים ברשימת הבדיקה קטן פי שלושה.

במה מנוע מדיניות מובנה שונה מחיצוני?

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

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

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

ספקות טכניים: מגבלות וטעויות נפוצות בהטמעה

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

מה לעשות בזמן תקלה אם כלל מפריע לתיקון דחוף?

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

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

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

נדון במשימה: מאיפה להתחיל הטמעת בדיקות

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

מכם להתחלה מספיק:

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

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

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