אבטחת אתרים לארגונים: מה באמת מגן, ומה רק נשמע טוב

שאלת האבטחה מגיעה בשתי גרסאות. בגרסה הראשונה מנהל נשאל בישיבת הנהלה אם האתר מוגן, ואין לו מה לענות חוץ מ"יש לנו SSL". בגרסה השנייה מגיע טלפון בשבע בבוקר שהאתר מפנה לאתר הימורים ביפנית. שתי הגרסאות מובילות לאותו מקום: אבטחת אתר היא לא מוצר שקונים פעם אחת, אלא כמה שכבות שעובדות יחד ושגרה שיש לה בעלים בשם. הדף הזה מסביר מה באמת תוקף אתר עסקי, אילו שכבות עוצרות מה, מה עושים בשעה הראשונה, ומה חייב להיות כתוב בהסכם עם הספק.

מי בעצם תוקף אתר של חברה?

כמעט תמיד לא אדם שבחר בכם, אלא תוכנה שסורקת את כל האינטרנט ומחפשת חולשה מוכרת. הסורק לא יודע מה החברה שלכם עושה ולא אכפת לו: הוא מזהה גרסה של תוסף עם באג שפורסם, מנסה סיסמאות שדלפו ממקום אחר, ועובר לכתובת הבאה. לכן "אנחנו קטנים מדי בשביל שיתקפו אותנו" הוא לא טיעון, אלא תיאור של הזמן שנשאר עד הסריקה הבאה.

אלה התרחישים שמופיעים בפועל באתרים עסקיים בישראל:

• ניצול חולשה בתוסף או בערכת עיצוב. חולשה מתפרסמת, תיקון יוצא, ומי שלא עדכן בשבועיים הקרובים נסרק ונפרץ. זה המקרה הנפוץ ביותר בוורדפרס.
• סיסמאות גנובות. לא פיצוח, אלא סיסמה שדלפה מאתר אחר שבו השתמשתם באותה סיסמה, או סיסמה שנשלחה פעם במייל לספק.
• הזרקת ספאם לקידום. התוקף לא מוריד את האתר, הוא מוסיף לו מאות עמודים או קישורים נסתרים כדי לקדם משהו אחר. הסימן הראשון הוא בדרך כלל דוח מגוגל, לא תלונה של לקוח.
• גניבת פרטי אשראי בחנות. סקריפט זדוני נשתל בעמוד התשלום וקורא את השדות לפני שהם מגיעים לספק הסליקה. בחנות זה התרחיש היקר ביותר.
• ניצול טפסים. טופס יצירת קשר בלי הגנה הופך למכונת ספאם, ולפעמים לצינור לשליחת דיוור בשמכם, מה שהורס את המוניטין של הדומיין במייל.
• הצפת תעבורה (DDoS). לרוב לא מתוחכמת, אבל מספיקה כדי להפיל אתר שיושב על אחסון חלש, בדיוק ביום שבו רץ קמפיין.
• הנדסה חברתית. מייל שנראה כמו הודעה מחברת האחסון על תפוגת חשבון, או טלפון למזכירה בבקשה לאפס סיסמה. הרכיב האנושי הוא הכי קל לתקיפה ואף חומת אש לא רואה אותו.
• גישה שנשארה פתוחה. ספק שסיים לפני שנתיים, עובד שעזב, מפתח שקיבל גישה לחודש. בחשבונות שאנחנו מקבלים לניהול זה כמעט תמיד מה שמוצאים.

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

שכבות ההגנה: מה כל אחת באמת עוצרת

אין שכבה אחת שעוצרת הכל, ולכן השאלה הנכונה היא לא "האם אנחנו מוגנים" אלא "מה כל שכבה שיש לנו עוצרת, ומה נשאר פתוח". השכבות מסודרות מבחוץ פנימה: הרשת שלפני האתר, השרת, התוכנה, המשתמשים, והנתונים. תוקף שעבר שכבה אחת אמור להיתקע בשכבה הבאה, וזו כל התועלת של הרעיון.

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

