בעלי חנויות רבים מטפלים באבטחה רק אחרי שמשהו קורה, ובדרך כלל זו לא פריצה מתוחכמת אלא מייל שנראה אמין שמישהו לחץ עליו. ההנחה שהפלטפורמה מטפלת בהכל נכונה חלקית, כי החוליה שנשברת ראשונה היא כמעט תמיד ההרשאות והסיסמאות של הצוות. אבטחת חנות אינטרנטית מתחילה בדיוק שם, ברשימת המשתמשים ובהרגלים היומיומיים של מי שנכנס לממשק. זו לא עבודה של מומחה תשתיות אלא סדרה של החלטות פשוטות שמישהו צריך לקבל ולתחזק.
להבין מה באמת מסכן אבטחת חנות אינטרנטית
כשמדברים על אבטחה הדמיון הולך לשרתים, לחומות אש ולקוד. בפועל, ברוב המקרים שמגיעים אליי לטיפול נקודת הכניסה הייתה חשבון של אדם, לא פרצה טכנית. מישהו השתמש באותה סיסמה בכמה מקומות, מישהו נשאר עם הרשאת מנהל שנה אחרי שסיים לעבוד, מישהו לחץ על קישור בטלפון בין שתי משימות.
זאת אומרת שהמאמץ צריך ללכת למקום שבו הסיכון באמת יושב. הפלטפורמה מטפלת בהצפנה, בעדכוני מערכת ובחסימות ברמת השרת. מה שהיא לא יכולה לעשות בשבילכם זה להחליט מי מקבל גישה, לכמה זמן, ומה קורה כשאותו אדם עוזב.
שלושת הווקטורים שחוזרים כמעט תמיד:
- חשבון עם סיסמה שדלפה במקום אחר לגמרי ומשמשת גם בממשק הניהול
- מייל פישינג שמוביל לעמוד התחברות מזויף שנראה כמו המערכת האמיתית
- הרשאות עודפות שנשארו פתוחות לאנשים שכבר לא צריכים אותן
שלושתם מטופלים בהחלטות ניהוליות ולא בקוד, וזו בדיוק הסיבה שהם נשארים פתוחים כל כך הרבה זמן. מי שמסדר את שלושת אלה מכסה את רוב התרחישים המעשיים.
יש כאן גם עניין של סדרי גודל. חנות בינונית מייצרת עשרות פעולות ניהול ביום מול כמה משתמשים, וכל אחת מהן היא הזדמנות לטעות קטנה. לא צריך תוקף מתוחכם כדי לנצל את זה, מספיק מישהו שמריץ ניסיונות התחברות אוטומטיים על אלפי חנויות ומחכה שאחת מהן תיפול.
מה שכן, זה גם אומר שההגנה לא חייבת להיות מתוחכמת. ברגע שהחנות שלכם דורשת יותר מאמץ מהממוצע, רוב הניסיונות האוטומטיים עוברים הלאה למטרה קלה יותר. זו לא הגנה מוחלטת אבל היא מסננת את הרוב המכריע של מה שקורה בפועל.
להפעיל אימות דו שלבי על כל משתמש
אימות דו שלבי זה חובה, זה סטנדרט, וככה זה צריך להיות במקור. סיסמה לבדה היא מידע שאפשר לגנוב, לנחש או לקנות, ואילו קוד חד פעמי דורש מהתוקף גישה פיזית למכשיר. זה ההבדל בין דלת עם מנעול לדלת עם מנעול ושרשרת.
הטעות הנפוצה היא להפעיל את זה רק על משתמש הבעלים. תוקף לא מחפש את החשבון החזק ביותר אלא את החלש ביותר, ומשתמש עם הרשאת עריכת מוצרים בלי אימות דו שלבי הוא בדיוק הדלת הזאת. אם יש חמישה אנשים בממשק, כל החמישה צריכים אימות.
סדר הפעולות שעובד בפועל:
- מפעילים אימות דו שלבי על חשבון הבעלים ומוודאים שהוא נכנס בהצלחה
- מייצרים רשימת משתמשים פעילים ועוברים עליהם אחד אחד
- מגדירים אימות לכל משתמש מול המכשיר האישי שלו, לא מול מכשיר משותף
- שומרים קודי גיבוי במקום שלא נגיש מהדפדפן של אף אחד
- קובעים שמשתמש חדש לא מקבל גישה לפני שהאימות מוגדר
השלב האחרון הוא זה שמחזיק לאורך זמן, כי הוא הופך את האימות לחלק מתהליך הקליטה ולא למשימה חד פעמית שנשכחת. בלי זה תמצאו את עצמכם חוזרים על אותה עבודה בכל פעם שמצטרף מישהו.
ההתנגדות שאני שומע הכי הרבה היא שזה מסרבל את הכניסה. בפועל מדובר בכמה שניות ביום, ורוב המערכות זוכרות מכשיר מוכר ולא מבקשות קוד בכל פעם מחדש. זה מחיר נמוך במיוחד ביחס למה שהוא מונע.
נקודה אחת שכדאי לסגור מראש היא מה קורה כשמישהו מאבד את הטלפון. קודי הגיבוי הם התשובה לזה, והם צריכים להיות שמורים במקום פיזי או מוצפן שאינו על אותו מכשיר. מי שמדלג על השלב הזה מגלה את הבעיה בדיוק ביום הכי לא נוח.
לזהות מייל פישינג לפני שלוחצים
איך מזהים מייל פישינג שנראה אמין לגמרי היא השאלה שמגיעה כמעט בכל שיחה על אבטחה, כי הרמה של המיילים האלה עלתה מאוד. הם כבר לא כתובים בעברית שבורה ולא מבקשים מכם להעביר כסף לנסיך זר, אלא מדברים בשפה של המערכות שאתם באמת עובדים איתן.
בודקים את הדומיין המלא של השולח ולא את שם התצוגה, מרחפים מעל הקישור לפני שלוחצים כדי לראות לאן הוא באמת מוביל, ושמים לב לדחיפות מלאכותית שדוחפת לפעול מיד. הכלל הפשוט ביותר הוא לא להיכנס לממשק ניהול דרך קישור במייל אלא להקליד את הכתובת ידנית, וכך גם מייל משכנע מאוד מאבד את היכולת שלו להזיק.
הסימנים שכדאי לאמן עליהם את הצוות:
- דומיין שולח שנראה כמעט נכון אבל עם אות נוספת, חסרה או מוחלפת
- בקשה להתחבר, לאמת פרטים או לאשר תשלום דרך קישור בגוף המייל
- לחץ זמן מלאכותי בסגנון חשבון ייחסם בשעות הקרובות
- קובץ מצורף שלא ביקשתם ולא ציפיתם לו
- פנייה כללית בלי שם ובלי הקשר להזמנה או לפעולה אמיתית
הכלל שמכסה את כולם יחד הוא פשוט: לא נכנסים למערכת דרך מייל. פותחים לשונית חדשה, מקלידים את הכתובת, ובודקים שם אם באמת יש התראה. מייל פישינג מושלם מבחינה עיצובית מאבד את כל הכוח שלו ברגע שאף אחד לא לוחץ על הקישור שבו.
שווה גם להכיר את הגרסאות שמכוונות ספציפית לחנויות. מייל שמתחזה להודעה על עסקה שנדחתה, פנייה שנראית כמו לקוח שמתלונן ומצרף קובץ, או הודעה על חריגה בחשבון הסליקה. כולן מנצלות את זה שאתם באמת מחכים להודעות מהסוג הזה.
זה אומר שהאימון של הצוות חשוב לא פחות מההגדרות. אדם אחד שיודע לעצור שנייה לפני לחיצה שווה יותר מכל מסנן, כי הוא זה שיושב בקצה שאף מערכת לא מגינה עליו.
לא לתת הרשאת מנהל למי שלא צריך אותה
הרשאת מנהל נותנת שליטה על משתמשים, על הגדרות תשלום ועל פרטי החשבון, ורוב האנשים בצוות לא צריכים אף אחת מהיכולות האלה. נותנים אותה כי זה מהיר יותר מלחשוב איזו הרשאה מדויקת נדרשת, ואז היא נשארת שם לנצח.
מה שקורה בפועל זה שכל מכשיר של כל אדם עם הרשאת מנהל הופך לנקודת כניסה שוות ערך לחשבון הבעלים. עובד שמתחבר מהלפטופ הפרטי בבית מרחיב את שטח התקיפה של החנות בלי שאף אחד החליט על זה במודע.
חלוקה שעובדת ברוב החנויות:
- מנהל מלא לבעלים בלבד, ואולי לאדם אחד נוסף שמחליף אותו
- הרשאת הזמנות ומשלוחים לצוות השירות והתפעול
- הרשאת קטלוג ותוכן למי שמעלה מוצרים ומעדכן מחלקות
- הרשאת דוחות בלבד למי שרק צריך לראות נתונים
- משתמש נפרד לכל ספק חיצוני, אף פעם לא שיתוף של חשבון קיים
ההפרדה הזאת לא מאטה אף אחד. היא רק מוודאת שסיסמה שדלפה מגבילה את הנזק לתחום שבו אותו אדם עובד, במקום לפתוח את כל המערכת.
להסיר גישה של ספקים וקבלנים שסיימו
כל חנות עובדת עם אנשים חיצוניים: מעצב, מקדם, מפתח, סוכנות, מישהו שהעלה קטלוג. כולם מקבלים גישה בזמן הפרויקט, וכמעט אף אחד לא מסיר אותה בסוף. אחרי כמה שנים רשימת המשתמשים מכילה חשבונות שאף אחד לא זוכר למי הם שייכים.
הבעיה מתחילה כשאותו ספק עובד עם עשרות לקוחות, מהמכשיר שלו, עם ההרגלים שלו. אתם לא שולטים באבטחה שלו, אבל אתם כן נושאים בתוצאה אם החשבון שלו נפרץ. גישה של ספק צריכה להיות מוגבלת בהיקף ובזמן מהרגע הראשון.
שגרה שמחזיקה סדר לאורך זמן:
- פותחים משתמש ייעודי לכל ספק עם שם שמזהה אותו
- נותנים רק את ההרשאות שהפרויקט באמת דורש
- רושמים ביומן תאריך לבדיקה חוזרת בסיום הפרויקט
- מבטלים את המשתמש ביום שהעבודה נסגרת, לא חודש אחרי
- עוברים על כל רשימת המשתמשים פעם ברבעון
הסקירה הרבעונית היא החלק החשוב, כי היא תופסת גם את מה שנשכח. אפשר לחבר אותה לאותה שגרה שבה אתם עוברים על משימות התחזוקה החודשיות ולא לנהל אותה כמשימה נפרדת שאף אחד לא מגיע אליה.
להפריד חשבון אישי מחשבון עסקי
הרבה חנויות מנוהלות מחשבון מייל אישי, לפעמים כזה שנפתח לפני עשור. אותו חשבון משמש להרשמות לאתרים, לרשתות חברתיות ולשחזור סיסמאות של החנות, וזה בדיוק מה שהופך אותו למטרה. מי שמשתלט על תיבת המייל יכול לאפס סיסמאות בכל מקום אחר.
חשבון עסקי ייעודי לניהול החנות פותר את זה בלי מאמץ מיוחד. הוא לא מופיע בהרשמות אקראיות, הוא לא משותף עם אף אחד, ויש עליו אימות דו שלבי חזק. זה גם מה שמאפשר להעביר בעלות בצורה מסודרת אם משהו משתנה בעסק.
מה שכן, ההפרדה צריכה להיות אמיתית ולא סמלית. סיסמה נפרדת, מכשיר אימות נפרד, ובלי העברה אוטומטית של הכל חזרה לתיבה הישנה. חשבון עסקי שמעביר את כל ההודעות לתיבה האישית לא הפריד כלום.
אותו היגיון חל גם על הדומיין ועל חשבון האחסון. אלה הנכסים שבלעדיהם אין חנות, והם לרוב רשומים על חשבון פרטי של מישהו שכבר לא בתמונה. שווה לבדוק פעם אחת על שם מי הכל רשום ולסדר את זה לפני שצריך.
להגביל גישה לפי כתובת IP כשאפשר
חלק מהפלטפורמות מאפשרות להגדיר שממשק הניהול נפתח רק מכתובות מסוימות. כשהצוות עובד ממשרד קבוע זו אחת ההגנות החזקות ביותר שאפשר להפעיל, כי היא חוסמת ניסיון התחברות עוד לפני שהסיסמה נבדקת בכלל.
ההגבלה הזאת מתאימה לחנות עם צוות שיושב במקום קבוע, ופחות לעסק שכולו נייד. בגדול, אם רוב העבודה נעשית מכתובת אחת או שתיים, שווה להגדיר את זה ולהשאיר נוהל ברור למקרה שצריך גישה חריגה.
לפני שמפעילים, כדאי לוודא כמה דברים:
- שכתובת המשרד קבועה ולא משתנה מדי כמה ימים
- שיש דרך מוסכמת לאשר גישה זמנית כשמישהו עובד מהבית
- שספקים חיצוניים יודעים מראש מה המגבלה
- שמישהו אחד אחראי לעדכן את הרשימה כשמשהו משתנה
בלי האחריות הזאת ההגבלה הופכת לחסם על העבודה עצמה, ואז מישהו מבטל אותה בלחץ של רגע ושוכח להחזיר. עדיף להגדיר נכון פעם אחת מאשר להפעיל ולכבות.
לוודא שיש גיבוי ושיודעים לשחזר ממנו
האם גיבוי אוטומטי של הפלטפורמה מספיק היא שאלה שכדאי לשאול לפני שצריך את התשובה. גיבוי הוא לא רק הגנה מפני פריצה, הוא גם הרשת מתחת לטעות אנוש: מחיקה של מחלקה שלמה, ייבוא שגוי שדרס אלפי מק"טים, עדכון שהשתבש.
הוא נקודת פתיחה טובה אבל הוא לא תשובה שלמה, כי גיבוי שלא ניסיתם לשחזר ממנו הוא הנחה ולא נכס. צריך לדעת כמה אחורה הגיבוי מגיע, מה בדיוק הוא כולל, כמה זמן לוקח לשחזר וכמה מכם יכולים להפעיל אותו בפועל. תרגיל שחזור אחד בשנה על סביבת בדיקה שווה יותר מכל הצהרה על גיבוי יומי.
מי שמנהל קטלוג גדול מכיר את התרחיש הזה היטב. ייבוא אחד לא נכון על חנות עם 2,000 מק"טים יכול למחוק שיוך למחלקות של חצי הקטלוג, ובלי גיבוי זמין העבודה הזאת נבנית מחדש מאפס. זה לא אירוע אבטחה, אבל הפתרון בדיוק זהה.
לכן הכלל שאני עובד לפיו הוא פשוט: לפני כל ייבוא המוני מייצאים קודם את המצב הקיים. זה לוקח דקה, וזה ההבדל בין תיקון של חמש דקות לבין שבוע עבודה. הרגל אחד קטן שמכסה את הסיכון הכי יקר בקטלוג.
שווה גם לוודא שהגיבוי לא יושב באותו מקום שממנו הוא מגבה. עותק שנמצא רק בתוך אותה מערכת נעלם יחד איתה, ולכן עותק אחד לפחות צריך להיות מחוץ לפלטפורמה, במקום שאתם שולטים בו.
לא לפרסם פרטים רגישים בערוצים פתוחים
הרבה מידע דולף בלי שאף אחד נפרץ. צילום מסך של ממשק ניהול שנשלח בקבוצת וואטסאפ, סטורי שמצלם מסך עם רשימת הזמנות, סיסמה שנשלחת בהודעה כדי לחסוך זמן. הכל נעשה מתוך כוונה טובה ומהירות.
מה שקורה בפועל זה שהמידע יוצא משליטתכם ברגע ששלחתם אותו. הודעה נשמרת במכשיר, קבוצה כוללת אנשים שהצטרפו מזמן, וצילום מסך נשאר בגלריה של הטלפון גם אחרי שההודעה נמחקה.
כללים פשוטים שמונעים את רוב זה:
- לא שולחים סיסמאות בהודעות, פותחים משתמש נפרד במקום
- מטשטשים פרטי לקוח בכל צילום מסך שיוצא החוצה
- לא מצלמים מסכי ניהול לתוכן שיווקי או לסטורי
- בודקים מי נמצא בקבוצה לפני ששולחים אליה משהו תפעולי
ההרגלים האלה עולים שניות בודדות ומונעים את סוג הדליפה שהכי קשה לתקן, כי היא לא משאירה עקבות במערכת ואין ממה לשחזר.
לוודא תעודת אבטחה תקפה בכל הדפים
תעודת אבטחה תקפה היא בסיס, אבל שווה לבדוק שהיא באמת חלה על כל הדפים ולא רק על עמוד הבית. דף שנטען בלי הצפנה, או דף מאובטח שטוען בתוכו רכיב לא מאובטח, מייצר אזהרה בדפדפן בדיוק ברגע הכי רגיש.
הגולש שרואה אזהרת אבטחה בעגלה לא בודק מה בדיוק הבעיה. הוא סוגר. זה אחד המקומים שבהם אבטחה ואמון נפגשים ישירות, וזו הסיבה שהנושא הזה חוזר בכל דיון על בניית אמון באתר מכירות.
מה לבדוק בפועל:
- שכל הדפים נטענים בהצפנה, כולל דפי מוצר ודפי תוכן ישנים
- שהתעודה בתוקף ושיש התראה לפני שהיא פגה
- שאין רכיבים או תמונות שנטענים מכתובת לא מאובטחת
- שהפניה מכתובת לא מאובטחת מגיעה לגרסה המאובטחת
בדיקה כזאת לוקחת דקות ומשתלבת יפה בתוך הבדיקות השבועיות באתר, כך שהיא לא נשענת על זיכרון של מישהו.
לנהל נכון את נתוני הלקוחות
החנות מחזיקה שמות, כתובות, טלפונים והיסטוריית הזמנות. זה נכס עסקי אמיתי וגם אחריות משפטית, והדרך שבה מתייחסים אליו בפועל היא לרוב מקרית. מייצאים קובץ לקוחות לצורך דיוור, שולחים אותו במייל, והוא נשאר בתיקיית ההורדות של שלושה אנשים.
כאן נכנס העיקרון הפשוט של מינימום נחוץ: מייצאים רק מה שצריך, רק כשצריך, ומוחקים אחרי השימוש. ככל שיש פחות עותקים של רשימת הלקוחות מסתובבים בעולם, כך יש פחות מקומות שמהם היא יכולה לדלוף.
שלושה כללים שמכסים את רוב המצבים:
- ייצוא נתוני לקוחות רק למטרה מוגדרת ולא כגיבוי אישי
- אף פעם לא שולחים קובץ לקוחות בערוץ פתוח או לא מוצפן
- פרטי תשלום נשארים אצל ספק הסליקה ולא נשמרים אצלכם
הכלל השלישי הוא החשוב מכולם. פרטי אשראי לא צריכים לעבור דרככם בשום שלב, וכל בקשה מלקוח לשלוח פרטים בהודעה או במייל צריכה לקבל תשובה אחת: דרך עמוד התשלום בלבד.
בנוסף, כדאי להגדיר מי בצוות בכלל רשאי לייצא נתוני לקוחות. ברוב החנויות אין סיבה שיותר מאדם אחד או שניים יוכלו להוריד את הרשימה המלאה, וההגבלה הזאת נעשית באותו מסך הרשאות שכבר סידרתם קודם.
לבנות נוהל תגובה למקרה שקורה
מה עושים ברגע שמגלים שמישהו נכנס לחשבון זו שאלה שצריך לענות עליה כשהכל רגוע, לא באמצע האירוע. בלי נוהל כתוב מראש, השעה הראשונה מתבזבזת על ניסיון להבין מי אחראי ומה עושים, וזו בדיוק השעה שקובעת כמה נזק ייגרם.
מנתקים את כל הסשנים הפעילים, מחליפים סיסמאות ומאפסים אימות דו שלבי למשתמש שנפגע, ואז עוברים על יומן הפעילות כדי לראות מה שונה. בשלב הבא בודקים במיוחד את פרטי חשבון הבנק, כתובות המייל להתראות ומשתמשי המנהל, כי אלה השדות שתוקף משנה ראשונים כדי לשמור לעצמו דריסת רגל.
נוהל התגובה לא צריך להיות מסמך ארוך. דף אחד עם שמות, סדר פעולות וטלפונים מספיק לחלוטין, ובלבד שהוא נמצא במקום שנגיש גם כשאין גישה לממשק. הדבר החשוב הוא שמישהו אחד מוגדר כאחראי, כי אירוע שכולם אחראים עליו הוא אירוע שאף אחד לא מטפל בו.
מה שכן, כדאי לעבור על הדף הזה פעם בשנה. אנשים מתחלפים, ספקים מתחלפים, ונוהל עם מספר טלפון של מישהו שעזב לפני שנתיים לא עוזר לאף אחד.
האם אימות דו שלבי באמת הכרחי לחנות קטנה
כן, וזה לא תלוי בגודל החנות. תוקף שמנסה סיסמאות גנובות לא בודק כמה הזמנות יש לכם בחודש, הוא פשוט מריץ רשימות מול כל ממשק ניהול שהוא מוצא. אימות דו שלבי הוא ההגנה היחידה שממשיכה לעבוד גם אחרי שסיסמה דלפה, ולכן הוא חובה על כל משתמש בממשק, כולל מי שנכנס פעם בחודש.
כמה משתמשי מנהל צריכים להיות בחנות
כמה שפחות, ובחנות ממוצעת מספיק אחד או שניים. כל משתמש מנהל נוסף הוא עוד סיסמה שיכולה לדלוף ועוד מכשיר שיכול להידבק, בלי שהוא מוסיף יכולת אמיתית לרוב האנשים בצוות. מי שמטפל בהזמנות צריך הרשאת הזמנות, מי שמעלה מוצרים צריך הרשאת קטלוג, וההפרדה הזאת לא מפריעה לאף אחד לעבוד.
אבטחה בחנות היא נוהל יומיומי ולא מוצר שקונים פעם אחת
אין מוצר אחד שמסדר את אבטחת חנות אינטרנטית, ואין הגדרה שמפעילים פעם אחת ושוכחים ממנה. יש רשימת משתמשים שמישהו עובר עליה ברבעון, אימות דו שלבי שמוגדר לכל מי שנכנס, וצוות שיודע לא ללחוץ על קישור במייל. הדברים האלה נשמעים קטנים בדיוק עד הרגע שבו הם לא.
אחרי 10 שנים ו-60+ חנויות, כמעט כל אירוע שראיתי היה אפשרי למניעה באחת הפעולות ברשימה הזאת. לא בטכנולוגיה מתקדמת אלא בהחלטה ניהולית שאף אחד לא הספיק לקבל.
בסופו של דבר, אבטחה טובה נראית כמו כלום. אף אחד לא שם לב אליה, אין מה לספר עליה, והחנות פשוט ממשיכה לעבוד. זה בדיוק מה שאתם רוצים שיקרה, וזה מה שמצדיק את הרבע שעה שהיא דורשת בכל רבעון.
אם אתם רוצים שמישהו יעבור על ההרשאות, הגיבויים והשגרות האלה כחלק מתחזוקה שוטפת של החנות, זה בדיוק מה שאני עושה.
