รายการตรวจสอบความปลอดภัยของ Firebase

หากต้องการเก็บทรัพยากรของ Firebase และผู้ใช้ของคุณ รักษาความปลอดภัยข้อมูล, ทำตาม หลักเกณฑ์ บางรายการอาจใช้ไม่ได้กับข้อกำหนดของคุณ แต่ให้ใช้ ขณะพัฒนาแอป

หลีกเลี่ยงการเข้าชมที่ละเมิด

ตั้งค่าการตรวจสอบและการแจ้งเตือนสำหรับบริการแบ็กเอนด์

หากต้องการตรวจหาการเข้าชมที่ละเมิด เช่น การโจมตีแบบปฏิเสธการให้บริการ (DOS) ให้ตั้งค่า การตรวจสอบและการแจ้งเตือนสำหรับ Cloud Firestore Realtime Database, Cloud Storage และ Hosting

หากคุณสงสัยว่ามีการโจมตีแอปพลิเคชัน โปรดติดต่อทีมสนับสนุนโดยเร็วที่สุดเพื่อ บอกให้พวกเขารู้ว่าเกิดอะไรขึ้น

เปิดใช้ App Check

เพื่อให้มั่นใจว่าจะมีเฉพาะแอปของคุณเท่านั้นที่เข้าถึงบริการแบ็กเอนด์ได้ ให้เปิดใช้ Firebase App Check สำหรับทุกบริการที่รองรับ

��ำหนดค่า Cloud Functions เพื่อปรับขนาดสำหรับการเข้าชมปกติ

Cloud Functions จะปรับขนาดให้ตรงกับความต้องการของแอปโดยอัตโนมัติ แต่ใน การโจมตีนี้อาจหมายถึง การเรียกเก็บเงินขนาดใหญ่ เพื่อป้องกันไม่ให้เกิดเหตุการณ์ดังกล่าว คุณสามารถ จำกัดจำนวนอินสแตนซ์ที่ทำงานพร้อมกัน ของฟังก์ชันตามการเข้าชมปกติของแอป

ตั้งค่าการแจ้งเตือนเมื่อใกล้ถึงขีดจํากัด

หากบริการของคุณมีคำขอเพิ่มขึ้นอย่างฉับพลัน โควต้ามักจะเริ่มทำงานโดยอัตโนมัติ ควบคุมการเข้าชมแอปพลิเคชันของคุณ อย่าลืมตรวจสอบ แดชบอร์ดการใช้งานและการเรียกเก็บเงิน แต่คุณยังสามารถ ตั้งการแจ้งเตือนงบประมาณ ในโปรเจ็กต์ของคุณเพื่อรับการแจ้งเตือนเมื่อการใช้ทรัพยากรเกินความคาดหมาย

ป้องกันการใช้เอง: ทดสอบฟังก์ชันในเครื่องด้วยโปรแกรมจำลอง

การ DOS ด้วยตนเองโดยไม่ได้ตั้งใจอาจเป็นเรื่องง่ายในระหว่างการพัฒนา Cloud Functions: เช่น การสร้างลูปการเขียนทริกเกอร์แบบไม่จำกัด คุณสามารถป้องกันไม่ให้ข้อผิดพลาดเหล่านี้ส่งผลกระทบต่อบริการที่ทำงานอยู่ได้โดยดำเนินการ ด้วย Firebase Local Emulator Suite

และหากคุณเผลอทำ DOS ด้วยตนเอง ให้ยกเลิกการทำให้ฟังก์ชันใช้งานได้โดยการลบฟังก์ชัน จาก index.js จากนั้นจึงเรียกใช้ firebase deploy --only functions

เมื่อการตอบสนองแบบเรียลไทม์ไม่สำคัญนัก โครงสร้างจะทำหน้าที่ในการปกป้อง

