התחילו מתהליך עסקי ומי שמחזיק במפתחות
רשמו איך מגיעה פנייה או הזמנה, מי מטפל בה ובאילו מערכות. ליד כל נכס ציינו בעלות עסקית, מנהל מורשה, ספק ותלות. דומיין שנרשם בחשבון פרטי של ספק או דואר שחזור שאין לעסק גישה אליו יכולים להקשות על המשך תפעול, גם אם האתר נראה מוכן.
NIST SP 1300 מציע לעסקים קטנים למפות נכסים, אחריות וסיכון בהקשר הפעילות. אין הכרח להתחיל מרשימת מוצרים ארוכה. אפשר להתחיל מהשאלות שהעסק מסוגל לבדוק ומהפערים שמונעים שליטה או התאוששות, ולתעד מי אחראי להשלמה.
הכינו שערי בדיקה לפני ההשקה
הטבלה היא מסגרת עבודה מקורית. היא אינה רשימת דרישות חוק או אישור מוכנות גורף. לכל שער קובעים בדיקה, מאשר ופערים ידועים. אם הוחלט להשיק בהיקף מצומצם, מתעדים מה פעיל ומה עדיין אינו זמין במקום להניח שהכול נכלל.
| שער | מה צריך לדעת | ראיית בדיקה |
|---|---|---|
| בעלות | מי שולט בדומיין, באחסון ובחיוב | חשבונות ומורשים ידועים |
| גישה | מי יכול לנהל ומה קורה באובדן | אימות ודרך התאוששות מתאימים |
| פנייה או הזמנה | מהו המסלול ומי מקבל | ניסיון סינתטי ביעד מאושר |
| מידע | מה נאסף ולמי יש גישה | מפת עותקים והרשאות |
| התאוששות | מה נשמר ואיך מחזירים | בדיקה מבודדת ותוצאה |
| תפעול | מי מתחזק ומי מטפל בכשל | בעלים וערוץ הסלמה |
סדרו זהויות ודואר לפני הפצת גישה רחבה
בחרו מי מנהל את סביבת הדואר ואילו חשבונות אישיים ותפקידים נדרשים. הפעילו מנגנוני אימות והתאוששות בתכנון שמתאים לספק, בלי להפיץ סיסמת מנהל לכל גורם. מדריכי Microsoft ו-Google מדגישים הגנת מנהלים ומשתמשים, אך היכולות משתנות בין סביבות ורישוי.
רשמו גם מי מחזיק ברשומות DNS ואילו מערכות שולחות בשם העסק. דואר שאפשר לשלוח ממנו אינו הוכחה שכל המקורות הוגדרו או שכל בקשת תשלום אמיתית. הרחבת שימוש ב-CRM, דיוור או חשבוניות צריכה עדכון מיפוי ובדיקת מסלול, לא רק פתיחת משתמש חדש.
בדקו אתר, מידע וחיבורים עם נתוני ניסיון
לפני פתיחת טופס או חנות הגדירו שדות נחוצים, נמענים ויעדי אוטומציה. ודאו שאין העתקה לא מתוכננת למדידה או ללוגים. בדיקת קבלה מתארת מה נשלח ומה חזר, ומשתמשת במידע סינתטי ככל האפשר. לא מבצעים חיוב אמת או משלוח ללקוח לצורך הוכחת תקינות בסיסית.
אם ספק מקים את האתר, בקשו מסירה של תפקידים, רכיבים, מקורות רישוי ודרך חזרה משינוי. עבודה שהסתיימה מבחינת עיצוב יכולה עדיין להשאיר תחזוקה, הרשאות או גיבוי בלי בעלים. את הפערים צריך לראות לפני העברת המערכת לשגרה.
דוגמה: ההשקה תוכננה אך שחזור החשבון תלוי באדם אחד
התרחיש להמחשה בלבד. האתר והדואר עובדים, אבל כל אפשרויות הניהול תלויות במכשיר ובתיבה של ספק יחיד. העסק ממפה בעלות ומתאם גישה חלופית מוגנת לפני מסירה. לא מבטל הרשאות בפתאומיות ולא מנסה לעקוף את מנגנוני הזיהוי של הספק.
בדיקת היכולת להמשיך לנהל אינה מחייבת לנתק חשבון עובד כדי לראות אם ניתן לשחזרו. מגדירים תרחיש מורשה ומתאים למוצר. המסמך צריך לתאר מי יכול לפעול ואילו תנאים דרושים, בלי לכלול קודים סודיים או מפתחות.
הגדירו שגרה קצרה שאפשר להחזיק לאורך זמן
לכל משימה חוזרת קבעו גורם מבצע, טריגר או תדירות ותוצר: סקירת גישה, עדכון רכיב, בדיקת גיבוי ובירור כשל. יש לעדכן את הבסיס כשעובד, ספק או מערכת מתווספים. טיפול באירוע הוא מסלול שצריך להגדיר, ואינו נכלל אוטומטית בעבודת ההקמה.
CyberFixCrew היא חברה ישראלית לעסקים המתמחה באבטחת אתרים ותשתיות דיגיטליות. אפשר לתאם בדיקת מצב ותוכנית עבודה לפי השירותים הקיימים. ההיקף לא מחליף ייעוץ מקצועי אחר שנדרש לעסק, ואין בכך הבטחה להשקה נטולת סיכון או לכיסוי כל מערכת.
