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

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

หลีกเลี่ยงการจราจรที่ไม่เหมาะสม

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

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

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

เปิดใช้งานการตรวจสอบแอป

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

กำหนดค่า Cloud Functions ของคุณเพื่อปรับขนาดสำหรับการรับส่งข้อมูลปกติ

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

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

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

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

การทำ DOS เองโดยไม่ตั้งใจอาจเป็นเรื่องง่ายในขณะที่พัฒนา Cloud Functions: ตัวอย่างเช่น โดยการสร้างทริกเกอร์-เขียนลูปแบบไม่จำกัด คุณสามารถป้องกันข้อผิดพลาดเหล่านี้ไม่ให้ส่งผลกระทบต่อบริการที่ใช้งานอยู่ได้โดยทำการพัฒนาด้วย ชุดโปรแกรมจำลอง 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 (ใช้โดย FCM HTTP API เดิม ) นั้น ละเอียดอ่อนและต้องเก็บเป็นความลับ

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

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

กฎความปลอดภัย

เริ่มต้นกฎในโหมดใช้งานจริงหรือล็อก

เมื่อคุณตั้งค่า Cloud Firestore, Realtime Database และ 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 และ Realtime Database

การรับรองความถูกต้อง

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

หากคุณมีระบบการลงชื่อเข้าใช้ที่ปลอดภัยอยู่แล้ว ไม่ว่าจะเป็นระบบแบบกำหนดเองหรือบริการของบุคคลที่สาม คุณสามารถใช้ระบบที่มีอยู่เพื่อตรวจสอบสิทธิ์กับบริการ Firebase สร้าง JWT แบบกำหนดเอง จากสภาพแวดล้อมที่เชื่อถือได้ จากนั้นส่งโทเค็นไปยังไคลเอนต์ของคุณ ซึ่งใช้โทเค็นเพื่อตรวจสอบสิทธิ์ ( 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 ที่กำหนดเอง

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

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

ระวังการสะกดผิดของห้องสมุดหรือผู้ดูแลใหม่

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

อย่าอัปเดตไลบรารีโดยไม่เข้าใจการเปลี่ยนแปลง

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

ติดตั้งไลบรารี watchdog เป็นการพึ่งพา dev หรือการทดสอบ

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

ตั้งค่าการตรวจสอบสำหรับฟังก์ชัน ตรวจสอบหลังจากการปรับปรุงห้องสมุด

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

ความปลอดภัยของฟังก์ชั่นคลาวด์

อย่าใส่ข้อมูลที่ละเอียดอ่อนในตัวแปรสภาพแวดล้อมของ Cloud Function

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

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

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

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

ฟังก์ชั่นง่าย ๆ นั้นปลอดภัยกว่า หากคุณต้องการความซับซ้อน ลองพิจารณา Cloud Run

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

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