आयुष्याच्या सातत्यासाठी
घडवलेली रचना.
तुमच्या डिजिटल लाइफ vault मागील तंत्रज्ञानाचे पारदर्शक वर्णन. आम्ही तांत्रिक शब्दांच्या पलीकडे जाऊन तुमच्या कुटुंबासाठी एक सुरक्षित, मानवकेंद्रित पूल (bridge) प्रदान करतो.
सिस्टम डिझाइन
माझा डेटा प्रत्यक्षात कुठे असतो?
आम्ही मुंबईतील Amazon ची डेटा सेंटर्स (ap-south-1) वापरतो. आमची सिस्टीम “serverless” आहे: पॅच करण्यासाठी किंवा लॉग इन करण्यासाठी Soult-व्यवस्थापित कोणतेही सर्व्हर नाहीत, आणि मूळ मशीनची सुरक्षा AWS सांभाळते. यामुळे अटॅक सरफेस कमी होतो, पण पूर्णपणे नाहीसा होत नाही — आमचे APIs, साइन-इन आणि क्लाउड कॉन्फिगरेशन यांचे संरक्षण अजूनही करावे लागते.
ap-south-1 (मुंबई) मध्ये DynamoDB, S3 आणि Cognito सह AWS Lambda वर serverless कम्प्युट. डेटा अनेक Availability Zones मध्ये स्टोअर केला जातो. क्रॉस-रिजन डिझास्टर रिकव्हरी आमच्या रोडमॅपवर आहे.
आज एक रिजन, पुढे सायलो
प्रत्येक वापरकर्त्याचा डेटा कुठे जातो?
आज Soult भारतातील AWS मुंबईमध्ये एकाच silo म्हणून चालते, आणि प्रत्येक वापरकर्त्याचा व्हॉल्ट तिथेच साठवला जातो. आम्ही UAE मध्ये लाँच करण्याची तयारी करत आहोत. तिथल्या वापरकर्त्यांचे व्हॉल्ट AWS मुंबई (भारत) मध्ये साठवले जातील, आणि साइन-अपच्या वेळी आम्ही त्यासाठी त्यांची स्पष्ट संमती घेऊ. स्वतंत्र प्रादेशिक silos आमच्या रोडमॅपवर आहेत.
आज: प्रत्येक वापरकर्त्यासाठी एक silo, ap-south-1 (मुंबई); देशानुसार रूटिंग लाईव्ह नाही. Roadmap: साइन-अपच्या वेळी होम-रिजन रूटिंग, US silo (us-east-1, us-west-2), SEA silo (ap-southeast-1, ap-southeast-3) आणि समर्पित GCC silo.
AWS मुंबई का?
स्थानिक नियमांचे पालन आणि सुरक्षा.
AWS मुंबईमुळे आम्हाला भारतात परिपक्व, स्वतंत्रपणे ऑडिट केलेली डेटा सेंटर व्यवस्था मिळते. तुमचा डेटा भारतीय भूमीवर ठेवल्याने तुमचा वारसा भारतीय कायद्यांनुसार राहतो आणि कोणत्याही अडचणींशिवाय तुमच्या कुटुंबाच्या आवाक्यात राहतो.
ap-south-1 मध्ये अनेक Availability Zones मध्ये पसरलेले सिंगल-रिजन डिप्लॉयमेंट; क्रॉस-रिजन DR आमच्या रोडमॅपवर. Native Cognito स्थानिक फोन सपोर्ट आणि AWS KMS मधील FIPS 140-validated क्रिप्टोग्राफिक मॉड्यूल्स.
Authentication प्रक्रिया
सुरक्षितपणे साइन अप करा आणि लॉग इन करा.
नोंदणी: फोन OTP आणि ईमेल OTP द्वारे पडताळणी केली जाते. तुम्ही एक सुरक्षा प्रश्न आणि 4-अंकी MPIN सेट करता. विश्वसनीय वापर: दैनंदिन प्रवेशासाठी फक्त तुमचा 4-अंकी MPIN लागतो. नवीन डिव्हाइस: 2-फॅक्टर सुरक्षा सक्रिय करते — आधी फोन OTP, नंतर तुमचा MPIN.
Multi-channel OTP पडताळणी. सुरक्षा उत्तरे one-way hashes म्हणून साठवली जातात; MPIN ची पडताळणी आणि साठवणूक AWS Cognito करते. नवीन डिव्हाइसवर Re-auth केल्यास MPIN च्या आधी OTP सक्रिय होतो.
शेअर केलेल्या डिव्हाइसवर MPIN
माझे कुटुंब हे का उघडू शकत नाही?
ज्या घरात फोन शेअर केला जातो, तिथे फिंगरप्रिंटमुळे नोंदणी केलेला कोणीही प्रवेश करू शकतो. एक खाजगी 4-अंकी PIN तुमचा vault खाजगी ठेवतो, जेव्हा मुले गेम्स खेळतात किंवा तुमचा जोडीदार फोन वापरतो.
4-अंकी MPIN, ज्याची पडताळणी आणि साठवणूक AWS Cognito करते. 3 अयशस्वी प्रयत्नांनंतर साइन-इन 24 तासांसाठी लॉक होते, आणि हे सर्व्हर-साइड लागू केले जाते. रीइन्स्टॉल, डिव्हाइस वाईप किंवा डिव्हाइस बदलल्याने लॉकआउट रीसेट होत नाही.
4-अंकी PIN का?
4 अंक खरंच सुरक्षित आहेत का?
होय — कारण संरक्षण हे लॉकआउट आहे, लांबी नाही. तीन चुकीच्या प्रयत्नांनंतर तुमचा vault 24 तासांसाठी लॉक होतो. तुमचा फोन चोरणाऱ्यालाही दार बंद होण्यापूर्वी फक्त 3 वेळा अंदाज लावता येतो. आम्ही जाणूनबुजून 6 ऐवजी 4 अंक निवडले: लांब PIN मुळे जास्त कोड विसरले जातात, लॉकआउट होतात आणि रीसेट करावे लागतात — आणि प्रत्यक्षात सुरक्षेचा खरा शत्रू स्मृतीची गुंतागुंत आहे, केवळ कच्ची एन्ट्रॉपी नाही.
4-अंकी शोध जागा: 10⁴ = 10,000. ब्रूट-फोर्स कमी करणे: सर्व्हर-साइड काउंटर, 24 तासांसाठी 3-स्ट्राइक लॉकआउट. लॉकआउटसह व्यावहारिक एन्ट्रॉपी असुरक्षित 6-अंकीच्या कच्च्या एन्ट्रॉपीपेक्षा जास्त असते. ट्रेड-ऑफ स्वीकारला: वापरण्यायोग्यता वाढ > किमान एन्ट्रॉपी वाढ.
हार्ड ड्राइव्हचा धोका
जर कोणी हार्ड ड्राइव्ह चोरले तर काय?
डेटा AES-256 ने एनक्रिप्टेड (स्थिर स्थितीत) असतो. चोरलेल्या हार्डवेअरमध्ये फक्त अर्थहीन सायफरटेक्स्ट असतो. एनक्रिप्शन कीज AWS द्वारे, डेटापासून वेगळ्या व्यवस्थापित केल्या जातात — त्या कधीही डेटा असलेल्या डिस्कवर नसतात.
फाइल्स: S3 सर्व्हर-साइड एनक्रिप्शन (SSE-S3, AES-256), प्रत्येक ऑब्जेक्टला आपोआप लागू. टेबल्स: DynamoDB एनक्रिप्शन (रेस्टमध्ये). उच्च-संवेदनशीलता असलेले फील्ड्स: लिहिण्यापूर्वी AWS KMS सह अतिरिक्त एनक्रिप्शन.
की व्यवस्थापन (KMS)
कीज कोणाकडे असतात?
AWS ठेवते. आमची फील्ड-एनक्रिप्शन की AWS KMS च्या हार्डवेअर सिक्युरिटी मॉड्यूल्समध्ये राहते आणि वाचता येण्याजोग्या स्वरूपात कधीही त्यांच्याबाहेर जात नाही, त्यामुळे Soult मधील कोणीही मूळ (raw) की कधीही हाताळत नाही. तुम्ही एखादे संरक्षित फील्ड सेव्ह करता किंवा उघडता तेव्हा आमचे ॲप्लिकेशन KMS ला ती की वापरण्यास सांगते, आणि यामुळेच पडताळलेले कौटुंबिक हस्तांतरण शक्य होते. फाइल्स आणि डेटाबेस टेबल्सच्या कीज AWS द्वारे व्यवस्थापित केल्या जातात.
संवेदनशील फील्ड्स: customer-managed की अंतर्गत KMS Encrypt/Decrypt; की मटेरियल KMS च्या FIPS 140-validated HSMs मधून कधीही बाहेर जात नाही. फाइल्स: S3 सर्व्हर-साइड एनक्रिप्शन (SSE-S3, AES-256). टेबल्स: DynamoDB एनक्रिप्शन (रेस्टमध्ये).
फील्ड-स्तरीय सुरक्षा
तुमच्या सर्वात संवेदनशील फील्डसाठी दुहेरी-लॉक सुरक्षा.
तुमच्या सर्वात संवेदनशील तपशीलांसाठी — आधार, PAN आणि पासपोर्ट क्रमांक, कार्ड आणि खाते क्रमांक, आणि Standard Password Keeper मधील पासवर्ड — आम्ही एक दुसरा लॉक जोडतो. आमचे सर्व्हर यातील प्रत्येक फील्ड सेव्ह करण्यापूर्वी AWS KMS की ने एनक्रिप्ट करतात, त्यामुळे डेटाबेसमध्ये ते सायफरटेक्स्ट म्हणून स्टोअर केलेले असतात.
customer-managed AWS KMS की वापरून सर्व्हर-साइड फील्ड-लेव्हल एनक्रिप्शन, जे आमचा बॅकएंड लिहिण्यापूर्वी खालील गोष्टींना लागू करतो: आधार, PAN आणि पासपोर्ट क्रमांक; प्राथमिक क्रेडिट आणि डेबिट कार्ड क्रमांक; कर्ज, क्रेडिट-कार्ड, मुदत ठेव (fixed-deposit), सरकारी बचत योजना आणि पर्यायी गुंतवणूक (alternative-investment) खाते क्रमांक; गुंतवणूक व्यवहार IDs; मालमत्ता दस्तऐवजांचे ओळखक्रमांक; आणि Standard Password Keeper पासवर्ड. KMS डिक्रिप्ट अधिकारांशिवाय टेबल वाचल्यास त्या फील्ड्ससाठी फक्त सायफरटेक्स्ट मिळतो. विमा पॉलिसी क्रमांक, बँक पासबुक खाते क्रमांक आणि Will चे तपशील फक्त at-rest एनक्रिप्शनने संरक्षित आहेत.
Client-side encryption
Soult सुद्धा वाचू शकत नाही असे कोणते सिक्रेट्स आहेत?
Password Keeper मध्ये दोन लेव्हल्स आहेत. रोजचे लॉगिन — Wi-Fi, स्ट्रीमिंग — तुमच्या ॲप MPIN ने अनलॉक होतात, आणि आम्ही ते रिकव्हर करायला मदत करू शकतो. तुमच्या सर्वात संवेदनशील लॉगिनसाठी तुम्ही Advanced चालू करता, जे vault password ने एंड-टू-एंड लॉक केलेले असते जे कधीही तुमच्या फोनमधून बाहेर जात नाही. Advanced एंट्री ॲड करण्यासाठी पासवर्डची गरज नाही; फक्त एंट्री वाचण्यासाठी लागतो. आम्ही लॉक केलेला रिझल्ट स्टोअर करतो आणि तो उघडण्याचे माध्यम आमच्याकडे कधीच नसते — त्यामुळे Soult decrypt बटण नाही, स्टाफ ओव्हरराइड नाही, आणि कायदेशीर आदेशाखाली देण्यासारखे काहीही अर्थपूर्ण नाही. तुम्हाला एक 12-शब्दांची रिकव्हरी फ्रेज पण मिळते, जी एकदाच दाखवली जाते आणि जी आम्हाला कधीच मिळत नाही. हा प्रामाणिक ट्रेड-ऑफ आहे: जर तुम्ही vault password आणि फ्रेज दोन्ही गमावले, तर ते पासवर्ड कायमचे जातील, कारण दुसरा पर्याय म्हणजे आमच्याकडे की असणे. फक्त पासवर्डच सील केला जातो; एंट्रीचे शीर्षक, युझरनेम, वेबसाइट, नोट्स आणि सुरक्षा प्रश्न व उत्तर Standard संरक्षण वापरतात.
Per-user X25519 identity keypair; public key clear मध्ये स्टोअर केले जाते, private seed कधीही unwrapped न ठेवता स्टोअर केले जाते. KEK = Argon2id(vault password, 16-byte random salt) — m=64 MiB, t=3, p=1, 32-byte output; private seed AES-256-GCM (12-byte nonce, 128-bit tag) ने रॅप केले जाते. हे KDF पॅरामीटर्स सक्रिय हार्डनिंग रिव्ह्यू अंतर्गत आहेत; वायर स्कीम व्हर्जन केलेली आहे (enc_scheme=e2e_v2) आणि प्रत्येक रॅप सेल्फ-डिस्क्राइबिंग आहे, त्यामुळे पॅरामीटर्स वापरकर्त्यांना पुन्हा एनरोल न करता वाढवता येतात. ॲड पब्लिक-की स्टाईल सील केले जातात: नवीन तात्पुरता X25519 keypair → आयडेंटिटी पब्लिक की विरुद्ध ECDH → HKDF-SHA256 (salt = तात्पुरता पब्लिक की, info soult-pwk-e2e-v2) → AES-256-GCM. एंट्री फक्त सिफरटेक्स्ट, IV आणि तात्पुरता पब्लिक की स्टोअर करते. एकाच सीडचे दोन स्वतंत्र रॅप्स आहेत — एक vault password अंतर्गत, एक 12-शब्दांच्या फ्रेज अंतर्गत जी 256-शब्दांच्या यादीतून (≈96 bits) निवडली जाते, जी ऑन-डिव्हाइस जनरेट होते आणि कधीही ट्रान्समिट होत नाही. MPIN मुद्दाम की डेरिवेशनमधून वगळले आहे, कारण ते रोटेट करणे किंवा क्लिअर करणे अन्यथा रिकव्हरी कायमची ब्रिक करेल; ते रिकव्हरीच्या वेळी एक वेगळा UI गेट म्हणून लागू केले जाते. enc_key_id = SHA-256(public key) चे पहिले 8 बाइट्स, त्यामुळे व्हॉल्ट रीसेट केल्यानंतर सुपरसीड केलेल्या कीला सील केलेल्या एंट्रीज सायलेंटली फेल होण्याऐवजी अनरिकव्हर करण्यायोग्य म्हणून फ्लॅग केल्या जातात. बॅकएंड e2e_ स्कीम्ससाठी KMS पूर्णपणे बायपास करते: या फील्ड्ससाठी कोणतीही सर्व्हर-साइड की नाही जी कंपेल, ऑडिट किंवा गैरवापर केली जाऊ शकते. व्याप्ती: फक्त पासवर्ड फील्ड सील केले जाते; हे संरक्षण तुम्ही इन्स्टॉल केलेल्या ॲपच्या अखंडतेवर (integrity) अवलंबून असते.
ट्रान्झिटमध्ये एन्क्रिप्शन
हेरगिरी-प्रूफ Wi-Fi.
डेटा सुरक्षित TLS टनलमधून प्रवास करतो. सार्वजनिक विमानतळावर किंवा कॅफेमधील Wi-Fi वर कोणीही तुमची माहिती चोरण्याचा प्रयत्न केल्यास, त्यांना फक्त एनक्रिप्टेड (encrypted) कोड दिसेल – तुम्ही काय अपलोड करता किंवा वाचता याबद्दल काहीही नाही.
API Gateway HTTPS द्वारे TLS 1.2+ सक्तीचे. फाइल्स S3 presigned URLs द्वारे अपलोड केल्या आणि वाचल्या जातात, ज्यांची मुदत 15 मिनिटांनंतर संपते.
‘नियमित ॲक्सेस नाही’ हे तत्त्व
Soult चे कर्मचारी माझी गोपनीय माहिती पाहू शकतात का?
नियमित कामकाजात नाही. Soult कर्मचारी सामान्य कामकाजात तुमच्या व्हॉल्टमधील कंटेंट पाहत नाहीत; प्रोडक्शन सिस्टीम्सचा ॲक्सेस IAM द्वारे मर्यादित असतो आणि त्याची नोंद ठेवली जाते. मृत्यूच्या दाव्याचे (death claim) पुनरावलोकन होत असताना, मोजके अधिकृत कर्मचारी त्या अकाउंटमधील कागदपत्रे उघडू शकतात, आणि अशा प्रत्येक ॲक्सेसची नोंद ठेवली जाते. तुमचे सर्वात संवेदनशील फील्ड्स KMS-एनक्रिप्टेड सायफरटेक्स्ट म्हणूनही स्टोअर केलेले असतात.
ॲप्लिकेशन रोल्ससाठी किमान-विशेषाधिकार (least-privilege) IAM. प्रोडक्शन ॲक्सेस मोजक्या, नावानिशी नियुक्त ॲडमिनिस्ट्रेटर्सपुरता मर्यादित असतो आणि त्याची नोंद ठेवली जाते. मृत्यूच्या दाव्यांचे पुनरावलोकन करणारे एका लहान allowlist मध्ये असतात, आणि ते उघडत असलेल्या प्रत्येक कागदपत्राची नोंद ठेवली जाते. डेटाबेस स्तरावर फक्त KMS-एनक्रिप्टेड फील्ड्सच सायफरटेक्स्ट असतात; इतर कंटेंट IAM ॲक्सेस कंट्रोल्स आणि लॉगिंगद्वारे संरक्षित असतो.
दोन प्रकारचे Executor
माझा व्हॉल्ट कोण पाहू शकते?
Regular Executor (सहसा कुटुंबातील सदस्य): त्यांचा स्वतःचा डॅशबोर्ड असतो, ज्यात त्यांना ज्या व्यक्तींसाठी नियुक्त केले आहे त्यांची यादी असते. ते मृत्यूचा दावा (death claim) दाखल करू शकतात. Soult ने त्याची पडताळणी करून मंजुरी दिल्यानंतरच ते — फोन आणि ईमेल OTP सह — साइन इन करून तुमचा व्हॉल्ट पाहू शकतात.
Emergency Executor (तुम्ही निवडलेली कोणतीही विश्वासू व्यक्ती — जोडीदार, मूल, भावंड किंवा मित्र): मृत्यूच्या दाव्याची गरज नाही. फोन आणि ईमेल OTP नंतर ते कधीही साइन इन करू शकतात. ते साइन इन करताच तुम्हाला ईमेल येतो.
दोन्ही भूमिकांना तुमचा व्हॉल्ट read-only (फक्त वाचण्यायोग्य) मोडमध्ये दिसतो. Emergency भूमिका वैद्यकीय आपत्कालीन परिस्थिती आणि तातडीच्या प्रसंगांसाठी आहे; Regular भूमिका मृत्यूनंतरच्या हस्तांतरणासाठी आहे. तुम्ही किती Executors नियुक्त करू शकता हे तुमच्या प्लॅनवर अवलंबून आहे.
ॲप्लिकेशन लॉजिकमध्ये भूमिका-आधारित ॲक्सेस. प्रत्येक एक्झिक्युटरला एक is_emergency फ्लॅग असतो (कोणतेही नाते; एकूण एक्झिक्युटर्सची मर्यादा प्लॅननुसार). नॉन-इमर्जन्सी एक्झिक्युटर्स मृत्यूचा दावा मंजूर झाल्यानंतरच साइन इन करू शकतात; इमर्जन्सी एक्झिक्युटर्स कधीही साइन इन करू शकतात. एक्झिक्युटर साइन-इनसाठी OTP पडताळणी आवश्यक असते आणि मालकाला ईमेल जातो. एक्झिक्युटर सेशन्स read-only असतात.
हस्तांतरण प्रोटोकॉल
माझ्या कुटुंबाला प्रत्यक्षात प्रवेश कसा मिळतो?
नियुक्त केलेला Regular Executor त्यांच्या डॅशबोर्डवरून मृत्यूचा दावा (death claim) दाखल करतो आणि मृत्यू प्रमाणपत्र अपलोड करतो; तुम्हाला आणि तुमच्या इतर Executors ना ईमेल पाठवला जातो. मंजुरी देण्यापूर्वी Soult चा अधिकृत ॲडमिनिस्ट्रेटर दाव्याचे आणि प्रमाणपत्राचे पुनरावलोकन करतो — पडताळणी न झालेल्या विनंतीवर काहीही दिले जात नाही. मंजुरीनंतर, तुमचे अकाउंट read-only (फक्त वाचण्यायोग्य) होते, आणि Executor फोन आणि ईमेल OTP सह साइन इन करून व्हॉल्ट पाहू आणि डाउनलोड करू शकतो. प्रत्येक वेळी Executor साइन इन करतो तेव्हा तुमच्या नोंदणीकृत पत्त्यावर ईमेल जातो. तुम्ही तुमच्या Executor साठी तुमचा vault password किंवा Recovery Kit ठेवला नसेल, तर Advanced Password Keeper मधील पासवर्ड लॉकच राहतात.
गेट: (1) नोंदणीकृत, पडताळलेला एक्झिक्युटर त्यांच्या डॅशबोर्डवरून प्रमाणपत्र अपलोड करून मृत्यूचा दावा दाखल करतो; (2) Amazon SES मालकाला आणि इतर एक्झिक्युटर्सना ईमेल पाठवते; (3) allowlist मधील Soult ॲडमिनिस्ट्रेटर दाव्याचे पुनरावलोकन करून मंजुरी देतो; (4) मंजुरीनंतर फोन + ईमेल OTP सह एक्झिक्युटर साइन-इन सुरू होते, आणि API स्तरावर अकाउंट read-only केले जाते; (5) प्रत्येक एक्झिक्युटर साइन-इनवर मालकाला ईमेल पाठवला जातो. दाव्याचे अपलोड आणि मंजुरी सुरक्षा इव्हेंट लॉगमध्ये नोंदवल्या जातात.
शेअरिंग नाही, हे डिझाइनमध्येच आहे
मी माझा एक डॉक्युमेंट माझ्या CA किंवा पती/पत्नीसोबत शेअर करू शकतो का?
सध्या नाही. यामध्ये प्रति-आयटम शेअरिंग नाही, अकाउंटंटसाठी प्रति-फोल्डर प्रवेश नाही, किंवा वेळ-मर्यादित शेअर लिंक नाही. तुमच्या व्हॉल्टमध्ये दुसरी कोणतीही व्यक्ती फक्त वर वर्णन केलेल्या Executor प्रक्रियेद्वारेच पाहू शकते – आणि तेव्हाही, त्यांना सर्व काही read-only मोडमध्ये दिसते. सध्या प्रति-आयटम किंवा प्रति-फोल्डर अशी कोणतीही 'granularity' (ग्रॅन्युलॅरिटी) नाही.
कोणतीही सहयोग यंत्रणा लागू केलेली नाही. एकमेव ॲक्सेस मार्ग: (1) प्रमाणित मालक सेशन, (2) व्हेरिफिकेशननंतर एक्झिक्युटर सेशन. शेअर-लिंक जनरेशन नाही, स्कोप केलेले टोकन नाहीत, प्रति-संसाधन ACL नाही. केवळ रोडमॅप विचाराधीन – तयार केलेले नाही.
वास्तविक परिस्थिती
धोके काय आहेत?
आम्ही हॅकर्स, अकाउंट ताब्यात घेणे (account takeover) आणि अंतर्गत व्यक्तींच्या प्रवेशापासून (insider access) संरक्षण करण्यासाठी काम करतो. तुमचा PIN शेअर करण्यासाठी तुम्हाला शारीरिकरित्या भाग पाडल्यास आम्ही ते थांबवू शकत नाही. Soult हे तुमच्या माहितीची व्यवस्था आणि कुटुंबासाठी सातत्य राखण्यासाठी आहे — दबावाखाली माहिती उघड करण्यापासून संरक्षण करण्यासाठी नाही.
धमकी मॉडेलमध्ये शारीरिक जबरदस्तीचा समावेश नाही. कमी करते: एक्सफिल्ट्रेशन, अकाउंट हॅक, इनसाइडर ॲक्सेस. कार्यक्षेत्राबाहेर: दबावाखाली PIN काढणे, अनलॉक केल्यानंतर डिव्हाइसची हॅकिंग.
भारतीय भूमीवर
माझा डेटा नेमका कुठे राहतो?
आज, सर्व व्हॉल्ट डेटा AWS मुंबईमधील आमच्या भारत 'silo' (सायलो) मध्ये आहे. आम्ही UAE मध्ये लाँच करण्याची तयारी करत आहोत. तिथल्या वापरकर्त्यांचे व्हॉल्ट AWS मुंबई (भारत) मध्ये साठवले जातील, आणि साइन-अपच्या वेळी आम्ही त्यासाठी त्यांची स्पष्ट संमती घेऊ. US आणि दक्षिणपूर्व आशियासाठी भविष्यातील silos, आणि समर्पित GCC silo, आमच्या रोडमॅपवर आहेत.
सक्रिय सायलो: ap-south-1 (मुंबई), ज्यामध्ये डेटा अनेक Availability Zones मध्ये स्टोअर केला जातो. क्रॉस-रिजन DR आमच्या रोडमॅपवर आहे. DPDP ॲक्ट, 2023 च्या तत्त्वांचा विचार करून तयार केलेले. इतर कोणताही सायलो लाईव्ह नाही, आणि कोणत्याही युझरला GCC रिजनमधून सेवा दिली जात नाही.
आपत्कालीन पुनर्प्राप्तीचे स्तर
प्रत्येक स्तरावरील बिघाड झाल्यास काय होते?
स्तर 1 – एक सर्व्हर निकामी झाल्यास: वापरकर्त्यांना जाणवत नाही; AWS च्या मॅनेज्ड सेवा तो आपोआप बदलतात.
स्तर 2 – मुंबईतील एक डेटा सेंटर निकामी झाल्यास: सेवा सुरू राहते, कारण तुमचा डेटा आधीच मुंबईतील अनेक डेटा सेंटर्समध्ये स्टोअर केलेला असतो.
स्तर 3 – संपूर्ण मुंबई 'region' (रिजन) बंद पडल्यास: AWS ते पूर्ववत करेपर्यंत सेवा थांबते. दुसऱ्या रिजनमधील स्टँडबाय आमच्या 'roadmap' (रोडमॅप) वर आहे, आज लाइव्ह नाही.
स्तर 4 – मुंबई 'region' (रिजन) कायमचा गमावल्यास: आज आम्ही त्यातून पूर्णपणे पुनर्प्राप्ती करू शकत नाही. 'Cross-region backup replication' (क्रॉस-रिजन बॅकअप रेप्लिकेशन) आमच्या 'roadmap' (रोडमॅप) वर आहे. तोपर्यंत, स्वतःचा बॅकअप ठेवणे हे सर्वात मजबूत संरक्षण आहे.
स्तर 1: मॅनेज्ड-सर्व्हिस सेल्फ-हीलिंग (Lambda, DynamoDB, S3). स्तर 2: ap-south-1 मध्ये multi-AZ स्टोरेज. स्तर 3–4: आज क्रॉस-रिजन फेलओव्हर नाही; दुसऱ्या रिजनमध्ये क्रॉस-रिजन बॅकअप रेप्लिकेशन आमच्या रोडमॅपवर आहे.
ऑडिट ट्रेल
बदलांची नोंद.
तुमच्या व्हॉल्टमधील प्रत्येक क्रिएट, अपडेट किंवा डिलीटची नोंद — बदल कोणी केला आणि केव्हा केला यासह.
DynamoDB मधील ऑडिट लॉग टेबल. Write operations (CUD) ट्रॅक करते. युझर प्रायव्हसी आणि परफॉर्मन्स बॅलन्ससाठी Read events वगळले आहेत. अकाउंटसोबत डिलीट केले जाते.
डेटा वापराच्या सीमा
विक्री नाही, ट्रेनिंग नाही, कोणतेही अनपेक्षित बदल नाहीत.
तुमच्या vault मधील माहिती AI मॉडेल्सना प्रशिक्षित करण्यासाठी किंवा मार्केटिंगसाठी कधीही वापरली जात नाही. जेव्हा app मध्ये AI फीचर्स वापरले जातात, तेव्हा त्या सेशनचा डेटा फक्त त्या संदर्भातच प्रोसेस केला जातो — मॉडेल सुधारण्यासाठी तो कधीही साठवला जात नाही. आमचे उत्पन्न केवळ सबस्क्रिप्शन-आधारित आहे. जर आम्ही कधीही कमाईचा नवीन मार्ग विचारात घेतला — कोणताही बदल असो — तर आम्ही तुम्हाला आधी विचारू. कळवणार नाही. घोषणा करणार नाही. विचारू. आणि आम्ही तुम्हाला तेव्हाच विचारू जेव्हा आम्हाला खरोखर वाटेल की ते तुमच्या फायद्याचे आहे.
Data isolation. कोणताही vault कंटेंट AI/ML ट्रेनिंग पाइपलाइनमध्ये फीड केला जात नाही. AI फीचर्स डेटा फक्त इन-कॉन्टेक्स्ट प्रति सेशन प्रोसेस करतात — मॉडेल सुधारण्यासाठी कोणताही डेटा रिटेन केला जात नाही. रेव्हेन्यू मॉडेल vault कंटेंटपासून स्वतंत्र आहे. भविष्यातील मॉनेटायझेशन बदल explicit per-user opt-in वर आधारित असतील — announce-and-proceed नाही.
प्रायव्हसी विरुद्ध हस्तांतरण
पुलाची निवड.
चॅट ॲप्स पूर्ण गोपनीयतेवर लक्ष केंद्रित करतात — जर तुम्ही एखादी key गमावली, तर ते तुम्हाला मदत करू शकत नाहीत. लाइफ वॉल्टसाठी ही एक मोठी त्रुटी आहे. म्हणूनच आम्ही Soult वेगळ्या पद्धतीने डिझाइन केले: तुमचा व्हॉल्ट डिझाइननुसारच रिकव्हर करण्यायोग्य आहे, त्यामुळे फोन हरवला किंवा PIN विसरला तरी तुमच्या कुटुंबासाठी दार कधीही बंद होत नाही, आणि पडताळणी झालेल्या Executors ना तुम्ही त्यांच्यासाठी ठेवलेले मिळू शकते. Soult कर्मचाऱ्यांना नियमित ॲक्सेस नसतो, आणि हस्तांतरण फक्त पडताळणी केलेल्या मार्गानेच होते. जे मोजके पासवर्ड फक्त तुम्हीच उघडले पाहिजेत, त्यांच्यासाठी Advanced Password Keeper तुम्हाला एकमेव कस्टडी (sole custody) देते. Soult हा तुमच्या वारशाकडे जाणारा एक पूल आहे, डिजिटल डेड एंड नाही.
स्टँडर्ड व्हॉल्ट डेटा सर्व्हर-साइड एनक्रिप्ट केलेला असतो (रेस्टमध्ये S3 आणि DynamoDB एनक्रिप्शन, आणि संवेदनशील फील्ड्ससाठी AWS KMS), त्यामुळे तो तुम्हाला पुन्हा मिळवून देता येतो किंवा पडताळणी झालेल्या एक्झिक्युटरला read-only स्वरूपात दाखवता येतो. कर्मचाऱ्यांना नियमित ॲक्सेस नाही; हस्तांतरणासाठी वर वर्णन केलेली पडताळणी केलेली मृत्यू-दावा प्रक्रिया आवश्यक आहे. Advanced Password Keeper मधील नोंदी (e2e_v2) हा एकमेव डेटा आहे जो Soult डिक्रिप्ट करू शकत नाही.
रोडमॅप
पुढे काय येत आहे?
नजीकच्या काळात: एका क्लिकवर vault export (आज वापरकर्ते मॅन्युअली बॅकअप घेतात); US silo (N. Virginia, DR Oregon); SEA silo (सिंगापूर, DR जकार्ता); क्रॉस-सायलो बॅकअप रेप्लिकेशन जेणेकरून संपूर्ण प्रदेश जरी नष्ट झाला तरी काहीतरी नेहमी सुरक्षित राहील.
मध्यम काळात: समर्पित GCC silo; SOC 2 Type II.
नेहमी-सक्रिय: सतत ऑडिट, सुरक्षा मजबूत करणे, इन्फ्रास्ट्रक्चर रिव्ह्यू.
Phase 1 (पुढील): एक-क्लिक एन्क्रिप्टेड एक्सपोर्ट, US silo ब्रिंग-अप. Phase 2: SEA silo, क्रॉस-सायलो कोल्ड बॅकअप रेप्लिकेशन, WAF, मोबाइल क्लायंटवर SSL पिनिंग. Phase 3: समर्पित GCC silo, SOC 2 Type II, मजबूत मल्टी-रिजन KMS.
प्रामाणिक दावे
प्रत्येक मार्केटिंग दाव्याची तपासणी केली आहे. आज काय खरे आहे, काय नियोजित आहे, काय बनवले नाही, आणि आम्ही काय वापरत नाही.
| दावा | स्थिती | व्यावहारिक सत्य |
|---|---|---|
| कर्मचाऱ्यांना नियमित ॲक्सेस नाही | खरे | Soult कर्मचाऱ्यांना व्हॉल्टमधील कंटेंटचा नियमित ॲक्सेस नसतो; प्रोडक्शन ॲक्सेस मर्यादित असतो आणि त्याची नोंद ठेवली जाते. मृत्यूच्या दाव्याचे पुनरावलोकन करताना, allowlist मधील मोजके पुनरावलोकनकर्ते अकाउंटमधील कागदपत्रे उघडू शकतात, आणि प्रत्येक ॲक्सेसची नोंद ठेवली जाते. Advanced Password Keeper मधील पासवर्ड वगळता, हे ॲक्सेस कंट्रोल आहे, तांत्रिक अशक्यता नाही. |
| भारतात डेटा रेसिडेन्सी | खरे | सर्व व्हॉल्ट डेटा भारतात, AWS मुंबईमध्ये स्टोअर केला जातो. काही ऑपरेशनल डेटा (साइन-इन कोड, पेमेंट्स, ॲनालिटिक्स, क्रॅश रिपोर्ट्स) अशा पुरवठादारांकडून हाताळला जातो, जे त्यावर भारताबाहेर प्रक्रिया करू शकतात. |
| ISO 27001 & ISO 9001 प्रमाणन | प्रगतीपथावर | सुरक्षा कार्यक्रम ISO 27001 शी संरेखित. गुणवत्ता व्यवस्थापन ISO 9001 शी संरेखित. दोन्हींसाठी मान्यताप्राप्त प्रमाणन प्रक्रिया सुरू आहे. |
| AES-256 एन्क्रिप्शन | खरे | सर्व व्हॉल्ट डेटा रेस्टमध्ये AES-256 ने एनक्रिप्ट केलेला असतो, आणि संवेदनशील फील्ड्सना AWS KMS चा अतिरिक्त स्तर मिळतो. |
| Password Keeper — स्टँडर्ड (Standard) | खरे | डीफॉल्ट. पासवर्ड आमच्या सर्व्हरवर AWS KMS ने एनक्रिप्ट केला जातो, त्यामुळे तो रिकव्हर करता येतो आणि तुमच्या Executors कडे सोपवता येतो. |
| Password Keeper — अ‍ॅडव्हान्स्ड (Advanced) | लाइव्ह | जुलै 2026 पासून लाइव्ह (ऑप्ट-इन). Password Keeper नोंदीसाठी Advanced चालू करा, आणि त्याचा पासवर्ड तुमच्या फोनवर, फक्त तुम्हाला माहीत असलेल्या व्हॉल्ट पासवर्डमधून तयार केलेल्या की ने एनक्रिप्ट केला जातो, त्यामुळे Soult तो डिक्रिप्ट करू शकत नाही. नोंदीचे इतर तपशील (शीर्षक, युझरनेम, वेबसाइट, नोट्स, सुरक्षा प्रश्न आणि उत्तर) Standard संरक्षण वापरतात. व्हॉल्ट पासवर्ड आणि तुमचा 12-शब्दांचा रिकव्हरी फ्रेज (recovery phrase) दोन्ही गमावल्यास तो पासवर्ड रिकव्हर करता येत नाही. |
| एक-क्लिक vault एक्सपोर्ट | नियोजित | आज बनवलेले नाही. युझर्स मॅन्युअली बॅकअप घेतात. वन-क्लिक एक्सपोर्ट आमच्या रोडमॅपवर आहे. |
| प्रत्येक वस्तू शेअर करणे | तयार नाही | सध्या शेअरिंग किंवा कोलाबोरेशनची सोय नाही. Executor हाच एकमेव ॲक्सेस मार्ग आहे. |
| क्रॉस-सायलो बॅकअप | रोडमॅपमध्ये | दुसऱ्या रिजनमध्ये बॅकअप रेप्लिकेशन (replication) आमच्या रोडमॅपवर आहे आणि US/SEA सायलो (silo) कार्यान्वित झाल्यावर उपलब्ध होईल. |
| क्रॉस-रिजन (cross-region) डिझास्टर रिकव्हरी | रोडमॅपमध्ये | आज तुमचा डेटा एकाच AWS रिजनमध्ये (मुंबई) असतो, आणि तिथल्या अनेक डेटा सेंटर्समध्ये स्टोअर केलेला असतो. दुसऱ्या रिजनमधील स्टँडबाय (standby) आमच्या रोडमॅपवर आहे; तोपर्यंत, संपूर्ण रिजन गमावण्याच्या धोक्यापासून तुमचा स्वतःचा बॅकअप हे सर्वात मजबूत संरक्षण आहे. |
| लाइव्ह सिस्टीम्समधून डिलीट करणे | तत्काळ | 10 सेकंदांचे कन्फर्मेशन (confirmation) आणि तुमचा MPIN, त्यानंतर तुमचे लॉगिन, नोंदी आणि फाइल्स लाइव्ह सिस्टीम्समधून काढून टाकल्या जातात. प्रत्येक युझरसाठी वेगळी की नसल्यामुळे, बॅकअप, फाइल्सच्या आधीच्या आवृत्त्या आणि लॉग्स क्रिप्टो-श्रेड (crypto-shred) केले जात नाहीत किंवा तात्काळ पुसले जात नाहीत. |
| युझर (user) डेटावर AI ट्रेनिंग (training) | कधीही नाही | व्हॉल्टमधील (vault) डेटा AI मॉडेल (model) ट्रेनिंगसाठी (training) कधीही वापरला जात नाही, जरी AI फीचर्स (features) सेशनमध्ये (session) वापरले गेले तरी. |
| ब्लॉकचेन | वापरले जात नाही | प्रायव्हेट (private) व्हॉल्टसाठी (vault) हे योग्य साधन नाही. त्याऐवजी आम्ही ऑडिट लॉग्स (audit logs) वापरतो. |
| झिरो-नॉलेज एनक्रिप्शन (Zero-knowledge encryption) | अंशतः लाइव्ह | आज अंशतः लाइव्ह. Advanced Password Keeper मधील नोंदी खऱ्या अर्थाने क्लायंट-साइड एनक्रिप्टेड आहेत — आमच्यापर्यंत कधीही न पोहोचणाऱ्या व्हॉल्ट पासवर्डमधून तयार केलेल्या की ने सील केलेल्या, त्यामुळे आम्ही त्या डिक्रिप्ट करू शकत नाही (पाहा Client-side encryption). उर्वरित व्हॉल्ट आमच्या सर्व्हरवर एनक्रिप्ट केला जातो, आणि संवेदनशील फील्ड्स AWS KMS अंतर्गत असतात. हे मजबूत आहे, पण झिरो-नॉलेज नाही — आणि हे जाणूनबुजून, जेणेकरून तुमच्या कुटुंबासाठी दार कधीही बंद होणार नाही. अधिक व्यापक ऑप्ट-इन (opt-in) झिरो-नॉलेज पर्याय आमच्या रोडमॅपवर आहेत. |
सामान्य प्रश्न
मी माझा डेटा कसा डिलीट (delete) करू?
10 सेकंदांच्या पुष्टीकरण विरामानंतर आणि तुमचा MPIN टाकल्यानंतर, तुमचे साइन-इन आणि व्हॉल्ट नोंदी आमच्या डेटाबेसमधून डिलीट केल्या जातात आणि तुमच्या फाइल्स ॲक्टिव्ह स्टोरेजमधून लगेच काढून टाकल्या जातात. हे तुम्हाला किंवा आमच्या सपोर्ट टीमला पूर्ववत करता येत नाही. बॅकअप, फाइल्सच्या आधीच्या आवृत्त्या आणि सिस्टीम लॉग्समधील प्रती तात्काळ पुसल्या जात नाहीत, आणि पेमेंटची नोंद तुमचे वैयक्तिक तपशील काढून टाकून ठेवली जाते. तुम्हाला जे ठेवायचे आहे ते आधी डाउनलोड करा. वन-क्लिक (one-click) एक्सपोर्ट (export) आमच्या रोडमॅपवर आहे.
Soult बंद पडल्यास काय होईल?
जर Soult ला कधी बंद करावे लागले, तर आम्ही तुम्हाला आधीच कळवू आणि तुमच्या व्हॉल्टची कॉपी मिळवण्यासाठी मदत करू. वन-क्लिक एक्सपोर्ट आमच्या रोडमॅपवर आहे. आम्ही तुमचा डेटा विकणार नाही किंवा तुमच्या संमतीशिवाय तुमचा vault कोणत्याही खरेदीदाराकडे हस्तांतरित करणार नाही.
सबस्क्रिप्शनचे (subscription) बिल (bill) कसे भरले जाते?
Soult वेबसाइटवर (website) Razorpay द्वारे व्यवस्थापित केले जाते. इन-ॲप (in-app) खरेदी नाही. यामुळे बिलिंग (billing) तुमच्या व्हॉल्ट (vault) डिव्हाइसपासून (device) वेगळे राहते.
डेटा नष्ट करण्याच्या प्रोटोकॉलचे (protocol) तपशील?
पुष्टी केल्यावर, युझरचे Cognito साइन-इन डिलीट केले जाते, DynamoDB मधील व्हॉल्ट टेबल्समधून त्यांच्या नोंदी (rows) काढून टाकल्या जातात आणि त्यांच्या S3 फाइल्स ॲक्टिव्ह स्टोरेजमधून काढल्या जातात, त्यानंतर asynchronous दुसरा clean-up pass चालतो. पेमेंट नोंदी वैयक्तिक तपशील redact करून ठेवल्या जातात. प्रत्येक युझरसाठी वेगळी की नसल्यामुळे क्रिप्टो-श्रेडिंग (crypto-shredding) होत नाही; बॅकअप, फाइल्सच्या आधीच्या आवृत्त्या आणि लॉग्स तात्काळ पुसले जात नाहीत.
Soult ब्लॉकचेन (blockchain) का वापरत नाही?
ब्लॉकचेन (blockchain) सार्वजनिक पडताळणीसाठी (public verification) तयार केले आहे, जिथे पक्ष एकमेकांवर विश्वास ठेवत नाहीत — जसे की क्रिप्टोकरन्सी (cryptocurrency), प्रतिस्पर्धकांमधील सप्लाय चेन (supply chain), सार्वजनिक जमीन रेकॉर्ड (record). त्याची ताकद म्हणजे छेडछाड जगाला दिसेल अशी करणे.
Soult व्हॉल्ट्स (vaults) सार्वजनिकतेच्या अगदी विरुद्ध आहेत — ते डिझाइननुसार (design) प्रायव्हेट (private) आहेत. डेटाशी संबंधित हितसंबंध असलेला युझर (user) हा एकमेव पक्ष आहे. छेडछाडीचा हेतू कमी असतो: कारण तो युझरचा (user) स्वतःचा डेटा (data) असतो, जो युझरच्या (user) स्वतःच्या कुटुंबासाठी (family) ठेवलेला असतो.
बदलांचा मागोवा घेण्यासाठी, आम्ही ऑडिट लॉग्स (audit logs) वापरतो (विभाग 14 पहा) — प्रत्येक Create (तयार करणे), Update (अपडेट करणे), Delete (डिलीट करणे) टाइमस्टॅम्प (timestamp) आणि ॲक्टरसह (actor) रेकॉर्ड (record) केले जाते. ब्लॉकचेनमुळे (blockchain) खर्च, गुंतागुंत वाढेल आणि सार्वजनिक लेजरवर (ledger) पॅटर्न (pattern) उघड करून प्रायव्हसी (privacy) कमी होईल — कोणत्याही युझरची (user) समस्या सोडवल्याशिवाय.
व्हेरिफाइड-पब्लिक (verified-public) ॲटेस्टेशन (attestation) ही खरी युझरची (user) गरज बनल्यास पुन्हा विचार केला जाईल.
Soult काय करू शकते आणि काय नाही याबद्दल अधिक माहितीसाठी — Legal Validity पेज (page) वाचा. Executor प्रोटोकॉलच्या तपशिलासाठी, Executor आणि Handover Flow पहा.
मोफत सुरुवात करा →