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

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

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

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

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

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

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

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

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

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

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

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

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

การทำ 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 ไว้เป็นความลับ

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

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

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

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

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

เมื่อคุณตั้งค่า 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 ให้แน่นขึ้น เพื่อป้องกันการโจมตีแบบ Brute Force คุณสามารถทำได้จาก หน้าของ 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 แบบกำหนดเอง

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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