אמצעים טכניים וארגוניים

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

גרסה 1.1 · עודכן לאחרונה: 22 באוקטובר 2026

אמצעים לפי סעיף 32 ל-GDPR שבאמצעותם LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Poland, מגן על שירות formexposed. דף זה מהווה חלק מההסכם לעיבוד מידע כנספח 2.

1. תחולה ועיקרון

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

מבנה לפי סעיף 32(1) ל-GDPR. פסאודונימיזציה והצפנה (נקודה (a)) נכללות בסעיף 4; הסודיות, השלמות, הזמינות והעמידות המתמשכות של המערכות (נקודה (b)) בסעיפים 3, 5, 6 ו-7; היכולת לשחזר זמינות בזמן סביר לאחר אירוע (נקודה (c)) בסעיף 7.1; התהליך לבדיקה, לאמידה ולהערכה סדירות של היעילות (נקודה (d)) בסעיף 9. בחרנו את האמצעים על בסיס הסיכונים המתוארים בהערכת ההשפעה על הגנת מידע שלנו, תוך התחשבות במצב הטכנולוגי העדכני ובעלויות היישום.

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

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

2. מבנה השירות

השירות פועל על שני שרתים של הספק עצמו בפולין, הממוקמים באותה רשת פנימית:

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

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

3. סודיות

3.1 בקרת גישה פיזית

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

3.2 בקרת גישה: כניסה לשירות

