הגדרת הרשאות גישה לקבצים ב-Bitrix24: מדריך מלא

למה הגדרת הרשאות הגישה ב-Bitrix24 נשברת כשהצוות גדל

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

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

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

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

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

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

אפקט מדיד: מהירות, יציבות, פחות סירובים

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

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

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

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

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

השוואת סכימות הפרדה: קבוצות, תפקידים, הורשה

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

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

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

סדר העבודות: מביקורת ועד מסירת נהלים

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

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

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

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

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

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

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

מטריצת תפקידים, תרשים תיקיות ונהלי עבודה

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

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

מקרה בוחן: סדר בתיקיות הפורטל לאחר מיזוג מחלקות

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

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

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

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

במה שונה איסור ברמת תיקייה מאיסור על קובץ?

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

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

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

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

ספקות טכניים נפוצים וניתוח מצבים שנויים במחלוקת

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

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

מה עושים אם הקבצים נמצאים באחסון חיצוני?

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

כיצד הפרויקט נמסר ללקוח?

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

כבר הענקנו הרשאות מיותרות — האם זה קריטי?

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

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

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

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

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

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

תארו את המשימה בצורה חופשית — נחזור עם הערכה ותוכנית עבודה.