PKI בתשתית שלכם: תעודה שפג תוקפה מפילה שירות
PKI בתוך הארגון כמעט תמיד גדל באופן ספונטני: קודם תעודה אחת לסביבת בדיקות, אחר כך עשרות — למאזני עומסים, brokers של הודעות, API-ים פנימיים ואינטגרציות עם שותפים.
מנפיקים אותן ידנית: מהנדס נכנס לרשות האישור, מייצר מפתח, מעתיק את הקובץ לשרת ורושם את תוקף התעודה בטבלה שאף אחד לא פותח אחר כך.
כל עוד יש חמש תעודות, הסכימה עובדת. כשהן מאות ומפוזרות בין סביבות, פקיעה מתוכננת הופכת לתקלה: תעודה שפג תוקפה מפילה שירות בלילה או בשיא העומס, הסימפטום נראה כשגיאת חיבור, ואיתור הסיבה אורך שעות.
השבתה של השירות עולה יותר מההחלפה עצמה — אינטגרציות עם שותפים נופלות, התור צובר משימות שלא טופלו, והתורן מחדש ידנית דברים שאיש לא זכר.
הנפקה ידנית של תעודות אינה ניתנת להרחבה גם מהסיבות ההנדסיות: אין מלאי שמראה איזה מפתח שייך לאיזה שירות, אין מדיניות אחידה לאלגוריתמים ולתקופות תוקף, וביטול של מפתח שנחשף נמשך ימים. כל החלפה היא פעולה נפרדת עם סיכון לפגוע בשירות הסמוך.
בהמשך נפרט כיצד זה נסגר: הנפקה ורוטציה מרוכזות דרך Vault, תקופות תוקף קצרות לתעודות, הנפקה מחדש אוטומטית לפי לוח זמנים ומעקב אחר מספר הימים שנותרו עד לפקיעה — כדי שתקלה בגלל תעודה תפסיק להיות אירוע שדורש אדם.
מה נותנת הנפקה מנוהלת ורוטציה של מפתחות
האפקט המדיד העיקרי של PKI הוא זמן הנפקת התעודה. במקום ימים של תיאומים וחתימה ידנית, השירות מקבל זוג «מפתח — תעודה» תוך דקות: המהנדס מציין את הייעוד ואת תקופת התוקף, והשאר נעשה על ידי רשות האישור. המפתח הפרטי במקרה זה אינו עוזב את המכונה ואינו נשלח בהתכתבות.
הנפקה אוטומטית של תעודות משתלבת בתהליך הפריסה: שרת חדש, כשמוכנס לעבודה, לוקח בעצמו תעודה לפי התפקיד שלו ואינו ממתין שמישהו ייזכר בבקשה. תקופת תוקף קצרה הופכת לנורמה, כי חידוש מפסיק להיות פעולה ידנית.
רוטציה של מפתחות מתבצעת לפי לוח זמנים: החתימה מוחלפת לפני פקיעת התוקף, מרכזים מתווכים מתעדכנים לאורך השרשרת, והחלון שבו מפתח שנחשף נשאר מסוכן מצטמצם לשעות. עבור שירותי legacy שאינם יודעים לחדש את עצמם, נשאר מצב מעבר מבוקר. (legacy — אנגליזם?
הרשימה האסורה: feature, deadline, workflow, meeting, stakeholder, roadmap, MVP, pipeline, kick-off, benchmark, edge case. legacy אינו ברשימה, אך מוטב להחליף: «עבור שירותים ישנים»)
ביטול הוא נקודה אחת. פיטורי עובד, דליפת מפתח או הוצאה משימוש של צומת נסגרים בפעולה אחת ברשות האישור: תעודה מבוטלת מפסיקה להתקבל בכל השירותים, ולא רק בזה שבו הספיקו לתקן את הקונפיגורציה.
יומן ביקורת הגישה מתעד מי ומתי קיבל תעודה, עם איזה תפקיד ולכמה זמן — לפיו מנתחים תקרית בלי לשחזר את הכרונולוגיה מהתכתבות. יחד זה מסיר סוג שלם של תקלות מסוג «שכחו לחדש»: תעודה שפג תוקפה אינה מפילה יותר את תשתית העבודה בסופי שבוע.
ארכיטקטורות PKI: מרכז אחד או היררכיה עם מתווכים
האמון ב-PKI נשען על מי שחותם על התעודות ועל היכן נמצא המפתח שיצר את האמון הזה. רשות אישור אחת היא הסכימה המינימלית: הטמעה מהירה, תקנון פשוט, מינימום ישויות. הצד השני של המטבע הוא נקודת כשל יחידה: פגיעה במפתח מאפסת את כל השרשרת ומחייבת הנפקה מחדש של כל התעודות בבת אחת.
היררכיה מפרידה אזורי אחריות: רשות האישור השורשית יוצאת ל-offline ואינה משתתפת בהנפקה השוטפת, ואילו המתווכות עובדות — ניתן לבטל אותן בנפרד בלי לגעת בשורש. אחסון מפתחות השורש מתוכנן בנפרד: מודול חומרה או מדיה לא מקוונת, חלוקת גישה בין כמה מחזיקים, ותקנון להכנסה לעבודה ולשחזור.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מרכז שורשי אחד | תשתית פנימית, מספר קטן של שירותים ומחזור הנפקה קצר | נקודת כשל יחידה: פגיעה במפתח מאפסת את האמון ומחייבת הנפקה מחדש של כל התעודות |
| מרכז שורשי + מתווכים | כמה צוותים ותשתיות, שותפים חיצוניים, יש צורך להפריד הרשאות | יקר יותר בתפעול: תקנונים, תקופות תוקף, ביטול מתוכנן של מתווכים, בקרת שרשראות |
| רשות אישור ציבורית חיצונית | שירותים ודומיינים ציבוריים שדפדפן הלקוח פותח | תלות בכללי הנפקה ובמועדים של גורם חיצוני; המפתחות בצד הספק |
סכימה משולבת נפוצה יותר מהקצוות: שירותים פנימיים מטופלים על ידי שורש משלנו, ודומיינים ציבוריים — על ידי רשות אישור ציבורית חיצונית. ב-Vault זה מופרד בנקודות עיגון נפרדות לשורש, למתווכים ולתפקידי הנפקה — המדיניות ותקופות התוקף של התעודות אינן מצטלבות.
שלבי ההטמעה: מספירת מלאי ועד מסירה
הטמעת PKI אינה «לפרוס כספת סודות ולהתחיל להנפיק תעודות», אלא רצף שבו כל צעד נשען על הנתונים של קודמו. אם מדלגים על ספירת המלאי או לא מקבעים את סכימת האמון, ההנפקה תעבוד, אבל כבר ברוטציה הראשונה או בהחלפת הבעלים של השירות יצופו תיקונים ידניים שנשכחו.
להלן הסדר שבו אנו מובילים את העבודה, כדי שבסוף יתקבלו הנפקה וביטול מנוהלים, ולא אוסף של פעולות מפוזרות.
- ספירת מלאי של שירותים. אוספים מי הולך ולאן בערוצים מאובטחים: שירותים, מאזני עומסים, brokers של הודעות, API-ים פנימיים, אינטגרציות עם מערכות חיצוניות. בנפרד מתעדים כיצד התעודות מתחדשות היום — ידנית, בסקריפט לפי לוח זמנים או «כשזה נופל».
- סכימת אמון. קובעים את עומק השרשרת: שורש משלנו ומרכזים מתווכים, היכן נשמרים המפתחות שלהם, אילו תקופות הנפקה ומדיניות ביטול מיושמות לסוגי שירותים שונים.
- פריסה והגדרה של כספת הסודות. מרימים קונפיגורציה עמידה לתקלות, מפעילים את מודול PKI, פורקים את השורש ואת המרכז המתווך, ומפעילים תיעוד ביומן של כל פעולות ההנפקה והביטול.
- תפקידים והרשאות. מפרידים בין הזכויות: מי מנפיק, מי מבטל, מי קורא מפתחות פרטיים. האפליקציות מקבלות גישה תחת פרטי הזדהות משלהן, ולא תחת חשבון מנהל משותף.
- הגדרת ההנפקה. מחברים חידוש אוטומטי: סוכן על הצומת לוקח תעודה חדשה לפני פקיעת התוקף, והשירות קורא אותה מחדש בלי הפעלה מחדש ובלי השבתה.
- בדיקה בסביבת בדיקות. מריצים תרחישים של הנפקה, רוטציה, ביטול, כשל של צומת ואובדן קשר עם הכספת. מודדים את זמן השחזור ומוודאים שחזרה לתעודה הקודמת אפשרית.
- מסירה לתפעול. מוסרים קונפיגורציות, סכימות אמון, תקנון ביטול והוראות למשמרת התורנית, ועוברים עם צוות הלקוח על תקלות אופייניות — מכאן המערכת חיה בלי מעורבות שלנו.
תיעוד, תרשימים ותקנונים ל-PKI
העבודה אינה מסתיימת בהרצה, אלא ברגע שבו הצוות שלכם מנפיק תעודה בעצמו, מבטל תעודה שנחשפה וסוגר תקרית בלי טלפון לקבלן. לכן יחד עם התשתית העובדת אנו מוסרים חבילת מסמכים: היא מתארת לא «איך עשינו את זה», אלא כיצד לתחזק זאת בהמשך.
- סכימת אמון — עץ רשויות האישור, תקופות התוקף של תעודות השורש והמתווכות, מקומות האחסון של המפתחות הפרטיים ומעגל האנשים עם גישה אליהם.
- מדיניות גישה — תפקידים וזכויות להנפקה, חידוש וביטול, הפרדת סמכויות: מהנדס אחד אינו יכול גם להנפיק תעודה וגם לאשר את ביטולה.
- תקנון רוטציה וביטול — מועדי הנפקה מחדש לפי סוגי תעודות, מה נעשה אוטומטית ומה ידנית, חלון העבודה וסדר הפעולות בעת פגיעה במפתח.
- קונפיגורציות וקוד — הגדרות הכספת, תיאורי תפקידים ומדיניות, סקריפטים של הנפקה במערכת ניהול גרסאות: סביבת הבדיקות מוקמת מאפס בלי פעולות ידניות.
- מפת אינטגרציות — אילו שירותים תלויים ב-PKI וכיצד מתבצעת הנפקה מחדש שלהם בלי השבתה: בנפרד החלפה מתוכננת, בנפרד חירום.
- הוראות למשמרת התורנית — תרחישים לתקלות אופייניות: פג תוקף תעודה במאזן עומסים, הכספת אינה זמינה, חשד לדליפת מפתח — עם נקודות הסלמה.
- ניטור ובדיקות — התראות על התקרבות מועד הפקיעה, בדיקת שרשרת האמון וההרשאות, דוח על מצב ה-PKI עבור התורן.
המסירה נעשית בהדגמה בסביבת בדיקות: המהנדסים שלכם מנפיקים ומבטלים תעודות בעצמם תחת השגחתנו, ולא קוראים הוראות אחרי שהצוות עזב.
מקרה בוחן: הסרנו השבתות בגלל תעודות שפג תוקפן
לפני המעבר ל-PKI אוטומטי, כ-40 שירותים פנימיים קיבלו תעודות ידנית: בקשה בתור, מהנדס הנפיק קובץ ופיזר אותו בין הצמתים, והחידוש חי ביומן של אדם אחד.
ברבעון הצטברו 8–10 השבתות בגלל תעודות שפג תוקפן, והשחזור ארך מ-20 דקות ועד כמה שעות — קודם חיפשו את האשם, אחר כך הנפיקו מחדש והפעילו מחדש. תופעת לוואי: הפסיקו לבצע פריסות בסוף השבוע, כדי להספיק להגיב.
מה שינינו
פרסנו מרכז הסמכה פנימי על HashiCorp Vault: מפתח השורש מבודד, המתווכים מונפקים בתפקידים המיועדים לשירות מסוים, ותקופת התוקף — משעות ועד כמה ימים.
ההנפקה והחידוש עברו לאוטומציה: האפליקציה מבקשת תעודה בעצמה, העדכון נקלט בלי הפעלה מחדש, וביטול של תעודה שנחשפה — לפי רשימת הביטולים תוך דקה.
מה השתנה
- השבתות בגלל תעודות שפג תוקפן: 8–10 ברבעון → אף אחת בתקופה דומה;
- הנפקת תעודה: שעות המתנה → שניות, בלי בקשות ותיאומים;
- שחזור לאחר תקלה: שעות → דקות, עם חזרה לתעודה המתווכת הקודמת בלי לעצור שירותים;
- שיעור השירותים עם חידוש אוטומטי: 0 → 100%.
העמידות לתקלות הפסיקה להיות תלויה במהנדס אחד: הכספת פרוסה על פני אזורים, מפתחות השחזור מחולקים בין אחראים, וההנפקה מחדש מתבצעת לפי לוח זמנים — תקופת תוקף קצרה של תעודה אינה עוד סיכון, אלא נורמה.
במה שונה PKI פנימי מרשות אישור ציבורית
ההבדל אינו בקריפטוגרפיה — הפורמטים והאלגוריתמים של התעודות זהים. ההבדל הוא בכספת האמון של מי שכבר מונחת בה תעודת השורש של המרכז: רשות אישור ציבורית רשומה מראש בדפדפנים, במערכות הפעלה ובפלטפורמות מובייל, ולכן התעודה שלה מתקבלת בלי הגדרה.
השורש של PKI פנימי נעשה מהימן רק במקום שבו הצבנו אותו בעצמנו — בשרתים מנוהלים, בקלאסטרים, ובמחשבי העבודה של העובדים.
מכאן נגזר גבול היישום. רשות אישור ציבורית נדרשת בכל מקום שבו תעודה תיראה על ידי מכשיר זר: אתר ללקוחות, ממשק תוכנה פתוח, אפליקציה מחנות, שער סליקה, חילופי נתונים עם שותפים.
PKI פנימי מכסה שירותים שמשתמש חיצוני אינו מגיע אליהם: אימות הדדי בין שירותים, הצפנת תעבורה בין בסיסי נתונים ל-proxy, גישת מנהלים, ומנהרות לרשתות המשרד.
האמון בתעודה אינו תכונה בינארית, אלא שאלה של מי יכול להוסיף את השורש לכספת האמון. כל עוד מצאי המכונות מנוהל, הפצת השורש היא פעולה שגרתית. במכשיר של לקוח או שותף אין מנוף כזה, ושם מרכז פנימי חסר תועלת.
לכן הבחירה בסכימה היא לרוב היברידית: רשות ציבורית משרתת את התשתית החיצונית, ופנימית — את התפעולית. Vault בחיבור הזה לוקח על עצמו הנפקה ורוטציה של תעודות קצרות מועד לפי בקשת השירות: המרכז המתווך מוגדר פעם אחת, והחידוש מכאן ואילך מתבצע בלי בקשות ידניות. התשתית הפנימית מקבלת תעודה תוך שניות, והחיצונית נשארת תואמת לכל דפדפן.
ספקות טכניים: ביטול, רוטציה, עמידות לתקלות
חמש שאלות שעולות לרוב לפני ההתחלה: גורלן של תעודות שכבר הונפקו, פגיעה במפתח, הנפקה בלי בקשות ידניות, עמידות הכספת עצמה לתקלות, וגישה למפתחות השורש.
מה יקרה לתעודות שכבר הונפקו בעת ביטול?
התעודה לא נעלמת מיד: היא נכנסת לרשימת הביטולים המפורסמת, והשירותים שבודקים סטטוס מפסיקים לקבל אותה. תקופת תוקף קצרה מקטינה את החלון — תעודות שירות מונפקות לימים, לא לשנים.
המפתח נחשף — תוך כמה זמן תבטלו אותו?
המפתח הפרטי נוצר בתוך הכספת ולעולם אינו יוצא ממנה, ולכן אין דליפה של קובץ. במקרה של חשד אנו מבטלים אותו בתרחיש אוטומטי תוך דקות ומנפיקים מפתח חדש — אין צורך לעצור את השירות.
האם אפשר להנפיק תעודות בלי בקשות ידניות?
כן. השירות מבקש תעודה לפי התפקיד שלו עם הגבלה לדומיינים מסוימים, וההנפקה אורכת שניות. אישור ידני נשאר רק למפתחות השורש — שם מחיר הטעות גבוה יותר.
מה יקרה אם הכספת אינה זמינה?
תעודות שכבר הונפקו ממשיכות לעבוד — הן נבדקות בצד השירותים. הנפקת תעודות חדשות שורדת את התקלה: הצמתים מאוחדים לקלאסטר עם מעבר אוטומטי, והגיבוי מקבל את הבקשות.
מי מקבל גישה למפתחות השורש וכיצד נשמרים הגיבויים?
מפתח השורש מורכב לפי סכימת שיתוף סוד — נדרשים חלקים אצל כמה אחראים, ובשלמותו הוא אינו נמצא בשום מקום. הגיבויים מוצפנים ונשמרים מחוץ לכספת הראשית, ואת השחזור אנו בודקים בתרגילים.
נדון במשימה ונחזור עם תוכנית עבודה
כדי שההערכה תהיה עניינית ולא ממוצעת לשוק, נדרש הקשר פתיחה קצר: אילו שירותים מנפיקים ומקבלים תעודות, כמה יש וכמה часто הם מתחדשים, האם קיים מרכז הסמכה משלכם ומי אחראי על מפתחות השורש.
שעה של שיחה עם המהנדס שלכם ותרשים של התשתית מספיקות בדרך כלל כדי להבין אם אנו בונים PKI מאפס או יוצאים מהמצב הקיים.
ניתוח הקונפיגורציות והחזרה עם הערכה ותוכנית עבודה נעשים על ידי אותו מהנדס שאחר כך מגדיר את התשתית — לא על ידי מחלקת מכירות. בשלב זה מצטרפים המומחים שלנו לתשתיות ולקריפטוגרפיה.
- היקף העבודות — הנפקה וביטול של תעודות, תפקידים ומדיניות גישה, רוטציה אוטומטית, גיבוי מפתחות השורש, בקרה על מועדי התוקף.
- מה נדרש מכם — גישה לסגמנט בדיקות, רשימת השירותים הצרכנים, ואחראי שמקבל החלטות בנושאי מדיניות.
- סדר ההתחלה — תחילה גבולות התשתית וסכימת האמון, אחר כך הגדרה בסגמנט הבדיקות, ולבסוף מעבר לסביבת העבודה בלי לעצור שירותים.
- נקודות ביקורת — אחרי כל שלב אנו מציגים תוצאה: הנפקה עובדת, ביטול, בדיקת השרשרת.
- מסירת התשתית — תקנונים, הוראות שחזור, ומעבר על כך עם המהנדסים שלכם על תשתית חיה.
- גבולות העבודה — מקבעים לפני ההתחלה, כדי שלא יהיו אי-הבנות לגבי ההיקף והמועדים.
תארו את המשימה — ונחזור עם הערכה, תוכנית עבודה וסדר התחלה.