หากไม่ต้องการแสดงผลลัพธ์ของฟังก์ชันแบบเรียลไทม์ ให้ทําดังนี้ ลดการเข้าชมที่มีการละเมิดโดยการประมวลผลผลลัพธ์เป็นกลุ่ม: เผยแพร่ ผลลัพธ์เป็น Pub/Sub หัวข้อ และประมวลผลผลลัพธ์ในรอบระยะเวลาที่สม่ำเสมอด้วย ฟังก์ชันที่กำหนดเวลาไว้

ทำความเข้าใจคีย์ API

คีย์ API สำหรับบริการ Firebase ไม่ใช่ข้อมูลลับ

Firebase ใช้คีย์ API เพื่อระบุโปรเจ็กต์ Firebase ของแอปไปยัง Firebase เท่านั้น บริการ และไม่ใช่การควบคุมการเข้าถึงฐานข้อมูลหรือข้อมูล Cloud Storage ซึ่งเป็น ดำเนินการโดยใช้ Firebase Security Rules ด้วยเหตุนี้ คุณไม่จำเป็นต้อง จัดการคีย์ API สำหรับบริการ Firebase เป็นความลับและคุณฝังคีย์เหล่านั้นได้อย่างปลอดภัย ในรหัสไคลเอ็นต์ ดูข้อมูลเพิ่มเติมเกี่ยวกับ คีย์ API สำหรับ Firebase

ตั้งค่าข้อจำกัดของคีย์ API

เพื่อเป็นการป้องกันเพิ่มเติมสำหรับผู้โจมตีที่พยายามใช้คีย์ API ของคุณเพื่อ คำขอปลอมแปลง คุณสามารถเพิ่ม ข้อจำกัดของคีย์ API เพื่อกำหนดขอบเขตคีย์ API เป็นไคลเอ็นต์ของแอปและ API ที่คุณใช้

เก็บคีย์เซิร์ฟเวอร์ FCM คีย์ไว้เป็นความลับ

ซึ่งต่างจากคีย์ API สำหรับบริการ Firebase ตรงที่คีย์เซิร์ฟเวอร์ FCM รายการ (ใช้โดย HTTP API เดิมFCM) มีข้อมูลที่ละเอียดอ่อนและต้องเก็บเป็นความลับ

เก็บคีย์บัญชีบริการไว้เป็นความลับ

ซึ่งต่างจากคีย์ API สำหรับบริการ Firebase ตรงที่คีย์ส่วนตัวของบัญชีบริการ (มือสอง) โดย Firebase Admin SDK) มีความละเอียดอ่อน และต้องเก็บไว้เป็นความลับ

Firebase Security Rules

เริ่มต้นกฎในเวอร์ชันที่ใช้งานจริงหรือโหมดล็อกขณะคุมสอบ

เมื่อตั้งค่า 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;
    }
  }
}

กฎความปลอดภัยเป็นสคีมา เพิ่มกฎเมื่อเพิ่มเอกสาร

ห้ามเขียนกฎความปลอดภัยหลังจากที่เขียนแอป เพื่อเป็นการทดสอบก่อนการเปิดตัว งาน แต่ให้เขียนกฎความปลอดภัยขณะที่เขียนแอปแทน โดยปฏิบัติเหมือน สคีมาฐานข้อมูล: เมื่อใดก็ตามที่คุณต้องใช้ ประเภทเอกสารหรือโครงสร้างเส้นทางใหม่ ให้เขียนกฎความปลอดภัยก่อน

ทดสอบกฎความปลอดภัยในหน่วยด้วย Local Emulator Suite เพิ่มลงใน CI

เพื่อให้มั่นใจว่ากฎความปลอดภัยของคุณสอดคล้องกับการพัฒนาแอป ให้ทดสอบกฎของคุณด้วย Firebase Local Emulator Suite แล้วเพิ่มการทดสอบเหล่านี้ลงในไปป์ไลน์ CI ดูคำแนะนำเ��ล่านี้สำหรับ Cloud Firestore และ Realtime Database

การตรวจสอบสิทธิ์

การตรวจสอบสิทธิ์ที่กำหนดเอง: Mint JWT จากสภาพแวดล้อม (ฝั่งเซิร์ฟเวอร์) ที่เชื่อถือได้

