ניהול אבטחה (Security Management)

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

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

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

• 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

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

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

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

נתוני אב • Master Data attributes (Product, Location, Customer, Region) הם הבסיס ל-permission filter criteria. • User Master ב-IBP מקושר לזהות ב-Cloud Identity דרך כתובת-דוא"ל / User ID. שאלות ראיון מהן שלוש שכבות-האבטחה ב-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 · ניהול משתמשים (15.2) • IBP · permission filters (15.4)

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

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