আর্কিটেকচার তৈরি করা হয়েছে
জীবনের ধারাবাহিকতার জন্য।
আপনার ডিজিটাল লাইফ vault-এর পেছনের প্রযুক্তির একটি স্বচ্ছ বিবরণ। আমরা ঠান্ডা শিল্প পরিভাষা থেকে সরে এসে আপনার পরিবারের জন্য একটি নিরাপদ, মানব-কেন্দ্রিক সেতু প্রদান করি।
সিস্টেম ডিজাইন
আমার ডেটা আসলে কোথায় থাকে?
আমরা মুম্বাইয়ের Amazon ডেটা সেন্টার (ap-south-1) ব্যবহার করি। আমাদের সিস্টেম “serverless”: প্যাচ করার বা লগ ইন করার মতো কোনো Soult-পরিচালিত সার্ভার নেই, এবং নিচের মেশিনগুলি AWS সুরক্ষিত রাখে। এতে অ্যাটাক সারফেস কমে, কিন্তু পুরোপুরি দূর হয় না — আমাদের API, সাইন-ইন এবং ক্লাউড কনফিগারেশন এখনও সুরক্ষিত রাখতে হয়।
ap-south-1 (মুম্বাই)-তে AWS Lambda-য় serverless কম্পিউট, সাথে DynamoDB, S3 এবং Cognito। ডেটা একাধিক Availability Zone জুড়ে সংরক্ষিত। ক্রস-রিজিয়ন দুর্যোগ পুনরুদ্ধার আমাদের রোডম্যাপে রয়েছে।
আজ একটি অঞ্চল, এরপর সিলো
প্রতিটি ব্যবহারকারীর ডেটা কোথায় যায়?
বর্তমানে Soult AWS মুম্বাই, ভারতে একটিমাত্র সিলো হিসেবে চলে, এবং প্রতিটি ব্যবহারকারীর ভল্ট সেখানেই সংরক্ষিত। আমরা UAE-তে লঞ্চ করার প্রস্তুতি নিচ্ছি। সেখানকার ব্যবহারকারীদের ভল্ট AWS মুম্বাইতে (ভারত) সংরক্ষিত হবে, এবং সাইন-আপের সময় আমরা এ বিষয়ে তাঁদের স্পষ্ট সম্মতি চাইব। আলাদা আঞ্চলিক সিলো আমাদের রোডম্যাপে আছে।
বর্তমানে: প্রতিটি ব্যবহারকারীর জন্য একটি সিলো, ap-south-1 (মুম্বাই); দেশ-ভিত্তিক কোনো রাউটিং চালু নেই। রোডম্যাপ: সাইন-আপের সময় হোম-রিজিয়ন রাউটিং, একটি US সিলো (us-east-1, us-west-2), একটি SEA সিলো (ap-southeast-1, ap-southeast-3) এবং একটি ডেডিকেটেড GCC সিলো।
কেন AWS মুম্বাই?
স্থানীয় নিয়মকানুন এবং সুরক্ষা।
AWS মুম্বাই আমাদের ভারতে একটি পরিণত, স্বাধীনভাবে অডিট করা ডেটা সেন্টার পরিকাঠামো দেয়। ভারতীয় ভূখণ্ডে ডেটা রাখলে আপনার উত্তরাধিকার ভারতীয় আইন মেনে চলে এবং কোনো জটিলতা ছাড়াই আপনার পরিবারের নাগালের মধ্যে থাকে।
ap-south-1-এ একাধিক Availability Zone জুড়ে সিঙ্গেল-রিজিয়ন ডিপ্লয়মেন্ট; ক্রস-রিজিয়ন DR আমাদের রোডম্যাপে। নেটিভ Cognito লোকালাইজড ফোন সাপোর্ট এবং AWS KMS-এ FIPS 140-ভ্যালিডেটেড ক্রিপ্টোগ্রাফিক মডিউল।
অথেন্টিকেশন ফ্লো
নিরাপদে সাইন আপ করুন এবং লগ ইন করুন।
রেজিস্ট্রেশন: ফোন OTP এবং ইমেল OTP-এর মাধ্যমে যাচাই করা হয়। আপনি একটি সিকিউরিটি প্রশ্ন এবং একটি ৪-ডিজিটের MPIN সেট করেন। বিশ্বস্ত ব্যবহার: প্রতিদিনের অ্যাক্সেসের জন্য শুধুমাত্র আপনার ৪-ডিজিটের MPIN প্রয়োজন। নতুন ডিভাইস: ২-ফ্যাক্টর সিকিউরিটি চালু করে — প্রথমে ফোন OTP, তারপর আপনার MPIN।
মাল্টি-চ্যানেল OTP ভেরিফিকেশন। সিকিউরিটি উত্তরগুলি ওয়ান-ওয়ে হ্যাশ হিসেবে সংরক্ষিত হয়; MPIN যাচাই ও সংরক্ষণ করে AWS Cognito। নতুন ডিভাইসে রি-অথেন্টিকেশনে MPIN-এর আগে OTP চাওয়া হয়।
শেয়ার করা ডিভাইসে MPIN
আমার পরিবার কেন এটা খুলতে পারবে না?
যেসব বাড়িতে ফোন শেয়ার করা হয়, সেখানে এনরোল করা যে কেউ ফিঙ্গারপ্রিন্ট দিয়ে ঢুকতে পারে। একটি ব্যক্তিগত ৪-ডিজিটের PIN আপনার ভল্টকে সুরক্ষিত রাখে, যখন বাচ্চারা গেম খেলে বা আপনার সঙ্গী ফোন ব্যবহার করে।
৪-ডিজিটের MPIN, যা AWS Cognito যাচাই ও সংরক্ষণ করে। ৩টি ব্যর্থ চেষ্টার পর সাইন-ইন ২৪ ঘণ্টার জন্য লক হয়ে যায়, যা সার্ভার-সাইডে কার্যকর করা হয়। পুনরায় ইনস্টল, ডিভাইস ওয়াইপ বা ডিভাইস পরিবর্তন করলেও লকআউট রিসেট হয় না।
কেন ৪-ডিজিটের PIN?
৪-ডিজিট কি সত্যিই সুরক্ষিত?
হ্যাঁ — কারণ সুরক্ষা লকআউটে, দৈর্ঘ্যে নয়। তিনবার ভুল চেষ্টা করলে আপনার ভল্ট ২৪ ঘণ্টার জন্য লক হয়ে যায়। এমনকি আপনার ফোন চুরি করলেও চোর দরজা বন্ধ হওয়ার আগে মাত্র ৩ বার চেষ্টা করার সুযোগ পায়। আমরা ইচ্ছাকৃতভাবে ৬-এর বদলে ৪ বেছে নিয়েছি: লম্বা PIN-এর কারণে বেশি কোড ভুলে যাওয়া, লকআউট এবং রিসেট হয় — আর বাস্তবে সুরক্ষার আসল শত্রু হল মেমরি কমপ্লেক্সিটি, কাঁচা এনট্রপি নয়।
৪-ডিজিটের সার্চ স্পেস: 10⁴ = 10,000। ব্রুট-ফোর্স কমানোর জন্য: সার্ভার-সাইড কাউন্টার, ২৪ ঘণ্টার জন্য ৩-স্ট্রাইক লকআউট। লকআউট সহ ব্যবহারিক এনট্রপি অসুরক্ষিত ৬-ডিজিটের কাঁচা এনট্রপিকে ছাড়িয়ে যায়। ট্রেড-অফ গৃহীত: ব্যবহারযোগ্যতার লাভ > প্রান্তিক এনট্রপির লাভ।
হার্ড ড্রাইভের ঝুঁকি
যদি কেউ হার্ড ড্রাইভ চুরি করে?
ডেটা অ্যাট রেস্ট AES-256 এনক্রিপ্টেড। চুরি হওয়া হার্ডওয়্যারে শুধুমাত্র অর্থহীন সাইফারটেক্সট থাকে। এনক্রিপশন কী AWS পরিচালনা করে, ডেটা থেকে আলাদাভাবে — কখনও একই ডিস্কে নয়।
ফাইল: S3 সার্ভার-সাইড এনক্রিপশন (SSE-S3, AES-256), প্রতিটি অবজেক্টে স্বয়ংক্রিয়ভাবে প্রয়োগ করা হয়। টেবিল: DynamoDB এনক্রিপশন অ্যাট রেস্ট। উচ্চ-সংবেদনশীল ফিল্ড: লেখার আগে অতিরিক্তভাবে AWS KMS দিয়ে এনক্রিপ্ট করা হয়।
কী ম্যানেজমেন্ট (KMS)
চাবি কার কাছে থাকে?
AWS রাখে। আমাদের ফিল্ড-এনক্রিপশন কী AWS KMS-এর হার্ডওয়্যার সিকিউরিটি মডিউলের ভেতরে থাকে এবং কখনও পাঠযোগ্য রূপে সেখান থেকে বের হয় না, তাই Soult-এর কেউ কখনও আসল কী হাতে পান না। আপনি যখন কোনো সুরক্ষিত ফিল্ড সেভ করেন বা দেখেন, তখন আমাদের অ্যাপ্লিকেশন KMS-কে সেটি ব্যবহার করতে বলে, এবং এটিই পরিবারের কাছে যাচাই করা হস্তান্তর সম্ভব করে। ফাইল এবং ডেটাবেস টেবিলের কী AWS পরিচালনা করে।
সংবেদনশীল ফিল্ড: একটি কাস্টমার-ম্যানেজড কী-এর অধীনে KMS Encrypt/Decrypt; কী ম্যাটেরিয়াল কখনও KMS-এর FIPS 140-ভ্যালিডেটেড HSM ছেড়ে যায় না। ফাইল: S3 সার্ভার-সাইড এনক্রিপশন (SSE-S3, AES-256)। টেবিল: DynamoDB এনক্রিপশন অ্যাট রেস্ট।
ফিল্ড-লেভেল সিকিউরিটি
আপনার সবচেয়ে সংবেদনশীল ফিল্ডগুলির জন্য ডাবল-লক সুরক্ষা।
আপনার সবচেয়ে সংবেদনশীল তথ্যের জন্য — Aadhaar, PAN ও পাসপোর্ট নম্বর, কার্ড ও অ্যাকাউন্ট নম্বর, এবং Standard Password Keeper-এর পাসওয়ার্ড — আমরা একটি দ্বিতীয় লক যোগ করি। সংরক্ষণের আগে আমাদের সার্ভার এই প্রতিটি ফিল্ড একটি AWS KMS কী দিয়ে এনক্রিপ্ট করে, তাই ডেটাবেসে সেগুলি সাইফারটেক্সট হিসেবে সংরক্ষিত থাকে।
একটি কাস্টমার-ম্যানেজড AWS KMS কী দিয়ে সার্ভার-সাইড ফিল্ড-লেভেল এনক্রিপশন, যা আমাদের ব্যাকএন্ড লেখার আগে এই ফিল্ডগুলিতে প্রয়োগ করে: Aadhaar, PAN এবং পাসপোর্ট নম্বর; প্রাইমারি ক্রেডিট ও ডেবিট কার্ড নম্বর; লোন, ক্রেডিট-কার্ড, ফিক্সড-ডিপোজিট, সরকারি-সঞ্চয় এবং বিকল্প-বিনিয়োগ অ্যাকাউন্ট নম্বর; বিনিয়োগ লেনদেনের আইডি; সম্পত্তির ডকুমেন্ট আইডেন্টিফায়ার; এবং Standard Password Keeper পাসওয়ার্ড। KMS ডিক্রিপ্ট অধিকার ছাড়া টেবিল রিড করলে সেই ফিল্ডগুলির জন্য শুধু সাইফারটেক্সট পাওয়া যায়। বিমা পলিসি নম্বর, ব্যাঙ্ক পাসবুক অ্যাকাউন্ট নম্বর এবং উইলের বিবরণ শুধুমাত্র অ্যাট-রেস্ট এনক্রিপশন দ্বারা সুরক্ষিত।
Client-side encryption
কোন সিক্রেট Soult নিজেও পড়তে পারবে না?
Password Keeper-এর দুটি লেভেল আছে। সাধারণ লগইন — Wi-Fi, স্ট্রিমিং — আপনার অ্যাপ MPIN দিয়ে আনলক হয়, এবং আমরা সেগুলি রিকভার করতে সাহায্য করতে পারি। আপনার সবচেয়ে সংবেদনশীল লগইনগুলির জন্য আপনি Advanced চালু করেন, যা একটি ভল্ট পাসওয়ার্ড দিয়ে এন্ড-টু-এন্ড লক করা থাকে যা কখনও আপনার ফোন ছেড়ে যায় না। Advanced এন্ট্রি যোগ করার জন্য কোনও পাসওয়ার্ডের প্রয়োজন হয় না; শুধু একটি পড়ার জন্য প্রয়োজন হয়। আমরা লক করা ফলাফল সংরক্ষণ করি এবং এটি খোলার কোনও উপায় কখনও আমাদের কাছে থাকে না — তাই কোনও Soult ডিক্রিপ্ট বাটন নেই, কোনও স্টাফ ওভাররাইড নেই, এবং কোনও আইনি আদেশে হস্তান্তর করার মতো অর্থবহ কিছুই নেই। আপনি একটি 12-শব্দের রিকভারি ফ্রেজও পাবেন, যা একবারই দেখানো হয় এবং আমরা কখনও পাই না। এটাই সৎ বিনিময়: ভল্ট পাসওয়ার্ড এবং ফ্রেজ দুটোই হারালে সেই পাসওয়ার্ডগুলি স্থায়ীভাবে চলে যাবে, কারণ বিকল্পটি হতো আমাদের কাছে একটি কী রাখা। শুধু পাসওয়ার্ডটিই সিল করা থাকে; এন্ট্রির টাইটেল, ইউজারনেম, ওয়েবসাইট, নোট এবং সিকিউরিটি প্রশ্ন ও উত্তর Standard সুরক্ষা ব্যবহার করে।
Per-user X25519 identity keypair; public key stored in the clear, private seed never stored unwrapped. KEK = Argon2id(vault password, 16-byte random salt) — m=64 MiB, t=3, p=1, 32-byte output; the private seed is wrapped with AES-256-GCM (12-byte nonce, 128-bit tag). These KDF parameters are under active hardening review; the wire scheme is versioned (enc_scheme=e2e_v2) and each wrap is self-describing, so parameters can be raised without re-enrolling users. Adds are sealed public-key style: fresh ephemeral X25519 keypair → ECDH against the identity public key → HKDF-SHA256 (salt = ephemeral public key, info soult-pwk-e2e-v2) → AES-256-GCM. The entry stores ciphertext, IV and the ephemeral public key only. Two independent wraps of the same seed exist — one under the vault password, one under a 12-word phrase drawn from a 256-word list (≈96 bits) that is generated on-device and never transmitted. The MPIN is deliberately excluded from key derivation, since rotating or clearing it would otherwise permanently brick recovery; it is enforced as a separate UI gate at recovery time. enc_key_id = first 8 bytes of SHA-256(public key), so entries sealed to a superseded key after a vault reset are flagged unrecoverable rather than failing silently. The backend bypasses KMS entirely for e2e_ schemes: no server-side key for these fields exists to be compelled, audited or misused. পরিধি: শুধুমাত্র পাসওয়ার্ড ফিল্ডটি সিল করা হয়; এই সুরক্ষা আপনার ইনস্টল করা অ্যাপের অখণ্ডতার উপর নির্ভর করে।
ট্রানজিটে এনক্রিপশন
গুপ্তচর-প্রুফ Wi-Fi।
ডেটা একটি সুরক্ষিত TLS টানেলের মাধ্যমে যায়। পাবলিক এয়ারপোর্ট বা ক্যাফে Wi-Fi-এ কেউ যদি আড়ি পাতে, তাহলে তারা শুধু এনক্রিপ্টেড এলোমেলো জিনিস দেখবে — আপনি কী আপলোড করছেন বা কী পড়ছেন, তার কিছুই নয়।
API Gateway HTTPS-এর মাধ্যমে TLS 1.2+ এনফোর্স করা হয়। ফাইলগুলি S3 প্রিসাইনড URL-এর মাধ্যমে আপলোড ও রিড করা হয়, যার মেয়াদ ১৫ মিনিট পরে শেষ হয়।
“কোনো রুটিন অ্যাক্সেস নয়” নীতি
Soult-এর কর্মীরা কি আমার গোপন জিনিস দেখতে পারে?
রুটিন কাজে নয়। স্বাভাবিক কাজের অংশ হিসেবে Soult কর্মীরা আপনার ভল্টের কন্টেন্ট দেখেন না; প্রোডাকশন সিস্টেমে অ্যাক্সেস IAM দ্বারা সীমিত এবং লগ করা হয়। যখন একটি মৃত্যুর দাবি পর্যালোচনা করা হয়, তখন অল্প কয়েকজন অনুমোদিত কর্মী সেই অ্যাকাউন্টের ডকুমেন্টগুলি খুলতে পারেন, এবং প্রতিটি এমন অ্যাক্সেস লগ করা হয়। আপনার সবচেয়ে সংবেদনশীল ফিল্ডগুলি KMS-এনক্রিপ্টেড সাইফারটেক্সট হিসেবেও সংরক্ষিত থাকে।
অ্যাপ্লিকেশন রোলগুলির জন্য লিস্ট-প্রিভিলেজ IAM। প্রোডাকশন অ্যাক্সেস অল্প কয়েকজন নির্দিষ্ট অ্যাডমিনিস্ট্রেটরের মধ্যে সীমিত এবং লগ করা হয়। মৃত্যুর দাবির পর্যালোচকরা একটি ছোট allowlist-এ আছেন, এবং তাঁরা যে প্রতিটি ডকুমেন্ট খোলেন তা লগ করা হয়। ডেটাবেস স্তরে শুধুমাত্র KMS-এনক্রিপ্টেড ফিল্ডগুলি সাইফারটেক্সট; অন্যান্য কন্টেন্ট IAM অ্যাক্সেস কন্ট্রোল ও লগিং দ্বারা সুরক্ষিত।
দুটি Executor ভূমিকা
কে আমার ভল্ট দেখতে পারে?
Regular Executor (সাধারণত পরিবারের একজন সদস্য): তাঁর নিজস্ব ড্যাশবোর্ড আছে, যেখানে তিনি যাঁদের জন্য মনোনীত, তাঁদের তালিকা থাকে। মৃত্যুর দাবি জানাতে পারেন। Soult সেটি যাচাই ও অনুমোদন করার পরেই কেবল তিনি সাইন ইন করতে পারেন — ফোন ও ইমেল OTP দিয়ে — এবং আপনার ভল্ট দেখতে পারেন।
Emergency Executor (আপনার বেছে নেওয়া যেকোনো বিশ্বস্ত ব্যক্তি — জীবনসঙ্গী, সন্তান, ভাইবোন বা বন্ধু): কোনো মৃত্যুর দাবির প্রয়োজন নেই। ফোন ও ইমেল OTP-র পর যেকোনো সময় সাইন ইন করতে পারেন। তিনি সাইন ইন করা মাত্রই আপনি একটি ইমেল পান।
দুটি ভূমিকাই আপনার ভল্ট read-only মোডে দেখেন। Emergency ভূমিকাটি মেডিকেল ইমার্জেন্সি এবং সময়-সংবেদনশীল পরিস্থিতির জন্য; Regular ভূমিকাটি মৃত্যুর পরে হস্তান্তরের জন্য। আপনি কতজন Executor মনোনীত করতে পারবেন তা আপনার প্ল্যানের উপর নির্ভর করে।
অ্যাপ্লিকেশন লজিকে রোল-বেসড অ্যাক্সেস। প্রতিটি Executor-এর একটি is_emergency ফ্ল্যাগ থাকে (যেকোনো সম্পর্ক; মোট Executor সংখ্যা প্ল্যান অনুযায়ী সীমিত)। নন-ইমার্জেন্সি Executor-রা শুধুমাত্র মৃত্যুর দাবি অনুমোদিত হওয়ার পরে সাইন ইন করতে পারেন; ইমার্জেন্সি Executor-রা যেকোনো সময় সাইন ইন করতে পারেন। Executor সাইন-ইনে OTP যাচাইকরণ প্রয়োজন এবং মালিককে ইমেল পাঠানো হয়। Executor সেশন read-only।
হস্তান্তর প্রোটোকল
আমার পরিবার কীভাবে অ্যাক্সেস পাবে?
মনোনীত Regular Executor তাঁর ড্যাশবোর্ড থেকে একটি মৃত্যুর দাবি জানান এবং একটি ডেথ সার্টিফিকেট আপলোড করেন; আপনাকে এবং আপনার অন্যান্য Executor-দের ইমেল করা হয়। অনুমোদনের আগে Soult-এর একজন অনুমোদিত অ্যাডমিনিস্ট্রেটর দাবি ও সার্টিফিকেটটি পর্যালোচনা করেন — যাচাই না হওয়া অনুরোধে কিছুই প্রকাশ করা হয় না। অনুমোদিত হলে, আপনার অ্যাকাউন্ট read-only হয়ে যায়, এবং Executor ফোন ও ইমেল OTP দিয়ে সাইন ইন করে ভল্টটি দেখতে ও ডাউনলোড করতে পারেন। প্রতিবার কোনো Executor সাইন ইন করলে আপনার নিবন্ধিত ঠিকানায় একটি ইমেল যায়। আপনি যদি আপনার Executor-এর জন্য আপনার ভল্ট পাসওয়ার্ড বা Recovery Kit রেখে না যান, তাহলে Advanced Password Keeper-এর পাসওয়ার্ডগুলি লক করাই থাকে।
গেট: (১) একজন নিবন্ধিত, যাচাই করা Executor তাঁর ড্যাশবোর্ড থেকে সার্টিফিকেট আপলোড সহ মৃত্যুর দাবি জানান; (২) Amazon SES মালিক এবং অন্যান্য Executor-দের ইমেল করে; (৩) allowlist-ভুক্ত একজন Soult অ্যাডমিনিস্ট্রেটর দাবিটি পর্যালোচনা ও অনুমোদন করেন; (৪) অনুমোদনের ফলে ফোন + ইমেল OTP সহ Executor সাইন-ইন চালু হয়, এবং API স্তরে অ্যাকাউন্টটি read-only হয়ে যায়; (৫) প্রতিটি Executor সাইন-ইনে মালিককে ইমেল করা হয়। দাবির আপলোড ও অনুমোদন একটি সিকিউরিটি ইভেন্ট লগে রেকর্ড করা হয়।
কোনো শেয়ারিং নেই, ডিজাইনগতভাবে
আমি কি আমার CA বা জীবনসঙ্গীর সাথে একটি ডকুমেন্ট শেয়ার করতে পারি?
আজ নয়। এখানে প্রতি-আইটেম শেয়ারিং, একজন অ্যাকাউন্ট্যান্টের জন্য প্রতি-ফোল্ডার অ্যাক্সেস, বা সময়-সীমিত শেয়ার লিঙ্ক নেই। অন্য কোনো ব্যক্তি আপনার ভল্টের ভেতরে দেখতে পাওয়ার একমাত্র উপায় হলো উপরে বর্ণিত Executor ফ্লো-এর মাধ্যমে — এবং তখনও, তারা সবকিছু read-only মোডে দেখতে পায়। এখনো প্রতি-আইটেম বা প্রতি-ফোল্ডার গ্র্যানুলারিটি নেই।
কোনো কোলাবোরেশন মেকানিজম প্রয়োগ করা হয়নি। একমাত্র অ্যাক্সেস পাথ: (১) অথেন্টিকেটেড মালিক সেশন, (২) Executor সেশন ভেরিফিকেশনের পর। কোনো শেয়ার-লিঙ্ক জেনারেশন, কোনো স্কোপড টোকেন, কোনো পার-রিসোর্স ACL নেই। শুধুমাত্র রোডম্যাপ বিবেচনায় আছে — তৈরি করা হয়নি।
বাস্তব পরিস্থিতি
ঝুঁকিগুলো কী কী?
আমরা হ্যাকার, অ্যাকাউন্ট দখল এবং অভ্যন্তরীণ অ্যাক্সেস থেকে সুরক্ষা দেওয়ার জন্য কাজ করি। কিন্তু আপনাকে শারীরিকভাবে জোর করে PIN শেয়ার করানো থেকে আমরা আটকাতে পারি না। Soult হল আপনার সম্পদ সুসংগঠিত রাখা এবং পরিবারের ধারাবাহিকতার জন্য — চাপের মুখে জোরপূর্বক তথ্য প্রকাশ থেকে সুরক্ষার জন্য নয়।
থ্রেট মডেল শারীরিক জবরদস্তি বাদ দেয়। যা প্রশমিত করে: এক্সফিলট্রেশন, অ্যাকাউন্ট টেকওভার, ইনসাইডার অ্যাক্সেস। আওতার বাইরে: জবরদস্তির অধীনে PIN এক্সট্রাকশন, আনলকের পর ডিভাইস কম্প্রোমাইজ।
ভারতীয় মাটি
আমার ডেটা ঠিক কোথায় থাকে?
বর্তমানে, সমস্ত ভল্ট ডেটা AWS মুম্বাইতে আমাদের ভারত সাইলোতে থাকে। আমরা UAE-তে লঞ্চ করার প্রস্তুতি নিচ্ছি। সেখানকার ব্যবহারকারীদের ভল্ট AWS মুম্বাইতে (ভারত) সংরক্ষিত হবে, এবং সাইন-আপের সময় আমরা এ বিষয়ে তাঁদের স্পষ্ট সম্মতি চাইব। US ও দক্ষিণ-পূর্ব এশিয়ার জন্য ভবিষ্যতের সাইলো, এবং একটি ডেডিকেটেড GCC সাইলো, আমাদের রোডম্যাপে আছে।
অ্যাক্টিভ সাইলো: ap-south-1 (মুম্বাই), ডেটা একাধিক Availability Zone জুড়ে সংরক্ষিত। ক্রস-রিজিয়ন DR আমাদের রোডম্যাপে রয়েছে। DPDP Act, 2023-এর নীতিগুলি মাথায় রেখে তৈরি। অন্য কোনো সাইলো চালু নেই, এবং কোনো ব্যবহারকারীকে GCC অঞ্চল থেকে পরিষেবা দেওয়া হয় না।
দুর্যোগ পুনরুদ্ধার স্তর
ব্যর্থতার প্রতিটি স্তরে কী ঘটে?
টিয়ার ১ — একটি সার্ভার ব্যর্থ হলে: ইউজারদের কাছে অদৃশ্য; AWS-এর ম্যানেজড পরিষেবা স্বয়ংক্রিয়ভাবে এটি প্রতিস্থাপন করে।
টিয়ার ২ — মুম্বাইয়ের একটি ডেটা সেন্টার ব্যর্থ হলে: পরিষেবা চালু থাকে, কারণ আপনার ডেটা আগে থেকেই মুম্বাইয়ের একাধিক ডেটা সেন্টারে সংরক্ষিত।
টিয়ার ৩ — পুরো মুম্বাই রিজিয়ন ডাউন হলে: AWS এটি পুনরুদ্ধার না করা পর্যন্ত পরিষেবা বন্ধ থাকে। দ্বিতীয় একটি রিজিয়নে স্ট্যান্ডবাই আমাদের রোডম্যাপে রয়েছে, আজ লাইভ নয়।
টিয়ার ৪ — মুম্বাই রিজিয়ন স্থায়ীভাবে হারিয়ে গেলে: আজ আমরা তা থেকে সম্পূর্ণভাবে পুনরুদ্ধার করতে পারি না। ক্রস-রিজিয়ন ব্যাকআপ রেপ্লিকেশন আমাদের রোডম্যাপে রয়েছে। ততদিন পর্যন্ত, নিজের একটি ব্যাকআপ রাখাই সবচেয়ে শক্তিশালী সুরক্ষা।
টিয়ার ১: ম্যানেজড-সার্ভিস সেলফ-হিলিং (Lambda, DynamoDB, S3)। টিয়ার ২: ap-south-1-এর মধ্যে মাল্টি-AZ স্টোরেজ। টিয়ার ৩–৪: আজ কোনো ক্রস-রিজিয়ন ফেইলওভার নেই; দ্বিতীয় একটি রিজিয়নে ক্রস-রিজিয়ন ব্যাকআপ রেপ্লিকেশন আমাদের রোডম্যাপে রয়েছে।
অডিট ট্রেইল
পরিবর্তনের রেকর্ড।
আপনার ভল্টে প্রতিটি Create, Update বা Delete-এর একটি রেকর্ড — কে পরিবর্তনটি করেছেন এবং কখন, সহ।
DynamoDB-তে অডিট লগ টেবিল। রাইট অপারেশন (CUD) ট্র্যাক করে। ব্যবহারকারীর গোপনীয়তা এবং পারফরম্যান্সের ভারসাম্যের জন্য রিড ইভেন্ট বাদ দেওয়া হয়েছে। অ্যাকাউন্টের সাথে মুছে ফেলা হয়।
ডেটা ব্যবহারের নিয়মাবলী
বিক্রি নয়, ট্রেনিং নয়, কোনো চমক নয়।
আপনার ভল্টের বিষয়বস্তু কখনোই AI মডেল প্রশিক্ষণের জন্য বা মার্কেটিংয়ের জন্য ব্যবহার করা হয় না। যখন অ্যাপে AI ফিচার ব্যবহার করা হয়, সেই সেশনের ডেটা শুধুমাত্র ইন-কনটেক্সট প্রক্রিয়াকরণ করা হয় — মডেলের উন্নতির জন্য কখনোই ধরে রাখা হয় না। আমাদের আয় শুধুমাত্র সাবস্ক্রিপশন-ভিত্তিক। যদি আমরা কখনো উপার্জনের নতুন কোনো উপায় বিবেচনা করি — যেকোনো পরিবর্তনই হোক না কেন — আমরা আগে আপনাকে জিজ্ঞাসা করব। জানাব না। ঘোষণা করব না। জিজ্ঞাসা করব। এবং আমরা তখনই জিজ্ঞাসা করব যদি আমরা সত্যিই বিশ্বাস করি যে এটি আপনার উপকারে আসবে।
ডেটা আইসোলেশন। কোনো ভল্ট ডেটা AI/ML ট্রেনিং পাইপলাইনে যায় না। AI ফিচারগুলো প্রতি সেশনে শুধুমাত্র ইন-কনটেক্সট ডেটা প্রসেস করে — মডেল উন্নত করার জন্য কোনো ডেটা রাখা হয় না। আয়ের মডেল ভল্টের ডেটার উপর নির্ভরশীল নয়। ভবিষ্যতে মনিটাইজেশনের যেকোনো পরিবর্তন ব্যবহারকারীর স্পষ্ট অপ্ট-ইন ছাড়া হবে না — ঘোষণা করে এগিয়ে যাওয়া হবে না।
গোপনীয়তা বনাম হ্যান্ডওভার
সেতুর মতো সমাধান।
চ্যাট অ্যাপগুলো চরম গোপনীয়তার উপর জোর দেয় — যদি আপনি একটি কী হারান, তারা আপনাকে সাহায্য করতে পারে না। একটি লাইফ ভল্টের জন্য এটি একটি ব্যর্থতা। তাই আমরা Soult-কে ভিন্নভাবে ডিজাইন করেছি: আপনার ভল্ট ডিজাইনগতভাবে পুনরুদ্ধারযোগ্য, তাই ফোন হারালে বা PIN ভুলে গেলে আপনার পরিবার কখনও আটকে যায় না, এবং যাচাইকৃত Executor-রা আপনার রেখে যাওয়া জিনিস পেতে পারেন। Soult কর্মীদের রুটিন অ্যাক্সেস নেই, এবং হস্তান্তর কেবল একটি যাচাইকৃত পথেই হয়। যে অল্প কয়েকটি পাসওয়ার্ড কেবল আপনারই খোলা উচিত, সেগুলির জন্য Advanced Password Keeper আপনাকে একক নিয়ন্ত্রণ দেয়। Soult আপনার উত্তরাধিকারের একটি সেতু, কোনো ডিজিটাল ডেড এন্ড নয়।
স্ট্যান্ডার্ড ভল্ট ডেটা সার্ভার-সাইডে এনক্রিপ্ট করা হয় (S3 ও DynamoDB এনক্রিপশন অ্যাট রেস্ট, সংবেদনশীল ফিল্ডের জন্য অতিরিক্ত AWS KMS), তাই এটি আপনাকে ফিরিয়ে দেওয়া যায় বা একজন যাচাইকৃত Executor-কে read-only হিসেবে দেখানো যায়। কর্মীদের কোনো রুটিন অ্যাক্সেস নেই; হস্তান্তরের জন্য উপরে বর্ণিত যাচাইকৃত মৃত্যু-দাবি ফ্লো প্রয়োজন। Advanced Password Keeper-এর এন্ট্রি (e2e_v2) হলো একমাত্র ডেটা যা Soult ডিক্রিপ্ট করতে পারে না।
রোডম্যাপ
এরপর কী আসছে?
নিকট-ভবিষ্যৎ: এক-ক্লিক ভল্ট এক্সপোর্ট (আজ ব্যবহারকারীরা ম্যানুয়ালি ব্যাক আপ করেন); US সাইলো (N. Virginia, DR Oregon); SEA সাইলো (Singapore, DR Jakarta); ক্রস-সাইলো ব্যাকআপ রেপ্লিকেশন যাতে একটি পুরো অঞ্চল হারিয়ে গেলেও কিছু না কিছু সবসময় টিকে থাকে।
মধ্য-ভবিষ্যৎ: একটি ডেডিকেটেড GCC সাইলো; SOC 2 Type II।
সর্বদা-সক্রিয়: চলমান অডিট, নিরাপত্তা জোরদারকরণ, পরিকাঠামো পর্যালোচনা।
ফেজ 1 (পরবর্তী): এক-ক্লিকে এনক্রিপ্টেড এক্সপোর্ট, US সাইলো চালু করা। ফেজ 2: SEA সাইলো, ক্রস-সাইলো কোল্ড ব্যাকআপ রেপ্লিকেশন, WAF, মোবাইল ক্লায়েন্টদের জন্য SSL পিনিং। ফেজ 3: ডেডিকেটেড GCC সাইলো, SOC 2 Type II, হার্ডেনড মাল্টি-রিজিওন KMS।
সৎ দাবি
প্রতিটি মার্কেটিং দাবি যাচাই করা হয়েছে। আজ কী সত্যি, কী পরিকল্পনা করা হয়েছে, কী তৈরি হয়নি, এবং আমরা কী ব্যবহার করি না।
| দাবি | স্ট্যাটাস | ব্যবহারিক সত্য |
|---|---|---|
| কর্মীদের কোনো রুটিন অ্যাক্সেস নেই | সত্যি | ভল্টের কন্টেন্টে কর্মীদের রুটিন অ্যাক্সেস নেই; প্রোডাকশন অ্যাক্সেস সীমিত এবং লগ করা হয়। মৃত্যুর দাবি পর্যালোচনার সময় allowlist-ভুক্ত অল্প কয়েকজন পর্যালোচক একটি অ্যাকাউন্টের ডকুমেন্ট খুলতে পারেন, এবং প্রতিটি অ্যাক্সেস লগ করা হয়। Advanced Password Keeper পাসওয়ার্ড ছাড়া, এটি একটি অ্যাক্সেস কন্ট্রোল, প্রযুক্তিগত অসম্ভাব্যতা নয়। |
| ভারতে ডেটা রেসিডেন্সি | সত্যি | সমস্ত ভল্ট ডেটা ভারতে, AWS মুম্বাইতে সংরক্ষিত। কিছু অপারেশনাল ডেটা (সাইন-ইন কোড, পেমেন্ট, অ্যানালিটিক্স, ক্র্যাশ রিপোর্ট) এমন প্রোভাইডাররা পরিচালনা করে, যারা তা ভারতের বাইরে প্রসেস করতে পারে। |
| ISO 27001 ও ISO 9001 সার্টিফিকেশন | প্রক্রিয়াধীন | নিরাপত্তা প্রোগ্রাম ISO 27001-এর সাথে সামঞ্জস্যপূর্ণ। গুণমান ব্যবস্থাপনা ISO 9001-এর সাথে সামঞ্জস্যপূর্ণ। উভয়ের জন্যই স্বীকৃত সার্টিফিকেশন প্রক্রিয়াধীন। |
| AES-256 এনক্রিপশন | সত্যি | সমস্ত ভল্ট ডেটা অ্যাট রেস্ট AES-256 দিয়ে এনক্রিপ্ট করা, এবং সংবেদনশীল ফিল্ডগুলিতে একটি অতিরিক্ত AWS KMS স্তর রয়েছে। |
| Password Keeper — Standard | সত্যি | ডিফল্ট। পাসওয়ার্ডটি আমাদের সার্ভারে AWS KMS দিয়ে এনক্রিপ্ট করা হয়, তাই এটি পুনরুদ্ধার করে আপনার Executor-দের কাছে হস্তান্তর করা যায়। |
| Password Keeper — Advanced | লাইভ | জুলাই ২০২৬ থেকে লাইভ (ঐচ্ছিক)। কোনো Password Keeper এন্ট্রির জন্য Advanced চালু করলে তার পাসওয়ার্ড আপনার ফোনেই এমন একটি কী দিয়ে এনক্রিপ্ট করা হয়, যা শুধু আপনার জানা একটি ভল্ট পাসওয়ার্ড থেকে তৈরি — তাই Soult সেটি ডিক্রিপ্ট করতে পারে না। এন্ট্রির অন্যান্য বিবরণ (টাইটেল, ইউজারনেম, ওয়েবসাইট, নোট, সিকিউরিটি প্রশ্ন ও উত্তর) Standard সুরক্ষা ব্যবহার করে। আপনার ভল্ট পাসওয়ার্ড এবং ১২-শব্দের রিকভারি ফ্রেজ — দুটোই হারালে সেই পাসওয়ার্ড আর পুনরুদ্ধার করা যায় না। |
| এক-ক্লিকে ভল্ট এক্সপোর্ট | পরিকল্পিত | আজ তৈরি হয়নি। ব্যবহারকারীরা ম্যানুয়ালি ব্যাকআপ নেন। ওয়ান-ক্লিক এক্সপোর্ট আমাদের রোডম্যাপে আছে। |
| আইটেম অনুযায়ী শেয়ারিং | তৈরি হয়নি | আজকে কোনো শেয়ারিং বা কোলাবোরেশন নেই। Executor-এর মাধ্যমেই একমাত্র অ্যাক্সেস করা যায়। |
| ক্রস-সিলো ব্যাকআপ | রোডম্যাপে আছে | দ্বিতীয় একটি রিজিয়নে ব্যাকআপ রেপ্লিকেশন আমাদের রোডম্যাপে রয়েছে, এবং US/SEA সিলো চালু হওয়ার সাথে সাথে আসবে। |
| ক্রস-রিজিয়ন দুর্যোগ পুনরুদ্ধার | রোডম্যাপে আছে | আজ আপনার ডেটা একটি AWS রিজিয়নে (মুম্বাই) থাকে, সেখানে একাধিক ডেটা সেন্টার জুড়ে সংরক্ষিত। দ্বিতীয় একটি রিজিয়নে স্ট্যান্ডবাই আমাদের রোডম্যাপে রয়েছে; ততদিন পর্যন্ত, পুরো একটি রিজিয়ন হারানোর বিরুদ্ধে আপনার নিজের ব্যাকআপই সবচেয়ে শক্তিশালী সুরক্ষা। |
| লাইভ সিস্টেম থেকে ডিলিশন | তাৎক্ষণিক | ১০ সেকেন্ডের কনফার্মেশন এবং আপনার MPIN, তারপর আপনার লগইন, রেকর্ড ও ফাইল লাইভ সিস্টেম থেকে সরিয়ে ফেলা হয়। কোনো প্রতি-ব্যবহারকারী কী নেই, তাই ব্যাকআপ, ফাইলের আগের ভার্সন এবং লগ crypto-shred করা হয় না বা তাৎক্ষণিকভাবে মুছে ফেলা হয় না। |
| ইউজার ডেটা দিয়ে AI ট্রেনিং | কখনোই নয় | ভল্টের কন্টেন্ট কখনোই AI মডেল ট্রেনিংয়ের জন্য ব্যবহার করা হয় না, এমনকি যখন সেশনের মধ্যে AI ফিচার ব্যবহার করা হয় তখনও। |
| ব্লকচেইন | ব্যবহার করা হয় না | একটি প্রাইভেট ভল্টের জন্য এটি ভুল টুল। এর বদলে আমরা অডিট লগ ব্যবহার করি। |
| জিরো-নলেজ এনক্রিপশন | আংশিক লাইভ | আজ আংশিক লাইভ। Advanced Password Keeper-এর এন্ট্রিগুলি সত্যিই ক্লায়েন্ট-সাইডে এনক্রিপ্ট করা — এমন একটি ভল্ট পাসওয়ার্ড থেকে তৈরি কী দিয়ে সিল করা, যা কখনও আমাদের কাছে পৌঁছায় না, তাই আমরা সেগুলি ডিক্রিপ্ট করতে পারি না (দেখুন ক্লায়েন্ট-সাইড এনক্রিপশন)। ভল্টের বাকি অংশ আমাদের সার্ভারে এনক্রিপ্ট করা, সংবেদনশীল ফিল্ডগুলি AWS KMS-এর অধীনে। এটি শক্তিশালী, কিন্তু জিরো-নলেজ নয় — ইচ্ছাকৃতভাবেই, যাতে আপনার পরিবার কখনও আটকে না যায়। আরও বিস্তৃত ঐচ্ছিক জিরো-নলেজ বিকল্প আমাদের রোডম্যাপে রয়েছে। |
সাধারণ প্রশ্ন
আমি আমার ডেটা কিভাবে ডিলিট করব?
১০ সেকেন্ডের নিশ্চিতকরণ বিরতি এবং আপনার MPIN-এর পরে, আপনার সাইন-ইন ও ভল্ট রেকর্ড আমাদের ডেটাবেস থেকে মুছে ফেলা হয় এবং আপনার ফাইলগুলি অ্যাক্টিভ স্টোরেজ থেকে সঙ্গে সঙ্গে সরিয়ে ফেলা হয়। আপনি বা আমাদের সাপোর্ট টিম কেউই তা আর ফেরাতে পারে না। ব্যাকআপ, ফাইলের আগের ভার্সন এবং সিস্টেম লগে থাকা কপিগুলি তাৎক্ষণিকভাবে মুছে ফেলা হয় না, এবং আপনার ব্যক্তিগত বিবরণ সরিয়ে একটি পেমেন্ট রেকর্ড রাখা হয়। যা কিছু রাখতে চান, আগে তা ডাউনলোড করে নিন। ওয়ান-ক্লিক এক্সপোর্ট আমাদের রোডম্যাপে আছে।
যদি Soult বন্ধ হয়ে যায়?
যদি কখনও Soult বন্ধ করতে হয়, আমরা আপনাকে আগে থেকে জানাব এবং আপনার ভল্টের একটি কপি পেতে সাহায্য করব। ওয়ান-ক্লিক এক্সপোর্ট আমাদের রোডম্যাপে আছে। আমরা আপনার ডেটা বিক্রি করব না, অথবা আপনার সম্মতি ছাড়া আপনার ভল্ট কোনো ক্রেতার কাছে হস্তান্তর করব না।
সাবস্ক্রিপশন কিভাবে বিল করা হয়?
Soult ওয়েবসাইটে Razorpay-এর মাধ্যমে ম্যানেজ করা হয়। কোনো ইন-অ্যাপ পারচেজ নেই। এটি আপনার ভল্ট ডিভাইস থেকে বিলিংকে আলাদা রাখে।
ডেটা মোছার প্রোটোকল বিস্তারিত?
নিশ্চিত করার পর, ব্যবহারকারীর Cognito সাইন-ইন মুছে ফেলা হয়, DynamoDB-র ভল্ট টেবিলগুলি থেকে তাঁর রো (row) মুছে ফেলা হয় এবং তাঁর S3 ফাইলগুলি অ্যাক্টিভ স্টোরেজ থেকে সরিয়ে ফেলা হয়, সাথে একটি অ্যাসিঙ্ক্রোনাস দ্বিতীয় ক্লিন-আপ পাস চলে। পেমেন্ট রেকর্ড ব্যক্তিগত বিবরণ মুছে রাখা হয়। কোনো প্রতি-ব্যবহারকারী কী নেই, তাই কোনো crypto-shredding নেই; ব্যাকআপ, ফাইলের আগের ভার্সন এবং লগ তাৎক্ষণিকভাবে মুছে ফেলা হয় না।
Soult কেন ব্লকচেইন ব্যবহার করে না?
ব্লকচেইন তৈরি হয়েছে পাবলিক ভেরিফিকেশনের জন্য, যেখানে শেয়ার্ড লেজারে বিভিন্ন পক্ষ একে অপরকে বিশ্বাস করে না — যেমন ক্রিপ্টোকারেন্সি, প্রতিদ্বন্দ্বীদের মধ্যে সাপ্লাই চেইন, পাবলিক ল্যান্ড রেকর্ড। এর শক্তি হল টেম্পারিং বিশ্বব্যাপী দৃশ্যমান করা।
Soult ভল্টগুলি পাবলিকের বিপরীত — এগুলি ডিজাইনগতভাবে প্রাইভেট। ডেটার উপর একমাত্র ইউজারেরই অধিকার থাকে। টেম্পারিংয়ের উদ্দেশ্য কম: এটি ইউজারের নিজস্ব ডেটা, যা ইউজারের নিজের পরিবারের জন্য রাখা হয়।
পরিবর্তন ট্র্যাকিংয়ের জন্য, আমরা অডিট লগ ব্যবহার করি (বিভাগ ১৪ দেখুন) — প্রতিটি Create, Update, Delete টাইমস্ট্যাম্প এবং অ্যাক্টর সহ রেকর্ড করা হয়। ব্লকচেইন খরচ, জটিলতা বাড়াতো এবং পাবলিক লেজারে প্যাটার্ন প্রকাশ করে প্রাইভেসি কমাতো — কোনো ইউজারের সমস্যা সমাধান না করেই।
যদি এবং যখন ভেরিফাইড-পাবলিক অ্যাটেস্টেশন একটি বাস্তব ইউজারের প্রয়োজন হয়ে দাঁড়ায়, তখন এটি আবার বিবেচনা করা হবে।
Soult কী করতে পারে এবং কী পারে না সে সম্পর্কে আরও জানতে — Legal Validity পেজটি পড়ুন। Executor প্রোটোকল সম্পর্কে বিস্তারিত জানতে, Executor ও Handover Flow দেখুন।
বিনামূল্যে শুরু করুন →