Android ট্রান্সপোর্ট লেয়ার , আপনার সার্ভার, FCM ব্যাকএন্ড এবং ক্লায়েন্ট ডিভাইসগুলির মধ্যে সম্পূর্ণ সংযোগ সহ, ট্রান্সপোর্ট লেয়ার সিকিউরিটি (TLS) ব্যবহার করে সুরক্ষিত। এটি ট্রানজিটে থাকাকালীন সমস্ত ডেটার জন্য শক্তিশালী পয়েন্ট-টু-পয়েন্ট এনক্রিপশন প্রদান করে, এটিকে নেটওয়ার্কে বাধা দেওয়া থেকে রক্ষা করে। এই শক্তিশালী সুরক্ষা মডেলটি বেশিরভাগ অ্যাপ্লিকেশনের জন্য উপযুক্ত। আপনি FCM আর্কিটেকচার ডকুমেন্টেশনে আরও বিশদ জানতে পারেন।
পয়েন্ট টু পয়েন্ট এনক্রিপশনের একটি সীমাবদ্ধতা হল এটি সম্পূর্ণ পথের জন্য এনক্রিপ্ট করা হয়নি যেখানে শুধুমাত্র প্রেরক এবং প্রাপক বার্তাটি ডিকোড করতে পারে। এই কারণেই FCM গোপনীয়তা সংবেদনশীল যোগাযোগের জন্য চ্যাট বার্তা বা প্রমাণীকরণ ট্রান্সকেশনের জন্য শেষ থেকে শেষ এনক্রিপশন ব্যবহার করার পরামর্শ দেয়। এন্ড থেকে এন্ড এনক্রিপশন সবচেয়ে বেশি পাওয়ার জন্য, এটিকে অবশ্যই উচ্চতর স্তরে প্রয়োগ করতে হবে, যেমন আপনার সার্ভার এবং অ্যাপ কোডের মধ্যে।
সংবেদনশীল ডেটার জন্য এন্ড-টু-এন্ড এনক্রিপশন যোগ করুন
ব্যক্তিগত বার্তা বা ব্যক্তিগত শংসাপত্রের মতো বিশেষভাবে সংবেদনশীল ডেটা পরিচালনা করে এমন অ্যাপ্লিকেশনগুলির জন্য, আপনি এন্ড-টু-এন্ড এনক্রিপশন (E2EE) সহ সুরক্ষার একটি অতিরিক্ত স্তর যুক্ত করতে পারেন৷ প্রক্রিয়াটিতে FCM এ পাঠানোর আগে আপনার সার্ভারে বার্তা পেলোড এনক্রিপ্ট করা এবং ব্যবহারকারীর ডিভাইসে আপনার অ্যাপের মধ্যে এটি ডিক্রিপ্ট করা জড়িত। এটি FCM ডেটা বার্তাগুলির সাথে কাজ করে, কারণ স্ট্যান্ডার্ড নোটিফিকেশন পেলোডগুলি অপারেটিং সিস্টেম দ্বারা পরিচালিত হয় এবং প্রদর্শিত হওয়ার আগে আপনার অ্যাপ দ্বারা ডিক্রিপ্ট করা যায় না৷
মনে রাখবেন যে FCM এন্ড-টু-এন্ড এনক্রিপশনের জন্য বিল্ট-ইন সমাধান প্রদান করে না। আপনার অ্যাপ্লিকেশনের মধ্যে এই নিরাপত্তা স্তর বাস্তবায়নের জন্য আপনি দায়ী। এই উদ্দেশ্যে ডিজাইন করা বাহ্যিক লাইব্রেরি এবং প্রোটোকল রয়েছে, যেমন ক্যাপিলারি বা DTLS ।
ধারণাগত উদাহরণ
E2EE ব্যবহার করার সময় FCM data
পেলোড কীভাবে পরিবর্তিত হয় তা এখানে।
এনক্রিপশনের আগে (স্ট্যান্ডার্ড পেলোড):
{
"token": "DEVICE_REGISTRATION_TOKEN",
"data": {
"sender": "user123",
"message_body": "Your 2FA code is 555-123",
"timestamp": "1661299200"
}
}
এনক্রিপশনের পরে (E2EE পেলোড):
{
"token": "DEVICE_REGISTRATION_TOKEN",
"data": {
"encrypted_payload": "aG9va2Vk...so much encrypted gibberish...ZW5jcnlwdA=="
}
}
আপনি যদি আপনার e2e এনক্রিপশন সঠিকভাবে প্রয়োগ করে থাকেন, তাহলে ক্লায়েন্ট অ্যাপ্লিকেশনই একমাত্র পক্ষ যা মূল বার্তা প্রকাশ করতে এনক্রিপ্ট করা পেলোড ডিক্রিপ্ট করতে সক্ষম।
বিকল্প: আপনার সার্ভার থেকে সরাসরি সামগ্রী আনা
যদি এন্ড-টু-এন্ড এনক্রিপশন আপনার অ্যাপের জন্য উপযুক্ত না হয়, আপনি পরিবর্তে খালি ডেটা বার্তা পাঠাতে পারেন। এই বার্তাগুলি আপনার সার্ভার থেকে সরাসরি সামগ্রী আনার জন্য অ্যাপের জন্য একটি সংকেত হিসাবে কাজ করে৷ এর অর্থ হল সংবেদনশীল ডেটা শুধুমাত্র ডেটা স্থানান্তরের জন্য FCM বাইপাস করে আপনার অ্যাপ এবং আপনার সার্ভারের মধ্যে পরিবহন করা হয়।
এই পদ্ধতির একটি ত্রুটি হল ডেটা পুনরুদ্ধার করতে আপনার সার্ভারের সাথে সংযুক্ত অ্যাপের কারণে সম্ভাব্য বিলম্ব। যখন একটি অ্যাপ একটি ডেটা বার্তা পায়, তখন ব্যাকগ্রাউন্ড হওয়ার আগে একটি বিজ্ঞপ্তি প্রদর্শন করার জন্য এটি সাধারণত কয়েক সেকেন্ড থাকে। আপনার সার্ভার থেকে ডেটা আনা এই উইন্ডোর মধ্যে সম্পূর্ণ নাও হতে পারে৷ এই ডেটা আনার সাফল্য ব্যবহারকারীর ডিভাইস সংযোগের মতো বিষয়গুলির উপর নির্ভর করে৷
অতএব, ডেটা আনতে অনেক সময় লাগতে পারে এমন পরিস্থিতিতে ব্যবহারকারীর অভিজ্ঞতার বিকল্প বিবেচনা করুন। উদাহরণস্বরূপ, আপনি একটি জেনেরিক বিজ্ঞপ্তি প্রদর্শন করতে পারেন যেমন "আপনার কাছে একটি নতুন বার্তা রয়েছে" এবং তারপর সম্পূর্ণ বিষয়বস্তু পুনরুদ্ধার হয়ে গেলে এটি আপডেট করতে পারেন।