• סיסמאות נשמרות רק כגיבוב בשיטה הסטנדרטית של PHP (bcrypt). אם השיטה הסטנדרטית משתנה, הגיבוב מחודש בכניסה הבאה לחשבון. גם בניסיון כניסה עם כתובת לא מוכרת השרת מחשב גיבוב, כדי שזמן התגובה לא יגלה אם קיים חשבון. באותו אופן, התגובה לבקשת איפוס סיסמה אינה מגלה, לא בניסוחה ולא במשכה, אם החשבון קיים; הודעות איפוס נשלחות לאותה כתובת לכל היותר שלוש פעמים בשעה. סיסמאות חדשות חייבות להיות באורך של עשרה תווים לפחות ולא לעלות על 72 בתים (UTF-8), משום ש-bcrypt אינו מביא בחשבון בתים נוספים. שינוי הסיסמה מנתק את כל המכשירים האחרים; איפוסה באמצעות הקישור מנתק את כל המכשירים, והקישור תקף פעם אחת בלבד.
• נעילה לאחר ניסיונות שנכשלו. ניסיונות כניסה שנכשלו נספרים לכל כתובת IP; לאחר ניסיונות רבים מדי בזמן קצר (כיום שמונה בתוך 15 דקות), הכניסה מאותה כתובת נחסמת זמנית. כניסה מוצלחת מאפסת מונה זה. הניסיונות נמחקים לאחר שבעה ימים. בנוסף, לפני כל בדיקת סיסמה נספר ניסיון אחד לכל חשבון (ובכתובת לא מוכרת, לכל כתובת שהוזנה) ולכל כתובת IP, לרבות ניסיונות מוצלחים: כיום לכל היותר שמונה לכל חשבון מאותה כתובת IP, ו-80 לכל כתובת IP בתוך 15 דקות; לכל חשבון במצטבר מכל הכתובות חלה מגבלה גבוהה משמעותית, נגד ניחוש מבוזר. לכן ניסיונות שנכשלו מכתובת אחרת אינם נועלים עוד את הבעלים מחוץ לחשבון. מונים אלה מכילים רק מפתח HMAC, ללא כתובת דוא״ל או IP בטקסט גלוי, ופוקעים עם חלון הזמן שלהם. אם אחסון המונים אינו זמין, הכניסה נדחית ולא מאושרת. מגבלה מאותו סוג חלה על אישור הסיסמה לפני שינוי סיסמה או כתובת, הפעלת הגורם השני או כיבויו, העברת סביבת עבודה, ייצוא המידע ומחיקת החשבון (חמישה ניסיונות לכל חשבון בתוך 15 דקות), על הרשמות (עשר לכל כתובת IP בשעה) ועל סיסמאות של פורטלים ללקוחות (עשרה ניסיונות לכל פורטל וכתובת IP, 50 לכל פורטל בתוך 15 דקות).
• גורם שני. כל חשבון יכול להפעיל כניסה עם קוד חד-פעמי לפי RFC 6238 (TOTP). הסוד לכך נשמר מוצפן במסד הנתונים; המפתח אינו נשמר במסד הנתונים, ולכן תמצית של מסד הנתונים לבדה אינה מספיקה. קוד שהתקבל אינו תקף בפעם השנייה. עשרה קודי שחזור נשמרים רק כגיבוב. קודים חד-פעמיים וקודי שחזור מוגבלים לעשרה ניסיונות לכל חשבון בתוך 15 דקות, לרבות במהלך ההגדרה.
• אזור ניהול רק עם גורם שני. אזור הניהול של המפעיל נפתח רק לחשבונות שבהם הגורם השני מופעל. רשימת הבדיקה להגדרה מדווחת על כל חשבון מנהל ללא גורם שני.
• הפעלות. סקריפטים אינם יכולים לקרוא את עוגיית ההפעלה (HttpOnly), היא נשלחת רק דרך HTTPS (Secure), ואינה נשלחת עם בקשות מאתרים של צדדים שלישיים העלולות לשנות דבר מה (SameSite=Lax). בעת הכניסה לחשבון נוצר מזהה הפעלה חדש, כך שמזהה שהושתל קודם אינו תקף עוד; השרת אינו מקבל מזהה הפעלה שלא הנפיק בעצמו. כל חשבון רואה את המכשירים המחוברים שלו ויכול לנתק אותם בנפרד.
• “להישאר מחוברים” היא אפשרות רשות ותקפה למשך 30 ימים, אך לא עבור חשבונות בעלי הרשאות ניהול; הם תמיד נכנסים עם סיסמה וגורם שני. האסימון מורכב משני חלקים; החלק המאמת נשמר במסד הנתונים רק כגיבוב. כל שימוש מחליף אותו בחדש, וגם בבקשות בו-זמניות כל אסימון תקף פעם אחת בלבד, כך שאסימון שנגנב מזוהה לכל המאוחר בביקור האמיתי הבא.
• קישורים בהודעות דוא״ל. קישורים לאישור הכתובת ולאיפוס הסיסמה נשמרים במסד הנתונים רק כגיבוב. קישור האיפוס תקף למשך שעה, הקישור לאישור הרשמה למשך 72 שעות, והקישור לאישור כתובת שהשתנתה למשך 24 שעות. אם כתובת הדוא״ל משתנה, קישור איפוס פתוח הופך ללא תקף.
• ממשקים. מפתחות API, קודי חיבור של ההרחבות וקודי הפצה נשמרים רק כגיבוב. ניתן להשתמש במפתחות API רק מספר מוגבל של פעמים בדקה; קודי חיבור של ההרחבות תקפים למשך 15 דקות ופעם אחת בלבד.
• הגנה מפני בוטים בטפסים הציבוריים (הרשמה, כניסה לחשבון, סיסמה, בדיקה, כלי כותרות תגובה, החרגה, תמיכה ויצירת קשר): Google reCAPTCHA, הנטען רק בעת השליחה. מתקבלת רק תשובה תקפה מ-Google בעלת ציון מספיק עבור הפעולה המדויקת של הטופס; אם Google אינו משיב בתוך שלוש שניות, השליחה נדחית. הפרטים מופיעים במדיניות הפרטיות.

3.3 בקרת גישה: ניהול שרתים

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

3.4 בקרת הרשאות: זכויות בתוך השירות

