قائمة التحقق من أمان Firebase

للحفاظ على أمان موارد Firebase وبيانات المستخدمين ، اتبع هذه الإرشادات. ليس بالضرورة أن ينطبق كل عنصر على متطلباتك ، ولكن ضعها في اعتبارك أثناء تطوير تطبيقك.

تجنب حركة المرور المسيئة

قم بإعداد المراقبة والتنبيه لخدمات الواجهة الخلفية

لاكتشاف حركة المرور المسيئة ، مثل هجمات رفض الخدمة (DOS) ، قم بإعداد المراقبة والتنبيه لـ Cloud Firestore و Realtime Database و Cloud Storage والاستضافة

إذا كنت تشك في حدوث هجوم على تطبيقك ، فاتصل بالدعم في أقرب وقت ممكن لإخبارهم بما يحدث.

تمكين التحقق من التطبيق

للمساعدة في ضمان وصول تطبيقاتك فقط إلى خدمات الواجهة الخلفية ، قم بتمكين التحقق من التطبيقات لكل خدمة تدعمها.

تكوين وظائف السحابة الخاصة بك لتوسيع نطاق حركة المرور العادية

تتوسع وظائف السحابة تلقائيًا لتلبية متطلبات تطبيقك ، ولكن في حالة وقوع هجوم ، قد يعني هذا فاتورة كبيرة. لمنع ذلك ، يمكنك تحديد عدد المثيلات المتزامنة لوظيفة ما بناءً على حركة المرور العادية لتطبيقك.

قم بإعداد التنبيه ليتم إعلامك عند الوصول إلى الحدود القصوى تقريبًا

إذا كانت خدمتك تحتوي على طلبات زيادات في الطلب ، فغالبًا ما يتم تشغيل نظام الحصص ، ويخنق تلقائيًا حركة المرور إلى تطبيقك. تأكد من مراقبة لوحة معلومات الاستخدام والفوترة ، ولكن يمكنك أيضًا تعيين تنبيهات الميزانية في مشروعك ليتم إعلامك عندما يتجاوز استخدام الموارد التوقعات.

منع الجرعات الذاتية: اختبر الوظائف محليًا باستخدام المحاكيات

قد يكون من السهل إجراء DOS بنفسك عن طريق الخطأ أثناء تطوير وظائف السحابة: على سبيل المثال ، من خلال إنشاء حلقة لا نهائية من كتابة المشغل. يمكنك منع هذه الأخطاء من التأثير على الخدمات المباشرة من خلال القيام بالتطوير باستخدام مجموعة محاكي Firebase .

(وإذا قمت بنفسك عن طريق الخطأ DOS ، فقم بإلغاء نشر وظيفتك عن طريق إزالتها من index.js ثم تشغيل firebase deploy --only functions .)

عندما تكون الاستجابة في الوقت الفعلي أقل أهمية ، تعمل البنية بشكل دفاعي

إذا لم تكن بحاجة إلى تقديم نتيجة إحدى الوظائف في الوقت الفعلي ، فيمكنك التخفيف من حركة المرور المسيئة عن طريق معالجة النتائج على دفعات: نشر النتائج إلى موضوع Pub / Sub ، ومعالجة النتائج على فترات منتظمة باستخدام وظيفة مجدولة .

فهم مفاتيح API

مفاتيح واجهة برمجة التطبيقات لخدمات Firebase ليست سرية

يستخدم Firebase مفاتيح واجهة برمجة التطبيقات فقط لتحديد مشروع Firebase لتطبيقك على خدمات Firebase ، وليس للتحكم في الوصول إلى قاعدة البيانات أو بيانات التخزين السحابي ، وهو ما يتم باستخدام قواعد أمان Firebase . لهذا السبب ، لا تحتاج إلى التعامل مع مفاتيح واجهة برمجة التطبيقات لخدمات Firebase على أنها أسرار ، ويمكنك تضمينها بأمان في رمز العميل. تعرّف على المزيد حول مفاتيح واجهة برمجة التطبيقات لـ Firebase .

قم بإعداد تحديد نطاق مفتاح API

كرادع إضافي ضد المهاجم الذي يحاول استخدام مفتاح واجهة برمجة التطبيقات (API) الخاص بك لانتحال الطلبات ، يمكنك إنشاء مفاتيح واجهة برمجة تطبيقات مخصصة لعملاء التطبيق .

حافظ على سرية مفاتيح خادم FCM

على عكس مفاتيح واجهة برمجة التطبيقات لخدمات Firebase ، فإن مفاتيح خادم FCM (المستخدمة بواسطة واجهة برمجة تطبيقات FCM HTTP القديمة ) حساسة ويجب أن تظل سرية.

حافظ على سرية مفاتيح حساب الخدمة

بخلاف مفاتيح واجهة برمجة التطبيقات لخدمات Firebase ، تعد المفاتيح الخاصة لحساب الخدمة (المستخدمة بواسطة Admin SDK ) حساسة ويجب أن تظل سرية.

قواعد الأمان

تهيئة القواعد في وضع الإنتاج أو القفل

