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

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

למה חריגות בגישה לקבצים קשות לאיתור

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

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

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

הגדירו קודם מהו קובץ רגיש

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

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

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

אילו דפוסים צריכים להדליק נורה אדומה

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

הדפוסים הבאים מצדיקים תיעדוף בבדיקות:

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

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

איך לבנות יכולת איתור בלי להציף את הצוות

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

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

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

עצירה נכונה: להכיל את האירוע לפני שמרחיבים אותו

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

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

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

הרשאות הן שכבת המניעה המשתלמת ביותר

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

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

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

אל תשכחו את עמדות הקצה ואת הגישה מרחוק

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

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

מדדו אם התהליך באמת עובד

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

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

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