ביקורת אבטחה של Bitrix: היכן נוצרים פרצים
פרצים בפורטל כמעט לעולם אינם נוצרים בגלל שגיאה אחת — אותם יוצרת קבוצה של הקלות קטנות שהצטברו במהלך השימוש. ביקורת אבטחה של Bitrix מתחילה בספירת מלאי: אילו מודולים מותקנים, האם הם מתעדכנים, למי יש גישה לאזור הניהול ובאיזו עילה. כבר בשלב זה מתגלה חלק ניכר מהבעיות.
אזור נפרד — הרשאות. חשבון עם גישה מלאה, שהוענק "לזמן מה" ונשאר לנצח, או תפקיד עורך שמאפשר טכנית להטמיע רכיבים עם קוד להרצה — זו דרך טיפוסית לגישה בלתי מורשית.
בדיקת מוגנות הפורטל נשענת על עקרון ההרשאות המינימליות הנדרשות: כל פעולה מאושרת על ידי תפקיד, ולא על ידי הנוחות של עובד מסוים.
בהמשך — קוד ונקודות כניסה שירותיות. עמודי שחזור סיסמה הנגישים מבחוץ, סקריפטים לגיבוי הנגישים מבחוץ, ספריות בדיקה שנותרו לאחר שיפורים, מוסרים נתונים ללא אימות. כך גם עם מודולים מיושנים: פגיעות ברכיב לרוב ידועה לציבור, אך העדכון נדחה כי "הכול עובד". כך מצטברות פגיעויות של אתר Bitrix — אחת אחת, בלי לשים לב.
את התמונה סוגר שכבת השרת: גרסאות שרת האינטרנט ומסד הנתונים, הרשאות לקבצים ולספריות, זמינות יציאות הניהול, רוטציית יומנים ומדיניות הגיבוי. כאן אנחנו מביטים לא בהגדרה בודדת, אלא בצירוף: פרמטר חלש כשלעצמו אינו מזיק, אבל יחד עם הרשאות עודפות הוא יוצר תרחיש תקיפה מוכן. התוצאה — רשימה מתועדפת: מה לסגור מיד, מה לפי תוכנית, ואיזו בדיקה תאשר שהפרץ אכן סולק.
בדיקת קוד, שרת והרשאות גישה: מה מסיר את הסיכונים
בדיקת הקוד של הפורטל מתחילה ברכיבים מותאמים אישית, מטפלי אירועים וסוכנים — כל מה שנכתב מעל הליבה של 1C-Bitrix. ממצאים טיפוסיים: סינון קלט לא נעשה בכל מקום, בדיקת הרשאות לפני פעולה משנה מתבצעת לאחר הכתיבה, נתונים מהבקשה נכנסים לשאילתה ללא פרמטריזציה. עדכון הליבה אינו סוגר פגמים כאלה — זהו סוג של כשל שחי בפרויקט עד לתיקון ידני.
הגדרות השרת אנחנו בוחנים כהמשך של האפליקציה: הרשאות מערכת הקבצים, כתיבה לספריות ההעלאה, מצב הצגת שגיאות, הצגת רשימת ספריות שירותיות, זמינות אזור הניהול מבחוץ, תיעוד יומנים וגיבויים. כאן כשל נמדד לא בקלקול, אלא בזמן ההתאוששות: בלי יומנים וגיבוי טרי החשבון הוא בשעות.
הרשאות הגישה של המשתמשים אנחנו מפרקים לפי מטריצת הקבוצות והירושה. עובדים שפוטרו, קבלנים חיצוניים וחשבונות שירות שומרים לרוב על עודף — עד כדי אזור הניהול וייצוא נתונים. הרשאה עודפת פועלת לא כתקיפה, אלא כמחיקה מקרית או דליפה דרך גישה פנימית.
תוצאת הבדיקה — לא "נהיה בטוח יותר", אלא מדדים מדידים: בכמה הצטמצם זמן התגובה לאירוע, אילו סוגי כשל נעלמו מהפרויקט, איזה חלק מהנתיבים הקריטיים מכוסה בבדיקות. העדכונים הופכים לצפויים, כי הקוד המותאם אישית מפסיק להישען על המבנים הפנימיים של הליבה.
אפשרויות בדיקה: חד-פעמית, שגרתית, לאחר אירוע
מצבי הבדיקה אינם מחליפים זה את זה — הם עונים על שאלות שונות. בדיקה חד-פעמית נותנת חתך של המוגנות לתאריך מסוים, בקרה שגרתית מראה מה השתנה מאז הפעם הקודמת, וניתוח חירום נדרש כאשר האתר כבר נפגע או מתנהג באופן מוזר.
הבחירה תלויה במה שידוע על המערכת היום: פרויקט חדש ללא היסטוריה, אתר חי עם שינויים מתמידים בתוכן ועדכוני מודולים, או עובדת אירוע שצריך לסגור ולא לחזור עליו.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| בדיקת מוגנות חד-פעמית | לפני עלייה לאוויר, לאחר מהדורה גדולה, בעת החלפת קבלן או ספק אירוח | נותנת חתך לתאריך: מה שנמצא נסגר פעם אחת, והשינויים הבאים בהרשאות הגישה ובתבניות נשארים ללא בקרה |
| בקרה שגרתית של התצורה | האתר חי, מודולים ורכיבים מתעדכנים, הרכב המנהלים משתנה | נדרשת רשימת ערכים לתקן ותקנון לטיפול בסטיות, אחרת הדוחות הופכים לזרם שאיש לא קורא |
| ניטור שינויים | שירות קריטי, שבו חשובה התגובה בשעות הראשונות ולא בשבוע הבא | דורש התראות מוגדרות ותורן שפועל לפיהן; התראות שווא מערערות במהירות את ערך הערוץ |
| ניתוח אירוע | יש חשד לפריצה, זינוק בעומס, קבצים זרים או הפניות | זו אינה מניעה: תחילה לוקליזציה והתאוששות, בדיקת הפגיעויות מתבצעת לאחר ההתייצבות |
בפועל משלבים בין המצבים: בדיקה חד-פעמית נלקחת כנקודת מוצא, בהמשך מפעילים בקרת שינויים, וניתוח אירוע נשאר תרחיש חירום עם צעדים מתוארים מראש.
סדר העבודה: מאיסוף ההרשאות ועד הדוח
ביקורת אינה הרצה חד-פעמית של סורק, אלא רצף צעדים עם תוצאה ניתנת לשחזור בכל אחד. את ההרשאות מתאמים מראש, את הדוח מרכיבים כך שניתן יהיה לסגור את ההערות לפי סעיפים ולבדוק מחדש.
- תיאום הרשאות וגבולות. חשבון מנהל של הפורטל, גישה למערכת הקבצים ולתצורת שרת האינטרנט, עותק של מסד הנתונים והגיבויים. בסביבת הייצור — רק קריאה ויומנים.
- מפת הפורטל. אתרים, מודולים ותבניות מותאמים אישית, טפסים ציבוריים, חילופי נתונים, משימות מתוזמנות. קוד שכתבו בעצמם — אזור הסיכון העיקרי, והוא נראה רק דרך מפה כזו.
- בדיקת התצורה. הרשאות קבוצות משתמשים, הגדרות ההגנה הפרואקטיבית של 1C-Bitrix, מדיניות סיסמאות, גישה לקבצים, יומני אירועים ותקופת שמירתם.
- בדיקת קוד ושרת. מטפלי טפסים והעלאת קבצים, ניתוח מודולים מותאמים אישית, הרשאות תהליכים, תצורת שרת האינטרנט, שירותים הנגישים מבחוץ.
- דוח עם עדיפויות. לכל הערה: מקום בקוד או בתצורה, תרחיש ניצול, סיווג קריטיות ותיקון קונקרטי.
- תוכנית לטיפול בהערות. תחילה מה שפותח גישה חיצונית, אחר כך השאר. את התיקונים מבצעים אנחנו או הצוות שלכם — עם בדיקה לאחר כל איטרציה.
- בדיקת בקרה. חוזרים על אותם תרחישים בתצורה המתוקנת ומתעדים מה נסגר ומה נותר, עם נימוק.
הדוח והתוכנית נשארים אצלכם: לפיהם ניתן לבצע תיקונים בכוחות עצמכם או לחזור אלינו לבדיקה חוזרת.
מה נשאר אצלכם: תקנונים, מפות ואבטחת אינטגרציות
הביקורת מסתיימת לא בדוח, אלא בסט של תוצרים עובדים שהצוות ממשיך לחיות לפיהם. כל סעיף להלן נמסר בציון הבעלים ותדירות הבדיקה — מסמך בלי אחראי מת כעבור חודש מהמסירה.
- מפת גישה: תפקידים וקבוצות בפורטל, טבלה של "מי רואה ומה משנה", חשבונות שירות נפרדים למשימות חילופי נתונים במקום חשבון ניהולי אחד.
- תקנון אבטחה לפורטל: דרישות לסיסמאות ולתקופת הפעילות של החיבור, אימות דו-שלבי חובה לתפקידים ניהוליים, סדר מתן ההרשאות לעובד חדש ושלילתן בעת פיטורים.
- כללי גיבוי: מה מגבים (קבצים, מסד נתונים, נתוני משתמשים, הגדרות חילופי נתונים), באיזו תדירות, היכן נמצאת העותק השני, באיזו תדירות בודקים את השחזור וכמה זמן אורך פריסה מחדש.
- אבטחת אינטגרציות עם 1C: רשימת נקודות החילוף, משתמש שירות נפרד לכל חיבור, הרשאות בדיוק עד למדריכים והמסמכים הנדרשים, תיעוד היומנים של החילוף משני הצדדים.
- תקנון עדכונים: חלון עבודה, בדיקה מחייבת על עותק של הפורטל, קריטריונים לנסיגה ומי שמקבל את ההחלטה עליה.
- רשימת מודולים וחיבורים חיצוניים: מה מותקן, לשם מה, מי הבעלים, מתי נבדק בפעם האחרונה.
- הגדרת יומן אירועים והתראות: אילו פעולות נרשמות, מה נשלח לאחראי, מהיכן מתחילים את ניתוח האירוע.
סט כזה מאפשר להעביר את הפורטל לצוות אחר או לעבור ביקורת בלי לשחזר בחופזה את מפת הגישה מהזיכרון.
מקרה בוחן: איך סגרו דליפת בקשות בפורטל
הלקוח הגיע לאחר ששותף העביר לו צילום מסך עם בקשות של אחרים: פניות של לקוחות מתחום אחד נראו בתחום אחר. הפורטל על 1C-Bitrix שירת כמה מאות עובדים וחברות שותפות, וברגע הפנייה איש לא יכול היה לומר מי בדיוק מייצא נתונים מהטפסים.
מה נמצא בשלושה ימי ניתוח
יומן הפעולות לא תיעד קריאה וייצוא — רק כניסה ושינוי רשומות. התפקיד "מנהל" אפשר טכנית גישה לכל האזורים עם הבקשות, וחשבון השירות של האינטגרציה עם הרשאות מלאות שמר את מפתח הגישה ישירות בתצורה.
כלומר מקור הדליפה יכול היה להיות כל אחד מהשלושה: הרשאות עודפות, מפתח שנעשה בו שימוש חוזר, או ייצוא ידני דרך לוח הניהול.
מה עשינו
הפרידו את ההרשאות לפי אזורים וסוגי פעולות: קריאה, ייצוא ומחיקה הפכו להרשאות שונות. את חשבון השירות הגבילו לרשימת מתודות מותרות, את המפתח העבירו לאחסון מאובטח עם רוטציה. הפעילו תיעוד יומנים של קריאה, ייצוא ושינוי הרשאות — עם שיוך כל פעולה לחשבון ולכתובת.
מדדים לפני ואחרי: קודם — כמה אלפי רשומות ביממה יצאו שלא לפי התקנון, אין עקבות ביומן, ניתוח האירוע נתקע בהשוואה ידנית וארך כשבועיים. אחרי — אפס ייצואים שלא תועדו, כל הפעולות עם הבקשות משויכות למשתמש מסוים, ניתוח אירוע מלא — בעשרים דקות.
את בקרת הגישה שיקמו, אבל העיקר — נוצרה נראות: כעת את הדליפה רואים בשלב הניסיון, ולא לפי תלונת השותף.
מה לעשות אם האתר כבר נגוע או שיש חשד לפריצה?
סימני פריצה לעתים רחוקות נראים חד-משמעיים: מנוע החיפוש מציב סימון, האנטי-וירוס מתלונן על קובץ שמורידים, מהניהול נעלמות הזמנות, והעומס עולה בזמן שהתנועה יורדת.
ראשית יש לא לנקות את הקוד, אלא לתעד את המצב — להעתיק קבצים ומסד נתונים למדיה נפרדת, לשמור את יומני שרת האינטרנט והכניסות לניהול. אם מוחקים את העקבות מיד, לא ניתן יהיה למצוא את נקודת הכניסה.
בהמשך מבודדים את האתר הנגוע: מעבירים לעמוד מציין מקום, סוגרים את הניהול לפי רשימת כתובות, מנטרלים הרצת סקריפטים בספריות ההעלאה, עוצרים משימות מתזמן. את השרת לא מכבים — לפי היומנים והחיבורים ברשת רואים לאן הולכים הנתונים ואיזה ערוץ משתמש התוקף.
במקביל מחליפים סיסמאות של מנהלים, מפתחות גישה וטוקנים של אינטגרציות, אחרת כניסה חוזרת תתבצע דרך גישה שנגנבה.
את נקודת הכניסה מחפשים לפי תאריכי שינוי הקבצים ועקבות בתצורה: שינויים ב-.htaccess, סקריפטים זרים בספריות ההעלאה, רשומות מיותרות באתחול אוטומטי ובמשימות מתזמן, תבניות ורכיבים ששונו.
את הכניסה נותנת לעתים קרובות לא חור בליבה, אלא גישה נשכחת — חשבון של עובד שפוטר, דומיין בדיקה עם מסד נתונים עובד, מודול Bitrix ללא עדכונים. דווקא הערוץ הזה קובע מה יהיה עלינו לשנות כדי שהתקיפה לא תחזור.
משחזרים מעותק נקי, שנלקח לפני האירוע, ובודקים את הארכיון עצמו לנגיעות — אחרת התקיפה תחזור יחד עם השחזור. לאחר הפריסה מעדכנים ליבה ומודולים, מרכיבים מחדש את תצורת השרת, מפעילים בקרת שלמות קבצים וניטור פעילות חשודה.
את תוכנית התגובה לאירוע מתעדים מראש: מי מבודד, למי יש גישה לעותקים, תוך כמה שעות מעלים את הגרסה העובדת.
ספקות נפוצים: הרשאות, עומס, עדכוני מודולים
רוב הספקות לפני ביקורת הם ארגוניים: לא רוצים לפתוח את סביבת הייצור, לעצור את הפורטל ולקבל בסוף רשימה של מאה סעיפים שאין מי שיסגור. אנחנו עונים על ארבע שאלות שנשאלות בתדירות הגבוהה ביותר.
העיקרון הכללי — תחילה קוראים, אחר כך נוגעים. ניתוח סטטי של קוד, תצורה והרשאות גישה מתבצע על עותק וייצוגי קבצים (דאמפים): הפורטל בייצור באותו זמן פועל כרגיל.
האם נדרשים פרטי כניסה של מנהל וגישה לשרת?
נדרש, אך לא מלא ולא ללא הגבלת זמן. פותחים חשבון נפרד עם הרשאות קריאה של תצורה, יומנים ורשימת המודולים המותקנים; לבדיקת ההפרדה בין ההרשאות — גישה לאזור הניהול של הפורטל. פרטי החשבון מועברים בערוץ מאובטח, תקפים רק למשך העבודה ומבוטלים לאחר מסירת הדוח.
האם הבדיקה תאט את עבודת הפורטל?
תרחישים דינמיים ועומס מריצים על עותק של סביבת הייצור: משחזרים תנועה, מגבילים את מספר הבקשות במקביל, בוחרים חלון מחוץ לשעות העבודה. מהפורטל עצמו אוספים רק יומנים ומדדים שאינם מתחרים על משאבים עם המשתמשים. אם לא ניתן להעלות עותק, הבדיקה מצטמצמת לחלק הסטטי — לוח הזמנים מתארך, ועבודת השירות אינה משתנה.
מה לעשות עם עדכוני מודולים שהוחמצו?
לעדכן הכול ברצף על הייצור — האפשרות הגרועה ביותר: שינויים במודולים נמחקים, והפורטל נשבר כבר במהדורה הראשונה. הסדר הפוך: ספירת מלאי של הליבה והמודולים, תיעוד השיפורים, עדכון על עותק עם הרצת תרחישי המפתח, ואז העברה לייצור. נקודת הנסיגה — גיבוי וצילום מצב (snapshot) של השרת לפני ההתחלה.
כמה זמן אורכת הבדיקה?
פורטל טיפוסי — משלושה עד חמישה ימי עבודה מרגע קבלת ההרשאות. לוח הזמנים מתארך אם יש הרבה רכיבים שנכתבו בעצמם, מודולים של מפתחים חיצוניים או שינויים בליבה. הערכה מדויקת ניתנת לאחר סקירת מבנה הפרויקט.
נדון במשימה: איך בנוי תחילת העבודה
תחילת העבודה אינה מחייבת מכם מפרט טכני של מאה עמודים. די להראות את המתאר: כמה אתרים ופורטלים פועלים על 1C-Bitrix, היכן הם מתארחים, מי מצד הלקוח אחראי על השרת ומי מאשר שינויים. זה מספיק כדי להעריך את היקף הבדיקה ולנקוב בלוחות זמנים ריאליים.
- רשימת המשאבים וייעודם: חלון ראווה, אזור אישי, פורטל פנימי, חילופי נתונים עם מערכת חשבונאית.
- מפת הפריסה: שרת אחד או כמה, היכן נמצא מסד הנתונים, היכן הסטטיקה, האם יש סביבה נפרדת לשינויים.
- נקודות כניסה ותפקידים: אילו קבוצות משתמשים קיימות ואילו הרשאות הוענקו למנהלים.
- הרשאות קריאה: עותק של האתר, הגדרות שרת האינטרנט, יומני אירועים. בפועל את הפורטל העובד לא נוגעים.
- אחראי מצד הלקוח: אדם אחד שמקבל החלטות ומאשר חלונות עבודה.
השלב הראשון — ספירת מלאי והערכת היקף. אנחנו מרכיבים מפה של רכיבים, מודולים והרחבות חיצוניות, בוחנים את הגדרות ההרשאות והיומנים, ולאחר מכן מוסרים תוכנית עבודה להגנת הפורטל עם עדיפויות: מה סוגרים מיד, מה ניתן לדחות. לכל סעיף מצוינים אחראי ולוח זמנים.
לאחר הבדיקה הפורטל אינו נותר ללא השגחה. תמיכה לאחר הבדיקה — היא בקרה של שינוי הגדרות, עדכוני מודולים ובדיקה חוזרת לאחר מהדורות. תארו את המשימה — נחזור עם הערכת היקף ותוכנית לשלב הראשון.