SSH CA: ניהול גישה מרוכז

SSH CA: מה מסוכן במפתחות סטטיים שהתרבו

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

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

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

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

מה נותנת הנפקה אחודה של תעודות גישה

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

הנפקה אחודה של גישות מעבירה את ההחלטה למרכז אישורים אחד. המהנדס מאמת זהות (גורם שני, כניסה ארגונית), מקבל תעודת גישה קצרת-מועד ופועל לפיה; המארח בודק את חתימת המרכז ואת ה-principal וההרשאות המצוינים בתעודה, ולא את תוכן קובץ המפתח. התאימות עם OpenSSH נשמרת — מקור האמון משתנה, לא הלקוח.

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

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

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

פורמטי גישה: SSH CA מול מפתחות סטטיים

לפני בחירת פורמט כדאי לקבוע מה בדיוק המארח בודק בכניסה: מחזיק המפתח הפרטי או תעודה חתומה בידי רשות אישורים עם פרמטרים. מפתחות סטטיים ב-authorized_keys — אפשרות ללא תשתית: בכמה מארחים עם הרכב צוות קבוע היא פשוטה ובעלת פחות תקורה מכל הטמעה.

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

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

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

הטמעה שלב אחר שלב: מביקורת מפתחות ועד מסירה

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

1. מלאי מפתחות. איסוף וניתוח של מפתחות מורשים, איתור כפילויות ומפתחות ללא תוקף, תיעוד נקודות הכניסה הנוכחיות וחשבונות שירות.
2. תכנון סכמת אמון. מגדירים היכן חי המפתח הפרטי של מרכז האישורים, מי מנהל אותו, אילו תפקידים נכנסים לתעודה, לכמה זמן היא מונפקת וכיצד היא מתחדשת.
3. פריסת סביבת בדיקה. מקימים מרכז אישורים במתחם מבודד, מגדירים בדיקת תעודות בשרתים ואת סדר השלילה, כדי שגישה שאבדה תתבטל מיד ולא לאחר עריכה ידנית של כל המכונות.
4. בדיקה בסביבת בדיקה. מריצים תרחישים: הנפקה וחידוש, סירוב לאחר שלילה, כניסת תורן כאשר מרכז האישורים אינו זמין. בנפרד — גישת חירום שאינה תלויה בסכמה הראשית.
5. הגירה. מעבירים שרתים בקבוצות, מהפריפריה אל הקריטיים; מפתחות ישנים נשארים כדרך גיבוי עד שהסכמה החדשה תשלים מחזור מלא של הנפקה ושלילה.
6. נהלים ומסירה. מוסרים תיעוד, כללי הנפקה ושלילה, סדר פעולות באובדן מפתח והדרכת צוות תורנות — מכאן והלאה התמיכה עובדת בלעדינו.

תוצרים: קונפיגורציות, סכמות ונהלים

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

• קונפיגורציות אמון בצמתים: עריכות ב-sshd_config עם ציון מרכז החתימה, מדיניות principals וקובץ נפרד של המפתחות הציבוריים של המרכז.
• תפקידים ותרחישי פריסה: פריסה אידמפוטנטית של קונפיגורציות על כל צי המכונות, כולל צמתים חדשים ומחודשים.
• אוטומציה להנפקת תעודות: תוקפים, מערך הרשאות לפי תפקידים, הנפקה עבור אנשים וחשבונות שירות ללא פעולות ידניות.
• סכמת אמון: מפה «מרכז חתימה — צמתים — משתמשים», נקודות כשל, גבולות מקטעים וסדר רוטציה של מפתחות המרכז.
• נוהל גישה: מי ועל בסיס מה מקבל אותה, כיצד מוסדרת גישה זמנית, מי מאשר וכיצד זה מתועד.
• סדר שלילה: רשימות תעודות שנשללו, זמן אספקתן לצמתים ופעולות התורן בעת חשיפת מפתח.
• ביקורת ויומנים: היכן לבדוק, מי ומתי נכנס, כיצד אירועים עוברים למערכת איסוף הלוגים שלכם וכמה זמן נשמרים.
• תיעוד ומסירה: הוראות לתורנים, נוהל שחזור המרכז, יומן שינויים ותחקיר עם הצוות.

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

מקרה בוחן: שלילת גישה בדקות במקום כמה ימים

בפרויקט אחד גישה ל-40+ שרתים ניתנה על ידי העתקת מפתחות ציבוריים לפי מלאי. פיטורי מהנדס הפכו למעבר על כל המארחים וניקוי authorized_keys: שלילה מלאה ארכה 2–4 ימים, וכל אותו זמן הגישה נשארה פעילה. מפתח משותף לצוות השלים את התמונה — לפי הלוגים אי אפשר היה להבין מי בדיוק התחבר.

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

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

מה לעשות אם הצי כבר פועל על מפתחות סטטיים?

המעבר להנפקה מרכזית אינו דורש «יום X» שבו כולם בבת אחת מנוטרלים ממפתחות סטטיים. דמון SSH קורא את שני מקורות האמון בבת אחת: קובץ עם המפתח הציבורי של המרכז והרשימה הרגילה של מפתחות מורשים פועלים במקביל.

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

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

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

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

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

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

התנגדויות טכניות נפוצות ותשובות המהנדסים

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

מה יקרה אם צומת ההנפקה אינו זמין?

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

כיצד לשלול גישה אם התעודה שהונפקה עדיין תקפה?

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

נדון בסכמת הגישה שלכם ונחזור עם תוכנית

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

בדיון ננתח:

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

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