איך לנהל rotation של credentials בלי להשבית אינטגרציה

קטגוריה: אינטגרציות | תאריך: אוקטובר 2026

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

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

מה נחשב credential באינטגרציה

credential הוא כל סוד או אמצעי שמאפשר לרכיב להזדהות מול מערכת אחרת. לדוגמה:

• client secret של חיבור OAuth.
• מפתח API שספק או מערכת פנימית מנפיקים.
• סיסמה של משתמש שירות.
• תעודת client לאימות הדדי.
• access key לחיבור טכני.
• token ארוך חיים שנשמר עבור תהליך רקע.

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

להתחיל ממפת צרכנים ולא מרשימת סודות

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

• איזו מערכת מנפיקה אותו ואיזו מערכת צורכת אותו.
• אילו שירותים, jobs, פונקציות או שרתים משתמשים בו.
• אילו סביבות מושפעות: פיתוח, בדיקות וייצור.
• מי הבעלים הטכני ומי הבעלים העסקי של התהליך.
• איך הסוד נטען: secret manager, משתנה סביבה, כספת או מנגנון אחר.
• האם נדרש restart, reload או deploy כדי שהערך החדש ייכנס לשימוש.
• מהו הסימן העסקי שהחיבור חזר לפעול, מעבר לתשובת authentication תקינה.

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

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

להעדיף חפיפה מבוקרת בין ישן לחדש

המסלול הבטוח ביותר הוא תקופת חפיפה שבה שני credentials תקפים לזמן מוגבל:

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

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

מה עושים כשאין תמיכה בשני credentials במקביל

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

• להכין מראש את כל שינויי הקונפיגורציה וה-deploys.
• לעצור זמנית צרכנים שעלולים לבצע כתיבה בזמן המעבר.
• להחליף את ה-credential במערכת היעד.
• לעדכן ולטעון אותו בכל הצרכנים לפי סדר קצר ומוגדר.
• להריץ בדיקת authentication ובדיקה עסקית מבוקרת.
• לפתוח מחדש את התורים ולעקוב אחרי backlog וחריגים.

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

להפריד בין הפצה, טעינה ושימוש

שלושה שלבים שונים יכולים להיראות כאילו ההחלפה הצליחה:

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

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

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

בדיקת canary לפני מעבר מלא

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

1. ה-service מצליח לטעון את ה-secret.
2. מערכת היעד מזהה ומאשרת את הזהות החדשה.
3. ההרשאות מספיקות לפעולה הנדרשת, אך אינן רחבות מהמתוכנן.
4. קריאה או כתיבה מבוקרת מתבצעת בלי ליצור כפילות.
5. לוגים ומדדים משייכים את הפעולה לגרסת ה-credential בלי לחשוף אותו.

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

לטפל נכון בכשלי authentication בזמן המעבר

שגיאות 401 או 403 במהלך rotation אינן סיבה ל-retry מהיר ואינסופי. retry לא יתקן secret שגוי או הרשאה חסרה, והוא עלול ליצור עומס ולהסתיר את מקור התקלה.

הגדירו כללים ברורים:

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

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

בקרה בלי לחשוף סודות

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

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

אל תרשמו token, secret או header מלא גם לא ברמת debug. אם נדרש correlation, השתמשו במזהה שהמערכת מנפיקה או ב-fingerprint חד-כיווני שאושר לשימוש, ולא בערך שניתן לשחזר ממנו את הסוד.

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

לתכנן ביטול של הערך הישן

השלב האחרון הוא גם השלב שקל לדחות. לפני ביטול credential ישן בדקו:

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

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

תרחישי בדיקה שכדאי להריץ

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

1. השירות נטען עם הגרסה החדשה ומבצע פעולה מותרת.
2. השירות מקבל secret לא תקין ועובר למצב בטוח בלי retry אינסופי.
3. instance אחד נשאר על הגרסה הישנה ומזוהה בבקרה.
4. job שרץ פעם ביום משתמש בערך החדש במחזור הבא.
5. הערך הישן מבוטל וניסיון להשתמש בו נכשל באופן גלוי.
6. ההרשאות של הערך החדש חסרות פעולה אחת ונוצרת התראה מובנת.
7. deploy נכשל באמצע ורק חלק מהצרכנים עברו.
8. backlog מצטבר בזמן המעבר ומעובד לאחר החזרה בלי כפילויות.
9. תעודה חדשה נטענת יחד עם chain נדרש ותאריך התפוגה מוצג בבקרה.
10. תכנית החזרה עובדת גם כאשר אי אפשר להפעיל מחדש את הערך הישן.

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

שאלות נפוצות

כל כמה זמן צריך לבצע rotation?

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

האם restart מספיק כדי לטעון secret חדש?

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

האם אפשר להשתמש באותו credential בכמה אינטגרציות?

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

מה עושים אם מגלים credential שפג רק אחרי שהתהליך נעצר?

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

להתחיל מחיבור אחד ולתרגל את כל המחזור

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

אם החיבור כולל כמה שירותים, מערכת ליבה או jobs שאינם מתועדים היטב, אפשר להתחיל ב-POC תפעולי מצומצם שמוכיח את מנגנון ההפצה, הטעינה והבקרה. Adaptico מסייעת בתכנון אינטגרציות ואוטומציות ארגוניות, כולל הרשאות, תפעול, בדיקות ונקודות התאוששות. אפשר [ליצור קשר](/#contact) כדי למפות חיבור אחד ולבנות עבורו תהליך rotation מבוקר.