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

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

מה תקנות הגנת הפרטיות דורשות מכם

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

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

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

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

מילון קצר לפני שמתחילים

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

• גיבוב (hash). המרה חד-כיוונית של סיסמה למחרוזת אקראית למראה. אפשר לבדוק אם סיסמה תואמת לגיבוב, אבל אי אפשר לשחזר ממנו את הסיסמה.
• הרשאות לפי תפקיד (RBAC). כל משתמש משויך לתפקיד, וכל תפקיד מגדיר מה רואים ומה מותר לעשות.
• זיוף בקשה בין אתרים (CSRF). תקיפה שגורמת לדפדפן שלכם, בזמן שאתם מחוברים למערכת, לבצע פעולה שלא ביקשתם.
• הזרקת סקריפט (XSS). קוד זדוני שמישהו מכניס לשדה טקסט, ושרץ אחר כך בדפדפן של משתמש אחר שצופה באותו טקסט.
• הגבלת קצב (rate limiting). חסימה של מי שמנסה לבצע את אותה פעולה - למשל כניסה - פעמים רבות מדי בזמן קצר.
• יומן פעולות (audit log). רישום קבוע של מי עשה מה ומתי במערכת, שמשתמש רגיל לא יכול לערוך.
• מבדק חדירה (penetration test). ניסיון מבוקר של גורם חיצוני לפרוץ למערכת כדי למצוא חולשות לפני שמישהו אחר ימצא אותן.

עשרת הדברים לדרוש מהמפתח

לכל דרישה מצורפת שורה של "איך בודקים" - שאלה או פעולה שלא דורשות ידע טכני.

1. סיסמאות נשמרות כגיבוב בלבד, אף פעם לא כטקסט

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

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

2. הרשאות לפי תפקיד, ולא יותר ממה שצריך

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

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

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

3. תקשורת מוצפנת בכל מסך, כולל אזור הניהול

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

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

4. הגנה מפני CSRF, XSS והזרקת SQL

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

איך בודקים: הקלידו בשדה חופשי, למשל שם לקוח, את הטקסט <b>test</b> ושמרו. אם המילה מופיעה אחר כך בהדגשה, המערכת מציגה טקסט בלי לנקות אותו. לגבי השאר, בקשו מהמפתח לתאר במשפט אחד איך הוא מגן מ-CSRF ומהזרקת SQL.

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

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

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

6. גיבויים אוטומטיים, ובדיקת שחזור אמיתית

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

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

7. יומן פעולות: מי עשה מה ומתי

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

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

8. עדכונים שוטפים, עם אחראי ועם תקציב

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

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

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

9. צמצום מידע: לאסוף פחות, לשמור פחות זמן

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

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

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

10. תוכנית לאירוע אבטחה, כתובה מראש

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

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

טבלת בדיקה מהירה

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

איך זה נראה במערכת שנמסרה

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

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

וכך זה נראה בפרויקט אמיתי. בGLOBAL JOBS, אתר לידים עם מערכת ניהול לידים לחברת כוח אדם, סיסמת המנהל נשמרת כגיבוב bcrypt בלבד, כל טופס במערכת מוגן ב-CSRF, אחרי חמישה ניסיונות כניסה כושלים החשבון ננעל ל-15 דקות, המערכת מנתקת אוטומטית אחרי 8 שעות, ואזור הניהול חסום לסריקה במנועי חיפוש. זו מערכת ב-PHP 8 עם אחסון בקובצי JSON, בלי מסד נתונים כבד - כלומר לא גודל הפרויקט קובע אם הרשימה מתקיימת, אלא האם מישהו דרש אותה.

מתי לא צריך את כל הרשימה

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

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

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

איך מכניסים את זה לאפיון ולהצעת המחיר

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

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

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

שורה תחתונה

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

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