כולנו עושים היום בקרות על הרשאות: קמפיינים תקופתיים לאישור הרשאות, וקבלת אישור להרשאות בעלות רגישות.
אבל רגע..
יש שלב שחייב לקרות הרבה לפני כל זה, והוא כמעט תמיד חלקי.
איך בכלל מזהים מה רגיש?
ברוב הארגונים הזיהוי מבוסס על אינטואיציה:
"אדמין זה מסוכן", "פרודקשן זה רגיש", והשאר נשאר באפור.
וזה לא בגלל שמישהו מזניח, זו פשוט בעיה מובנית:
⧫ רוב ההרשאות לא נראות "מסוכנות" בשם שלהן
הרשאה בשם כמו “Config Editor” או “Integration Manager” יכולה להיות קריטית, אבל אין בה מילה שתדליק נורה.
⧫ רגישות היא עניין של הקשר, לא רק של שם
אותה הרשאה יכולה להיות תמימה במערכת אחת, ומסוכנת מאוד במערכת אחרת.
⧫ הנוף הטכנולוגי השתנה
בענן וב-SaaS הרבה הרשאות נותנות כוח עצום בלי להיראות "פריבילגיות".
⧫ המידע מפוזר
האם הרשאה "מסוכנת" תלוי בסביבה, בסוג הפעולה ובנתונים שאליהם היא נוגעת.
התוצאה בפועל:
ארגונים מטפלים מצוין במה שהם כבר מכירים כרגיש, אבל מפספסים כמות גדולה של הרשאות רגישות "שקטות".
ככה מתקדמים נכון:
🏷️ מתחילים בתיוג הרשאות כ- "רגישות"
בלי תיוג: קשה מאד להפעיל בקרות איכותיות.
1️⃣ תיוג ידני כנקודת פתיחה
בעלים של מערכת מסמן מה באמת מסוכן: מה מאפשר לנהל, לשנות, למחוק או לגשת למידע רגיש.
2️⃣ במקביל – תיוג ממוכן, דרך ה- IGA
מערכת IGA יכולה לזהות אוטומטית הרשאות רגישות, למשל:
– הרשאות שמאפשרות Write/Delete/Manage
– גישה לסביבות Prod או לנתונים רגישים
– הרשאות עם רדיוס פגיעה רחב במיוחד במספר מערכות
רק אחרי שיש תיוג כזה, אפשר באמת להפעיל בקרות אפקטיביות:
אישורים מחמירים יותר, סקירות ממוקדות, הרשאות זמניות, חריגים עם תוקף, ובעלים ברורים.
אם אין לכם היום מנגנון שיטתי לזיהוי ותיוג הרשאות רגישות, סביר שכל הבקרות שאתם מפעילים מטפלות רק בחלק מהתמונה, ואולי לא בחלק שהכי חשוב.
רוצים פשוט להתייעץ? אנחנו זמינים! כתבו לנו: [email protected]
