জোড়া লাগানো

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

ব্যবহারকারীর গোপনীয়তা বজায় রাখতে এনক্রিপশন প্রয়োগ করার তিনটি প্রাসঙ্গিক উপায় রয়েছে: ট্রানজিটে এনক্রিপশন, বিশ্রামে এনক্রিপশন এবং এন্ড-টু-এন্ড এনক্রিপশন:

• ট্রানজিটে এনক্রিপশন হল ব্যবহারকারী এবং আপনার সাইটের মধ্যে ডেটা এনক্রিপ্ট করা: অর্থাৎ, HTTPS। আপনি সম্ভবত ইতিমধ্যেই আপনার সাইটের জন্য HTTPS সেট আপ করেছেন, কিন্তু আপনি কি নিশ্চিত যে আপনার সাইটের সমস্ত ডেটা এনক্রিপ্ট করা হয়েছে? পুনঃনির্দেশ এবং HSTS এর জন্য এটিই, এবং সেগুলি নীচে বর্ণনা করা হয়েছে এবং আপনার HTTPS সেটআপের অংশ হওয়া উচিত৷
• বিশ্রামে এনক্রিপশন হল আপনার সার্ভারে সংরক্ষিত ডেটার এনক্রিপশন। এটি ডেটা লঙ্ঘন থেকে রক্ষা করে এবং এটি আপনার নিরাপত্তা অবস্থানের একটি গুরুত্বপূর্ণ অংশ।
• এন্ড-টু-এন্ড এনক্রিপশন হল ক্লায়েন্টের ডেটা আপনার সার্ভারে পৌঁছানোর আগেই এনক্রিপশন। এটি ব্যবহারকারীর ডেটা এমনকি আপনার থেকেও রক্ষা করে: আপনি আপনার ব্যবহারকারীদের ডেটা সংরক্ষণ করতে পারেন, কিন্তু আপনি এটি পড়তে পারবেন না। এটি বাস্তবায়ন করা কঠিন, এবং এটি সব ধরনের অ্যাপ্লিকেশনের জন্য উপযুক্ত নয়, তবে এটি ব্যবহারকারীর গোপনীয়তার জন্য একটি শক্তিশালী সহায়তা, কারণ কেউ তাদের ডেটা নিজেদের ছাড়া অন্য কেউ দেখতে পারে না।

HTTPS

প্রথম পদক্ষেপ হল HTTPS এর মাধ্যমে আপনার ওয়েব পরিষেবা পরিবেশন করা। এটি খুব সম্ভবত আপনি ইতিমধ্যে এটি করেছেন, কিন্তু যদি না হয় তবে এটি একটি গুরুত্বপূর্ণ পদক্ষেপ। HTTPS হল HTTP, একটি প্রোটোকল যা একটি ব্রাউজার একটি সার্ভার থেকে ওয়েব পৃষ্ঠাগুলির অনুরোধ করতে ব্যবহার করে, কিন্তু SSL ব্যবহার করে এনক্রিপ্ট করা হয়। এর মানে হল যে একজন বহিরাগত আক্রমণকারী প্রেরক (আপনার ব্যবহারকারী) এবং প্রাপকের (আপনি) মধ্যে একটি HTTPS অনুরোধ পড়তে বা হস্তক্ষেপ করতে পারে না, কারণ এটি এনক্রিপ্ট করা হয়েছে এবং তাই তারা এটি পড়তে বা পরিবর্তন করতে পারে না। এটি ট্রানজিটে এনক্রিপশন: যখন ডেটা ব্যবহারকারী থেকে আপনার কাছে বা আপনার থেকে ব্যবহারকারীর কাছে চলে যাচ্ছে। ট্রানজিটে HTTPS এনক্রিপশন ব্যবহারকারীর ISP, বা তারা যে Wi-Fi ব্যবহার করছে তার প্রদানকারীকে আপনার পরিষেবার সাথে তাদের সম্পর্কের অংশ হিসাবে তারা আপনাকে যে ডেটা পাঠাচ্ছে তা পড়তে সক্ষম হতে বাধা দেয়। এটি আপনার পরিষেবার বৈশিষ্ট্যগুলিকেও প্রভাবিত করতে পারে: বিদ্যমান JavaScript API-এর অনেকগুলি ব্যবহারের জন্য ওয়েবসাইটটিকে HTTPS-এর মাধ্যমে পরিবেশন করা প্রয়োজন৷ MDN- এর আরও বিস্তৃত তালিকা রয়েছে, কিন্তু একটি নিরাপদ প্রেক্ষাপটের পিছনে থাকা APIগুলির মধ্যে রয়েছে পরিষেবা কর্মী, পুশ বিজ্ঞপ্তি, ওয়েব শেয়ার এবং ওয়েব ক্রিপ্টো এবং কিছু ডিভাইস API।

