सुरक्षा और ग्राउंडिंग

भरोसा एक मैकेनिज़्म है,
बैज नहीं।

यह पृष्ठ सबूत है: सिस्टम क्या लागू करता है, क्या संग्रहीत करता है, कौन इस तक पहुँच सकता है, और हमने अभी क्या नहीं बनाया।

सुरक्षा संपर्क

support@salewise.co.uk

पुनरुत्पादन के चरण शामिल करें। कृपया किसी दूसरे व्यापारी का डेटा एक्सेस न करें या सेवा बाधित न करें।

वर्तमान स्थिति

  • कोई SOC 2 या ISO 27001 प्रमाणन नहीं।
  • अभी कोई स्वतंत्र पेनेट्रेशन टेस्ट नहीं।
  • कोई कार्ड डेटा संग्रहीत नहीं।

संक्षेप में

चार दावे, और सबूत कहाँ है।

मार्केटिंग विशेषण नहीं। ऐसे डिज़ाइन फ़ैसले जिनके पीछे कोड है।

01

मॉडल कीमत तय नहीं कर सकता।

जनरेशन से पहले रिट्रीवल चलता है। मॉडल संभावित ID में से चुनता है; सर्वर उन्हें सत्यापित करके कीमत, स्टॉक और वेरिएंट खुद रेंडर करता है।

मैकेनिज़्म पढ़ें

02

प्रदाता के रहस्य स्टोरेज में एन्क्रिप्टेड हैं।

AES-256-GCM, प्रति रिकॉर्ड एक यादृच्छिक IV, और अतिरिक्त प्रमाणित डेटा जो हर सिफ़रटेक्स्ट को उसके प्रदाता, खाते और इंटीग्रेशन रिकॉर्ड से बाँधता है।

मैकेनिज़्म पढ़ें

03

Salewise में कोई कार्ड डेटा नहीं आता।

कोई चेकआउट नहीं और कोई PAN स्टोरेज नहीं। खरीदार फ़ोन पर फ़ैसला करता है और व्यापारी के मौजूदा टिल पर भुगतान करता है।

मैकेनिज़्म पढ़ें

04

एक्सेस सीमित है, साझा नहीं।

हर स्टोर रूट पर स्टोर का स्वामित्व जाँचा जाता है। एक्सेस टोकन 15 मिनट चलते हैं; रीफ़्रेश टोकन हैश होते हैं और उपयोग पर बदले जाते हैं।

मैकेनिज़्म पढ़ें

शुरुआत से कैटलॉग-आधारित

मॉडल चुनता है। सर्वर रेंडर करता है।

जनरेशन से पहले रिट्रीवल चलता है। मॉडल संभावित उत्पादों में से चुनता है; सर्वर गणित और रेंडरिंग करता है।

01

पहले रिट्रीवल

मॉडल से कुछ पूछे जाने से पहले सर्वर व्यापारी के कैटलॉग से संभावित उत्पाद निकालता है। मॉडल कभी ओपन वेब पर खोज नहीं करता।

02

मॉडल चुनता है। सर्वर रेंडर करता है।

कीमत, स्टॉक, वेरिएंट और ऑफ़र सर्वर-साइड कैटलॉग रिकॉर्ड से रेंडर होते हैं। मॉडल के लेख में लिखा कोई भी आँकड़ा सच का स्रोत नहीं होता।

03

ID सत्यापित होती हैं

मॉडल जो भी उत्पाद चुनता है, उसे रिट्रीव किए गए संभावित सेट में मौजूद होना चाहिए। अमान्य ID जवाब खरीदार तक पहुँचने से पहले हटा दी जाती हैं।

04

ईमानदार इनकार

अगर कैटलॉग में जवाब नहीं है, तो एजेंट साफ़ बताता है और हैंडओवर देता है। मॉडल उपलब्ध न होने पर असिस्टेंट बताता है कि वह जवाब नहीं दे सकता; खरीदार फिर कोशिश कर सकता है या किसी स्टाफ़ सदस्य से पूछ सकता है।

मॉडल तक क्या जाता है

  • खरीदार का सवाल।
  • रिट्रीव किए गए कैटलॉग उत्पादों का एक सेट।
  • स्टोर सेटिंग्स और संबंधित नीति का पाठ।

मॉडल तक कभी क्या नहीं जाता

  • कार्ड डेटा या भुगतान क्रेडेंशियल।
  • पासवर्ड, API कुंजियाँ या Salewise मास्टर कुंजी।
  • ऐसा कोई टूल जो POS में लिख सके।

