מפתח דלף ב־GitHub? מחיקתו מהקוד אינה סוגרת את האירוע

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

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

נוהל לרבע השעה הראשונה

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

1. ביטול וסיבוב — בעל החשבון אצל הספק: בטלו את המפתח שנחשף ואמתו בממשק הספק שמעמדו אינו פעיל. הנפיקו אישור חדש עם ההרשאות הדרושות בלבד והעבירו אליו את השירותים התלויים בו דרך מנגנון ניהול הסודות. אם ביטול מיידי ישבית שירות חיוני, הכינו חלופה בדחיפות, הגבילו ככל האפשר את זמן החפיפה ותעדו מתי בוטל האישור הישן.
2. מיפוי החשיפה — מתחזק המאגר: שמרו את מזהה ההתראה, שם המאגר, הענף, נתיב הקובץ, מזהה ה־commit ומועד הגילוי. בדקו אם אותו אישור הופיע גם בענפים אחרים, בבקשות משיכה, בקובצי תצורה או בתוצרי CI. השתמשו במסמך האירוע במזהה מפתח של הספק או בפרט מזהה מקוצר; אל תעתיקו אליו את הערך המלא.
3. בדיקת שימוש — בעל השירות ואיש האבטחה: התחילו ביומני הספק מהמועד המוקדם ביותר שבו ייתכן שהאישור נחשף. חפשו פעולות שאינן מתאימות לשימוש הצפוי: גישה ממקור לא מוכר, יצירת משאבים, שינוי הרשאות או שליפת נתונים. שמרו את טווח הזמן שנבדק ואת הרשומות הרלוונטיות, גם אם עדיין אין ממצא חד־משמעי.
4. תיעוד והסלמה — מנהל האירוע: רשמו מי ביטל את האישור, מתי נעשה הביטול, אילו מערכות עברו לחלופה ואילו בדיקות עוד פתוחות. אם נמצאה פעולה לא מורשית, הרחיבו את הבדיקה למשאבים שההרשאות אפשרו גישה אליהם ושתפו את האחראים להם.

מה בודקים אחרי ביטול האישור

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

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

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

איך Secret scanning מסייע למפות את החשיפה

תיעוד Secret scanning של GitHub מתאר סריקה של היסטוריית Git בכל ענפי המאגר והתראות על סוגי אישורים מזוהים, בהם מפתחות API ואסימונים. הסריקה פועלת אוטומטית במאגרים ציבוריים; במאגרים פרטיים ופנימיים שבבעלות ארגון הזמינות תלויה בתוכנית החשבון ובהפעלת GitHub Secret Protection. פתחו את ההתראות במאגר כדי לאתר את מקום החשיפה, אך אמתו את ביטול האישור אצל הספק שהנפיק אותו.

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

מתי מנקים את היסטוריית Git

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

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

איך מונעים חשיפה חוזרת

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

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

קראו גם:

• אסימון API של Cloudflare דלף? Roll משאיר את אותן ההרשאות
• 2FA ב־GitHub עלול לנעול אתכם בחוץ: שמרו יותר מנתיב שחזור אחד