alterno logo 2024_Negative (1)

היבטי אבטחת מידע בפיתוח UI5 – חלק א

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

החומר מבוסס על ה-TOP10 משנת 2017 המפורטים במניפסט של ארגון ששמו OWASP, העוסק באבטחת המידע ודרכי הגנה מפני תקיפות נפוצות. להלן חמשת הנושאים הקריטיים הראשונים והסבר קצר אודות דרך ההתמודדות בפיתוח SAP UI5 עם הסיכון. מתנצלים מראש על התרגום שלנו לשפת הקודש שיכול להיות לא מדויק לפעמים.

A1: Injection (הזרקה)

מדובר בתופעה בה מכשיר הקצה מעביר מידע עודף (שעלול להיות פוגעני) מעבר למה שוגדר במבנה הנתונים בתוך השאילתה. לדוגמא, במקרה של יצירת הזמנה על ידי לקוח, מכשיר הקצה מזריק שאילתת SQL כחלק מהמבנה, והשרת מבצע את השאילתה כחלק מהתהליך. מדובר בתופעה הכי נפוצה בעולם הפריצות לאתרי WEB, והדרך הכי פופולרית לתקוף אתר בדרך כלל בה לידי ביטוי ב-SQL Injection.

איך תשתיות SAP מתמודדות עם Injection

השאילתות שעוברות ל-SAP מאפליקציות UI5 הן מסוג JSON כאשר הפרוטוקול הוא ODATA. מנוע המעבד את הבקשות (SAP NetWeaver Gateway) מעבר רק בקשות שהמבנה שלהן מוגדר ומגיע תקין (כולל ולידציה של אורך וסוג של כל שדה ושדה) ולא מעביר פנימה בקשות אשר המבנה שלהן אינו תקין.

A2: Broken Authentication (הזדהות שבורה)

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

איך תשתיות SAP מתמודדות עם Broken Authentication

השכבה של SAP NetWeaver מאפשרת לנהל את הנושאים האלו ולהגדיר את התצורה רצויה, ובדרך כלל החלק הזה נמצא בידיו של איש BASIS יחד עם צוות אבטחת מידע, אבל במקרה ואתם שוקלים להחצין את היישום שלכם לעולם החיצון – מומלץ להוסיף שכבה נוספת – Web Application Firewall, מכיוון שהשרת האפליקציה SAP NetWeaver אינו מוצר אבטחת מידע, וגם מצריך עדכונים שוטפים של הגרסה בהתאם ל-security patches המסופקים על ידי SAP.

A3: Sensitive Data Exposure (חשיפה של מידע רגיש)

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

 

איך תשתיות SAP מתמודדות עם חשיפה של מידע רגיש

מערכות SAP מספקות מגוון כלים לצורך הגנה על הנתונים:

  • ניהול הרשאות בעת הגישה נעשה בצד ה-ECC והגישה למידע נעשית עם SSO של המשתמש הנוכחי, לכן ההרשאות שיש לכם כיום במערכות התפעוליות בא לידי ביטוי בצורה שקופה
  • יישומי UI5 אינם שומרים מידע במחשב המשתמש עקב העובדה שמדובר ביישומי WEB
  • הנתונים יכולים להיות מוצפנים עם פרוטוקול SSL \ TLS
  • מידע רגיש (לדוגמא סיסמאות) נשמר במערכות SAP בצורה מוצפנת

 

A4: XML External Entities XXE (ישויות חיצוניות)

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

 

איך תשתיות SAP מתמודדות עם XXE

פרוטוקול ODATA הממומש ברמת SAP NetWeaver Gateway מגדיר בצורה ברורה (ולא ניתנת לשינוי בצד הקורא לשירות) את המבנה של הנתונים הצפויים להיכנס למערכת. במקרה ומבנה הנתונים המגיע בשאילתה אינו תואם למבנה המוגדר ב-Gateway השאילתה לא עוברת והכל נרשם ללוגים במערכת, כך שתוכלו גם לאתר  נסיונות מהסוג הזה.

 

A5: Broken Access Control (בקרת גישה לקויה)

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

 

איך תשתיות SAP מתמודדות עם בקרת גישה לקויה

במקרה ואנו מדברים על יישומי UI5, יש לנו שתי שכבות שעוזרות לנו לנהל הרשאות:

  • ברמת SAP NetWeaver Gateway – ניהול הרשאות ברמת שירותי ODATA על ידי הרשאות SAP מאפשר הפרדת הרשאות ראשונית – פה אנו מגדירים למי מותר להריץ מה ברמת השאילתות, אבל עדיין לא מגיעים לרזולוציה של מידע טרנזקציוני \ אובייקטי הרשאה
  • ברמת SAP ECC \ כל מערכת BACK END אחרת – השליפות מתבצעות עם יוזר נוכחי ולכן ההרשאות האפליקטיביות שיש למשתמש הפונה למערכת – חלות גם ב-UI5. חשוב לוודא שאין BACK DOORS בקוד ה-ABAP, לדוגמא ביצוע שאילתות עם יוזר קבוע.

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

אתם מוזמנים לפנות אלינו עם שאלות.

נתראה בחלק ב' של מאמר זה.

Any questions?

Just write us a message!

Fill out the form and we will be in touch as soon as possible!