הגדרת SSM לניהול מאובטח של שרתים ללא SSH

ניהול מאובטח של שרתים דרך AWS Systems Manager

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

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

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

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

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

מה משתנה לאחר ויתור על חיבורי SSH ישירים

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

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

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

אפשרויות גישה לשרתים: השוואת מצבים

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

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

הטמעת Systems Manager: מביקורת ועד מסירה

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

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

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

סט מסמכים והגדרות שאתם מקבלים

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

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

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

מקרה בוחן: ויתור על חיבורים ישירים בצי שרתים

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

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

מדדים לפני ואחרי

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

מה לעשות אם מפתחות SSH כבר התפזרו בצוות

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

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

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

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

ספקות טכניים לפני ויתור על גישה ישירה

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

כיצד מתעדכן רכיב השירות בצי מכונות?

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

כיצד להפריד בין צוותים לקבלנים?

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

האם נותרת גישת חירום?

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

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

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

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

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