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