HTTPS এর মাধ্যমে আপনার ওয়েবসাইট পরিবেশন করতে আপনার একটি SSL শংসাপত্রের প্রয়োজন হবে৷ এগুলি Let's Encrypt এর মাধ্যমে বিনামূল্যে তৈরি করা যেতে পারে, অথবা আপনি যদি একটি ব্যবহার করেন তবে প্রায়শই আপনার হোস্টিং পরিষেবা দ্বারা সরবরাহ করা যেতে পারে। এটি একটি তৃতীয় পক্ষের পরিষেবা ব্যবহার করাও সম্ভব যা আপনার ওয়েব পরিষেবাকে "প্রক্সি" করে এবং HTTPS, সেইসাথে ক্যাশিং এবং CDN পরিষেবাগুলি প্রদান করতে পারে৷ ক্লাউডফ্লেয়ার এবং ফাস্টলি-এর মতো এই ধরনের পরিষেবার অসংখ্য উদাহরণ রয়েছে—ঠিক কোনটি ব্যবহার করতে হবে তা আপনার বর্তমান অবকাঠামোর উপর নির্ভর করে। অতীতে, HTTPS প্রয়োগ করা কঠিন বা ব্যয়বহুল হতে পারে, যে কারণে এটি শুধুমাত্র অর্থপ্রদানের পৃষ্ঠাগুলিতে বা বিশেষভাবে সুরক্ষিত উত্সগুলিতে ব্যবহার করার প্রবণতা ছিল; কিন্তু অবাধে উপলব্ধ সার্টিফিকেট, মান উন্নয়ন এবং ব্রাউজারগুলির বৃহত্তর বিস্তার সেই সমস্ত বাধা দূর করেছে।

করবেন

• সবকিছুর জন্য আপনার সার্ভারে HTTPS সক্ষম করুন (আপনি যে পদ্ধতিটি বেছে নিন)।
• আপনার সার্ভারের সামনে একটি প্রক্সি ব্যবহার করার কথা বিবেচনা করুন, যেমন Cloudflare ( httpsiseasy.com/ প্রক্রিয়াটি ব্যাখ্যা করে)।
• আসুন এনক্রিপ্ট আপনাকে আপনার নিজস্ব Let's Encrypt SSL সার্টিফিকেট তৈরি করার প্রক্রিয়ার মধ্য দিয়ে নিয়ে যাবে।
• অথবা আপনার নিজের শংসাপত্র তৈরি করতে সরাসরি OpenSSL ব্যবহার করুন এবং এটি আপনার পছন্দের শংসাপত্র কর্তৃপক্ষ (CA) দ্বারা স্বাক্ষর করুন ( HTTPS সক্ষম করুন বিস্তারিতভাবে এটি কীভাবে করবেন তা ব্যাখ্যা করে)।

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

শংসাপত্র তৈরি করা এবং সেগুলিকে CA দ্বারা স্বাক্ষর করা হল SSL প্রক্রিয়াটি কীভাবে পরিচালিত হত, কিন্তু Let's Encrypt ব্যবহার করা সহজ হতে পারে যদি এটি আপনার প্রদানকারী দ্বারা সমর্থিত হয় বা যদি আপনার সার্ভার টিম এটির জন্য প্রযুক্তিগতভাবে যথেষ্ট পারদর্শী হয় এবং এটি বিনামূল্যে। আপনি যদি ক্লাউড হোস্টিংয়ের চেয়ে উচ্চ স্তরে কিছু ব্যবহার করেন তবে আপনার সরবরাহকারীর জন্য একটি পরিষেবা হিসাবে SSL অফার করাও সাধারণ, তাই এটি পরীক্ষা করা মূল্যবান৷

কেন