• תפקידים. בכל סביבת עבודה קיימים התפקידים בעלים, מנהל וצופה. שינוי, מחיקה, הזמנה ושמירת פרטי כניסה שמורים לבעלים ולמנהלים; רק הבעלים רשאי לשנות תפקידים ולהסיר חברים. הזמנה תקפה רק כל עוד האדם ששלח אותה עדיין בעלים או מנהל. צופים רואים כתובות של webhooks וערוצי צ׳אט כשהן מקוצרות למארח בלבד, משום שהכתובת לבדה מאפשרת פרסום בערוץ. הבדיקה מתבצעת בשרת ולא רק בממשק.
• שיוך לסביבת העבודה. דומיינים והגדרות נגישים רק לחברי סביבת העבודה. עבור כל בדיקה, השירות יוצר דוח תחת קישור אקראי שאינו ניתן לניחוש; ניתן לגשת לתוצאות ולצילומי המסך של בדיקה באמצעות קישור זה ללא כניסה לחשבון, ולצילומי מסך רק יחד עם הקישור לדוח שלהם. הקישור מופיע בחשבון ובהתרעות; העברתו לאחרים מעבירה גם את הדוח.
• בקשות המשנות מצב דורשות אסימון אבטחה לכל הפעלה (הגנת CSRF), המושווה בזמן קבוע.
• “תצוגה כלקוח”. לצורכי תמיכה, המפעיל יכול לראות את היישום כפי שהלקוח רואה אותו. התצוגה מסתיימת לאחר שעה, חוסמת שינויים בסיסמה, בכתובת, בגורם השני, במכשירים, במינוי, בייצוא ובמחיקה, סוגרת בינתיים את אזור הניהול ונרשמת ביומן. סיומה מנתק את המפעיל לחלוטין; הוא יכול לחזור לאזור הניהול רק באמצעות כניסה מחדש עם סיסמה וגורם שני. הלקוח יכול לראות זאת בייצוא המידע שלו.
• ניהול. רק למספר מצומצם של חשבונות שהורשו במפורש יש הרשאות ניהול; כל איפוס של גורם שני על ידי ההנהלה נרשם ביומן.

3.5 בקרת הפרדה

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

4. הצפנה, פסאודונימיזציה וצמצום מידע

4.1 פרטי כניסה לסריקה מאחורי כניסה לחשבון

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

• בעת שמירתם, שרת האינטרנט מצפין אותם באמצעות המפתח הציבורי של שרת הסריקה (ECIES: X25519 עם מפתח חד-פעמי לכל רשומה, HKDF-SHA256, AES-256-GCM). המפתח הפרטי קיים רק בשרת הסריקה. שרת האינטרנט, מסד הנתונים והגיבויים מכילים רק טקסט מוצפן; גם אנחנו איננו יכולים לקרוא אותו שם.
• כל רשומה מקושרת לדומיין שלה באופן קריפטוגרפי. אם היא מועברת לדומיין אחר, הפענוח נכשל.
• לצורך סריקה, הטקסט המוצפן מצורף למשימה. שרת הסריקה מפענח אותו ומעביר את פרטי הכניסה למכולת הבדיקה רק דרך הקלט הסטנדרטי, ולעולם לא כארגומנט בשורת פקודה שיהיה גלוי ברשימות תהליכים. ברגע ששרת הסריקה קרא אותו, הטקסט המוצפן נמחק מהמשימה; ריצה מנקה שאריות כלשהן לאחר שעה לכל המאוחר.
• פרטי הכניסה לעולם אינם מוצגים, אינם נרשמים ביומן, אינם נמסרים דרך ה-API ואינם מיוצאים. הממשק מציג רק את התו הראשון ואת אורך שם המשתמש. הסרתם דורסת את הטקסט המוצפן.
• מאחורי הכניסה לחשבון, הסורק קורא בלבד: ללא שליחה, ללא בדיקה פעילה, ללא צילומי מסך, וללא דפים להתנתקות, למחיקה או לביטול.

4.2 הצפנה וגיבובים נוספים

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

4.3 צמצום מידע מעצם התכנון

