איך להחליף אלפי סיסמאות של שירותים בלי להפיל את האתר?

⁦TL⁩;⁦DR⁩

• סיבוב (Rotation) הוא השלב האחרון: החלפת למעלה מ-1,000 אישורי שירות (service credentials) ב-150 יישומים שונים ללא כל השבתה, הוכיחה שרוב העבודה מתבצעת עוד לפני שמחליפים סיסמה אחת.

• בקרות אבטחה המיועדות לבני אדם מפספסות אישורי שירות: לאישורי שירות אין אדם שיקבל התראה, אין נתיב ל-MFA, לעיתים קרובות אין להם בעלים מוגדר, והם נכשלים בשקט. בנוסף, העותקים שלהם מתפזרים בתוך סקריפטים, קבצי תצורה (config files), צינורות CI/CD וצ'אטים.

• קודם כל מלאי, אחר כך SCALER: יש לדעת מי משתמש בכל חשבון, מי הבעלים שלו והאם הוא עדיין נחוץ. לאחר מכן יש לבצע את ששת השלבים הבאים לפי הסדר: Scale, Classify, Assign, Lifecycle, Enforce, ו-Rotate.

⁦Mayank Sethi⁩

בעבר הובלתי תהליך של סיבוב סיסמאות עבור למעלה מ-1,000 אישורי שירות ביותר מ-150 יישומים. סיימנו את התהליך ללא השבתות כלל. הסיבוב עצמו היה החלק הקל; רוב העבודה נעשתה לפני ששינינו אפילו סיסמה אחת.

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

הפער שסקירת זהות סטנדרטית מחמיצה

דמיינו סקירת זהות טיפוסית. אימות רב-גורמי (⁦MFA⁩) מופעל עבור כל עובד. כניסה יחידה מכסה את היישומים העיקריים. מדיניות רשת מגבילה מי יכול להגיע לייצור. הביקורת עוברת.

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

הנתונים הרחבים בנושא אישורים שהודלפו מצביעים על אותה מגמה. חברת GitGuardian גילתה 28.65 מיליון סודות (secrets) מקודדים חדשים בהתחייבויות (commits) ציבוריות ב-GitHub בשנת 2025, עלייה של 34% בהשוואה לשנה הקודמת. כאשר בדקה מחדש סודות משנת 2022 בינואר 2026, התברר כי למעלה מ-64% מהם עדיין היו תקפים. אישורים דולפים ונשארים פעילים במשך שנים.

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

ארבע דרכים שבהן אישורי שירות שונים מסיסמאות משתמש

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

אישורי שירות לא זוכים לתמיכה כזו:

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

• אין נתיב ⁦MFA⁩: אפליקציה לא יכולה לאשר הודעת דחיפה.

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

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

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

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

סיסמאות משתמש הן בעיה של אנשים, והנחיות, הדרכה ו-⁦MFA⁩ מטפלים ברובן. אישורי שירות הם בעיית מלאי. אתה פותר אותם על ידי ידיעת מה קיים, מי משתמש בו ומי עונה על זה.

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

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

הם גם מחזיקים בגישה קבועה (standing access). חשבון שירות שומר לרוב על אותן הרשאות ביומו האחרון כמו ביומו הראשון, גם לאחר שהצורך בהן הצטמצם. מאחר שדבר אינו מחייב שינוי, האישור נשאר בתוקף.

אישורי שירות נוטים להתפשט. כדי לבצע עבודה, צוותים מעתיקים אותם לסקריפטים, קבצי תצורה, צינורות CI/CD (continuous integration) ושרשורי צ'אט. GitGuardian גילתה כי במאגרים פנימיים יש סבירות גבוהה פי שישה להימצאות סודות מקודדים מאשר במאגרים ציבוריים. כ-28% מהתקריות מתחילות מחוץ למאגרים, בכלים כמו Slack, Jira ו-Confluence.

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

שני אינסטינקטים שמחמירים את זה

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

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

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

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

מה יש למלאי לענות

לפני שסובבנו משהו, כל חשבון שירות נזקק לשלוש תשובות:

• מי משתמש בו? אילו יישומים, עבודות או צינורות מתחברים אליו כיום?

• מי הבעלים שלו? איזה אדם אחראי על זה עכשיו?

• האם זה עדיין נחוץ? האם משהו השתמש בו לאחרונה?

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

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

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

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

שישה שלבים, תמיד בסדר הזה

לא היה שם למה שעשינו באותו זמן. במבט לאחור, זה היה שישה שלבים, תמיד באותו סדר. מאז קראתי לזה ⁦SCALER⁩, כי הסדר הוא החלק שכדאי לשמור.

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

• סיווג: קשר כל חשבון לאפליקציה שבה הוא תומך.

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

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

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

• סובב: שנה אישורים בצורה שבה תוכל להפוך במהירות אם משהו נשבר.

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

מדוע נתיב חזרה הפך את הסיבוב לבטוח יותר

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

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

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

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

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

אם הייתי מריץ את התוכנית הזו שוב, הייתי שומר על ארבעת השלבים הראשונים כפי שהם, אך משנה את שיטת האימות. בפלטפורמות התומכות בשני מפתחות פעילים, אימות מבוסס מפתח (key-pair authentication) מאפשר חפיפה בין המפתח הישן לחדש עד שהאימות מושלם, ובכך מבטל את הצורך בחזרה לאחור.

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

⁦FAQ⁩

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

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

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

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

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

תחילה בנה את המלאי ולאחר מכן סובב. השיטה ⁦SCALER⁩ מפעילה שישה שלבים לפי סדר: קנה מידה, ⁦Classify⁩, ⁦Assign⁩, ⁦Lifecycle⁩, ⁦Enforce⁩, ו-⁦Rotate⁩. בפלטפורמות שאינן יכולות להחזיק שתי סיסמאות חוקיות בו-זמנית, נתיב חזרה זמני מונע מסיבוב כושל להפוך להפסקה.

מאמר זה הוא פוסט אורח. ⁦Views⁩ והדעות המובעות בפרסום זה הם אלו של המחבר בלבד ואינם משקפים את המדיניות, העמדה או השקפות הרשמיות של ⁦GitGuardian⁩. התוכן מסופק למטרות מידע; ⁦GitGuardian⁩ אינה נושאת באחריות לכל שגיאות, השמטות או תוצאות הנובעות מהשימוש במידע זה. אם יש לך שאלה כלשהי בנוגע לתוכן, אנא פנה ישירות למחבר. הדעות המובעות כאן הן אך ורק של המחבר ואינן מייצגות את הדעות, העמדות או המדיניות של ⁦Group⁩ 1001 ⁦Insurance Holdings⁩, ⁦LLC⁩ או שותפיה.

חוקרי GitGuardian הגיעו ל-44 אשכולות (clusters) Kubernetes פעילים באמצעות סודות שדלפו, ו-30% מהם היו חשופים במשך יותר משנתיים. הנה כיצד OWASP Kubernetes Top 10 מסביר את סיכוני האבטחה הללו, ומדוע K03, כשלים בניהול סודות (Secrets Management Failures), הופך דליפה בודדת לשרשרת של פריצות.

⁦Dwayne McDaniel⁩

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

⁦Soujanya Ain⁩