บริหารจัดการ Rule ของไฟร์วอลล์อย่างไรให้ดีที่สุด

ภาพประกอบจาก Algosec
Credit: ShutterStock

ไฟร์วอลล์เป็นอุปกรณ์หน้าบ้านที่สำคัญที่สุดของทุกองค์กร ไม่ว่าจะทำหน้าที่กรองทราฟฟิค ตรวจจับภัยคุกคาม หรือป้องกันการโจมตีรูปแบบต่างๆทั้งจากภายในและภายนอก ในองค์กรขนาดใหญ่ ก็อาจติดตั้งไฟร์วอลล์ทั้ง สำนักงานใหญ่ สำนักงานสาขา หรือแยกเป็นไฟร์วอลล์ของแต่ละหน่วยงาน รวมทั้งฝ่ายความปลอดภัยด้าน IT ก็อาจแบ่งออกเป็นหลายฝ่าย เช่น Security, Risk Management หรือ Compliance การบริหารจัดการไฟร์วอลล์ทั้งหมดเพื่อให้เป็นไปตามกฎ ระเบียบ และสามารถใช้งานได้เต็มประสิทธิภาพจึงเป็นเรื่องท้าทายอย่างมาก ทีมงาน TechTalkThai จึงสรุป Best Pratice สำหรับบริหารจัดการ Rule ของไฟร์วอลล์มาดังนี้

1. ให้ Security Policy Manager หรือ Compliance Manager อยู่ในลูปเสมอ
เนื่องจากในบริษัทขนาดกลางและขนาดใหญ่ ฝ่ายความปลอดภัยอาจถูกแบ่งย่อยออกเป็นฝ่าย Security, Risk Management และ Compliance ซึ่งอาจจะไม่ได้ทำงานร่วมกันตลอดเวลา ดังนั้นแล้ว เพื่อให้ Rule ของไฟร์วอลล์สอดคล้องกับกฏและนโยบาย หรือมาตรฐานต่างๆขององค์กร ผู้ดูแลระบบไฟร์วอลล์ควรแจ้งทุกฝ่ายที่เกี่ยวข้องก่อนการปรับแต่ง แก้ไข Rule ของไฟร์วอลล์เสมอ เพื่อให้แต่ละฝ่ายสามารถตรวจสอบ Rule ให้มั่นใจได้ว่าไม่ขัดกับนโยบายใดๆขององค์กร

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

ปัจจุบันนี้ ไฟร์วอลล์ระดับ Enterprise-grade หลายยี่ห้อ มักมีฟังก์ชันในการตรวจสอบว่า Rule ไหนไม่ถูกเรียกใช้งานบ้าง ผู้ดูแลระบบไฟร์วอลล์ควรหมั่นตรวจสอบและทำเรื่องปิด Rule ที่ไม่ใช้งานทิ้งไปอย่างสม่ำเสมอ

3. จัดการ Rule ที่ขัดแย้งกัน
องค์กรที่ใช้ไฟร์วอลล์มานาน มักจะมีการปรับปรุง แก้ไข Rule ของไฟร์วอลล์บ่อย Rule ที่มีอยู่ก็จะเริ่มสลับซับซ้อนขึ้นเรื่อยๆ บางครั้ง Rule ใหม่ที่สร้างขึ้นเกิดขัดแย้งกับ Rule เดิมที่มีอยู่ ส่งผลให้ Rule ใหม่อาจไม่ถูกใช้งานเลย (เนื่องจากเงื่อนไขของทราฟฟิคตรงกับ Rule ที่อยู่ด้านบนก่อนเสมอ) เช่นเดียวกับข้อที่ 2 สำหรับไฟร์วอลล์ระดับ Enterprise-grade เราสามารถสังเกต Rule ที่ขัดแย้งกันเหล่านี้ได้จากช่วงเวลา Commit / Save / Comply หรือจากการแจ้งเตือน Rule ที่ไม่เคยถูกเรียกใช้งาน

4. บันทึกการแก้ไข Rule และการตั้งค่าไฟร์วอลล์ทุกครั้ง
บริษัทส่วนใหญ่มักไม่ใส่ใจในการทำเอกสารเกี่ยวกับไฟร์วอลล์มากนัก ส่งผลให้เป็นเรื่องยากที่จะตรวจสอบว่าใครเป็นผู้แก้ไข Rule, แก้ไขอย่างไร แล้วแก้ไขไปเพื่ออะไร ผู้ที่มารับช่วงดูแลระบบไฟร์วอลล์ต่อจึงมักต้องรับเคราะห์นั่งไล่ตรวจสอบทีละ Rule เมื่อมีปัญหาเกิดขึ้น ทำให้การแก้ไขปัญหาทำได้ล่าช้า รวมทั้งเป็นปัญหาการขัดหลักมาตรฐานบางอย่างขององค์กร เช่น PCI-DSS ดังนั้นแล้ว เมื่อต้องการปรับแต่ง Rule ของไฟร์วอลล์ ควรจดบันทึกสม่ำเสมอว่า ใครเป็นผู้ร้องขอ, Rule ปรับแต่งอย่างไร และสาเหตุที่ปรับแต่ง จะได้ง่ายต่อการตรวจสอบในอนาคต

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

ภาพประกอบจาก Securosis | https://securosis.com/projectquant/nso-quant-firewall-management-process-map-updated/
ภาพประกอบจาก Securosis | https://securosis.com/projectquant/nso-quant-firewall-management-process-map-updated/

ที่มา: http://www.networkworld.com/article/2452587/network-security/best-practices-for-firewall-management.html

About techtalkthai

ทีมงาน TechTalkThai เป็นกลุ่มบุคคลที่ทำงานในสาย Enterprise IT ที่มีความเชี่ยวชาญทางด้าน Network, Security, Server, Storage, Operating System และ Virtualization มารวมตัวกันเพื่ออัพเดตข่าวสารทางด้าน Enterprise IT ให้แก่ชาว IT ในไทยโดยเฉพาะ

Check Also

พบช่องโหว่ใน Kubernetes ที่อาจถูกใช้ยึดควบคุม Windows Node

พบช่องโหว่ใน Kubernetes ที่อาจถูกใช้ยึดควบคุม Windows Node ทั้งหมดในคลัสเตอร์

SonicWall เตือนช่องโหว่ Zero-day ใน SMA 1000 ให้ผู้ใช้อัปเดตด่วน!

พบการโจมตีในโซลูชัน SonicWall SMA 1000 Appliance Management Console (AMC) และ Central Management Console (CMC) ที่เป็นโซลูชันสำหรับรวมศูนย์การบริหารจัดการ โดยช่องโหว่มีความร้ายแรงที่ …