โปรแกรมเมอร์ที่มีประสบการณ์สักหน่อยคงเข้าใจได้ไม่ย ากว่าซอฟต์แวร์ที่ไม่มีบั๊กนั้นแทบไม่มีจริงอยู่ในโล ก หนังสือ Code Complete ของ Steve McConnell ระบุว่าโดยทั่วไปแล้วโค้ดทุกๆ 1000 บรรทัด (KLOC: kilo lines of code) จะมีข้อผิดพลาดประมาณ 15-50 จุด ซอฟต์แวร์ที่คุณภาพสูงมากๆ อาจจะมีกระบวนการตรวจสอบที่รัดกุม อาจจะทำให้คุณภาพซอฟต์แวร์ดีขึ้น จุดผิดพลาดต่ำลงต่ำ แต่ซอฟต์แวร์สมัยใหม่ที่มีความซับซ้อนสูง พึ่งพิงกับไลบรารีภายนอกจำนวนมาก แทบเป็นไปไม่ได้ที่จะอ้างว่าซอฟต์แวร์เหล่านี้ไม่มีค วามผิดพลาดอยู่เลย ในบางกรณีอาจมีผู้อ้างว่าทำได้เช่นในโครงการอวกาศบาง โครงการ แต่ซอฟต์แวร์เหล่านั้นมักเป็นงานเฉพาะทาง ไม่ต้องรองรับฮาร์ดแวร์ที่หลากหมายและมาตรฐานการเชื่ อมต่อกับภายนอกจำนวนมาก
ระยะเวลาซัพพอร์ต


การส่งมอบซอฟต์แวร์ที่ไร้ความผิดพลาดอาจจะเป็นไปได้ย าก การพัฒนาซอฟต์แวร์จึงมักจะมีช่วงที่ผู้ผลิตประกาศว่า จะ "ดูแล" ซอฟต์แวร์ของตัวเองต่อไปเมื่อมีปัญหา ช่วงเวลานี้เรียกว่าช่วงเวลาซัพพอร์ต (ซึ่งอาจจะสับสนกับการขอคำแนะนำสำหรับซอฟต์แวร์จริงๆ ) ซอฟต์แวร์ที่มีผู้ใช้จำนวนมากส่งผลกระทบต่อผู้ใช้เป็ นวงกว้าง มักจะประกาศช่วงเวลาซัพพอร์ตให้กับลูกค้าไว้ล่วงหน้า ตัวอย่างเช่น วินโดวส์นั้นทางไมโครซอฟต์จะแบ่งช่วงเวลาซัพพอร์ตออก เป็นสองช่วง คือ ช่วงซัพพอร์ตหลัก (mainstream support) ที่จะมีอัพเดตให้รวมถึงมีฟีเจอร์ใหม่ๆ ที่สำคัญให้อยู่เสมอๆ เช่น เบราว์เซอร์รุ่นใหม่ หรือรองรับมาตรฐานใหม่ๆ และหลังจากช่วงนั้นไปแล้วจะเป็นช่วงซัพพอร์ตระยะยาว (extended support) ที่มีเฉพาะแพตช์ความปลอดภัย ในกรณีของ Windows 7 เพิ่มหมดซัพพอร์ตหลักไปเมื่อเดือนมกราคมที่ผ่านมา และจะหมดซัพพอร์ตทั้งหมดในวันที่ 14 มกราคม 2020 หรืออีกประมาณ 5 ปีข้างหน้า

