আপনার Firebase রিসোর্স এবং ব্যবহারকারীদের ডেটা সুরক্ষিত রাখতে, এই নির্দেশিকাগুলো অনুসরণ করুন। প্রতিটি বিষয় আপনার প্রয়োজনের ক্ষেত্রে প্রযোজ্য নাও হতে পারে, কিন্তু আপনার অ্যাপ তৈরি করার সময় এগুলো মনে রাখবেন।
আপত্তিকর ট্র্যাফিক এড়িয়ে চলুন
ব্যাকএন্ড পরিষেবাগুলির জন্য মনিটরিং এবং অ্যালার্টিং সেট আপ করুন
ডিনায়াল-অফ-সার্ভিস (DOS) আক্রমণের মতো ক্ষতিকর ট্র্যাফিক শনাক্ত করতে Cloud Firestore , Realtime Database , Cloud Storage এবং Hosting জন্য মনিটরিং ও অ্যালার্টিং ব্যবস্থা চালু করুন।
আপনার অ্যাপ্লিকেশনে কোনো আক্রমণের সন্দেহ হলে, কী ঘটছে তা জানাতে যত তাড়াতাড়ি সম্ভব সাপোর্টের সাথে যোগাযোগ করুন ।
App Check সক্ষম করুন
শুধুমাত্র আপনার অ্যাপগুলোই যেন আপনার ব্যাকএন্ড পরিষেবাগুলো অ্যাক্সেস করতে পারে, তা নিশ্চিত করতে, যে সকল পরিষেবা এটি সমর্থন করে সেগুলোর জন্য Firebase App Check সক্রিয় করুন।
সাধারণ ট্র্যাফিকের জন্য আপনার Cloud Functions স্কেল করতে কনফিগার করুন।
Cloud Functions আপনার অ্যাপের চাহিদা মেটাতে স্বয়ংক্রিয়ভাবে স্কেল করে, কিন্তু কোনো আক্রমণের ক্ষেত্রে এর ফলে একটি বড় অঙ্কের বিল আসতে পারে। এটি প্রতিরোধ করতে, আপনি আপনার অ্যাপের স্বাভাবিক ট্র্যাফিকের উপর ভিত্তি করে একটি ফাংশনের যুগপৎ ইনস্ট্যান্সের সংখ্যা সীমিত করতে পারেন।
সীমা প্রায় পৌঁছে গেলে বিজ্ঞপ্তি পাওয়ার জন্য সতর্কীকরণ ব্যবস্থা সেট করুন।
আপনার সার্ভিসে অনুরোধের সংখ্যা হঠাৎ বেড়ে গেলে, প্রায়শই কোটা চালু হয়ে যায় এবং স্বয়ংক্রিয়ভাবে আপনার অ্যাপ্লিকেশনের ট্র্যাফিক কমিয়ে দেয়। আপনার Usage এবং billing ড্যাশবোর্ড নিরীক্ষণ করা নিশ্চিত করুন, তবে রিসোর্স ব্যবহার প্রত্যাশার চেয়ে বেশি হলে বিজ্ঞপ্তি পাওয়ার জন্য আপনি আপনার প্রোজেক্টে বাজেট অ্যালার্টও সেট করতে পারেন।
সেলফ-ডোজ প্রতিরোধ করুন: এমুলেটর ব্যবহার করে স্থানীয়ভাবে ফাংশনগুলো পরীক্ষা করুন।
Cloud Functions ডেভেলপ করার সময় ভুলবশত নিজের উপরই DOS আক্রমণ চালানো সহজ হতে পারে: উদাহরণস্বরূপ, একটি অসীম ট্রিগার-রাইট লুপ তৈরি করার মাধ্যমে। Firebase Local Emulator Suite ব্যবহার করে ডেভেলপমেন্টের কাজ করার মাধ্যমে আপনি এই ভুলগুলো থেকে লাইভ সার্ভিসকে রক্ষা করতে পারেন।
আর যদি আপনি ভুলবশত নিজেকেই DOS আক্রমণ করে ফেলেন, তাহলে index.js থেকে ফাংশনটি মুছে দিয়ে এবং তারপর রান করে আনডিপ্লয় করুন।firebase deploy --only functions .
যেখানে তাৎক্ষণিক সাড়াদান কম গুরুত্বপূর্ণ, সেখানে কাঠামো প্রতিরক্ষামূলকভাবে কাজ করে।
যদি আপনার কোনো ফাংশনের ফলাফল রিয়েল টাইমে দেখানোর প্রয়োজন না হয়, তাহলে ফলাফলগুলো ব্যাচ আকারে প্রসেস করার মাধ্যমে আপনি অতিরিক্ত ট্র্যাফিক প্রতিরোধ করতে পারেন: ফলাফলগুলো একটি Pub/Sub টপিকে পাবলিশ করুন এবং একটি শিডিউলড ফাংশনের মাধ্যমে নিয়মিত বিরতিতে সেগুলো প্রসেস করুন।
এপিআই কীগুলি বুঝুন
ফায়ারবেস পরিষেবাগুলির এপিআই কীগুলি গোপনীয় নয়।
ফায়ারবেস পরিষেবাগুলির জন্য এপিআই কীগুলি শুধুমাত্র সেই পরিষেবাগুলির কাছে আপনার ফায়ারবেস প্রজেক্ট এবং অ্যাপকে শনাক্ত করে । Google Cloud আইএএম পারমিশন, Firebase Security Rules এবং Firebase App Check মাধ্যমে অনুমোদন পরিচালিত হয়।
ফায়ারবেস থেকে সরবরাহ করা সমস্ত এপিআই কী স্বয়ংক্রিয়ভাবে ফায়ারবেস-সম্পর্কিত এপিআই-এর জন্য সীমাবদ্ধ থাকে। যদি আপনার অ্যাপের সেটআপ এই পৃষ্ঠার নির্দেশিকা অনুসরণ করে, তাহলে ফায়ারবেস পরিষেবার জন্য সীমাবদ্ধ এপিআই কীগুলিকে গোপনীয় হিসাবে বিবেচনা করার প্রয়োজন নেই এবং সেগুলি আপনার কোড বা কনফিগারেশন ফাইলে অন্তর্ভুক্ত করা নিরাপদ।
এপিআই কী সীমাবদ্ধতা সেট আপ করুন
আপনি যদি অন্যান্য গুগল পরিষেবার জন্য এপিআই কী ব্যবহার করেন, তাহলে নিশ্চিত করুন যে আপনি আপনার এপিআই কী-গুলোকে শুধুমাত্র আপনার অ্যাপ ক্লায়েন্ট এবং ব্যবহৃত এপিআইগুলোর মধ্যে সীমাবদ্ধ রাখতে এপিআই কী বিধিনিষেধ প্রয়োগ করেছেন।
আপনার Firebase-প্রদত্ত API কীগুলি শুধুমাত্র Firebase-সম্পর্কিত API-গুলির জন্য ব্যবহার করুন। যদি আপনার অ্যাপ অন্য কোনো API ব্যবহার করে (উদাহরণস্বরূপ, Maps-এর জন্য Places API বা Gemini Developer API ), তাহলে একটি পৃথক API কী ব্যবহার করুন এবং সেটিকে প্রযোজ্য API-এর মধ্যে সীমাবদ্ধ রাখুন।
FCM সার্ভার কীগুলি গোপন রাখুন
Firebase পরিষেবাগুলির API কী-এর বিপরীতে, FCM সার্ভার কী ( যা লিগ্যাসি FCM HTTP API দ্বারা ব্যবহৃত হয়) সংবেদনশীল এবং অবশ্যই গোপন রাখতে হবে।
সার্ভিস অ্যাকাউন্টের কীগুলো গোপন রাখুন
Firebase পরিষেবাগুলির API কী-এর মতো নয়, পরিষেবা অ্যাকাউন্টের প্রাইভেট কী (যা Firebase Admin SDK দ্বারা ব্যবহৃত হয়) সংবেদনশীল এবং অবশ্যই গোপন রাখতে হবে।
Firebase Security Rules
প্রোডাকশন বা লকড মোডে নিয়মগুলি শুরু করুন
যখন আপনি Cloud Firestore , Realtime Database এবং Cloud Storage সেট আপ করবেন, তখন ডিফল্টরূপে সমস্ত অ্যাক্সেস অস্বীকার করার জন্য আপনার Firebase Security Rules শুরু করুন এবং আপনার অ্যাপ তৈরি করার সাথে সাথে নির্দিষ্ট রিসোর্সগুলিতে অ্যাক্সেস দেওয়ার জন্য নিয়ম যুক্ত করুন।
Cloud Firestore (প্রোডাকশন মোড) এবং Realtime Database (লকড মোড)-এর নতুন ইনস্ট্যান্সের জন্য ডিফল্ট সেটিংসগুলোর মধ্যে একটি ব্যবহার করুন। Cloud Storage জন্য, নিম্নলিখিতের মতো একটি নিরাপত্তা নিয়ম কনফিগারেশন দিয়ে শুরু করুন:
rules_version = '2';
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if false;
}
}
}
নিরাপত্তা নিয়মাবলী হলো একটি স্কিমা; ডকুমেন্ট যোগ করার সময় নিয়মাবলীও যোগ করুন।
আপনার অ্যাপ লেখার পরে, এক ধরনের প্রাক-লঞ্চ কাজ হিসেবে সিকিউরিটি রুল লিখবেন না। এর পরিবর্তে, অ্যাপ লেখার সময়ই সিকিউরিটি রুলগুলো লিখুন এবং সেগুলোকে একটি ডাটাবেস স্কিমার মতো বিবেচনা করুন: যখনই আপনার কোনো নতুন ডকুমেন্ট টাইপ বা পাথ স্ট্রাকচার ব্যবহার করার প্রয়োজন হবে, প্রথমে সেটির সিকিউরিটি রুলটি লিখুন।
Local Emulator Suite ব্যবহার করে নিরাপত্তা নিয়মগুলির ইউনিট পরীক্ষা করুন; এটিকে CI-তে যোগ করুন।
আপনার অ্যাপের উন্নয়নের সাথে আপনার নিরাপত্তা নিয়মগুলো তাল মিলিয়ে চলছে কিনা তা নিশ্চিত করতে, Firebase Local Emulator Suite ব্যবহার করে আপনার নিয়মগুলো ইউনিট টেস্ট করুন এবং এই টেস্টগুলো আপনার CI পাইপলাইনে যোগ করুন। Cloud Firestore এবং Realtime Database জন্য এই গাইডগুলো দেখুন।
প্রমাণীকরণ
কাস্টম প্রমাণীকরণ: একটি বিশ্বস্ত (সার্ভার-সাইড) পরিবেশ থেকে JWT তৈরি করা
আপনার যদি আগে থেকেই একটি সুরক্ষিত সাইন-ইন সিস্টেম থাকে, তা কাস্টম সিস্টেম হোক বা কোনো থার্ড-পার্টি পরিষেবা, আপনি Firebase পরিষেবাগুলির সাথে প্রমাণীকরণের জন্য আপনার বিদ্যমান সিস্টেমটি ব্যবহার করতে পারেন। একটি বিশ্বস্ত পরিবেশ থেকে কাস্টম JWT তৈরি করুন , তারপর টোকেনগুলি আপনার ক্লায়েন্টের কাছে পাঠান, যা প্রমাণীকরণের জন্য টোকেনটি ব্যবহার করে ( iOS+ , Android , Web , Unity , C++ )।
তৃতীয় পক্ষের প্রদানকারীর সাথে কাস্টম অথেনটিকেশন ব্যবহারের একটি উদাহরণের জন্য, “Okta ব্যবহার করে Firebase-এর সাথে অথেনটিকেশন করুন” ব্লগ পোস্টটি দেখুন।
পরিচালিত প্রমাণীকরণ: OAuth 2.0 প্রোভাইডারগুলো সবচেয়ে সুরক্ষিত।
আপনি যদি Firebase-এর পরিচালিত প্রমাণীকরণ বৈশিষ্ট্যগুলি ব্যবহার করেন, তাহলে OAuth 2.0 / OpenID Connect প্রদানকারী বিকল্পগুলি (Google, Facebook, ইত্যাদি) সবচেয়ে সুরক্ষিত। সম্ভব হলে আপনার ব্যবহারকারীর সংখ্যার উপর নির্ভর করে এই প্রদানকারীগুলির মধ্যে এক বা একাধিককে সমর্থন করা উচিত।
ইমেল-পাসওয়ার্ড প্রমাণীকরণ: ব্রুট ফোর্স আক্রমণ প্রতিরোধ করতে সাইন-ইন এন্ডপয়েন্টের জন্য কঠোর কোটা নির্ধারণ করুন।
আপনি যদি Firebase-এর পরিচালিত ইমেল-পাসওয়ার্ড প্রমাণীকরণ পরিষেবা ব্যবহার করেন, তাহলে ব্রুট ফোর্স আক্রমণ প্রতিরোধ করতে identitytoolkit.googleapis.com এন্ডপয়েন্টগুলির ডিফল্ট কোটা আরও কঠোর করুন। আপনি Google Cloud কনসোলের Identity Toolkit API পৃষ্ঠা থেকে এটি করতে পারেন।
ইমেল-পাসওয়ার্ড প্রমাণীকরণ: ইমেল গণনা সুরক্ষা সক্রিয় করুন
আপনি যদি Firebase-এর পরিচালিত ইমেল-পাসওয়ার্ড প্রমাণীকরণ পরিষেবা ব্যবহার করেন, তাহলে ইমেল এনুমারেশন সুরক্ষা সক্রিয় করুন , যা ক্ষতিকারক ব্যক্তিদের আপনার প্রোজেক্টের প্রমাণীকরণ এন্ডপয়েন্টগুলির অপব্যবহার করে অ্যাকাউন্টের নাম অনুমান করা থেকে বিরত রাখে।
মাল্টি-ফ্যাক্টর অথেনটিকেশনের জন্য Google Cloud Identity Platform আপগ্রেড করুন।
সাইন-ইন করার সময় অতিরিক্ত নিরাপত্তার জন্য, আপনি Google Cloud Identity Platform এ আপগ্রেড করে মাল্টি-ফ্যাক্টর অথেনটিকেশন সাপোর্ট যোগ করতে পারেন। আপগ্রেড করার পরেও আপনার বিদ্যমান Firebase Authentication কোডটি কাজ করতে থাকবে।
বেনামী প্রমাণীকরণ
ওয়ার্ম অনবোর্ডিংয়ের জন্য শুধুমাত্র অ্যানোনিমাস অথেন্টিকেশন ব্যবহার করুন।
ব্যবহারকারীরা প্রকৃতভাবে সাইন ইন করার আগে তাদের প্রাথমিক অবস্থা সংরক্ষণ করার জন্য শুধুমাত্র অ্যানোনিমাস অথেন্টিকেশন ব্যবহার করুন। অ্যানোনিমাস অথেন্টিকেশন ব্যবহারকারীর সাইন-ইন-এর বিকল্প নয়।
ব্যবহারকারীরা যদি অন্যান্য ডিভাইসে তাদের ডেটা রাখতে চান, তাহলে তাদেরকে অন্য কোনো সাইন-ইন পদ্ধতিতে রূপান্তর করুন।
ব্যবহারকারী লোকাল স্টোরেজ মুছে ফেললে বা ডিভাইস পরিবর্তন করলে বেনামী প্রমাণীকরণ ডেটা সংরক্ষিত থাকবে না । যদি কোনো একটি ডিভাইসে অ্যাপ পুনরায় চালু হওয়ার পরেও ডেটা সংরক্ষিত রাখার প্রয়োজন হয়, তবে ব্যবহারকারীকে একটি স্থায়ী অ্যাকাউন্টে রূপান্তর করুন ।
এমন নিরাপত্তা নিয়ম ব্যবহার করুন যা ব্যবহারকারীদের একটি সাইন-ইন প্রদানকারীতে রূপান্তরিত হতে বা তাদের ইমেল যাচাই করতে বাধ্য করে।
যে কেউ আপনার প্রোজেক্টে একটি বেনামী অ্যাকাউন্ট তৈরি করতে পারে। এই বিষয়টি মাথায় রেখে, সমস্ত অপ্রকাশ্য ডেটা এমন নিরাপত্তা নিয়ম দিয়ে সুরক্ষিত করুন, যেগুলোতে নির্দিষ্ট সাইন-ইন পদ্ধতি বা যাচাইকৃত ইমেল ঠিকানা বাধ্যতামূলক করা হয় ।
উদাহরণস্বরূপ:
allow write: if request.auth.token.firebase.sign_in_provider != "anonymous";
allow write: if request.auth.token.email_verified = true;
Cloud Functions নিরাপত্তা
এনভায়রনমেন্ট ভেরিয়েবলে কখনো সংবেদনশীল তথ্য রাখবেন না।
প্রায়শই সেলফ-হোস্টেড Node.js অ্যাপে প্রাইভেট কী-এর মতো সংবেদনশীল তথ্য রাখার জন্য এনভায়রনমেন্ট ভেরিয়েবল ব্যবহার করা হয়। Cloud Functions এমনটা করবেন না । যেহেতু Cloud Functions এক ফাংশন থেকে অন্য ফাংশনে এনভায়রনমেন্ট পুনঃব্যবহার করে, তাই এনভায়রনমেন্টে সংবেদনশীল তথ্য সংরক্ষণ করা উচিত নয়।
Firebase API কী-গুলো (যা গোপনীয় নয় ) সংরক্ষণ করতে, সেগুলোকে কোডের মধ্যে এম্বেড করুন।
আপনি যদি Cloud Functions -এ Firebase Admin SDK ব্যবহার করেন, তাহলে আপনাকে স্পষ্টভাবে সার্ভিস অ্যাকাউন্টের ক্রেডেনশিয়াল প্রদান করার প্রয়োজন নেই, কারণ Admin SDK ইনিশিয়ালাইজেশনের সময় স্বয়ংক্রিয়ভাবে সেগুলি সংগ্রহ করে নিতে পারে।
আপনি যদি এমন গুগল এবং Google Cloud এপিআই কল করেন যার জন্য সার্ভিস অ্যাকাউন্ট ক্রেডেনশিয়াল প্রয়োজন, তাহলে Node.js-এর জন্য Google Auth লাইব্রেরিটি অ্যাপ্লিকেশন ডিফল্ট ক্রেডেনশিয়াল থেকে এই ক্রেডেনশিয়ালগুলো সংগ্রহ করতে পারে, যা Cloud Functions স্বয়ংক্রিয়ভাবে যুক্ত হয়ে যায়।
আপনার Cloud Functions গুগল-বহির্ভূত পরিষেবাগুলির প্রাইভেট কী এবং ক্রেডেনশিয়াল উপলব্ধ করতে, Secret Manager ব্যবহার করুন।
সংবেদনশীল তথ্য এনক্রিপ্ট করুন
আপনার ফাংশনগুলোতে সংবেদনশীল তথ্য পাঠানো যদি এড়ানো সম্ভব না হয়, তবে তথ্যটি এনক্রিপ্ট করার জন্য আপনাকে অবশ্যই নিজস্ব একটি সমাধান বের করতে হবে।
সরল ফাংশনগুলো বেশি নিরাপদ; যদি জটিলতার প্রয়োজন হয়, তবে Cloud Run বিবেচনা করতে পারেন।
আপনার ফাংশনগুলো যথাসম্ভব সহজ ও বোধগম্য রাখার চেষ্টা করুন। ফাংশনের জটিলতা প্রায়শই এমন বাগ বা অপ্রত্যাশিত আচরণের কারণ হতে পারে যা সহজে চোখে পড়ে না।
আপনার যদি জটিল লজিক বা এনভায়রনমেন্ট কনফিগারেশনের প্রয়োজন হয়, তাহলে Cloud Functions পরিবর্তে Cloud Run ব্যবহার করার কথা বিবেচনা করতে পারেন।
পরিবেশ ব্যবস্থাপনা
উন্নয়ন এবং পর্যায়ক্রমিক প্রকল্প স্থাপন করুন
ডেভেলপমেন্ট, স্টেজিং এবং প্রোডাকশনের জন্য আলাদা ফায়ারবেস প্রজেক্ট তৈরি করুন। স্টেজিং প্রজেক্টে পরীক্ষা না করা পর্যন্ত ক্লায়েন্ট কোড প্রোডাকশনে মার্জ করবেন না।
প্রোডাকশন ডেটাতে টিমের অ্যাক্সেস সীমিত করুন
আপনি যদি একটি বড় দলের সাথে কাজ করেন, তাহলে পূর্বনির্ধারিত IAM রোল অথবা কাস্টম IAM রোল ব্যবহার করে প্রোডাকশন ডেটাতে অ্যাক্সেস সীমিত করার মাধ্যমে ভুল এবং লঙ্ঘনের পরিণতি প্রশমিত করতে পারেন।
যদি আপনার টিম ডেভেলপমেন্টের জন্য Firebase Local Emulator Suite (প্রস্তাবিত) ব্যবহার করে, তাহলে প্রোডাকশন প্রজেক্টে আরও ব্যাপক অ্যাক্সেস দেওয়ার প্রয়োজন নাও হতে পারে।
গ্রন্থাগার ব্যবস্থাপনা
লাইব্রেরির বানান ভুল বা নতুন রক্ষণাবেক্ষণকারীদের ব্যাপারে সতর্ক থাকুন।
আপনার প্রোজেক্টে লাইব্রেরি যোগ করার সময়, লাইব্রেরির নাম এবং এর রক্ষণাবেক্ষণকারীদের প্রতি বিশেষ মনোযোগ দিন। আপনি যে লাইব্রেরিটি ইনস্টল করতে চান, তার সাথে প্রায় একই নামের কোনো লাইব্রেরিতে ক্ষতিকারক কোড থাকতে পারে।
পরিবর্তনগুলো না বুঝে লাইব্রেরি আপডেট করবেন না।
আপগ্রেড করার আগে আপনার ব্যবহৃত যেকোনো লাইব্রেরির চেঞ্জ লগগুলো ভালোভাবে দেখে নিন। নিশ্চিত হন যে আপগ্রেডটি কোনো বাড়তি সুবিধা যোগ করছে, এবং যাচাই করে নিন যে এর রক্ষণাবেক্ষণকারী এখনও আপনার বিশ্বস্ত একজন ব্যক্তি।
ওয়াচডগ লাইব্রেরিগুলোকে ডেভ বা টেস্ট ডিপেন্ডেন্সি হিসেবে ইনস্টল করুন
আপনার প্রোজেক্টে অনিরাপদ ডিপেন্ডেন্সি খুঁজে বের করতে Snyk-এর মতো কোনো লাইব্রেরি ব্যবহার করুন।
Cloud Functions জন্য মনিটরিং সেট আপ করুন; লাইব্রেরি আপডেটের পর এটি পরীক্ষা করুন।
আপনি যদি Cloud Functions লগার এসডিকে ব্যবহার করেন, তাহলে লাইব্রেরি আপডেটের কারণে সৃষ্ট আচরণসহ অন্যান্য অস্বাভাবিক আচরণ পর্যবেক্ষণ করতে এবং সে সম্পর্কে সতর্কবার্তা পেতে পারবেন।