หากต้องการรักษาทรัพยากร Firebase และข้อมูลผู้ใช้ของคุณให้ปลอดภัย ให้ปฏิบัติตามหลักเกณฑ์เหล่านี้ ไม่ใช่ว่าทุกรายการจะใช้ได้กับความต้องการของคุณ แต่โปรดระลึกไว้เสมอว่าเมื่อคุณพัฒนาแอปของคุณ
หลีกเลี่ยงการจราจรที่ไม่เหมาะสม
ตั้งค่าการตรวจสอบและแจ้งเตือนสำหรับบริการแบ็กเอนด์
เพื่อตรวจจับการรับส่งข้อมูลที่ไม่เหมาะสม เช่น การโจมตีโดยปฏิเสธการให้บริการ (DOS) ตั้งค่าการตรวจสอบและแจ้งเตือนสำหรับ Cloud Firestore , Realtime Database , Cloud Storage และ Hosting
หากคุณสงสัยว่ามีการโจมตีแอปพลิเคชันของคุณ โปรด ติดต่อฝ่ายสนับสนุน โดยเร็วที่สุดเพื่อแจ้งให้ทราบว่าเกิดอะไรขึ้น
เปิดใช้งานการตรวจสอบแอป
เพื่อช่วยให้มั่นใจว่ามีเพียงแอพของคุณเท่านั้นที่สามารถเข้าถึงบริการแบ็กเอนด์ของคุณได้ ให้เปิดใช้งาน App Check สำหรับทุกบริการที่รองรับ
กำหนดค่า Cloud Functions ของคุณเพื่อปรับขนาดสำหรับการรับส่งข้อมูลปกติ
Cloud Functions จะปรับขนาดโดยอัตโนมัติเพื่อตอบสนองความต้องการของแอปของคุณ แต่ในกรณีที่มีการโจมตี นี่อาจหมายถึงการเรียกเก็บเงินจำนวนมาก เพื่อป้องกันสิ่งนี้ คุณสามารถ จำกัดจำนวนอินสแตนซ์ของฟังก์ชันที่เกิดขึ้นพร้อมกัน โดยพิจารณาจากการรับส่งข้อมูลปกติสำหรับแอปของคุณ
ตั้งค่าแจ้งเตือนเมื่อใกล้ถึงขีดจำกัด
หากบริการของคุณมีคำขอเพิ่มขึ้น โควตามักจะเริ่มทำงาน และจะควบคุมปริมาณการใช้งานแอปพลิเคชันของคุณโดยอัตโนมัติ ตรวจสอบให้แน่ใจว่าได้ตรวจสอบ แดชบอร์ดการใช้งานและการเรียกเก็บเงิน ของคุณ แต่คุณยังสามารถ ตั้งค่าการแจ้งเตือนงบประมาณ ในโครงการของคุณเพื่อรับการแจ้งเตือนเมื่อการใช้ทรัพยากรเกินความคาดหมาย
ป้องกัน self-DOS: ทดสอบฟังก์ชันภายในเครื่องด้วยโปรแกรมจำลอง
การทำ DOS ด้วยตัวเองโดยไม่ได้ตั้งใจทำได้ง่ายในขณะพัฒนา Cloud Functions: ตัวอย่างเช่น โดยการสร้างลูปทริกเกอร์-เขียนแบบไม่จำกัด คุณสามารถป้องกันข้อผิดพลาดเหล่านี้ไม่ให้ส่งผลกระทบต่อบริการที่ใช้งานจริงโดยดำเนินการพัฒนาด้วย ชุดโปรแกรมจำลอง Firebase
(และถ้าคุณทำ DOS ด้วยตัวเองโดยไม่ได้ตั้งใจ ให้ยกเลิกการปรับใช้ฟังก์ชันของคุณโดยลบออกจาก index.js
จากนั้นเรียกใช้
)
เมื่อการตอบสนองแบบเรียลไทม์มีความสำคัญน้อยกว่า โครงสร้างก็ทำหน้าที่ป้องกัน
หากคุณไม่ต้องการนำเสนอผลลัพธ์ของฟังก์ชันแบบเรียลไทม์ คุณสามารถบรรเทาการรับส่งข้อมูลที่ไม่เหมาะสมโดยการประมวลผลผลลัพธ์เป็นชุด: เผยแพร่ผลลัพธ์ในหัวข้อ 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 รุ่นเก่า ) มี ความละเอียดอ่อนและต้องเก็บเป็นความลับ
เก็บกุญแจบัญชีบริการไว้เป็นความลับ
คีย์ส่วนตัวของบัญชีบริการ (ใช้โดย 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
ให้เข้มงวดขึ้น เพื่อป้องกันการโจมตีด้วยกำลังเดรัจฉาน คุณสามารถทำได้จาก หน้าของ API ใน Google Cloud Console
อัปเกรดเป็น 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 ซึ่ง ไม่ใช่ secret เพียงแค่ฝังคีย์ไว้ในโค้ด
- หากคุณใช้ 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