چک لیست امنیتی Firebase

برای ایمن نگه داشتن منابع Firebase و داده های کاربران خود، این دستورالعمل ها را دنبال کنید. لزوماً همه موارد برای نیازهای شما اعمال نمی شوند، اما هنگام توسعه برنامه خود آنها را در نظر داشته باشید.

از ترافیک ناهنجار خودداری کنید

نظارت و هشدار را برای خدمات باطن تنظیم کنید

برای شناسایی ترافیک سوء استفاده‌کننده، مانند حملات انکار سرویس (DOS)، نظارت و هشدار را برای Cloud Firestore ، پایگاه داده بیدرنگ ، فضای ذخیره‌سازی ابری و میزبانی تنظیم کنید.

اگر مشکوک به حمله به برنامه خود هستید، در اسرع وقت با پشتیبانی تماس بگیرید تا به آنها اطلاع دهید که چه اتفاقی در حال رخ دادن است.

بررسی برنامه را فعال کنید

برای اطمینان از اینکه فقط برنامه‌های شما می‌توانند به خدمات پشتیبان شما دسترسی داشته باشند، بررسی برنامه را برای هر سرویسی که از آن پشتیبانی می‌کند فعال کنید.

توابع ابری خود را به گونه ای پیکربندی کنید که برای ترافیک عادی مقیاس شوند

Cloud Functions به طور خودکار برای برآورده کردن خواسته های برنامه شما مقیاس می شود، اما در صورت حمله، این می تواند به معنای یک صورت حساب بزرگ باشد. برای جلوگیری از این امر، می توانید تعداد نمونه های همزمان یک تابع را بر اساس ترافیک عادی برنامه خود محدود کنید .

هشدار را تنظیم کنید تا در صورت نزدیک شدن به محدودیت ها به شما اطلاع داده شود

اگر سرویس شما افزایش درخواست داشته باشد، اغلب سهمیه ها وارد می شوند و به طور خودکار ترافیک را به برنامه شما کاهش می دهند. مطمئن شوید که داشبورد استفاده و صورت‌حساب خود را کنترل می‌کنید، اما همچنین می‌توانید هشدارهای بودجه را برای پروژه خود تنظیم کنید تا زمانی که استفاده از منابع بیش از حد انتظار است به آنها اطلاع داده شود.

جلوگیری از self-DOSes: تست عملکردها به صورت محلی با شبیه سازها

می‌توان هنگام توسعه توابع ابری، به‌طور تصادفی خود را DOS کرد: برای مثال، با ایجاد یک حلقه ماشه-نوشتن نامحدود. شما می توانید با انجام برنامه توسعه خود با مجموعه شبیه ساز Firebase از تأثیر این اشتباهات بر خدمات زنده جلوگیری کنید.

(و اگر به طور تصادفی خودتان DOS انجام دادید، تابع خود را با حذف آن از index.js و سپس اجرای firebase deploy --only functions بازگشایی کنید.)

در جایی که پاسخگویی بلادرنگ اهمیت کمتری دارد، ساختار به صورت تدافعی عمل می کند

اگر نیازی به ارائه نتیجه یک تابع در زمان واقعی ندارید، می‌توانید با پردازش نتایج به صورت دسته‌ای، ترافیک سوءاستفاده‌کننده را کاهش دهید: نتایج را در یک موضوع Pub/Sub منتشر کنید و نتایج را در فواصل زمانی منظم با یک تابع زمان‌بندی شده پردازش کنید. .

کلیدهای API را درک کنید

کلیدهای API برای خدمات Firebase مخفی نیستند

Firebase از کلیدهای API فقط برای شناسایی پروژه Firebase برنامه شما به سرویس‌های Firebase استفاده می‌کند و نه برای کنترل دسترسی به پایگاه داده یا داده‌های Cloud Storage، که با استفاده از قوانین امنیتی Firebase انجام می‌شود. به همین دلیل، نیازی نیست که کلیدهای API برای سرویس های Firebase را به عنوان راز تلقی کنید و می توانید با خیال راحت آنها را در کد مشتری جاسازی کنید. درباره کلیدهای API برای Firebase بیشتر بیاموزید.

محدوده کلید API را تنظیم کنید

به عنوان یک عامل بازدارنده اضافی در برابر مهاجمی که تلاش می‌کند از کلید API شما برای جعل درخواست‌ها استفاده کند، می‌توانید کلیدهای API را در محدوده مشتریان برنامه خود ایجاد کنید.

کلیدهای سرور FCM را مخفی نگه دارید

برخلاف کلیدهای API برای سرویس‌های Firebase، کلیدهای سرور FCM (که توسط API قدیمی FCM HTTP استفاده می‌شود) حساس هستند و باید مخفی نگه داشته شوند.

کلیدهای حساب سرویس را مخفی نگه دارید

