אבטחה

סביבת ייצור

סביבת הייצור פועלת באיחוד האירופי 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 (הבאת מפתח משלך) זמין בכל תוכנית — לקוחות יכולים לנתב את תעבורת המודל דרך מפתח הספק שלהם, שלעולם אינו מופיע בפלט היומנים של 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 נאכף בשתי שכבות עצמאיות, לכל אחת רשימת היתר מפורשת של מקורות. מקור עם תו כללי נדחה בזמן הבנייה — פריסת ייצור ללא מקורות מפורשים אינה יכולה להתקדם.

אבטחת בינה מלאכותית סוכנותית והגנה מפני הזרקת פרומפט

וידג'ט הצ'אט ושרת ה-MCP לכל דייר ממופים אל OWASP Top 10 ליישומים סוכנותיים 2026 (ASI01–ASI10). היריב העיקרי שאנו מתכננים מולו הוא תוכן לא מהימן שמגיע למודל — מטען הזרקת פרומפט המוסתר במסמך שאוחזר, בתוצאת כלי או בהקשר הדף — המנסה לחטוף את הסוכן, לחלץ נתונים או להטעות את המשתמש.

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

הבקרות שתומכות בעמדה זו:

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

מודל האיומים המנוקה המלא ותוצאות ההערכה היריבה — מפת OWASP Agentic Top 10 יחד עם מתודולוגיית הצוות האדום שלנו — זמינים לצוותי אבטחה לפי בקשה בכתובת admin@syncanix.com תחת הסכם סודיות הדדי.

ניהול סודות

סודות הייצור שוכנים במנהל סודות ייעודי תחת מרחב שמות לכל סביבה. תצורה שאינה סודית שוכנת במאגר פרמטרים נפרד. הסודות נחשפים לעומסי העבודה בעת האתחול — הם לעולם אינם שוכנים בבקרת המקור. הרשאות מסד הנתונים מתחלפות אוטומטית; אסימוני צד שלישי (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 — מאושר בקבלה תוך 3 ימי עסקים וממוין תוך 7 ימים. הפרות מאומתות בעלות השפעה על לקוחות מדווחות ללקוחות המושפעים תוך 24 שעות מרגע האישור, בהתאם להתחייבות לפי סעיף 33 של ה-DPA. ספר הפעלה מתועד לתגובה לאירועים מתורגל מדי רבעון.