מדוע דרוש SSH Certificate Authority במקום מפתחות סטטיים
מפתח פרטי שהועתק לגיבוי, למחשב נייד שני או לקונפיגורציית build, מפסיק להיות סוד — אך ממשיך לעבוד. מפתחות SSH ארוכי-חיים חיים שנים: הם ניתנים לקבלן לתקופת הפרויקט, ונסגרים במעבר ידני על כל הצי. עד הרגע שבו צריך להוכיח למי יש גישה, אין רשימה מעודכנת לא בתפעול ולא באבטחה.
SSH Certificate Authority מסיר את סיבת הבעיה עצמה: במקום מפתח ארוך-חיים, מהנדס מקבל certificate קצר-חיים, חתום על ידי המרכז עבור תפקיד מסוים. בשרתים נשאר רק המפתח הציבורי של המרכז, הפרטי לא יוצא מהמאגר, ותוקף וקבוצת ההרשאות מוגדרים ב-certificate, ולא במארח.
ניהול גישת SSH עובר לנקודה אחת: הנפקה, תוקף, שלילה. מלאי מפתחות הופך לרשימת certificates שהונפקו עם בעלים וזמן, ולא למפקד קבצים בכל הצי. ביקורת גישות נשענת על יומן אחד: מי, מתי ובאיזה תפקיד קיבל כניסה.
שלילה מפסיקה להיות פעולה ידנית. ההנפקה נפסקת, ו-certificate שכבר הונפק פג מעצמו לאחר תקופה מוגדרת — מדקות ועד משמרת. עותק שנשאר במכונה זרה חסר תועלת עד אז: יש לו חתימת המרכז, אבל אין לו תוקף.
להלן נפרט כיצד להקים זאת: היכן למקם את המרכז, כיצד לקשור אותו לאימות הקיים ומה לעשות עם מפתחות שכבר התפזרו.
מה מעניקה הנפקה מרכזית של certificates גישה
הנפקה מרכזית נשענת על מפתח מהימן אחד של רשות אישורים: sshd בכל מארח קורא אותו מ-TrustedUserCAKeys, והכניסה מאושרת באמצעות certificate חתום על ידי המרכז.
מפתחות ציבוריים אישיים ב-authorized_keys מפסיקים להיות נקודת ניהול — בשרתים הם פשוט לא נשארים, ותפקיד המשתמש מוגדר בשדה principals ב-certificate. המהנדס מקבל גישה באותה פקודה רגילה; רק מקור האמון משתנה.
תוקף ה-certificate הופך לפרמטר גישה. עבור אוטומציה ומשימות שירות אנו מנפיקים אותו לדקות, עבור תורנות ידנית — למשמרת עבודה, ובסוף החלון הגישה נסגרת מעצמה, בלי מעורבות איש.
החלון מצטמצם מ"עד שיזכרו" לפרק זמן מדיד, ופרק זמן זה זהה לכל המארחים, כי הוא מוגדר במקום אחד, ולא בקונפיגורציה של כל מכונה.
שלילת גישה מפסיקה להיות פרויקט. מספיק להפסיק הנפקת certificates חדשים עבור תפקיד או אדם, ולבטל את הפעילים דרך רשימת שלילה — זה עניין של דקות, ולא מעבר על צי מארחים ותיקון מפתחות. בעת פיטורים או החלפת תפקיד, חלון הגישה לא נמשך עד הביקורת הבאה של הגישות, אלא נסגר באותו יום.
כך נעלם סוג שלם של כשלים: "שכחו למחוק מפתח". אין מי שישכח — אין מה למחוק, כי אין מפתחות קבועים במארחים, וה-certificate שהונפק פג לפי לוח זמנים. בנפרד נפתרת גם המורשת, כאשר אותו מפתח יושב בתיקייה משותפת ועובר בין קבלנים וצוותים במשך שנים: מפתח כזה פשוט לא עובר בדיקה.
יומן החיבורים הופך למלא וחד-משמעי. בלוגים של המארח רואים את המספר הסידורי של ה-certificate, קבוצת ה-principals וטביעת האצבע של רשות האישורים, וביומן ההנפקה — למי, לאיזה תפקיד ולאיזו תקופה הוא הונפק.
שתי הרשומות מקושרות לפי המספר, ולכן לשאלה "מי ומתי נכנס למארח הזה" יש תשובה בלי השוואה ידנית של טבלאות גישה.
דרכים להנפקת גישת SSH: השוואת אפשרויות
יש שלוש אפשרויות, והן נבדלות לא בכלי, אלא בנקודה שבה מתקבלת ההחלטה על הגישה: במארח עצמו, במרכז האישורים או בשניהם גם יחד. הקריטריון המעשי אחד — כמה מהר נסגרת הגישה למהנדס שעזב או איבד מחשב נייד.
כל השאר — נוחות ההנפקה, תוקף הגישה, שלמות הביקורת — הוא תוצאה של הנקודה הנבחרת. להלן השוואה לפי שני צירים: מתי האפשרות מתאימה ומה הצוות משלם עבורה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
מפתחות סטטיים ב-authorized_keys |
צי מארחים קטן, מנהל אחד או שניים, הרכב הגישה משתנה לעיתים רחוקות | שלילה — תיקון ידני בכל מארח; למפתח אין תוקף; עותק של הקובץ עוקף בקרה; ביקורת רק לפי יומני כניסה |
| Certificates עם הנפקה מרכזית | הצי גדל, נדרשים תוקף גישה קצר ומדיניות גישה אחידה לכל המארחים | נדרש מרכז אישורים משלו והתחזקותו; המארחים צריכים לתת בו אמון; נדרשים נהלי הנפקה ורוטציה |
| מצב גישה היברידי | תקופת מעבר: מארחים חדשים כבר על certificates, ישנים עדיין על מפתחות | שני קווי אמון בו-זמנית; צריך לדעת במדויק מי ואיפה עובר בסטטי; יש להגביל את חלון המעבר בתאריך |
סכמה נקייה כמעט לא קיימת בפועל: צי המארחים מתעדכן בצורה לא אחידה, וחלק מהמכונות עדיין חיות עם סטטי. לכן המעבר מעצב כשלב נפרד עם תאריך סגירה — אחרת תקופת ההיבריד הופכת למצב קבוע עם כפילות חשבונאות גישה ונקודות כשל מיותרות.
סדר היישום: מביקורת מפתחות ועד מסירת נהלים
סדר יישום ה-certificates נבנה כך שהגישה לשרתים לא תיפסק באף מחזור תורנות. תחילה מתעדים את המצב הקיים, אחר כך מתכננים את סכמת האמון, ורק לאחר מכן מנפיקים certificates באמת — תחילה לקבוצת פיילוט, ואז לכל הצי.
- מלאי הצי. אוספים רשימת מארחים, חשבונות שירות ואנשים שנכנסים ב-SSH, מסמנים היכן נשארו מפתחות סטטיים ואילו מהם לא היו בשימוש זמן רב. בלי המפה הזאת אי אפשר להבין אילו תפקידים ו-principals נדרשים.
- תכנון סכמת האמון. מגדירים תפקידי הנפקה, קבוצת principals, תוקף certificates ותבניות חתימה; מחליטים מה לעשות עם מפתחות ארוכי-חיים וכיצד לארגן גישת חירום.
- הגדרת ההנפקה. פורסים את Vault כרשות אישורים, מקשרים אותו לספריית המשתמשים, מפעילים יומן הנפקה ובדיקת חתימה בצד המארחים.
- קבוצת פיילוט. מעבירים 5–10 מהנדסים ומשמרת תורנות, בודקים כניסה רגילה, פקיעת certificate ושלילת גישה. אם התורן לא יכול להיכנס באירוע תקלה, הסכמה לא מוכנה.
- העברה מדורגת של הצי. מתקדמים לפי מקטעים: תחילה מארחי בדיקות ופנים, אחר כך שירותי עבודה, ולבסוף צמתים קריטיים. בכל שלב רואים את שיעור הכניסות המוצלחות ואת סיבות הסירוב.
- מסירת נהלים. מוסרים תיעוד: כיצד להנפיק ולשלול certificate, מה לעשות בעת חשיפה, סדר תורנות וחיבור עובדים חדשים.
מדיניות גישה, תפקידים ותיעוד לאחר היישום
לאחר היישום נשאר אצל הלקוח לא רק גישה עובדת באמצעות certificates, אלא גם סט מלא של ארטיפקטים במאגר שלו עצמו. בלעדיו הפתרון הופך לקופסה שחורה שרק מחבר ההגדרה יכול לתחזק. להלן מה בדיוק מוסרים ולפי אילו סימנים בודקים שאפשר להשתמש בזה באופן עצמאי.
- סכמת האמון. היכן נמצא המפתח הפרטי של רשות האישורים, כיצד המארחים מקבלים אמון בו בהגדרת sshd, אילו קווי מתחלקים ברשויות נפרדות ולא ברשות משותפת אחת.
- תפקידי חתימה. קובצי תפקידים לכל קבוצה: תוקף certificate, principals מותרים, סט הרחבות, איסור העברת agent ופקודות שרירותיות.
- מדיניות גישה. התאמה בין תפקידים וקבוצות מהספרייה, כללים נפרדים לחשבונות שירות ולתורנים, סדר הנפקת גישה מחוץ לתוכנית עם ציון המאשר.
- נוהל שלילה. כיצד נשלל מפתח אחד וכיצד נשללת גישה לכל הקבוצה, לאן מגיעה רשימת השלילה, תוך כמה זמן היא מתפשטת למארחים וכיצד מאמתים את עצם השלילה.
- הוראות לתורנים. מה לעשות בעת אובדן מפתח, למי להסלים, כיצד להנפיק גישה זמנית והיכן לראות יומן חתימה עבור עובד מסוים.
- ביקורת ותפוקות. תיעוד כל הנפקה: מי, מתי, לפי איזה תפקיד ועם איזה principal; ייצוא לאיסוף לוגים כללי ותקופת שמירה.
- תיעוד תפעולי. תרשימי סביבות, רוטציה של מפתח המרכז, הוספת מארחים חדשים ושחזור המרכז מגיבוי עם בדיקת אמון במארחים.
מקרה בוחן: מעבר ממפתחות ארוכי-חיים ל-certificates
הלקוח — צי מבוזר של כמה מאות שרתים בשלושה קווי מתח. הגישה ניתנה באמצעות מפתחות SSH שחיו שנים: מפתח של עובד נשאר פעיל גם אחרי פיטוריו, ומלאי של "מי הולך לאן" לא היה. שלילה הפכה למשימה נפרדת — אישור, תפוצה לצוותים ותיקון ידני של רשימות מפתחות מהימנים בכל צומת.
איך זה היה
ביקורת חשפה כ-600 מפתחות ארוכי-חיים; חלק לא היה בשימוש יותר משנה, אך נשאר ברשימות מהימנות. זמן השלילה הממוצע לאחר פיטורים — כמה ימים, וכל אותו זמן תעודת הכניסה נשארה בתוקף. הכניסה בוצעה במפתח משותף לתפקיד, ולכן לפי היומנים אי אפשר היה להבחין מי בדיוק נכנס לצומת.
מה שינו ומה נהיה
פרסו את Vault בתפקיד SSH Certificate Authority: רשויות מהימנות נרשמו בקונפיגורציית הצמתים, והמפתחות החלו להיחתם לתקופה קצרה — משמרת עבודה במקום גישה ללא הגבלת זמן. ההרשאות פוזרו לפי תפקידים דרך principals ומדיניות: מנהל בסיס נתונים ומהנדס תורן מקבלים סטים שונים של מארחים.
תוקף ה-certificate — 8 שעות, חידוש אוטומטי כל עוד הסשן פעיל. שלילה אורכת דקות: ה-certificate נכנס לרשימת שלילה, והצמתים מפסיקים להכניס את הבעלים בלי מעבר ידני על הצי.
שיעור המפתחות ארוכי-החיים הצטמצם לאחוזים בודדים — נשארו חשבונות שירות עם הרשאות מוגבלות, והתקריות עם גישה פעילה של מפוטרים פסקו.
מה לעשות אם מפתחות סטטיים כבר פרוסים בצי השרתים?
המיגרציה לא מחייבת לעצור גישה: בכל צומת מוסיפים ל-authorized_keys את ההנחיה TrustedUserCAKeys עם המפתח הציבורי של רשות האישורים, והשרת מתחיל לקבל שני אופני אימות בו-זמנית. המפתחות הסטטיים נשארים פעילים, ולכן חזרה לאחור בכל שלב עולה שורה אחת ב-sshd_config.
בדיוק זה הופך את המעבר לניהולי: קו המתח הישן חי בדיוק כמה שצריך, ומכבים אותו במודע, ולא ברגע של תקלה.
סדר השלבים כפוף לכלל "תחילה מרחיבים אמון, אחר כך מצמצמים הרשאות". קודם כול מלאי: מי מתחבר, לאילו צמתים, מאילו כתובות ובאיזה שם — לפי סטטי זה נראה רק בעקיפין, ולכן המרשם נאסף מיומנים וקונפיגורציות.
לאחר מכן מפיצים אמון במרכז בכל הצי, אחר כך מנפיקים את ה-certificates עצמם, ורק לאחר שכל התעבורה עברה דרכם, מוחקים את הסטטי מ-authorized_keys.
תאימות לשרתים ישנים נפתרת לא ב"לעדכן הכול", אלא בחלוקה לקווי מתח. במקום שיש ענף OpenSSH עדכני או הפצה מתעדכנת, ה-certificates מופעלים כסדרם.
צמתים שאי אפשר לעדכן — builds ישנים, מערכות משובצות, חומרה עם קושחה סגורה — נשארים על מפתחות מקומיים בקו מתח נפרד עם הגבלה קפדנית לפי כתובות מקור ותוקף. זה לא פשרה, אלא גבול מפורש: הוא מתועד ומצטמצם בהדרגה.
עבודה נפרדת — קבלנים. certificate מונפק לא לאדם בכלל, אלא לתפקיד עם קבוצת principals ותוקף קצר, ולכן הגישה מפסיקה להיות ללא הגבלת זמן. ביומנים מופיע שם קונקרטי ומספר סידורי במקום השורה "מפתח משותף התחבר" — בחקירת תקלה זה ההבדל בין חקירה לבין ניחושים.
המעבר מסתיים במחיקת מפתחות סטטיים ובהעברת גישה רק דרך certificates, ובמקביל בכל קו מתח נשארת דרך מתועדת לחזרה לאחור. נפרט כיצד לפרוס מעבר כזה לפי שלבים עבור הצי שלכם.
ספקות טכניים: תוקפים, שלילה ותאימות
שאלות בתחילת היישום כמעט תמיד אותן שאלות: כמה חי ה-certificate, מה לעשות בעת פיטורים, האם יהיה צורך לעבור ידנית על מאות מארחים ומה יישאר ביומנים. להלן תשובות ענייניות: עם פרמטרים שאנו מתעדים בקונפיגורציה, ותיאור כיצד זה מתנהג בתפעול אמיתי.
עד כמה צריך להיות קצר תוקף ה-certificate?
הטווח המעשי — מכמה שעות ועד יממה אחת עבור אנשים ודקות עבור משימות שירות. ההנפקה מתרחשת ברגע ההתחברות, המפתח הפרטי לא יוצא מתחנת העבודה של המהנדס, ולכן תוקף ארוך לא נותן שום נוחות, רק סיכון.
תוקף קצר פועל כתחליף לשלילה: עד הרגע שצריך לקחת את הגישה, ה-certificate לרוב כבר פג, והחידוש קורה בלי שהאדם מבחין.
כיצד לשלול גישה אם העובד עזב וה-certificate עדיין בתוקף?
שתי רמות בלתי תלויות. הראשונה — רשימת certificates שלולים, שמופצת למארחים ונלקחת על ידי שירות הגישה בלי הפעלה מחדש ובלי לקטוע סשנים פעילים. השנייה — חסימת חשבון בספרייה: במקרה זה החידוש פשוט לא מונפק. החלון שבו certificate ישן עדיין מתקבל מוגבל לדקות, ולא לימים.
כיצד המארח משתכנע שה-certificate שהוצג אמיתי?
המארח נותן אמון רק במפתח הציבורי של מרכז החתימה — הוא נרשם פעם אחת בהגדרות שלו. החתימה נבדקת מקומית, אין פנייה למרכז ברגע הכניסה, ולכן אי-זמינות המרכז לא חוסמת עבודה.
ה-principals והמגבלות הנוספות בתוך ה-certificate קובעים לאילו חשבונות ומארחים הוא חל — אותו מפתח לא פותח הכול בבת אחת.
מה ייכנס לתיעוד יומני הגישה?
ביומנים נשארים טביעת אצבע ומספר סידורי של ה-certificate, ולא רק שם משתמש: אפשר לקשר את הסשן להנפקה מסוימת ולהבין באיזה מפתח השתמשו. הרשומות נאספות לזרם כללי עם מזהה בקשה, ולכן חקירת תקלה לא הופכת להשוואת לוגים בכל מארח.
אפשר ליישם בשלבים בלי לעצור עבודה?
כן. תחילה מרימים את מרכז החתימה ומעבירים קו מתח אחד, ומפתחות רגילים ממשיכים לפעול במקביל. לאחר מכן מעבירים קבוצות מארחים בתורן; בכל שלב החזרה לאחור — החזרת האמון למפתחות הקודמים — היא הפיכה ולא דורשת בנייה מחדש של התשתית.
נדון במשימה: נתאים סכמת גישה לקו המתח שלכם
כדי שההערכה תהיה מדויקת ולא "לפי תחושות", אנחנו צריכים לראות את נוף הגישה הנוכחי: כמה מכונות בקו המתח, כיצד מפתחות מונפקים היום ומה צריך להיכנס ליומן. להלן מה שכדאי להכין לשיחה. נאסוף זאת בפגישה אחת ונחזור עם הערכה ותוכנית יישום.
- מפת הצי: רשימת שרתים וסביבות, מקובצת לפי סביבות ורמות קריטיות.
- תפקידים ו-principals: מי שייך לאילו קבוצות, אילו הרשאות נדרשות, למי הגישה ניתנת זמנית.
- הנפקה נוכחית: כיצד מפתחות נוצרים כיום — ידנית, בסקריפט, דרך פאנל או חשבון דומיין.
- נקודות כניסה: bastion, מארחי ביניים, runners של build, תת-רשתות ניהול.
- תוקף ושלילה: זמן הפעולה המקסימלי של certificate ונוהל שלילה מיידית בעת פיטורים או תקלה.
- מקור נתוני החשבון: ספריית משתמשים, שירות כניסה אחודה או מלאי — כדי לקשור את ההנפקה לתקן כוח האדם.
- מגבלות קו המתח: רשתות מבודדות, היעדר גישה יוצאת, דרישות ביקורת ונהלים פנימיים.
- מדדי יעד: זמן הנפקת גישה, שיעור השרתים תחת certificates, היקף פעולות ידניות.
לפי הסט הזה נציע סכמת גישה לקו המתח שלכם: היכן ממוקם המרכז המהימן, כיצד בנויים תפקידים, תוקפים ושלילה, מה נכנס ליומן וכיצד זה מאומת בבדיקה. תארו את המשימה — נחזור עם הערכה, תוכנית לפי שלבים, תחומי אחריות ונקודות חזרה לאחור בכל שלב.