ফায়ারবেস নিরাপত্তা চেকলিস্ট

উৎপাদন বা লক মোডে নিয়ম শুরু করুন

আপনি যখন 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 জন্য এই নির্দেশিকাগুলি দেখুন।

প্রমাণীকরণ

কাস্টম প্রমাণীকরণ: একটি বিশ্বস্ত (সার্ভার-সাইড) পরিবেশ থেকে মিন্ট JWTs

আপনার যদি ইতিমধ্যেই একটি সুরক্ষিত সাইন-ইন সিস্টেম থাকে, একটি কাস্টম সিস্টেম হোক বা তৃতীয় পক্ষের পরিষেবা, আপনি 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 কনসোলে আইডেন্টিটি টুলকিট 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 এবং Google Cloud API-কে কল করেন যেগুলির পরিষেবা অ্যাকাউন্টের শংসাপত্রের প্রয়োজন হয়, তাহলে Node.js-এর জন্য Google Auth লাইব্রেরি অ্যাপ্লিকেশন ডিফল্ট শংসাপত্রগুলি থেকে এই শংসাপত্রগুলি পেতে পারে, যা Cloud Functions স্বয়ংক্রিয়ভাবে জমা হয়৷

• আপনার Cloud Functions অ-Google পরিষেবাগুলির জন্য ব্যক্তিগত কী এবং শংসাপত্রগুলি উপলব্ধ করতে, Secret Manager ব্যবহার করুন৷

সংবেদনশীল তথ্য এনক্রিপ্ট করুন

আপনি যদি আপনার ফাংশনে সংবেদনশীল তথ্য পাস করা এড়াতে না পারেন, তাহলে আপনাকে অবশ্যই তথ্য এনক্রিপ্ট করতে আপনার নিজস্ব কাস্টম সমাধান নিয়ে আসতে হবে।

সহজ ফাংশন নিরাপদ; আপনার যদি জটিলতার প্রয়োজন হয়, Cloud Run বিবেচনা করুন

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

আপনার যদি জটিল যুক্তি বা পরিবেশ কনফিগারেশনের প্রয়োজন হয়, Cloud Functions পরিবর্তে Cloud Run ব্যবহার করার কথা বিবেচনা করুন।

পরিবেশ ব্যবস্থাপনা

উন্নয়ন এবং মঞ্চায়ন প্রকল্প সেট আপ করুন

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

প্রোডাকশন ডেটাতে টিমের অ্যাক্সেস সীমিত করুন

আপনি যদি একটি বৃহত্তর দলের সাথে কাজ করেন, তাহলে আপনি পূর্বনির্ধারিত IAM ভূমিকা বা কাস্টম IAM ভূমিকা ব্যবহার করে উত্পাদন ডেটাতে অ্যাক্সেস সীমিত করে ভুল এবং লঙ্ঘনের পরিণতিগুলি হ্রাস করতে পারেন৷

যদি আপনার টিম Firebase Local Emulator Suite (প্রস্তাবিত) ডেভেলপমেন্টের জন্য ব্যবহার করে, তাহলে আপনাকে প্রোডাকশন প্রোজেক্টে বৃহত্তর অ্যাক্সেস দেওয়ার প্রয়োজন নাও হতে পারে।

গ্রন্থাগার ব্যবস্থাপনা

লাইব্রেরির ভুল বানান বা নতুন রক্ষণাবেক্ষণকারীদের জন্য সতর্ক থাকুন

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

পরিবর্তনগুলি না বুঝে লাইব্রেরি আপডেট করবেন না

আপগ্রেড করার আগে আপনার ব্যবহার করা যেকোনো লাইব্রেরির পরিবর্তন লগগুলি দেখুন। নিশ্চিত করুন যে আপগ্রেড মান যোগ করে, এবং পরীক্ষা করে দেখুন যে রক্ষণাবেক্ষণকারী এখনও আপনার বিশ্বাসযোগ্য একটি পক্ষ।

ওয়াচডগ লাইব্রেরিগুলিকে ডেভ বা টেস্ট নির্ভরতা হিসাবে ইনস্টল করুন৷

অনিরাপদ নির্ভরতার জন্য আপনার প্রকল্প স্ক্যান করতে Snyk এর মতো একটি লাইব্রেরি ব্যবহার করুন।

Cloud Functions জন্য মনিটরিং সেট আপ করুন; লাইব্রেরি আপডেটের পরে এটি পরীক্ষা করুন

আপনি যদি Cloud Functions লগার SDK ব্যবহার করেন, তাহলে আপনি লাইব্রেরি আপডেটের কারণে সৃষ্ট আচরণ সহ অস্বাভাবিক আচরণের নিরীক্ষণ এবং সতর্ক হতে পারেন।