אבטחה
עודכן ב־2026-09-22
העמוד הזה מתאר איך המערכת מגנה על הנתונים, ומה הגבולות של ההגנה
הזו. עמוד אבטחה שמבטיח הכל אינו עמוד אבטחה.
בידוד בין חברות
כל חברה רואה את הנתונים של עצמה בלבד. זה לא מסתמך על סינון
במסך, אלא נאכף בבסיס הנתונים עצמו: לכל טבלה יש כלל הרשאה שמצמיד
כל שורה לחברה, והוא חל על כל בקשה – גם כזו שנשלחה ישירות אל השרת,
לא דרך המערכת. קוד שנכתב בעתיד ויפספס תנאי סינון עדיין לא יחזיר
נתונים של חברה אחרת.
מעבר לכך, עמודות רגישות נשמרות בהרשאת כתיבה נפרדת: מצב המנוי,
התוכנית ותאריך התוקף אינם ניתנים לשינוי מהדפדפן בשום צורה – רק
השרת כותב אותם, בתגובה לאישור מספק התשלומים. גם סטטוס של קריאת
שירות והתשובה עליה נכתבים בצד שלנו בלבד.
בידוד בין חברות נבדק בבדיקות אוטומטיות שרצות על כל שינוי בקוד,
ובהן ניסיונות גישה מכוונים מחברה אחת לנתוני חברה אחרת.
סיסמאות
- אף אחד אצלנו אינו יכול לראות סיסמה. הסיסמאות
נשמרות מגובבות (hashed) בשכבת האימות של Supabase.
- גם מנהל בחברה אינו קובע סיסמה לעובד. העובד
מקבל קישור בדואר וקובע סיסמה בעצמו. זה לא רק נוח – זה מונע מצב
שבו סיסמה של עובד עוברת בוואטסאפ ונשארת שם.
- קישור הזמנה וקישור איפוס הם חד-פעמיים ופגים. קישור שנצרך
כבר אינו עובד, והאסימון נמחק מהכתובת מיד כדי שלא יישאר
בהיסטוריית הדפדפן.
- אורך מינימלי של 6 תווים נאכף בשרת, לא רק במסך.
הרשאות לפי תפקיד
שלושה תפקידים, וההבדל ביניהם נאכף בשרת:
| תפקיד | מה מותר |
|---|
| בעלים | הכל, כולל המנוי והחיוב |
| מנהל | סידורים, עובדים, סניפים, הגדרות ומשתמשים – ללא חיוב |
| עובד | המשמרות שלו והבקשות שלו בלבד. הוא אינו רואה את הסידור המלא, אינו רואה עובדים אחרים, ואינו יכול לערוך דבר |
עובד מעדכן את הבקשות שלו דרך פונקציות מוגדרות בשרת שבודקות שהוא
אכן מעדכן את עצמו, ולא דרך כתיבה חופשית לטבלה. גם אם ינסה לשלוח
בקשה משלו ישירות לשרת, הוא לא יוכל לשנות בקשה של אדם אחר, לאשר
לעצמו בקשה, או להגיש אחרי מועד הסגירה שהמנהל קבע.
העברה ואחסון
- כל התעבורה מוצפנת ב-HTTPS.
- הנתונים מאוחסנים ב-Supabase באזור [DATA_REGION], עם הצפנה
באחסון וגיבויים מנוהלים מצד הספק.
- מפתח הניהול של בסיס הנתונים קיים רק בשרת, כמשתנה סביבה, ואינו
מגיע לדפדפן בשום מצב. פעולות שדורשות אותו – למשל הזמנת משתמש
חדש – רצות בצד השרת ומאמתות מי הקורא לפני שהן פועלות.
- פרטי אמצעי תשלום אינם עוברים בשרתים שלנו ואינם נשמרים בהם.
מה איננו עושים
- אין באתר ובמערכת אף קובץ Cookie, אף כלי אנליטיקה ואף פיקסל
של צד שלישי.
- אין מעקב מיקום, אין שעון נוכחות ואין ניטור עובדים.
- איננו מוכרים נתונים ואיננו משתפים אותם עם מפרסמים.
מה באחריותך
החלק הזה אינו קטן, ולכן הוא כתוב במפורש:
- סיסמאות חזקות, ולא כאלה שחוזרות משירותים אחרים.
- להשבית משתמש שסיים לעבוד – כל זמן שהוא פעיל, הוא נכנס.
- לתת תפקיד מנהל רק למי שצריך לראות את כל הסידור ואת כל
העובדים.
- לא להזין בשדות החופשיים (הערה על עובד, סיבה לבקשה) מידע
רפואי או אישי מעבר לנדרש.
מצאת בעיה?
אנחנו רוצים לשמוע, ואנחנו לא נתייחס לדיווח כאל תקיפה:
support@setshifts.com. נאשר קבלה
תוך 48 שעות ונעדכן אותך עד שהעניין נסגר. אם אירוע אבטחה יפגע
בנתונים של לקוח, נודיע ללקוחות שנפגעו ישירות ובלי לחכות שישאלו.
מה עוד לא קיים
כדי שהתמונה תהיה מלאה: אין עדיין אימות דו-שלבי, אין יומן פעולות
(audit log) שנגיש ללקוח, ואין תקן SOC 2 או ISO 27001. אלה דברים
שמתוכננים, ולא דברים שיש.
Security
Updated 2026-09-22
This page describes how the system protects your data, and the
limits of that protection. A security page that promises everything is
not a security page.
Isolation between companies
Each company sees only its own data. This does not rely on
filtering in the screen; it is enforced by the database itself. Every
table carries a permission rule that ties each row to a company, and
it applies to every request – including one sent straight to the
server rather than through the app. Code written in future that
forgets a filter still cannot return another company's data.
Beyond that, sensitive columns have separate write permissions:
subscription state, plan and valid-until date cannot be changed from
the browser in any way – only the server writes them, in response to
confirmation from the payment provider. The status of a support
ticket and its reply are likewise written only on our side.
Isolation between companies is covered by automated tests that run
on every code change, including deliberate attempts to read one
company's data from another.
Passwords
- Nobody here can see a password. Passwords are
stored hashed in Supabase's authentication layer.
- A manager does not set a password for staff
either. Each person gets a link by email and chooses their
own. That is not only convenient – it prevents a staff password
being sent over WhatsApp and living there forever.
- Invitation and reset links are single-use and expire. A link
that has been used no longer works, and the token is stripped from
the address immediately so it does not sit in browser history.
- A six-character minimum is enforced on the server, not only in
the screen.
Permissions by role
Three roles, and the difference between them is enforced on the
server:
| Role | What it can do |
|---|
| Owner | Everything, including the subscription and billing |
| Manager | Schedules, staff, locations, settings and users – no billing |
| Staff | Their own shifts and their own availability, and nothing else. They cannot see the full schedule, cannot see other people, and cannot edit anything |
Staff update their own availability through defined server
functions that check they are updating themselves, not by writing
freely to a table. Even sending a handcrafted request straight to the
server, they cannot change someone else's request, approve their own,
or submit after the deadline the manager set.
In transit and at rest
- All traffic is encrypted over HTTPS.
- Data is stored in Supabase in the [DATA_REGION] region, with
encryption at rest and provider-managed backups.
- The database admin key exists only on the server, as an
environment variable, and never reaches the browser. Operations
that need it – inviting a new user, for instance – run server-side
and verify who is calling before they act.
- Payment details do not pass through our servers and are not
stored there.
What we do not do
- There is not a single cookie, analytics tool or third-party
pixel on the site or in the app.
- No location tracking, no time clock, no staff monitoring.
- We do not sell data and do not share it with advertisers.
What is on you
This part is not small, so it is spelled out:
- Strong passwords, not ones reused from other services.
- Deactivate a user who has left – while they are active, they
can sign in.
- Give the manager role only to people who should see the whole
schedule and everyone on it.
- Keep medical or personal details out of the free-text fields (a
note on a staff card, a reason for a request) beyond what is
needed.
Found a problem?
We want to hear about it, and we will not treat a report as an
attack: support@setshifts.com. We
acknowledge within 48 hours and keep you updated until it is closed.
If a security incident affects customer data, we tell the affected
customers directly, without waiting to be asked.
What does not exist yet
So the picture is complete: there is no two-factor authentication
yet, no customer-visible audit log, and no SOC 2 or ISO 27001
certification. Those are planned, not present.