Chapter 15 · 6 תת-פרקים · ~24 דק'

תפקידים ואבטחה

Roles and Security

פרק זה הוא יחידת-לימוד מלאה לתפקידים ולאבטחה ב-SAP IBP (Integrated Business Planning) בענן. אבטחה ב-IBP אינה רק 'מי נכנס למערכת' — היא קובעת אילו נתוני-תכנון כל משתמש רואה, מה מותר לו לשנות, ובאילו שלבים של תהליך-התכנון הוא מעורב. הפרק עוקב אחר מודל-האבטחה המלא: ניהול משתמשים ב-SAP Cloud Identity, יצירת קבוצות-משתמשים (user groups), הקצאת business roles הבנויים מ-business catalogs, ובקרת-הנתונים העדינה דרך permission filters עם read/write criteria — כולל permission filters בשלב-התהליך (process stage). כל תת-פרק מורחב ל-18 מקטעים: שלוש רמות-הסבר (מנהלים, מתחילים, יועצים), מטרה עסקית, דוגמת-תהליך, דוגמת CBC, ניווט באפליקציות-הניהול של IBP, טבלאות/אובייקטים, פרטי-קונפיגורציה, תרשים-זרימה, טעויות נפוצות, פתרון-תקלות, שיטות-מומלצות, שאלות-ראיון ומסקנות-מפתח. המטרה: לשלוט במודל-האבטחה של IBP מקצה-לקצה.

1/6

הסבר מנהלים

ניהול-האבטחה ב-IBP הוא שכבת-הבקרה המגדירה מי רשאי לעשות מה, ועל אילו נתונים. בשונה ממערכות ECC המסורתיות, אבטחה ב-IBP בענן בנויה על שלושה רכיבים משולבים: זהויות (SAP Cloud Identity), הרשאות תפקודיות (business roles המורכבים מ-business catalogs), ובקרת-נתונים (permission filters). הבנת המודל הזה היא תנאי-סף לכל מימוש IBP מאובטח ותואם-רגולציה.

הסבר למתחילים

דמיין בניין-משרדים. כדי לעבוד בו צריך שלושה דברים: כרטיס-כניסה לבניין (זהות), רשימת-החדרים שמותר לך להיכנס אליהם (התפקיד), והיתר לגעת רק בתיקים מסוימים בתוך כל חדר (סינון-הנתונים). ב-IBP בדיוק כך: הזהות פותחת את המערכת, ה-business role פותח אפליקציות ופעולות, וה-permission filter מצמצם את הנתונים שתראה ותשנה.

הסבר ליועצים

מודל-האבטחה של IBP הוא שכבתי ומורכב משלוש שכבות עצמאיות שמצטלבות: (1) Authentication — מנוהל ב-SAP Cloud Identity Services (Identity Authentication / IAS), כולל SSO ו-MFA. (2) Authorization תפקודית — business role אוסף business catalogs, שכל אחד מהם מעניק גישה לקבוצת-אפליקציות ופעולות (display/maintain). (3) Data-level security — permission filters עם read/write criteria מצמצמים שורות-נתונים לפי ערכי-מאפיינים (Master Data attributes). חשוב: שלוש השכבות הן AND — משתמש חייב לעבור את כולן. שינויי-הרשאות נכנסים לתוקף בכניסה הבאה (re-login) ולעיתים דורשים רענון-cache.

מטרה עסקית

המטרה: להבטיח שכל מתכנן רואה ומשנה רק את חלקו בתכנית — בלי לחשוף נתונים רגישים (מחירים, תחזיות-מתחרים, אזורים שאינם באחריותו), תוך עמידה בהפרדת-תפקידים (Segregation of Duties) ובדרישות-ביקורת.

דוגמת תהליך

ארגון גלובלי מקים IBP: צוות-האבטחה מגדיר תחילה את הזהויות ב-Cloud Identity, יוצר business roles לכל פרסונה (Demand Planner, Supply Planner, Viewer), מרכיב כל role מ-business catalogs מתאימים, ולבסוף מצרף permission filters שמגבילים כל מתכנן לאזורו ולמוצריו. בדיקת-קבלה: כל פרסונה נכנסת ומוודאת שהיא רואה בדיוק את מה שתוכנן — לא פחות ולא יותר.