নিরাপত্তা আপনার গোপনীয়তার গল্পের একটি অংশ: আপনি যে ব্যবহারকারীর ডেটা হস্তক্ষেপের বিরুদ্ধে সুরক্ষিত রাখেন তা প্রদর্শন করতে সক্ষম হওয়া বিশ্বাস গড়ে তুলতে সাহায্য করে। আপনি যদি HTTPS ব্যবহার না করেন, তাহলে আপনার সাইটগুলিকেও ব্রাউজার দ্বারা "নিরাপদ নয়" হিসেবে পতাকাঙ্কিত করা হয় (এবং কিছু সময়ের জন্য ছিল)। বিদ্যমান জাভাস্ক্রিপ্ট APIগুলি প্রায়শই শুধুমাত্র HTTPS পৃষ্ঠাগুলিতে উপলব্ধ ("সুরক্ষিত উত্স") ৷ এটি আপনার ব্যবহারকারীদের তাদের ওয়েব ব্যবহার তাদের ISP দ্বারা দেখা থেকে রক্ষা করে। এটি অবশ্যই একটি সেরা অনুশীলন; এখন ওয়েবসাইটগুলির জন্য HTTPS ব্যবহার না করার কোন কারণ নেই।

ব্রাউজার কিভাবে একটি HTTP (নিরাপদ) পৃষ্ঠা উপস্থাপন করে

HTTPS এ রিডাইরেক্ট করুন

যদি আপনার সাইটটি http: এবং https: URL উভয়েই পাওয়া যায়, তাহলে আপনাকে সমস্ত http URL অ্যাক্সেস https-এ রিডাইরেক্ট করা উচিত। এটি উপরের কারণগুলির জন্য, এবং এটি নিশ্চিত করে যে আপনার সাইটটি Whynohttps.com- এ প্রদর্শিত হবে না যদি এটি জনপ্রিয় হয়। এটি কীভাবে করবেন তা আপনার অবকাঠামোর উপর অনেক বেশি নির্ভর করে। আপনি যদি AWS-এ হোস্ট করেন তবে আপনি একটি ক্লাসিক বা অ্যাপ্লিকেশন লোড ব্যালেন্সার ব্যবহার করতে পারেন। গুগল ক্লাউড অনুরূপ। Azure এ আপনি একটি সামনের দরজা তৈরি করতে পারেন; এক্সপ্রেস সহ নোডে request.secure এর জন্য চেক করুন ; Nginx-এ সমস্ত পোর্ট 80 ধরুন এবং 301 ফেরত দিন ; এবং Apache এ, একটি RewriteRule ব্যবহার করুন । আপনি যদি একটি হোস্টিং পরিষেবা ব্যবহার করেন, তাহলে সম্ভবত তারা স্বয়ংক্রিয়ভাবে আপনার জন্য HTTPS URL-এ পুনঃনির্দেশ পরিচালনা করবে: Netlify, Firebase এবং GitHub পেজগুলি আরও অনেকের মধ্যে এটি করে।

এইচএসটিএস

HSTS হল "HTTP Strict-Transport-Security" এর জন্য সংক্ষিপ্ত, এবং আপনার পরিষেবার জন্য HTTPS ব্যবহার করার জন্য একটি ব্রাউজারকে লক করার একটি উপায়। একবার আপনি HTTPS-এ আপনার স্থানান্তর নিয়ে খুশি হলে, অথবা আপনি যদি ইতিমধ্যেই এটি করে থাকেন, তাহলে আপনি আপনার বহির্গামী প্রতিক্রিয়াগুলিতে একটি কঠোর-পরিবহন-নিরাপত্তা HTTP প্রতিক্রিয়া শিরোনাম যোগ করতে পারেন। একটি ব্রাউজার যা আগে আপনার সাইটটি অ্যাক্সেস করেছে তারা এই শিরোনামটি দেখেছে তা রেকর্ড করবে এবং তারপর থেকে আপনি HTTP অনুরোধ করলেও স্বয়ংক্রিয়ভাবে এই সাইটটি HTTPS হিসাবে অ্যাক্সেস করবে। এটি উপরের মত আপনার পুনঃনির্দেশের মধ্য দিয়ে যাওয়া এড়িয়ে যায়: যেন ব্রাউজারটি HTTPS ব্যবহার করার জন্য আপনার পরিষেবার সমস্ত অনুরোধ নীরবে "আপগ্রেড" করে।

