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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

فهم مفاتيح API

مفاتيح API لخدمات Firebase ليست سرية

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

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

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

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

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

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

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

قواعد الأمن

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

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

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

بالنسبة للتخزين السحابي، ابدأ بتكوين قواعد الأمان كما يلي:

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 .

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

إذا كنت تستخدم خدمة مصادقة كلمة مرور البريد الإلكتروني المُدارة من 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 المستضاف ذاتيًا، يمكنك استخدام متغيرات البيئة لاحتواء معلومات حساسة مثل المفاتيح الخاصة. لا تفعل هذا في Cloud Functions . نظرًا لأن Cloud Functions تعيد استخدام البيئات بين استدعاءات الوظائف، فلا ينبغي تخزين المعلومات الحساسة في البيئة.

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

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

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

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

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

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