برای ایمن نگه داشتن منابع Firebase و داده های کاربران، این دستورالعمل ها را دنبال کنید. لزوماً هر موردی برای نیازهای شما اعمال نمی شود، اما هنگام توسعه برنامه خود آنها را در نظر داشته باشید.
از تردد نادرست خودداری کنید
نظارت و هشدار را برای خدمات باطن تنظیم کنید
برای شناسایی ترافیک سوءاستفادهکننده، مانند حملات انکار سرویس (DOS)، نظارت و هشدار را برای Cloud Firestore ، پایگاه داده بیدرنگ ، فضای ذخیرهسازی ابری و میزبانی تنظیم کنید.
اگر مشکوک به حمله به برنامه خود هستید، در اسرع وقت با پشتیبانی تماس بگیرید تا به آنها اطلاع دهید که چه اتفاقی می افتد.
بررسی برنامه را فعال کنید
برای اطمینان از اینکه فقط برنامههای شما میتوانند به خدمات پشتیبان شما دسترسی داشته باشند، بررسی برنامه را برای هر سرویسی که از آن پشتیبانی میکند فعال کنید.
توابع Cloud خود را به گونهای پیکربندی کنید که برای ترافیک عادی مقیاس شوند
Cloud Functions به طور خودکار برای برآورده کردن خواسته های برنامه شما مقیاس می شود، اما در صورت حمله، این می تواند به معنای یک صورت حساب بزرگ باشد. برای جلوگیری از این امر، می توانید تعداد نمونه های همزمان یک تابع را بر اساس ترافیک عادی برنامه خود محدود کنید.
هشدار را تنظیم کنید تا در صورت نزدیک شدن به محدودیت ها به شما اطلاع داده شود
اگر سرویس شما افزایش درخواست داشته باشد، اغلب سهمیه ها وارد می شوند و به طور خودکار ترافیک را به برنامه شما کاهش می دهند. مطمئن شوید که داشبورد استفاده و صورتحساب خود را کنترل میکنید، اما همچنین میتوانید هشدارهای بودجه را برای پروژه خود تنظیم کنید تا زمانی که استفاده از منابع بیش از حد انتظار است به آنها اطلاع داده شود.
جلوگیری از self-DOS: عملکردها را به صورت محلی با شبیه سازها آزمایش کنید
در حین توسعه توابع ابری، میتوان به راحتی خود را به طور تصادفی DOS کرد: برای مثال، با ایجاد یک حلقه نوشتن نامحدود. شما می توانید با انجام برنامه توسعه خود با مجموعه شبیه ساز Firebase از تأثیر این اشتباهات بر خدمات زنده جلوگیری کنید.
(و اگر خودتان به طور تصادفی DOS انجام دادید، تابع خود را با حذف آن از index.js
و سپس اجرای
، undeploy کنید.)
در جایی که پاسخگویی بلادرنگ اهمیت کمتری دارد، ساختار به صورت تدافعی عمل می کند
اگر نیازی به ارائه نتیجه یک تابع در زمان واقعی ندارید، میتوانید با پردازش نتایج به صورت دستهای، ترافیک سوءاستفادهکننده را کاهش دهید: نتایج را در یک موضوع 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
شناسهای.googleapis.com را محدود کنید تا از حملات brute force جلوگیری کنید. میتوانید این کار را از صفحه API در Google Cloud Console انجام دهید.
برای احراز هویت چند عاملی به پلتفرم 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 Functions از Cloud Run استفاده کنید.