הגדרת כללי הגנה על סביבות ב-CI/CD

Environment protection rules: היכן נשברת הפריסה לפרודקשן

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

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

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

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

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

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

מה נותנת הגנת סביבות מנוהלת

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

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

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

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

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

מצבי הגנת סביבות: השוואת גישות

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

להלן חלופות טכניות והמשמעות שלהן. הבחירה תלויה בכמה אנשים משחררים לסביבה וכמה מורכבת החזרה לאחור.

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

איך אנחנו מטמיעים הגנת סביבות: שלבי העבודה

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

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

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

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

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

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

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

תצורות, מפות תפקידים ונהלים בתוצרים

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

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

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

מקרה בוחן: איך הפריסה הפסיקה לעקוף בדיקות

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

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

ההגנה הועברה מענפים לסביבות: עבור סביבת הייצור הפעלנו environment protection rules באמצעים של הפלטפורמה, בפרויקט הזה — GitHub.

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

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

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

מה לעשות אם protection rules כבר מוגדרים אבל עוקפים אותם?

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

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

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

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

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

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

שאלות טכניות נפוצות על הגנת סביבות

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

האם נצטרך לכבות פריסות אוטומטיות קיימות?

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

איך לשחרר תיקון חירום בלילה?

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

האם קבלנים חיצוניים יקבלו גישה לסביבת הייצור?

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

האם מאשר אחד מספיק?

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

נדון במפת הפריסה שלכם ובנקודות המעקף

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

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

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

כדי שהבדיקה תהיה עניינית, שלחו:

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

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