ความเสี่ยงและมาตรการในการใช้ไลบรารีในการสร้างระบบธุรกิจ

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

คืออะไรคือ “ไลบรารี”

ในการสร้างระบบงาน, บริษัทระบบสารสนเทศจะไม่สร้างโปรแกรมที่จำเป็นทั้งหมดด้วยตนเอง แทนที่จะทำเช่นนั้น, พวกเขามักจะสร้างฐานข้อมูลด้วย “ชิ้นส่วนซอฟต์แวร์ที่มีอยู่แล้ว” และสร้างส่วนที่ขาดหายไปด้วยตนเอง ซึ่งเป็นวิธีที่ทั่วไปที่สุด ชิ้นส่วนซอฟต์แวร์ที่มีอยู่แล้วนี้เรียกว่า “ไลบรารี” ฟังก์ชันทั่วไปมักจะพัฒนาโดยใช้ไลบรารี ฟังก์ชันทั่วไปหมายถึง “ฟังก์ชันการเข้าสู่ระบบ” หรือ “ฟังก์ชันการรับข้อมูลจากฐานข้อมูล” ซึ่งเป็นฟังก์ชันที่มีความต้องการสูงในทุกอุตสาหกรรมและระบบของทุกประเทศ ฟังก์ชันที่มีความต้องการสูงนี้มีไลบรารีที่สอดคล้องกัน อย่างไรก็ตาม, สำหรับฟังก์ชันที่ไม่เป็นทั่วไป เช่น การตอบสนองต่อความต้องการเฉพาะของลูกค้า ไม่มีไลบรารีที่มีอยู่แล้ว ดังนั้นบริษัทระบบสารสนเทศจะต้องสร้างขึ้นด้วยตนเอง

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

ประโยชน์ของไลบรารี: ทำได้เร็วและปลอดภัย

มีสองเหตุผลที่บริษัทระบบจะให้ความสำคัญกับการใช้ไลบรารีมากกว่าการสร้างด้วยตนเอง

• สามารถสร้างได้เร็วกว่าการสร้างด้วยตนเอง
• มีความปลอดภัยสูงกว่าการสร้างด้วยตนเอง

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

ข้อเสียของไลบรารีคืออะไร

การใช้งานไลบรารีสามารถสร้างระบบอย่างรวดเร็วและปลอดภัย ซึ่งเป็นประโยชน์ทั้งสำหรับลูกค้าและบริษัทระบบ อย่างไรก็ตาม การใช้งานไลบรารีมีค่าใช้จ่ายที่ต้องจ่าย นอกจากนี้ หากไม่มีการอัปเดต อาจมีโอกาสที่จะมี “ช่องโหว่” และหากมีการอัปเดต ระบบอาจหยุดทำงาน ซึ่งเป็นปัญหาที่ยากที่จะแก้ไข

หากไม่มีการอัปเดต อาจมีช่องโหว่

ผู้กระทำผิดที่วางแผนจะขโมยข้อมูลส่วนบุคคล ข้อมูลบัตรเครดิต หรือความลับขององค์กร จะค้นหาข้อบกพร่องด้านความปลอดภัยในไลบรารี (และซอฟต์แวร์ทั้งหมด) ข้อบกพร่องด้านความปลอดภัยเหล่านี้เรียกว่า “ช่องโหว่” ในภาษา IT มีหลายตัวอย่างที่ได้รับความเสียหายจากช่องโหว่ที่ซ่อนอยู่ในไลบรารีที่ใช้งาน ตัวอย่างเช่น ไลบรารี Struts2 ที่ใช้ในเว็บไซต์สำรวจของกระทรวงการขนส่งและที่อยู่อาศัยของญี่ปุ่นถูกโจมตีและประมาณ 200,000 ข้อมูลลูกค้าถูกรั่วไหล และเว็บไซต์ขายตั๋วที่ใช้ Struts2 อาจมีข้อมูลบัตรเครดิต 32,187 รายการรั่วไหล ช่องโหว่ของไลบรารีที่ไม่ทราบในขณะที่ระบบถูกส่งมอบอาจเปิดเผยในภายหลัง

การอัปเดตอาจมีความเสี่ยงที่ระบบจะหยุดทำงาน

ในบางครั้ง แม้จะมีช่องโหว่ การอัปเดตอาจไม่สามารถทำได้ เนื่องจากมีความเสี่ยงที่ระบบจะหยุดทำงานชั่วคราวเมื่อมีการอัปเดต ไลบรารีไม่ใช่โปรแกรมที่เขียนโดยบริษัทระบบ ดังนั้น การทราบรายละเอียดทั้งหมดอาจยาก ดังนั้น ความเสี่ยงที่ระบบจะมีปัญหาที่ไม่คาดคิดเมื่อมีการอัปเดตและระบบจะหยุดทำงานชั่วคราวไม่สามารถป้องกันได้ ลูกค้าอาจรู้สึกโกรธกับบริษัทระบบถ้าไม่ทราบรายละเอียดของระบบที่ส่งมอบ อย่างไรก็ตาม ความจริงคือบริษัทระบบทั่วไปไม่สามารถจัดการกับไลบรารีที่ใช้ในระบบปัจจุบันทั้งในเรื่องของคุณภาพและปริมาณ ตัวอย่างเช่น มีไลบรารีที่เรียกว่า “React” ที่ได้รับความนิยมสูงสุดในการสร้างอินเตอร์เฟซผู้ใช้ ไลบรารีนี้เป็นสิ่งที่มีคุณภาพสูงที่สร้างโดยวิศวกรของ Facebook และมีจำนวนโค้ดที่มากถึง 195,486 บรรทัด

