જીવનની સાતત્યતા માટે
બનાવવામાં આવેલી આર્કિટેક્ચર.
તમારા ડિજિટલ લાઇફ વોલ્ટ પાછળની ટેકનોલોજીનું પારદર્શક વર્ણન. અમે ઔદ્યોગિક જાર્ગનથી આગળ વધીને તમારા પરિવાર માટે એક સુરક્ષિત, માનવ-કેન્દ્રિત સેતુ પ્રદાન કરીએ છીએ.
સિસ્ટમ ડિઝાઇન
મારો ડેટા ખરેખર ક્યાં રહે છે?
અમે મુંબઈમાં એમેઝોનના ડેટા સેન્ટર્સ (ap-south-1) નો ઉપયોગ કરીએ છીએ. અમારી સિસ્ટમ “સર્વરલેસ” છે: patch કરવા કે log in કરવા માટે Soult દ્વારા સંચાલિત કોઈ સર્વર નથી, અને નીચેના મશીનોને AWS સુરક્ષિત રાખે છે. આનાથી attack surface ઘટે છે પણ સંપૂર્ણ દૂર થતી નથી — અમારા APIs, સાઇન-ઇન અને ક્લાઉડ કન્ફિગરેશનને હજુ પણ સુરક્ષાની જરૂર છે.
ap-south-1 (મુંબઈ) માં AWS Lambda પર serverless compute, સાથે DynamoDB, S3 અને Cognito. ડેટા અનેક Availability Zones માં સંગ્રહિત થાય છે. ક્રોસ-રીજન ડિઝાસ્ટર રિકવરી અમારા roadmap પર છે.
આજે એક રિજન, પછી સાઇલોસ
દરેક યુઝરનો ડેટા ક્યાં જાય છે?
આજે Soult AWS મુંબઈ, ભારતમાં એક જ silo તરીકે ચાલે છે, અને દરેક યુઝરનું vault ત્યાં જ સંગ્રહિત છે. અમે UAE માં લૉન્ચ કરવાની તૈયારી કરી રહ્યા છીએ. ત્યાંના યુઝર્સના vaults AWS મુંબઈ (ભારત) માં સંગ્રહિત થશે, અને સાઇન-અપ વખતે અમે તે માટે તેમની સ્પષ્ટ સંમતિ માંગીશું. અલગ પ્રાદેશિક silos અમારા roadmap પર છે.
આજે: દરેક યુઝર માટે એક silo, ap-south-1 (મુંબઈ); કોઈ દેશ-આધારિત રૂટિંગ લાઇવ નથી. Roadmap: સાઇન-અપ વખતે home-region રૂટિંગ, US silo (us-east-1, us-west-2), SEA silo (ap-southeast-1, ap-southeast-3) અને એક dedicated GCC silo.
AWS મુંબઈ શા માટે?
સ્થાનિક નિયમો અને સુરક્ષા.
AWS મુંબઈ અમને ભારતમાં એક પરિપક્વ, સ્વતંત્ર રીતે ઓડિટ થયેલ ડેટા-સેન્ટર વ્યવસ્થા આપે છે. તમારો ડેટા ભારતીય જમીન પર રાખવાથી તમારી વિરાસત ભારતીય કાયદાને અનુસરે છે અને કોઈ મુશ્કેલી વિના તમારા પરિવારની પહોંચમાં રહે છે.
ap-south-1 માં અનેક Availability Zones પર single-region deployment; ક્રોસ-રીજન DR અમારા roadmap પર. Native Cognito localised ફોન સપોર્ટ અને AWS KMS માં FIPS 140-validated cryptographic modules.
પ્રમાણીકરણ પ્રવાહ
સુરક્ષિત રીતે સાઇન અપ કરો અને લોગ ઇન કરો.
રજીસ્ટ્રેશન: ફોન OTP અને ઇમેઇલ OTP દ્વારા ચકાસવામાં આવે છે. તમે એક સુરક્ષા પ્રશ્ન અને 4-અંકનો MPIN સેટ કરો છો. વિશ્વસનીય ઉપયોગ: દૈનિક ઍક્સેસ માટે ફક્ત તમારા 4-અંકના MPIN ની જરૂર પડે છે. નવું ડિવાઇસ: 2-factor સુરક્ષા ટ્રિગર કરે છે — પહેલા ફોન OTP, પછી તમારો MPIN.
Multi-channel OTP verification. સુરક્ષા જવાબો one-way hashes તરીકે સંગ્રહિત થાય છે; MPIN ની ચકાસણી અને સંગ્રહ AWS Cognito દ્વારા થાય છે. નવા ડિવાઇસ પર Re-auth, MPIN પહેલાં OTP ટ્રિગર કરે છે.
શેર કરેલા ડિવાઇસ પર MPIN
મારો પરિવાર આ કેમ ખોલી શકતો નથી?
શેર કરેલા ફોનવાળા ઘરોમાં, ફિંગરપ્રિન્ટ્સ નોંધાયેલા કોઈપણને દાખલ થવા દે છે. જ્યારે બાળકો ગેમ્સ રમે અથવા તમારા જીવનસાથી ફોનનો ઉપયોગ કરે ત્યારે એક ખાનગી 4-અંકનો PIN તમારા vault ને ખાનગી રાખે છે.
4-અંકનો MPIN, જેની ચકાસણી અને સંગ્રહ AWS Cognito દ્વારા થાય છે. 3 નિષ્ફળ પ્રયાસો સાઇન-ઇનને 24 કલાક માટે લૉક કરે છે, જે server-side લાગુ થાય છે. Reinstall, ડિવાઇસ વાઇપ, અથવા ડિવાઇસ બદલવાથી lockout રીસેટ થતું નથી.
4-અંકનો PIN શા માટે?
શું 4 અંકો ખરેખર સુરક્ષિત છે?
હા — કારણ કે સુરક્ષા lockout છે, લંબાઈ નહીં. ત્રણ ખોટા પ્રયાસો અને તમારું vault 24 કલાક માટે લોક થઈ જાય છે. તમારા ફોન સાથેનો ચોર પણ દરવાજો બંધ થાય તે પહેલાં ફક્ત 3 અનુમાન લગાવી શકે છે. અમે જાણી જોઈને 6 ને બદલે 4 પસંદ કર્યા: લાંબા PINs વધુ ભૂલાઈ ગયેલા કોડ્સ, lockouts અને resets નું કારણ બને છે — અને વ્યવહારમાં સુરક્ષાનો વાસ્તવિક દુશ્મન મેમરી કોમ્પ્લેક્સિટી છે, raw entropy નહીં.
4-અંકનો સર્ચ સ્પેસ: 10⁴ = 10,000. Brute-force mitigation: server-side counter, 24 કલાક માટે 3-strike lockout. lockout સાથે Practical entropy unprotected 6-અંકની raw entropy કરતાં વધી જાય છે. Trade-off સ્વીકાર્ય: usability gain > marginal entropy gain.
હાર્ડ ડ્રાઇવનું જોખમ
જો કોઈ હાર્ડ ડ્રાઇવ ચોરી લે તો શું?
ડેટા AES-256 encrypted at rest છે. ચોરાયેલા હાર્ડવેરમાં ફક્ત અર્થહીન ciphertext હોય છે. Encryption keys નું સંચાલન AWS દ્વારા, ડેટાથી અલગ, થાય છે — ક્યારેય ડેટા સાથે સમાન ડિસ્ક પર નહીં.
ફાઇલો: S3 server-side encryption (SSE-S3, AES-256), દરેક object પર આપમેળે લાગુ. Tables: DynamoDB encryption at rest. High-sensitivity fields: write પહેલાં AWS KMS વડે વધારાનું encryption.
કી મેનેજમેન્ટ (KMS)
ચાવીઓ કોની પાસે છે?
AWS રાખે છે. અમારી field-encryption key AWS KMS ના hardware security modules ની અંદર રહે છે અને ક્યારેય વાંચી શકાય તેવા સ્વરૂપમાં બહાર આવતી નથી, તેથી Soult માં કોઈ પણ વ્યક્તિ ક્યારેય raw key સંભાળતી નથી. જ્યારે તમે કોઈ સુરક્ષિત field સેવ કરો છો કે જુઓ છો ત્યારે અમારી એપ્લિકેશન KMS ને તેનો ઉપયોગ કરવા કહે છે, અને આ જ ચકાસાયેલી પારિવારિક સોંપણી શક્ય બનાવે છે. ફાઇલો અને database tables માટેની keys નું સંચાલન AWS કરે છે.
સંવેદનશીલ fields: customer-managed key હેઠળ KMS Encrypt/Decrypt; key material ક્યારેય KMS ના FIPS 140-validated HSMs ની બહાર જતું નથી. ફાઇલો: S3 server-side encryption (SSE-S3, AES-256). Tables: DynamoDB encryption at rest.
ફિલ્ડ-લેવલ સુરક્ષા
તમારા સૌથી સંવેદનશીલ ફિલ્ડ્સ માટે ડબલ-લોક સુરક્ષા.
તમારી સૌથી સંવેદનશીલ વિગતો — આધાર, PAN અને પાસપોર્ટ નંબર, કાર્ડ અને એકાઉન્ટ નંબર, અને Standard Password Keeper પાસવર્ડ — માટે અમે એક બીજું લોક ઉમેરીએ છીએ. સેવ કરતા પહેલાં અમારા servers તે દરેક field ને AWS KMS key વડે encrypt કરે છે, તેથી database માં તે ciphertext તરીકે સંગ્રહિત હોય છે.
Customer-managed AWS KMS key સાથે server-side field-level encryption, જે અમારું backend write પહેલાં આ fields પર લાગુ કરે છે: આધાર, PAN અને પાસપોર્ટ નંબરો; પ્રાથમિક ક્રેડિટ અને ડેબિટ કાર્ડ નંબરો; લોન, ક્રેડિટ-કાર્ડ, ફિક્સ્ડ-ડિપોઝિટ, સરકારી-બચત અને વૈકલ્પિક-રોકાણ એકાઉન્ટ નંબરો; રોકાણ ટ્રાન્ઝેક્શન IDs; મિલકત દસ્તાવેજ ઓળખકર્તાઓ; અને Standard Password Keeper પાસવર્ડ્સ. KMS decrypt અધિકારો વિના table read કરવાથી તે fields માટે ફક્ત ciphertext જ મળે છે. વીમા પોલિસી નંબરો, બેંક પાસબુક એકાઉન્ટ નંબરો અને Will ની વિગતો ફક્ત at-rest encryption દ્વારા સુરક્ષિત છે.
Client-side encryption
Which secrets can even Soult never read?
Password Keeper ના બે સ્તર છે. રોજિંદા લૉગિન — Wi-Fi, સ્ટ્રીમિંગ — તમારા એપ MPIN વડે અનલૉક થાય છે, અને અમે તેમને રિકવર કરવામાં મદદ કરી શકીએ છીએ. તમારા સૌથી સંવેદનશીલ લૉગિન માટે તમે Advanced ચાલુ કરો છો, જે ક્યારેય તમારો ફોન ન છોડતા vault પાસવર્ડ વડે end-to-end લૉક થાય છે. Advanced એન્ટ્રી ઉમેરવા માટે કોઈ પાસવર્ડની જરૂર નથી; ફક્ત તેને વાંચવા માટે જ જરૂર પડે છે. અમે લૉક થયેલું પરિણામ સંગ્રહિત કરીએ છીએ અને તેને ખોલવાનું સાધન ક્યારેય રાખતા નથી — તેથી Soult પાસે કોઈ decrypt બટન નથી, કોઈ સ્ટાફ ઓવરરાઇડ નથી, અને કાનૂની આદેશ હેઠળ સોંપવા માટે કંઈ અર્થપૂર્ણ નથી. તમને એક 12-શબ્દનો recovery phrase પણ મળે છે, જે ફક્ત એક જ વાર બતાવવામાં આવે છે અને અમને ક્યારેય મળતો નથી. આ જ પ્રામાણિક ટ્રેડ-ઓફ છે: જો vault પાસવર્ડ અને phrase બંને ખોવાઈ જાય, તો તે પાસવર્ડ્સ કાયમ માટે જતા રહે છે, કારણ કે વિકલ્પનો અર્થ એ થાય કે અમે key રાખીએ. ફક્ત પાસવર્ડ પોતે જ સીલ થાય છે; એન્ટ્રીનું શીર્ષક, યુઝરનેમ, વેબસાઇટ, નોંધો અને સુરક્ષા પ્રશ્ન અને જવાબ Standard protection નો ઉપયોગ કરે છે.
પ્રતિ-યુઝર X25519 identity keypair; public key ખુલ્લી રીતે સંગ્રહિત થાય છે, 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) વડે wrap કરવામાં આવે છે. આ KDF parameters ની સક્રિય hardening સમીક્ષા ચાલી રહી છે; wire scheme versioned છે (enc_scheme=e2e_v2) અને દરેક wrap સ્વ-વર્ણનાત્મક છે, તેથી યુઝર્સને ફરીથી enroll કર્યા વિના parameters વધારી શકાય છે. ઉમેરાતી એન્ટ્રીઓ public-key શૈલીમાં સીલ થાય છે: નવું ephemeral X25519 keypair → identity public key સામે ECDH → HKDF-SHA256 (salt = ephemeral public key, info soult-pwk-e2e-v2) → AES-256-GCM. એન્ટ્રી ફક્ત ciphertext, IV અને ephemeral public key સંગ્રહિત કરે છે. એક જ seed ના બે સ્વતંત્ર wraps હોય છે — એક vault password હેઠળ, અને એક 256-શબ્દોની યાદીમાંથી લેવાયેલા 12-શબ્દના phrase (≈96 bits) હેઠળ, જે ડિવાઇસ પર જનરેટ થાય છે અને ક્યારેય ટ્રાન્સમિટ થતો નથી. MPIN ને key derivation માંથી જાણીજોઈને બાકાત રાખવામાં આવ્યો છે, કારણ કે અન્યથા તેને બદલવાથી કે ક્લિયર કરવાથી recovery કાયમ માટે બંધ થઈ જાય; recovery સમયે તેને અલગ UI gate તરીકે લાગુ કરવામાં આવે છે. enc_key_id = SHA-256(public key) ના પ્રથમ 8 bytes, તેથી vault reset પછી બદલાયેલી key પર સીલ થયેલી એન્ટ્રીઓ ચૂપચાપ નિષ્ફળ જવાને બદલે unrecoverable તરીકે ચિહ્નિત થાય છે. e2e_ schemes માટે backend KMS ને સંપૂર્ણપણે bypass કરે છે: આ fields માટે એવી કોઈ server-side key અસ્તિત્વમાં નથી જેને ફરજિયાત રીતે માંગી શકાય, ઓડિટ કરી શકાય કે દુરુપયોગ કરી શકાય. વ્યાપ: ફક્ત password field જ સીલ થાય છે; આ સુરક્ષા તમે ઇન્સ્ટોલ કરો છો તે એપની અખંડિતતા પર આધાર રાખે છે.
ટ્રાન્ઝિટમાં એન્ક્રિપ્શન
જાસૂસી-પ્રૂફ Wi-Fi.
તમારો ડેટા સુરક્ષિત TLS ટનલ દ્વારા પસાર થાય છે. પબ્લિક એરપોર્ટ કે કેફે Wi-Fi પર કોઈ જાસૂસી કરશે તો તેમને ફક્ત એન્ક્રિપ્ટેડ ગીબરિશ (અર્થહીન કોડ) જ દેખાશે — તમે શું અપલોડ કરો છો કે વાંચો છો તેની કોઈ માહિતી નહીં.
API Gateway HTTPS દ્વારા TLS 1.2+ લાગુ. ફાઇલો S3 presigned URLs દ્વારા અપલોડ થાય છે અને વાંચવામાં આવે છે, જે 15 મિનિટ પછી સમાપ્ત થાય છે.
“નિયમિત ઍક્સેસ નહીં” સિદ્ધાંત
શું Soult સ્ટાફ મારા રહસ્યો જોઈ શકે છે?
નિયમિત કામગીરીમાં નહીં. સામાન્ય કામકાજ દરમિયાન Soult ના કર્મચારીઓ તમારા વોલ્ટની સામગ્રી જોતા નથી; production systems ની ઍક્સેસ IAM દ્વારા પ્રતિબંધિત અને લોગ થયેલી છે. જ્યારે મૃત્યુના દાવાની સમીક્ષા થઈ રહી હોય, ત્યારે થોડા અધિકૃત કર્મચારીઓ તે એકાઉન્ટના દસ્તાવેજો ખોલી શકે છે, અને આવી દરેક ઍક્સેસ લોગ થાય છે. તમારા સૌથી સંવેદનશીલ fields KMS-encrypted ciphertext તરીકે પણ સંગ્રહિત છે.
એપ્લિકેશન રોલ્સ માટે લઘુત્તમ-પ્રિવિલેજ IAM. Production ઍક્સેસ થોડા નામાંકિત એડમિનિસ્ટ્રેટર્સ સુધી મર્યાદિત છે અને લોગ થાય છે. મૃત્યુ-દાવાના સમીક્ષકો એક ટૂંકી allowlist છે, અને તેઓ ખોલે છે તે દરેક દસ્તાવેજ લોગ થાય છે. Database લેયર પર ફક્ત KMS-encrypted fields જ ciphertext છે; અન્ય સામગ્રી IAM ઍક્સેસ કંટ્રોલ્સ અને લોગિંગ દ્વારા સુરક્ષિત છે.
બે Executor ની ભૂમિકાઓ
મારું વોલ્ટ કોણ જોઈ શકે છે?
Regular Executor (સામાન્ય રીતે પરિવારના સભ્ય): તેમનું પોતાનું ડેશબોર્ડ હોય છે જેમાં તેઓ જે લોકો માટે નિયુક્ત થયા છે તેમની યાદી હોય છે. તેઓ મૃત્યુનો દાવો રજૂ કરી શકે છે. Soult તેની ચકાસણી કરીને મંજૂરી આપે પછી જ તેઓ સાઇન ઇન કરી શકે છે — ફોન અને ઇમેઇલ OTP વડે — અને તમારું વોલ્ટ જોઈ શકે છે.
Emergency Executor (તમે પસંદ કરો તે કોઈ પણ વિશ્વાસુ વ્યક્તિ — જીવનસાથી, સંતાન, ભાઈ-બહેન કે મિત્ર): મૃત્યુના દાવાની જરૂર નથી. ફોન અને ઇમેઇલ OTP પછી ગમે ત્યારે સાઇન ઇન કરી શકે છે. તેઓ સાઇન ઇન કરે કે તરત જ તમને ઈમેલ મળે છે.
બંને ભૂમિકાઓ તમારું વોલ્ટ read-only મોડમાં જુએ છે. ઇમરજન્સી ભૂમિકા મેડિકલ ઇમરજન્સી અને સમય-સંવેદનશીલ પરિસ્થિતિઓ માટે છે; રેગ્યુલર ભૂમિકા મૃત્યુ પછી હેન્ડઓવર માટે છે. તમે કેટલા executors નિયુક્ત કરી શકો તે તમારા પ્લાન પર આધાર રાખે છે.
Application logic માં role-based access. દરેક executor પાસે is_emergency ફ્લેગ હોય છે (કોઈ પણ સંબંધ; કુલ executors ની મર્યાદા પ્લાન મુજબ). Non-emergency executors મૃત્યુનો દાવો મંજૂર થયા પછી જ સાઇન ઇન કરી શકે છે; emergency executors ગમે ત્યારે સાઇન ઇન કરી શકે છે. Executor સાઇન-ઇન માટે OTP ચકાસણી જરૂરી છે અને તે માલિકને ઇમેઇલ મોકલે છે. Executor sessions read-only હોય છે.
હેન્ડઓવર પ્રોટોકોલ
મારા પરિવારને ખરેખર એક્સેસ કેવી રીતે મળે છે?
નિયુક્ત Regular Executor તેમના ડેશબોર્ડ પરથી મૃત્યુનો દાવો રજૂ કરે છે અને મૃત્યુ પ્રમાણપત્ર અપલોડ કરે છે; તમને અને તમારા અન્ય Executors ને ઇમેઇલ મોકલવામાં આવે છે. Soult ના અધિકૃત એડમિનિસ્ટ્રેટર મંજૂરી આપતા પહેલાં દાવા અને પ્રમાણપત્રની સમીક્ષા કરે છે — ચકાસણી વિનાની વિનંતી પર કંઈ પણ આપવામાં આવતું નથી. મંજૂરી મળ્યા પછી, તમારું એકાઉન્ટ read-only બની જાય છે, અને Executor ફોન અને ઇમેઇલ OTP વડે સાઇન ઇન કરીને વોલ્ટ જુએ અને ડાઉનલોડ કરે છે. દર વખતે કોઈ Executor સાઇન ઇન કરે ત્યારે તમારા રજિસ્ટર્ડ સરનામે ઇમેઇલ જાય છે. જ્યાં સુધી તમે તમારા Executor માટે તમારો vault પાસવર્ડ કે Recovery Kit છોડ્યો ન હોય, ત્યાં સુધી Advanced Password Keeper ના પાસવર્ડ્સ લૉક જ રહે છે.
ગેટ: (1) નોંધાયેલ, ચકાસાયેલ executor તેમના ડેશબોર્ડ પરથી પ્રમાણપત્ર અપલોડ સાથે મૃત્યુનો દાવો રજૂ કરે છે; (2) Amazon SES માલિક અને અન્ય executors ને ઇમેઇલ કરે છે; (3) allowlist માં સામેલ Soult એડમિનિસ્ટ્રેટર દાવાની સમીક્ષા કરીને મંજૂરી આપે છે; (4) મંજૂરીથી ફોન + ઇમેઇલ OTP સાથે executor સાઇન-ઇન ખૂલે છે અને API લેયર પર એકાઉન્ટ read-only બને છે; (5) દરેક executor સાઇન-ઇન પર માલિકને ઇમેઇલ મળે છે. દાવાના અપલોડ અને મંજૂરીઓ સુરક્ષા ઇવેન્ટ લોગમાં નોંધાય છે.
ડિઝાઇન દ્વારા, કોઈ શેરિંગ નહીં
શું હું મારા CA અથવા જીવનસાથી સાથે એક ડોક્યુમેન્ટ શેર કરી શકું?
અત્યારે નહીં. અહીં કોઈ પર-આઇટમ શેરિંગ નથી, એકાઉન્ટન્ટ માટે કોઈ પર-ફોલ્ડર એક્સેસ નથી, કોઈ સમય-મર્યાદિત શેર લિંક નથી. તમારા વોલ્ટની અંદર કોઈ અન્ય વ્યક્તિ જોઈ શકે તે એકમાત્ર રસ્તો ઉપર વર્ણવેલ Executor ફ્લો દ્વારા છે — અને ત્યારે તેઓ બધું read-only મોડમાં જુએ છે. હજુ સુધી કોઈ પર-આઇટમ કે પર-ફોલ્ડર ગ્રેન્યુલારિટી નથી.
કોઈ સહયોગ મિકેનિઝમ લાગુ કરેલ નથી. એકમાત્ર એક્સેસ પાથ: (1) પ્રમાણિત માલિક સેશન, (2) વેરિફિકેશન પછી એક્ઝિક્યુટર સેશન. કોઈ શેર-લિંક જનરેશન નથી, કોઈ સ્કોપ્ડ ટોકન્સ નથી, કોઈ પ્રતિ-સંસાધન ACL નથી. ફક્ત રોડમેપ વિચારણા — બનેલ નથી.
વાસ્તવિકતા તપાસ
જોખમો શું છે?
અમે હેકર્સ, એકાઉન્ટ હડપ કરવા અને આંતરિક ઍક્સેસ સામે રક્ષણ આપવા માટે કામ કરીએ છીએ. જો તમને તમારો PIN શેર કરવા માટે શારીરિક રીતે દબાણ કરવામાં આવે, તો અમે તેને રોકી શકતા નથી. Soult સંસ્થા અને પરિવારની સાતત્યતા માટે છે — દબાણ હેઠળ ફરજિયાત ખુલાસાથી રક્ષણ માટે નહીં.
થ્રેટ મોડેલમાં શારીરિક દબાણનો સમાવેશ થતો નથી. નિવારણ: એક્સફિલ્ટ્રેશન, એકાઉન્ટ ટેકઓવર, આંતરિક એક્સેસ. અવકાશની બહાર: દબાણ હેઠળ PIN નિષ્કર્ષણ, અનલોક પછી ઉપકરણનું સમાધાન.
ભારતીય જમીન
મારો ડેટા ખરેખર ક્યાં રહે છે?
આજે, બધો vault ડેટા AWS મુંબઈમાં અમારા ભારત સાઇલોમાં રહે છે. અમે UAE માં લૉન્ચ કરવાની તૈયારી કરી રહ્યા છીએ. ત્યાંના યુઝર્સના vaults AWS મુંબઈ (ભારત) માં સંગ્રહિત થશે, અને સાઇન-અપ વખતે અમે તે માટે તેમની સ્પષ્ટ સંમતિ માંગીશું. US અને દક્ષિણપૂર્વ એશિયા માટેના ભવિષ્યના સાઇલો, અને એક સમર્પિત GCC સાઇલો, અમારા roadmap પર છે.
સક્રિય સિલો: ap-south-1 (મુંબઈ), જેમાં ડેટા અનેક Availability Zones માં સંગ્રહિત છે. ક્રોસ-રીજન DR અમારા roadmap પર છે. DPDP એક્ટ, 2023 ના સિદ્ધાંતોને ધ્યાનમાં રાખીને બનાવેલ. બીજો કોઈ સિલો લાઇવ નથી, અને કોઈ પણ યુઝરને GCC રીજનમાંથી સેવા આપવામાં આવતી નથી.
ડિઝાસ્ટર રિકવરી ટિયર્સ
નિષ્ફળતાના દરેક સ્તરે શું થાય છે?
ટિયર 1 — એક સર્વર નિષ્ફળ જાય: યુઝર્સને ખબર પણ પડતી નથી; AWS ની managed services તેને આપમેળે બદલી નાખે છે.
ટિયર 2 — મુંબઈનું એક ડેટા સેન્ટર નિષ્ફળ જાય: સેવા ચાલુ રહે છે, કારણ કે તમારો ડેટા પહેલેથી જ મુંબઈના અનેક ડેટા સેન્ટર્સમાં સંગ્રહિત છે.
ટિયર 3 — આખું મુંબઈ રીજન ડાઉન થાય: AWS તેને પુનઃસ્થાપિત કરે ત્યાં સુધી સેવા થંભી જાય છે. બીજા રીજનમાં standby અમારા roadmap પર છે, આજે લાઇવ નથી.
ટિયર 4 — મુંબઈ રીજન કાયમ માટે નષ્ટ થાય: આજે અમે તેમાંથી સંપૂર્ણ રિકવર કરી શકતા નથી. ક્રોસ-રીજન બેકઅપ રેપ્લિકેશન અમારા roadmap પર છે. ત્યાં સુધી, તમારો પોતાનો બેકઅપ રાખવો એ સૌથી મજબૂત સુરક્ષા છે.
ટિયર 1: managed-service સ્વ-હીલિંગ (Lambda, DynamoDB, S3). ટિયર 2: ap-south-1 ની અંદર multi-AZ સ્ટોરેજ. ટિયર 3–4: આજે કોઈ ક્રોસ-રીજન failover નથી; બીજા રીજનમાં ક્રોસ-રીજન બેકઅપ રેપ્લિકેશન અમારા roadmap પર છે.
ઓડિટ ટ્રેઇલ
બદલાવનો રેકોર્ડ.
તમારા vault માં થયેલા દરેક Create, Update કે Delete ની નોંધ — કોણે ફેરફાર કર્યો અને ક્યારે, તે સાથે.
DynamoDB માં audit log table. Write operations (CUD) ટ્રેક કરે છે. યુઝર પ્રાઇવસી અને પર્ફોર્મન્સ બેલેન્સ માટે Read events બાકાત રાખવામાં આવે છે. એકાઉન્ટની સાથે જ ડિલીટ થાય છે.
ડેટાના ઉપયોગની મર્યાદાઓ
વેચાણ નહીં, ટ્રેનિંગ નહીં, કોઈ નવાઈ નહીં.
તમારી vault સામગ્રીનો ઉપયોગ ક્યારેય AI મોડલને તાલીમ આપવા અથવા માર્કેટિંગ માટે થતો નથી. જ્યારે ઍપમાં AI સુવિધાઓનો ઉપયોગ થાય છે, ત્યારે તે સેશનનો ડેટા ફક્ત સંદર્ભમાં જ પ્રક્રિયા કરવામાં આવે છે — મોડેલ સુધારણા માટે ક્યારેય જાળવી રાખવામાં આવતો નથી. આવક ફક્ત સબ્સ્ક્રિપ્શન-આધારિત છે. જો અમે ક્યારેય કમાણીની નવી રીત — કોઈપણ ફેરફાર — વિશે વિચારીશું, તો અમે પહેલા તમને પૂછીશું. સૂચિત નહીં કરીએ. જાહેરાત નહીં કરીએ. પૂછીશું. અને અમે ફક્ત ત્યારે જ પૂછીશું જો અમને ખરેખર લાગશે કે તે તમને લાભ કરશે.
ડેટા આઇસોલેશન. કોઈ પણ vault content AI/ML ટ્રેનિંગ પાઇપલાઇન્સમાં ફીડ કરવામાં આવતો નથી. AI ફીચર્સ ડેટાને ફક્ત in-context per session જ પ્રોસેસ કરે છે — મોડેલ સુધારવા માટે કોઈ રીટેન્શન નહીં. રેવન્યુ મોડેલ vault content થી સ્વતંત્ર છે. ભવિષ્યમાં મોનેટાઇઝેશનના બદલાવ માટે સ્પષ્ટ per-user opt-in જરૂરી રહેશે — announce-and-proceed નહીં.
પ્રાઇવસી વિરુદ્ધ હેન્ડઓવર
પુલનો વિકલ્પ.
ચેટ ઍપ્સ સંપૂર્ણ ગુપ્તતા પર ધ્યાન કેન્દ્રિત કરે છે — જો તમે ચાવી ગુમાવો, તો તેઓ તમને મદદ કરી શકતા નથી. જીવન vault માટે તે એક નિષ્ફળતા છે. તેથી અમે Soult ને અલગ રીતે ડિઝાઇન કર્યું છે: તમારું vault ડિઝાઇનથી પુનઃપ્રાપ્ત કરી શકાય તેવું છે, જેથી ખોવાયેલો ફોન કે ભૂલાયેલો PIN ક્યારેય તમારા પરિવારને બહાર ન રાખે, અને ચકાસાયેલ executors તમે છોડેલું મેળવી શકે. Soult ના કર્મચારીઓને નિયમિત ઍક્સેસ નથી, અને હેન્ડઓવર ફક્ત ચકાસાયેલ માર્ગ દ્વારા જ થાય છે. જે થોડા પાસવર્ડ ફક્ત તમે જ ક્યારેય ખોલવા જોઈએ, તેમના માટે Advanced Password Keeper તમને એકમાત્ર કસ્ટડી આપે છે. Soult તમારી વિરાસતનો સેતુ છે, ડિજિટલ ડેડ એન્ડ નથી.
Standard vault ડેટા server-side encrypted છે (S3 અને DynamoDB encryption at rest, ઉપરાંત સંવેદનશીલ fields માટે AWS KMS), તેથી તે તમને પાછો આપી શકાય છે અથવા ચકાસાયેલ executor ને read-only બતાવી શકાય છે. સ્ટાફની કોઈ નિયમિત ઍક્સેસ નથી; હેન્ડઓવર માટે ઉપર વર્ણવેલ ચકાસાયેલ મૃત્યુ-દાવા ફ્લો જરૂરી છે. Advanced Password Keeper એન્ટ્રીઓ (e2e_v2) એ એકમાત્ર ડેટા છે જે Soult decrypt કરી શકતું નથી.
રોડમેપ
આગળ શું આવી રહ્યું છે?
નજીકના ભવિષ્યમાં: એક-ક્લિક vault નિકાસ (આજે વપરાશકર્તાઓ મેન્યુઅલી બેકઅપ લે છે); US સાયલો (N. Virginia, DR Oregon); SEA સાયલો (Singapore, DR Jakarta); ક્રોસ-સાયલો બેકઅપ રેપ્લિકેશન જેથી આખો પ્રદેશ ખોવાઈ જાય તો પણ કંઈક હંમેશા બચી રહે.
મધ્યમ ગાળામાં: એક સમર્પિત GCC સાયલો; SOC 2 Type II.
હંમેશા ચાલુ: ચાલુ ઑડિટ, સુરક્ષા મજબૂતીકરણ, ઇન્ફ્રાસ્ટ્રક્ચર સમીક્ષાઓ.
Phase 1 (આગામી): one-click encrypted export, US silo bring-up. Phase 2: SEA silo, cross-silo cold backup replication, WAF, SSL pinning on mobile clients. Phase 3: dedicated GCC silo, SOC 2 Type II, hardened multi-region KMS.
પ્રામાણિક દાવાઓ
દરેક માર્કેટિંગ દાવા, ચકાસાયેલ. આજે શું સાચું છે, શું આયોજનમાં છે, શું બન્યું નથી, અને શું અમે ઉપયોગ કરતા નથી.
| દાવો | સ્થિતિ | વ્યવહારિક સત્ય |
|---|---|---|
| સ્ટાફની નિયમિત ઍક્સેસ નહીં | સાચું | Vault સામગ્રીની નિયમિત સ્ટાફ ઍક્સેસ નથી; production ઍક્સેસ પ્રતિબંધિત અને લોગ થયેલી છે. સમીક્ષકોની એક નાની allowlist મૃત્યુના દાવાની સમીક્ષા કરતી વખતે એકાઉન્ટના દસ્તાવેજો ખોલી શકે છે, અને દરેક ઍક્સેસ લોગ થાય છે. Advanced Password Keeper પાસવર્ડ્સ સિવાય, આ એક ઍક્સેસ કંટ્રોલ છે, ટેકનિકલ અશક્યતા નથી. |
| ભારતમાં ડેટા રેસિડેન્સી | સાચું | બધો vault ડેટા ભારતમાં, AWS મુંબઈમાં સંગ્રહિત છે. કેટલોક ઓપરેશનલ ડેટા (સાઇન-ઇન કોડ, પેમેન્ટ્સ, એનાલિટિક્સ, ક્રેશ રિપોર્ટ્સ) એવા પ્રોવાઇડર્સ દ્વારા સંભાળવામાં આવે છે જે તેના પર ભારતની બહાર પ્રક્રિયા કરી શકે છે. |
| ISO 27001 અને ISO 9001 સર્ટિફિકેશન | પ્રગતિમાં | સુરક્ષા પ્રોગ્રામ ISO 27001 સાથે સંરેખિત. ગુણવત્તા વ્યવસ્થાપન ISO 9001 સાથે સંરેખિત. બંને માટે માન્યતાપ્રાપ્ત સર્ટિફિકેશન પ્રગતિમાં છે. |
| AES-256 એન્ક્રિપ્શન | સાચું | બધો vault ડેટા AES-256 વડે at rest encrypted છે, અને સંવેદનશીલ fields ને AWS KMS નું વધારાનું સ્તર મળે છે. |
| Password Keeper — Standard | સાચું | ડિફૉલ્ટ. પાસવર્ડ AWS KMS વડે અમારા servers પર encrypted છે, તેથી તેને પુનઃપ્રાપ્ત કરીને તમારા Executors ને સોંપી શકાય છે. |
| Password Keeper — Advanced | લાઇવ | જુલાઈ 2026 થી લાઇવ (opt-in). કોઈ Password Keeper એન્ટ્રી માટે Advanced ચાલુ કરો, અને તેનો પાસવર્ડ તમારા ફોન પર ફક્ત તમે જ જાણો છો તે vault password માંથી મેળવેલી key વડે encrypt થાય છે, તેથી Soult તેને decrypt કરી શકતું નથી. એન્ટ્રીની અન્ય વિગતો (શીર્ષક, યુઝરનેમ, વેબસાઇટ, નોંધો, અને સુરક્ષા પ્રશ્ન અને જવાબ) Standard protection નો ઉપયોગ કરે છે. જો તમારો vault password અને તમારો 12-શબ્દનો recovery phrase બંને ખોવાઈ જાય, તો તે પાસવર્ડ પુનઃપ્રાપ્ત કરી શકાતો નથી. |
| વન-ક્લિક vault એક્સપોર્ટ | આયોજનમાં | આજે ઉપલબ્ધ નથી. યુઝર્સ મેન્યુઅલ બેકઅપ લે છે. એક-ક્લિક એક્સપોર્ટ અમારા roadmap પર છે. |
| આઇટમ દીઠ શેરિંગ | ઉપલબ્ધ નથી | આજે કોઈ શેરિંગ કે સહયોગ નથી. Executor flow જ એકમાત્ર એક્સેસ પાથ છે. |
| ક્રોસ-સાઇલો બેકઅપ | રોડમેપમાં | બીજા રીજનમાં બેકઅપ રેપ્લિકેશન અમારા roadmap પર છે અને US/SEA સાઇલોઝ ડિપ્લોય થશે ત્યારે આવશે. |
| ક્રોસ-રીજન ડિઝાસ્ટર રિકવરી | રોડમેપ | આજે તમારો ડેટા એક AWS રીજન (મુંબઈ) માં રહે છે, જ્યાં તે અનેક ડેટા સેન્ટર્સમાં સંગ્રહિત છે. બીજા રીજનમાં standby અમારા roadmap પર છે; ત્યાં સુધી, આખું રીજન ગુમાવવા સામે તમારો પોતાનો બેકઅપ સૌથી મજબૂત સુરક્ષા છે. |
| લાઇવ સિસ્ટમ્સમાંથી ડિલીશન | તાત્કાલિક | 10-સેકન્ડની પુષ્ટિ અને તમારો MPIN, પછી તમારું લૉગિન, રેકોર્ડ્સ અને ફાઇલો લાઇવ સિસ્ટમ્સમાંથી દૂર થાય છે. કોઈ પર-યુઝર key નથી, તેથી બેકઅપ, ફાઇલોના અગાઉના વર્ઝન અને લોગ્સ crypto-shred થતા નથી કે તરત જ ભૂંસાતા નથી. |
| યુઝર ડેટા પર AI ટ્રેનિંગ | ક્યારેય નહીં | વૉલ્ટની સામગ્રીનો ઉપયોગ AI મોડેલ ટ્રેનિંગ માટે ક્યારેય થતો નથી, ભલે AI ફીચર્સ સેશનમાં ઉપયોગમાં લેવાય. |
| બ્લોકચેન | ઉપયોગ થતો નથી | પ્રાઇવેટ વૉલ્ટ માટે ખોટું ટૂલ. તેના બદલે અમે ઓડિટ લોગ્સનો ઉપયોગ કરીએ છીએ. |
| ઝીરો-નોલેજ એન્ક્રિપ્શન | આંશિક રીતે લાઇવ | આજે આંશિક રીતે લાઇવ. Advanced Password Keeper એન્ટ્રીઓ ખરેખર client-side encrypted છે — એવા vault password માંથી મેળવેલી key વડે સીલ થયેલી, જે ક્યારેય અમારા સુધી પહોંચતો નથી, તેથી અમે તેમને decrypt કરી શકતા નથી (જુઓ Client-side encryption). બાકીનું vault અમારા servers પર encrypted છે, જેમાં સંવેદનશીલ fields AWS KMS હેઠળ છે. તે મજબૂત છે, પરંતુ zero-knowledge નથી — જાણીજોઈને, જેથી તમારો પરિવાર ક્યારેય બહાર ન રહી જાય. વધુ વ્યાપક opt-in zero-knowledge વિકલ્પો અમારા roadmap પર રહે છે. |
સામાન્ય પ્રશ્નો
હું મારો ડેટા કેવી રીતે ડિલીટ કરી શકું?
10-સેકન્ડના પુષ્ટિ વિરામ અને તમારા MPIN પછી, તમારું સાઇન-ઇન અને vault રેકોર્ડ્સ અમારા databases માંથી ડિલીટ થાય છે અને તમારી ફાઇલો સક્રિય સ્ટોરેજમાંથી તરત જ દૂર થાય છે. આ ન તો તમે કે ન તો અમારી સપોર્ટ ટીમ પાછું લાવી શકે છે. બેકઅપ, ફાઇલોના અગાઉના વર્ઝન અને સિસ્ટમ લોગ્સમાંની કોપીઓ તરત જ ભૂંસાતી નથી, અને પેમેન્ટ રેકોર્ડ તમારી વ્યક્તિગત વિગતો દૂર કરીને રાખવામાં આવે છે. તમે જે કંઈ રાખવા માંગતા હો તે પહેલાં ડાઉનલોડ કરી લો. એક-ક્લિક એક્સપોર્ટ અમારા roadmap પર છે.
જો Soult બંધ થઈ જાય તો શું?
જો Soult ને ક્યારેય બંધ કરવું પડે, તો અમે તમને અગાઉથી જાણ કરીશું અને તમારા vault ની કોપી મેળવવામાં તમારી મદદ કરીશું. એક-ક્લિક એક્સપોર્ટ અમારા roadmap પર છે. અમે તમારો ડેટા વેચીશું નહીં કે તમારી સંમતિ વિના તમારા વૉલ્ટને કોઈ ખરીદનારને ટ્રાન્સફર કરીશું નહીં.
સબ્સ્ક્રિપ્શન્સનું બિલિંગ કેવી રીતે થાય છે?
Soult વેબસાઇટ પર Razorpay દ્વારા મેનેજ થાય છે. કોઈ ઇન-એપ ખરીદી નથી. આ બિલિંગને તમારા વૉલ્ટ ડિવાઇસથી અલગ રાખે છે.
ઇરેઝર પ્રોટોકોલની વિગતો?
પુષ્ટિ થતાં, યુઝરનું Cognito સાઇન-ઇન ડિલીટ થાય છે, DynamoDB માંના vault tables માંથી તેમની rows purge થાય છે અને તેમની S3 ફાઇલો સક્રિય સ્ટોરેજમાંથી દૂર થાય છે, ત્યારબાદ asynchronous બીજો clean-up pass થાય છે. પેમેન્ટ રેકોર્ડ્સ વ્યક્તિગત વિગતો redact કરીને રાખવામાં આવે છે. કોઈ પર-યુઝર key નથી, તેથી crypto-shredding નથી; બેકઅપ, ફાઇલોના અગાઉના વર્ઝન અને લોગ્સ તરત જ ભૂંસાતા નથી.
Soult બ્લોકચેનનો ઉપયોગ કેમ નથી કરતું?
બ્લોકચેન જાહેર ચકાસણી માટે બનાવવામાં આવ્યું છે, જ્યાં પક્ષો એકબીજા પર વિશ્વાસ કરતા નથી તેવા શેર કરેલા લેજર્સ પર — જેમ કે ક્રિપ્ટોકરન્સી, હરીફો વચ્ચેની સપ્લાય ચેઇન, જાહેર જમીન રેકોર્ડ્સ. તેની તાકાત એ છે કે તે છેડછાડને દુનિયા સમક્ષ દૃશ્યમાન બનાવે છે.
Soult વૉલ્ટ્સ જાહેરથી વિપરીત છે — તે ડિઝાઇન દ્વારા ખાનગી છે. ડેટામાં હિસ્સો ધરાવનાર એકમાત્ર પક્ષ યુઝર છે. છેડછાડનો ઇરાદો ઓછો હોય છે: તે યુઝરનો પોતાનો ડેટા છે, જે યુઝરના પોતાના પરિવાર માટે રાખવામાં આવે છે.
ફેરફાર ટ્રેકિંગ માટે, અમે ઓડિટ લોગ્સનો ઉપયોગ કરીએ છીએ (વિભાગ 14 જુઓ) — દરેક Create, Update, Delete ટાઇમસ્ટેમ્પ અને એક્ટર સાથે રેકોર્ડ કરવામાં આવે છે. બ્લોકચેન ખર્ચ, જટિલતા ઉમેરશે અને જાહેર લેજરમાં પેટર્ન ખુલ્લી કરીને ગોપનીયતા ઘટાડશે — કોઈપણ યુઝર સમસ્યા હલ કર્યા વિના.
જો અને જ્યારે ચકાસાયેલ-જાહેર પ્રમાણપત્ર વાસ્તવિક યુઝરની જરૂરિયાત બનશે ત્યારે પુનર્વિચાર કરવામાં આવશે.
Soult શું કરી શકે છે અને શું નથી કરી શકતું તે વિશે વધુ — Legal Validity પેજ વાંચો. Executor પ્રોટોકોલની વિગતવાર માહિતી માટે, Executor & Handover Flow જુઓ.
મફતમાં શરૂ કરો →