דוגמת CBC

ב-CBC (מבקבק Coca-Cola): מתכנן-הביקוש של אזור הצפון רואה רק את ה-SKUs והמפעלים של הצפון; מתכנן-האספקה הארצי רואה את כל המפעלים אך יכול לשנות רק תכניות-ייצור; מנהל-המכירות מקבל role של Viewer בלבד — רואה תחזיות אך לא משנה. כל זה נאכף בשלוש השכבות יחד.

תרשים תהליך

הגדרת זהותCloud IdentityAuthentication / SSO

יצירת business roleManage Business Roles

הרכבה מ-business catalogsאפליקציות + פעולות

הצמדת permission filtersread/write criteria

הקצאה למשתמש/קבוצהManage Users

בדיקת-קבלה לכל פרסונהרואה בדיוק את המתוכנן

ניווט / SPRO

SAP IBP Web UI

└─Side Navigation

└─Administration

└─Manage Users

SAP IBP Web UI

└─Administration

└─Roles and Permissions

└─Manage Business Roles

SAP Cloud Identity Services

└─Identity Authentication

└─User Management

קונפיגורציה

Authentication: מוגדר ב-SAP Cloud Identity Services (IAS) — SSO/SAML, MFA, מדיניות-סיסמה.
Authorization: business role = אוסף business catalogs; כל catalog מעניק אפליקציות + פעולות.
Data security: permission filters עם read/write criteria מוצמדים ל-role או למשתמש.
כלל-זהב: שלוש השכבות הן AND — חוסר באחת חוסם גישה.

T-Codes

Manage UsersManage Business RolesManage Permission Filters

Tables

IBP User MasterBusiness RoleBusiness CatalogPermission Filter

Fiori Apps

Manage UsersManage Business RolesManage Permission FiltersManage User Groups

נתוני אב

Master Data attributes (Product, Location, Customer, Region) הם הבסיס ל-permission filter criteria.
User Master ב-IBP מקושר לזהות ב-Cloud Identity דרך כתובת-דוא"ל / User ID.

טעויות נפוצות

התמקדות בהרשאות-אפליקציה (business role) בלבד תוך התעלמות מ-permission filters — המשתמש רואה את כל הנתונים.
מתן role רחב 'כדי לחסוך זמן', ואז ניסיון לצמצם בדיעבד — קשה לתחזק וחושף בקרת-ביקורת.
הנחה שינוי-הרשאה נכנס מיד — בפועל דורש re-login ולעיתים רענון-cache.

פתרון תקלות

משתמש רואה נתונים שאסור לו ➔ חסר permission filter, או ה-filter לא הוצמד ל-role/למשתמש.
משתמש לא נכנס כלל ➔ בעיית Authentication ב-Cloud Identity (זהות לא-פעילה / SSO).
משתמש לא רואה אפליקציה ➔ business catalog חסר ב-business role.

שיטות מומלצות

תכנן את שלוש השכבות יחד מהיום הראשון — אל תדחה את ה-permission filters.
אמץ עקרון-המינימום (least privilege): התחל מצומצם, הרחב לפי צורך מוכח.
תעד מטריצת-פרסונות (persona × catalogs × filters) ושמור אותה כמקור-אמת.

שאלות ראיון

מהן שלוש שכבות-האבטחה ב-IBP?

Authentication (SAP Cloud Identity), Authorization תפקודית (business role המורכב מ-business catalogs), ו-Data-level security (permission filters עם read/write criteria). שלושתן פועלות כ-AND.

מדוע business role לבדו אינו מספיק לאבטחה?

business role פותח אפליקציות ופעולות, אך אינו מצמצם אילו שורות-נתונים נראות. ללא permission filter המשתמש יראה את כל הנתונים שהאפליקציה מציגה.

מסקנות מפתח

אבטחת IBP = שלוש שכבות: זהות, תפקיד תפקודי, סינון-נתונים.
השכבות פועלות כ-AND — חוסר באחת חוסם.
permission filters הם מה שהופך אבטחה ל'מי רואה אילו נתונים', לא רק 'מי נכנס'.

נושאים קשורים

IBP · ניהול משתמשים (15.2)IBP · permission filters (15.4)

SAP by Sali · Project NEO

טוען את נוף ה-SAP…