אבטחה

סביבת ייצור

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

בידוד דיירים, עם ראיות

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

1. גבול: כל בקשה מאומתת חייבת להתפענח לדייר, אחרת היא נדחית בקצה.
2. הקשר הבקשה: זהות הדייר נקשרת לבקשה ומופצת לכל שכבה מתחת — לעולם לא מועברת ידנית.
3. שאילתות: כל גישה לנתונים תחומה במפורש לדייר המבקש.
4. בסיס נתונים: מדיניות אבטחה ברמת שורה על כל טבלה מרובת-דיירים אוכפת את אותו גבול בתוך Postgres עצמו — אפילו בדיקה שהוחמצה היפותטית למעלה לא תוכל לחצות אותו.

זה נבדק, לא נטען: אבטחה ברמת שורה מוכחת בחבילת אינטגרציה שרצה מול בסיס נתונים Postgres אמיתי, ומטריצת בדיקות לילית מנסה קריאות, כתיבות, גישה ללוגים, גישה לסודות וגישה לחיפוש וקטורי בין דיירים — נדרש מעבר של כל בדיקה לפני כל פריסה. סוקרי אבטחה יכולים לבקש את חבילת הראיות המלאה בכתובת admin@syncanix.com.

הצפנה

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

כל הנתונים במעבר משתמשים ב-TLS 1.3 כמינימום. אתר השיווק, לוח הבקרה של הלקוח בכתובת app.syncanix.com ונקודת הקצה של ה-API מפנים כולם HTTP ל-HTTPS ואוכפים HSTS עם max-age של שנתיים כולל תת-דומיינים, עם preload. נתמך BYOK (הבאת מפתח משלך) בדרגת enterprise — מפתחות שהלקוח מספק משמשים למעטפת הנתונים של הלקוח מבלי שיופיעו אי-פעם בפלט היומנים של Syncanix.

זהות ואימות

האימות של לוח הבקרה מנוהל על ידי Auth0. כל נקודת קצה של ה-API מוגנת בשכבת אימות שמאמתת את חתימת ה-JWT מול נקודת הקצה JWKS של הספק, מאמתת את הקהל (audience) ואת המנפיק (issuer), ודוחה אסימונים שפג תוקפם. ההגנה מופעלת כברירת מחדל; נקודת קצה היא ציבורית רק כשהיא מסומנת במפורש. אין מצב כשל מסוג "שכחתי להוסיף אימות" — ברירת המחדל נאכפת.

הרשאה

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

IAM והרשאות מינימליות

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

אבטחת היישום

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

כותרות אבטחה של HTTP נשלחות בכל תגובה המופנית ללקוח:

• Content-Security-Policy עם רשימת היתר קפדנית (Auth0, מקור עצמי, ללא סקריפטים מוטבעים).
• Strict-Transport-Security: max-age=63072000; includeSubDomains; preload.
• X-Frame-Options: DENY (הגנה מפני clickjacking).
• X-Content-Type-Options: nosniff.
• Referrer-Policy: strict-origin-when-cross-origin.
• Permissions-Policy: מיקום גאוגרפי, מיקרופון ומצלמה — כולם נדחים כברירת מחדל.

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

ניהול סודות

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

תיעוד וביקורת

היומנים הם JSON מובנה עם שמירה של 14 יום כברירת מחדל. כל שורת יומן נושאת מזהה מתאם (מזהה בקשה) כך שניתן לשחזר את מסלולו של משתמש יחיד מקצה לקצה. רשימת הסתרה ממסכת אוטומטית את השדות token / password / secret / authorization; מידע אישי מלא לעולם אינו מגיע אל מנגנון התיעוד. כשלי אימות מפיקים שורת WARN עם כתובת ה-IP של המקור והסיבה — לעולם לא עם תוכן האסימון.

היגיינת תלויות

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

הסמכות וביקורות

איסוף הראיות עבור SOC 2 Type I מתחיל באמצעות Vanta בחודש שלאחר ההשקה המסחרית של Syncanix, עם דוח Type I המתוכנן לרבעון השלישי של 2026. SOC 2 Type II עוקב כעבור כ-9 חודשים. ראיות ISO 27001 נאספות במקביל (חפיפת בקרות של 70-80% עם SOC 2) — ההסמכה מתוכננת לרבעון הרביעי של 2026. סטטוס תאימות מלא →

תגובה לאירועים

דיווח על פגיעויות נשלח אל admin@syncanix.com — מאושר בקבלה תוך 24 שעות וממוין תוך 72 שעות. הפרות מאומתות בעלות השפעה על לקוחות מדווחות ללקוחות המושפעים תוך 24 שעות מרגע האישור, בהתאם להתחייבות לפי סעיף 33 של ה-DPA. ספר הפעלה מתועד לתגובה לאירועים נבחן ברבעון.