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