একইভাবে, আপনি আপনার পৃষ্ঠাগুলির সাথে একটি আপগ্রেড-অনিরাপদ-অনুরোধের শিরোনাম পরিবেশন করতে পারেন। এটি Strict-Transport-Security থেকে ভিন্ন কিন্তু সম্পর্কিত কিছু করে। আপনি যদি Upgrade-Insecure-Requests: 1 , তাহলে এই পৃষ্ঠা থেকে অন্যান্য সংস্থানগুলিতে (ছবি, স্ক্রিপ্ট) অনুরোধগুলি https হিসাবে অনুরোধ করা হবে যদিও লিঙ্কটি http হয়। যাইহোক, ব্রাউজার নিজেই https হিসাবে পৃষ্ঠাটিকে পুনরায় অনুরোধ করবে না এবং ব্রাউজার পরবর্তী সময়ের জন্য মনে রাখবে না। বাস্তবে, আপগ্রেড-অনিরাপদ-অনুরোধ উপযোগী যদি আপনি অনেকগুলি লিঙ্ক সহ একটি বিদ্যমান সাইটকে HTTPS-এ রূপান্তর করেন এবং বিষয়বস্তুতে লিঙ্ক URLগুলিকে রূপান্তর করা কঠিন, তবে যেখানে সম্ভব বিষয়বস্তু পরিবর্তন করা ভাল।

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

করবেন

আপনার বহির্গামী প্রতিক্রিয়াগুলিতে HSTS হেডার যোগ করুন:

Strict-Transport-Security: max-age=300; includeSubDomains

সর্বোচ্চ বয়সের প্যারামিটার নির্দেশ করে যে কতক্ষণ, সেকেন্ডে, ব্রাউজারটিকে HTTPS আপগ্রেডটি মনে রাখা এবং প্রয়োগ করা উচিত। (এখানে আমরা এটি 300 সেকেন্ড, অর্থাৎ পাঁচ মিনিটে সেট করেছি।) অবশেষে আপনি এটি 6,3072,000 হতে চান, যা দুই বছর, এবং এটি hstspreload.org সুপারিশ করে, কিন্তু এটি পুনরুদ্ধার করা বেশ কঠিন। যদি সমস্যা থাকে। তাই এটি সুপারিশ করা হয় যে আপনি এটিকে প্রথমে একটি কম নম্বর দিয়ে সেট করুন (300), নিশ্চিত করার জন্য পরীক্ষা করুন যে কিছুই ভাঙেনি, এবং তারপরে ধাপে সংখ্যা বাড়ান।

আপনার বহির্গামী প্রতিক্রিয়াগুলিতে Upgrade-Insecure-Requests শিরোনামগুলি যুক্ত করুন:

Upgrade-Insecure-Requests: 1 Content-Security-Policy: upgrade-insecure-requests

এন্ড-টু-এন্ড এনক্রিপশন

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

এটা কিভাবে কাজ করে?