• בדיקת מסירה: נקראות רק הכותרות ולכל היותר 8 KB הראשונים של הטקסט. רק המועד, השיוך, ככל שרלוונטי מזהה שליחת הבדיקה, ותוצאת בדיקת האותנטיות (SPF, DKIM, DMARC) מגיעים למסד הנתונים, ולעולם לא התוכן או כתובת שולח מלאה. תוצאת האותנטיות של הודעת הדוא״ל האחרונה נשמרת עם הדומיין ונדרסת על ידי הבאה; היא מכילה את כתובת ה-IP של שרת הדוא״ל המוסר ואת דומיין הדוא״ל של השולח. הודעת הדוא״ל נמחקת מתיבת הדואר לאחר עיבוד מוצלח; אם האחזור או המחיקה נכשלים, הדבר מתבצע בריצה המוצלחת הבאה.
• בדיקות: מבנה הטפסים נשמר עם שמות שדות, סוגים ותוויות, מאפייני חובה ונראות, ללא ערכים; הסורק קורא התחלות של שדות נסתרים שמולאו מראש (עד 24 תווים) ושל מאפייני נתונים (עד 60 תווים) רק במהלך הבדיקה ואינו שומר אותן. צילומי המסך של הבדיקה המלאה אינם עוברים השחרה; רק בדיקות הדפדפן מכסות שדות קלט. כתובות נמען של טפסים נשמרות רק כדומיין. שליחות בדיקה פעילות מכילות רק טקסטים מסומנים לבדיקה ללא מידע אישי.
• הרחבות עבור WordPress ו-TYPO3 מעבירות רק נתונים יומיים ומאפיינים כגון מלאי התוספים, ובתוסף WordPress מחובר גם את הדומיינים של קישורים מהודעות שנחסמו לצורך הגנה משותפת (מופעלת כברירת מחדל); ללא תוכן אחר וללא שמות, כתובות או כתובות IP של מבקרים. ספירות אופציונליות של שגיאות טופס ושדות כבויות כברירת מחדל.
• “Fix it for me”: הקוד שהודבק מעובד רק למשך הבקשה ואינו נשמר.
• תג: תמונת התג באתרי לקוחות אינה מציבה עוגייה ואינה מתחילה הפעלה.
• הודעות תפעוליות לטלפון של המפעיל הן טקסטים קבועים ללא משתנים, כלומר ללא שמות, כתובות או תוכן. הודעות שגיאה בדוא״ל למפעיל מכילות את הטקסט הגולמי של הודעת השגיאה, ללא סינון מידע רגיש ובקיצור ל-400 תווים; במקרים מסוימים הוא עשוי להכיל כתובות או קישורים.
• הגנה משותפת: בין הרחבות הלקוחות משותפים רק דומיינים מתוך קישורים בספאם שנחסם; חילופי רשתות IP כבויים.
• מיקום: המדינה של כתובת IP נקבעת מתוך קובץ מסד נתונים מקומי; שום כתובת אינה מועברת לשירות מיקום גאוגרפי.

5. הגנה מפני שימוש לרעה בסורק

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

5.1 ריצה מבודדת

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

5.2 רשת: שתי שכבות

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

5.3 בקשות שמבצע שרת האינטרנט

כאשר שרת האינטרנט עצמו מבקש כתובות של צדדים שלישיים – לצורך הוכחת שליטה בדומיין, כלי כותרות התגובה, חיפוש קבצים חשופים, בקשות דופק, שאילתות RDAP ובדיקת תעודות, webhooks והתרעות בצ׳אט, ונקודת הבדיקה השנייה האופציונלית – חלים אותם כללים: רק פרוטוקולי אינטרנט, ביציאות האינטרנט המקובלות (webhooks והתרעות בצ׳אט רק דרך HTTPS ביציאה הסטנדרטית), רק כתובות ציבוריות, חיבור רק לכתובת המדויקת שנבדקה מראש, כך שלא ניתן להפנות שם לאחר מכן ליעד פנימי, ללא מעקב אחר הפניות כלל או מעקב ידני בלבד עם בדיקה מחדש בכל פעם, ומגבלות זמן קצרות; לצורך הוכחת שליטה בדומיין, בקשות דופק ונקודת הבדיקה השנייה בבדיקות דפדפן, גם גודל תגובה מוגבל.

5.4 מה הסורק אינו עושה באתרי צדדים שלישיים

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

6. שלמות: העברה וקלט

6.1 תעבורה

