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

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

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

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

ในการตรวจสอบการจราจรที่ไม่เหมาะสมเช่น (DOS) การโจมตีการปฏิเสธการให้บริการ, การตั้งค่าการตรวจสอบและแจ้งเตือนสำหรับ เมฆ FireStore , เรียลไทม์ฐานข้อมูล , การจัดเก็บเมฆ และ โฮสติ้ง

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

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

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

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

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

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

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

ป้องกัน self-DOS: ทดสอบฟังก์ชันภายในเครื่องด้วยอีมูเลเตอร์

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

(และถ้าคุณทำบังเอิญ DOS ตัวเอง undeploy ฟังก์ชั่นของคุณโดยการถอดออกจาก index.js แล้ววิ่ง firebase deploy --only functions .)

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

หากคุณไม่ต้องการที่จะนำเสนอผลของการทำงานในเวลาจริงที่คุณสามารถลดกับการจราจรที่ไม่เหมาะสมโดยการประมวลผลผลใน batches นี้: เผยแพร่ผลไปยัง ผับ / ตำบล หัวข้อและประมวลผลในช่วงเวลาปกติที่มี ฟังก์ชั่นที่กำหนดไว้ .

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

คีย์ API สำหรับบริการ Firebase ไม่เป็นความลับ

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

ตั้งค่าการกำหนดขอบเขตคีย์ API

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

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

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

เก็บกุญแจบัญชีบริการไว้เป็นความลับ

นอกจากนี้ยังแตกต่างจากปุ่ม API สำหรับบริการ Firebase, บริการบัญชีคีย์ส่วนตัว (ที่ใช้โดย ผู้ดูแลระบบ 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 ของคุณ ดูคำแนะนำเหล่านี้สำหรับ ระบบคลาวด์ FireStore และ เรียลไทม์ฐานข้อมูล

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

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

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

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

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

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

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

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

อัปเกรดเป็น Cloud Identity Platform สำหรับการตรวจสอบสิทธิ์แบบหลายปัจจัย

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

การตรวจสอบแบบไม่ระบุชื่อ

ใช้การพิสูจน์ตัวตนแบบไม่ระบุตัวตนเท่านั้นสำหรับการเริ่มต้นใช้งานอย่างอบอุ่น

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

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

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

ใช้กฎความปลอดภัยที่กำหนดให้ผู้ใช้ต้องแปลงเป็นผู้ให้บริการลงชื่อเข้าใช้หรือยืนยันอีเมลแล้ว

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

ตัวอย่างเช่น:

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

การจัดการสิ่งแวดล้อม

ตั้งโครงการพัฒนาและจัดฉาก

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

จำกัดการเข้าถึงข้อมูลการผลิตของทีม

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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