הגדרת משתמשים ב-Linux: איפה נשברת הפרדת הגישה
חשבון משותף בשרתים נראה נוח בדיוק עד התקרית הראשונה. כל הפעולות ביומן חתומות באותו uid, ואי אפשר לקבוע מי בדיוק הפעיל מחדש את מסד הנתונים או תיקן את התצורה — הבירור נמשך ימים, ואת המבצע מחפשים לפי סימנים עקיפים. אם חשבון כזה עוד מונח בהערות אצל כל הצוות, לבטל אותו מהיר יותר מלהבין למי יש אותו.
התקלה הטיפוסית השנייה — הרשאות שניתנו "לזמן מה". כלל ב-sudo ללא בקשת סיסמה נשאר בקובץ לאחר סגירת המשימה, עובד נשכח בקבוצה עם הרשאות לקונטיינרים, והמפתח הציבורי של מי שעזב ממשיך לשבת ב-authorized_keys בעשרות מארחים בבת אחת. הביטול לא היה חלק מהתהליך, ולכן הרשאות מיותרות חיות שנים וצפות רק בבדיקה או אחרי תקלה.
מכאן הבעיה השלישית: ביקורת גישה אינה עונה על שאלה פשוטה — מי ומתי קיבל גישה לשרת. מזהים מספריים נעשים בהם שימוש חוזר לאחר מחיקת רשומה, שורות יומן ישנות מתחילות להצביע על אדם אחר, ותקופת שמירת הלוגים לעיתים קרובות קצרה מתוחלת החיים של המפתח. הפרדת הרשאות גישה מפסיקה להיות פורמליות: בלי חשבונות אישיים החקירה מתאפסת.
נבחן כיצד זה נסגר: חשבונות אישיים עם תפקידים דרך קבוצות, תוחלת חיים מוגבלת להרשאות, בדיקה תקופתית של מפתחות וכללי ביקורת שלפיהם ניתן לאשר או להפריך גישה לפי היומן.
מה נותן סדר בחשבונות ובהרשאות גישה
מודל גישה אחיד אינו עוסק בנוחות הניהול, אלא במספרים צפויים: כמה זמן תופסת הענקת הרשאות וביטולן, כמה חשבונות מורשים קיימים במלאי, והאם ניתן לשחזר את תמונת התקרית מיומני הכניסה.
הענקה וביטול הרשאות — פעולה אחת לכל המלאי
ההרשאות מחולקות בקבוצות, ולא ידנית לפי שרתים — המנגנון המובנה של Linux מועבר למודל גישה אחיד. העובד נכנס לקבוצה הנדרשת ומקבל הרשאות בכל מקום שבו היא מוצהרת; פיטורים או החלפת תפקיד הם הסרה מהקבוצה, והגישה נעלמת בכל הצמתים בבת אחת. שיעור השרתים תחת נוהל אחיד שואף ל-100%, והביטול מפסיק להיות תלוי בשאלה אם התורן זוכר מכונה מסוימת.
חשבונות מורשים — בודדים, תוחלת החיים מוגבלת
במקום חשבון root משותף בכל מארח — רשומות אישיות וכללי sudo לפי תפקידים, ולעבודות חד-פעמיות — גישה זמנית עם תאריך סיום. מספר החשבונות המורשים מצטמצם לבודדים, וכל כניסה תחתם ניתנת להסבר. תוחלת החיים של חשבון קבלן או מתלמד נקבעת מראש: הרשומה נכבית מעצמה, ואין צורך להזכיר לאף אחד عنها.
התקרית נבחנת לפי יומנים
תיעוד כניסות, קריאות sudo ועריכות בקבוצות עובר לאיסוף מרוכז, שבו הרשומה משויכת לאדם ולא לכתובת המכונה. בירור השאלה "מי ומתי קיבל גישה לצומת הזה" תופס דקות במקום יום של התכתבות עם הצוות.
הפרדת גישה ב-Linux: רשומות מקומיות, ספרייה, דומיין
סכימת החשבונות נקבעת לא לפי גודל המלאי, אלא לפי המקום שבו נמצא מקור האמת ומי אחראי לביטול הגישה. רשומות מקומיות ב-/etc/passwd וב-/etc/group עובדות כל עוד מדובר בעשרות מכונות: פיטורי עובד הופכים לסיבוב בכל המארחים, המזהים מתפצלים בין סביבות, והמורשת ב-sudoers יש לבדוק ידנית.
להלן שלוש סכימות שבהן באמת בוחרים. לכל אחת מחיר תמיכה משלה, והוא נראה רק בשנה השנייה להפעלה.
| סכימה | מתי מתאימה | מה לתחזק בכוחות עצמך |
|---|---|---|
| חשבונות וקבוצות מקומיים | 1–5 מארחים, סביבות מבודדות, חשבונות שירות למשימה מסוימת | סנכרון מזהים, ביטול גישה ידני, בירור אי-התאמות בכללי העלאת הרשאות, מלאי "מי הוגדר היכן" |
| שירות ספרייה | 10+ מארחים, דרישות אחידות לסיסמאות, כניסת SSH משותפת לצוות | זמינות השירות עצמו, רפליקות, גיבוי ושחזור הספרייה, העברת הסכימה בעת עדכון |
| אימות דומיין | המלאי כבר בדומיין, יש צורך במדיניות קבוצתית ובכניסה אחידה | חיבור בין חשבונות דומיין לחשבונות מקומיים, מטמון נתונים לעבודה ללא קשר לבקר, איתור תקלות בהתאמת קבוצות |
בפועל כמעט תמיד מתקבלת סכימה היברידית: הדומיין אחראי לאנשים ולקבוצות, והרשומות המקומיות — לשירותים שאינם זקוקים לדומיין (דמונים, גיבוי, ניטור).
המפתח כאן הוא לקבוע מראש טווחי מזהים לכל תפקיד, אחרת עם חיבור מארח לספרייה הקבצים הקיימים יחליפו בעלים והאפליקציה תפסיק לקרוא את הנתונים שלה. התנאי השני — ניהול קבוצות באמצעות כללים, ולא על ידי עריכת קבצים במארח: אז ביטול הגישה נבדק בפקודה אחת ונשאר ביומן הביקורת.
כיצד מתבצעת ההטמעה: מביקורת רשומות ועד לנוהל
ההטמעה מתחילה לא בעריכת קונפיגים, אלא בתמונה מלאה: במלאי השרתים חשבונות מצטברים, גישה "לזמן מה" נשארת לתמיד, עם פיטורים חוסמים כניסה למערכת, אבל שוכחים מפתחות ב-authorized_keys, כללי sudo ומשימות ב-cron. לכן הסדר הפוך מהרגיל: תחילה מתעדים מה קיים, אחר כך מעצבים תפקידים, ורק לאחר מכן משנים את התצורה.
- ביקורת חשבונות. אוספים רשימת משתמשים וקבוצות מהמארחים, מנתחים
sudoers, תוקף סיסמאות, מפתחות וחשבונות שירות, ומצליבים עם עובדים אמיתיים ובעלי תהליכים. - מלאי הרשאות. בונים מטריצה "מי — איזו קבוצה — איזה כלל sudo — באילו מארחים", ומסמנים הרשאות עודפות ללא סיסמה וגישה לספריות שאינן זקוקות לה.
- סכימת גישה. מנסחים תפקידים — מנהל, תורן, מפתח, חשבון שירות — וכללים: הרשאות ניתנות בקבוצות ולא אישית, כניסת root בסיסמה חסומה, ומקור חשבונות מרוכז הוא חובה.
- הגדרה. מעבירים את הסכימה לתיאור תצורה, כדי שהגישה תשחזר במארח חדש ולא תוגדר ידנית: קבוצות, מדיניות sudo, הגבלות סשנים, רישום פעולות ביומן המערכת.
- בדיקה בסביבת בדיקות, ואחר כך בפרודקשן. בודקים את תחביר הכללים לפני היישום, פורסים בקבוצות שרתים תוך שמירת הגרסה הקודמת של התצורה — החזרה לאחור תופסת דקות.
- בדיקה לאחר ההטמעה. עוברים על בדיקות מנקודת המבט של כל תפקיד: הפקודה הנדרשת עוברת, המיותרת נחסמת, וניסיון להעלות הרשאות נרשם ביומן. בפלט — דוח "לפני ואחרי" לפי מספר הרשומות והכללים.
- מסירת הנוהל. מוסרים מסמך: כיצד לפתוח וכיצד לסגור חשבון, מה לעשות עם פיטורים, מי ובאיזו תדירות בוחן מחדש הרשאות; מעבירים הדרכה לאחראים ומוסרים תבניות בדיקה.
תצורות, סכימות גישה ונוהלים לחשבונות
הגדרת חשבונות אינה מסתיימת בכניסה עובדת לשרת, אלא בסט ארטיפקטים שלפיהם הצוות שלכם יוכל לנהל גישות בלעדינו. הכול נמצא באותו מאגר כמו תצורת התשתית — עם היסטוריית שינויים ואפשרות להחזיר עריכה לאחור.
- קובצי תצורה — כללי כניסה, הגבלות sudo והגדרות חיבור לספרייה, מסודרים לפי תפקידים ומארחים, ולא תבנית אחת משותפת לכל המלאי.
- מפת תפקידים וקבוצות — טבלה "תפקיד → קבוצות → מארחים → רמת גישה", שממנה רואים מיד מי ולאן נכנס.
- מדיניות סיסמאות ומפתחות — תוחלת חיים, מורכבות, חסימה לאחר ניסיונות כושלים, דרישות למפתחות ואימות דו-שלבי לחשבונות ניהול.
- נוהל הענקה וביטול הרשאות — בקשה, מאשר, תוקף הגישה הזמנית, סדר פעולות עם פיטורים והעברה.
- סדר בחינה מחדש של הרשאות — הצלבה תקופתית של חשבונות פעילים עם נתוני משאבי אנוש, וסריקה נפרדת של חשבונות שירות ומפתחות שירות.
- תיעוד חשבונות — היכן תצורת האמת, כיצד לבדוק אי-התאמה במארח, מה לעשות כאשר כניסה נכשלת.
- הוראות לתמיכה — תרחישים טיפוסיים: עובד עזב, החליף תפקיד, איבד מפתח, נדרשת גישה חד-פעמית ליום.
כל סעיף נבדק: פורסים גישות בסביבה נקייה בדיוק לפי התיעוד ובודקים היכן הוא לא הספיק. בדרך כלל אחרי ריצה כזו ההוראות מתקצרות, ומפת התפקידים נעשית מדויקת יותר.
מקרה בוחן: מודל גישה אחיד במקום רשומות שהתפזרו
מה היה לפני העבודה
אלינו הגיעה רשת קמעונאית עם מלאי של 40 שרתים, שבהם הגישה ישבה בקבצים מקומיים: לכל מנהל רשומה משלו ב-sudoers או בקבוצת wheel, סיסמאות נשלחו במסנג'רים, ומפתחות SSH לא בוטלו לאחר פיטורים. המלאי הראה 340 רשומות עם הרשאות מוגברות — חלקן היו שייכות לקבלנים שכבר שנה לא נגעו בתשתית.
בירור של תקרית אחת עם קריסת שירות ארך שלושה ימים: לפי הלוגים אי אפשר היה להבין של מי החשבון שהריץ את הפקודה ומה בדיוק השתנה בדיסק.
מה שינו ומה התקבל
החשבונות אוחדו לספרייה אחת, וההרשאות תוארו בתפקידים לפי תחומי אחריות, ולא לפי אנשים. הרשאות קבועות הושארו רק למשמרת התורנית, לסוכני הניטור ולחשבונות שירות; לאחרים נותנים הרשאות זמניות — ל-4 שעות, עם ציון המשימה ותפוגה אוטומטית. סיסמאות הוסרו לטובת מפתחות, וכל פעולה עם הרשאות מוגברות נרשמת ביומן משותף עם שיוך לאדם מסוים.
חשבונות מורשים קבועים נותרו 27 במקום 340. הענקת גישה תופסת 15 דקות לפי בקשה עם אישור, והביטול — דקות: מנתקים את החשבון בספרייה, והוא מפסיק לעבוד בכל השרתים בבת אחת, בלי סיבוב ידני בין מכונות. בירור התקרית הצטמצם לשעה וחצי: רואים מי הריץ את הפקודה, מאיזו מכונה ומה היה לפני ואחרי.
בנפרד עיגנו נוהל: הצלבה רבעונית של הספרייה עם חיבורים בפועל, בחינה מחדש של תפקידים בעת החלפת תפקיד, ובירור חובה של כל מקרה של העלאת הרשאות מחוץ לבקשה.
מה לעשות אם החשבונות כבר התפזרו בין השרתים?
אי אפשר למחוק חשבונות מקומיים ולהפעיל בבת אחת ספרייה מרוכזת: בשרתים כבר מקובעים בעלי קבצים עם UID מסוימים, מפתחות גישה בספריות בית, כללי sudo עם חריגים נקודתיים ומשימות שירות לפי לוח זמנים.
החלפה גורפת שוברת לא רק כניסת אנשים, אלא גם את התקשורת בין שירותים — גיבויים, ייצוא ודיוור נעצרים בלי שגיאה ברורה ביומנים.
הצעד הראשון בתשתית חיה הוא מיפוי, לא עריכות. אוספים מכל המארחים משתמשים וקבוצות מקומיים, את ה-UID שלהם, הרכב הקבוצות, הרשאות sudo, בעלי ספריות עם נתונים ומפתחות גישה פעילים.
עושים זאת עם כלי איסוף עובדות (במקרה שלנו — Ansible), ובפלט — טבלה מסכמת שבה מיד רואים את מי אסור לגעת בו בכלל, ואת מי אפשר להעביר בגל הראשון.
הלאה — מעבר הדרגתי. משתמשים חדשים פותחים בספרייה, ורשומות מקומיות משאירים כל עוד השם, ה-UID והקבוצות תואמים: קבצים שנוצרו לפני ואחרי ההעברה נקראים באותה צורה — זוהי תאימות לאחור, שבגללה פורשים את המעבר על פני שבועות.
כללי sudo מעבירים בקבצים נפרדים לספריית inclusions, ולא על ידי עריכת קובץ משותף: אז שגיאה בשורה אחת לא מנתקת sudo לכולם בבת אחת.
חשבונות אפליקציות וחשבונות שירות משאירים מקומיים — הם קשורים ל-UID קבוע, וההעברה שוברת גישה לנתונים והרשאות על ספריות. לאחראים בזמן המעבר משאירים כניסה מקומית חירום עם סבב סיסמאות ורישום ביומן.
את המנגנון הישן מנתקים רק לאחר הצלבה: אם לפי חשבונות מקומיים אין כניסות בתקופה מוגדרת, מעבירים אותם לארכיון.
שאלות טכניות בנושא חשבונות והרשאות גישה
חשבונות והרשאות הם תחום שבו שינויים מצטברים שנים ונדירים בבחינה. להלן תשובות לשאלות שעולות לרוב בבירור גישה ובמסירת נוהל.
האם אפשר להשאיר חשבון משותף?
רק אם הוא נדרש טכנית. רשומה אישית עם כללי sudo נקודתיים בקובץ נפרד מותירה עקבה אישית ביומנים, והפעולות נשארות ניתנות לשחזור. חשבון התחברות משותף, אם אי אפשר בלעדיו, מגבילים במפתח ובכתובת המקור.
כיצד לפתוח חשבונות שירות?
בלי מעטפת כניסה ועם מינימום הרשאות: מעטפת nologin, גישה לספריות הנדרשות דרך קבוצה, ולא דרך הרשאת כתיבה לכולם. כך השירות לא הופך לנקודת כניסה מוכנה לתוקף.
איך לתת גישה לקבלן בלי לאבד שליטה?
חשבון נפרד, כניסה במפתח, סט פקודות מוגבל דרך sudo ותוקף. לאחר העבודה הגישה נחסמת, המפתח מבוטל, והפעולות נשארות ביומן.
האם אפשר לתת הרשאות לזמן מוגבל?
כן, זהו מצב תקני: כללי ההענקה מוציאים לקבצים נפרדים, מפעילים ומכבים אותם לפי לוח זמנים, ותוחלת החיים של החשבון עצמו מוגבלת בפרמטר נפרד.
למי שייך הנוהל לאחר המסירה?
לכם. מוסרים מטריצת גישה, סדר הענקה וביטול הרשאות, רשימת בדיקה בעת פיטורים והתצורות עצמן עם הערות — ניתן לבצע ולשנות את הנוהל ללא מעורבותנו.
ספרו לנו על מלאי השרתים שלכם — נחזור עם תוכנית
כדי שההערכה תהיה עניינית ולא לפי תבנית, די בכמה נתוני פתיחה. צריך להבין מאין מגיעים החשבונות, איך בנויה הכניסה לשרתים והיכן מצטברים האירועים — אז ביקורת הגישה מחושבת לפי תמונה אמיתית, ולא לפי ניחושים.
מה לשלוח כדי להתחיל דיון:
- מקור החשבונות: קבצים מקומיים, ספריית LDAP או דומיין Active Directory, וכן אם יש סכימות היברידיות.
- כללי כניסה: הגדרות SSH — איסור סיסמה לחשבונות שירות, הגבלה לפי קבוצות, האם כניסה ישירה של סופר-משתמש מושבתת.
- רשימת תפקידים מורשים: מי ודרך מה מקבל הרשאות מוגברות, והאם יש חריגים חד-פעמיים ב-sudoers.
- מדיניות מחזור חיים: תוקף סיסמה, חסימה לאחר ניסיונות כושלים, סדר פיטורים וביטול מפתחות.
- לאן נכתבים יומני כניסה ושינוי הרשאות: קבצים מקומיים, שרת איסוף ייעודי או מערכת חיצונית.
- מלאי: כמה שרתים, אילו קבוצות תמונות, והאם יש מתחמים עם דרישות נפרדות לגישה.
בתגובה נחזיר דברים קונקרטיים שלפיהם אפשר לקבל החלטה. מפת גישה: מי הולך לאן, דרך איזו קבוצה, והיכן ניתנו הרשאות מיותרות. גבולות עבודה עם רשימה מפורשת של מה כלול ומה נשאר בצד שלכם, וסדר בדיקה: רשימת ביקורת לכל שרת, אופן החזרה לאחור ונקודה שבה השינויים מתועדים.
מסירת התוצאות — תצורות, סכימת תפקידים, נוהל הענקה וביטול גישה והוראה קצרה למשמרת התורנית. תארו את המשימה — נחזור עם הערכה ותוכנית.