הרשאות מנהל קבועות הן פצצה מתקתקת

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

למה הרשאת מנהל קבועה מסוכנת כל כך

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

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

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

הבעיה האמיתית: לא מי אדמין, אלא מתי ולמה

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

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

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

התוקפים כבר לא צריכים הרבה רעש

דוח CrowdStrike Global Threat Report 2026 מצביע על שינוי מטריד: זמן התנועה הראשוני של תוקפים ירד ל 29 דקות בממוצע, והזמן המהיר ביותר שנצפה היה 27 שניות. עוד נתון חשוב הוא שרוב הזיהויים היו ללא נוזקה, כלומר התוקפים השתמשו בזהויות תקפות, זרימות גישה אמינות, אפליקציות SaaS ותשתיות ענן שנראו לגיטימיות.

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

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

הטעות שמנהלים עושים עם MFA

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

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

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

מה באמת צריך למדוד

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

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

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

הצ׳קליסט שלנו להרשאות מנהל שלא הופכות לאירוע

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

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

מה אומרים הסטנדרטים

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

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

דוגמה מהשטח

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

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

השורה התחתונה

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

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

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