همچنین برخلاف کلیدهای API برای سرویس‌های Firebase، کلیدهای خصوصی حساب سرویس (که توسط Admin SDK استفاده می‌شود) حساس هستند و باید مخفی نگه‌داشته شوند.

قوانین امنیتی

قوانین را در حالت تولید یا قفل راه اندازی کنید

هنگامی که Cloud Firestore، پایگاه داده بیدرنگ و Cloud Storage را راه‌اندازی می‌کنید، قوانین امنیتی خود را راه‌اندازی کنید تا به طور پیش‌فرض همه دسترسی‌ها را رد کنید، و قوانینی را اضافه کنید که به منابع خاصی در حین توسعه برنامه خود دسترسی پیدا می‌کنند.

این یکی از تنظیمات پیش‌فرض برای نمونه‌های جدید Cloud Firestore (حالت تولید) و پایگاه داده بیدرنگ (حالت قفل) است. هنگام تنظیم یک نمونه پایگاه داده جدید، این گزینه را انتخاب کنید.

برای 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 و پایگاه داده بیدرنگ ببینید.

احراز هویت

احراز هویت سفارشی: JWT ها را از یک محیط قابل اعتماد (سمت سرور) برش دهید

اگر قبلاً یک سیستم ورود به سیستم امن دارید، چه یک سیستم سفارشی یا یک سرویس شخص ثالث، می‌توانید از سیستم موجود خود برای احراز هویت با خدمات Firebase استفاده کنید. JWT های سفارشی را از یک محیط قابل اعتماد ایجاد کنید ، سپس توکن ها را به مشتری خود منتقل کنید، که از توکن برای احراز هویت استفاده می کند ( iOS+ ، Android ، Web ، Unity ، C++ ).

برای مثالی از استفاده از احراز هویت سفارشی با ارائه‌دهنده شخص ثالث، به پست وبلاگ، احراز هویت با Firebase با استفاده از Okta مراجعه کنید.

احراز هویت مدیریت شده: ارائه دهندگان OAuth 2.0 امن ترین هستند

اگر از ویژگی‌های احراز هویت مدیریت شده Firebase استفاده می‌کنید، گزینه‌های ارائه‌دهنده OAuth 2.0 / OpenID Connect (Google، Facebook، و غیره) ایمن‌ترین گزینه‌ها هستند. اگر می توانید (بسته به پایگاه کاربری خود) باید از یک یا چند مورد از این ارائه دهندگان پشتیبانی کنید.

احراز هویت رمز عبور ایمیل: برای جلوگیری از حملات brute force، سهمیه محدودی را برای نقطه پایانی ورود به سیستم تعیین کنید.

اگر از سرویس احراز هویت گذرواژه ایمیل مدیریت شده Firebase استفاده می‌کنید، سهمیه پیش‌فرض نقاط انتهایی identitytoolkit.googleapis.com را سفت کنید تا از حملات brute force جلوگیری کنید. می توانید این کار را از صفحه API در کنسول Google Cloud انجام دهید.

احراز هویت با رمز عبور ایمیل: حفاظت از شمارش ایمیل را فعال کنید

اگر از سرویس احراز هویت رمز عبور ایمیل مدیریت شده Firebase استفاده می‌کنید، محافظت از شمارش ایمیل را فعال کنید ، که از سوء استفاده عوامل مخرب از نقاط پایانی تأیید پروژه شما برای حدس زدن نام حساب‌ها جلوگیری می‌کند.

برای احراز هویت چند عاملی به پلتفرم Cloud Identity ارتقا دهید

برای امنیت بیشتر در ورود به سیستم، می‌توانید با ارتقا به پلتفرم Cloud Identity، پشتیبانی از احراز هویت چند مرحله‌ای را اضافه کنید. کد احراز هویت Firebase موجود شما پس از ارتقاء به کار خود ادامه خواهد داد.

احراز هویت ناشناس

فقط از احراز هویت ناشناس برای ورود گرم استفاده کنید

فقط از احراز هویت ناشناس برای ذخیره وضعیت اولیه برای کاربران قبل از ورود به سیستم استفاده کنید. احراز هویت ناشناس جایگزینی برای ورود به سیستم کاربر نیست.

اگر کاربران در صورت گم شدن تلفن خود به داده ها نیاز دارند، آنها را به روش دیگری برای ورود به سیستم تبدیل کنید

اگر کاربر فضای ذخیره‌سازی محلی را پاک کند یا دستگاه‌ها را تغییر دهد، داده‌های احراز هویت ناشناس باقی نمی‌مانند. اگر نیاز دارید که داده‌ها را فراتر از راه‌اندازی مجدد برنامه در یک دستگاه نگه دارید، کاربر را به یک حساب دائمی تبدیل کنید .

از قوانین امنیتی استفاده کنید که کاربران را ملزم می کند به ارائه دهنده ورود به سیستم تبدیل شده یا ایمیل خود را تأیید کرده باشند