عند إعداد Cloud Firestore و Realtime Database و Cloud Storage ، قم بتهيئة قواعد الأمان الخاصة بك لرفض الوصول بالكامل افتراضيًا ، وإضافة القواعد التي تمنح الوصول إلى موارد معينة أثناء تطوير تطبيقك.

هذا هو أحد الإعدادات الافتراضية للمثيلات الجديدة لـ Cloud Firestore (وضع الإنتاج) و Realtime Database (الوضع المقفل). اختر هذا الخيار عند إعداد طبعة قاعدة بيانات جديدة.

بالنسبة إلى Cloud Storage ، ابدأ بتكوين قواعد الأمان مثل ما يلي:

rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if false;
    }
  }
}

قواعد الأمان هي مخطط؛ أضف القواعد عند إضافة المستندات

لا تكتب قواعد الأمان بعد كتابة تطبيقك ، كنوع من مهمة ما قبل التشغيل. بدلاً من ذلك ، اكتب قواعد الأمان أثناء كتابة تطبيقك ، ومعاملتها كمخطط قاعدة بيانات: كلما احتجت إلى استخدام نوع مستند جديد أو بنية مسار ، اكتب قاعدة الأمان الخاصة به أولاً.

اختبار الوحدة لقواعد الأمان باستخدام Emulator Suite ؛ أضفه إلى CI

للتأكد من أن قواعد الأمان الخاصة بك تتماشى مع تطوير تطبيقك ، اختبر الوحدة قواعدك باستخدام مجموعة محاكي Firebase وأضف هذه الاختبارات إلى خط أنابيب CI الخاص بك. راجع هذه الأدلة الخاصة بـ Cloud Firestore و Realtime Database .

المصادقة

المصادقة المخصصة: قم بصنع JWTs من بيئة موثوقة (من جانب الخادم)

إذا كان لديك بالفعل نظام تسجيل دخول آمن ، سواء كان نظامًا مخصصًا أو خدمة تابعة لجهة خارجية ، فيمكنك استخدام نظامك الحالي للمصادقة مع خدمات Firebase. قم بإنشاء JWTs مخصصة من بيئة موثوقة ، ثم قم بتمرير الرموز المميزة إلى عميلك ، والذي يستخدم الرمز المميز للمصادقة ( iOS + ، Android ، Web ، Unity ، C ++ ).

للحصول على مثال لاستخدام المصادقة المخصصة مع موفر تابع لجهة خارجية ، راجع منشور المدونة ، المصادقة باستخدام Firebase باستخدام Okta .

المصادقة المُدارة: موفرو OAuth 2.0 هم الأكثر أمانًا

إذا كنت تستخدم ميزات المصادقة المُدارة من Firebase ، فإن خيارات موفر OAuth 2.0 / OpenID Connect (Google و Facebook وما إلى ذلك) هي الأكثر أمانًا. يجب عليك دعم واحد أو أكثر من هؤلاء المزودين إذا كان بإمكانك (حسب قاعدة المستخدمين الخاصة بك).

مصادقة كلمة مرور البريد الإلكتروني: قم بتعيين حصة ضيقة لنقطة نهاية تسجيل الدخول لمنع هجمات القوة الغاشمة

إذا كنت تستخدم خدمة مصادقة كلمة مرور البريد الإلكتروني المُدارة من Firebase ، فقم بتشديد الحصة الافتراضية لنقاط نهاية identitytoolkit.googleapis.com لمنع هجمات القوة الغاشمة. يمكنك القيام بذلك من صفحة API في Google Cloud Console .

مصادقة كلمة مرور البريد الإلكتروني: قم بتمكين حماية تعداد البريد الإلكتروني

إذا كنت تستخدم خدمة مصادقة كلمة مرور البريد الإلكتروني المُدارة من Firebase ، فقم بتمكين حماية تعداد البريد الإلكتروني ، مما يمنع الجهات الضارة من إساءة استخدام نقاط نهاية مصادقة مشروعك لتخمين أسماء الحسابات.

قم بالترقية إلى Cloud Identity Platform للمصادقة متعددة العوامل

لمزيد من الأمان عند تسجيل الدخول ، يمكنك إضافة دعم مصادقة متعددة العوامل من خلال الترقية إلى Cloud Identity Platform . سيستمر رمز مصادقة Firebase الحالي في العمل بعد الترقية.

مصادقة مجهولة

استخدم فقط المصادقة المجهولة للإعداد الدائم

استخدم المصادقة المجهولة فقط لحفظ الحالة الأساسية للمستخدمين قبل تسجيل الدخول فعليًا. المصادقة المجهولة ليست بديلاً لتسجيل دخول المستخدم.

قم بتحويل المستخدمين إلى طريقة تسجيل دخول أخرى إذا كانوا يريدون البيانات عندما يفقدون هواتفهم

لن تستمر بيانات المصادقة المجهولة إذا قام المستخدم بمسح التخزين المحلي أو تبديل الأجهزة. إذا كنت بحاجة إلى الاحتفاظ بالبيانات بعد إعادة تشغيل التطبيق على جهاز واحد ، فقم بتحويل المستخدم إلى حساب دائم .