หากคุณมีระบบการลงชื่อเข้าใช้ที่ปลอดภัยอยู่แล้ว ไม่ว่าจะเป็นระบบที่กำหนดเอง ของบุคคลที่สาม คุณสามารถใช้ระบบที่มีอยู่เพื่อตรวจสอบสิทธิ์กับ Firebase ทั้งหมด สร้าง JWT ที่กำหนดเอง จากสภาพแวดล้อมที่เชื่อถือได้ แล้วส่งโทเค็นไปให้ไคลเอ็นต์ของคุณ ซึ่งใช้ โทเค็นเพื่อตรวจสอบสิทธิ์ (iOS+, Android, เว็บ, Unity, C++)

โปรดดูตัวอย่างการใช้การตรวจสอบสิทธิ์ที่กำหนดเองกับผู้ให้บริการบุคคลที่สามที่ บล็อกโพสต์ ตรวจสอบสิทธิ์ด้วย Firebase โดยใช้ Okta

การตรวจสอบสิทธิ์ที่มีการจัดการ: ผู้ให้บริการ OAuth 2.0 คือความปลอดภัยมากที่สุด

หากใช้ฟีเจอร์การตรวจสอบสิทธิ์ที่มีการจัดการของ Firebase จะมีการใช้ OAuth 2.0 / OpenID ตัวเลือก Connect Provider (Google, Facebook ฯลฯ) คือตัวเลือกที่ปลอดภัยที่สุด คุณ ควรรองรับผู้ให้บริการเหล่านี้อย่างน้อย 1 รายหากทำได้ (ทั้งนี้ขึ้นอยู่กับผู้ใช้ ฐาน)

การตรวจสอบสิทธิ์ทางอีเมลด้วยรหัสผ่าน: กำหนดโควต้าที่แน่นอนสำหรับปลายทางการลงชื่อเข้าใช้เพื่อป้องกันการโจมตีแบบบรูตฟอร์ซ

หากคุณใช้บริการการตรวจสอบสิทธิ์อีเมลรหัสผ่านที่มีการจัดการของ Firebase ให้กระชับ โควต้าเริ่มต้นของอุปกรณ์ปลายทาง identitytoolkit.googleapis.com เครื่องเพื่อป้องกันบรูต การโจมตีแบบบังคับ คุณสามารถทำได้จาก หน้า Identity Toolkit API ในคอนโซล Google Cloud

การตรวจสอบสิทธิ์อีเมลด้วยรหัสผ่าน: เปิดใช้การป้องกันการนับอีเมล

หากคุณใช้บริการตรวจสอบสิทธิ์อีเมล-รหัสผ่านที่มีการจัดการของ 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 (ซึ่งไม่ใช่ข้อมูลลับ) เพียงฝังโค้ดไว้ในโค้ด

• หากคุณใช้ Firebase Admin SDK ใน Cloud Functions คุณไม่จำเป็นต้อง ระบุข้อมูลเข้าสู่ระบบบัญชีบริการอย่างชัดเจน เนื่องจากAdmin SDK จะได้รับเมตริกเหล่านั้นโดยอัตโนมัติระหว่างการเริ่มต้น

• หากคุณเรียกใช้ Google และ API ของ Google Cloud ที่ต้องใช้บัญชีบริการ ข้อมูลเข้าสู่ระบบ ไลบรารีการตรวจสอบสิทธิ์ของ Google สำหรับ Node.js สามารถรับข้อมูลเข้าสู่ระบบเหล่านี้ได้ จาก ข้อมูลเข้าสู่ระบบเริ่มต้นของแอปพลิเคชัน ซึ่งจะสร้างโดยอัตโนมัติใน Cloud Functions

• หากต้องการให้คีย์ส่วนตัวและข้อมูลเข้าสู่ระบบสำหรับบริการที่ไม่ใช่ของ Google พร้อมใช้งานสำหรับ Cloud Functions ใช้ Secret Manager

