আপলোডের জন্য ক্লায়েন্ট-সাইড বনাম সার্ভার-সাইড এনক্রিপশন

আপলোড করা ডকুমেন্টের জন্য এনক্রিপশন নির্বাচনের গুরুত্ব

আপনার অ্যাপ যদি মানুষকে ফাইল আপলোড করার সুযোগ দেয়, আপনি শুধু “ডকুমেন্ট” জমা রাখছেন না। প্রায়ই আপনি ব্যবহারকারীর জন্য একটি দ্বিতীয় পরিচয় সংরক্ষণ করছেন: স্বাক্ষরিত চুক্তি, পাসপোর্ট বা ড্রাইভিং লাইসেন্সের ছবি, মেডিকেল ফর্ম এবং ল্যাব রিপোর্ট। ফাইলগুলো ছোট হতে পারে, কিন্তু ঝুঁকি বেশ বড়।

একটি ফাঁস হওয়া চুক্তি আইনি ও আর্থিক সমস্যার সৃষ্টি করতে পারে: মূল্য প্রকাশ পেতে পারে, স্বাক্ষর কপি হতে পারে, এবং বিরোধ দ্রুত কুখ্যাত হতে পারে। চুরি হওয়া আইডি স্ক্যান পরিচয় চুরির এবং অ্যাকাউন্ট দখলের দিকে নিয়ে যেতে পারে। মেডিকেল ডকুমেন্ট ব্যক্তিগত স্বাস্থ্য বিবরণ উন্মোচিত করতে পারে যা মানুষ কখনোই বিস্তৃতভাবে ভাগ করতে চাননি। একটি মাত্র ভুল দীর্ঘদিনের জন্য বিশ্বাস নষ্ট করতে পারে।

দলগুলো প্রায়ই “এনক্রিপ্টেড স্টোরেজ” বললেও তার ভিন্ন অর্থ থাকে। কখনো তারা কেবল আপলোড সংযোগকে (HTTPS) এনক্রিপ্ট করা বোঝায়। কখনো তারা ডিস্কে ফাইল এনক্রিপ্ট করা (এট রেস্ট) বোঝায়। কখনো তারা বোঝায় যে ফাইলটা ব্যবহারকারীর ডিভাইসে ছাড়া আগে এনক্রিপ্ট করা হয়, ফলে সার্ভার কখনো প্লেইনটেক্সট দেখে না (ক্লায়েন্ট-সাইড এনক্রিপশন)। এগুলো সমান নয়; এগুলো বিভিন্ন ব্যর্থতা থেকে রক্ষা করে।

সিকিউরিটি পছন্দ প্রতিদিনের ব্যবহারপূর্নতা ও সাপোর্টকেও প্রভাবিত করে। বেশি প্রাইভেসি মানে হতে পারে বেশি ঝামেলা: ফাইল দেখার অতিরিক্ত ধাপ, শেয়ার করা কঠিন হওয়া, সীমিত সার্চ ও প্রিভিউ, এবং কীগুলি হারালে ব্যথাদায়ক রিকভারি। সহজ প্রবেশাধিকার ইনডেক্সিং, অ্যান্টিভাইরাস স্ক্যানিং, প্রিভিউ এবং পাসওয়ার্ড রিসেটকে সহজ করে, কিন্তু একই সাথে সার্ভার (এবং যেই কেউ সেটি কম্প্রোমাইজ করে) আরও বেশি দেখতে পারে।

একটি ছোট ক্লিনিক কল্পনা করুন যা বীমা আইডি এবং মেডিকেল PDF আপলোড করে। স্টাফদের দ্রুত সঠিক ফাইল খুঁজে পেতে হয়, কিন্তু ক্লিনিক চাইবে যে যদি কোন অ্যাডমিন অ্যাকাউন্ট হ্যাক হয় তাতে ক্ষতি কম হয়। “সঠিক” মডেল নির্ভর করে কোন ব্যর্থতা সবচেয়ে ক্ষতিকর হবে এবং ব্যবহারকারীরা কতটা অসুবিধা মেনে নিতে প্রস্তুত।

দ্রুত সংজ্ঞা: ক্লায়েন্ট-সাইড বনাম সার্ভার-সাইড এনক্রিপশন

