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

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

מה כולל מחזור החיים של תעודה ארגונית?

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

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

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

מיפוי הוא נקודת הכשל הראשונה

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

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

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

הנפקה: לא לתת לכל מערכת לבקש תעודה

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

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

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

פריסה נכונה אינה מסתיימת בהתקנת קובץ

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

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

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

חידוש תעודות: אוטומציה עם בקרות, לא אוטומציה עיוורת

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

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

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

ביטול, אירוע אבטחה ותיעוד לביקורת

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

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

מדדים שמנהלי IT ורכש צריכים לראות

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

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

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

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