Check out what’s new from Firebase@ Google I/O 2021, and join our alpha program for early access to the new Remote Config personalization feature. Learn more

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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