এই পদ্ধতিটি প্রায়শই মেসেজিং অ্যাপ্লিকেশন দ্বারা ব্যবহৃত হয়, যেখানে এটি "এন্ড-টু-এন্ড এনক্রিপশন" বা "e2e" হিসাবে উল্লেখ করা হয়। এইভাবে, দু'জন ব্যক্তি যারা একে অপরের কী জানেন তারা তাদের বার্তাগুলিকে এনক্রিপ্ট এবং ডিক্রিপ্ট করতে পারে এবং বার্তা প্রদানকারীর মাধ্যমে সেই বার্তাগুলি পাঠাতে পারে, কিন্তু বার্তা প্রদানকারী (যার কাছে সেই কীগুলি নেই) বার্তাগুলি পড়তে পারে না। বেশিরভাগ অ্যাপ্লিকেশনগুলি মেসেজিং অ্যাপ নয়, তবে এটি দুটি পদ্ধতিকে একত্রিত করা সম্ভব - একটি সম্পূর্ণ ক্লায়েন্ট-সাইড ডেটা স্টোর, এবং ক্লায়েন্টের কাছে পরিচিত একটি কী সহ ডেটা এনক্রিপশন - স্থানীয়ভাবে ডেটা সঞ্চয় করার জন্য তবে এটি সার্ভারে এনক্রিপ্ট করা পাঠানোও। এটি উপলব্ধি করা গুরুত্বপূর্ণ যে এই পদ্ধতির সীমাবদ্ধতা রয়েছে: এটি সমস্ত পরিষেবার জন্য সম্ভব নয়, এবং বিশেষ করে এটি ব্যবহার করা যাবে না যদি আপনি, পরিষেবা প্রদানকারী হিসাবে, ব্যবহারকারী যা সংরক্ষণ করছেন তাতে অ্যাক্সেসের প্রয়োজন হয়৷ এই সিরিজের পার্ট 2- এ যেমন বর্ণনা করা হয়েছে, ডেটা মিনিমাইজেশনের নীতি মেনে চলা সর্বোত্তম; আপনি যদি পারেন তবে ডেটা সংগ্রহ করা এড়িয়ে চলুন। যদি ব্যবহারকারীর ডেটা সঞ্চয়স্থানের প্রয়োজন হয়, কিন্তু পরিষেবা প্রদানের জন্য আপনার সেই ডেটাতে অ্যাক্সেসের প্রয়োজন না হয়, তাহলে এন্ড-টু-এন্ড এনক্রিপশন একটি কার্যকর বিকল্প। আপনি যদি এমন পরিষেবাগুলি প্রদান করেন যার জন্য ব্যবহারকারীর পরিষেবা প্রদানের জন্য কী সঞ্চয় করে তা দেখতে সক্ষম হওয়া প্রয়োজন, তাহলে এন্ড-টু-এন্ড এনক্রিপশন উপযুক্ত নয়৷ কিন্তু আপনি যদি তা না করেন, তাহলে আপনি আপনার ওয়েব সার্ভিসের ক্লায়েন্ট-সাইড জাভাস্ক্রিপ্ট সার্ভারে পাঠানো যেকোনো ডেটা এনক্রিপ্ট করতে পারেন এবং এটি প্রাপ্ত যেকোনো ডেটা ডিক্রিপ্ট করতে পারেন।

একটি উদাহরণ: Excalidraw

Excalidraw এটি করে এবং কিভাবে একটি ব্লগ পোস্টে ব্যাখ্যা করে। এটি একটি ভেক্টর অঙ্কন অ্যাপ্লিকেশন যা সার্ভারে অঙ্কন সংরক্ষণ করে, যা একটি এলোমেলোভাবে নির্বাচিত কী দিয়ে এনক্রিপ্ট করা হয়। Excalidraw অপেক্ষাকৃত কম কোডের সাথে এই এন্ড-টু-এন্ড এনক্রিপশন বাস্তবায়ন করতে পারে তার একটি কারণ হল যে ক্রিপ্টোগ্রাফিক লাইব্রেরিগুলি এখন window.crypto সহ ব্রাউজারে তৈরি করা হয়েছে, যা সমস্ত আধুনিক ব্রাউজারে সমর্থিত JavaScript API-এর একটি সেট। ক্রিপ্টোগ্রাফি কঠিন এবং অ্যালগরিদম প্রয়োগ করা অনেক প্রান্তের ক্ষেত্রে আসে। ব্রাউজারকে এখানে ভারী উত্তোলন করার জন্য এনক্রিপশনকে ওয়েব ডেভেলপারদের কাছে আরও অ্যাক্সেসযোগ্য করে তোলে এবং তাই এনক্রিপ্ট করা ডেটার মাধ্যমে গোপনীয়তা বাস্তবায়ন করা সহজ করে তোলে। যেমন Excalidraw তাদের লেখায় বর্ণনা করে, এনক্রিপশন কীটি ক্লায়েন্ট-সাইডে থেকে যায়, কারণ এটি URL খণ্ডের অংশ: যখন একটি ব্রাউজার একটি URL https://example.com/path?param=1#fraghere পরিদর্শন করে, এর পথ URL ( /path ) এবং পরামিতিগুলি ( param=1 ) সার্ভারে ( example.com ) পাঠানো হয়, কিন্তু খণ্ডটি ( fraghere ) হয় না, এবং তাই সার্ভার কখনই এটি দেখতে পায় না। এর মানে হল যে এমনকি যদি এনক্রিপ্ট করা ডেটা সার্ভারের মাধ্যমে যায়, এনক্রিপশন কীটি করে না এবং এইভাবে গোপনীয়তা সংরক্ষণ করা হয় কারণ ডেটা এন্ড-টু-এন্ড এনক্রিপ্ট করা হয়।