ในโลกของลินุกซ์ก็คล้ายกัน Red Hat Enterprise Linux (RHEL) ที่นิยมใช้งานกันในองค์กรแบ่งช่วงซัพพอร์ตออกเป็นสี่ ช่วง ได้แก่ Production 1 แก้ปัญหาความปลอดภัย, แก้ไขปัญหา, และรองรับฮาร์ดแวร์ใหม่ๆ Production 2 แก้ปัญหาความปลอดภัย และรองรับฮาร์ดแวร์ใหม่เฉพาะกรณีที่ไม่ต้องเปลี่ยนซอ ฟต์แวร์มากนัก, Production 3 แก้ไขเฉพาะปัญหาความปลอดภัยระดับวิกฤติ (Critical) และระดับเร่งด่วน (Urgent) เท่านั้น ไม่มีแผนการรองรับฮาร์ดแวร์ใหม่ๆ หลังจากพ้นช่วง Production 3 ไปแล้วจะเป็นช่วง Extended Life Cycle Support (ELS) ที่จะแก้ปัญหาความปลอดภัยระดับวิกฤติเท่านั้นและซัพพ อร์ตชนิดนี้ต้องซื้อเพิ่มเติม
การซัพพอร์ตระบบปฎิบัติการส่วนมากจะรวมถึงไลบรารีต่า งๆ ที่มาพร้อมกับระบบปฎิบัติการด้วย ในกรณีของลินุกซ์ ดิสโทรต่างๆ มักรวมเอาไลบรารีและซอฟต์แวร์จำนวนมากเข้าเป็นส่วนหน ึ่งของโครงการ ไลบรารีและซอฟต์แวร์ที่ได้รับการซัพพอร์ตจากลินุกซ์ด ิสโทรต่างๆ อาจจะไม่ใช่รุ่นใหม่ที่สุด แต่นโยบายการซัพพอร์ตก็จะตรงตามรอบของดิสโทรนั้นๆ ไปด้วย หากไลบรารีหยุดซัพพอร์ตไปก่อนนักพัฒนาของดิสโทรก็มัก จะกลับไปแก้ซอฟต์แวร์รุ่นเก่าให้ เช่น กรณี RedHat ที่มาพร้อมกับ PHP 5.3 เมื่อพบบั๊กแต่ทาง PHP เลิกซัพพอร์ตไปแล้ว ทาง RedHat ก็จะให้นักพัฒนาของตัวเองเข้ามาดูแลแพตช์นี้เอง เรียกว่า backporting ในกรณีเช่นนี้ต้องระวังว่าไม่ได้ใช้ซอฟต์แวร์ที่ติดต ั้งได้แต่ไม่ได้ซัพพอร์ต เช่น EPEL ใน RedHat/CentOS, หรือ Universe และ Multiverse ใน Ubuntu ที่แม้จะติดตั้งได้สะดวก แต่ซอฟต์แวร์เหล่านี้ไม่ได้รับการซัพพอร์ตจากดิสโทรโ ดยตรง ทีมงานอาจจะปฎิเสธไม่แพตช์ซอฟต์แวร์ให้แม้มีปัญหา
แจ้งเตือนและแก้ไข

หัวใจสำคัญของการซัพพอร์ตซอฟต์แวร์ คือ กระบวนการแจ้งเตือนผู้พัฒนา เมื่อมีผู้พบช่องโหว่ความปลอดภัย โดยมารยาทแล้วจะไม่เปิดเผยช่องโหว่นั้นๆ สู่สาธารณะ แต่จะแจ้งเตือนไปยังเจ้าของโครงการโดยตรง โดยให้เวลากับเจ้าของโครงการเป็นระยะเวลาหนึ่งให้แก้ ไข หากเจ้าของโครงการแจ้งกลับว่าไม่สามารถแก้ไขได้ทันก็ สามารถขอยืดเวลานั้นได้ในบางกรณี ตัวอย่างของหน่วยงานแจ้งเตือน เช่น CERT ให้เวลา 45 วันหลังแจ้งเตือนเพื่อแก้ไข หรือหากมีการโจมตีจริงแล้วก็าอาจจะลดระยะเวลาลงได้เช ่นกัน หลังจากนั้นทาง CERT จะเปิดเผยข้อมูลทั้งหมดสู่สาธารณะ ส่วนโครงการเอกชนอย่าง Project Zero ของกูเกิลนั้นให้เวลา 90 วัน
เมื่อทางโครงการได้รับคำแจ้งเตือนแล้วจะแจ้งไปยังผู้ พัฒนาด้วยช่องทางส่วนตัว โดยโครงการมักกำหนดวันเปิดเผยบั๊กร่วมกับโครงการอื่น ๆ เช่น Debian และ Ubuntu ซึ่งมี Debian เป็นฐานก็ควรอัพเดตพร้อมๆ กัน ไม่เช่นนั้นการแก้ไขบั๊กของ Debian จะกลายเป็นการเปิดเผยช่องโหว่ของโครงการอื่นๆ เจ้าของโครงการจะเป็นผู้ดูแลให้มีการอัพเดตซอฟต์แวร์ พร้อมๆ กันในทุกๆ เวอร์ชั่นที่ยังซัพพอร์ตโดยดิสโทรอยู่
หลังจากนั้นนักพัฒนาจะส่งแพตช์ไปให้เจ้าของโครงการ ดิสโทรต่างๆ ก็จะปล่อยอัพเดตในเวลาไล่เลี่ยกัน สำหรับผู้ที่สนใจอ่านเพิ่มเติมอ่านได้ที่บล็อคของคุณเทพพิทักษ์ที่บันทึกประสบการณ์การแก้ช่องโหว่ความปลอดภัย CVE-2009-4012 ในฐานะนักพัฒนา
ทดสอบก่อนอัพเดต

