הגדרת ביקורת הפעלות מיוחסות (הקלטת הפעלות)

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

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

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

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

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

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

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

מה משתנה לאחר הטמעת הקלטת סשנים

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

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

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

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

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

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

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

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

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

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

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

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

איך אנחנו מיישמים: ממלאי מלאי ועד מסירה

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

מלאי ותרשים חיבור

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

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

הגדרה ובדיקה

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

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

מסירה לתפעול

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

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

מדיניות גישה והפרדת תפקידי מנהלים

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

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

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

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

מה מגדירים בהרשאות:

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

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

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

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

מה היה לפני

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

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

מה שינו

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

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

במקביל הקמנו מרשם בעלים: לכל רשומה נוסף אחראי ותאריך סקירה, ורשומות לא פעילות נחסמות אוטומטית לפי כלל lifecycle.

מה נהיה

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

במה שונה הקלטת סשנים מתיעוד פקודות

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

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

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

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

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

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

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

מה הלקוח מקבל לידיו לאחר ההטמעה

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

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

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

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

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

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

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

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

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

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

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

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