প্রায়োগিক প্রশ্নটি সহজ: ফাইলটা কখন এনক্রিপ্ট করা হয়, এবং পরে কে সেটি ডিক্রিপ্ট করতে পারবে?

সার্ভার-সাইড এনক্রিপশন মানে ফাইলটি ব্যাকএন্ডে পৌঁছালে পাঠযোগ্য আকারে থাকে, এবং আপনার সার্ভার সেটি সেভ করার আগে এনক্রিপ্ট করে। এটিই এনক্রিপশন অ্যাট রেস্ট: যদি কেউ ড্রাইভ চুরি করে বা স্টোরেজ বালতি তে কাঁচা অ্যাক্সেস পায়, তারা এলোমেলো ডেটা পাবে। আপনার সার্ভার প্রয়োজনে ফাইলটি ডিক্রিপ্ট করতে পারে।

ক্লায়েন্ট-সাইড এনক্রিপশন মানে ফাইলটি আপলোডের আগে ব্যবহারকারীর ডিভাইসে (ব্রাউজার বা মোবাইল) এনক্রিপ্ট করা হয়। আপনার সার্ভার কেবল সাইফারটেক্সট রাখে। স্বাভাবিক অপারেশনে, সার্ভার কনটেন্ট পড়তে পারে না যদি না ডিক্রিপশনের কী-তেও অ্যাক্সেস থাকে।

মূল বিভাজন হল কী-অধিকার:

• সার্ভার-সাইড এনক্রিপশনে কীগুলো আপনার ব্যাকএন্ড দ্বারা পরিচালিত হয় (প্রায়ই কী ম্যানেজমেন্ট সার্ভিসের মাধ্যমে), এবং ব্যাকএন্ডই ফাইলগুলোকে অনুমোদিত ব্যবহারকারীদের জন্য ডিক্রিপ্ট করে।
• ক্লায়েন্ট-সাইড এনক্রিপশনে কীগুলো ব্যবহারকারী, তাদের ডিভাইস বা ক্লায়েন্ট-রক্ষিত সিক্রেট দ্বারা নিয়ন্ত্রিত হয়, এবং ব্যাকএন্ড মূলত স্টোরেজ ও অ্যাক্সেস নিয়ম প্রয়োগ করে।

উভয় মডেলে আপনাকে এখনও অথেনটিকেশন ও পারমিশন দরকার। এনক্রিপশন একেবারে অ্যাক্সেস কন্ট্রোলের বদলি রাখে না।

মানুষরা প্রায়ই “এন্ড-টু-এন্ড এনক্রিপশন” বলতে চান: ফাইলটি সেন্ডারের ডিভাইসে এনক্রিপ্ট করা হয়, সার্ভারে এনক্রিপ্টেড থাকে এবং অনুমোদিত রিসিপিয়েন্টের ডিভাইসে কেবল তখনই ডিক্রিপ্ট হয়। এটি গোপনীয়তা বাড়ায়, কিন্তু সার্ভার-সাইড প্রিভিউ, ফুল-টেক্সট সার্চ, ভাইরাস স্ক্যানিং এবং সহজ রিকভারি অনেক কঠিন করে তোলে যদি আপনি থ্রেট মডেল পরিবর্তন করতে রাজি না হন।

থ্রেট মডেল: আপনি আসলে কাকে আটকাতে চাইছেন

এনক্রিপশন তখনই সাহায্য করে যখন আপনি পরিষ্কার হন যে কোন ঝুঁকি কমাতে চান। “কেবল প্রত্যাশিত ব্যবহারকারীই ফাইল পড়তে পারবে” এই লক্ষ্যটি “স্টোরেজ ফাঁস হলে ক্ষতি কমানো” থেকে আলাদা পছন্দগুলোর দিকে নিয়ে যাবে।

চুক্তি, আইডি বা মেডিকেল ডকুমেন্ট সংরক্ষণকারী অ্যাপগুলির জন্য সাধারণ হুমকি:

• চুরি বা পুনঃব্যবহৃত পাসওয়ার্ড (অ্যাকাউন্ট দখল)
• ইনসাইডার অ্যাক্সেস যা হওয়া উচিত তার চেয়ে বিস্তৃত (সাপোর্ট, অ্যাডমিন, কন্ট্রাক্টর)
• কম্প্রোমাইজড ক্লাউড অ্যাকাউন্ট বা ভুল কনফিগার করা স্টোরেজ বালতি
• বাগ বা ডাটাবেস/ব্যাকআপ ফাঁস
• ব্যবহারকারীর ডিভাইসে ম্যালওয়্যার