नियंत्रण बही

नियंत्रण की बही, भरोसे का बैज नहीं।

हर पंक्ति नियंत्रण, उसके पीछे का मैकेनिज़्म और सीमा बताती है। अगर किसी प्रश्नावली को और विवरण चाहिए, तो पूछें।

कैटलॉग-आधारित जवाब

कैटलॉग सच का स्रोत है।

मॉडल चलने से पहले सर्वर संभावित उत्पाद रिट्रीव करता है। मॉडल केवल उसी सेट से ID चुन सकता है। अमान्य ID हटा दी जाती हैं, और कीमत, स्टॉक, वेरिएंट व ऑफ़र सर्वर-साइड रेंडर होते हैं। अगर कैटलॉग में जवाब नहीं है, तो एजेंट साफ़ बताता है और हैंडओवर देता है।

स्टोरेज में क्रेडेंशियल

रहस्य एन्क्रिप्टेड, बंधे और संस्करणबद्ध हैं।

प्रदाता क्रेडेंशियल AES-256-GCM और प्रति रिकॉर्ड यादृच्छिक 96-बिट IV का उपयोग करते हैं। अतिरिक्त प्रमाणित डेटा सिफ़रटेक्स्ट को provider:{providerId}:account:{accountId}:credentials से बाँधता है, इसलिए दूसरे टेनेंट में कॉपी किया गया रिकॉर्ड डिक्रिप्ट नहीं होता। keyVersion कुंजी रोटेशन का समर्थन करता है; विफल डिक्रिप्ट रहस्य लौटाने के बजाय बंद हो जाता है।

Salewise अनुरोध

हस्ताक्षरित, केवल बियरर नहीं।

Salewise मास्टर API के अनुरोधों पर method, path, timestamp, nonce और body के SHA-256 पर HMAC-SHA256 हस्ताक्षर होता है। हस्ताक्षर की तुलना स्थिर समय में होती है और रीप्ले विंडो से सीमित है। मास्टर कुंजी सर्वर-साइड है, एक बार कॉन्फ़िगर होती है, स्टोरेज में एन्क्रिप्टेड रहती है और कभी ब्राउज़र को नहीं लौटाई जाती।

खाते और भूमिकाएँ

व्यापारी खाता सर्वर एडमिन नहीं है।

Sage में व्यापारी और सर्वर-एडमिन भूमिकाएँ हैं। पासवर्ड प्रति-खाता नमक के साथ scrypt का उपयोग करते हैं। एक्सेस टोकन 15 मिनट बाद समाप्त होते हैं; रीफ़्रेश टोकन हैश के रूप में संग्रहीत होते हैं, उपयोग पर बदले जाते हैं और 30 दिन बाद समाप्त होते हैं। आमंत्रण 7 दिन बाद समाप्त होते हैं और आमंत्रित ईमेल से बंधे होते हैं।

टेनेंट आइसोलेशन

स्टोर लुकअप एक स्वामित्व जाँच है।

हर स्टोर रूट डेटा लौटाने से पहले स्टोर खोजता है और जाँचता है कि वह प्रमाणित खाते का है। रिपॉज़िटरी मेथड खाते और स्टोर तक सीमित हैं, और SQL रूट हैंडलर में नहीं, रिपॉज़िटरी परत के पीछे रहता है।

कार्ड डेटा

कोई भुगतान नहीं, कोई PAN नहीं।

Salewise भुगतान नहीं लेता और कार्ड डेटा संग्रहीत नहीं करता। खरीदार PWA में कोई चेकआउट नहीं है, और लेन-देन व्यापारी के POS के भीतर ही रहता है। हम कार्ड भुगतान के लिए PCI DSS दायरा नहीं मानते, क्योंकि हम कार्ड भुगतान प्रोसेस नहीं करते।

रिटेंशन

कॉन्फ़िगर किया गया, अनिश्चितकालीन नहीं।

संदर्भ तैनाती सेशन ट्रांसक्रिप्ट के लिए 180 दिन और इवेंट रिकॉर्ड के लिए 365 दिन के लिए कॉन्फ़िगर है, जो एनवायरनमेंट और DPA से तय होता है। व्यापारी-विशिष्ट रिटेंशन DPA में तय होता है, और हटाना अनुरोध पर होता है। आज किसी निर्धारित डेटा हटाने का दावा नहीं है।

ऑडिट ट्रेल

सुरक्षा से जुड़ी घटनाएँ रिकॉर्ड छोड़ती हैं।

