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

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

למה Active Directory הוא יעד ראשון לתוקפים

Active Directory הוא מנגנון האמון המרכזי בארגון. הוא מאמת משתמשים, מעניק הרשאות, מפיץ מדיניות קבוצתית ומנהל גישה למשאבים. מי שמשיג הרשאות Domain Admin, או הרשאות מקבילות בפועל, יכול בדרך כלל ליצור חשבונות, לשנות מדיניות, לנוע בין שרתים ולפגוע בגיבויים.

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

מתחילים ממיפוי ולא משינוי הגדרות

לפני הפעלת מדיניות חדשה, יש לבנות תמונת מצב אמינה של הדומיין. צריך לדעת כמה בקרי תחום קיימים, באילו אתרים, אילו מערכות תלויות ב-LDAP או ב-NTLM, מי חבר בקבוצות מורשות, אילו חשבונות שירות פעילים ומה מופץ באמצעות GPO.

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

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

הפרדת הרשאות: לא מנהלים דומיין מחשבון היומיום

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

גם כאן נדרשת מידתיות. לא כל טכנאי Help Desk זקוק להרשאות Domain Admin כדי לאפס סיסמה או לצרף תחנה לדומיין. יש להאציל הרשאות לפי משימה, יחידת ארגון או קבוצת שרתים, ולתעד מי קיבל מה ולמה. שימוש נכון ב-Delegation מצמצם את מספר האנשים שיכולים לגרום נזק רחב, גם בטעות.

יש לבחון בקפדנות חברות בקבוצות בעלות השפעה גבוהה, כגון Domain Admins, Enterprise Admins, Schema Admins, Account Operators ו-Backup Operators. חשוב לבדוק גם הרשאות פחות גלויות: ACL על יחידות ארגוניות, זכות לערוך GPO, הרשאות איפוס סיסמה לחשבונות רגישים והרשאות שכפול ספרייה שעלולות לאפשר תקיפות מסוג DCSync.

תחנות ניהול ייעודיות

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

MFA חשוב, אך הוא אינו מחליף תחנת ניהול מאובטחת. אימות רב-גורמי יכול לעצור שימוש בסיסמה גנובה, אך לא בהכרח יעצור תוקף שכבר השתלט על תחנת מנהל או על אסימון גישה פעיל.

הקשחת בקרי תחום והפרוטוקולים שסביבם

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

יש לבחון הפעלה ואכיפה של LDAP Signing ו-Channel Binding לאחר בדיקת תאימות. אלו בקרות חשובות נגד תרחישים של יירוט או העברת אימות, אך מערכות ישנות עלולות להיכשל אם הן משתמשות ב-LDAP באופן לא תקין. לכן מתחילים במצב ביקורת, קוראים את הלוגים, מזהים את המערכות החריגות ורק אז עוברים לאכיפה.

אותו עיקרון חל על הפחתת תלות ב-NTLM. אי אפשר תמיד לבטל NTLM מיידית, במיוחד בארגונים עם מערכות ותיקות או ציוד ייעודי. אבל אפשר למדוד את השימוש, להבין מי עדיין תלוי בו, לתקן את הנתיבים החריגים ולהתקדם בהדרגה לאימות Kerberos ולצפנים מודרניים. מדיניות נוקשה ללא מיפוי תייצר תקלות. מדיניות מדורגת תייצר שיפור אמיתי.

חשבונות שירות הם מוקד נוסף לסיכון. במקום סיסמאות ידניות וקבועות, יש לבחון שימוש ב-Group Managed Service Accounts במקומות המתאימים. חשבונות אלו מפחיתים את הצורך של צוותים לשמור סיסמאות בקבצי תצורה או בגיליונות עבודה, ומאפשרים סבב סיסמאות מנוהל. לא כל יישום תומך בכך, אך במערכות שכן - זהו שיפור תפעולי ואבטחתי ברור.

GPO הוא מנגנון הגנה וגם מנגנון תקיפה

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

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

באותו הקשר, ניהול סיסמאות מנהל מקומי באמצעות Windows LAPS הוא רכיב בסיסי. סיסמה מקומית זהה בכל התחנות הופכת דליפה אחת לאירוע רוחבי. סיסמאות ייחודיות, שמאוחסנות ומנוהלות בצורה מבוקרת, מקטינות מאוד את יכולת התנועה הרוחבית של תוקף.

ניטור: בלי ראיות אין שליטה

הקשחה שלא מלווה בניטור היא הנחה שהכול עובד. יש להפעיל מדיניות Audit מתקדמת ולשלוח אירועים רלוונטיים למערכת ניהול לוגים או ל-SIEM. שינויים בקבוצות מיוחסות, יצירת משתמשים, איפוס סיסמאות, שינויים ב-GPO, ניסיונות אימות כושלים והרשאות חריגות הם אירועים שחייבים להיות ניתנים לחקירה.

אין צורך להציף את צוות ה-SOC בכל אירוע. הערך מגיע מהתראות שמחברות הקשר: חשבון שנוסף לקבוצת ניהול, התחבר מיד לשרתים רבים, ולאחר מכן ביצע שינויי מדיניות, הוא תרחיש שדורש בדיקה. לעומת זאת, אלפי אירועי כניסה תקינים ללא תיעדוף יהפכו את המערכת לרעש יקר.

נדרשים גם גיבויים שנבדקו בפועל. גיבוי System State של בקרי תחום, הגנה על מאגרי גיבוי, הפרדת הרשאות למערכת הגיבוי ובדיקת שחזור תקופתית הם חלק מההקשחה. בארגון שנפגע, השאלה אינה רק אם יש גיבוי, אלא אם ניתן לשחזר זהויות, מדיניות והרשאות לנקודת זמן אמינה ובזמן סביר.

תכנית עבודה מעשית להקשחת Active Directory בסביבת אנטרפרייז

עדיף לבצע את המהלך בשלבים מדידים ולא במסגרת פרויקט חד-פעמי. סדר עבודה יעיל כולל ארבעה מהלכים:

1. מיפוי נכסים, חשבונות, קבוצות מיוחסות, GPO, תלות ב-LDAP וב-NTLM, ותיעוד בעלי השירותים.
2. סגירת סיכונים מיידיים: חשבונות ניהול משותפים, חברויות מיותרות, סיסמאות מקומיות זהות, חשבונות לא פעילים והרשאות שאינן מוצדקות.
3. הקשחה מדורגת של פרוטוקולים, בקרי תחום ותחנות ניהול, תחילה במצב ביקורת ובסביבת פיילוט.
4. מעבר לתפעול שוטף הכולל ביקורת הרשאות, מעקב אחר חריגות, בדיקות שחזור ומדדי תאימות ברורים.

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

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