a16z: แนวทางการรักษาความปลอดภัยของสัญญาอัจฉริยะสำหรับโครงการ Web3
บทความนี้มาจาก a16zcryptoบทความนี้มาจาก
ผู้เขียนต้นฉบับ: Andy Beal, Nassim Eddequouaq, Riyaz Faizullabhoy และ Christian Seifert เรียบเรียงโดย Katie Koo นักแปล Odaily
โดยทั่วไปแล้ว แฮ็กเกอร์จะค้นหาและใช้ประโยชน์จากข้อบกพร่องในสายโซ่ของกระบวนการพัฒนาซอฟต์แวร์ทั้งหมด (ตั้งแต่การออกแบบ การปรับใช้งาน ไปจนถึงการบำรุงรักษา) ซึ่งจะเป็นการทำลายอุปสรรคด้านความปลอดภัยของโครงการบล็อกเชน หากสามารถเรียนรู้ประสบการณ์ที่เกี่ยวข้องล่วงหน้าได้ ผมเชื่อว่าจะมีอุบัติเหตุด้านความปลอดภัยน้อยลงมาก。
บทความนี้สรุปองค์ประกอบด้านความปลอดภัยที่นักพัฒนา Web3 และทีมรักษาความปลอดภัยต้องพิจารณาเมื่อออกแบบ พัฒนา และบำรุงรักษาสัญญาอัจฉริยะ ซึ่งครอบคลุมวงจรทั้งหมดตั้งแต่การสร้างแบบจำลองภัยคุกคามไปจนถึงการเตรียมการรับมือเหตุฉุกเฉิน
การพัฒนาซอฟต์แวร์ที่ปลอดภัยประกอบด้วยห้าขั้นตอนต่อไปนี้:
การออกแบบ: ผู้พัฒนาอธิบายถึงฟังก์ชันและการทำงานที่จำเป็นของระบบ รวมถึงเกณฑ์มาตรฐานที่สำคัญและคุณสมบัติคงที่
การพัฒนา: นักพัฒนาเขียนรหัสระบบ
การทดสอบและตรวจสอบ: นักพัฒนารวบรวมโมดูลทั้งหมดในสภาพแวดล้อมการทดสอบและประเมินความถูกต้อง ขนาด และปัจจัยอื่นๆ
การปรับใช้: นักพัฒนานำระบบไปสู่การผลิต
การบำรุงรักษา: นักพัฒนาจะประเมินและแก้ไขระบบเพื่อให้แน่ใจว่าทำงานได้ตามที่ต้องการ
แผนภาพด้านล่างแมปปัจจัยด้านความปลอดภัยที่ต้องพิจารณาในขั้นตอนข้างต้น
ขั้นตอนวงจรชีวิตของซอฟต์แวร์และข้อควรพิจารณาด้านความปลอดภัยที่เกี่ยวข้องตามที่อธิบายไว้ข้างต้นเป็นพื้นฐานสำหรับการอำนวยความสะดวกในการรักษาความปลอดภัยของสัญญาอัจฉริยะ ต่อไปนี้ เราจะทำการวิจัยโดยละเอียดเพิ่มเติมในสามประเด็น
ชื่อเรื่องรอง
1. ข้อพิจารณาด้านความปลอดภัยของสัญญาอัจฉริยะในขั้นตอนการออกแบบ - พิจารณาการสร้างแบบจำลองภัยคุกคามและการออกแบบความปลอดภัย
อะไร: การระบุและจัดลำดับความสำคัญของภัยคุกคามที่อาจเกิดขึ้นกับระบบอย่างชัดเจนตั้งแต่ช่วงต้นของวงจรชีวิตการพัฒนาโครงการเป็นกุญแจสำคัญ ผู้พัฒนาสัญญาอัจฉริยะควรระบุการควบคุมความปลอดภัยทั้งหมดที่จะใช้ในระหว่างการพัฒนา และภัยคุกคามที่ควรตรวจสอบระหว่างการทดสอบ การตรวจสอบ และการเฝ้าติดตาม สมมติฐานด้านความปลอดภัยทั้งหมด รวมถึงความซับซ้อนที่คาดหวังและวิธีการทางเศรษฐกิจของผู้โจมตี ควรได้รับการกำหนดและอธิบายอย่างชัดเจนในระหว่างขั้นตอนการออกแบบ
เหตุผล: แม้ว่านักพัฒนาซอฟต์แวร์จะดึงดูดใจให้มุ่งความสนใจไปที่การใช้สัญญาอัจฉริยะหรือโปรโตคอลเพียงอย่างเดียว แต่การมุ่งเน้นเพียงอย่างเดียวอาจทำให้ "จุดบอด" ที่ผู้โจมตีสามารถใช้ประโยชน์ได้ออกแบบระบบด้วยความคิดแบบ "ผู้โจมตี" และสันนิษฐานว่าบุคคล เครื่อง หรือบริการใดๆ สามารถถูกโจมตีได้
ชื่อเรื่องรอง
2. ข้อควรพิจารณาด้านความปลอดภัยในระยะการพัฒนา - ข้อพิจารณาด้านการบริหารและการควบคุมการเข้าถึงอะไร: ใช้การควบคุมการเข้าถึงที่จำกัดความสามารถของบัญชีพิเศษและการเรียกสัญญาอัจฉริยะไปยังฟังก์ชันพิเศษที่ดำเนินการด้านการบริหาร เช่น การอัปเกรดสัญญาและการตั้งค่าพารามิเตอร์พิเศษ
ปฏิบัติตาม "หลักการของสิทธิ์น้อยที่สุด" - ผู้เข้าร่วมแต่ละคนควรมีสิทธิ์เข้าถึงขั้นต่ำเท่านั้น
แนวทาง: สร้างกระเป๋าเงินหลายลายเซ็นหรือสัญญา DAO เพื่อจัดการการเปลี่ยนแปลงอย่างโปร่งใสในนามของชุมชน การเปลี่ยนแปลงควรผ่านกระบวนการตรวจสอบอย่างถี่ถ้วนและมีการล็อกเวลา (จงใจชะลอการออกกฎหมายโดยสามารถยกเลิกได้) เพื่อให้แน่ใจว่าความถูกต้องสามารถตรวจสอบและย้อนกลับได้ในกรณีที่เกิดการโจมตีด้านธรรมาภิบาล ตรวจสอบให้แน่ใจว่ามีการจัดเก็บคีย์พิเศษไว้อย่างปลอดภัยและเข้าถึงได้ในกระเป๋าคุมข้อมูลด้วยตนเองหรือบริการรักษาความปลอดภัย
ชื่อเรื่องรอง
3. พิจารณาเทมเพลตและการผสานรวมที่ใช้ซ้ำได้ ผ่านการทดสอบการต่อสู้
อะไร: ใช้ประโยชน์จากมาตรฐานสัญญาอัจฉริยะที่มีอยู่ (เช่น OpenZeppelin Contracts) หากเป็นไปได้ และประเมินสมมติฐานด้านความปลอดภัยที่อาจจำเป็นสำหรับการรวมโปรโตคอลกับโปรโตคอลที่มีอยู่
เหตุผล: การใช้มาตรฐานที่ผ่านการทดสอบการต่อสู้และการตรวจสอบโดยชุมชนที่มีอยู่และการใช้มาตรการเพื่อลดความเสี่ยงด้านความปลอดภัยสามารถช่วยได้มาก การประเมินความเสี่ยงของการรวมโปรโตคอลช่วยพัฒนาการตรวจสอบความปลอดภัยเพื่อป้องกันการโจมตีส่วนประกอบภายนอก เช่น การจัดการของออราเคิลทราบความเสี่ยงของคุณและติดตามการโจมตีห่วงโซ่อุปทาน ใช้อินเทอร์เฟซอย่างเป็นทางการเพื่อเรียกใช้โปรโตคอลภายนอก และตรวจสอบให้แน่ใจว่าได้พิจารณาความเสี่ยงในการผสานรวมที่อาจเกิดขึ้น ตรวจสอบการอัปเดตและการเปิดเผยข้อมูลด้านความปลอดภัยสำหรับสัญญาที่นำกลับมาใช้ใหม่
ชื่อเรื่องรอง
4. ข้อควรพิจารณาด้านความปลอดภัยระหว่างขั้นตอนการทดสอบและทบทวน - พิจารณาการทดสอบและเอกสารประกอบ
อะไร: สร้างเอกสารโค้ดที่ชัดเจนและครอบคลุม และสร้างชุดทดสอบที่รวดเร็ว ละเอียดถี่ถ้วน และเรียกใช้ได้ง่าย หากเป็นไปได้ ให้สร้างสภาพแวดล้อมการทดสอบบนเครือข่ายทดสอบหรือจำลองเครือข่ายหลักเพื่อทำการทดลองเชิงลึกเพิ่มเติมเหตุผล:การเขียนข้อสันนิษฐานเกี่ยวกับพฤติกรรมที่คาดหวังของ codebase ช่วยให้มั่นใจได้ว่าความเสี่ยงในรูปแบบภัยคุกคามได้รับการแก้ไข และผู้ใช้และผู้ตรวจสอบภายนอกเข้าใจถึงความตั้งใจของทีมพัฒนา
แนวทาง: ใช้เฟรมเวิร์กการทดสอบและตัวตรวจสอบความปลอดภัยที่เป็นที่รู้จัก เช่น Hardhat, Mythril, Slither, Truffle เป็นต้น ซึ่งมีเทคนิคการทดสอบที่แตกต่างกัน เช่น fuzzing การตรวจสอบคุณสมบัติ และแม้แต่การตรวจสอบอย่างเป็นทางการ ใช้ความคิดเห็นของ NatSpec เพื่อบันทึกโค้ดของคุณอย่างละเอียด โดยระบุผลข้างเคียงที่คาดหวัง พารามิเตอร์ และค่าส่งคืน สร้างเอกสารตามเวลาจริงโดยใช้เครื่องมือสร้างเอกสารรวมถึงคำแนะนำการออกแบบระดับสูง
ชื่อเรื่องรอง
5. พิจารณาการทบทวนภายในและการตรวจสอบความปลอดภัย
อะไร: ใช้เวลาในการเปิดเผยช่องโหว่ผ่านการตรวจสอบโค้ดภายในและภายนอกเหตุผล: การเปลี่ยนจากการพัฒนาฟีเจอร์เป็นการเน้นประเด็นด้านความปลอดภัยช่วยให้นักพัฒนามีเวลาในการตรวจหาปัญหาที่อาจคลุมเครือ
การตรวจสอบภายนอกมีประโยชน์อย่างยิ่งที่นี่ เนื่องจากสามารถนำเสนอมุมมองและความเชี่ยวชาญภายนอกที่ทีมพัฒนาไม่มี
ดูคำแนะนำจาก ConsenSys, Nassent, OpenZeppelin และ Trail of Bits ซึ่งให้รายการตรวจสอบสำหรับนักพัฒนา รวมถึงเวลา สำหรับทุกคนที่เตรียมการตรวจสอบ ตรวจสอบให้แน่ใจว่าได้ตรวจสอบธุรกรรมการปรับใช้เพื่อให้แน่ใจว่าใช้รหัสเวอร์ชันที่ตรวจสอบแล้วและมีพารามิเตอร์ที่เหมาะสม โดยเฉพาะอย่างยิ่งเมื่ออัปเกรดซอฟต์แวร์
ชื่อเรื่องรอง
6. ข้อควรพิจารณาด้านความปลอดภัยในขั้นตอนการปรับใช้และการบำรุงรักษา - การกระตุ้นการมีส่วนร่วมของชุมชนหมวกขาว
อะไร: สร้างโปรแกรมที่สนับสนุนการมีส่วนร่วมของชุมชนในการปรับปรุงความปลอดภัยของฐานรหัสโอเพ่นซอร์ส วิธีหนึ่งในการทำเช่นนี้คือการสร้างรางวัลบั๊ก อีกวิธีหนึ่งคือการกระตุ้นให้ชุมชนพัฒนาโปรโตคอลเพื่อตรวจสอบและตรวจจับบ็อต
เหตุผล: ทีมพัฒนาจะได้รับประโยชน์จากความรู้และประสบการณ์ที่หลากหลาย (นี่คือบทบาทของโอเพ่นซอร์สในด้านการเข้ารหัสด้วย) โปรแกรมดังกล่าวสามารถช่วยจุดประกายความกระตือรือร้นให้กับโครงการ โดยเปลี่ยนชุมชนและแฮ็กเกอร์หมวกขาวให้กลายเป็นผู้ประกาศข่าวประเสริฐ นอกจากนี้ยังสามารถช่วยเปลี่ยนผู้โจมตีให้กลายเป็นสินทรัพย์ที่ปลอดภัยโดยให้แฮ็กเกอร์กลายเป็นผู้ปกป้อง
หมายเหตุ: ผู้เขียนบางคนในบทความนี้ทำงานให้กับ Forta Corporation ซึ่งเป็นเจ้าของเครือข่ายที่มีโครงสร้างแรงจูงใจแบบโทเค็นสำหรับการสร้างหุ่นยนต์เฝ้าระวังความปลอดภัยคุณภาพสูงแบบกระจายอำนาจ ทีมพัฒนาสามารถสนับสนุนชุมชนโปรโตคอลของตนให้ใช้ประโยชน์จากแนวทางดั้งเดิมและแบบเนทีฟของ Web3 เพื่อจูงใจให้รางวัลบั๊กและอาจเป็นประโยชน์ต่อผู้เข้าร่วมผ่านการรักษาความปลอดภัยที่ได้รับการปรับปรุง ซึ่งเป็นสถานการณ์ที่ทุกฝ่ายได้ประโยชน์
ชื่อเรื่องรอง
7. ข้อควรพิจารณาด้านความปลอดภัยในการตรวจสอบตามเวลาจริง
อะไร: ใช้ระบบที่ตรวจสอบสัญญาอัจฉริยะและส่วนประกอบการดำเนินงานที่สำคัญ เช่น oracles และ cross-chain bridges และรายงานกิจกรรมที่น่าสงสัยไปยังทีมพัฒนาและชุมชนตามรูปแบบภัยคุกคามที่รู้จัก
วิธีการ: ใช้แพลตฟอร์มการตรวจสอบหรือโหนดแบบกระจายเพื่อเรียกใช้หุ่นยนต์เพื่อตรวจสอบเหตุการณ์สัญญาอัจฉริยะแบบเรียลไทม์ เสียบแดชบอร์ดข้อมูลและการแจ้งเตือนสำหรับทีมพัฒนาและชุมชนที่กว้างขึ้นตามต้องการ
ชื่อเรื่องรอง
8. ข้อพิจารณาด้านความปลอดภัยสำหรับการปฏิบัติการตอบโต้อุบัติเหตุและเหตุฉุกเฉิน
อะไร: ใช้เครื่องมือและกระบวนการที่สามารถตอบสนองได้ทันทีกับปัญหาด้านความปลอดภัยใดๆ ที่เกิดขึ้น
เหตุผล: แม้จะมีการป้องกันก่อนการปรับใช้ที่ดีที่สุด ปัญหาแบบเรียลไทม์ของสัญญาอัจฉริยะและส่วนประกอบหลัก เช่น oracles และ cross-chain bridge ก็ยังเป็นไปได้ บุคลากรเฉพาะ กระบวนการที่ชัดเจน และระบบอัตโนมัติที่เหมาะสมช่วยให้มั่นใจได้ว่าเหตุการณ์ต่างๆ จะได้รับการตรวจสอบอย่างรวดเร็วและแก้ไขได้โดยเร็วที่สุด
แนวทาง: เตรียมพร้อมสำหรับสถานการณ์ที่เลวร้ายที่สุด วางแผนวิธีตอบสนองต่อเหตุการณ์หรือเหตุฉุกเฉิน และทำให้ความสามารถในการตอบสนองเป็นไปโดยอัตโนมัติในขอบเขตสูงสุดที่เป็นไปได้ ซึ่งรวมถึงการมอบหมายความรับผิดชอบในการสอบสวนและการตอบสนอง ซึ่งสามารถติดต่อกับสาธารณะเกี่ยวกับข้อกังวลด้านความปลอดภัยผ่านทางรายการส่งจดหมายด้านความปลอดภัยแบบกระจาย คำแนะนำในที่เก็บโค้ด หรือการลงทะเบียนสัญญาอัจฉริยะ ตามรูปแบบภัยคุกคามของข้อตกลง พัฒนาชุดของกระบวนการที่สามารถรวมการซ้อมสถานการณ์และเวลาตอบสนองที่คาดหวังซึ่งจำเป็นสำหรับการดำเนินการอย่างเร่งด่วน สามารถพิจารณาการรวมระบบอัตโนมัติเข้ากับการตอบสนองเหตุการณ์ฉุกเฉินการพิจารณาด้านความปลอดภัยควรเป็นส่วนสำคัญของการพัฒนาที่ประสบความสำเร็จ ไม่ใช่แค่การคิดภายหลังหรือเพิ่มเติม
แม้ว่าเฟรมเวิร์กนี้จะแชร์แนวทางด่วนสำหรับการสร้างโปรโตคอลและแอปพลิเคชัน Web3 ที่อำนวยความสะดวกในการรักษาความปลอดภัยตลอดกระบวนการพัฒนา แต่ก็ไม่มีภาพรวมสั้นๆ ที่สามารถพูดถึงความปลอดภัยของสัญญาอัจฉริยะได้อย่างครบถ้วน ทีมที่ไม่มีความเชี่ยวชาญด้านความปลอดภัยภายในองค์กรควรติดต่อผู้เชี่ยวชาญด้านความปลอดภัย Web3 ที่มีคุณสมบัติเหมาะสม ซึ่งสามารถแนะนำและช่วยให้นำไปใช้กับสถานการณ์เฉพาะของตนได้