استخدم قواعد الأمان التي تتطلب من المستخدمين التحويل إلى موفر تسجيل الدخول أو التحقق من بريدهم الإلكتروني

يمكن لأي شخص إنشاء حساب مجهول في مشروعك. مع وضع ذلك في الاعتبار ، قم بحماية جميع البيانات غير العامة بقواعد الأمان التي تتطلب أساليب تسجيل دخول محددة أو عناوين بريد إلكتروني تم التحقق منها .

علي سبيل المثال:

allow write: if request.auth.token.firebase.sign_in_provider != "anonymous";
allow write: if request.auth.token.email_verified = true;

إدارة البيئة

قم بإعداد مشاريع التطوير والتنفيذ

قم بإعداد مشاريع Firebase منفصلة للتطوير والتنفيذ والإنتاج. لا تدمج كود العميل في الإنتاج حتى يتم اختباره مقابل المشروع المرحلي.

تقييد وصول الفريق إلى بيانات الإنتاج

إذا كنت تعمل مع فريق أكبر ، فيمكنك التخفيف من عواقب الأخطاء والانتهاكات عن طريق تقييد الوصول إلى بيانات الإنتاج باستخدام أدوار محددة مسبقًا أو أدوار IAM مخصصة.

إذا كان فريقك يستخدم مجموعة المحاكي للتطوير ، فقد لا تحتاج إلى منح وصول أوسع إلى مشروع الإنتاج.

إدارة المكتبات

احترس من الأخطاء الإملائية في المكتبة أو المشرفين الجدد

عند إضافة مكتبات إلى مشروعك ، انتبه جيدًا لاسم المكتبة والقائمين عليها. يمكن أن تحتوي المكتبة التي تحمل اسمًا مشابهًا للمكتبة التي تنوي تثبيتها على تعليمات برمجية ضارة.

لا تقم بتحديث المكتبات دون فهم التغييرات

انظر إلى سجلات التغيير لأي مكتبات تستخدمها قبل الترقية. تأكد من أن الترقية تضيف قيمة ، وتحقق من أن المشرف لا يزال طرفًا تثق به.

قم بتثبيت مكتبات المراقبة على أنها مطور أو تبعيات تجريبية

استخدم مكتبة مثل Snyk لفحص مشروعك بحثًا عن التبعيات غير الآمنة.

إعداد مراقبة الوظائف ؛ تحقق من ذلك بعد تحديثات المكتبة

إذا كنت تستخدم SDK لمسجل وظائف السحابة ، فيمكنك مراقبة السلوك غير المعتاد وتنبيهه ، بما في ذلك السلوك الناجم عن تحديثات المكتبة.

سلامة وظيفة السحابة

لا تضع أبدًا معلومات حساسة في متغيرات بيئة وظيفة السحابة

غالبًا في تطبيق Node.js المستضاف ذاتيًا ، يمكنك استخدام متغيرات البيئة لاحتواء معلومات حساسة مثل المفاتيح الخاصة. لا تفعل هذا في وظائف السحابة . نظرًا لأن وظائف السحابة تعيد استخدام البيئات بين استدعاءات الوظائف ، فلا ينبغي تخزين المعلومات الحساسة في البيئة.

  • لتخزين مفاتيح Firebase API ، وهي ليست سرية ، عليك فقط تضمينها في التعليمات البرمجية.
  • إذا كنت تستخدم Firebase Admin SDK في وظيفة السحاب ، فلن تحتاج إلى تقديم بيانات اعتماد حساب الخدمة بشكل صريح ، لأن SDK يمكن أن تحصل عليها تلقائيًا أثناء التهيئة.
  • إذا كنت تتصل بـ Google و Google Cloud APIs التي تتطلب بيانات اعتماد حساب الخدمة ، فيمكن لمكتبة مصادقة Google لـ Node.js الحصول على بيانات الاعتماد هذه من بيانات الاعتماد الافتراضية للتطبيق ، والتي يتم ملؤها تلقائيًا في وظائف السحابة.
  • لإتاحة مفاتيح وبيانات اعتماد خاصة للخدمات غير التابعة لـ Google للوظائف السحابية ، استخدم Cloud Secret Manager .

تشفير المعلومات الحساسة

إذا لم تتمكن من تجنب تمرير معلومات حساسة إلى وظيفة السحابة الخاصة بك ، فيجب عليك التوصل إلى حل مخصص خاص بك لتشفير المعلومات.

الوظائف البسيطة أكثر أمانًا ؛ إذا كنت بحاجة إلى تعقيد ، ففكر في Cloud Run

حاول أن تجعل وظائف السحابة الخاصة بك بسيطة ومفهومة قدر الإمكان. غالبًا ما يؤدي التعقيد في وظائفك إلى أخطاء يصعب اكتشافها أو سلوك غير متوقع.

إذا كنت بحاجة إلى تكوينات منطقية أو بيئة معقدة ، ففكر في استخدام Cloud Run بدلاً من Cloud Functions.