กรณีที่ความอ่อนแอกลายเป็นประเด็นในการพิจารณาคดี

ในกรณีที่เกิดความเสียหายจากความอ่อนแอที่เกิดจากไลบรารี ปัญหาที่เกิดขึ้นคือใครที่จะต้องรับผิดชอบ อ้างอิงที่น่าสนใจคือคำพิพากษาของศาลแขวงโตเกียวในวันที่ 23 มกราคม พ.ศ. 2557 (2014). โจทก์ได้มอบหมายให้บริษัทระบบของจำเลยสร้างระบบการขาย แต่หลังจากที่ระบบเริ่มทำงาน ข้อมูลบัตรเครดิตของผู้ใช้สิ้นสุดได้รั่วไหลออกไปเนื่องจากความอ่อนแอของระบบ ทำให้โจทก์เสียค่าใช้จ่ายในการขอโทษและการสอบสวนประมาณ 32 ล้านเยน และเกิดข้อพิพาท ในสัญญาที่โจทก์และจำเลยได้ทำขึ้นมีข้อประกันที่ระบุว่า หากเกิดความเสียหายจากความผิดของจำเลย จำนวนเงินชดใช้ค่าเสียหายจะถูกจำกัดไว้ที่จำนวนเงินของสัญญา ข้อประกันนี้เป็นจุดที่ถูกโต้แย้ง คำพิพากษาได้สั่งให้จำเลยชดใช้ค่าเสียหายเกินจำนวนเงินของสัญญา เนื่องจากมีความผิดร้ายแรงของจำเลย และในกรณีที่มีความผิดร้ายแรง ข้อประกันจะไม่สามารถใช้งานได้

จำเลยเป็นบริษัทที่ดำเนินธุรกิจในการวางแผนระบบการประมวลผลข้อมูล การสร้างหน้าเว็บ และการพัฒนาระบบธุรกิจ โดยใช้ความรู้เฉพาะทางเกี่ยวกับโปรแกรม และได้นำเสนอแอปพลิเคชันเว็บนี้ในธุรกิจของตนเอง โจทก์ได้ทำสัญญาสั่งซื้อระบบนี้โดยไว้วางใจในความรู้เฉพาะทางของจำเลย ดังนั้น ความระมัดระวังที่ต้องการจากจำเลยจึงค่อนข้างสูง ดังที่ได้กล่าวไว้ข้างต้น หากไม่มีมาตรการป้องกันการโจมตี SQL Injection บุคคลที่สามสามารถโจมตี SQL Injection และทำให้ข้อมูลส่วนบุคคลรั่วไหลออกจากฐานข้อมูลนี้ได้ ซึ่งจำเลยสามารถทำนายได้ และ กระทรวงเศรษฐกิจและอุตสาหกรรมและ IPA ได้ยกตัวอย่างการโจมตี SQL Injection ในวิธีการโจมตีที่เป็นตัวแทนสำหรับแอปพลิเคชันเว็บ และได้เตือนให้ระวัง ดังนั้น สามารถทำนายได้ว่าสถานการณ์นี้สามารถเกิดขึ้นได้ นอกจากนี้ โดยการใช้กลไกการผูกหรือการประมวลผล Escape สามารถหลีกเลี่ยงผลลัพธ์ที่เกิดขึ้นจากการรั่วไหลนี้ได้ ไม่มีหลักฐานที่แสดงว่าการดำเนินการเพื่อหลีกเลี่ยงผลลัพธ์นี้จะต้องใช้แรงงานหรือค่าใช้จ่ายมาก ดังนั้น สามารถกล่าวได้ว่าการหลีกเลี่ยงผลลัพธ์นี้เป็นเรื่องที่ง่าย ดังนั้น จำเลยควรถูกยอมรับว่ามีความผิดร้ายแรง

คำพิพากษาของศาลแขวงโตเกียว วันที่ 23 มกราคม พ.ศ. 2557 (2014)

คำอธิบายในเอกสารของศูนย์ข้อมูลซอฟต์แวร์ มูลนิธิทั่วไป ที่แปลคำพิพากษานี้ในบริบทของความอ่อนแอของไลบรารี คือดังต่อไปนี้

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

คำถามและคำตอบเกี่ยวกับปัญหาทางกฎหมายในการใช้ OSS ในยุค IoT [PDF] (หน้าที่ 84)

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

มาตรการป้องกันช่องโหว่ที่เป็นไปได้ในทางปฏิบัติคืออะไร

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

1. การทำสัญญาบำรุงรักษาที่รวมถึงการอัปเดตไลบรารี
2. การตรวจสอบช่องโหว่

การทำสัญญาบำรุงรักษาที่รวมถึงการอัปเดตไลบรารี

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

การตรวจสอบช่องโหว่

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

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

สรุป

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