מדיניות אבטחה של 1С-Битрикс: היכן ההגנה נשברת
לרוב מדיניות האבטחה של 1С-Битрикс נשברת לא בשלב ההגדרה, אלא בשלב התפעול: הרשאות גישה של מנהלים ניתנות "לצמיחה עתידית", לוח הניהול נגיש מהאינטרנט, ונהלי העבודה עם קבצים וטפסים נשענים על הזיכרון של המפתח.
כל אחד מהאזורים הללו בנפרד נראה בלתי מזיק, אך יחד הם יוצרים שלוש נקודות כשל יציבות שדרכן עוברות רוב התקריות האמיתיות.
הנקודה הראשונה — הרשאות יתר של מנהלים. כאשר לכל מפתח ומנהל תוכן יש גישה מלאה להגדרות מודולים, לניהול משתמשים ולעריכת קבצי מערכת, כל טעות או חשבון שנפרץ חושפים את כל האתר.
חלוקה לקבוצות עם ההרשאות המינימליות הנדרשות ותפקיד נפרד לעריכת קוד מסירים את הסיכון הזה בלי לפגוע במהירות העבודה.
הנקודה השנייה — הגנת לוח הניהול. כתובת כניסה פתוחה, היעדר הגבלה לפי כתובות וסיסמאות חלשות הופכים את ניסויי הסיסמה לשאלה של זמן. הגבלת גישה ללוח לפי IP, אימות דו-שלבי והחלפת נתיב הכניסה הסטנדרטי סוגרים את האזור הזה.
הנקודה השלישית — פגיעויות בטפסים ובהעלאת קבצים. מטפלים ללא ולידציה מקבלים נתונים שרירותיים, והעלאת קבצים ללא בדיקת סוג והרשאות מאפשרת להעלות קוד הרצה. ולידציה בצד השרת, רשימה לבנה של סיומות ואחסון ההעלאות מחוץ לשורש האתר — המינימום הבסיסי שלעיתים קרובות חסר.
בנפרד יש להזכיר את הנהלים: מי ומתי משנה הגדרות, כיצד מתועדים שינויים, ומה קורה כאשר עובד עם גישה מסיים את עבודתו. בלי זה, אפילו מדיניות אבטחה של 1С-Битрикс שהוגדרה כראוי מדרדרת תוך מספר חודשים. מפרטים כיצד לבנות הגנה כך שתוחזק ללא בקרה ידנית מתמדת.
מה נותנת הגנה בנויה לפלטפורמה
מדיניות אבטחה של 1С-Битрикс אינה רשימת בדיקה חד-פעמית, אלא מערכת כללים שהפלטפורמה מיישמת על כל בקשה: מה מותר למודול, אילו קבצים ניתן להריץ, כיצד נבדקות הרשאות המשתמש ומה קורה בעת דחייה.
כאשר הכללים בנויים, משטח התקיפה מצטמצם באופן צפוי: נסגרות נקודות הכניסה שדרכן מגיעים לרוב סורקים אוטומטיים וניסיונות ניצול חולשות ידועות.
האפקט מדיד בשלושה מישורים. הראשון — הפחתת אירועים: תרחישים טיפוסיים (ניחוש סיסמאות לפאנל הניהול, העלאת קבצים ניתנים להרצה דרך טפסים, גישה לא מורשית למדורים פנימיים) נחסמים ברמת ההגדרות, ולא מנותחים בדיעבד.
השני — האצת טיפול בפניות: כאשר קיימת תקנון תגובה ולוגים ברורים, המהנדס מבין בתוך דקות מה בדיוק קרה ואיזה מודול כשל, במקום שחזור ממושך של התמונה לפי סימנים עקיפים. השלישי — בדיקות צפויות: ביקורת ובקרה פנימית מתנהלות לפי כללים שהוגדרו מראש, ולא הופכות להפתעה עם חסימת סביבת העבודה.
בנפרד יש להתחשב בגורם האנושי. המדיניות קובעת אילו פעולות זמינות לעורך התוכן, אילו למנהל, ואילו דורשות אישור. הדבר מסיר סוג של אירועים שבהם הבעיה נוצרה לא עקב פריצה, אלא עקב שינוי מקרי של הגדרה קריטית או פרסום קוד לא בטוח.
בסך הכל, הגנה בנויה מעבירה את האבטחה ממצב של "כיבוי שריפות" למצב של תהליך מנוהל: ברור מה מוגן, מה מתועד בלוגים וכיצד לפעול בעת דחייה. בהמשך נפרק ממה מורכבת הגדרה כזו בפועל.
גישות להגדרת הגנה: השוואת אפשרויות
ההגנה של 1С-Битрикс בנויה משלושה שכבות, ולקוחות בדרך כלל בוחרים ביניהן, ולא בין הגדרות ספציפיות. האמצעים המובנים — מסנן פרואקטיבי, בדיקת הרשאות על קבצים, הגבלת הפעלות, תיעוד ביומן — מכסים תרחישים טיפוסיים: ניחוש סיסמה, העלאת קבצים להרצה דרך טפסים, גישה למדורים פנימיים. זה מספיק כל עוד האתר פועל על שרת אחד ואינו מקבל תשלומים.
המעטפת החיצונית — יישום אינטרנט לפני הליבה, כללי סינון בקשות, הגבלת קצב הפניות, בידוד לוח הניהול ברשת — נדרשת במקומות שבהם יש תעבורה ציבורית, אינטגרציות ונתונים אישיים. היא אינה מבטלת את האמצעים המובנים, אלא מסירה עומס מהליבה: בקשות חשודות נחסמות לפני שהן מגיעות ליישום.
ביקורת ותקנונים — בדיקה סדירה של התצורה, ניתוח יומנים, הרשאות גישה לפי תפקידים, סדר עדכון הליבה והמודולים — הופכים הגדרה חד-פעמית לתהליך מנוהל. בלעדיהם כל עדכון או מודול חדש שוב פותח את מה שנסגר.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| רק אמצעים מובנים | אתר קטן, שרת אחד, אין תשלומים ונתונים אישיים | אינה מחזיקה התקפות ממוקדות, אין הגנה לפני הליבה, ההגדרות מתאפסות בעדכונים |
| מובנים + מעטפת חיצונית | תעבורה ציבורית, אינטגרציות, אזור אישי, תשלום | דורשת תחזוקת כללים, התראות שווא בעת שינויים באתר |
| ביקורת מלאה עם תקנונים | שחרורים סדירים, כמה סביבות, דרישות בנוגע לנתונים אישיים | נדרשים תפקידים ייעודיים וזמן צוות, הגדרה חד-פעמית אינה עובדת |
בפועל משלבים בין השכבות: אמצעים מובנים כבסיס, מעטפת חיצונית תחת עומס, תקנונים — כדי שהתצורה לא תתפצל בין הסביבות. הבחירה תלויה בכמה נתונים וכסף עוברים דרך האתר.
כיצד אנו מיישמים מדיניות אבטחה: שלבים
את העבודה מתחילים במיפוי הרשאות גישה: מייצאים רשימה של חשבונות משתמש, קבוצות והרשאות ברמת המודולים, מערכת הקבצים ופאנל הניהול. בשלב זה עולים לפני השטח משתמשים "מתים", מנהלים מיותרים והרשאות שניתנו "לזמן מה" ונשכחו. בלי המפה הזו כל הגדרה של כללים הופכת לניחוש — לכן מתעדים את המצב הנוכחי כנקודת ייחוס.
בהמשך מתכננים סכמת תפקידים לפי תחומי האחריות בפועל של העובדים, ולא לפי קבוצות שהתגבשו היסטורית. כל אחד מקבל את המינימום הנדרש לעבודתו: מנהל התוכן לא נוגע בהגדרות המודולים, קבלן חיצוני רואה רק את המדור שלו. בנפרד מתארים חשבונות שירות והרשאות גישה של אינטגרציות — להם תוקף משלהם והיקף נראות משלהם.
- מיפוי הרשאות גישה: אוספים חשבונות משתמש, קבוצות, הרשאות למודולים ולקבצים, ומסמנים את הבעלים של כל תפקיד.
- סכמת תפקידים: מתאימים את תחומי האחריות של העובדים להרשאות מינימליות מספיקות, ומסירים חפיפות ועודפות.
- הגדרת כללים: מפעילים מדיניות סיסמאות, הגבלת הפעלות, הגנה על פאנל הניהול, תיעוד כניסות ושינויים.
- הפרדה לפי רמות: מגדירים הרשאות לאינפובלוקים, למודולים ולמערכת הקבצים כך שגישה למדור אחד לא תפתח את המדורים הסמוכים.
- בדיקה: מריצים תרחישים תחת כל תפקיד, ומוודאים שהמיותר סגור ושאין פעולות עבודה שנשברו.
- תיעוד נהלים: מתארים את סדר הענקת ושלילת ההרשאות, מועדי בחינה מחדש, ואחראים לכל פעולה.
- מסירה והדרכה: מראים לאחראים כיצד לתחזק את הכללים, לאן להסתכל בעת תקרית וכיצד להגיב לעזיבת עובד.
מה נותנת הרצף הזה
הסדר אינו מקרי: תחילה רואים את התמונה האמיתית של ההרשאות, אחר כך מתכננים תפקידים, ורק לאחר מכן מפעילים את הכללים הטכניים. אם מחליפים את השלבים, ההגדרות יונחו מעל כאוס וחלק מההרשאות יישארו פתוחות. הבדיקה לפני המסירה תופסת קונפליקטים כשמחירם מינימלי.
בסיום הלקוח מקבל לא סט חד-פעמי של סימוני וי, אלא מתאר עבודה: סכמת תפקידים מובנת, כללים מופעלים, נהלים להענקה ולשלילה של הרשאות גישה, ואחראים שעברו הדרכה. בהמשך די לבחון את המדיניות מחדש לפי לוח זמנים ובעת שינויים בצוות — בלי לפרק הכול מהתחלה.
מדיניות גישה ותפקידים: מה מגדירים
ההגדרה מתחילה במיפוי: אילו קבוצות משתמשים באמת קיימות, לאילו מדורים בממשק הניהול ולמודולים הם זקוקים לגישה, מי מפרסם תוכן, מי רק צופה בפניות.
בלי זה מטריצת התפקידים הופכת לפורמליות — ההרשאות מחולקות "לפי העין", וכעבור חצי שנה איש לא זוכר לשם מה למנהל יש גישה להגדרות המודולים.
לאחר מכן מקבעים את הכללים כקונפיגורציה שניתן לבדוק ולהעביר בין סביבות:
- מטריצת תפקידים — טבלת "קבוצה → מדור → פעולה": קריאה, כתיבה, פרסום, מחיקה. קבוצות שירות כמו מנהלי מערכת ומפתחים מופרדות ממנהלי תוכן, ולכל רמה יש מינימום הרשאות משלה.
- כללים לקבוצות — ירושה במקום הענקה נקודתית: תפקיד חדש מורכב מערכות מוכנות, ולא מעשרות תיבות סימון בממשק. שינוי כלל חל על כל הקבוצה בבת אחת.
- הגבלות על קבצים וטפסים — רשימה לבנה של סיומות להעלאה, איסור על סקריפטים ניתנים להרצה בספריות ההעלאה, בדיקת טפסים נשלחים והגבלת תדירות הפניות אליהם.
- תיעוד פעולות — מי נכנס, מה שינה, מתי פרסם או מחק. הרשומות נשמרות בנפרד מבסיס הנתונים התפעולי, כדי שעריכת תוכן לא תמחק את ההיסטוריה.
- הפרדת גישה לבלוקי מידע ולמודולים — הרשאות לבלוקי מידע ספציפיים, ולא למודול כולו: העורך עובד עם המדור שלו ואינו רואה את המדורים השכנים.
- מדיניות סשנים — משך חיים, הצמדה להתקן, התנהגות בכניסה במקביל מכתובות שונות.
- נוהל בחינה מחדש — עם פיטורים או שינוי תפקיד ההרשאות נשללות באותו יום, ולא "כשיגיעו הידיים".
כל סעיף מעצבים כקונפיגורציה ניתנת לשחזור, ולא כהסכמה בעל פה. אז בעת העברת האתר לשרת חדש או הוספת עובד הכללים מיושמים באופן אחיד, והפערים נראים מיד — לפי התיעוד ולפי ההרשאות בפועל.
מקרה בוחן: כיצד נסגר מערך אירועי האבטחה בפורטל
הפורטל על 1С-Битрикс שירת כמה מאות עובדים: בקשות לגישות עברו דרך דואר אלקטרוני ומסרים מיידיים, והרשאות ניתנו ידנית מפאנל הניהול. בשיא — יותר ממאה פניות בחודש, זמן מתן ההרשאות הממוצע הגיע עד לשני ימי עבודה, וחלק מהגישות נותרו בידי עובדים לאחר מעבר בין מחלקות.
מה היה לפני השינויים
הביקורת חשפה שלוש בעיות מערכתיות. ההרשאות הצטברו: ולמחצית מהמשתמשים היו יותר גישות ממה שנדרש לתפקידם הנוכחי, מכיוון שבעת מעברים ההרשאות הישנות לא נשללו.
עדכוני המודולים והליבה בוצעו ידנית וללא נוהל — חלק מהאירועים התרחשו דווקא לאחר עדכונים, כאשר השתנו הגדרות הגישה לקבצים ולמדורים. גיבויים נעשו, אך את השחזור איש לא בדק, ולכן זמן השחזור בפועל היה בלתי ידוע.
מה שינו
הפרדנו את הגישות לפי תפקידים וקשרנו אותן למבנה היחידות הארגוניות, כך שההרשאות ניתנות ונשללות אוטומטית בעת שינויים בכוח האדם. הגדרנו מדיניות סיסמאות, אימות דו-שלבי למנהלים ותיעוד פעולות בפאנל הניהול. את העדכונים העברנו למתאר בדיקה עם קיבוע תצורה, ואת נוהל הגיבוי השלמנו בבדיקת שחזור סדירה.
מה קרה לאחר מכן
הפניות בנושא גישות הצטמצמו בערך פי שלושה — מתן הרשאות טיפוסיות נסגר לפי תפקידים ללא עבודה ידנית. זמן מתן ההרשאות הממוצע ירד לכמה שעות, והשלילה בעת מעבר מתבצעת אוטומטית. מערך הכשלים לאחר עדכונים חדל לחזור על עצמו: השינויים עוברים תחילה במתאר בדיקה, ולתוצר נכנסת תצורה שכבר נבדקה. זמן השחזור מגיבוי כעת ידוע ועומד בנוהל המוסכם.
במה שונה הגנת אתר מהגנת פורטל?
אתר ציבורי ופורטל פנימי נבנים על אותה פלטפורמה, אך מודלי האיומים שלהם שונים, ומדיניות האבטחה של 1С-Битрикс עבורם מוגדרת באופן שונה. האתר פתוח החוצה: כל מי שמצא את הדומיין תוקף אותו — מסורקי פגיעויות אוטומטיים ועד לניחוש ממוקד של פרטי התחברות של מנהל.
הפורטל מוסתר מאחורי הפרימטר ונגיש לעובדים, ולכן הסיכון העיקרי כאן אינו פריצה מבחוץ אלא ניצול לרעה של הרשאות: דליפת מאגר לקוחות, ייצוא תנאים מסחריים, שינוי נתונים בדיעבד.
מכאן ההבדל הראשון — תפקידים. באתר קריטית ההגנה על תרחישים לא מאומתים: טפסים, רכיבים ציבוריים, העלאת קבצים, אזור הניהול שלעיתים קרובות נשאר פתוח בכתובת הסטנדרטית. בפורטל המרכזי הופך מודל הגישה: מי רואה אילו מדורים, מי יכול לאשר מסמכים, כיצד מופרדות ההרשאות בין מחלקות וקבלנים.
אותו חשבון בדיוק עם הרשאות עודפות באתר — חור אבטחה, בפורטל — נורמה יומיומית שנשארת בלתי מורגשת במשך שנים.
ההבדל השני — נהלי תגובה. עבור האתר בונים הגנה מרעש חיצוני: הגבלת קצב בקשות, סינון תעבורה נכנסת, בקרת שלמות קבצים, עדכונים סדירים של הליבה והמודולים. עבור הפורטל חשובים יותר תיעוד פעולות המשתמשים ובקרת שינויים: מי ומתי ערך רשומה, אילו נתונים ייצא, מאילו כתובות נכנס. בלי זה חקירת אירוע בתוך החברה נתקלת בהיעדר עקבות.
השלישי — סדרי עדיפויות במשאבים מוגבלים. באתר סוגרים תחילה את משטח התקיפה הציבורי, משום שדווקא אותו בוחנים כל הזמן. בפורטל מסדרים תחילה את ההרשאות והסשנים, משום שהנזק מגיע לרוב מבפנים.
אין לערבב גישות אלה: מדיניות שנכתבה עבור אתר מותירה את הפורטל בלי בקרת גישה, ומדיניות עבור פורטל אינה מגנה על טפסים ציבוריים.
ספקות טכניים נפוצים
מדיניות אבטחה היא מערכת כללים ברמת הליבה והתצורה, ולא טלאי מעל המוצר. לכן הדבר הראשון שלקוח טכני בודק הוא האם ההגנה לא תשבור עדכונים, מהירות ואינטגרציות. להלן ניתוח של שלושה ספקות שעולים לרוב לפני ההתחלה.
האם יהיה צורך לכתוב מחדש את המדיניות לאחר כל עדכון של הפלטפורמה?
הכללים נבנים על מנגנונים סטנדרטיים: חלוקת הרשאות לפי תפקידים, סינון קלט, בקרת סשנים ומערכת הקבצים. עדכוני הפלטפורמה משנים את הפנים הפנימיים של המודולים, אך אינם מבטלים את נקודות ההצמדה הללו — כלומר, התצורה עוברת ללא כתיבה מחדש.
אנו מתעדים כל כלל בשכבה נפרדת ומנהלים יומן שינויים: בעת עדכון רואים בדיוק מה מושפע, והתיקון נעשה נקודתית ולא "מאפס". לפני העלאה של עדכון אנו מריצים בדיקות בסביבת בדיקה — אם כלל מתנגש עם הגרסה החדשה, זה עולה לפני הפרודקשן.
האם ההגנה תאט את האתר וזמן התגובה יגדל?
רוב הבדיקות — הרשאות גישה ואימות נתונים — מבוצעות ברמת הבקשה ואינן מוסיפות השהיה מורגשת. דברים כבדים כמו סריקה מלאה של קבצים בכל פנייה איננו מפעילים: הם יוצרים עומס ללא תועלת אמיתית. במקום זאת — בקרה סלקטיבית של קבצים ששונו ותיעוד פעולות חשודות.
בפועל זמן התגובה נשאר בטווח הערכים הקודמים, וצווארי בקבוק, אם היו, דווקא נעלמים: חלק מהבקשות המיותרות נחסמות לפני העיבוד.
מה עם שירותים חיצוניים — סליקה, דיוורים, CRM?
האינטגרציות פועלות דרך אותן הרשאות ומפתחות גישה, ולכן המדיניות לא שוברת אותן אלא מסדרת אותן. אנו מקצים לכל שירות סט הרשאות נפרד לפי עקרון המינימום ההכרחי: שער סליקה אינו מקבל גישה לפאנל הניהול, מערכת הדיוורים — למאגר ההזמנות. המפתחות נשמרים מחוץ לקוד ומתחלפים לפי לוח זמנים. אם שירות מפסיק להגיב או מפתח מבוטל — זה נראה בלוגים, ולא עולה כ"האתר לא עובד".
נותרו ספקות לגבי סטאק או תרחיש מסוים — תארו את המשימה, נחזור עם הערכה ותוכנית.
נדון במשימה שלכם ונחזור עם תוכנית
כדי לחזור עם הערכה ותוכנית עבודה, אנחנו צריכים מינימום של נתוני קלט: מהו הפרויקט, על איזו מהדורה של «1С-Битрикс» הוא פועל, כיצד בנוי ההוסטינג ומה כבר הוגדר בנוגע להרשאות גישה. מכאן מתחיל ניתוח התצורה הנוכחית — בלעדיו כל הערכה תהיה ניחוש.
לאחר מכן אנחנו עובדים בשלבים:
- אוספים את התצורה הנוכחית: מהדורת המוצר, הרכב המודולים, הסביבה (שרת ייעודי, ענן, shared), גרסאות PHP ומסד הנתונים, נקודות האינטגרציה עם «1С».
- בודקים את הגדרות האבטחה בפועל: הרשאות קבוצות משתמשים, מדיניות סיסמאות, יומן חדירות של ההגנה הפרואקטיבית, רמות הגישה לפאנל הניהול ולקבצים.
- מתעדים את הפערים בין מה שהוצהר לבין מה שלמעשה מופעל — זהו היקף העבודה העיקרי.
- מתאמים סדרי עדיפויות: מה סוגרים בראשונה (הרשאות גישה, עדכונים, גיבויים), ומה ניתן להעביר לגל השני.
- מכינים תוכנית עבודה עם שלבים, אחראים וקריטריוני קבלה לכל סעיף.
- חוזרים עם הערכת לוחות זמנים ומאמץ עבודה — לפי שלבים, ולא במספר אחד של «עד הסוף».
כדי שהשיחה תהיה עניינית, תארו את המשימה בצורה חופשית:
- מהו הפרויקט ועל איזו מהדורה של «1С-Битрикс» הוא פועל;
- היכן מאוחסן האתר ומי אחראי על התשתית;
- אילו תקלות או הערות כבר היו (פריצה, פעילות חשודה, דרישות ביקורת);
- אילו אינטגרציות עם «1С» ומערכות חיצוניות מעורבות;
- האם קיימות מגבלות על זמן השבתה וחלונות עדכון;
- מי מצד הלקוח מקבל את התוצאה וכיצד הוא בודק אותה.
ככל שנתוני הקלט מפורטים יותר, כך ההערכה מדויקת יותר. אם חלק מהנתונים אינו ידוע — כתבו זאת כך, ונוסיף לתוכנית שלב נפרד לספירת מלאי.