מקטע חיסיון

1) מדוע יש צורך במקטע

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

• פחות תקריות בשל ”זכויות מיותרות”;
• מאיץ חקירות: גישה שקופה ומובנת;
• ציות עם SoD/ציות, ביקורת ספק;
• ניסויים בטוחים ושחרור מהיר ללא סיכון לליבת הייצור.

2) עקרונות

אפס אמון: כל פעולה נבדקת באופן קונטקטואלי; בלי ”אזורים מהימנים”.
חיסיון מינימלי: זכויות מינימום שניתנו לתקופה מינימלית (באופן אידיאלי JIT).
הקשר על פני תפקיד: זכויות תלויות לא רק בתפקיד, אלא גם בתכונות (דייר, אזור, סביבה, סיכון).
הפרדה בין חובות (SoD): חניכה נפרדת, אישור, ביצוע וביקורת.
מדיניות-as-Code: מדיניות בקוד עם ורסינציה, בדיקות וביקורות.

3) מודל בגרות גישה

1. RBAC (תפקידים) - תפקידים קבועים (תמיכה, סיכון, תשלומים, מסחר, מבצעים, SRE, ציות).
2. (ABAC): הוספת תכונות: דייר, אזור, תחום שיפוט, מוצר, ערוץ, סביבה (prod/stage/dev), זמן, רמת סיכון של פעולה, אותות KRI.
3. PBAC (מבוסס מדיניות): מדיניות מרכזית ”מי/מה/איפה/מתי/למה” (לדוגמה, במכירות - רק על ידי JIT ועם כרטיס).

4) תחומי סגמנטציה (ציר אחר ציר)

4. דייר/לקוח 1

הגישה והפעולות מוגבלות למותג/מפעיל/שיוך ספציפי.
פעילויות של דייר צולב אסורות מלבד צבירה לא מוגדרת של מח "ש.

4. 2 אזור/תחום שיפוט

מדיניות לוקחת בחשבון רישוי מקומי וכללי KYC/AML.
פעולות הנתונים של השחקן מוגבלות על ידי גאוגרפיה של אחסון ועיבוד.

4. 3 סביבה (dev/stage/prod)

Prod מבודד: נקודות זכות בודדות, רשתות, Bastion/PAM, ”לקרוא רק כברירת מחדל”.
גישה לדחף רק JIT, עם כרטיס והחלפת חלונות.

4. 4 כיתת נתונים

PII/finance/gaming telemetry/technologies - רמות שונות של גישה ומיסוך.
ייצוא PII - רק באמצעות הזרמות עבודה מוצפנות מאושרות וTTL.

4. 5 ביקורתיות של פעולות

P1/P2/P3 כיתות: פרסום מקדמים, קיזוז ידני, מסקנות, שינוי בניתוב PSP - דורש שליטה כפולה.
פעולות בסיכון נמוך יכולות להיעלם על ידי פוליטיקה.

5) רמות חיסיון (שכבות)

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

6) Sod ותפקידים לא מתאימים

• תתחילו להסיק מסקנות שתאשרו באופן סופי.
• ליצור קמפיין בונוס שיופעל במכירה למגבלות השינוי.
• פיתחו את התכונה שמיישמת את הגליל המשוחרר אל הדרבן.
• מבקש העלאה של מח "ש כדי לאשר את הפענוח.

לכל זוג מדיניות פורמלית של איסור והדרה עם תאריך תיקון.

7) גישת JIT ופאם

הגבהה לפי בקשה: ציין את היעד/כרטיס/מונח; לאחר תפוגה - החזרה אוטומטית.
בקרה כפולה: P1/P2 פעולות - שתי אפליקציות מפונקציות שונות.
בקרת הפעלה: הקלטת פגישות קריטיות, התראות חריגות, העתקת היובש בזמן העבודה עם מח "ש.
פריצה: גישת חירום עם מגבלות קשות ופוסט ביקורת חובה.

8) חשבונות שירות וסקופים של API

סקופים מינימליים; משימות/מיקרו-רחיים מחלקים אסימונים/תעודות קצרות חיים.
סיבוב של סודות, איסור של סודות משותפים; ”אלוהים-היקף” איסור.
מגבלות על קצב/מכסות, מפתחות אידמפוטנטיות, חתימת webhook (HMAC).

9) מקטע רמת תשתית

רשתות: בידוד קטע (per-domain/per-per-tenant), עיכוב יציאת ברירת המחדל, mTLS.
Kubernetes/Cloud: spaces/projects per-sביבה ותחום, Gatekeeper/OPA לאסור דפוסים מסוכנים.
DB/Caches: מתווך גישה (DB proxy/IAM), קריאה כברירת מחדל בלבד, DDL נמנע ממכירות מחוץ לחלון.
מקשים/דליים שונים לכל מחלקה עם מדיניות TTL ו-WORM לביקורת.

