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

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

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

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

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

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

ניהול תעודות דיגיטליות בארגון מתחיל בגילוי, לא ברכישה

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

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

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

הבעלות צריכה להיות מוגדרת בשני רבדים

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

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

מחזור חיים שאפשר לבקר ולמדוד

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

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

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

איפה אוטומציה נכשלת בפועל

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

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

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

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

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

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

תוכנית עבודה מעשית ל-90 יום

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

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

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

המדד החשוב באמת: יכולת שינוי מבוקרת

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

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