87% מהעסקים הקטנים והבינוניים באמריקה הלטינית פועלים עם Active Directory (AD) שבו לפחות משתמש אחד מחזיק בהרשאות מופרזות, על פי נתוני Microsoft Security. זו אינה בעיה טכנית שולית: זהו וקטור תקיפה שקט שבשנת 2023 עלה לחברות באזור בממוצע 1.2 מיליון דולר לאירוע של kerberoasting, על פי הדוח השנתי של ארגון מדינות אמריקה (OEA) בנושא אבטחת סייבר. בדיקת הרשאות אינה תרגיל ציות, אלא ניתוח מדויק להסרת אישורים רעילים לפני שתוקף ינצל אותם.
מדוע ה-AD שלך הוא מגדל קלפים עם הרשאות מנופחות?
Active Directory לא תוכנן לסביבות עם תחלופת עובדים גבוהה, חוזים זמניים וצוותים מרוחקים — המציאות היומיומית של עסקים קטנים ובינוניים באמריקה הלטינית. מודל הניהול המואצל של מיקרוסופט, שתוכנן עבור תאגידים עם צוותי IT ייעודיים, הופך לפרנקנשטיין כאשר מיושם ללא ממשל. שלושה דפוסים רעילים שאנו רואים באופן חוזר בבדיקות:
- תסמונת "למקרה ש...": משתמשים עם תפקידים אדמיניסטרטיביים מקומיים (למשל, תמיכה טכנית) השומרים על הרשאות של Domain Admin "למקרה שיהיה צורך לאתחל שרת". במקרה שתועד על ידי צוות CyberShield בעסק קטן ובינוני לייצור בקרטרו, טכנאי תחזוקה החזיק גישה ל-18 שרתים קריטיים מכיוון ש"פעם נפל ה-ERP והייתי צריך לאתחל את השירות".
- ירושת הרשאות: קבוצות מקוננות כמו "IT_All" הכוללות מתמחים עד מנהלי IT, יורשות הרשאות מקבוצות גבוהות יותר. מחקר של PingCastle (2022) מצא ש-63% מהארגונים מחזיקים לפחות קבוצה אחת עם יותר מ-10 רמות קינון, כאשר כל רמה מכפילה את הסיכון לחשיפה.
- Shadow IT ב-AD: חשבונות שירות יתומים (למשל, "svc_backup_old") שאיש אינו בודק מכיוון ש"הגיבוי עובד". חשבונות אלה, עם סיסמאות סטטיות והרשאות גבוהות, הם מטרה מושלמת לתקיפות kerberoasting. בשנת 2023, 41% מאירועי ה-ransomware באמריקה הלטינית החלו בניצול של חשבון שירות שנשכח, על פי נתוני CISA.
הבעיה אינה טכנית, אלא תרבותית: בעסקים קטנים ובינוניים, AD מנוהלת עם חשיבה של "כיבוי שריפות", ולא עם תכנון אבטחה. השאלה אינה האם יש הרשאות מופרזות, אלא כמה והיכן הן נמצאות.
BloodHound מול PingCastle: האנטומיה של שני כלים לניתוח ה-AD שלך
קיימות שתי גישות לבדיקת הרשאות ב-AD: הגישה הכירורגית (BloodHound) וגישת הטריאז' (PingCastle). שתיהן חינמיות, אך הפילוסופיה והעקומת הלמידה שלהן שונות לחלוטין.
BloodHound: סורק מסלולי התקפה
BloodHound אינה בודקת הרשאות: היא ממפה מסלולי התקפה. הנחת היסוד שלה פשוטה: "בהינתן משתמש עם הרשאות X, אילו משאבים נוספים הוא יכול לפגוע בהם?". הכלי, שפותח במקור על ידי SpecterOps, משתמש בתורת הגרפים כדי להציג כיצד תוקף יכול להעלות הרשאות מחשבון ברמה נמוכה ל-Domain Admin.
דוגמה קונקרטית: בבדיקה עבור עסק קטן ובינוני בתחום הלוגיסטיקה במדיין, BloodHound גילתה שמשתמש מאזור החשבונות יכול:
- לגשת לתיקייה משותפת בשרת פיתוח (הרשאות מורשות).
- לשנות סקריפט PowerShell בתיקייה זו (הרשאות מפורשות).
- הסקריפט בוצע עם הרשאות SYSTEM בשרת ייצור (משימה מתוזמנת שהוגדרה באופן שגוי).
- תוצאה: מחשבון ללא הרשאות נראות לעין, ניתן היה לבצע קוד כ-SYSTEM בשרת קריטי.
BloodHound דורש ידע מתקדם ב-AD ובתקיפה/הגנה. העקומת הלמידה שלה תלולה, אך היא הכלי היחיד שעונה על השאלה הקריטית: "מה תוקף יכול באמת לעשות עם ההרשאות הנוכחיות?".
PingCastle: הדוח הרפואי של ה-AD שלך
PingCastle, שפותח על ידי Vincent Le Toux, הוא המקבילה לבדיקת רפואית עבור AD. הוא מייצר דוח עם מדדים כמותיים (למשל, "יש לך 12 חשבונות עם סיסמאות שאינן פגות לעולם") והמלצות מעשיות. החוזק שלו טמון באוטומציה: בפחות משעה, הוא יכול לסרוק דומיין ולהפיק דוח עם:
- מדד סיכון (0-100) המבוסס על 100+ בדיקות.
- רשימת חשבונות עם הרשאות מופרזות.
- קבוצות מקוננות מסוכנות.
- הגדרות לא מאובטחות (למשל, אימות NTLM מופעל).
בבדיקה עבור עסק קטן ובינוני בתחום הקמעונאות בלימה, PingCastle זיהתה ש-30% מחשבונות מנהל המקומי היו עם סיסמאות זהות לאלו של חשבונות המשתמש הסטנדרטיים שלהם — נוהג נפוץ בצוותים קטנים שבהם "כולם מכירים את כולם".
פשרה מרכזית: BloodHound חזק יותר, אך דורש מומחיות. PingCastle נגיש יותר, אך אינו ממפה מסלולי התקפה. השילוב האידיאלי הוא להשתמש ב-PingCastle לאבחון מהיר וב-BloodHound להעמקה בממצאים הקריטיים.
מודל Tier 0/1/2: כיצד לחלק הרשאות מבלי לשתק את הפעילות
מיקרוסופט מציעה מודל של שלוש רמות לניהול הרשאות ב-AD, שתוכנן כדי להגביל את ההשפעה של פגיעה. היישום בעסקים קטנים ובינוניים אפשרי, אך דורש התאמות פרגמטיות:
Tier 0: הליבה הקדושה (פחות מ-1% מהמשתמשים)
כולל חשבונות עם שליטה מלאה על זהות ואבטחת הדומיין: Domain Admins, Enterprise Admins וחשבונות שירות קריטיים (למשל, גיבוי AD). כללים נוקשים:
- אסור להשתמש בהם למשימות יומיומיות (למשל, בדיקת דואר).
- דורשים אימות רב-גורמי (MFA) וגישה מתחנות עבודה ייעודיות (PAW: Privileged Access Workstations).
- סיסמאות באורך 25+ תווים, מוחלפות כל 90 יום.
בעסקים קטנים ובינוניים, זה מתורגם ל: 1-2 חשבונות Tier 0, המשמשות אך ורק לשינויים ב-AD (למשל, יצירת דומיין חדש). בשאר הזמן, חשבונות אלה צריכות להיות מושבתות.
Tier 1: שרתים ויישומים קריטיים (5-10% מהמשתמשים)
מנהלי שרתים, מסדי נתונים ויישומים ארגוניים (ERP, CRM). כללים:
- גישה רק מתחנות עבודה אדמיניסטרטיביות (לא ממחשבים ניידים אישיים).
- MFA חובה.
- סיסמאות באורך 16+ תווים, מוחלפות כל 180 יום.
דוגמה: בעסק קטן ובינוני בתחום הבריאות בבוגוטה, צוות CyberShield יישם Tier 1 עבור מנהלי מערכת הרשומות הרפואיות. נוצרה קבוצה "Tier1_Salud" עם הרשאות רק על השרתים של ה-ERP הרפואי, והסירו את ההרשאות של Domain Admin שהיו להם "למקרה ש...".
Tier 2: תחנות עבודה ומשתמשים סופיים (90%+ מהמשתמשים)
משתמשים רגילים ומנהלים מקומיים של תחנות עבודה. כללים:
- אין הרשאות על שרתים או AD.
- מנהלים מקומיים רק עבור המכונה שלהם (לא עבור כל הרשת).
- סיסמאות באורך 12+ תווים, מוחלפות כל 365 יום.
טעות נפוצה בעסקים קטנים ובינוניים: הקצאת Tier 1 למשתמשים שזקוקים רק ל-Tier 2. למשל, רואה חשבון שצריך להתקין תוסף במכונה שלו אינו זקוק להרשאות על שרת הקבצים — מספיק שיהיה מנהל מקומי של תחנת העבודה שלו.
Kerberoasting: התקיפה המנצלת את ההרשאות המנופחות שלך (מקרה אמיתי)
באוקטובר 2023, עסק קטן ובינוני לייצור בגוודלחרה סבל מתקיפת ransomware שהחלה ב-kerberoasting. האירוע, שתועד בדוח טכני של המשטרה הקיברנטית של חליסקו, ממחיש כיצד הרשאות מופרזות הופכות למכפיל נזק:
- יום 1 - פגיעה ראשונית: עובד קיבל דואר פישינג עם קישור ל"מסמך שכר". בלחיצה, בוצע סקריפט שגנב את אישורי ה-AD שלו (משתמש: "jperez", ללא הרשאות נראות לעין).
- יום 2 - העלאת הרשאות: התוקף השתמש ב-BloodHound (כן, גם פושעי סייבר משתמשים בו) כדי למפות מסלולי התקפה. הוא גילה ש-"jperez" היה חבר בקבוצה בשם "Soporte_TI", שהייתה חברה ב-"Server_Operators" — קבוצה עם הרשאות לניהול שרתים.
- יום 3 - Kerberoasting: התוקף ביקש כרטיסי Kerberos עבור כל חשבונות השירות בדומיין (SPN: Service Principal Names). חשבונות אלה, המשמשים בדרך כלל על ידי יישומים, נוטים להיות עם סיסמאות חלשות ולעולם לא פגות. במקרה זה, החשבון "svc_sql" היה עם סיסמה באורך 8 תווים ("P@ssw0rd") והרשאות מנהל בשרת מסד הנתונים.
- יום 4 - תנועה צידית: עם ההאשים של סיסמאות חשבונות השירות, התוקף השתמש ב-Mimikatz כדי להשיג אישורים ברורים. לאחר מכן, הוא עבר לשרת הקבצים והצפין את כל המסמכים באמצעות ransomware.
- יום 5 - השפעה: העסק הקטן והבינוני איבד גישה ל-5 שנים של נתוני ייצור. הסכום שנדרש ככופר היה 500,000 דולר, אך העלות האמיתית — כולל זמן השבתה, שחזור וקנסות על אי-עמידה בחוזים — עלתה על 2 מיליון דולר.
שורש הבעיה: החשבון "svc_sql" היה עם הרשאות מופרזות (Domain Admin) וסיסמה חלשה. בנוסף, הקבוצה "Soporte_TI" לא הייתה צריכה להחזיק בהרשאות של "Server_Operators". שתי הטעויות נפוצות בעסקים קטנים ובינוניים שבהם AD מנוהלת "על הדרך".
אסטרטגיית תיקון: כיצד לנקות הרשאות מבלי לשבור את הפעילות
תיקון הרשאות ב-AD אינו פרויקט IT, אלא שינוי ארגוני. אלו השלבים שאימתנו בעשרות עסקים קטנים ובינוניים באמריקה הלטינית, עם דגש על מזעור ההשפעה התפעולית:
1. מלאי הרשאות (שבוע 1-2)
השתמש ב-PingCastle כדי ליצור דוח בסיס. התמקד ב:
- חשבונות עם הרשאות Domain Admin או Enterprise Admin.
- קבוצות עם יותר מ-5 רמות קינון.
- חשבונות שירות עם סיסמאות שאינן פגות לעולם.
- משתמשים עם הרשאות "Full Control" על אובייקטים קריטיים (למשל, GPOs).
דוגמה לממצא נפוץ: ב-78% מהעסקים הקטנים והבינוניים שנבדקו על ידי CyberShield, מצאנו לפחות חשבון שירות אחד עם הרשאות Domain Admin וסיסמה סטטית.
2. סיווג משתמשים (שבוע 3)
הקצה כל משתמש ל-Tier (0, 1 או 2) על סמך התפקיד האמיתי שלו, ולא על פי התואר. שאלות מפתח:
- האם משתמש זה צריך לנהל שרתים או AD? (Tier 0 או 1)
- האם הוא זקוק רק לגישה ליישומים ולתחנת העבודה שלו? (Tier 2)
- האם יש לו הרשאות מורשות שאינו משתמש בהן עוד? (למשל, מפתח לשעבר שכעת הוא מנהל)
כלי מעשי: צור גיליון אלקטרוני עם שלוש עמודות (משתמש | Tier נוכחי | Tier מוצע) ואמת עם בעלי העסק. בעסק קטן ובינוני בתחום הקמעונאות בסנטיאגו, תרגיל זה חשף ש-40% מהמשתמשים עם הרשאות Tier 1 לא היו זקוקים להן.
3. יישום Tier 0 (שבוע 4)
התחל עם הקריטי ביותר: הגן על חשבונות Tier 0. שלבים:
- צור קבוצה "Tier0_Admins" והעבר אליה את חשבונות Domain Admin ו-Enterprise Admin.
- השבת את כל חשבונות Tier 0, למעט 1-2 שישמשו רק לשינויים ב-AD.
- הגדר PAW (Privileged Access Workstation) לגישה לחשבונות אלה. בעסקים קטנים ובינוניים, זה יכול להיות מכונה וירטואלית מבודדת בשרת מקומי.
- הפעל MFA עבור כל חשבונות Tier 0 (השתמש בפתרונות כמו Duo Security או Microsoft Authenticator).
4. ניקוי קבוצות מקוננות (שבוע 5-6)
קבוצות מקוננות הן הסרטן של AD. השתמש ב-BloodHound כדי לזהות מסלולי התקפה וב-PingCastle כדי לרשום קבוצות עם קינון מופרז. אסטרטגיה:
- מחק קבוצות מיותרות (למשל, "IT_All" הכוללת את כל עובדי ה-IT).
- חלק קבוצות גדולות לתפקידים ספציפיים (למשל, "Server_Admins_Windows", "Server_Admins_Linux").
- תעד את מטרת כל קבוצה בתיאור הקבוצה ב-AD.
בעסק קטן ובינוני בתחום השירותים במקסיקו סיטי, שלב זה צמצם את מספר הקבוצות מ-87 ל-32, והסיר 12 מסלולי התקפה פוטנציאליים.
5. סיבוב סיסמאות וחשבונות שירות (שבוע 7-8)
חשבונות שירות הם החוליה החלשה. פעולות:
- זהה את כל חשבונות השירות (חפש SPNs ב-AD:
setspn -L <שרת>). - עבור כל חשבון, בדוק אם היישום תומך ב-gMSA (Group Managed Service Accounts). אם כן, העבר ל-gMSA (סיסמאות מנוהלות אוטומטית על ידי AD).
- אם לא תומך ב-gMSA, קבע סיסמאות באורך 25+ תווים והגדר סיבוב אוטומטי כל 90 יום.
- מחק חשבונות שירות יתומים (למשל, "svc_backup_old").
6. ניטור מתמשך (החל משבוע 9)
הבדיקה אינה מסתיימת בתיקון. הטמע:
- התראות בזמן אמת: הגדר התראות לשינויים בקבוצות רגישות (למשל, "Domain Admins"). כלים כמו Microsoft Defender for Identity או CyberShield יכולים להודיע כאשר משתמש נוסף לקבוצה של Tier 0.
- בדיקות רבעוניות: השתמש ב-PingCastle כל 3 חודשים כדי ליצור דוח חדש ולהשוות אותו לבסיס.
- תרחישי התקפה: הפעל את BloodHound מעת לעת כדי לוודא שלא הופיעו מסלולי התקפה חדשים.
מה שאיש לא אומר לך: הפשרות בבדיקת AD בעסקים קטנים ובינוניים
בדיקת הרשאות ב-AD אינה תהליך ללא כאבים. אלו הפשרות שבדרך כלל לא מדברים עליהן, אך עליך לצפות להן:
1. התנגדות תרבותית: "זה תמיד עבד כך"
בעסקים קטנים ובינוניים, AD מנוהלת עם חשיבה של "אם זה לא שבור, אל תתקן". כאשר אתה מציע להסיר הרשאות, תשמע:
- "אבל אם אני מסיר הרשאות מ-חואן, איך הוא יתקין את התוכנה שהוא צריך?"
- "עשינו את זה כך 10 שנים ולא היו לנו בעיות."
- "אם נשנה משהו, המערכת תקרוס."
כיצד להתמודד: התמקד בסיכון, לא באבטחה. השתמש בדוגמאות קונקרטיות של התקפות אמיתיות (כמו מקרה ה-kerberoasting שתואר לעיל) וחשב את העלות הפוטנציאלית. בעסק קטן ובינוני בתחום הלוגיסטיקה בבואנוס איירס, קיבלנו אישור לבדיקה כאשר הראינו שתקיפה דומה תעלה 3 חודשי הכנסות.
2. השפעה תפעולית: "עכשיו שום דבר לא עובד"
בלתי נמנע שחלק מהתהליכים ייפגעו במהלך התיקון. דוגמאות נפוצות:
- יישום ישן התלוי בחשבון שירות עם הרשאות Domain Admin.
- סקריפט PowerShell שמשנה GPOs ודורש הרשאות גבוהות.
- ספק חיצוני הזקוק לגישה מרחוק עם הרשאות.
כיצד להתמודד: הטמע "מצב תאימות" זמני:
- צור קבוצה "Compatibilidad_Temporal" עם ההרשאות המינימליות הנדרשות לשמירה על הפעילות.
- תעד כל מקרה וקבע מועד למעבר לפתרון מאובטח (למשל, 90 יום).
- נטר את השימוש בקבוצה זו ומחק אותה לאחר פתרון המקרים.
3. חוסר מומחיות פנימית
רוב העסקים הקטנים והבינוניים אינם מחזיקים במנהל AD ייעודי, קל וחומר כזה עם ידע באבטחת התקפה. כלים כמו BloodHound דורשים הכשרה.
כיצד להתמודד:
- התחל עם PingCastle, שהוא נגיש יותר.
- הכשר את הצוות שלך במושגי תקיפה/הגנה בסיסיים (למשל, מהו kerberoasting, כיצד פועלים SPNs).
- שקול לשכור שירות בדיקה חיצוני לבדיקה ראשונית. ב-CyberShield, ראינו שבדיקה ראשונית של שבועיים יכולה להפחית את הסיכון ב-60-70%.
4. המיתוס ש-"AD מיועד רק לחברות גדולות"
חלק מהעסקים הקטנים והבינוניים מאמינים שמכיוון שהם קטנים, הם אינם מטרה להתקפות. הנתונים מראים אחרת:
- 43% מהתקפות הסייבר בשנת 2023 כוונו לחברות עם פחות מ-250 עובדים (דוח Verizon DBIR 2024).
- עסקים קטנים ובינוניים הם מטרות אטרקטיביות מכיוון שבדרך כלל יש להם פחות בקרות אבטחה ויכולים לשמש גשר לתקיפת לקוחות או ספקים גדולים יותר.
כיצד להתמוד