पंजीकरण, साइन-इन, विफल साइन-इन, आमंत्रण, सेटअप और इंटीग्रेशन क्रेडेंशियल में बदलाव ऑडिट लॉग में लिखे जाते हैं। ऑडिट विवरण में ईमेल कच्चे रूप में नहीं, हैश के रूप में होते हैं। लॉग आज आंतरिक है; अभी व्यापारी के लिए ऑडिट स्क्रीन नहीं है।

मॉडल की सीमा

मॉडल को उतना ही मिलता है जितना ज़रूरी है।

मॉडल को खरीदार का सवाल, रिट्रीव किए गए कैटलॉग उत्पाद, स्टोर सेटिंग्स और संबंधित नीति का पाठ मिलता है। उसे पासवर्ड, API क्रेडेंशियल या कार्ड डेटा नहीं मिलता, और उसके पास POS में लिख सकने वाला कोई टूल नहीं है।

“निर्मित” का अर्थ है कि नियंत्रण आज उत्पाद में मौजूद है। इसका अर्थ यह नहीं कि हर नियंत्रण का स्वतंत्र ऑडिट हुआ है। कमी इस पृष्ठ के नीचे सूचीबद्ध है।

क्रेडेंशियल और अनुरोध

स्टोरेज में एन्क्रिप्टेड। भेजते समय हस्ताक्षरित।

सुरक्षा समीक्षक आमतौर पर सबसे पहले ये दो मैकेनिज़्म माँगते हैं।

स्टोरेज में क्रेडेंशियल

एल्गोरिदम
AES-256-GCM, प्रमाणित एन्क्रिप्शन।
IV
प्रति रिकॉर्ड 12 यादृच्छिक बाइट, कभी दोबारा उपयोग नहीं।
बाइंडिंग
AAD provider:{providerId}:account:{accountId}:credentials. कॉपी किया गया रिकॉर्ड डिक्रिप्ट नहीं होता।
रोटेशन
हर रिकॉर्ड पर keyVersion; रोटेशन के दौरान पिछली कुंजी स्वीकार की जाती है।
विफलता
विफल डिक्रिप्ट बंद हो जाता है। यह पुराने रहस्य से दोबारा कोशिश नहीं करता।

Salewise अनुरोध

मास्टर कुंजी सर्वर सेटअप के दौरान एक बार कॉन्फ़िगर होती है। हर अनुरोध उसी से हस्ताक्षरित होता है; हस्ताक्षर बियरर टोकन नहीं है।

canonical =
  method + "\n" +
  path + "\n" +
  timestamp + "\n" +
  nonce + "\n" +
  sha256(body);

signature =
  HMAC-SHA256(masterKey, canonical);
  • timestamp और nonce हेडर के साथ X-Sage-Signature के रूप में भेजा जाता है।
  • स्थिर समय में तुलना, रीप्ले विंडो के साथ।
  • मास्टर कुंजी सर्वर-साइड रखी जाती है और स्टोरेज में एन्क्रिप्टेड होती है।
  • कभी ब्राउज़र को नहीं लौटाई जाती और किसी लॉग में नहीं लिखी जाती।

डेटा, भूमिकाएँ और रिटेंशन

सीमित डेटा। सीमित एक्सेस। एक रिकॉर्ड।

उत्पाद का सवाल का जवाब देने के लिए असिस्टेंट को यह जानने की ज़रूरत नहीं कि खरीदार कौन है।

सेशन क्या दर्ज करता है

  • सेशन ID, QR कोड और वह गलियारा जहाँ से यह शुरू हुआ।
  • सवाल, जवाब और सिफ़ारिशें।
  • हैंडऑफ़ इवेंट और समय-चिह्न।

कोई नाम, खाता या कार्ड डेटा नहीं। डेमो किसी सेशन को नामित खरीदार से नहीं जोड़ता।

कौन पहुँच सकता है

  • एक व्यापारी खाता, जो उससे जुड़े स्टोर तक सीमित है।
  • एक सर्वर एडमिन, सेटअप और प्रदाता कॉन्फ़िगरेशन के लिए।
  • स्टोर रूट के ज़रिए किसी दूसरे व्यापारी के स्टोर तक पहुँच नहीं।

आमंत्रण एक ईमेल से बंधे होते हैं और 7 दिन बाद समाप्त होते हैं।

कितने समय तक रहता है

  • सेशन ट्रांसक्रिप्ट: 180 दिन के लिए कॉन्फ़िगर।
  • इवेंट रिकॉर्ड: 365 दिन के लिए कॉन्फ़िगर।
  • व्यापारी-विशिष्ट शर्तें: DPA में तय।

