אבטחת Active Directory: מה מגן באמת על הדומיין, ומה רק נראה ככה

Active Directory (לרוב בקיצור AD) הוא לא "עוד שרת": הוא מי שמחליט מי מורשה להיכנס לאן, על איזה מחשב, ולעיתים גם איך נראית כל התשתית סביבו. כשהוא נפרץ, התוקף לא "שובר מחשב אחד", הוא מקבל מפת דרכים לכל הארגון. במאמר הזה נפרק למה זה קורה בפועל, מה עושים קודם (לפי סדר שעובד בשטח), ואיך זה מתחבר לענן ול-Microsoft Entra ID בסביבות היברידיות.

למה AD הוא יעד מספר אחת

ברוב הארגונים עם Windows Server, הזהות נשענת על AD: משתמשים, קבוצות, מדיניות, לעיתים גם DNS ושירותי קבצים. תוקף שמגיע לחשבון עם הרשאות גבוהות, במיוחד Domain Admin או שירותים רצים בהקשר של מערכת עם הרשאות מלאות, יכול לנוע לרוחב הרשת בלי שיצטרך "לפרוץ" שוב ושוב כל תחנה.

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

עקרון השכבות (Tiering), בלי זה קשה לנצח

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

• Tier 0, בקרי דומיין, תשתיות הזהות, מערכות שאם נופלות, נופל הכול.
• Tier 1, שרתי יישום ותשתית שרתים (לא קצה).

• Tier 2, תחנות קצה ומשתמשים.

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

חשבונות מנהלים: פחות זה יותר, ותמיד עם מעקב

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

מה שעובד טוב יותר:

• מינימום Domain Admins, רק מי שבאמת צריך, עם אישור תהליכי.
• שירותים רצים תחת gMSA או חשבונות ייעודיים ממוזערים, לא תחת מנהל דומיין.

• Break glass, שני חשבונות חירום מבודדים, מורכבים, שנשמרים בכספת תהליכית ונבדקים בתרגילים. הם לא לשימוש יומיומי.

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

סיסמאות מקומיות ו-LAPS

בלי LAPS (Local Administrator Password Solution), הרבה תחנות שומרות על אותה סיסמת מנהל מקומי, ואז תוקף שקיבל אותה במקום אחד יכול לנוע הצידה. LAPS מבטיח שסיסמת Administrator מקומית ייחודית לכל מחשב ומתחלפת לפי מדיניות.

זה אחד השדרוגים עם היחס הגבוה ביותר בין מאמץ לתועלת באבטחת AD בסביבת Windows.

חתימות ופרוטוקולים: LDAP, SMB ו-Kerberos

חולשות קלאסיות נובעות מכך שמערכות מדברות בפרוטוקולים "חלשים מדי" כשמשאירים ברירות מחדל ישנות:

• LDAP signing, מפחית סיכון לשינוי תעבורה בין לקוח לבקר.
• SMB signing, חשוב כשמדובר בתעבורת קבצים ובהרחבות שמסתמכות על SMB.

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

עדכונים, גיבוי ו-SYSVOL

בקרי דומיין חייבים להיות הראשונים בעדכונים, לא האחרונים. עיכוב חודשים על קומulative update לשרת שמחזיק AD הוא הימור שאף IT מנוסה לא לוקח בקלות.

בנוסף:

• גיבויים שמאומתים בשחזור (לא רק "יש קובץ").
• מעקב אחר SYSVOL ומדיניות קבוצתית, שינויים שם משפיעים על אלפי מחשבים.

ניטור ויומנים: לראות לפני שמגיעים למסקנה

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

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

AD מול Entra (Azure AD) בסביבה היברידית

בהרבה עסקים יש סנכרון בין AD לבין Entra ID דרך Connect/Cloud Sync. אז הזהות הופכת לדו-ממדית: טעות בהרשאות בענן משפיעה על SaaS, וטעות ב-AD משפיעה על מה שנכנס לסנכרון. אסטרטגיית אימות חזקה בענן (למשל MFA ו-שיטות אימות מתקדמות) לא מבטלת את הצורך בהקשחת AD, היא משלימה אותה.

טעויות נפוצות שרואים בשטח

• אותו סיסמה / אותו מנהל מקומי בכל התחנות.
• VPN מלא לכל הרשת במקום גישה ממוקדת לשרתים.

• חשבונות שירות עם סיסמה שלא מתחלפת שנים.
• RDP פתוח לבקרי דומיין מהאינטרנט (גם אם "יש סיסמה חזקה").

• גיבוי שלא נבדק, עד יום אחד שצריך אותו באמת.

סיכום קצר

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

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