• ניתן לגשת ליישום מהאינטרנט רק דרך HTTPS; הדפדפן מקבל הוראה להשתמש רק ב-HTTPS למשך שנה (HSTS). התעודות מחודשות אוטומטית.
• כותרות נוספות מגבילות הטמעה של היישום בדפים של צדדים שלישיים, ניחוש סוגי קבצים ושליחת טפסים ליעדים של צדדים שלישיים. מדיניות אבטחת תוכן מאפשרת להפעיל ביישום רק סקריפטים שהשרת מאשר בתגובה המתאימה; דפדפנים עדכניים אינם מפעילים סקריפטים או מטפלי אירועים שהוזרקו ל-HTML.
• תיבת הדואר של בדיקת המסירה מאוחזרת באמצעות חיבור מוצפן עם אימות תעודה.
• ניתן לחתום על webhooks באמצעות סוד של הלקוח (HMAC-SHA256 עם חותמת זמן), כדי שהנמען יוכל לאמת את המקור ואת השלמות. בקשות לנקודת הבדיקה השנייה האופציונלית חתומות, ובבדיקות דפדפן גם התגובות שלהן.
• נאמר בגלוי: החיבורים בתוך הרשת הפנימית שלנו אינם מוצפנים לכל אורכם. פרטי הכניסה לסריקה מאחורי כניסה לחשבון נשארים מוצפנים לאורך כל התהליך (סעיף 4.1).

6.2 בקרת קלט ויומנים

• פעולות חשובות בחשבונות ובסביבות עבודה (כגון כניסה לחשבון, שינויים בדומיינים, ביעדי התרעות ובהרשאות, מחיקות וגישת התמיכה) מתועדות ביומן הפעילות עם חשבון, מועד, כתובת IP ומדינה, ונמחקות לאחר 365 ימים.
• רישומי גישה לדפים הנשמרים לצורכי אבטחה ומניעת שימוש לרעה נמחקים לאחר 60 ימים, יומני שגיאות לאחר 90 ימים, ותוכן של הודעות דוא״ל שנשלחו לאחר 30 ימים. אסימוני גישה בכתובות שהתבקשו ובכתובות מפנות, כגון אלה של קישורי דוחות או פורטלים, מופיעים ברישומי הגישה לדפים רק בצורה מוסווית.
• ההסכמה למסמכי החוזה נשמרת עם הגרסה שהוצגה, סכום הביקורת שלה, המועד, כתובת ה-IP ומזהה הדפדפן.
• ניתן לצרף ליומני ראיות חותמת זמן מרשות חותמות זמן חיצונית; רק סכום ביקורת של התוכן מועבר אליה, ולא התוכן עצמו.

7. זמינות ועמידות

7.1 גיבוי

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

7.2 ניטור

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

7.3 שינויים ופריסה

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

8. מחיקה ותקופות שמירה

• ריצת מחיקה בכל לילה אוכפת את התקופות המצוינות במדיניות הפרטיות ובהסכם לעיבוד מידע. היא קוראת את אותן הגדרות שמהן נלקחים המספרים בטקסטים; לכן, ביחס לתקופות אלה, הטקסט וההתנהגות אינם שונים.
• תוצאות בדיקות, לרבות צילומי מסך, נמחקות לאחר 13 חודשים (האחרונה לכל דומיין נשארת), נתוני הרחבות לאחר 13 חודשים, יומני מסירת התרעות לאחר 90 ימים ופניות לתמיכה לאחר 24 חודשים.
• הסרת דומיין מוחקת את המידע של הדומיין, לרבות בדיקות, טפסים, ממצאים, צילומי מסך, דוחות, משימות, יעדי התרעות ויומנים, אירועים, נתוני מסירה, פרטי כניסה לסריקה מאחורי כניסה לחשבון וראיות.
• מחיקת חשבון מתבצעת מייד; סביבות עבודה ללא חברים נוספים נמחקות עם המידע שלהן, וסביבות עבודה עם חברים נוספים מועברות לחבר אחר, בעדיפות למנהלים, ומתוכם לבעל הוותק הארוך ביותר. עד לפקיעת תקופות השמירה שלהם נשארים הפריטים הבאים: היומנים שרשומותיהם שומרות את מספר החשבון הישן, שכבר אינו מפנה לחשבון קיים כלשהו, לרבות רשומת המחיקה, וכן הודעות דוא״ל שנשלחו, הוכחת כריתת החוזה, פניות לתמיכה, דוחות של בדיקות לקוחות פוטנציאליים (עד 90 ימים) ונתוני חיוב אצל Stripe; הפרטים מופיעים במדיניות הפרטיות.
• מידע שנמחק נשאר בגיבויים עד לפקיעתם לאחר 14 ימים. לא מתבצעת מחיקה ממוקדת בתוך גיבוי; אם גיבוי משוחזר, בקשות מחיקה מאוחרות יותר הידועות לנו מבוצעות שוב ידנית.