এছাড়া প্রকাশ কোথায় ঘটতে পারে তা আলাদা করে দেখা সহায়ক:

• ট্রান্সিটে: ডিভাইস থেকে সার্ভারে ফাইল যাচ্ছে
• অ্যাট রেস্ট: অবজেক্ট স্টোরেজ, ডাটাবেস রো, ব্যাকআপ, লগ
• ভিউ/প্রসেসিং সময়: প্রিভিউ, OCR, সার্চ, কনভার্শন

মূল পার্থক্য: সার্ভার-সাইড এনক্রিপশনে আপনার সিস্টেম ডিক্রিপ্ট করতে পারে, তাই এটি প্রিভিউ, স্ক্যান এবং ইনডেক্স করতে পারে। ক্লায়েন্ট-সাইড এনক্রিপশনে সার্ভার কেবল সাইফারটেক্সট সংরক্ষণ করে এবং কনটেন্ট পড়তে পারে না যদি না ইউজার-হোল্ড কী প্রদান করে—এটি সার্ভার ব্রিচ ও ইনসাইডার অ্যাক্সেসের ব্লাস্ট রেডিয়াস সাধারনত কমায়।

তবে এনক্রিপশন সব কিছু থামায় না। যদি ডিভাইস ইনফেক্টেড হয়, ম্যালওয়্যার এনক্রিপশনের আগে বা পরে ফাইলটা চুরি করতে পারে। যদি কেউ ডকুমেন্ট দেখতে পারে, তারা সেগুলোর স্ক্রিনশট নিতে, পুনরায় শেয়ার করতে বা প্রিন্ট করতে পারবে।

প্রতিটি মডেল কী বিরুদ্ধে রক্ষা করে (এবং কী করে না)

একটি ব্যবহারযোগ্য তুলনা হল: কোন পয়েন্টে কাদা কারা প্লেইনটেক্সট দেখতে পারে? সেই উত্তর ব্রিচ ইমপ্যাক্ট, ইনসাইডার রিস্ক এবং ব্যাকআপের সুরক্ষা নির্ধারণ করে।

সার্ভার-সাইড এনক্রিপশন-এ সার্ভার ব্রিচে অনেক কিছু উন্মোচিত হতে পারে। ব্যাকএন্ড সাধারনত ডিক্রিপশন কী-তে অ্যাক্সেস রাখে (বা এটি অনুরোধ করতে পারে) কারণ প্রিভিউ জেনারেট করা, অ্যান্টিভাইরাস চালানো, সার্চ বা শেয়ারিং পরিচালনা করা দরকার। সবচেয়ে খারাপ ক্ষেত্রে, যদি আক্রমনকারী স্টোরড ডাটা ও কী উভয়ই পায়, তারা সবকিছু ডিক্রিপ্ট করতে পারে।

ক্লায়েন্ট-সাইড এনক্রিপশন-এ যে কেউ আপনার ইন্ফ্রাস্ট্রাকচার ব্রিচ করলে সাধারণত তারা এনক্রিপ্টেড ব্লব চুরি করে। ব্যবহারকারী-হোল্ড কী না থাকলে সেই ব্লবের প্রয়োগ সীমিত।

ইনসাইডার অ্যাক্সেসে পার্থক্য সবচেয়ে বেশি দেখা যায়। সার্ভার-সাইড এনক্রিপশনে একটি প্রিভিলেজড কর্মী, ক্লাউড অ্যাডমিন বা কম্প্রোমাইজড সাপোর্ট অ্যাকাউন্ট প্রায়শই ডকুমেন্ট অ্যাক্সেস করতে পারে। ক্লায়েন্ট-সাইড এনক্রিপশনে আপনার ইনফ্রাস্ট্রাকচার ফাইলগুলো রাখলেও সেগুলো পড়তে পারে না যদি না কী সরবরাহ করা হয়।

ক্লায়েন্ট-সাইড এনক্রিপশন ডিভাইস হ্যাক হওয়া সমাধান করে না। ID ও মেডিকেল PDF মত উচ্চ-ঝুঁকির আপলোডের জন্য ডিভাইস নিরাপত্তা ও অ্যাকাউন্ট সুরক্ষা স্টোরেজ এনক্রিপশনের মতোই গুরুত্বপূর্ণ।