10) מדיניות כקוד (PaC)

מדיניות בריפוזיטוריות (Rego/YAML), ביקורת יחסי ציבור, בדיקות רכב (unit/e2e), ביקורת diff.
הקשר דינמי: זמן של יום, מיקום, רמת KRI, סיכון ניקוד הפעולה.
הסברים של הרשאה/דחיית החלטה והתייחסות למדיניות בביקורת.

11) יומנים וביקורת

שלמות: מי/מה/איפה/מתי/למה, ערכי טרום פוסט, תעודת כרטיס.
לא ניתן לשינוי: אוסף מרכזי, תולעת/בלתי ניתנת לשינוי, חתימת תקליטים.
קישוריות: שרשרת של קונסולות אדמיניסטרציה = APIS = = מסדי נתונים = = = מספקים חיצוניים.
ביקורת SLA: קצב התגובה לבקשות בקרה/רגולטור.

12) לוחות מחוונים ומטריצים (KPI/KRI)

גישה ל-KPI: נתח של JIT נגד זכויות קבע, משך חיסיון ממוצע,% מכוסה על ידי SoD, זמן עיבוד יישומים, כיסוי חידוש.
KRI של שימוש לרעה: התפרצויות של פעולות רגישות, פריקה המונית, מיקומים/שעות לא טיפוסיים, ”zayavka * deystviye * otkat” רצפים.
מסלול של תפקידים בסיכון גבוה, אירועי זכוכית שבורה, מגמות.

13) דוגמאות מדיניות (סקיצות)

Prod-jit = = = לא נכון וכרטיס = = sod_ok וזמן ב Chank Window.
Oxcultion PII: ”אפשר אם data_class=PII ומטרה במטרות שונות ו tl <= 7d והצפנה = על ומאשר> = 2”.
PSP-Extreme: "לאפשר פעולה ניתוב dual_control risk_assessment_passed rollback_plan_attached'.

14) מימוש מפת דרכים (8-12 שבועות)

נד. 1-2: Operation/Face/Data Inventory, SoD Matrix, Data Classification ו-Segmentation Domains.
נד. 3-4: בסיס RBAC, קטלוג תפקידים, JIT עבור קונסולות ייצור, תחילת PAC (OPA/Gatekeeeper).
נד. 5-6: ABAC: דייר/אזור/סביבה/תכונות כיתת נתונים; הפרדה בין שמות ופרויקטים.
נד. 7-8: PAM (JIT-ruption, session recording, break-glass), DDL איסורים וברוקר נתונים, מדיניות ייצוא PII.
נד. 9-10: PBAC לפעולות בסיכון גבוה (מסקנות, בונוסים, PSP), שליטה כפולה, התראות KRI.
נד. 11-12: תיקונים רבעוניים, 100% כיסוי בסיכון גבוה של פעולות PAC, דיווח ואימונים.

15) חפצים

קטלוג תפקידים: תפקידים, מינימום הרשאות, בעלים.
מטריקס SoD: תפקידים/פעולות בלתי מתאימים, יוצאים מן הכלל, תהליך עקיפה.
Policy Pack: מערכת של מדיניות PaC עם מבחנים ודוגמאות המכחישות/מאפשרות.
טופס בקשה גישה: מטרה, מונח, אובייקט (דייר/אזור/סביבה), הערכת סיכונים, אפליקציות.
רשימה של פעולות P1/P2, חלונות, קריטריונים של שליטה כפולה.
Audit Playbook: אוסף ומספק יומנים, תגובת SLA, תפקידים.

16) תרופות אנטי ־ פטריות

זכויות ניהול קבועות וחשבונות כלליים.
דייר חוצה גישה ”לנוחיות”.
אין אביזרי בידוד/שלב/dev.
מדיניות על נייר ללא אכיפה בקוד/קונסולות.
יצוא PII על ידי הסדר ידני ללא הצפנה ו TTL.
היעדר תיקונים וזכויות תלויות.

17) השורה התחתונה

מקטע חיסיון הוא לא רק "תפקידים נכונים. זהו בידוד רב-ממדי (דייר, אזור, סביבה, נתונים, ביקורתיות) + הקשר דינמי (ABAC/PBAC) + תהליכים (SoD, JIT, Resterication) + כפייה טכנית (PAC, PAM, רשתות/DB). לולאה זו מפחיתה באופן דרמטי את הסיכון לטעות ולהתעלל, מאיצה שינוי בטוח, והופכת את הפלטפורמה לעמידה בקנה מידה ודרישות רגולטוריות.