ملحق أمن المعلومات

1. כללי

1.1 LoyalX הוא שם מסחרי של שירות המופעל על ידי מוחמד אבו אחמד, עוסק פטור (להלן: "LoyalX" או "המפעיל").

1.2 הנספח מתאר את אמצעי אבטחת המידע והגיבוי שהמפעיל נוקט בשירות LoyalX (להלן: "השירות" או "הפלטפורמה"). הוא מתאר גם את האחריות של בית העסק לאבטחת השימוש שלו בשירות. הנספח הוא חלק מהסכם השירות ומהסכם עיבוד המידע (loyalx.co/he/legal/dpa).

1.3 המונחים בנספח מוגדרים בהסכם השירות ובהסכם עיבוד המידע. אבטחת מידע פירושה הגנה על שלמות המידע, או הגנה על המידע מפני עיבוד שלא בהרשאה כדין. אירוע אבטחה כמשמעותו בתקנות הגנת הפרטיות (אבטחת מידע), התשע"ז–2017 (להלן: "תקנות אבטחת מידע"). האמור בלשון זכר — גם בלשון נקבה ולהפך.

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

2. אירוח ותשתית

2.1 מסד הנתונים. כל המידע הקבוע של השירות נשמר במסד נתונים מנוהל (PostgreSQL) אצל ספק מסד הנתונים Supabase, באזור פרנקפורט, גרמניה (האיחוד האירופי). זה כולל גם את הלוגואים והתמונות שבתי העסק מעלים, ואת קובצי הייצוא עד שהם מורדים.

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

2.3 ספקים אמריקאיים. ספק האירוח וספק מסד הנתונים הם חברות שמטה שלהן בארצות הברית. פרטים על ספקי המשנה ועל העברות מידע מחוץ לישראל מופיעים בנספח ספקי המשנה (loyalx.co/he/legal/subprocessors).

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

2.5 סביבות בדיקה. לסביבות התצוגה המקדימה (preview) של האפליקציה אין גישה למסד הנתונים של הייצור, והן מוגנות בהזדהות מול ספק האירוח.

3. הפרדה בין בתי עסק

3.1 השירות הוא שירות משותף לבתי עסק רבים (רב-דיירי). כל המידע של בית עסק משויך לבית העסק בלבד.

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

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

4. הזדהות וניהול גישה

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