আরও সচেতন থাকুন স্টোরেজের বাইরে কোথায় লিক হতে পারে:

• ব্যাকআপ ও স্ন্যাপশট যেখানে ডিক্রিপ্টকৃত ফাইল বা কী ধরা পড়ে
• লগ যেখানে ফাইলনেম, মেটাডেটা বা এক্সট্র্যাক্ট করা টেক্সট রেকর্ড হয়
• থাম্বনেইল, প্রিভিউ ও সার্চ ইনডেক্স
• ইমেইল, চ্যাট বা টিকেটিং টুলে এক্সপোর্ট
• আপলোড বা কনভার্শনের সময় তৈরি অস্থায়ী ফাইল

ইউএক্স ট্রেডঅফ যা ব্যবহারকরী তাৎক্ষণিকভাবে অনুভব করবে

সবচেয়ে বড় পার্থক্য গণিত নয়—এটা ব্যবহারকারীদের কি সহজে করতে পারে এবং কী কঠিন হয়ে পড়ে।

সার্ভার-সাইড এনক্রিপশন প্রায়ই অদৃশ্য থাকে। ব্যবহারকারী লগইন করে, আপলোড করে এবং তা সঙ্গে সঙ্গে প্রিভিউ করতে পারে। সাপোর্ট পাসওয়ার্ড রিসেট করে সাহায্য করতে পারে। সুপারভাইজার অনুপস্থিত হলে অ্যাক্সেস পুনরায় বরাদ্দ করতে পারে।

ক্লায়েন্ট-সাইড এনক্রিপশন অনবোর্ডিং ও দৈনিক কাজ পরিবর্তন করে। ব্যবহারকারীদের শক্তিশালী পাসফ্রেজ, ডিভাইসে লোকাল কী অথবা অতিরিক্ত আনলক ধাপ প্রয়োজন হতে পারে। ডিভাইস বদল, ব্রাউজার ক্লিয়ার করা বা অ্যাপ রিইনস্টল করলে অ্যাক্সেস ভেঙে যেতে পারে যদি আপনি কী ব্যাকআপ ও রিকভারি পরিকল্পনা না করেন।

অ্যাকাউন্ট রিকভারি দলগুলোকে চমকে দেয়। যদি কেবল ব্যবহারকারী কী ধারণ করে, তাহলে “পাসওয়ার্ড ভুলে গেছি” হয়ে দাঁড়ায় “অ্যাক্সেস হারিয়ে গেছে” তে। আপনি রিকভারি কী বা এসক্রো ফ্লো যোগ করতে পারেন, কিন্তু এর অর্থ কী তা খোলাখুলি ব্যাখ্যা করা দরকার।

শেয়ারিংও আরও জটিল হয়। সার্ভার-সাইড এনক্রিপশনে শেয়ারিং মূলত পারমিশন বিষয়; ক্লায়েন্ট-সাইডে সাধারণত কী শেয়ারিংয়ের বিষয় আসে—রিভোকেশন ও পুরনো কপিগুলোর ব্যবস্থাও বিবেচনা করতে হয়।

সার্চ ও সুবিধাজনক ফিচারগুলোকে কোথাও ডিক্রিপ্ট করা দরকার। ফুল-টেক্সট সার্চ, প্রিভিউ ও OCR সার্ভারকে ফাইল পড়তে দিলে সহজ। যদি আপনি এন্ড-টু-এন্ড স্টাইল প্রাইভেসি চান, আপনাকে ক্লায়েন্ট-সাইড OCR, লোকাল ইনডেক্সিং বা সীমিত সার্চ (যেমন ফাইলনেম ও ট্যাগ) মেনে নিতে হবে।

উদাহরণ: একটি ক্লিনিক ল্যাব PDF আপলোড করে এবং স্ক্যানের ভিতরের রোগীর নাম খুঁজতে OCR চায়। সার্ভার-সাইড এনক্রিপশন দ্রুত OCR ও সার্চ সমর্থন করে। ক্লায়েন্ট-সাইډ এনক্রিপশন ঐ কাজটি ডিভাইসে করে, যা ওয়েব ও মোবাইল জুড়ে ধীর ও সাপোর্ট করা কঠিন হতে পারে।

