กลยุทธ์การรักษาความปลอดภัยและการลดการโกง

ก่อนที่จะดำดิ่งสู่กลยุทธ์เฉพาะในการพัฒนาอย่างปลอดภัยและป้องกันการโกง สิ่งสำคัญคือต้องเข้าใจหลักการพื้นฐานของความปลอดภัยใน Roblox เกมที่ปลอดภัยจะถูกสร้างขึ้นจากแนวคิดที่คาดการณ์การกระทำที่เป็นปฏิปักษ์ ก่อนที่จะเขียนโค้ดบรรทัดเดียว คุณต้องทำความเข้าใจหลักการพื้นฐานเหล่านี้ให้ดี มันควรมีอิทธิพลต่อการตัดสินใจด้านสถาปัตยกรรมและการออกแบบทุกอย่างที่คุณทำ

อย่าเชื่อใจลูกค้า

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

• ถอดรหัส LocalScript ที่ทำซ้ำหรือ ModuleScript ใดๆ แม้ว่าจะไม่เคยทำงานบนลูกค้า
• ครอบครองเครือข่ายของตัวละครและชิ้นส่วนที่ไม่ถูกยึด
• กระตุ้นเหตุการณ์ที่เริ่มต้นจากลูกค้า เช่น เหตุการณ์ Touched หรือการเปิดใช้งาน ProximityPrompt ที่ระยะหรือความถี่ใดๆ
• แก้ไขตำแหน่ง ฟิสิกส์ หรือการโต้ตอบของผู้เล่นกับโลก
• เรียกใช้หรือเรียก RemoteEvents และ RemoteFunctions ที่ความถี่ใดๆ ด้วยอาร์กิวเมนต์ตามอำเภอใจ (นอกจากอาร์กิวเมนต์ Player ตัวแรก)
• เปลี่ยนแปลงสิ่งใดใน DataModel ท้องถิ่นของตนโดยไม่ต้องเรียกเหตุการณ์ที่คาดหวัง
• ดัดแปลงพฤติกรรมของโค้ดที่ทำงานในท้องถิ่นได้ตามอำเภอใจ

ด้วยเหตุนี้ ทุกตรรกะที่สำคัญต้องได้รับการตรวจสอบจากเซิร์ฟเวอร์หรือทำงานเฉพาะบนเซิร์ฟเวอร์ ผลที่ตามมาของการควบคุมนี้มีรายละเอียดใน Network Ownership, Movement Validation, and Physics Exploits และ Access Control and Confidentiality

อำนาจของเซิร์ฟเวอร์

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

บทบาทของเซิร์ฟเวอร์คือ:

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

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

ความปลอดภัยโดยการออกแบบ

รวมการพิจารณาด้านความปลอดภัยเข้าไปในการออกแบบเกมของคุณตั้งแต่เริ่มต้น แทนที่จะพยายามติดตั้งในภายหลังในฐานะความคิดที่ตามมา

• สร้างโมเดลภัยคุกคามสำหรับฟีเจอร์ใหม่ทุกฟีเจอร์ สำหรับฟีเจอร์ใหม่แต่ละฟีเจอร์ ให้ถามว่า

  • ผู้โจมตีจะสามารถใช้ประโยชน์จากสิ่งนี้ได้อย่างไรหากพวกเขามีการควบคุมเต็มที่เหนือคลิปของตน?
  • หากลูกค้าสามารถส่งค่าใดๆ สำหรับพารามิเตอร์ใดๆ ที่ใช้ในฟีเจอร์นี้ ผลลัพธ์ที่เลวร้ายที่สุดคืออะไร?
  • จะเกิดอะไรขึ้นหากฟีเจอร์นี้ถูกใช้มากกว่า 1,000 ครั้งต่อวินาที? อัตราสูงสุดที่ควรใช้คืออะไร?
  • ผู้ใช้ที่โกงสามารถใช้สิ่งนี้เพื่อทำลายประสบการณ์ของผู้เล่นคนอื่นได้หรือไม่?
  • ทรัพยากรเท่าใดในกรณีที่เลวร้ายที่สุดที่ฟีเจอร์นี้สามารถใช้ได้จริง?
  • ข้อมูลหรือสถานะภายในขั้นต่ำที่ฉันต้องเปิดเผยสำหรับฟีเจอร์นี้คืออะไร?
• แบ่งหน้าที่ความรับผิดชอบตั้งแต่เนิ่นๆ เก็บตรรกะและข้อมูลใน ServerScriptService ตั้งแต่วันแรก อย่าวางไว้ในคอนเทนเนอร์ที่ทำซ้ำเช่น ReplicatedStorage หรือ Workspace.