9. ארגון ובחינה

• אנשים: השירות מופעל כיום על ידי הבעלים עצמו. אנשים נוספים מקבלים גישה רק לאחר התחייבות לסודיות ורק בהיקף הנחוץ, והם מעבדים מידע רק לפי הוראותינו (סעיף 29 וסעיף 32(4) ל-GDPR).
• מעבדי משנה: אנו מתקשרים איתם רק לאחר בחינת הערבויות שלהם ובמסגרת חוזה לפי סעיף 28(4) ל-GDPR, ומפרטים אותם בדף מעבדי משנה; הפרטים מוסדרים בהסכם לעיבוד מידע.
• הפרות של אבטחת מידע אישי: אם הפרה של אבטחת מידע אישי משפיעה על מידע המעובד מטעם הלקוח, אנו מודיעים ללקוח ללא דיחוי בלתי מוצדק, ככל האפשר בתוך 48 שעות; הפרטים מוסדרים בהסכם לעיבוד מידע.
• דיווח על חולשות אבטחה: אנו מקבלים דיווחים בדף אבטחה ובאמצעות הקובץ /.well-known/security.txt.
• רשימת בדיקה להגדרה ולהשקה: באזור הניהול, רשימת בדיקה מודדת את מצב ההגדרות הרלוונטיות לאבטחה, כגון גיבוי, מנהלים ללא גורם שני, הגדרת דוא״ל ואות חיים, ומציגה חריגות.
• בחינת אמצעים אלה (סעיף 32(1)(d) ל-GDPR): בכל שינוי משמעותי בשירות, לאחר כל אירוע אבטחה, וביתר המקרים לפחות פעם בשנה. במסגרת זו אנו בוחנים אם האמצעים יעילים ועדיין מתאימים לסיכונים, ומתעדים את התוצאה בגרסה חדשה של דף זה, או, אם דבר אינו משתנה, בציון תאריך הבחינה בסעיף 11. באופן שוטף, רשימת הבדיקה להגדרה ולהשקה מודדת את מצב ההגדרות שהיא מכסה.
• ביקורות חיצוניות: כיום לא מוזמנות בדיקות חדירה חיצוניות, ואין הסמכות אבטחה. הדבר מצוין כאן כדי שאיש לא יניח שהן קיימות.

10. מתוכנן, טרם יושם

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

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

11. מצב וגרסה

• גרסה 1.1 · עודכן לאחרונה: 22 באוקטובר 2026 · במקרה של הבדלים בין גרסאות השפה, הנוסח הפולני גובר במקום הנוסח הגרמני; אין שינוי אחר.
• גרסה 1.0 · עודכן לאחרונה: 11 באוקטובר 2026 · גרסה ראשונה כדף נפרד; קודם לכן נספח 2 להסכם לעיבוד מידע. תוקן בהשוואה לנספח הקודם: בדיקת השחזור מתבצעת מדי שבוע, הגיבויים נמצאים באותו שרת, לא מורצת חבילת בדיקות אוטומטית לפני כל פריסה, והחיבורים ברשת הפנימית אינם מוצפנים לכל אורכם. תוארו לראשונה: הצפנת פרטי הכניסה לסריקה מאחורי כניסה לחשבון, בידוד הסורק, השגחה הדדית והתרעת שגיאה.
• שינויים מתפרסמים עם מספר גרסה חדש כאן ובסקירה שינויים במסמכי החוזה; על כל החלשה של אמצעים חלה תקופת ההודעה המוקדמת של ההסכם לעיבוד מידע.
• במקרה של הבדלים בין גרסאות השפה, הנוסח הפולני גובר.