ডকুমেন্ট-নির্দিষ্ট প্রয়োজন: চুক্তি, আইডি ও মেডিকেল রেকর্ড

সবচেয়ে ভাল পছন্দ ফাইল টাইপের চেয়ে বেশি ওয়ার্কফ্লো নির্ভর: কে এটি পড়বে, কত দ্রুত, কতবার এবং কতদিন ধরে।

চুক্তি

চুক্তিতে রিভিউ, রেডলাইন, অনুমোদন এবং অডিট ট্রেইল থাকে। দলগুলো সাধারণত নির্ভরযোগ্য সার্চ, শেয়ারিং এবং রিটেনশন নিয়ম চায়।

আপনার অ্যাপ যদি প্রোডাক্টের ভিতরে সহযোগিতামূলক রিভিউ সাপোর্ট করে, সার্ভার-সাইড এনক্রিপশন প্রায়ই বাস্তবসিদ্ধ কারণ সিস্টেম প্রিভিউ রেন্ডার, সার্চ চালানো এবং রোল-ভিত্তিক অ্যাক্সেস প্রয়োগ করতে পারে ব্যবহারকারীদের কীগুলি ম্যানেজ করতে না বলতে।

ক্লায়েন্ট-সাইড এনক্রিপশন তখনও উপযুক্ত হতে পারে যদি অ্যাপটি প্রধানত একটি ভল্ট হিসেবে কাজ করে, যেমন ছোট নির্বাহী দলের জন্য চূড়ান্ত স্বাক্ষরিত PDF সংরক্ষণ। ট্রেডঅফ হলো বিল্ট-ইন সুবিধাগুলো কম পাওয়া।

আইডি (পাসপোর্ট, ড্রাইভার লাইসেন্স)

আইডি উচ্চ ঝুঁকির হলেও প্রায়ই আস্থাভিত্তিক ও অল্প সময়ের জন্য প্রয়োজন। অনেক দল কেবল যাচাই করার জন্যই রাখে, তারপর মুছে দেয়। ওয়ার্কফ্লো হলো দ্রুত দেখা ও কড়া হ্যান্ডলিং নিয়ম, সহযোগিতা নয়।

একটি সাধারণ পদ্ধতি হলো সার্ভার-সাইড এনক্রিপশন কড়া অ্যাক্সেস কন্ট্রোল, স্ট্রং অডিট লগ এবং সংক্ষিপ্ত রিটেনশনের সঙ্গে। ক্লায়েন্ট-সাইড এনক্রিপশন ব্যবহার করা যেতে পারে যদি সাপোর্ট স্টাফরা কখনোই ID দেখতে না পারুক—তবে তখন যাচাই শেষ করার জন্য অন্য উপায় থাকা দরকার।

মেডিকেল ডকুমেন্ট

মেডিকেল রেকর্ডগুলো উচ্চতর গোপনীয়তার প্রত্যাশা বহন করে। ব্যবহারকারীরা প্রায়ই ধরে নেন যে শুধুমাত্র সবচেয়ে প্রয়োজনীয় ব্যক্তিরাই দেখতে পারবে।

ক্লায়েন্ট-সাইড এনক্রিপশন সার্ভার ব্রিচ বা অ্যাডমিন অপব্যবহার হলে এক্সপোজার কমাতে পারে। কিন্তু এটি বাস্তব ইউএক্স এবং অপারেশনাল সমস্যা তৈরি করতে পারে: পাসওয়ার্ড রিসেট, ডিভাইস পরিবর্তন এবং জরুরি অ্যাক্সেস জটিল হয়ে যায়।

বাছাই করার আগে প্রতিটি ডকুমেন্ট টাইপকে ওয়ার্কফ্লোর সাথে মিলিয়ে দেখুন:

• কে তা পড়বে (কোথা থেকে)
• কত দ্রুত এটি লোড করতে হবে
• কতদিন রাখবেন
• কোন প্রোডাক্ট ফিচারগুলো গুরুত্বপূর্ণ (প্রিভিউ, সার্চ, অটোমেটেড ডিলিশন)

কিভাবে বেছে নেবেন: ধাপে ধাপে সিদ্ধান্ত প্রক্রিয়া

শুরু করুন যা আপনি স্টোর করেন এবং কে তা স্পর্শ করে তা লিখে। একটি “uploads” ফোল্ডার নীতি নয়—নীতিটি নির্দিষ্ট করুন।

