ניהול הרשאות וזהויות: טעויות נפוצות שמובילות לדליפת מידע
ניהול הרשאות וזהויות: טעויות נפוצות שמובילות לדליפת מידע
ניהול הרשאות וזהויות נשמע כמו משהו שמסדרים פעם אחת ושוכחים.
בפועל?
זה אחד המקומות הכי ״שקטים״ בארגון, עד שיום אחד הוא נהיה הכי רועש.
והקטע המצחיק-עצוב הוא שהדליפות הגדולות לא קורות בגלל האקרים עם קפוצ׳ון, אלא בגלל החלטה קטנה, הגיונית, שנראתה ״רק לרגע״.
למה זה תמיד מתחיל ב״רק תן לי גישה רגע״?
כמעט כל תקלה אמיתית מתחילה בבקשה לגיטימית.
מישהו צריך לעלות גרסה.
מישהי צריכה לראות דוח.
צוות חייב לפתור תקלה דחופה.
ואז מישהו אומר: ״תן הרשאת אדמין, נוריד אחר כך״.
ספוילר עדין: ״אחר כך״ זה מקום דמיוני, ליד ״מחר אני מתחיל דיאטה״.
כאן בדיוק ניהול זהויות והרשאות צריך להיות חכם, קליל, ומהיר.
לא קשוח ומעצבן.
כי אם התהליך מרגיש כמו עונש, אנשים יעקפו אותו, ובצדק.
7 טעויות קלאסיות שמזמינות דליפת מידע עם קפה ועוגייה
בוא נפרק את הטעויות שחוזרות שוב ושוב.
לא כדי להפחיד.
כדי שתוכל לזהות אותן מוקדם, לחייך, ולסדר אותן לפני שהן עושות דרמה.
1) הרשאות יתר: כשכולם ״כמעט אדמין״
הטעות הכי נפוצה בעולם: נותנים יותר מדי הרשאות ״כדי שלא ייתקע״.
ואז זה נהיה סטנדרט.
ואז פתאום גם עובד חדש יכול למחוק מאגר, לראות נתוני לקוחות, או לשנות קונפיג בפרודקשן.
הגישה הנכונה פשוטה: הרשאת מינימום.
לא מינימום כי לא סומכים.
מינימום כי זה סדר.
כי כשיש מינימום הרשאות, גם טעות אנוש היא קטנה יותר.
2) אין בעלים להרשאה: ״מי נתן את זה בכלל?״
הרשאה שאין לה בעלים היא הרשאה שלא תוסר.
נקודה.
אם אף אחד לא מרגיש אחראי על הגישה למערכת, אז כולם קצת אחראים, ובפועל אף אחד לא.
פתרון פרקטי: לכל אפליקציה, לכל מאגר, לכל סביבת ענן – יש בעלים ברור.
בן אדם.
לא ״הצוות״.
והבעלים הזה מחליט מי מקבל גישה, לכמה זמן, ולמה.
3) חשבונות רפאים: עובדים עזבו, ההרשאות נשארו
Onboarding כולם אוהבים.
Offboarding? פחות פופולרי.
וכאן מגיעים חשבונות יתומים: משתמשים של עובדים שכבר לא בארגון, ספקים שסיימו, פרילנסרים ששכחו מהם.
החשבונות האלה לא עושים רעש.
וזה בדיוק הבעיה.
מה עושים?
- סגירה מיידית של חשבונות כשאדם יוצא מהארגון
- תהליך קבוע שמחבר HR-IT-Security ולא מסתמך על ״מישהו יעדכן״
- ביקורת חודשית על משתמשים פעילים מול רשימת עובדים וספקים
4) הרשאות קבועות למשימות זמניות: ״זה רק לסופ״ש״
משימה זמנית דורשת הרשאה זמנית.
ברור, נכון?
ועדיין, בפועל נותנים הרשאה קבועה כי זה נוח.
הפתרון הכי אלגנטי הוא גישה לפי זמן: הרשאה שפג תוקפה.
אם המערכת לא תומכת בזה בקלות, בונים שכבה שמנהלת את זה.
כי הרשאות זמניות הן כמו תזכורת אוטומטית: הן חוסכות ״שכחנו״.
5) סיסמאות משותפות: ״הנה, שמתי בקובץ״
סיסמה משותפת היא הזמנה לחוסר שליטה.
אי אפשר לדעת מי נכנס.
אי אפשר לדעת מי שינה.
וכשמשהו נשבר, כולם נשבעים שזה לא הם.
זה אפילו לא עניין של אמון.
זה עניין של עקיבות.
אם חייבים גישה משותפת לשירות, משתמשים בזהות שירות מסודרת, עם הרשאות מינימום, רוטציה, וניהול סודות כמו שצריך.
6) אין הפרדת תפקידים: אותו אדם גם מבקש וגם מאשר
כשאותו אדם יכול לבקש גישה וגם לאשר אותה, זה נוח.
וזה גם מסוכן.
לא בגלל שהוא ״יעשה משהו רע״.
אלא כי אין בלמים.
הפרדת תפקידים היא כמו חגורת בטיחות: היא שם בשביל הרגע שבו כולם עייפים, לחוצים, ורק רוצים לסגור טיקט.
7) לא בודקים לוגים: ״יש לנו לוגים… איפשהו״
לוגים זה מדהים.
בתנאי שמישהו באמת מסתכל.
מערכת IAM בלי ניטור היא כמו מצלמות אבטחה שלא מחוברות לחשמל.
לא צריך להיות פרנואיד.
צריך להיות עקבי.
- התראות על כניסות חריגות
- התראות על שינויי הרשאות
- התראות על גישה לנתונים רגישים מחוץ לשעות עבודה
אז מה כן עושים? תכנון קליל שמוריד סיכון בלי להכביד
המטרה היא לא לבנות ״מבצר״ שאף אחד לא יכול לעבוד בו.
המטרה היא לייצר זרימה.
שבה גישה ניתנת מהר, אבל גם נשלטת.
שבה יש מינימום הרשאות, אבל אפס דרמות.
הבסיס: ״זהות אחת״ לכל אדם, בכל מקום
ככל שיש יותר זהויות לאותו אדם, כך קשה יותר לדעת מה באמת קורה.
אידאלית, יש מקור אמת אחד לזהויות.
וממנו מסתעפות הרשאות למערכות שונות.
ככה כשמשהו משתנה, לא רודפים אחרי זה בעשר מערכות.
RBAC, ABAC ומה שביניהם: לבחור נכון ולא לפי טרנד
RBAC מתאים כשיש תפקידים ברורים: תמיכה, פיתוח, כספים.
ABAC מתאים כשיש תנאים דינמיים: מיקום, סוג מכשיר, רמת רגישות, זמן.
במציאות, רוב הארגונים צריכים שילוב.
RBAC כדי לא להשתגע.
ABAC כדי להוסיף דיוק איפה שכואב באמת.
גישה פריבילגית: להתייחס אליה כמו אל חומר דליק (בקטע טוב)
הרשאות אדמין, root, owner, superuser – הן לא ״עוד הרשאה״.
הן עולם אחר.
כאן כדאי לעבוד עם עקרונות פשוטים:
- Just-in-time – מקבלים הרשאה רק כשצריך
- Just-enough – מקבלים רק את מה שצריך
- אישור כפול לפעולות קריטיות
- תיעוד מלא של מי קיבל, מתי, ולמה
5 שאלות ותשובות שאנשים באמת שואלים (כן, גם בשקט)
הנה כמה שאלות שחוזרות בכל ארגון, בכל גודל, בכל ענף.
שאלה 1: למה מינימום הרשאות לא הופך את כולם לאיטיים ועצבניים?
כי אם מתכננים נכון, מינימום הרשאות מגיע עם תהליך מהיר לקבלת גישה.
אנשים לא צריכים כוח בלתי מוגבל.
הם צריכים דרך קלה לקבל את מה שחסר להם, לכמה זמן שהם צריכים.
שאלה 2: מה ה״סימן הראשון״ שיש בעיית הרשאות?
כשיש הרבה הרשאות חריגות ״שנוספו ידנית״.
וכשאין תשובה ברורה לשאלה: ״מי באמת צריך את זה?״
שאלה 3: חייבים MFA בכל מקום?
במקומות רגישים ובגישות מרחוק – כן, כמעט תמיד.
במקומות פחות רגישים, אפשר לדרג לפי סיכון.
העיקרון: לא הכול צריך להיות אותו דבר, אבל מה שקריטי צריך להיות סגור טוב.
שאלה 4: איך מטפלים בספקים חיצוניים בלי להסתבך?
נותנים גישה לפי זמן, לפי תפקיד, ולסביבה מוגבלת.
ועדיף עם משתמשים אישיים ולא חשבונות משותפים.
ספק טוב לא נעלב מתהליך מסודר.
הוא דווקא נרגע.
שאלה 5: מה עושים כשיש ״מערכת ישנה״ שאי אפשר לשנות בה כלום?
עוטפים אותה.
שמים שכבת גישה לפני: פרוקסי, VPN עם מדיניות, או פתרון SSO אם אפשר.
ואם אין ברירה, לפחות מצמצמים הרשאות ומגבירים ניטור.
המבחן האמיתי: האם אפשר להסביר את ההרשאות שלך במשפט אחד?
נסו רגע לחשוב על מערכת אחת קריטית אצלכם.
עכשיו ענו: מי יכול לגשת אליה, ולמה?
אם התשובה היא ״אממ… נראה לי ש…״ אז יש כאן הזדמנות מעולה לשיפור.
לא צריך להפוך הכול ביום אחד.
כן צריך להתחיל איפה שהסיכון הכי גבוה והערך העסקי הכי משמעותי.
שני קישורים, שתי זוויות, ואותו רעיון: סדר עושה שקט
לפעמים קל יותר להבין ניהול זהויות והרשאות כשמסתכלים על אנשים שעוסקים בעולם הטכנולוגיה והאקו סיסטם מזוויות שונות.
אם מעניין אותך להכיר עוד הקשר מקצועי-עסקי, אפשר להציץ באילון אוריאל.
ואם בא לך גם זווית יותר יומיומית וקרובה, אפשר לראות את איילון אוריאל.
סיכום שמחזיר אותך לעיקר: פחות ״כוח״, יותר שליטה
ניהול הרשאות, ניהול זהויות, בקרת גישה ו-IAM הם לא ״פרויקט״ שמסמנים עליו וי.
זה הרגל.
הרגל שמונע דליפת מידע בלי להכניס את כולם למצב מגננה.
כשתהליך הגישה מהיר, כשההרשאות זמניות כשצריך, כשיש בעלים ברור לכל מערכת, וכשיש ניטור שעובד באמת – הכול נהיה קל יותר.
וגם הרבה יותר רגוע.
כי בסוף, אבטחה טובה היא זו שכמעט לא מרגישים.
רק נהנים מהשקט שהיא מביאה.
