ביקורת אבטחה של 1C-Bitrix: היכן נשברת ההגנה
רוב ניתוחי האירועים באתרים ובפורטלים המנוהלים על ידי 1C-Bitrix מראים אותו דבר: הפלטפורמה עצמה סגורה די בקפידה, אבל הכניסה נמצאת דרך המעטפת. גישת בדיקה שנשכחה, מודול-«טלאי» שלא עודכן שלוש שנים, הרשאות כתיבה לתיקיות שבהן יושב הקוד.
תרחיש טיפוסי — גישה לא מורשית מושגת לא דרך ליבת המוצר, אלא דרך הרחבה שהותקנה על ידי קבלן «לשבוע» ונשארה לשנים.
נקודת תורפה שנייה — תצורת הסביבה. מצב דיבוג בסביבת הפרודקשן, יומנים ודאמפים בתיקייה נגישה מהאינטרנט, חשבון מנהל יחיד לפיתוח, בדיקות ופרודקשן, גיבויים ליד האתר.
פריצה לחנות מקוונת לרוב מגיעה דווקא מכאן: משחזרים הרשאות דרך חשבון ישן של עובד או קבלן שעזב, ולא מפענחים סיסמה לפאנל הניהול.
המחיר של אירוע כזה — לא רק זמן השבתה. שינויים בתבנית עיצוב ההזמנה, סקריפטים מיירטים בעמוד התשלום, אי-התאמה בנתונים בהזמנות ובהיסטוריית הלקוחות. פרצת האתר נחשפת בדרך כלל דרך צד שלישי — מערכת תשלומים, תוצאות חיפוש או תלונת קונה — כאשר הגישה כבר הושגה ומעוגנת.
בדיקת אבטחה שבאמת מוצאת משהו מתבצעת בשלושה רבדים: תפקידים והרשאות באזור הניהול, קוד צד שלישי ומקורו, תצורת השרת והתיקיות. בהמשך נפרט כיצד נסגר כל רובד ובאיזה סדר.
מה נותנת תצורה מאובטחת: זמן, סיכונים, זמן השבתה
סדר בתצורה נמדד לא במספר הסעיפים הסגורים ברשימת הבדיקות, אלא בכמה אירועים לא קרו ובכמה מהר הפלטפורמה חוזרת לעבודה. להלן ארבעה אפקטים שנראים ביומני האירועים ובמדדי הזמינות.
נעלמת מחלקת הכשלים דרך קלט משתמש
בדיקת נתונים בגבול האפליקציה, הפרדת הרשאות על קבצים ואזורי ניהול, השבתת מודולים שאינם בשימוש — תרחישי חדירה טיפוסיים דרך פרמטרי בקשות והעלאת קבצים מפסיקים לעבוד. הניסיונות נשארים ביומנים, אך אינם מגיעים לשינוי נתונים ב-1C-Bitrix.
השחזור הופך לפעולה מוסדרת
עותקים מאומתים של מסד הנתונים וחלק הקבצים, סדר פריסה קבוע וחזרה מגיבוי מעודכן מתורגלים — הופכים את החזרה לעבודה לתהליך שחוזר על עצמו. המהנדס הולך לפי מסמך, ולא מברר תוך כדי היכן נמצאים הנתונים הדרושים — זמן השחזור מתקצר פי כמה.
ההשבתה מפסיקה להימשך יום שלם
התראות על אנומליות, בקרת שלמות, הפרדה בין סביבות עדכון לסביבת הפרודקשן — ממקמות את התקלה: שירות אחד הולך לאיבוד, והשאר ממשיכים לקבל הזמנות. הנזק מאי-זמינות מוגבל לשעות במקום יממה של ניתוח השלכות.
עמידות בפני עומס וניסיונות ניחוש סיסמאות
הגבלת קצב בקשות, סגירת ממשק הניהול לפי רשימת כתובות ועדכון רכיבים מיושנים מסירים את עיקר המתקפות האוטומטיות. פרץ תעבורה מבוט או ניסיונות ניחוש פרטי חשבון כבר לא מוציאים את האתר מכלל פעולה.
פורמטים של ביקורת: בדיקה חד-פעמית או בקרה שוטפת
בדיקה חד-פעמית ובקרה שוטפת פותרות שאלות שונות. הראשונה עונה על השאלה «מה פתוח сейчас», השנייה — «האם לא נפתח שוב לאחר עדכון, שדרוג או החלפת קבלן». לכן את פורמט העבודה בוחרים לא לפי נפח הדוח, אלא לפי תדירות השינויים בפרויקט ולפי איזה נתונים הוא מעבד.
| פורמט | מתי מתאים | מגבלות |
|---|---|---|
| בדיקה חד-פעמית | לפני עלייה לאוויר, אחרי שדרוג משמעותי או אירוע, בעת החלפת צוות | מתעדת מצב לתאריך: העדכון הבא של הליבה או המודול שוב משנה את התמונה |
| בקרה שוטפת | פרויקט פעיל עם שינויים ועדכונים שוטפים | דורשת נוהל וגישה קבועה לסביבה; בין בדיקות חלק מהשינויים נשארים ללא הערכה |
| ליווי אבטחה | חנות, אזור אישי, החלפת נתונים עם מערכת חשבונאית, תרחישי תשלום | דורש כוננות ומעורבות מהנדס; לאתר תדמית זה מוגזם |
כיצד לבחור פורמט
קו מנחה פשוט: ככל שיש יותר נקודות כניסה וככל שהשינויים עולים לאוויר לעיתים קרובות יותר, כך המרווח בין הבדיקות צריך להיות קצר יותר. בדיקה חד-פעמית מוצדקת כאשר הפרויקט קפוא ומתוקן לעיתים רחוקות — הדוח סוגר את המשימה ומשמש בסיס להשוואה. אם הקוד והתצורה מתוקנים מדי שבוע, בקרה ללא לוח זמנים מאבדת משמעות: הפרצה מספיקה לחיות כמה גרסאות.
בפועל הפורמטים לא מתנגשים, אלא משלימים זה את זה. בדיקה חד-פעמית נותנת תמונת מצב ורשימת עדיפויות, בקרה שוטפת שומרת עליהן סגורות, וליווי אבטחה מוסיף ניתוח אירועים ובדיקת הרשאות. תארו את הפרויקט — נציע פורמט ולוח זמנים בהתאם לתדירות הגרסאות שלכם.
שלבי העבודה: מאיסוף הרשאות ועד מסירת נהלים
ביקורת אנו מבצעים ברצף קבוע — כך הממצאים לא הולכים לאיבוד, ואת התוצאה אפשר לבדוק שוב. תחילה אנו מסכמים את הגבולות: ליבה, מודולים ורכיבים מותאמים אישית, תצורת שרת, אינטגרציות עם 1C ושירותים חיצוניים.
- גבולות ואיסוף הרשאות. אנו מבקשים גישה לפאנל הניהול, למאגר הקוד ולשרת תחת חשבון נפרד עם הרשאות מינימליות, לא תחת משתמש-על. במקביל אוספים מפת מערכת: דומיינים, מסדי נתונים, מתזמן משימות, חיבורים חיצוניים, רשימת מנהלים.
- בדיקת קוד. ניתוח ידני של מודולים ורכיבים מותאמים אישית בתוספת סורק אוטומטי: שאילתות למסד נתונים ללא הגנה, כתיבת קלט משתמש לדיסק, עקיפת בדיקת הרשאות, קריאות מיושנות לליבה.
- בדיקת סביבה ואינטגרציות. הרשאות קבצים, זמינות גיבויים ומדורים שירותיים מבחוץ, הגדרות סשנים, פורטים פתוחים, מדיניות עדכונים. בנפרד — החלפת נתונים עם 1C ושירותים חיצוניים: מפתחות בגלוי, היעדר חתימת בקשות.
- טיפול בממצאים. מדרגים לפי נגישות והשלכות, סוגרים במקבצים מהקריטי לקוסמטי. כל תיקון מתאמים ובודקים בסביבת בדיקות, ולא בסביבת הפרודקשן.
- בדיקת בקרה. חוזרים על תרחישים לפי הממצאים הסגורים ומריצים את הסורק מחדש — יש צורך באישור שהפרצה אינה נגישה, ולא ב«כאילו תיקנו».
- מסירת נהלים. דוח עם עדיפויות, רשימת עדכוני חובה, כללי הפרדת הרשאות ונוהל תגובה לאירוע — כדי שהתיקון הבא לא יחזיר את המצב לאחור.
מה נשאר אצלכם: תצורות, תרשימים, נהלים
הביקורת מסתיימת לא בדוח רב-עמודים, אלא באוסף תוצרים שנשארים במאגר הקוד ובשרת שלכם. נהלים ותרשימים ממשיכים לעבוד בכל שחרור גרסה ובשעה הראשונה של אירוע — להלן מפורטים מה בדיוק נמסר.
- תצורות ליבה ושרת. מצבי דיבוג מושבתים, מדורים שירותיים סגורים, איסור הרצת קוד בתיקיות העלאה וגיבויים, ענפי תלויות מעודכנים.
- מפת פרצות. רשימת נקודות כניסה עם רמת קריטיות, תרחיש ניצול וסדר סגירה: מה מתקנים מיד, ומה נכנס לגרסה מתוכננת.
- תרשים תפקידים והרשאות גישה. טבלת «תפקיד — מה רואה — מה משנה»: עורך תוכן לא נכנס להגדרות מודולים, קבלן עובד בקבוצה נפרדת עם תקופת גישה מוגבלת.
- מטריצת הרשאות ברמת קבצים ומסד נתונים. אילו חשבונות שירות ניגשים למה, אילו תיקיות סגורות לכתיבה, היכן מופעל תיעוד חובה.
- תיעוד אבטחה. הגדרות עם הסבר מדוע נבחר דווקא הערך הזה — כדי שהמנהל הבא לא יכבה הגנה «מטעמי נוחות».
- נוהל אירועים. סדר פעולות, נקודות הסלמה, את מי ובתוך כמה זמן מיידעים, כיצד מתעדים עקבות ומעלים עבודה מגיבוי.
- תוכנית בדיקות שוטפות. מה ובאיזו תדירות מריצים: עדכונים, הרשאות, יומנים, שחזור בדיקה — עם אחראי לכל סעיף.
מקרה בוחן: כיצד ניתחו אירוע בחנות מקוונת
החנות פעלה על 1C-Bitrix, ונקודת הכניסה הייתה סקריפט ישן להעלאת תמונות: הוא קיבל קובץ ללא בדיקת סוג וללא אימות. שמו לב לכך לא דרך היומנים — הרוטציה שלהם כבר דרסה את התקופה הרלוונטית — אלא דרך תלונות קונים על החלפת קישורים בכרטיסי מוצרים.
עד הבוקר ב-400 פריטים הופיעו מעברים לדומיין צד שלישי, תוצאות החיפוש הציגו כותרות מזויפות, ולא ניתן היה לחזור למצב קודם: גיבוי נעשה פעם בשבוע ומעולם לא נבדק לפריסה. החנות הייתה מושבתת כמעט יממה, וכל אותו זמן לא בוצעו הזמנות.
מה עשו
עברו על כל נקודות הכניסה: טפסים, העלאת קבצים, מטפלים ברקע, סקריפטים שירותיים. מודולים מיושנים הושבתו, על האחרים הוגדרו הרשאות לקבצים ולתיקיות כך שקוד הפעלה לא ישב לצד קוד שהועלה.
פאנל הניהול נסגר באימות דו-שלבי והגבלה לפי כתובות, הופעלו גיבויים יומיים עם בדיקת שחזור חובה ומעקב אחר שינויים בקבצים בדיסק.
מדדים לפני ואחרי
נקודות כניסה ללא אימות — מ-14 ל-2. גילוי החלפת קבצים — מאפס ל-15 דקות. שחזור מלא של האתר — מיממה ל-40 דקות. קישורים מוחלפים בכרטיסים — אפס, וניסיונות סריקה חוזרים נתקלים באזורים סגורים ואינם מגיעים לשינויים.
במה שונה בדיקת קוד מבדיקת שרת
בדיקת קוד עונה על השאלה מה הפרויקט עצמו עושה, בדיקת שרת — באילו תנאים הוא פועל. הראשונה מנתחת מודולים מותאמים אישית, תבניות רכיבים, מטפלי אירועים וטפסים משלכם; השנייה — מערכת ההפעלה, הרשאות, שירותים, ערוצים וזמינות ממשקים מבחוץ. האזורים אינם חופפים: כלים שונים ודוחות שונים.
בקוד מחפשים פרצות הזרקה — שאילתות לא מוכנות, פלט ללא סינון תווים, עקיפת בדיקת הרשאות בטפסים משלכם, קליטת קבצים ללא ולידציה, דליפות נתונים ליומנים. הניתוח מתבצע לפי מאגר הקוד ואינו רואה לא הרשאות קבצים, לא תיקיית גיבויים פתוחה, ולא פאנל ניהול הנגיש לכל האינטרנט.
| אזור | מה בודקים | גבולות |
|---|---|---|
| קוד הפרויקט | מודולים מותאמים אישית, תבניות, מטפלי אירועים, טפסים משלכם, העלאת קבצים | לא יציג הגדרות שרת, הרשאות קבצים וזמינות פאנל הניהול מבחוץ |
| שרת וסביבה | מערכת הפעלה, הרשאות, שירותים, ערוצים, גיבויים, יומנים, הגנת היקף | לא יקרא את לוגיקת האפליקציה: עקיפת הרשאות בתוך מודול תישאר בלתי מורגשת |
| הגדרות פלטפורמה ותצורת סביבה | הרשאות קבוצות, מדיניות סיסמאות וסשנים, מצב דיבוג, תיעוד, מטמון | לא מחליף ניתוח קוד ולא אחראי למצב מערכת ההפעלה |
בפועל המתחמים מצטלבים במתקפה, לא בהגנה: פרויקט נקי מבחינת קוד מדליף דרך תיקיית גיבויים פתוחה, ושרת מוקפד פורצים דרך טופס שמקבל קובץ ללא בדיקה.
לכן ביקורת אבטחה לאתר על 1C-Bitrix נעשית בכל שלושת האזורים בבת אחת, והממצאים מרוכזים לרשימה אחת עם עדיפות — קודם גישה לנתונים ולפאנל הניהול.
ספקות טכניים נפוצים לפני תחילת העבודה
לפני ביקורת אבטחה לקוחות שואלים כמעט את אותן שאלות: האם צריך לעצור את האתר, האם מספיקות הרשאות חלקיות, מה יופיע בדוח והאם ניתן לסגור את ההערות בכוחות עצמכם. להלן תשובות כדי להסיר ספקות לפני תחילת העבודה.
האם יהיה צורך לעצור את האתר במהלך הבדיקה?
לא. בודקים עותק של הפרויקט: קוד, הרשאות קבוצות משתמשים, הגדרות מודולים ורכיבים, פרמטרי סביבה. בסביבת הפרודקשן לא נוגעים — מבקרים ופניות עובדים כרגיל, ובדיקות בעומס מתאמות בנפרד ומועברות לשעות פעילות נמוכה.
מה עושים אם ההרשאות חלקיות?
מתחילים ממה שיש: קריאת קבצי הפרויקט, פאנל הניהול וייצוא מסד הנתונים נותנים את רוב התמונה. גישה למאגר הקוד, לתצורות שרת האינטרנט וליומנים מתבקשת תוך כדי — ובדוח מסמנים אילו אזורים נותרו ללא בדיקה.
מה ייכלל בדוח?
רשימת הערות עם עדיפות, תרחיש ניצול והפניה לקובץ או פרמטר מסוים, בתוספת המלצות לתיקון. לכל סעיף — קריטריון שלפיו ניתן לחזור על הבדיקה ולאשר שההערה נסגרה.
האם נוכל לתקן את ההערות בכוחות עצמנו?
כן, הדוח עצמאי: הוא מתאר את מהות הבעיה, את מקומה ואת אופן התיקון. אם נוח יותר להעביר את הסגירה אלינו — נתאם היקף, נעריך בנפרד ונאשר את התוצאה בבדיקה חוזרת.
נדון במשימה: ממה מתחיל הניתוח
כדי שהניתוח יתחיל ללא הפסקות, נדרשים לנו הרשאות למה שכבר עובד והקשר מינימלי על הפרויקט. הסדר הוא כזה: שיחה קצרה על המשימה, איסוף נתוני פתיחה, הערכה ותוכנית עבודה עם שלבים, עדיפויות ומועדים — ורק לאחר אישור מתחילים בעבודה.
מה שולחים בהתחלה:
- כתובת האתר או הסביבה, גישת בדיקה עם אותה תצורה כמו בסביבת הפרודקשן;
- מאגר קוד עם הקוד או ארכיון של תבניות ומודולים, כולל התאמות אישיות;
- ייצוא תצורה ורשימת מודולים מותקנים;
- גישה לשרת או לפאנל האחסון: יומני שרת האינטרנט, פרמטרי PHP, משימות מתוזמנות, הרשאות קבצים;
- תפקידי מנהלים וכללי גישה: מי ואיך נכנס לפאנל הניהול, האם יש חשבונות משותפים;
- תיאור אירועים, אם היו: מתי שמו לב, מה השתנה באתר, מה שוחזר;
- רשימת אינטגרציות — 1C, מערכות תשלום, שירותים חיצוניים, לאן יוצאים הנתונים.
לפי הנתונים האלה אנו מרכיבים תמונה שלמה: היכן הקוד מסתכן, היכן תצורת השרת, היכן הפרדת ההרשאות. הערכה ותוכנית מגיעות עם פירוט לפי שלבים ועדיפויות — קודם מה שסוגר נתיבים קריטיים, אחר כך חיזוק מתוכנן. תארו את המשימה בשתיים-שלוש פסקאות, ונחזור עם הערכה ותוכנית.