תשובה קצרה: אם במאגר המידע של האפליקציה שלכם קרה אירוע אבטחה חמור, תקנה 11(ד) לתקנות הגנת הפרטיות (אבטחת מידע) קובעת שמודיעים לרשות להגנת הפרטיות "באופן מיידי", ומדווחים גם על הצעדים שננקטו. ב-21.7.2026 הרשות הטילה עיצום כספי של 256,000 ש"ח על קופת חולים מאוחדת שדיווחה כחודשיים אחרי שידעה על אירוע, לראשונה מאז שתיקון 13 נכנס לתוקף. הרשות כתבה שמדווחים כבר על מה שידוע, ומשלימים פרטים אחר כך. המדריך הזה מסביר מה בודקים טכנית באפליקציה שנבנתה ב-Lovable, Base44 או Supabase, כדי שיהיה לכם מה לדווח ומה לתקן.
שימו לב: זה מדריך טכני, לא ייעוץ משפטי. אם השאלה היא האם האירוע שלכם מחייב דיווח, ומה בדיוק כותבים, מתייעצים עם עורך דין שעוסק בהגנת הפרטיות.
מה הרשות כתבה על העיצום הראשון
לפי ההודעה של הרשות:
- הקופה ידעה על האירוע בנובמבר 2025 ודיווחה לרשות ב-27.1.2026.
- העיצום הוטל לפי תקנה 11(ד), על אי-דיווח מיידי.
- עמדת הרשות: חובת הדיווח קמה כשמגלים את האירוע. המתנה עד שכל הבדיקות מסתיימות "מרוקנת מתוכן את דרישת המיידיות". נדרש דיווח ראשוני לפי מה שידוע, ואת הפרטים משלימים אחר כך.
המשמעות המעשית לצוות טכני: את הבירור לא עושים לפני הדיווח, אלא במקביל אליו. הבירור הטכני נותן לכם את מה שמשלימים.
האם זה בכלל "אירוע אבטחה חמור"?
לפי ההגדרה בתקנות (הנוסח המלא), זה תלוי ברמת האבטחה של המאגר:
| רמת האבטחה של המאגר | מה נחשב אירוע אבטחה חמור |
|---|---|
| גבוהה | כל שימוש במידע בלי הרשאה או מעבר להרשאה, או פגיעה בשלמות המידע |
| בינונית | אותו דבר, אבל רק כשזה נוגע לחלק מהותי מהמאגר |
| בסיסית, או מאגר שמנוהל בידי יחיד | לא נכלל בהגדרה |
איזו רמה חלה על המאגר שלכם, לפי סוג המידע, מספר האנשים ומספר בעלי ההרשאות, היא שאלה לעורך הדין. מה שהצוות הטכני יכול לעשות הוא לענות מהר על השאלות שהוא ישאל: איזה מידע יש בכל טבלה, כמה רשומות, ומי יכול לגשת אליהן.
מה בודקים מיד, לפני שנוגעים בשום דבר
הכותרת של השלבים כאן היא "מיד" ולא מספר שעות. התקנה לא קובעת שעון, אבל הרשות מצפה לדיווח ראשוני כשמגלים, והשלבים האלה הם מה שהצוות הטכני עושה באותו זמן.
1. שומרים ראיות
לפני שמתקנים, שומרים את מה שיעזור להבין מה קרה:
- הבקשה שחשפה את המידע. אם מישהו דיווח לכם על חשיפה, שמרו את הבקשה המדויקת, את התגובה, ואת הזמן.
- לוגים. ב-Supabase, בלוח הבקרה, שמרו את הלוגים של ה-API, של ההתחברות ושל Postgres לטווח הזמן הרלוונטי. משך השמירה של הלוגים תלוי בתוכנית, ולכן מייצאים אותם מיד ולא מחכים.
- מצב ההרשאות לפני התיקון. צלמו או ייצאו את מדיניות ה-RLS הנוכחית של כל טבלה. אחרי התיקון כבר לא תוכלו להראות מה היה פתוח.
2. עוצרים את החשיפה
- מפתח שדלף. אם מפתח
service_roleאו מפתח secret של Supabase הגיע לקוד צד-לקוח, למאגר קוד ציבורי או לקובץ שנשלח, מחליפים אותו אצל Supabase. מחיקה מהקוד לא מבטלת מפתח שכבר נחשף. - טבלה בלי RLS. מפעילים RLS ומגדירים מדיניות. הפירוט נמצא במדריך ל-RLS שלא עובד ב-Supabase.
- אפליקציית Base44. בודקים מי יכול לקרוא כל ישות (entity) והאם האפליקציה מוגדרת כציבורית. הפירוט נמצא במדריך האבטחה ל-Base44.
- מפתחות של צד שלישי. מפתחות של ספק תשלומים, שירות מייל או מודל AI שהיו באותו מקום מוחלפים גם הם.
3. מבינים מה דלף
השאלות שהדיווח יצטרך לענות עליהן, ואיך עונים עליהן טכנית:
- אילו טבלאות ואילו עמודות? בלוגים של ה-API מסננים לפי הנתיב
/rest/v1/ושם הטבלה, בטווח הזמן שבו היא הייתה פתוחה. - כמה רשומות? סופרים את הרשומות שהיו בטבלה בזמן החשיפה, ולא רק את אלה שאתם יודעים שנקראו.
- ממתי? מתי השינוי שפתח את הטבלה נכנס. בקבצי המיגרציה או בהיסטוריית הקוד אפשר לראות מתי RLS כובה או מתי מפתח הגיע לקוד.
- מי ניגש? כתובות IP ובקשות עם המפתח הציבורי בלי משתמש מחובר, שקראו טבלאות של מידע אישי.
4. רושמים ציר זמן
מתי גיליתם, מי גילה, מה עשיתם ומתי. לפי הרשות, החובה מתחילה בזמן הגילוי, ולכן הציר הזה הוא חלק מהדיווח ולא רק תיעוד פנימי.
איך מדווחים
- הטופס: דיווח על אירוע אבטחה חמור במאגר מידע באתר הרשות.
- גם אם מישהו אחר כבר יודע: לפי הטופס, מדווחים גם אם המשטרה, מערך הסייבר או רגולטור אחר הודיעו לכם על האירוע.
- כופרה: הצפנה של מידע או מניעת גישה אליו נחשבות פגיעה בשלמות המידע.
- דיווח ראשוני, ואחר כך השלמות. מה שידוע עכשיו, והצעדים שננקטו, כמו שהתקנה דורשת.
למה זה נפוץ באפליקציות שנבנו עם AI
כלי AI בונים מהר טבלאות, מסכים וחיבורים, אבל לא תמיד מגדירים מי רשאי לקרוא מה. שלושת הדפוסים שהכי נפוצים: טבלה שנוצרה בלי RLS, מפתח service_role שהגיע לקוד צד-לקוח, ומדיניות RLS שבודקת שהמשתמש מחובר אבל לא שהוא בעל הרשומה. את שלושתם אפשר לבדוק לפני שמישהו אחר מוצא אותם, עם בדיקת הדליפות החינמית ועם הצ'קליסט לפני השקה.
רוצים לדעת מה פתוח אצלכם לפני שמישהו אחר יגלה? בדיקה לפני השקה עוברת על ההרשאות, ה-RLS, המפתחות והתשלומים ומסתיימת בדוח בעברית עם תיקונים לפי סדר עדיפות. אם כבר קרה אירוע, שלחו לנו הודעה בוואטסאפ ונעזור בצד הטכני: מה לשמור, מה לסגור ומה דלף. את הצד המשפטי עושים עם עורך דין.
