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

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

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

מתי PKI מקומי הופך לצוואר בקבוק

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

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

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

מה Cloud PKI באמת משנה

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

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

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

הענן לא פותר בעיית מדיניות

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

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

אבטחה, ריבונות נתונים ומפתחות פרטיים

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

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

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

ההיבט שפחות מדברים עליו: FinOps של תעודות

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

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

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

האם הגיע הזמן לעבור מ-PKI מקומי ל-Cloud PKI? כך בודקים

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

1. ממפים את המצב הקיים. אספו את כל רשויות ההנפקה, התעודות הפעילות, בעלי השירותים, נקודות ההפצה, התלות ב-Active Directory והאינטגרציות עם VPN, Wi-Fi, MDM ויישומים.
2. מדרגים את התעודות לפי קריטיות. התחילו במקרי שימוש שקל לבודד ושיש בהם ערך מיידי, ולא ברשות השורש או במערכת הייצור הרגישה ביותר.
3. מגדירים מדיניות לפני הגירה. קבעו תפקידי ניהול, MFA, זמני תוקף, כללי חידוש, טיפול בעזיבת עובד ונוהל ביטול תעודה במקרה של חשד לפגיעה.
4. מבצעים פיילוט מדיד. בחרו קבוצת משתמשים או שירות מוגדר, בדקו הנפקה וחידוש אוטומטיים, מדדו חריגות ובחנו את הלוגים ואת תהליך התמיכה בפועל.
5. מתכננים מצב היברידי כשצריך. אין חובה להעביר הכול ביום אחד. לעיתים נכון להשאיר רכיבים פנימיים או רשות שורש בסביבה מקומית, ולהעביר לענן את ההנפקה והניהול של תעודות יומיומיות.

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

מתי נכון להישאר מקומיים

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

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

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