סדר העדיפויות בפועל תלוי בכמה מאמץ כל צעד דורש ביחס לסיכון שהוא מוריד. הדירוג הבא הוא שיפוט מקצועי שלנו מעבודה על אתרים, לא מדידה:

עדכונים: הסיכון הכי גדול והכי משעמם

עדכון תוכנה הוא הפעולה שמונעת את מרבית הפריצות לאתרים עסקיים, והיא גם זו שהכי קל לדחות. חולשה מתפרסמת יחד עם התיקון, ובאותו רגע כל מי שלא עדכן נמצא ברשימה ציבורית של יעדים אפשריים. הפער בין פרסום לתקיפה נמדד בימים.

שגרת תיקונים טובה לא דורשת צוות אבטחה, היא דורשת שלושה דברים: בעלים בשם, קצב קבוע, וסביבת בדיקה. כך זה נראה בפועל:

מה שנשכח כמעט תמיד: גרסת ה-PHP של השרת. גרסה שיצאה מתמיכה לא מקבלת עוד תיקוני אבטחה, וזה נכון גם כשהאתר עובד מצוין. אותו דבר לגבי מערכת ההפעלה של השרת, בסיס הנתונים ותוספי צד שלישי שהמפתח שלהם נטש. תוסף שלא עודכן שנתיים הוא לא "יציב", הוא נטוש.

משתמשים, הרשאות ואימות דו-שלבי

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

אל תעצרו באתר עצמו. שרשרת השליטה כוללת גם את חשבון האחסון, את רשם הדומיין, את ניהול ה-DNS, את חשבון המייל שאליו מגיעות איפוס הסיסמאות, ואת חשבון ה-Tag Manager שיכול להזריק סקריפט לכל עמוד. אלה חשבונות שצריכים אימות דו-שלבי לא פחות מהאתר, ובבעלות החברה, לא בבעלות הספק. אתר שנפרץ חוזר תוך יום; דומיין שאבד לוקח חודשים.

אחסון, HTTPS וכותרות אבטחה

האחסון הוא שכבת האבטחה שקונים ושוכחים, והוא זה שקובע מה קורה כשמשהו משתבש. שרת מוקשח מבודד כל אתר מהשכנים שלו, מריץ גרסת PHP נתמכת, מגביל הרשאות קבצים, ומאפשר העברת קבצים מוצפנת בלבד. אחסון זול שבו ארבעים אתרים חולקים את אותה תיקייה הוא סיכון גם כשהאתר שלכם מעודכן, כי פריצה לשכן יכולה לזלוג אליכם.

לגבי HTTPS ותעודת SSL, כדאי לומר את זה בפירוש: התעודה מצפינה את התעבורה ומוודאת שהדפדפן מדבר עם השרת הנכון. היא לא בודקת תוספים, לא חוסמת תוקפים ולא מגנה על בסיס הנתונים. מה שכן חשוב סביבה:

• הפניה גורפת ל-HTTPS על כל הכתובות, כולל תמונות וקבצים, כדי שלא יישאר תוכן מעורב.
• חידוש אוטומטי של התעודה. תעודה שפגה היא הסיבה הנפוצה ביותר להשבתה שגרמנו לעצמנו. שימו התראה גם על התאריך.
• גרסת TLS מודרנית בשרת, בלי גרסאות ישנות שנשארו פתוחות "בשביל תאימות".
• תעודה נפרדת לכל מערכת שיושבת על דומיין משנה, כדי שתקלה במערכת אחת לא תפיל את השאר.

מעל זה יושבות כותרות האבטחה, שורות שהשרת שולח עם כל עמוד ומצמצמות את מה שהדפדפן מוכן לעשות. הן זולות להפעלה ומונעות משפחה שלמה של תקיפות:

חומת אש, הגבלת קצב והצפות תעבורה

חומת אש לאפליקציה (WAF) יושבת לפני האתר ומסננת בקשות לפי חוקים, לפני שהן מגיעות לשרת שלכם. היא עוצרת היטב סריקות אוטומטיות, ניסיונות ניצול של חולשות מוכרות והצפות תעבורה, ולכן היא השכבה הראשונה שכדאי להוסיף לאתר שכבר עודכן ומסודר.

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

לצד חומת האש, שתי הגדרות פשוטות מורידות הרבה רעש:

• הגבלת ניסיונות כניסה לפי כתובת IP וזמן. זה מנטרל את רוב ניסיונות הסיסמאות האוטומטיים.
• הגבלת קצב על טפסים יחד עם שדה מלכודת נסתר. עדיף על להוסיף עוד אימות מול המשתמש, שפוגע גם בנגישות וגם באחוזי המילוי.

הצפת תעבורה נבלמת ברשת שלפני האתר, לא בשרת עצמו. אם התוכנית שלכם היא "נגדיל את השרת כשזה יקרה", אין לכם תוכנית. שאלו את ספק האחסון מה קורה כשמגיעות מאה אלף בקשות בדקה, ומי מקבל את ההחלטה בשתיים בלילה.

תוספים, ערכות וסקריפטים חיצוניים

כל תוסף, ערכת עיצוב וסקריפט חיצוני הם קוד שלא כתבתם, שרץ באתר שלכם עם ההרשאות שלכם. זו שרשרת האספקה שלכם, וברוב האתרים היא ארוכה בהרבה ממה שמישהו זוכר. ניקוי שלה הוא לרוב שיפור האבטחה הזול ביותר שיש.

לפני שמתקינים רכיב חדש, ארבע שאלות: מתי הוא עודכן לאחרונה, כמה אתרים משתמשים בו, מי עומד מאחוריו, ואיך הוא הגיב בפעם האחרונה שדווחה בו חולשה. רכיב שלא עודכן שנה, או שהמפתח שלו לא מגיב, הוא חוב שנצבר. אחרי ההתקנה: מוחקים ולא רק מכבים כל תוסף וערכה שלא בשימוש, כי קוד שיושב על השרת נסרק גם כשהוא כבוי.

הפרק המסוכן במיוחד הוא סקריפטים שרצים בעמוד מול הגולש: צ׳אט, פיקסלים, כלי הקלטת מסך, מערכות המלצות, ובעיקר כל מה שמוזרק דרך Tag Manager. סקריפט כזה יכול לקרוא כל שדה בטופס, כולל שדות תשלום. מכאן נובעות שלוש מסקנות מעשיות: לצמצם את הרשימה למי שבאמת נחוץ, להתייחס להרשאת Tag Manager כאל הרשאת אבטחה ולא כאל הרשאת שיווק, ולהשתמש ב-Content-Security-Policy כדי לקבוע מראש מאילו מקורות מותר לטעון קוד.

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

רשימת הקשחה לוורדפרס ולווקומרס

וורדפרס לא פחות בטוח ממערכות אחרות, אבל הוא הנפוץ ביותר ולכן הכי נסרק. ההקשחה שלו היא רשימה קצרה של הגדרות שעושים פעם אחת, ובדיקה שהן עדיין במקום אחרי כל שינוי גדול. אלה הסעיפים שאנחנו עוברים עליהם בכל אתר:

את ההנחיות הרשמיות מתחזקים בוורדפרס עצמו: מדריך ההקשחה של WordPress.org. אם אתם מנהלים חנות ונתקלים גם בתקלות תפעול, יש לנו מדריך נפרד לפתרון בעיות נפוצות בווקומרס, כולל מסך לבן אחרי עדכון והזמנות תקועות.

