איך Spun מצפין את הנתונים שלך
פירוט כנה, תרחיש-לפי-תרחיש, על מה מוצפן מקצה לקצה, מה מוצפן רק בהעברה, ומה חייב להיות קריא על ידי Spun כדי שהמוצר יעבוד.
במבט אחד
הצפנה לפי תרחיש
להלן כל סוג נתונים ש-Spun נוגע בו ובדיוק איך הוא מוגן. אנו מסמנים E2EE כ-כן רק כשאף מערכת של Spun לא יכולה לקרוא את התוכן.
| תרחיש | E2EE | הערות |
|---|---|---|
שיחת קול 1:1 (Spun → Spun) DTLS-SRTP (WebRTC) | כן | WebRTC טהור עמית-לעמית. מפתחות מוסכמים בין שני הקצוות — Spun לעולם לא מחזיק אותם. |
שיחת וידאו 1:1 (Spun → Spun) DTLS-SRTP (WebRTC) | כן | זהה לקול. ממסרי TURN רואים רק מנות מוצפנות כש P2P ישיר נכשל. |
שיחה קבוצתית (3+ משתתפים) TLS 1.2+ ל-SFU, DTLS-SRTP למדיה | לא | LiveKit Cloud SFU מפענח מדיה לניתוב למשתתפים אחרים. ארכיטקטורת SFU סטנדרטית. |
חדר תרגום (מצב P2P, ≤2 משתתפים) DTLS-SRTP (WebRTC) | כן | עובר ל-SFU אם משתתף שלישי מצטרף — ראה שורה למעלה. |
חדר תרגום (מצב SFU, 3+ משתתפים) TLS 1.2+ ל-SFU | לא | ל-LiveKit SFU יש גישה למדיה לתרגום ומיקסוס מחדש. |
הודעות WhatsApp (בתוך WhatsApp) Signal Protocol (Meta) | חלקי | WhatsApp עצמו מוצפן E2EE בין משתתפים. אבל ברגע שספק הגייטוויי שלך מקבל הודעות נכנסות בשמך, הגייטוויי ו-Spun רואים טקסט רגיל — כך עובדת תיבת דואר עסקית. |
הודעות WhatsApp (ב-Spun) TLS 1.2+ | לא | נדרש לתצוגת תיבת דואר, חיפוש, תכונות AI ואוטומציות. |
Spun Chat והודעות צוות TLS 1.2+ | לא | טקסט רגיל במנוחה כדי שהודעות יהיו ניתנות לחיפוש ועיבוד על ידי תכונות AI שהפעלת. |
קבצים מצורפים (תמונות, וידאו, מסמכים) TLS 1.2+ (Cloudflare R2 + S3 SigV4) | לא | R2 מנהל מפתחות. Spun חותם כתובות URL קצרות-חיים לגישה לכל ארגון. |
נתוני כרטיס תשלום TLS 1.2+ ישירות ל-Stripe | חלקי | Stripe Elements אוסף נתוני כרטיס ישירות בדפדפן — לעולם לא מגיע לשרתי Spun. אנחנו מקבלים רק מזהה לקוח אטום. |
פקודות ותפוקות AI TLS 1.2+ לספק AI | לא | נשלח ב-TLS ל-OpenAI / AssemblyAI / וכו׳. הסתרת מידע אישי (כשמופעלת) מסירה שדות רגישים לפני השליחה. |
גיבויי בסיס נתונים TLS 1.2+ | לא | הצפנת גיבוי מנוהל סטנדרטית. |
E2EE = הצפנה מקצה לקצה. "כן" אומר שגם Spun לא יכול לקרוא את הנתונים. "חלקי" אומר E2EE בתוך צד שלישי (Stripe, WhatsApp) אך גלוי ל-Spun לחלק שאנו מטפלים.
בהעברה
כל מה שנע בין הדפדפן שלך, השרתים שלנו וספקי המשנה שלנו מוצפן ב-TLS.
TLS 1.2+ בכל מקום על הקו
כל התעבורה דפדפן ↔ Spun, Spun ↔ גייטוויי WhatsApp, Spun ↔ OpenAI / AssemblyAI / Deepgram / Sarvam / Azure, Spun ↔ Stripe מוצפנת ב-TLS. גרסאות פרוטוקול ישנות מושבתות במאזן העומסים.
קצה מונחה על ידי Cloudflare
Cloudflare מסיים TLS בקצה ומצפין מחדש למקור. תעודות מקור מצמידות בקשות לשרתי Hetzner שלנו. הגנת WAF ו-DDoS תמיד פעילה.
כתובות URL חתומות קצרות-חיים
הורדות מדיה משתמשות ב-S3 SigV4 presigned URLs המוגבלות לאובייקט ספציפי ופגות תוקף בדקות. גם URL שדלף מפסיק לעבוד מהר.
במנוחה
נתונים מאוחסנים מוצפנים על ידי ספק הענן ומבודדים לכל ארגון על ידי אבטחה ברמת שורה של PostgreSQL.
PostgreSQL עם אבטחה ברמת שורה
כל טבלה המכילה נתוני דיירים משתמשת במדיניות RLS של PostgreSQL לאכיפת בידוד ארגון. גם שאילתה שבטעות חסרה מסנן ארגון נדחית ברמת בסיס הנתונים.
שכבת נתונים EU אחת
כל שרתי האפליקציה, PostgreSQL ו-Redis רצים ב-Hetzner נירנברג (גרמניה, EU). שכבת נתונים אחת, תחום שיפוט אחד. דיסקים מוצפנים AES-256 במנוחה.
Cloudflare R2 למדיה
תמונות, סרטונים, אודיו, מסמכים מאוחסנים ב-Cloudflare R2 עם הצפנת AES-256 בצד השרת. גישה מוגבלת על ידי URL חתום לכל ארגון ואובייקט.
שיחות קול ווידאו
מה E2EE אמיתי, מה לא, ולמה. אנחנו לא משווקים שיחות קבוצתיות כמוצפנות מקצה לקצה כי הן לא.
קול ווידאו 1:1 — E2EE אמיתי
כששני משתמשי Spun מתקשרים, השמע והוידאו מוצפנים ב-DTLS-SRTP מקצה לקצה בין שני הדפדפנים. שרת Spun מעביר רק איתות SDP. גם אם Cloudflare TURN ממסר (במקרה של NAT סימטרי, חומות אש), הוא רואה רק מנות מוצפנות.
שיחות קבוצתיות (3+) — מוצפן בהעברה, לא E2EE
שיחות קול/וידאו קבוצתיות וחדרי תרגום רב-משתתפים משתמשים ב-LiveKit Cloud כ-SFU. מדיה מוצפנת ב-DTLS-SRTP בין כל לקוח ל-SFU, אך ה-SFU מפענח בקבלה לניתוב למשתתפים אחרים. זו ארכיטקטורת SFU סטנדרטית ואינה מוצפנת מקצה לקצה.
חדרי תרגום — P2P קודם כשאפשר
חדרי תרגום מנסים P2P (E2EE) קודם כשרק שני משתתפים נוכחים, ועוברים ל-SFU כששלישי מצטרף או כשמכשירים מוגבלים מדי ל-P2P. מצב החיבור נראה בממשק השיחה.
למה אנחנו לא טוענים ל-E2EE מלא בשיחות קבוצתיות
LiveKit תומך במצב הצפנה מקצה לקצה אופציונלי (באמצעות Encoded Insertable Streams API) שמגן על המדיה גם מה-SFU. הוא לא מופעל כרגע בשיחות קבוצתיות של Spun — הוספתו דורשת מנגנון החלפת מפתחות בין משתתפים ותאימות דפדפן/קודק מאומתת לכל לקוח נתמך.
אם E2EE מלא לקבוצה הוא דרישה עבורך, צור איתנו קשר ב-[email protected] — זה במפת הדרך ונשתף סטטוס.
תשלומים וזהות
הנתונים הרגישים ביותר מטופלים על ידי מעבדים מתמחים כך ש-Spun לעולם לא רואה או מאחסן אותם.
נתוני כרטיס עוברים ישירות ל-Stripe
Stripe Elements אוסף מספרי כרטיס, CVC ותאריכי תפוגה בתוך iframe שנשלח ישירות ל-Stripe — עוקף את שרתי Spun לחלוטין. אנחנו מקבלים רק מזהה לקוח/אמצעי תשלום אטום. Stripe מאושר PCI-DSS Level 1.
סיסמאות מגובבות ב-Argon2
חשבונות אימייל/סיסמה משתמשים ב-Argon2id עם מלח לכל משתמש. אנחנו לא מחזיקים או מתעדים סיסמאות בטקסט רגיל. התחברות דרך Google Sign-In מאצילה אימות ל-Google לחלוטין — לא קיימת סיסמה ב-Spun לחשבונות אלה.
מפתחות API ו-webhooks חתומים
כל עומסי webhook של צד שלישי (WhatsApp, Stripe, תוספים) חתומים ב-HMAC-SHA256 ומאומתים בצד השרת. טוקני API לתוספים הם JWT קצרי-חיים (RS256) עם נקודת JWKS פומבית.
הודעות WhatsApp: המגבלות של E2EE
ה-E2EE של WhatsApp מגן על הודעות בזמן שהן בתוך התשתית של WhatsApp. ברגע שספק הגייטוויי שלך מקבל הודעה בשמך, הגייטוויי רואה טקסט רגיל. זה נכון לכל ספק WhatsApp Business API — כך עובדות תיבות דואר עסקיות.
שאלות נוספות?
לפרטים טכניים ספציפיים (cipher suites, רשויות תעודה, מדיניות רוטציית מפתחות וכו׳) או לבקשת מענה לשאלון אבטחה, שלח אימייל ל- [email protected].