מרכז אמון ואבטחה
תיעוד שקוף של פרקטיקות האבטחה, בידוד הנתונים, התאימות לתקנים, וההיערכות לאירועי אבטחה. כל יכולת מסומנת לפי מצבה האמיתי - פעיל, בפיתוח, או מתוכנן
1. מערכת הגנה רב-שכבתית
כל בקשה עוברת חמש שכבות הגנה עצמאיות. כשל בשכבה אחת נחסם על ידי הבאות
apps/www/functions/_middleware.js:9-26 - HSTS, CSP, X-Frame-Options DENY, Referrer-Policy, Permissions-Policy
2. בידוד נתונים בין לקוחות
הסוד שמבדיל אנטרפרייז אמיתי משירותי SaaS רגילים - בידוד ברמת הבסיס נתונים, לא רק ברמת השאילתה
| חבילה | מודל בידוד | הגנה בפועל | סטטוס |
|---|---|---|---|
| Starter / Professional | בסיס נתונים משותף, סינון לפי tenant_id בכל שאילתה | הגנה ברמת היישום - באג חמור באפליקציה יכול תיאורטית לחשוף נתוני לקוח אחר. אנחנו אוכפים זאת בסקירות קוד ובדיקות | פעיל |
| Enterprise | בסיס נתונים פיזי נפרד לכל לקוח (Database per tenant) | אי אפשר טכנית לקרוא נתוני לקוח אחר - גם באג חמור באפליקציה לא יחצה את גבול הבסיס. הסטנדרט של סנואופלייק וסיילספורס | בפיתוח |
| Enterprise+ | הצפנה במפתח לקוח (Bring Your Own Key) | הלקוח מחזיק במפתח ההצפנה. שלילת המפתח על ידו - מנתקת אותנו מהיכולת לקרוא את הנתונים | מתוכנן |
schema/001_initial.sql:14-15 - עמודה tenants.db_id מוכנה להחזיק מזהה של D1 נפרד לכל לקוח. החלטה אסטרטגית רשומה ב-CLAUDE.md (החלטה 1 - רמה 3)
3. אימות וזהויות
איך מוודאים שמי שמתחבר באמת מי שהוא טוען להיות
פעילסיסמאות מוצפנות
הסיסמה לעולם לא נשמרת כטקסט. השרת שומר רק חתימת SHA-256 עם מלח ייחודי לפרויקט (סוד שרת). השוואה ברגע הכניסה מתבצעת על החתימה בלבד
פעילJWT חתום
אחרי כניסה מוצלחת ניתן אסימון HMAC-SHA256 שתקף ל-24 שעות. כל בקשה אחר כך נבדקת בזמן קבוע ללא גישה לבסיס נתונים. השוואת חתימה עמידה לתקיפת זמן (constant-time)
פעילעוגיית HttpOnly
האסימון נשמר בעוגייה עם HttpOnly, Secure, ו-SameSite=Lax. אי אפשר לקרוא אותה מ-JavaScript בדפדפן, מה שחוסם תקיפות XSS שמטרתן גניבת סשן
פעילהגבלת קצב כניסות
חמישה ניסיונות כניסה כושלים בחמש עשרה דקות לפי כתובת IP - וההמשך נחסם עד שהחלון מתאפס. רישום כל כישלון ב-audit_log
בפיתוחאימות דו-שלבי (TOTP)
העמודה two_factor_enabled מוכנה בטבלת המשתמשים. המימוש עם Google Authenticator והאכיפה הגורפת מתוכננים לפני קליטת לקוח אנטרפרייז ראשון
מתוכנןSSO לאנטרפרייז (SAML / OIDC)
חבילת אנטרפרייז תקבל יכולת חיבור למערכת זהויות ארגונית (Okta, Azure AD, Google Workspace). תאריך השקה ייקבע יחד עם הלקוח הראשון שיבקש
apps/www/functions/lib/auth.js:22-64 sha256Hex + HMAC-SHA256 + השוואה constant-time | functions/api/auth/login.js:10,31,46 rate limit + password verify + JWT issue
4. הגנת פרטיות (היערכות ל-GDPR)
זכויות שעומדות ללקוחות הקצה של הלקוחות שלנו, גם אם החוק עדיין לא מחייב
פעילגישה לנתונים אישיים בלבד
כל שאילתה במערכת מסוננת לפי tenant_id ולפי user_id המחובר. משתמש אחד לא יכול לראות נתונים של משתמש אחר, גם באותו לקוח
בפיתוחמחיקת חשבון מלאה
תהליך מחיקה תוך 30 ימים מבקשה - כולל בסיס נתונים, גיבויים, ויומני ביקורת ישנים מעל הסף החוקי. זכות "להישכח"
בפיתוחייצוא מלא של נתוני לקוח
לקוח יוכל להוריד את כל הנתונים שלו בפורמט מובנה (JSON או CSV) בכל רגע. ניידות נתונים (data portability) לפי GDPR סעיף 20
מתוכנןהסמכת GDPR רשמית
תהליך הסמכה רשמי וביקורת חיצונית. מועד ההסמכה ייקבע על פי דרישת הלקוח האנטרפרייז הראשון שיבקש זאת בכתב - לא מוכרז תאריך בלי התחייבות אמיתית
5. ביקורת ושקיפות
כל פעולה משמעותית במערכת מתועדת ונשמרת. שום שינוי לא קורה ללא עקבות
פעיליומן פעולות מלא
טבלת audit_log רושמת לכל פעולה: מזהה משתמש, מזהה לקוח, סוג פעולה, כתובת IP, user-agent, מצב לפני, מצב אחרי. כניסה, יציאה, וכישלון כניסה - כולם נכנסים
בפיתוחשמירה ל-12 חודשים
מדיניות שמירה אוטומטית של רשומות ביקורת ל-12 חודשים. רשומות ישנות יותר ירדו אוטומטית (אלא אם נדרשת שמירה חוקית ארוכה יותר)
בפיתוחייצוא יומן ביקורת (Enterprise)
לקוחות אנטרפרייז יוכלו לייצא את יומן הביקורת של הלקוח שלהם לקובץ JSON, או לזרום אותו ל-SIEM פנימי שלהם (Splunk, Datadog וכדומה)
מתוכנןSOC 2 Type II
ביקורת SOC 2 Type II דורשת לפחות שישה חודשי תפעול עם בקרות מתועדות. תאריך התחלת הביקורת ייקבע עם רואה החשבון אחרי שיש לקוח אנטרפרייז משלם - לא מוכרז תאריך בלי התחייבות
מתוכנןISO 27001
מסלול הסמכה ל-ISO 27001 מקביל ל-SOC 2. הסטנדרט הבינלאומי לניהול אבטחת מידע. תאריך ייקבע עם גוף מסמיך
schema/001_initial.sql:220-235 - טבלת audit_log עם כל השדות | apps/www/functions/lib/auth.js:105-118 פונקציית logAudit | functions/api/auth/login.js:33,63 רישום login_failed + login_success
6. תגובה לאירועי אבטחה
תהליך מסודר שמופעל מהרגע הראשון של חשד לבעיית אבטחה
סיווג חומרה
נמוך / בינוני / גבוה / קריטי תוך שעה
בידוד
חסימה מיידית של המקור, השעיית סשנים פעילים אם נדרש
חקירה
שחזור מ-audit_log, איסוף ראיות, זיהוי שורש הבעיה
תיקון
פיתוח תיקון, בדיקת רגרסיה, פריסה
דיווח ללקוח
תוך 72 שעות אם נחשפו נתונים אישיים (תואם GDPR)
פוסט-מורטם
פרסום ציבורי בעמוד הסטטוס לאחר תיקון מלא
בפיתוחתיבת דיווח security
כתובת [email protected] תוקם להגעה לחוקרי אבטחה ולקוחות. דיווחים יטופלו בתעדוף מקסימלי
מתוכנןתכנית Bug Bounty
תגמול כספי לחוקרי אבטחה שיגלו פגיעויות. השקה אחרי שלב הביטא, כשמסת השירות מצדיקה
פעילהיסטוריית אירועים
נכון להיום, אין חשיפת פגיעות (CVE) ידועה במערכת. אם וכאשר תהיה - היא תפורסם בעמוד הסטטוס תוך 72 שעות מהתיקון
7. תשתית והמשכיות עסקית
המערכת רצה על Cloudflare - אחת מתשתיות הענן המוכחות ביותר בעולם
פעילפלטפורמת ענן
Cloudflare Pages, Workers, D1 ו-KV. תשתית עם מעבד נתונים-משנה שמחזיק בהסמכות SOC 2, ISO 27001, ו-GDPR. הוסכמי DPA זמינים
פעילהצפנה במנוחה ובמעבר
כל הנתונים מוצפנים במנוחה (ניהול Cloudflare) ובמעבר (TLS 1.3). פנייה לא מוצפנת לאתר מופנית אוטומטית ל-HTTPS
פעילגיבוי יומי אוטומטי
Cloudflare D1 מבצע גיבויים אוטומטיים. ניתן לשחזר את הבסיס לכל נקודה בזמן ב-30 הימים האחרונים (Point-in-time recovery)
בפיתוחבחירת אזור (EU / US)
לקוחות אנטרפרייז יוכלו לבחור אזור גיאוגרפי לאחסון הנתונים שלהם. ברירת מחדל כיום - אזור Cloudflare הקרוב גיאוגרפית ללקוח
מתוכנןיעדי שחזור (RTO / RPO)
יעד החלמה מתקלה (RTO) פחות מ-4 שעות, יעד אובדן נתונים (RPO) פחות משעה אחת. היעדים יעוגנו בהסכם רמת שירות (SLA) ללקוחות אנטרפרייז כשהמודל ייכנס לתוקף
מתוכנןעמוד סטטוס פומבי
עמוד status.mindsetaisys.com יציג בזמן אמת זמינות, חביון, ואירועים פתוחים. פרוטוקול תקשורת לאירועים מפורסם שם
apps/www/wrangler.toml:9-19 - PORTAL_KV וגדרות D1 (mindsetaisys-portal-db) מוגדרים ופועלים