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

PKI, או Public Key Infrastructure, אינו רעיון חדש. ארגונים משתמשים בו שנים עבור VPN, Wi-Fi ארגוני, חתימה דיגיטלית, הצפנת דואר, אימות מחשבים ושירותים פנימיים. השינוי הוא באופן ההפעלה: במקום להחזיק תשתית CA מקומית, לדאוג לזמינות, לגיבויים, לחידושים ולניהול חומרה ייעודית, אפשר לצרוך את היכולות האלו כשירות ענן עם ממשקי ניהול, אוטומציה ובקרה מרכזית.

למה סיסמאות ו-MFA לא פותרים כל בעיית זהות

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

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

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

מה Cloud PKI משנה בצוות ה-IT

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

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

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

אוטומציה היא ההבדל בין תשתית עובדת לתשתית מנוהלת

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

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

איפה כדאי להתחיל עם Cloud PKI

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

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

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

החלטות ארכיטקטורה שאסור לדלג עליהן

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

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

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

מדדים שצריך להציג להנהלה ולרכש

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

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

טעויות נפוצות בהטמעת PKI בענן

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

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

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

Cloud PKI: הדרך הפשוטה רק כשבוחרים נכון

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

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

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