সীমাবদ্ধতা

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

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

বিশ্রামে এনক্রিপশন

ট্রানজিটে আপনার ব্যবহারকারীদের ডেটা এনক্রিপ্ট করার পাশাপাশি, সার্ভারে আপনার সংরক্ষণ করা ডেটা এনক্রিপ্ট করার বিষয়টি বিবেচনা করাও গুরুত্বপূর্ণ৷ এটি ডেটা লঙ্ঘন থেকে রক্ষা করতে সহায়তা করে, কারণ যে কেউ আপনার সঞ্চিত ডেটাতে অননুমোদিত অ্যাক্সেস পায় তার কাছে এনক্রিপ্ট করা ডেটা থাকবে, যা আশা করি তাদের কাছে ডিক্রিপ্ট করার কী থাকবে না। বিশ্রামে ডেটা এনক্রিপ্ট করার দুটি ভিন্ন এবং পরিপূরক পদ্ধতি রয়েছে: আপনি যে এনক্রিপশন যোগ করেন এবং আপনার ক্লাউড স্টোরেজ প্রদানকারী যোগ করে এমন এনক্রিপশন (যদি আপনি ক্লাউড স্টোরেজ প্রদানকারী ব্যবহার করেন)। স্টোরেজ প্রদানকারী এনক্রিপশন আপনার সফ্টওয়্যারের মাধ্যমে ডেটা লঙ্ঘনের বিরুদ্ধে খুব বেশি সুরক্ষা প্রদান করে না (কারণ স্টোরেজ প্রদানকারীর এনক্রিপশন সাধারণত তাদের পরিষেবার ব্যবহারকারী হিসাবে আপনার কাছে স্বচ্ছ হয়), তবে এটি প্রদানকারীর পরিকাঠামোতে ঘটে যাওয়া লঙ্ঘনের বিরুদ্ধে সাহায্য করে। এটি চালু করা প্রায়শই সহজ এবং তাই বিবেচনা করার মতো। এই ক্ষেত্রটি দ্রুত পরিবর্তিত হয় এবং আপনার নিরাপত্তা দল (বা আপনার টিমের নিরাপত্তা-বুদ্ধিমান প্রকৌশলী) এটির বিষয়ে পরামর্শ দেওয়ার জন্য সর্বোত্তম, তবে সমস্ত ক্লাউড স্টোরেজ প্রদানকারীরা অ্যামাজন S3 ব্লক স্টোরেজ, Azure স্টোরেজ এবং Google ক্লাউড স্টোরেজের মাধ্যমে বিশ্রামে এনক্রিপশন অফার করে। ডিফল্টরূপে, এবং ডেটাবেস ডেটা স্টোরেজের জন্য AWS RDS , Azure SQL , Google Cloud SQL অন্যদের মধ্যে। আপনার ক্লাউড স্টোরেজ প্রদানকারীর সাথে এটি পরীক্ষা করে দেখুন, যদি আপনি একটি ব্যবহার করেন। ডেটা লঙ্ঘন থেকে ব্যবহারকারীর ডেটা রক্ষা করতে সাহায্য করার জন্য বিশ্রামে ডেটার এনক্রিপশন পরিচালনা করা আরও কঠিন, কারণ এনক্রিপশন কীগুলি সুরক্ষিতভাবে পরিচালনা করা এবং আক্রমণকারীদের কাছে সেগুলি উপলব্ধ না করে কোডের জন্য উপলব্ধ করা চ্যালেঞ্জিং। এই স্তরে নিরাপত্তা সংক্রান্ত বিষয়ে পরামর্শ দেওয়ার জন্য এটি সেরা জায়গা নয়; আপনার নিরাপত্তা-বুদ্ধিমান প্রকৌশলী বা ডেডিকেটেড টিমের সাথে এই বিষয়ে কথা বলুন, বা বাইরের নিরাপত্তা সংস্থার সাথে কথা বলুন।