הגדרת ניהול סודות בצינור CI/CD

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

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

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

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

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

מה משתנה לאחר סידור הגישה

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

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

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

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

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

אפשרויות אחסון הרשאות: השוואה ומגבלות

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

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

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

שלבי הטמעת ניהול סודות בצינור

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

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

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

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

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

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

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

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

מה שינו

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

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

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

מה התוצאה

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

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

במה שונה החלפה ידנית של מפתחות מרוטציה אוטומטית?

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

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

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

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

ניהול סודות מפסיק להיות משימת "לא לשכוח" והופך למדיניות עם תוחלת חיים מדידה לכל מפתח.

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

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

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

האם הנפקת סודות תאט את האספקה?

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

איך להנפיק גישה זמנית לקבלנים חיצוניים?

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

נדון במשימה: ננתח את סכימת ההרשאות ונעריך את היקף העבודה

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

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

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