हटाना अनुरोध पर होता है। आज किसी निर्धारित डेटा हटाने का दावा नहीं है।

ऑडिट इवेंट

पंजीकरण, साइन-इन, विफल साइन-इन, आमंत्रण, सेटअप और इंटीग्रेशन क्रेडेंशियल में बदलाव ऑडिट लॉग में लिखे जाते हैं। ऑडिट विवरण में ईमेल कच्चे रूप में नहीं, हैश के रूप में होते हैं। लॉग आज आंतरिक है; हम इसे व्यापारी के लिए ऑडिट स्क्रीन के रूप में नहीं दिखाते।

एट्रिब्यूशन

रिकॉर्ड को ऑडिट में टिकना है।

मिलान वाली बिक्री या तो सटीक होती है या मॉडल्ड। व्यापारी देख सकता है कि कौन सी, और क्यों।

डिटर्मिनिस्टिक

सेशन से बिक्री तक पहुँचा रिडेम्पशन कोड। विश्वास 1.0। मॉडल्ड गलत। बिक्री सीधे एट्रिब्यूटेड है।

मॉडल्ड

दो घंटे की खिड़की में उसी स्टोर की बिक्री जिसमें सुझाए गए उत्पाद हों। विश्वास स्कोर संग्रहीत होता है, अधिकतम 0.92, और जहाँ भी रिपोर्ट हो, मिलान मॉडल्ड लेबल होता है।

सटीक मिलान सटीक होते हैं। मॉडल्ड मिलान जहाँ भी रिपोर्ट हों, मॉडल्ड लेबल होते हैं। सब्सक्रिप्शन ही एकमात्र शुल्क है, और एट्रिब्यूशन को राजस्व के रूप में नहीं दिखाया जाता।

ईमानदार सीमाएँ

हम किसका दावा नहीं करते।

जब कमियाँ बताई जाएँ, तो भरोसा जाँचना आसान होता है।

अगर किसी प्रश्नावली में इस सूची की कोई चीज़ चाहिए, तो बताएँ।

हम सौदा खोने को तैयार हैं, उसके इर्द-गिर्द जवाब देने से बेहतर।

  • 01

    आज हमारे पास SOC 2 या ISO 27001 प्रमाणन नहीं है।

  • 02

    आज हमने स्वतंत्र पेनेट्रेशन टेस्ट या सुरक्षा ऑडिट पूरा नहीं किया है।

  • 03

    हम कार्ड भुगतान के लिए PCI DSS दायरा नहीं मानते, क्योंकि हम कार्ड भुगतान प्रोसेस नहीं करते।

  • 04

    मौजूदा उत्पाद में हम किसी एक व्यापारी के कैटलॉग या बातचीत पर साझा मॉडल प्रशिक्षित नहीं करते।

  • 05

    कोई भी AI सिस्टम जोखिम-मुक्त नहीं है। ग्राउंडिंग गढ़ने की गुंजाइश कम करती है; यह व्यापारी की समीक्षा और हैंडओवर नियमों की ज़रूरत नहीं हटाती।

  • 06

    आज हम कोई निर्धारित रिटेंशन सफ़ाई नहीं चलाते; हटाना DPA के तहत एक परिचालन प्रक्रिया है।

  • 07

    हमारा ऑडिट लॉग आंतरिक है और व्यापारी के लिए ऑडिट स्क्रीन के रूप में उजागर नहीं है।

  • 08

    हम इस पृष्ठ पर किसी सेवा स्तर का वादा नहीं करते; कोई भी उपलब्धता प्रतिबद्धता ऑर्डर फ़ॉर्म में तय होती है।

जिम्मेदारी से खुलासा

अगर आपको लगता है कि आपने कोई भेद्यता खोजी है, तो संपर्क करें support@salewise.co.uk और पुनरुत्पादन के लिए पर्याप्त विवरण दें। कृपया किसी दूसरे व्यापारी का डेटा एक्सेस न करें, सेवा बाधित न करें, या हमें जवाब देने का मौका मिलने से पहले सार्वजनिक रूप से खुलासा न करें।

सुरक्षा के सवाल

असुविधाजनक सवाल पूछें।

सुरक्षा प्रश्नावली, डेटा प्रोसेसिंग की शर्तें और आर्किटेक्चर के सवाल स्वागत योग्य हैं। जो हमारे पास है उसका जवाब देंगे और जो नहीं है वह भी बताएँगे।