ปัญหาสำคัญของการแก้ปัญหาความปลอดภัยคือการแก้ปัญหาเ หล่านั้นมักเป็นความลับ ขณะเดียวกันผู้ดูแลระบบเองก็มีความลำบากเพราะการเปลี ่ยนแปลงซอฟต์แวร์แต่ละครั้งมักกระทบส่วนอื่นๆ อยู่เป็นระยะ ผู้ดูแลระบบที่รับผิดชอบต่อการอัพเดตจึงต้องการเวลาท ดสอบแพตช์ที่ปล่อยออกมาว่าสามารถทำงานร่วมกับซอฟต์แว ร์อื่นๆ ได้ถูกต้องหรือไม่ โครงการซอฟต์แวร์จำนวนมากจึงเริ่มวางมาตรการปล่อยแพต ช์ความปลอดภัยในรูปแบบที่คาดเดาได้
แนวทางการปล่อยแพตช์สำคัญคือ Patch Tuesday ของไมโครซอฟท์ โดยกำหนดเป็นวันอังคารที่สองของทุกเดือน (ดู Microsoft Security Bulletin สังเกตวันที่ปล่อยอัพเดต) แนวทางนี้ทำให้ฝ่ายไอทีสามารถเตรียมบุคลากร เพื่อทดสอบซอฟต์แวร์ทันทีหลังแพตช์ปล่อยออกมา และนำระบบที่แพตช์แล้วขึ้นได้อย่างรวดเร็ว บริษัทซอฟต์แวร์ขนาดใหญ่มีแนวโน้มจะปล่อยแพตช์ในช่วง เวลาที่คาดเดาได้เช่นนี้มากขึ้น เช่นทุกวันนี้ออราเคิลก็มีนโยบายปล่อยแพตช์ความปลอดภัยวันอังคารที่ใกล้กับวันที่ 17 ของทุกเดือน
สำหรับซอฟต์แวร์ที่ต้องอาศัยการทดสอบมากกว่า อย่างเช่นระบบ CMS เพราะหน่วยงานอาจจะเข้าถึง API ระดับต่ำ หรือกระทั่งแพตช์ซอฟต์แวร์ด้วยตัวเอง การทดสอบมักใช้เวลามากกว่าระบบปฎิบัติการ หรือซอฟต์แวร์ที่มีอินเทอร์เฟซชัดเจนเช่นระบบฐานข้อม ูล ตัวอย่าง Drupal ประกาศกำหนดการอัพเดตเป็นเดือนละสองรอบ โดยวันพุธแรกของเดือนจะเป็นการแก้บั๊กทั่วไป ส่วนวันพุธที่สามของเดือนจะเป็นการแก้บั๊กความปลอดภั ยเท่านั้น แนวทางนี้ทำให้ผู้ดูแลระบบสามารถทดสอบแพตช์บั๊กอื่นๆ ไปได้ก่อน และน่าจะอัพเดตได้ทันทีหากมีบั๊กความปลอดภัย เพราะผลกระทบกับ API ต่างๆ น่าจะน้อย
แนวทางโดยรวม

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

  • ระยะเวลาซัพพอร์ตของซอฟต์แวร์ที่เกี่ยวข้อง: นับตั้งแต่ตัวระบบปฎิบัติการ, ซอฟต์แวร์ประยุกต์ที่ซื้อมาใช้งาน, ไลบรารีสำหรับพัฒนา ฯลฯ ควรศึกษาอายุการซัพพอร์ตล่วงหน้าว่าแต่ละโครงการที่เ กี่ยวข้องมีนโยบายการอัพเดตอย่างไร
  • เตรียมทีมงานดูแลระบบต่อเนื่อง: โครงการหนึ่งๆ ควรเตรียมการซัพพอร์ตไว้ตั้งแต่แรก ทั้งด้านงบประมาณและบุคคลากร ซอฟต์แวร์ไม่ว่าจะพัฒนาไว้ดีแค่ไหน ก็มีข้อผิดพลาดที่ต้องดูแลเสมอ
  • ตรวจสอบความปลอดภัยเป็นระยะ: ในกรณีที่มีซอฟต์แวร์พัฒนาเป็นการภายในอาจจะต้องมีกา รตรวจสอบความปลอดภัย (penetration testing) เพิ่มเติม

In-Depth, Security




อ่านต่อ...