4 דברים ששאלו אותנו השבוע על תעודות אבטחה דיגיטליות

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

התשובה הקצרה: ההצפנה זהה. אבל מה שעומד מאחורי התעודה — לא.

תעודה חינמית (למשל Let's Encrypt) נותנת בדיוק דבר אחד: הוכחה שמי שהנפיק אותה שולט בדומיין. אבל מי הנפיק אותה? אין בדיקת זהות, אין ישות משפטית מאחוריה, ואין למי לפנות.

מה לא מקבלים בתעודות חינמיות:

אימות זהות ארגונית (OV/EV) — אף אחד לא בדק שהחברה שמאחורי האתר באמת קיימת ורשומה

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

תמיכה אנושית ו-SLA — בעולם החינמי יש פורום קהילתי, לא ערוצי תמיכה

רק תעודות שאינן TLS — חתימת קוד, S/MIME, IoT, תעודות מכונה. פשוט לא קיימות שם

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

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

למי תעודה חינמית לא מתאימה?

מסחר אלקטרוני וכל אתר שמקבל תשלומים (PCI DSS), פיננסים, ביטוח ובריאות, מגזר ציבורי, חתימת קוד, S/MIME, תעודות מכונה ו-IoT, וכל ארגון עם דרישת SLA או יותר מכמה עשרות תעודות לניהול.

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


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

מי שמחליט על אורך החיים של תעודות TLS הוא פורום CA/Browser — גוף שבו יושבים בעיקר יצרני הדפדפנים (Apple, Google, Mozilla, Microsoft). היוזמה לקיצור הגיעה מהם. יצרני התעודות דווקא היו הצד שביקש להאט את הקצב.

איפה אנחנו נמצאים בפועל:

  • התוקף כבר ירד ל-200 יום
  • בשנה הקרובה הוא יורד ל-100 יום
  • והיעד הסופי: 47 יום 

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

למה זה קורה? כי תעודה שנפרצה או הונפקה בטעות מהווה בעיה בדיוק כל עוד היא בתוקף. מנגנוני הביטול (CRL/OCSP) מעולם לא עבדו טוב באמת — דפדפנים מתעלמים מהם או נכשלים בשקט. קיצור התוקף הוא פתרון אגרסיבי אבל אפקטיבי.

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

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


שתי התשובות נכונות, וזה בדיוק העניין.

מחשב קוונטי שיודע לשבור RSA ו-ECC עדיין לא קיים. אבל התקיפה כבר התחילה, והיא נקראת Harvest Now, Decrypt Later: תוקפים אוספים היום תעבורה מוצפנת ושומרים אותה בצד, בהנחה שבעוד עשור יהיה להם במה לפתוח אותה.

השאלה המעשית פשוטה: כמה שנים המידע שלכם צריך להישאר סודי? אם התשובה גדולה מ-10 — הבעיה שלכם היא כבר היום.

מה כבר קרה: NIST פרסם תקני הצפנה פוסט-קוונטיים רשמיים (ML-KEM, ML-DSA, SLH-DSA), ורגולטורים בארה"ב ובאירופה כבר מפרסמים לוחות זמנים למעבר.

ומה DigiCert כבר עושה בנושא: התשתית כבר קיימת בפועל, לא בהצהרות. DigiCert Private CA מנפיקה כיום תעודות פרטיות עם ML-DSA ו-SLH-DSA, בגיבוי HSM שתומכים ב-PQC (Thales SafeNet Luna ו-Crypto4A). Trust Lifecycle Manager כבר יודע להנפיק ולנהל תעודות PQC פרטיות דרך פרופילים ייעודיים. ובמקביל, DigiCert Labs מציעה תעודות quantum-safe לבדיקות, כדי שארגונים יוכלו לנסות בסביבת מעבדה לפני שזה הופך לחובה.

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


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

איפה מתחבאות תעודות שאף אחד לא מנהל

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

  • מאזני עומסים ו-Reverse Proxy — F5, NGINX, HAProxy. לרוב הותקנו פעם אחת ונשכחו
  • קונטיינרים ו-Kubernetes — תעודות בתוך Secrets, service mesh, mTLS בין שירותים. נוצרות ונמחקות בקצב שאיש לא עוקב אחריו
  • צינורות CI/CD — מפתחות וטוקנים לחתימה שיושבים כמשתני סביבה, לעיתים בהיסטוריית ה-repo
  • סביבות פיתוח ובדיקות — תעודות self-signed שהודבקו "רק לרגע" והגיעו לפרודקשן
  • תשתית רשת — נתבים, מתגים, VPN, ממשקי ניהול של חומות אש
  • מדפסות, מצלמות אבטחה ובקרי מבנה — תעודות ברירת מחדל של היצרן שמעולם לא הוחלפו
  • שרתי דואר, שרתי קבצים ובסיסי נתונים — חיבורים מוצפנים פנימיים
  • תשתית ענן — Load balancers, API Gateways, CDN. לעיתים בחשבון ענן שהוקם לפיילוט ונשכח
  • סוכני AI ו-API keys — הקטגוריה החדשה, וזו שגדלה הכי מהר
  • תעודות שהנפיק עובד שכבר עזב — קלאסיקה. אין מי שמקבל את התראת התפוגה, כי תיבת הדואר נסגרה

מה קורה כשתעודה פגה — ולמה זה יקר יותר ממה שנדמה

תעודה שפגה תוקף לא מתריעה ולא מתקשרת. היא פשוט שוברת את החיבור.

  • השבתת שירות מיידית — אתרים, אפליקציות ו-APIs מפסיקים להגיב. במערכות B2B זה מפיל גם את הלקוחות שלכם
  • אזהרת אבטחה אדומה בדפדפן — הלקוח לא רואה תקלה טכנית. הוא רואה "האתר הזה לא בטוח" ועוזב
  • כשלים שקטים בשרשרת — אינטגרציית API שמפסיקה להעביר נתונים בלי שאיש מבחין. מתגלה ימים אחר כך, כשהנתונים כבר חסרים
  • זמן אבחון ארוך — צוותים מבזבזים שעות במרדף אחרי באג לפני שמישהו חושב לבדוק את התעודה. הכשל נראה כמו כל דבר חוץ מהסיבה האמיתית
  • הפרות SLA וקנסות — השבתה שאתם משלמים עליה חוזית
  • פגיעה בתדמית — במיוחד כשמדובר בחברת אבטחת מידע או בספק תשתית
  • חשיפה רגולטורית — במגזרים מפוקחים, השבתה שנגרמה מכשל תפעולי בסיסי היא בדיוק מה שביקורת מחפשת

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

שתף:

פוסטים נוספים: