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

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

מה באמת נחשב לגישה פריבילגית?

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

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

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

הגדרת גישה פריבילגית מתחילה במיפוי, לא במוצר

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

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

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

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

עקרון ההרשאה המזערית - עם הקשר תפעולי

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

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

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

כך בונים תהליך שאנשים באמת משתמשים בו

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

1. הגדירו בעלים לכל מערכת קריטית. בעל המערכת מאשר מי זכאי לגישה ומהו טווח ההרשאות, בעוד צוות ה-IT מיישם את המדיניות ושומר על הבקרה הטכנית.

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

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

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

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

ניהול סיסמאות אינו תחליף לניהול גישה

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

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

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

איפה ארגונים נכשלים בביקורת הרשאות?

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

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

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

המדדים שיגידו אם המדיניות עובדת

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

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

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

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