ולשאלה שחוזרת: לא, המעבר לפיתוח מותאם אישית הוא לא פתרון אבטחה בפני עצמו. הוא מחליף סיכון בסיכון אחר, ואת ההשוואה המסודרת כתבנו במדריך בחירת התשתית לאתר.

גיבויים שבאמת שוחזרו

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

הגדרה סבירה לאתר עסקי נראית כך:

שתי מילים שכדאי להביא לישיבה: כמה זמן מותר שהאתר יהיה למטה, וכמה מידע מותר לאבד. אלה שתי החלטות עסקיות, לא טכניות, והן אלה שקובעות כמה משקיעים. אתר תדמית שיכול לחכות יום זה לא אותו תקציב כמו חנות שמוכרת בכל שעה.

ניטור: איך יודעים לפני שהלקוחות מודיעים

המטרה של ניטור היא לקצר את הזמן בין הרגע שמשהו קרה לרגע שמישהו יודע. ברוב האתרים העסקיים הזמן הזה נמדד בימים, וכל יום כזה מכפיל את הנזק: יותר עמודי ספאם שנכנסו לגוגל, יותר פרטים שנקראו, יותר לקוחות שראו אזהרה אדומה.

מי שכבר מודד תנועה יכול לחבר את זה למה שממילא נמצא אצלו: ירידה פתאומית בעמודים המאונדקסים או קפיצה בעמודים שלא הכרתם היא סימן אבטחה, לא רק סימן קידום.

האתר נפרץ: מה עושים בשעה הראשונה

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

כמה כללים שמצילים ארגונים מטעויות יקרות בשעה הזאת:

• לא למחוק ולהמשיך. קובץ זדוני אחד הוא כמעט תמיד לא היחיד, והוא הרמז לדרך הכניסה.
• לא לשחזר לאותה תשתית בלי לסגור את החולשה. אחרת חוזרים לאותו מקום בתוך ימים.
• להחליף סודות, לא רק סיסמאות. מפתחות API, סיסמאות בסיס הנתונים, מפתחות אבטחה של האתר וסיסמאות המייל שמחובר אליו.
• לא לשלם לאף אחד שהתקשר להודיע שיש לכם וירוס. זו תבנית הונאה מוכרת.
• להחליט מי מדבר. אדם אחד מול לקוחות ומול ההנהלה, עם מסר אחיד וקצר.

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

כשיש לכם מידע על לקוחות, אבטחה היא חובה משפטית

ברגע שהאתר אוסף פרטים מזהים, אבטחת המידע מפסיקה להיות המלצה טכנית והופכת לחובה שבדין. תיקון 13 לחוק הגנת הפרטיות נכנס לתוקף באוגוסט 2025 והרחיב את החובות סביב איסוף מידע, יידוע, אבטחה ודיווח, ובגופים מסוימים גם מינוי ממונה הגנת פרטיות. את הפרטים והחשיפה הספציפית שלכם בודקים עם היועץ המשפטי, אבל את הבסיס אפשר לסגור בלי לחכות לו.

מה זה אומר מעשית לאתר:

העדכונים הרשמיים מתפרסמים אצל הרשות להגנת הפרטיות. לגופים ציבוריים ולחברות שנותנות להם שירות מצטרפת גם דרישת הנגישות, שהיא ביקורת נפרדת עם לוח זמנים משלה: ריכזנו אותה במדריך נגישות האתרים, ואת שאר דרישות העבודה מול מכרזים ורשויות במדריך הדיגיטל לגופים ציבוריים.

מה לדרוש מספק האחסון או מהסוכנות, בכתב

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

מה עושים עכשיו

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

רוצים לדעת איפה אתם עומדים לפני שמתחילים? האבחון הדיגיטלי החינמי סורק את האתר ומצביע על מה שנראה מבחוץ, כולל תשתית וביצועים, ואם תרצו שמישהו יחזיק את השכבות האלה באופן שוטף, זה בדיוק מה שכולל שירות האחסון, האבטחה והנגישות שלנו.