هر کسی می تواند یک حساب کاربری ناشناس در پروژه شما ایجاد کند. با در نظر گرفتن این موضوع، از همه داده‌های غیر عمومی با قوانین امنیتی محافظت کنید که به روش‌های ورود به سیستم یا آدرس‌های ایمیل تأیید شده نیاز دارند .

مثلا:

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

مدیریت محیط زیست

راه اندازی پروژه های توسعه و مرحله بندی

پروژه های Firebase جداگانه برای توسعه، مرحله بندی و تولید راه اندازی کنید. کد مشتری را تا زمانی که در برابر پروژه مرحله‌بندی آزمایش نشده است با تولید ادغام نکنید.

دسترسی تیم به داده های تولید را محدود کنید

اگر با تیم بزرگ‌تری کار می‌کنید، می‌توانید با محدود کردن دسترسی به داده‌های تولید با استفاده از نقش‌های از پیش تعریف‌شده یا نقش‌های سفارشی IAM، پیامدهای اشتباهات و نقض‌ها را کاهش دهید.

اگر تیم شما از مجموعه شبیه ساز برای توسعه استفاده می کند، ممکن است نیازی به اجازه دسترسی گسترده تر به پروژه تولید نداشته باشید.

مدیریت کتابخانه

مراقب غلط املایی کتابخانه یا نگهدارنده های جدید باشید

هنگام افزودن کتابخانه ها به پروژه خود، به نام کتابخانه و نگهبانان آن توجه زیادی داشته باشید. کتابخانه ای با نام مشابه با کتابخانه ای که قصد نصب آن را دارید می تواند حاوی کدهای مخرب باشد.

بدون درک تغییرات، کتابخانه ها را به روز نکنید

قبل از ارتقا، به گزارش تغییرات کتابخانه‌هایی که استفاده می‌کنید نگاه کنید. مطمئن شوید که ارتقاء ارزش اضافه می‌کند و بررسی کنید که نگهدارنده هنوز طرف مورد اعتماد شما باشد.

کتابخانه‌های Watchdog را به‌عنوان برنامه‌نویس یا وابستگی آزمایشی نصب کنید

از کتابخانه ای مانند Snyk برای بررسی وابستگی های ناامن پروژه خود استفاده کنید.

تنظیم نظارت برای توابع. پس از به روز رسانی کتابخانه آن را بررسی کنید

اگر از Cloud Functions Logger SDK استفاده می‌کنید، می‌توانید رفتار غیرعادی، از جمله رفتارهای ناشی از به‌روزرسانی‌های کتابخانه را کنترل کنید و از آن مطلع شوید .

ایمنی عملکرد ابر

هرگز اطلاعات حساس را در متغیرهای محیطی Cloud Function قرار ندهید

اغلب در یک برنامه Node.js خود میزبان، از متغیرهای محیطی برای حاوی اطلاعات حساس مانند کلیدهای خصوصی استفاده می کنید. این کار را در Cloud Functions انجام ندهید . از آنجایی که Cloud Functions از محیط‌ها بین فراخوانی‌های تابع استفاده مجدد می‌کند، اطلاعات حساس نباید در محیط ذخیره شوند.

  • برای ذخیره کلیدهای Firebase API که مخفی نیستند ، کافی است آنها را در کد جاسازی کنید.
  • اگر از Firebase Admin SDK در یک عملکرد Cloud استفاده می‌کنید، نیازی به ارائه صریح اعتبار حساب سرویس ندارید، زیرا SDK می‌تواند به‌طور خودکار آنها را در طول اولیه‌سازی به دست آورد.
  • اگر با Google و Google Cloud APIهایی تماس می‌گیرید که به اعتبار حساب سرویس نیاز دارند، کتابخانه Google Auth برای Node.js می‌تواند این اعتبارنامه‌ها را از اعتبارنامه‌های پیش‌فرض برنامه دریافت کند، که به‌طور خودکار در توابع Cloud پر می‌شوند.
  • برای در دسترس قرار دادن کلیدهای خصوصی و اعتبارنامه‌های سرویس‌های غیر Google در Cloud Functions، از Cloud Secret Manager استفاده کنید.

رمزگذاری اطلاعات حساس

اگر نمی‌توانید از ارسال اطلاعات حساس به Cloud Function خود اجتناب کنید، باید راه‌حل سفارشی خود را برای رمزگذاری اطلاعات ارائه دهید.

توابع ساده ایمن تر هستند. اگر به پیچیدگی نیاز دارید، Cloud Run را در نظر بگیرید

سعی کنید تا حد امکان عملکردهای ابری خود را ساده و قابل فهم نگه دارید. پیچیدگی در عملکردهای شما اغلب می تواند منجر به اشکالات یا رفتار غیرمنتظره شود.

اگر به تنظیمات پیچیده منطقی یا محیطی نیاز دارید، از Cloud Run به جای Cloud Functions استفاده کنید.