אבטחה ב-Kodo

תשתית

Kodo רץ על Vercel לאחסון ולעיבוד, עם בסיס נתונים Postgres מנוהל (Neon) למידע של האפליקציה. כשאנחנו צריכים אחסון אובייקטים (למשל דוחות PDF בתוכניות Win), אנחנו משתמשים ב-Vercel Blob. איזור הפריסה העיקרי שלנו הוא ארצות הברית. Vercel מטפל בתעבורת ה-edge, בסיום ה-TLS ובהפחתת DDoS בקצה הרשת. Neon מטפל בשכפול בסיס הנתונים, בשחזור לנקודת זמן וגיבויים מנוהלים.

שני הספקים מפרסמים תיעוד אבטחה משלהם, שאפשר לקרוא ישירות: vercel.com/security ו- neon.tech/security. שניהם מאושרי SOC 2 Type II.

הצפנה

כל התעבורה בין הדפדפן שלך ל-Kodo מוצפנת ב-TLS 1.2 או גבוה יותר. אנחנו לא מקבלים חיבורים מעל HTTP רגיל. חיבורי בסיס הנתונים משרתי האפליקציה שלנו ל-Postgres גם הם מוצפנים ב-TLS. מידע במנוחה בבסיס הנתונים מוצפן ב-AES-256 על ידי ספק בסיס הנתונים. גיבויים מנוהלים מוצפנים באותו תקן.

אנחנו לא שומרים סיסמאות. אימות מטופל על ידי Clerk, שמשתמש ב-hashing סיסמאות בתקן תעשייתי ותומך באפשרויות מודרניות ללא סיסמה (passkeys, magic links, כניסה דרך רשת חברתית).

אימות וגישה

אימות משתמשי קצה מטופל על ידי Clerk. Clerk תומך באימות רב-שלבי (MFA) לחשבונות שמפעילים אותו, ואנחנו ממליצים להפעיל אותו. session-ים משתמשים ב-cookies מאובטחים, HTTP-only, עם דגלי Secure ו-SameSite מופעלים.

גישה פנימית למערכות ייצור מוגבלת לצוות הקטן של המהנדסים שצריך אותה כדי להפעיל את השירות. כל חבר צוות נכנס לקונסולות של ספקים דרך single sign-on עם MFA נדרש. גישה לבסיס נתוני ייצור נרשמת בלוג. אנחנו מסובבים אישורי גישה לפי לוח זמנים קבוע ומיד כשתפקיד של חבר צוות משתנה.

אבטחת אפליקציה

האפליקציה עוקבת אחר נהלי אבטחת אינטרנט סטנדרטיים:

• כותרות Content Security Policy כדי להגביל אילו סקריפטים ומשאבים הדפדפן יטען.
• Strict Transport Security (HSTS) כדי שהדפדפנים יסרבו לדבר עם Kodo מעל HTTP רגיל.
• cookies מאובטחים, HTTP-only, SameSite לכל מצב session.
• שאילתות בסיס נתונים מפרמטרות דרך ה-ORM שלנו. אנחנו לא בונים SQL בהשרשור מחרוזות, מה שסוגר את הדלת על injection במקור.
• אימות קלט בצד השרת בכל נקודת קצה של ה-API, באמצעות ספריות אימות סכמה.
• הגבלת קצב בנקודות קצה ציבוריות (כולל הבדיקה החינמית) כדי להאט התעללות וניסיונות credential stuffing.
• סריקת תלויות בכל pull request כדי שנשים לב כשלספרייה שאנחנו משתמשים בה יש פגיעות ידועה.

מעבדי צד שלישי

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

• Vercel לאחסון, עיבוד edge ו-TLS.
• Neon ל-Postgres מנוהל, גיבויים ושחזור לנקודת זמן.
• Clerk לאימות משתמשי קצה וניהול session.
• Stripe לעיבוד תשלומים. Stripe מאושרת PCI-DSS Level 1. אנחנו אף פעם לא רואים או שומרים מספרי כרטיס מלאים; Stripe מטפלת בכל זה בתשתית שלה.
• Resend למייל תפעולי (הדוח שלך, עדכונים חודשיים, הודעות אבטחה).
• ממשקי API של עוזרי AI מ-OpenAI, Anthropic, Google ו-xAI, שאיתם אנחנו מריצים את הבדיקות שהבטחנו. אנחנו שולחים את השאלות הציבוריות שלקוח היה שואל (למשל "מספרה הכי טובה בפלורנטין"). אנחנו לא שולחים נתוני חשבון או מידע אישי.

רשימת ספקים מלאה ומה כל אחד מעבד נמצאת ב מדיניות הפרטיות שלנו.

ניטור ותגובה לתקריות

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

אם נגלה תקרית אבטחה שמשפיעה על מידע משתמשים, נודיע למשתמשים שנפגעו בלי עיכוב מיותר, ובכל מקרה תוך 72 שעות מאישור התקרית. זה תואם את לוח הזמנים של GDPR להודעה. ההודעה תגיד לך מה קרה, איזה מידע היה מעורב, מה עשינו בקשר לזה, ומה (אם בכלל) אתה צריך לעשות מהצד שלך.

גיבויים ושחזור

בסיס הנתונים מגובה יומית על ידי ספק ה-Postgres המנוהל, עם שחזור לנקודת זמן עבור 7 הימים האחרונים. הגיבויים מוצפנים ומאוחסנים באותו אזור כמו בסיס הנתונים הראשי. אנחנו בודקים את תהליך השחזור רבעונית מול סביבת staging כדי שנדע שזה באמת עובד לפני שאנחנו צריכים את זה.

פרטיות ומינימליזציה של מידע

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

הפירוט המלא של מה שאנחנו אוספים, כמה זמן אנחנו שומרים אותו, ואיך לבקש מחיקה נמצא ב מדיניות הפרטיות.

מה אנחנו עדיין לא עושים

להיות כנים לגבי הפערים חשוב לא פחות מלפרט את הנהלים. הנה מה שאין לנו היום:

• הסמכת SOC 2. אנחנו עוקבים אחר הנהלים שביקורת SOC 2 מחפשת, אבל אנחנו עדיין לא מוסמכים. בכוונתנו להמשיך ל-SOC 2 Type II ככל שנצמח.
• תוכנית bug bounty רשמית. אנחנו עדיין לא מריצים תוכנית bounty בתשלום. אנחנו כן מקבלים ומגיבים לדיווחי פגיעות ב- [email protected] (ראה למטה).
• שאלוני אבטחה מותאמים לרכש ארגוני. אנחנו מתמקדים בעסקים קטנים, לא במחזורי רכש ארגוני. אם אתה צריך סקירת אבטחה מעמיקה לארגון גדול, Kodo עדיין לא ההתאמה הנכונה.
• דוחות penetration test לפי דרישה. אנחנו מבצעים סקירות אבטחה פנימיות בכל גרסה משמעותית. בדיקות penetration של צד שלישי נמצאות במפת הדרכים.

דיווח על פגיעות

אם אתה חושב שמצאת בעיית אבטחה ב-Kodo, אנא שלח מייל ל- [email protected]. תכלול את השלבים לשחזור, את ההשפעה שאתה חושב שיש, וכל proof-of-concept שנוח לך לחלוק. אנחנו מגיבים תוך 5 ימי עסקים, בדרך כלל תוך יום אחד.

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

עודכן לאחרונה: 28 במאי 2026. Kodo היא צוות קטן. העמוד הזה מתאר את הנהלים הנוכחיים שלנו, לא הסמכה. אנחנו מעדכנים אותו ככל שהמוצר מתפתח.