ধাপ ১: শুধু “ইউজার” নয়, এক্সেস ম্যাপ করুন

রোলগুলো তালিকাভুক্ত করুন এবং দুটি প্রশ্নের উত্তর দিন: কে ফাইল খুলতে পারবে, এবং কে কখনোই খোলা দেখতে পারবে না (অ্যাডমিনসহ)? রিটেনশনও এখানে যুক্ত করুন।

ধাপ ২: আপনার থ্রেট অনুমান নির্ধারণ করুন

খোলাখুলি বলুন আপনি কী থেকে প্রতিরোধ করতে চাইছেন।

• যদি ইনসাইডার রিস্ক শীর্ষে থাকে, ক্লায়েন্ট-সাইড এনক্রিপশন আরও আকর্ষণীয়।
• যদি ডিভাইস হারানো ও পাসওয়ার্ড রিসেট সাধারণ, রিকভারি জটিলতা আপনাকে মূল্য দিতে হবে।

তারপর অভিজ্ঞতাটি টেস্ট করুন:

1. রিকভারি ও সাপোর্ট: কেউ পাসওয়ার্ড ভুলে গেলে বা ফোন হারালে কী হবে? যদি আপনাকে রিকভার করতে হয়, সম্পূর্ণ ক্লায়েন্ট-সাইড এনক্রিপশন ঠিক না-ও হতে পারে।

2. মাস্ট-হ্যাভ ফিচার: প্রিভিউ, সার্চ, OCR, ই-সাইনিং বা API-ভিত্তিক প্রসেসিং কি লাগবে? এসব অনেকটাই সহজ হয় সার্ভার-সাইড ডিক্রিপশনে।

3. অডিট ও কমপ্লায়েন্স: আপনাকে কি নির্দিষ্ট লগ দরকার কে কখন কী দেখেছে? দুই মডেলেই লগ রাখা যায়, কিন্তু ক্লায়েন্ট-সাইড ডিজাইনে “আমরা সাহায্য করতে পারছি না” ফল এড়াতে অতিরিক্ত যত্ন লাগে।

অধিকাংশ দল হাইব্রিড মডেলে যায়: বেশিরভাগ ডকুমেন্টে সার্ভার-সাইড এনক্রিপশন, এবং কিছু “স্টাফ কখনোই দেখতে পারবে না” ধরনের সংবেদনশীল আপলোডে ক্লায়েন্ট-সাইড এনক্রিপশন।

সাধারণ ভুল ও জাল ফাঁদ

সবচেয়ে বড় ফাঁদ হল এনক্রিপশনকে পুরো কাহিনীর মতো দেখা। প্রাইভেসি ও কমপ্লায়েন্স নির্ভর করে কে ডেটা অ্যাক্সেস করতে পারে, অ্যাক্সেস কিভাবে অনুমোদিত হয়, কী লগ করা হয়, কতদিন রাখা হয় এবং কীভাবে ডিলিশন অনুরোধ 처리 হয়। এনক্রিপশন একা যথেষ্ট নয়।

দ্বিতীয়টি হলো ক্লায়েন্ট-সাইড এনক্রিপশন তৈরি করা কিন্তু রিকভারি প্ল্যান না রাখা। যদি একজন ব্যবহারকারী ডিভাইস হারায়, পাসফ্রেজ ভুলে যায় বা কোম্পানি ছেড়ে যায়, আপনি কি অ্যাক্সেস পুনরুদ্ধার করতে পারবেন নাকি আপনার নিরাপত্তা প্রতিশ্রুতি ভঙ্গ হবে? "আমরা সাহায্য করতে পারি না" ব্যক্তিগত ভল্টে গ্রহণযোগ্য হতে পারে, কিন্তু ব্যবসায়িক অ্যাপে সাধারণত ব্যর্থ হয়।

এই ভুলগুলো বাস্তব ফাঁস ও ওয়ার্কঅ্যারাউন্ড সৃষ্টি করে:

• অ্যাডমিনকে একটি লুকানো “সব কিছু দেখা” পথ দেওয়া বা সাপোর্টকে ব্যবহারকারীর ছদ্মবেশ ধারণ করার অনুমতি দেওয়া, কঠোর লগ ও দ্বিতীয়-ব্যক্তি অনুমোদন ছাড়া।
• ব্রাউজার বা অ্যাপে ডিক্রিপ্ট করে কপি রেখে দেয়া (ক্যাশড প্রিভিউ, অস্থায়ী ডাউনলোড, সিঙ্ক করা ফোল্ডার)।
• “নিরাপদ” ডকুমেন্টগুলো পরে অনিরাপদ চ্যানেলে পাঠানো (ইমেইল করা PDF, চ্যাটে স্ক্রিনশট পেস্ট করা, টিকেটে অ্যাটাচ করা)।
• সিকিউর ফ্লো এত কঠিন করা যে ব্যবহারকারীরা ব্যক্তিগত ড্রাইভে চলে যায় বা স্ক্রিনের ছবি নেয়।
• “এট রেস্টে এনক্রিপ্টেড” থাকা মানেই স্বয়ংক্রিয়ভাবে সম্মতি, অ্যাক্সেস ইতিহাস, রিটেনশন এবং ব্রিচ রিপোর্টিং প্রয়োজনীয়তা পূরণ হবে এমন বোঝা ভুল।

উদাহরণ: একটি ক্লিনিক ইনটেক ফর্ম এনক্রিপ্ট করে, তারপর স্টাফ একটি বিলিং রিপোর্ট এক্সপোর্ট করে যা একটি লোকাল আনএনক্রিপ্টেড ফোল্ডার তৈরি করে। সেই ফোল্ডার শেয়ারড ড্রাইভে ব্যাকআপ হয়। লিকেজটি ক্রিপ্টো তে নয়, ওয়ার্কফ্লোতে ঘটেছে।

চূড়ান্তভাবে সিদ্ধান্ত নেওয়ার আগে দ্রুত চেকলিস্ট

একটি সরল বাক্যে লিখুন: এই ফাইলগুলো কে পড়তে পারবে, এবং সার্ভারে অ্যাক্সেস পেলে কারা কখনোই পড়তে পারবে না।

তারপর চেক করুন:

• কে ডিক্রিপ্ট করে, এবং কখন? সঠিক রোল ও শর্ত তালিকাভুক্ত করুন। আপনার পলিসি যদি বলে “শুধুমাত্র আপলোডকারী,” গোপনে ব্যাকডোর ভাগ কী যোগ করবেন না।
• আপনি কি দ্রুত অ্যাক্সেস বাতিল করতে পারবেন? অফবোর্ডিং-ই প্রকৃত পরীক্ষা। সিদ্ধান্ত নিন অ্যাক্সেস একাউন্ট-, ডিভাইস- বা গ্রুপ-ভিত্তিক কি না।
• ডিভাইস হারানো বা পাসওয়ার্ড রিসেট হলে কী হবে? যদি রিকভারি দরকার, শক্তিশালী অনুমোদন দিয়ে তা সুরক্ষিত করুন।
• প্রিভিউ, ভাইরাস স্ক্যানিং বা OCR লাগে কি? যদি লাগে, পরিকল্পনা করুন কোথায় ডিক্রিপশন হবে এবং কে সেটি ট্রিগার করতে পারবে।
• আপনার অডিট লগ পর্যাপ্ত নির্দিষ্ট কি? "দেখা হয়েছে" বনাম "ডাউনলোড করা হয়েছে" কি হিসেবে গণ্য হবে, এবং ব্যবহারকারী, সময়, ডিভাইস ও কারণ ক্যাপচার করুন।

উদাহরণ পরিস্থতি: একটি ছোট দল যা IDs ও মেডিকেল PDF রাখে

একটি ছোট ক্লিনিকের অ্যাপ আছে যেখানে স্টাফ রোগীর রেফারেল (PDF) এবং বীমার ID-এর ছবি আপলোড করে। লক্ষ্য হলো ডকুমেন্টগুলো দ্রুত সঠিক ব্যক্তিদের কাছে পৌঁছে দেয়া, এবং ডিভাইস হারানো, অ্যাকাউন্ট কম্প্রোমাইজ বা ক্লাউড ভুল কনফিগারেশনের ক্ষতি কমানো।

