אבטחה וביסוס
אמון הוא מנגנון,
לא תג.
העמוד הזה הוא הראיות: מה המערכת אוכפת, מה היא שומרת, מי יכול להגיע לזה, ומה עוד לא בנינו.
איש קשר לאבטחה
support@salewise.co.ukצרפו שלבי שחזור. נא לא לגשת לנתונים של סוחר אחר או לשבש את השירות.
מצב נוכחי
- אין הסמכת SOC 2 או ISO 27001.
- אין בדיקת חדירה עצמאית עדיין.
- לא נשמרים נתוני כרטיס.
הגרסה הקצרה
ארבע טענות, והיכן נמצאות הראיות.
לא שמות תואר שיווקיים. החלטות תכנון עם קוד מאחוריהן.
01
המודל לא יכול לקבוע מחיר.
השליפה רצה לפני היצירה. המודל בוחר מתוך מזהי מועמדים; השרת מאמת אותם ומרנדר בעצמו מחיר, מלאי ווריאציות.
קראו את המנגנון02
סודות הספקים מוצפנים במנוחה.
AES-256-GCM, IV אקראי לכל רשומה, ונתונים מאומתים נוספים שקושרים כל טקסט מוצפן לספק, לחשבון ולרשומת האינטגרציה שלו.
קראו את המנגנון03
שום נתוני כרטיס לא נכנסים ל-Salewise.
אין קופה ואין אחסון PAN. הקונה מחליט בטלפון ומשלם בקופה הקיימת של הסוחר.
קראו את המנגנון04
הגישה מוגבלת בהיקף, לא משותפת.
הבעלות על החנות נבדקת בכל מסלול חנות. אסימוני גישה תקפים ל-15 דקות; אסימוני רענון נשמרים כ-hash ומתחלפים בכל שימוש.
קראו את המנגנוןמבוסס מהיסוד
המודל בוחר. השרת מרנדר.
השליפה רצה לפני היצירה. המודל בוחר מתוך מועמדים; השרת עושה את החשבון ואת הרינדור.
01
שליפה תחילה
השרת שולף מוצרים מועמדים מהקטלוג של הסוחר לפני שהמודל נשאל דבר. המודל אינו מחפש באינטרנט הפתוח.
02
המודל בוחר. השרת מרנדר.
מחירים, מלאי, וריאציות ומבצעים מרונדרים בצד השרת מרשומות הקטלוג. מספר בטקסט של המודל אינו מקור האמת.
03
מזהים נבדקים
כל מוצר שהמודל בוחר חייב להימצא בקבוצת המועמדים שנשלפה. מזהים לא חוקיים מוסרים לפני שהתשובה מגיעה לקונה.
04
סירוב כן
אם הקטלוג אינו מכיל תשובה, הסוכן אומר זאת ומציע העברה לאדם. כשהמודל אינו זמין, העוזר מודיע שאינו יכול לענות; הקונה יכול לנסות שוב או לשאול איש צוות.
מה נשלח למודל
- שאלת הקונה.
- קבוצה של מועמדי קטלוג שנשלפו.
- הגדרות החנות וטקסט המדיניות הרלוונטי.
מה לעולם לא נשלח למודל
- נתוני כרטיס או אישורי תשלום.
- סיסמאות, מפתחות API או מפתח המאסטר של Salewise.
- כלי שיכול לכתוב ל-POS.
יומן בקרות
יומן בקרות, לא תג אמון.
כל שורה מפרטת את הבקרה, את המנגנון שמאחוריה, והיכן הגבול. אם שאלון צריך יותר פירוט, שאלו.
תשובות מבוססות
הקטלוג הוא מקור האמת.
- השרת שולף מוצרים מועמדים לפני שהמודל רץ. המודל רשאי לבחור מזהים רק מהקבוצה הזו. מזהים לא חוקיים מוסרים, ומחיר, מלאי, וריאציות ומבצעים מרונדרים בצד השרת. אם לקטלוג אין תשובה, הסוכן אומר זאת ומציע העברה לאדם.
פרטי גישה במנוחה
סודות מוצפנים, קשורים ומנוהלים בגרסאות.
- פרטי הגישה של ספקים מוצפנים ב-AES-256-GCM עם IV אקראי של 96 סיביות לכל רשומה. נתונים מאומתים נוספים קושרים את הטקסט המוצפן ל-provider:{providerId}:account:{accountId}:credentials, כך שרשומה שהועתקה לדייר אחר נכשלת בפענוח. keyVersion תומך בסיבוב מפתחות; פענוח שנכשל נסגר בבטחה במקום להחזיר סוד.
בקשות Salewise
חתומות, לא רק bearer.
- בקשות ל-API המאסטר של Salewise נושאות חתימת HMAC-SHA256 על השיטה, הנתיב, חותמת הזמן, ה-nonce ו-SHA-256 של הגוף. החתימה מושווית בזמן קבוע ומוגבלת בחלון הגנה מפני הפעלה חוזרת. מפתח המאסטר נמצא בצד השרת, מוגדר פעם אחת, מוצפן במנוחה ולעולם אינו מוחזר לדפדפן.
חשבונות ותפקידים
חשבון סוחר אינו מנהל שרת.
- ל-Sage יש תפקידי סוחר ומנהל שרת. סיסמאות משתמשות ב-scrypt עם מלח לכל חשבון. אסימוני גישה פגים לאחר 15 דקות; אסימוני רענון נשמרים כ-hash, מתחלפים בכל שימוש ופגים לאחר 30 יום. הזמנות הצטרפות פגות לאחר 7 ימים וקשורות לדוא״ל המוזמן.
בידוד דיירים
חיפוש חנות הוא בדיקת בעלות.
- כל מסלול חנות מאתר את החנות ובודק שהיא שייכת לחשבון המאומת לפני החזרת נתונים. שיטות ה-Repository מוגבלות לפי חשבון וחנות, וה-SQL נמצא מאחורי שכבת ה-Repository ולא במטפלי המסלול.
נתוני כרטיס
בלי תשלומים, בלי PANs.
- Salewise אינה גובה תשלומים ואינה שומרת נתוני כרטיס. ל-PWA של הקונה אין קופה, והעסקה נשארת בתוך ה-POS של הסוחר. אנו לא טוענים להיקף PCI DSS לתשלומי כרטיס משום שאיננו מעבדים תשלומי כרטיס.
שמירה
מוגדרת, לא ללא הגבלה.
- פריסת הייחוס מוגדרת ל-180 יום לתמלולי הפעלות ול-365 יום לרשומות אירועים, לפי משתני סביבה ו-DPA. שמירה ספציפית לסוחר מוסכמת ב-DPA, ומחיקה מטופלת לפי בקשה. לא מוצהר כיום על מחיקה מתוזמנת.
נתיב ביקורת
אירועים רלוונטיים לאבטחה משאירים רשומה.
- הרשמה, התחברות, התחברות שנכשלה, הזמנות, הקמה ושינויי פרטי גישה לאינטגרציה נכתבים ליומן ביקורת. דוא״ל נשמר כ-hash בפרטי הביקורת ולא כטקסט גלוי. היומן פנימי היום; אין עדיין מסך ביקורת לסוחר.
גבול המודל
המודל מקבל את המינימום שהוא צריך.
- המודל מקבל את שאלת הקונה, מועמדי קטלוג שנשלפו, הגדרות חנות וטקסט מדיניות רלוונטי. הוא אינו מקבל סיסמאות, פרטי גישה ל-API או נתוני כרטיס, ואין לו כלי שיכול לכתוב ל-POS.
״בנוי״ פירושו שהבקרה קיימת במוצר היום. זה לא אומר שכל בקרה נבדקה באופן עצמאי. הפער מפורט בתחתית העמוד.
פרטי גישה ובקשות
מוצפנים במנוחה. חתומים בתעבורה.
שני המנגנונים שסוקר אבטחה בדרך כלל מבקש ראשונים.
פרטי גישה במנוחה
- אלגוריתם
- AES-256-GCM, הצפנה מאומתת.
- IV
- 12 בתים אקראיים לכל רשומה, לא בשימוש חוזר.
- קישור
- AAD provider:{providerId}:account:{accountId}:credentials. רשומה שהועתקה נכשלת בפענוח.
- סיבוב
- keyVersion בכל רשומה; המפתח הקודם מתקבל במהלך הסיבוב.
- כשל
- פענוח שנכשל נסגר בבטחה. הוא אינו מנסה שוב עם סוד ישן.
בקשות Salewise
מפתח המאסטר מוגדר פעם אחת במהלך הקמת השרת. כל בקשה נחתמת בו; החתימה אינה אסימון bearer.
canonical = method + "\n" + path + "\n" + timestamp + "\n" + nonce + "\n" + sha256(body); signature = HMAC-SHA256(masterKey, canonical);
- נשלחת כ-X-Sage-Signature עם כותרות חותמת זמן ו-nonce.
- מושווית בזמן קבוע, עם חלון הגנה מפני הפעלה חוזרת.
- מפתח המאסטר נשמר בצד השרת ומוצפן במנוחה.
- לעולם אינו מוחזר לדפדפן או נכתב ליומן.
נתונים, תפקידים ושמירה
נתונים מצומצמים. גישה מוגבלת. רשומה.
העוזר אינו צריך לדעת מי הקונה כדי לענות על שאלת מוצר.
הפעלה רושמת
- מזהה הפעלה, קוד ה-QR והמעבר שהתחילו אותה.
- השאלות, התשובות וההמלצות.
- אירועי העברה וחותמות זמן.
בלי שם, חשבון או נתוני כרטיס. ההדגמה אינה מקשרת הפעלה לקונה מזוהה.
מי יכול להגיע לזה
- חשבון סוחר, מוגבל לחנויות המקושרות אליו.
- מנהל שרת, לצורך הקמה ותצורת ספקים.
- בלי גישה לחנות של סוחר אחר דרך מסלולי החנות.
הזמנות הצטרפות קשורות לדוא״ל ופגות לאחר 7 ימים.
כמה זמן זה נשמר
- תמלולי הפעלות: מוגדרים ל-180 יום.
- רשומות אירועים: מוגדרות ל-365 יום.
- תנאים ספציפיים לסוחר: נקבעים ב-DPA.
מחיקה מטופלת לפי בקשה. לא מוצהר כיום על מחיקה מתוזמנת.
אירועי ביקורת
הרשמה, התחברות, התחברות שנכשלה, הזמנות, הקמה ושינויי פרטי גישה לאינטגרציה נכתבים ליומן ביקורת. דוא״ל נשמר כ-hash בפרטי הביקורת ולא כטקסט גלוי. היומן פנימי היום; איננו מציגים אותו כמסך ביקורת לסוחר.
ייחוס
הרשומה חייבת לעמוד בביקורת.
מכירה מותאמת היא מדויקת או מודלית. הסוחר יכול לראות איזו, ולמה.
דטרמיניסטי
קוד מימוש שעבר מההפעלה למכירה. ביטחון 1.0. הסימון ״מודלי״ כבוי. המכירה מיוחסת במלואה.
מודלי
מכירה באותה חנות בתוך חלון של שעתיים שמכילה פריטים מומלצים. ציון ביטחון נשמר, מוגבל ל-0.92, וההתאמה מסומנת כמודלית בכל מקום שבו היא מדווחת.
התאמות מדויקות הן מדויקות. התאמות מודליות מסומנות כמודליות בכל מקום שבו הן מדווחות. המנוי הוא החיוב היחיד, וייחוס אינו מוצג כהכנסה.
גבולות ישרים
מה אנחנו לא טוענים.
אמון קל יותר לבדיקה כשהפערים מוצהרים.
אם שאלון דורש משהו מהרשימה הזו, אמרו זאת.
אנחנו מעדיפים להפסיד את העסקה מאשר לענות סביבה.
- 01
אין לנו הסמכת SOC 2 או ISO 27001 היום.
- 02
לא השלמנו בדיקת חדירה או ביקורת אבטחה עצמאית היום.
- 03
איננו טוענים להיקף PCI DSS לתשלומי כרטיס, משום שאיננו מעבדים תשלומי כרטיס.
- 04
איננו מאמנים מודל משותף על הקטלוג או השיחות של סוחר אחד במוצר הנוכחי.
- 05
אין מערכת AI נטולת סיכון. ביסוס מצמצם המצאות; הוא אינו מבטל את הצורך בבדיקה של הסוחר ובכללי העברה.
- 06
איננו מפעילים מחיקה מתוזמנת של נתונים היום; מחיקה היא הליך תפעולי במסגרת ה-DPA.
- 07
יומן הביקורת שלנו פנימי ואינו נחשף כמסך ביקורת לסוחר.
- 08
איננו מבטיחים רמת שירות בעמוד הזה; כל התחייבות זמינות נקבעת בטופס ההזמנה.
גילוי אחראי
אם אתם סבורים שמצאתם פגיעות, פנו ל support@salewise.co.uk עם מספיק פירוט כדי לשחזר אותה. נא לא לגשת לנתונים של סוחר אחר, לא לשבש את השירות ולא לפרסם בפומבי לפני שניתנה לנו הזדמנות להגיב.
שאלות אבטחה
שאלו את השאלה הלא נוחה.
שאלוני אבטחה, תנאי עיבוד נתונים ושאלות ארכיטקטורה מתקבלים בברכה. נענה על מה שיש לנו ונאמר מה אין.