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

תוֹכֶן

• 1. התמודדות עם קבוצות מקוננות
• 2. מעבר ל- RBAC מרמת ACL
• 3. ניהול מחשבים
• אין באגים, אין מתח - המדריך השלב אחר צעד שלך ליצירת תוכנה לשינוי חיים מבלי להרוס את חייך
• 4. טיפול במנעולי חשבון משתמש
• 5. העלאת הרשאה וזחילת הרשאה

מקור: Tmcphotos / Dreamstime.com

להסיר:

למדו חמישה אזורים עיקריים ב- AD העלולים לדרוש התערבות תוכנה של צד שלישי.

יתכן ואף קריטי יותר לארגון שלך מאשר היישום המוערך ביותר שלך או הקניין הרוחני המוגן ביותר שלך הוא סביבת ה- Active Directory (AD) שלך. Active Directory הוא מרכזי באבטחת הרשת, המערכת, המשתמש והאפליקציה שלך. היא שולטת בבקרת הגישה של כל האובייקטים והמשאבים שבתשתית המחשוב שלך ובעלות משמעותית הן במשאבי אנוש והן במשאבי חומרה הנדרשים לניהולו. ותודה לספקי תוכנה של צד שלישי, אתה יכול להוסיף גם מערכות לינוקס, UNIX ו- Mac OS X לרפרטואר המשאבים המנוהלים של AD.

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

1. התמודדות עם קבוצות מקוננות

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

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

למנהלי מערכות היה האני מאמין "נהל קבוצות, לא יחידים" הלם במוחם במשך שנים, אך ניהול קבוצות מוביל בהכרח לקבוצות מקוננות והרשאות מנוהלות בצורה לא טובה. (למידע נוסף על Softerra Adaxes אבטחה מבוססת תפקידים כאן.)

2. מעבר ל- RBAC מרמת ACL

מעבר מרשימת ניהול בקרת גישה ממוקדת על ידי משתמשים (ACL) לסגנון ניהול מודעות AD לשיטה הארגונית יותר של בקרת גישה מבוססת תפקידים (RBAC) נראה כאילו זו תהיה משימה קלה. לא כך עם AD. ניהול ACLs קשה, אך מעבר ל- RBAC הוא גם לא הליכה בפארק. הבעיה עם רשימות ACL היא שאין מיקום מרכזי בספירה לניהול הרשאות, מה שהופך את הממשל למאתגר ויקר. RBAC מנסה להקל על הרשאות וכשלי גישה על ידי טיפול בהרשאות גישה לפי תפקיד ולא על ידי פרט, אך זה עדיין נופל בגלל היעדר ניהול הרשאות ריכוזי. אבל, ככל שכואב למעבר ל- RBAC, זה טוב בהרבה מניהול ידני של הרשאות על בסיס משתמש למשתמש באמצעות רשימות ACL.

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

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

3. ניהול מחשבים

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

אין באגים, אין מתח - המדריך השלב אחר צעד שלך ליצירת תוכנה לשינוי חיים מבלי להרוס את חייך

אתה לא יכול לשפר את כישורי התכנות שלך כאשר לאף אחד לא אכפת מאיכות התוכנה.

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

4. טיפול במנעולי חשבון משתמש

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

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

5. העלאת הרשאה וזחילת הרשאה

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

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

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

תוכן זה מובא אליך על ידי השותף שלנו, Adaxes.