4.2 התחברות עם Google. אפשר להתחבר עם חשבון Google. השירות מבקש רק את הרשאות הזיהוי הבסיסיות (זהות, דוא"ל ושם), ולא שומר את תמונת הפרופיל.

4.3 הפעלות (sessions).

• (א) לאחר ההתחברות נוצרת הפעלה עם מזהה אקראי. במסד הנתונים נשמר רק גיבוב של המזהה.
• (ב) בדפדפן, המזהה נשמר בעוגייה מאובטחת: נשלחת רק ב-HTTPS, לא נגישה לקוד בדף, ועם הגבלת שליחה מאתרים אחרים.
• (ג) הפעלה של משתמש בית עסק פגה לאחר 30 יום לכל היותר, או לאחר 7 ימים ללא פעילות. אצל מנהלי הפלטפורמה השרת מסיים את ההפעלה לאחר 12 שעות.
• (ד) כשמשתמש מוסר מבית העסק, הגישה שלו לבית העסק נחסמת מיד. אם אינו משויך לבית עסק אחר, כל ההפעלות שלו מבוטלות. הפעלה שבוטלה לא ניתנת להפעלה מחדש.
• (ה) אפליקציית LoyalX Business שומרת את מזהה ההפעלה באחסון המאובטח של מערכת ההפעלה (Keychain ב-iOS ו-Keystore ב-Android). ב-Android הגיבוי האוטומטי של נתוני האפליקציה כבוי.

4.4 אימות דו-שלבי.

• (א) משתמשי בתי העסק יכולים להפעיל אימות דו-שלבי באפליקציית אימות (TOTP). למי שהפעיל אותו, נדרש קוד גם בכל התחברות, כולל התחברות עם Google.
• (ב) הסוד של האימות הדו-שלבי נשמר מוצפן.
• (ג) קודי השחזור נשמרים כגיבוב, וכל קוד ניתן לשימוש פעם אחת.
• (ד) אצל מנהלי הפלטפורמה האימות הדו-שלבי הוא חובה. בלי אימות דו-שלבי הם לא יכולים להיכנס לממשק הניהול. לפני פעולות רגישות נדרש אימות חוזר, אם עברו יותר מ-15 דקות מהאימות האחרון.

4.5 נעילה ומגבלות קצב.

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

4.6 אסימונים.

• (א) אסימונים לשימוש חד-פעמי נשמרים כגיבוב ובתוקף מוגבל. למשל: קישור לאיפוס סיסמה בתוקף לשעה, קישור לאימות דוא"ל ל-48 שעות, הזמנת צוות ל-7 ימים, וקישור להורדת ייצוא ל-24 שעות ולהורדה אחת.
• (ב) קישור הכרטיס האישי של חבר מועדון וקוד ה-QR שלו כוללים חתימה קריפטוגרפית שהשרת בודק. בלי החתימה אי אפשר להשתמש בהם.
• (ג) קישור הכרטיס האישי משמש כאמצעי גישה לדף הכרטיס. כל מי שמחזיק בקישור יכול לפתוח את הדף, לשנות הסכמות ולמחוק את הכרטיס. לכן חשוב לא לשתף אותו. כשחבר מועדון מצטרף שוב עם פרטי קשר שכבר רשומים, הקישור נשלח רק לפרטי הקשר הרשומים. כשהכרטיס נמחק, מוחלף מזהה הקישור, והקישור הישן מפסיק לעבוד.

4.7 הרשאות לפי תפקיד.

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

4.8 גישת המפעיל.

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

5. תיעוד ויומני ביקורת

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

5.2 יומן ביקורת ואירועי אבטחה.

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

5.3 תקופת השמירה. יומן הביקורת ואירועי האבטחה נשמרים כל עוד חשבון בית העסק קיים, ועד 7 שנים לאחר סגירתו, כמפורט במדיניות השמירה והמחיקה (loyalx.co/he/legal/data-retention).

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

6. הצפנה

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

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

6.3 במנוחה.

• (א) לפי הצהרת ספק מסד הנתונים, מסד הנתונים והגיבויים המנוהלים שלו מוצפנים במנוחה. המפעיל לא אימת זאת באופן עצמאי.
• (ב) המפעיל מצפין בעצמו את סודות האימות הדו-שלבי ואת קישורי ההסרה מרשימות תפוצה.
• (ג) המפעיל שומר כגיבוב סיסמאות, אסימוני הפעלה, אסימונים חד-פעמיים וקודי שחזור.
• (ד) שאר המידע, כולל פרטי הקשר של חברי המועדון, מזהי הקישור לכרטיס ולקוד ה-QR ואסימוני העדכון של Apple Wallet, נשמר במסד הנתונים בלי הצפנה נוספת ברמת השדה, ומוגן באמצעים שבסעיפים 2 עד 4.

6.4 תמונות. תמונות שבתי העסק מעלים מעובדות מחדש בשרת, ונתוני המטא שלהן (כולל מיקום GPS) מוסרים.

7. פיתוח מאובטח וניהול שינויים

7.1 קוד השירות מנוהל במערכת ניהול גרסאות. שינויים מוגשים כבקשות משיכה (pull requests).

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

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

7.4 השירות לא כולל כיום כלי אנליטיקה, פיקסלים של פרסום או סקריפטים של צד שלישי בדפים.

7.5 מה לא קיים. השירות לא עבר מבדק חדירה חיצוני, ולא קיבל הסמכת אבטחת מידע כלשהי (כגון ISO 27001 או SOC 2). המפעיל הוא אדם יחיד, ולכן אין סקירת קוד אנושית בלתי תלויה של כל שינוי.

8. ניטור והתראות

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

8.2 התראות.

• (א) השירות שולח למפעיל התראות בדוא"ל כשמשימה מתוזמנת נכשלת, או כשעדכון של כרטיס Wallet נכשל אחרי כל הניסיונות החוזרים.
• (ב) ההתראות כוללות שמות משימות ומונים בלבד, בלי מידע על לקוחות.

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

9. ניהול פגיעויות ועדכונים

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

9.2 עדכוני התשתית (מערכות הפעלה, מסד הנתונים והרשת) מנוהלים בידי ספקי האירוח ומסד הנתונים, לפי המדיניות שלהם.

9.3 פגיעות שמדווחת למפעיל ל-support@loyalx.co תיבחן ותטופל בזמן סביר.

10. טיפול באירועי אבטחה

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

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

10.3 המפעיל יתעד אירועי אבטחה כנדרש בתקנות אבטחת מידע.

11. גיבוי ושחזור

11.1 גיבויים מנוהלים.

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

11.2 אין שחזור לנקודת זמן. השירות לא כולל כיום שחזור לנקודת זמן (Point-in-Time Recovery). לכן, אם מסד הנתונים ישוחזר מגיבוי, המצב יחזור למועד הגיבוי היומי האחרון. מידע שהוזן אחרי הגיבוי האחרון עלול לאבד, בהיקף של עד כ-24 שעות. למשל: הצטרפויות, ניקובים, מימושים ושינויי הגדרות.

11.3 עותקים נוספים של המפעיל.

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

11.4 שחזור.

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

11.5 מחיקות וגיבויים.

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

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

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

12. אחריות בית העסק

בית העסק אחראי לאבטחת השימוש שלו בשירות. בין היתר, הוא אחראי:

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

12.2 סיסמאות ואימות דו-שלבי. להשתמש בסיסמאות חזקות וייחודיות. מומלץ מאוד להפעיל אימות דו-שלבי לבעלים ולמנהלים.

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

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

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

12.6 דיווח. לדווח למפעיל מיד, ל-support@loyalx.co, על כל חשד לגישה לא מורשית לחשבון, לאובדן מכשיר עם גישה פעילה, או לאירוע אבטחה אחר.

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

13. שינוי האמצעים

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

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

14. מגבלות

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

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

14.3 השירות תלוי בספקי צד שלישי: ספק האירוח, ספק מסד הנתונים, ספק הדוא"ל, Apple ו-Google. תקלה אצלם עלולה לפגוע בשירות.

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

15. פרטי התקשרות

• דיווח על אירוע אבטחה או פגיעות, פניות בנושא פרטיות, תמיכה ופניות כלליות: support@loyalx.co
• טופס יצירת קשר: loyalx.co/contact

תאריך תחילה: 15 באוקטובר 2026