הפרויקט הסתיים. מה קורה לגישה של הספק?
בסיום פרויקט בודקים שהמערכת נמסרה, שהתקלות הפתוחות תועדו ושיש למי לפנות בתקופת התמיכה. כדאי להוסיף לרשימה הזאת עוד בדיקה: אילו הרשאות נשארו לספק, ולמה הן עדיין נחוצות.
גישה שניתנה לצורך ההקמה יכולה להישאר פעילה גם אחרי שהעבודה הסתיימה. חשבון אורח, הרשאת ניהול בענן, חיבור מרחוק או מפתח API לא בהכרח מתבטלים כשמאשרים את החשבונית האחרונה. כדי לסגור אותם בצורה מסודרת, צריך לחבר בין מי שיודע שהפרויקט הסתיים לבין מי שמנהל את ההרשאות בכל מערכת.
המטרה היא לסיים את הגישה שאין בה עוד צורך, ולהגדיר מחדש כל גישה שנדרשת להמשך השירות. אפשר לעשות זאת בלי לפגוע בתמיכה, בתנאי שמבררים מראש מה צריך להמשיך לעבוד ומי אחראי עליו.
מי מודיע שהעבודה הסתיימה
מנהל הפרויקט יודע שהמסירה הושלמה. הרכש מכיר את תאריך סיום ההתקשרות. צוות ה־IT יודע אילו חשבונות הוא פתח. אבל לא תמיד יש אדם אחד שמחבר את המידע הזה ומוודא שהטיפול נסגר.
לכן כדאי לקבוע אחראי פנימי לסיום הגישה. הוא לא חייב לבצע את השינויים בעצמו. תפקידו לוודא שבעלי המערכות קיבלו הודעה, שהפעולות בוצעו ושכל חריגה אושרה. גם אם הספק מנהל חלק מהסביבה, הארגון צריך לדעת מי מטעמו מאשר את המשך הגישה.
כבר בהזמנת העבודה אפשר לקבוע מה מפעיל את התהליך: מסירה סופית, סיום חוזה, החלפת ספק או סיום תפקיד של אדם מסוים בצוות הספק. תאריך בחוזה עוזר, אבל צריך גם דרך להעביר את האירוע לאנשים שיכולים לפעול.
מתחילים מרשימת הגישות
רשימת משתמשים בספריית הזהויות היא נקודת פתיחה. כדאי להשוות אותה גם לרישומים של בעלי המערכות, כי גישה יכולה להינתן בכמה מקומות ובכמה צורות:
- חשבונות אישיים של עובדי הספק וחשבונות אורח.
- הרשאות ניהול, קבוצות גישה וחשבונות מקומיים במערכות.
- חיבורי VPN וכלים לשליטה או לתמיכה מרחוק.
- מפתחות API, חשבונות שירות וחיבורים בין מערכות.
- שיתופי קבצים, מאגרי קוד וסביבות בדיקה ששימשו בפרויקט.
לכל פריט צריך להיות הסבר: לאיזו מערכת הוא שייך, מי משתמש בו, איזו פעולה הוא מאפשר ומי מאשר אותו. יש חשיבות מיוחדת לחשבון שירות שממשיך להפעיל תהליך עסקי. לפני שמבטלים אותו, צריך לברר את התלות ולהסדיר בעלות וגישה חלופית לפי הצורך.
ההסתכלות הזאת תואמת את בקרת ניהול החשבונות של CIS, שמתייחסת גם לחשבונות משתמש, גם לחשבונות מנהל וגם לחשבונות שירות. בדיקה שמתמקדת רק בשמות העובדים עלולה להשאיר חלק מהגישה מחוץ לרשימה.
כשעדיין צריך תמיכה
לפעמים יש סיבה טובה להשאיר לספק גישה אחרי המסירה. יש תקופת אחריות, טיפול בתקלה או שירות תחזוקה מתמשך. במקרה כזה צריך להתאים את ההרשאה לעבודה שנותרה.
כדאי לתעד מה נדרש, מי מאשר, לאילו מערכות ניתן להיכנס ומתי בודקים את הצורך שוב. גישת ניהול רחבה שנדרשה בהקמה לא בהכרח נחוצה לתמיכה שוטפת. כשאפשר, מגדירים תוקף מוגבל או הפעלה של הגישה רק לאחר אישור למשימה מסוימת.
אם אין תאריך סיום ידוע, קובעים לפחות מועד בדיקה ואחראי להחלטה. הניסוח ״נשאיר למקרה שנצטרך״ לא מסביר מי רשאי להשתמש בגישה ובאילו תנאים. לעומת זאת, אישור מתועד עם היקף מוגדר מאפשר להמשיך לעבוד בלי לאבד את השליטה בהרשאות.
בודקים מה השתנה בפועל
סגירת קריאה אינה מוכיחה שכל נתיבי הגישה טופלו. צריך לבדוק את המערכות שנכללו ברשימה ולשמור תיעוד שמתאים לפעולה: מצב חשבון לאחר השבתה, שינוי הרשאה, ביטול מפתח או רישום של ביטול חיבור.
חשוב גם להבין את התנהגות המערכת. בחלק מהיישומים, השבתת החשבון המרכזי אינה מסיימת מיד חיבור שכבר נפתח. התיעוד של Microsoft בנושא ביטול גישה מסביר שחיבורים וטוקנים יכולים להתנהג אחרת, ושיישום עשוי לנהל חיבור פעיל משלו. לכן הבדיקה צריכה להתייחס גם לחיבורים קיימים ולחשבונות שנוצרו ישירות ביישום.
מפתחות וסודות דורשים טיפול נפרד. אם אין בהם עוד צורך, יש לבטל אותם. אם השירות ממשיך לפעול והספק הכיר סוד שמשמש אותו, צריך לתכנן החלפה או מעבר מבוקר שלא ישבית את השירות. הנחיות OWASP לניהול סודות מפרידות בין יצירה, החלפה, ביטול ופקיעה. החלפת סיסמה אחת לא מטפלת אוטומטית בכל אלה.
שומרים תשובה שאפשר לבדוק אחר כך
בסוף התהליך כדאי לשמור רישום קצר: אילו גישות נבדקו, מה נסגר, מתי בוצע השינוי ומי אימת אותו. לצד הרישום שומרים הפניה לראיות ואת החריגים שאושרו, עם בעלים ומועד בדיקה. אין צורך לשמור סיסמאות או סודות בתוך מסמך הסגירה.
צריך להתייחס בנפרד גם למידע ולנכסים שנשארו אצל הספק. בררו אילו קבצים, עותקים ותיעוד נמסרו, ומה סוכם לגבי החזרה, שמירה או מחיקה שלהם. אשרו את הטיפול לפי ההסכם וההוראות החלות על הארגון, במקום להניח שביטול החשבון מחק גם מידע שכבר הועתק.
מכניסים את הסגירה לתהליך מראש
קל יותר לבצע את הבדיקה הזאת כשכבר בתחילת הפרויקט מתעדים גישות, בעלי תפקידים ותנאי סיום. NIST CSF 2.0, בסעיף GV.SC-10, מתייחס במפורש לפעולות שיש לתכנן גם לאחר סיום קשר עם ספק. זו נקודת ייחוס שימושית לבניית התהליך, בלי להניח שכל מסגרת חלה על כל ארגון.
אפשר להתחיל מפרויקט אחד שהסתיים ולבדוק אם ניתן להסביר את כל הגישות שנותרו ממנו. אם הרשימה חלקית או שהאחריות אינה ברורה, יש כבר משימה מוגדרת לשיפור.
שאלות שעולות בסיום ההתקשרות
האם צריך לבטל כל גישה מיד בסיום הפרויקט?
צריך לסגור גישה שאין בה עוד צורך. גישה שנדרשת לתמיכה או להפעלת שירות יכולה להישאר בכפוף לאישור, היקף מוגדר ומועד בדיקה. לפני השינוי בודקים תלות בתהליכים פעילים.
איזה תיעוד כדאי לשמור?
רשימת הגישות שנבדקו, הפעולות שבוצעו, מועדי הביצוע והאימות, והפניות לראיות. גישה שנשארה פעילה צריכה להופיע כחריגה מאושרת עם אחראי ומועד בדיקה.
במסגרת שירותי ה־CISO של Cybecs אפשר לבחון את התהליך, להגדיר אחריות ובקרות, ולבדוק את הראיות לסגירת הגישה בהתאם להיקף שסוכם. את השינויים הטכניים מבצעים הצוותים המורשים בארגון או ספק ה־IT. אפשר לפנות אלינו כדי להבין מה כדאי לבדוק אצלכם קודם.