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

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

DigiCert הוא חלק מניהול תעודות, לא רק רכישה

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

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

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

איפה נוצרת החשיפה בפועל

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

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

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

צוואר בקבוק נפוץ: בעלים לא ברור

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

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

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

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

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

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

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

חידוש DigiCert בלי לחץ של הרגע האחרון

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

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

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

חתימת קוד דורשת משמעת נפרדת

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

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

רישוי, רכש ו-FinOps: איפה אפשר להחזיר שליטה

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

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

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

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

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