เข้ารหัสข้อมูลที่ละเอียดอ่อน

หากคุณไม่สามารถหลีกเลี่ยงการส่งข้อมูลที่ละเอียดอ่อนไปยังฟังก์ชันของคุณได้ คุณต้อง ก็สร้างโซลูชันที่กำหนดเองเพื่อเข้ารหัสข้อมูลได้

ฟังก์ชันที่เรียบง่ายมีความปลอดภัยกว่า ถ้าต้องการความซับซ้อน โปรดพิจารณา Cloud Run

พยายามทำให้ฟังก์ชันของคุณเรียบง่ายและเข้าใจได้ง่ายที่สุด ความซับซ้อน ในหน้าที่ต่างๆ ของคุณ มักนำไปสู่ข้อบกพร่องที่ค้นพบได้ยาก หรือการทำงานที่ไม่คาดคิด

หากคุณต้องใช้ตรรกะหรือการกำหนดค่าสภาพแวดล้อมที่ซับซ้อน ให้พิจารณาใช้ Cloud Run แทนที่จะเป็น Cloud Functions

การจัดการสภาพแวดล้อม

ตั้งค่าโปรเจ็กต์การพัฒนาและการทดลองใช้

สร้างโปรเจ็กต์ Firebase แยกต่างหากสำหรับการพัฒนา การทดลองใช้ และเวอร์ชันที่ใช้งานจริง อย่าผสานโค้ดไคลเอ็นต์กับเวอร์ชันที่ใช้งานจริงจนกว่าจะได้รับการทดสอบกับการทดลองใช้

จำกัดการเข้าถึงข้อมูลเวอร์ชันที่ใช้งานจริงของทีม

หากทำงานร่วมกับทีมขนาดใหญ่ คุณก็ลดผลกระทบจากความผิดพลาดลงได้ และการละเมิดด้วยการจำกัดการเข้าถึงข้อมูลที่ใช้งานจริงโดยใช้ บทบาท IAM ที่กำหนดไว้ล่วงหน้า หรือ บทบาท IAM ที่กำหนดเอง

หากทีมของคุณใช้Firebase Local Emulator Suite (แนะนำ) สำหรับการพัฒนา คุณอาจไม่จำเป็นต้องให้สิทธิ์เข้าถึงแบบกว้างสำหรับ สำหรับโครงการที่ใช้งานจริง

การจัดการห้องสมุด

ระวังการสะกดผิดหรือมีผู้บำรุงรักษารายใหม่ในคลัง

เมื่อเพิ่มไลบรารีลงในโปรเจ็กต์ ควรให้ความสำคัญกับชื่อของไลบรารี ห้องสมุดและผู้บำรุงรักษา ไลบรารีที่มีชื่อคล้ายกับชื่อที่คุณต้องการ การติดตั้งอาจมีโค้ดที่เป็นอันตราย

ไม่อัปเดตไลบรารีหากไม่ทราบการเปลี่ยนแปลง

ดูบันท��กการเปลี่ยนแปลงของไลบรารีที่ใช้ก่อนอัปเกรด ตรวจสอบให้แน่ใจว่า การอัปเกรดเป็นการเพิ่มมูลค่า และตรวจสอบว่าผู้บำรุงรักษายังคงเป็นตัวคุณเอง ความน่าเชื่อถือ

ติดตั้งไลบรารี Watchdog เป็น Dependency หรือทดสอบ

ใช้ไลบรารี เช่น Snyk เพื่อสแกนโปรเจ็กต์ สำหรับการขึ้นต่อกันที่ไม่ปลอดภัย

ตั้งค่าการตรวจสอบสำหรับ Cloud Functions ตรวจสอบหลังจากอัปเดตห้องสมุด

หากคุณใช้แท็ก Cloud Functions Logger SDK จากนั้น คุณสามารถ ตรวจสอบและรับการแจ้งเตือน ที่มีลักษณะการทำงานที่ผิดปกติ รวมถึงการทำงานที่เกิดจากการอัปเดตไลบรารี