একটি কার্যকর পন্থা হলো কড়া রোলে সার্ভার-সাইড এনক্রিপশন। ফাইলগুলো এট রেস্টে এনক্রিপ্ট থাকে, এবং পারমিশন দ্বারা কন্ট্রোল করা হয়: ফ্রন্ট ডেস্ক আপলোড করতে পারে, বিলিং ID দেখতে পারে, এবং ক্লিনিশিয়ানরা রেফারেল দেখতে পারে। এটি দৈনন্দিনভাবে সহজ থাকে কারণ স্টাফরা ডেস্কটপ বা মোবাইলে অতিরিক্ত ধাপ ছাড়া ডকুমেন্ট খুলতে পারে, এবং স্যুপারভাইজার অনুপস্থিত হলে অ্যাক্সেস পুনরায় বরাদ্দ করতে পারে।

অন্য একটি পন্থা হলো সবচেয়ে সংবেদনশীল আইটেমগুলোর জন্য ক্লায়েন্ট-সাইড এনক্রিপশন ব্যবহার করা। ফাইল ডিভাইসে এনক্রিপ্ট হওয়ার পরে আপলোড হয়, তাই সার্ভারে কেবল সাইফারটেক্সট সংরক্ষিত হয়। এতে সার্ভার ব্রিচ ও ইনসাইডার অ্যাক্সেসের প্রভাব কমে, কিন্তু অপারেশনে পরিবর্তন আনে:

• পাসওয়ার্ড রিসেট সার্ভার-সাইড এনক্রিপশনে সাধারণত অ্যাক্সেস পুনরুদ্ধার করে; ক্লায়েন্ট-সাইডে রিসেট হলে ব্যবহারকারী লক আউট হতে পারে যদি কী ব্যাকআপ না থাকে।
• স্টাফ টার্নওভার সার্ভার-সাইডে সহজ; ক্লায়েন্ট-সাইডে আপনাকে কী ট্রান্সফার বা এসক্রো করার পরিকল্পনা রাখতে হবে যাতে ডকুমেন্ট অ্যাক্সেসযোগ্য থাকে।

ব্যবহারকারীরা শেয়ারিং, মোবাইল অ্যাক্সেস এবং হারানো ফোনের পরে রিকভারি নিয়ে ঘাঁটাঘাটি করার সময় ঘর্ষণ অনুভব করে। এই বিবরণগুলো এনক্রিপশন মডেল মাত্রের মতো গুরুত্বপূর্ণ।

পরবর্তী ধাপ: সিদ্ধান্ত নিন, নীতি ডকুমেন্ট করুন, এবং ইমপ্লিমেন্ট করুন

আপনার থ্রেট অনুমান সরল ভাষায় লিখে শুরু করুন। আপনার রিস্ক অনুযায়ী সবচেয়ে সহজ পদ্ধতি বেছে নিন, তারপর কেবল সেখানে কঠোরতা যোগ করুন যেখানে ডকুমেন্টগুলি সত্যিই তা justify করে।

ফলে সিদ্ধান্তটিকে একটি সংক্ষিপ্ত অভ্যন্তরীণ নিয়ম সেটে রাখুন:

• কোন ফাইল টাইপ কোথায় রাখা যাবে
• কে কিভাবে অ্যাক্সেস ও শেয়ার করতে পারবে এবং অ্যাক্সেস কিভাবে অনুমোদিত হবে
• রিটেনশন ও ডিলিশন নীতি
• পাসওয়ার্ড রিসেট ও ডিভাইস হারানোর পরে রিকভারি কেমন হবে
• এক্সপোর্ট (ডাউনলোড, ইমেইল, মেসেজিং) কিভাবে হ্যান্ডল হবে এবং কখন ব্লক করা হবে

তারপর সেই নিয়মগুলোকে বাস্তবায়নের দিকে নকশা করুন: রোল চেক, অডিটেড অ্যাকশন (দেখা, ডাউনলোড, শেয়ার), নিরাপদ প্রিভিউ এবং সতর্ক কী হ্যান্ডলিং।

যদি আপনি AppMaster (appmaster.io) মতো নো-কোড প্ল্যাটফর্মে নির্মাণ করছেন, রোল ও অনুমোদন ফ্লো আগে থেকেই মডেল করা সুবিধা দেয়, তারপর চাহিদা বদলালে পুরো অ্যাপ পুনর্লিখতে হয় না। গুরুত্বপূর্ণ অংশ হলো বাস্তব ব্যবহারকারীর জন্য সিকিউর পাথে সহজ করে তোলা।