שרת Microsoft CA, או בשמו המלא Active Directory Certificate Services, נראה לרוב כמו רכיב תשתית ותיק ויציב: הוא הוקם פעם אחת, הונפקו ממנו תעודות לשרתים, ל-VPN ולמשתמשים, והוא ממשיך לעבוד. אבל זו בדיוק הסיבה ששהשאלה למה ארגונים נוטשים את Microsoft CA ועוברים ל-Cloud PKI? הפכה לשאלה תפעולית ולא רק טכנולוגית. כשהתעודות מתרבות, כוח העבודה הופך היברידי והאפליקציות עוברות לענן, תשתית CA מקומית עלולה להפוך לנקודת חיכוך, סיכון ועלות שקשה לראות בתקציב הראשוני.

המעבר אינו אומר ש-Microsoft CA הוא מוצר לא תקין או לא מאובטח. עבור ארגון שמבוסס כולו על Active Directory מקומי, עם מעט תרחישי הנפקה וצוות תשתיות זמין, הוא עדיין יכול להיות בחירה הגיונית. הבעיה מתחילה כשהארגון מנסה להרחיב אותו לתרחישים שהוא לא תוכנן לנהל בפשטות: מכשירים מחוץ לרשת, שירותי ענן, עומסי DevOps, עובדים ללא Domain Join, וחידוש תעודות בקצב מהיר.

Microsoft CA עובד היטב - עד שהמורכבות גדלה

AD CS משתלב היטב עם סביבת Windows ו-Active Directory. באמצעות Group Policy ו-auto-enrollment אפשר להפיץ תעודות למחשבי דומיין, לנהל אימות Wi-Fi מסוג 802.1X, לחתום על קוד או להנפיק תעודות לשירותים פנימיים. בארגון בעל גבולות רשת ברורים, זו תשתית מוכרת לצוות ה-IT ולעיתים גם כזו שכבר קיימת ללא רכישת מוצר נוסף.

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

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

למה ארגונים נוטשים את Microsoft CA ועוברים ל-Cloud PKI

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

תעודות כבר אינן מיועדות רק לשרתים פנימיים

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

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

אוטומציה במקום מעקב ידני אחרי תאריכי תפוגה

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

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

אבטחת מפתחות ובקרת הרשאות מדויקת יותר

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

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

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

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

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

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

מתי לא כדאי למהר לעבור

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

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

איך בוחנים מעבר בלי לסכן את סביבת הייצור

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

אחריו כדאי להגדיר מקרי שימוש לפי עדיפות: תחנות קצה מרוחקות, EAP-TLS לרשת אלחוטית, VPN, חתימת קוד, machine identities או שירותים בענן. אין צורך לבצע migration גורף. פיילוט מוגבל עם קבוצת משתמשים או מערכת אחת מאפשר לבדוק enrollment, חידוש, ביטול תעודות, ביצועים ואיסוף לוגים ל-SIEM.

בבחירת פלטפורמה, אין להסתפק במילה Cloud. צריך לבדוק תמיכה בפרוטוקולי הנפקה רלוונטיים, אינטגרציה עם Active Directory ופתרונות MDM, אפשרויות API, ניהול מחזור חיי מפתחות, MFA למנהלים, Audit Logs, יכולות התאוששות ומודל רישוי ברור. חשוב גם לברר מי מספק תמיכה כאשר חידוש תעודה נכשל ומי אחראי על גבולות האחריות בין ספק הענן, צוות ה-IT והאינטגרטור.

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

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