เข้าใจความเสี่ยงของ policy สอบถามเรื่อง policy ได้ด้วยภาษาทั่วไป ขอชมการสาธิต →
Published:
ประวัติศาสตร์เชิงปฏิบัติของ Firewall – ตอนที่ 2: คุณค่าของการบริหารจัดการ
by FireMon
Jody Brazil CEO at FireMon Check Point และ firewall แบบ stateful inspection เป็นฝ่ายชนะในศึกช่วงแรกกับ proxy firewall (ตอนที่ 1: ยุคเริ่มต้น) หลายคนอาจสรุปง่าย ๆ ว่าชัยชนะนี้เป็นเรื่องของเทคโนโลยีการตรวจสอบทราฟฟิกเพียงอย่างเดียว แต่นั่นคือการมองข้ามนวัตกรรมสำคัญของโซลูชัน Check Point นั่นคือ Policy Management การที่ firewall แบบ stateful inspection เอาชนะคู่แข่งแบบ proxy ได้ในช่วงกลางทศวรรษ 1990 มีสาเหตุสำคัญมาจากความง่ายในการบริหารจัดการ เนื้อหาส่วนใหญ่ของบทความนี้มุ่งไปที่ Check Point สาเหตุหลักคือบทบาทที่โดดเด่นของ Check Point ในตลาด firewall ช่วงปลายทศวรรษ 1990 ถึงต้นทศวรรษ 2000 แต่อีกส่วนหนึ่งก็อาจมาจากประสบการณ์ที่ผมคลุกคลีกับ Check Point ในช่วงเวลานั้น ผมยินดีรับฟังมุมมองของท่านและรอติดตามความคิดเห็นของท่าน ช่วงกลางทศวรรษ 1990 เป็นยุคที่เครือข่ายเปลี่ยนแปลงอย่างรวดเร็ว ตัวอย่างเช่น อีเทอร์เน็ตเป็นเพียงหนึ่งในตัวเลือก ไม่ใช่โปรโตคอลเครือข่ายภายในที่ใช้กันเสมอไป (ยังจำ token ring ได้หรือไม่) การเชื่อมต่ออินเทอร์เน็ตไม่ใช่เรื่องที่ถือเป็นค่าเริ่มต้น แต่เป็นเรื่องที่ต้องนำมาถกเถียงกัน การเชื่อมต่อแบบ dial-up ยังเป็นเรื่องปกติ และ AOL คือผู้เล่นรายใหญ่ที่สุด การบอกว่า firewall เป็นเทคโนโลยีกระแสหลักในเวลานั้น ย่อมสะท้อนความเข้าใจที่คลาดเคลื่อนว่าอินเทอร์เน็ตเองเป็นกระแสหลักแล้ว ผลพวงหนึ่งของเครือข่ายที่เปลี่ยนแปลงอย่างรวดเร็วคือความไม่รู้และการขาดประสบการณ์ในวงกว้าง ในบริบทเช่นนี้ ความสามารถในการบริหารจัดการ firewall จึงไม่ควรถูกมองข้าม เพราะเป็นปัจจัยขับเคลื่อนตลาดที่ชี้ขาดว่าใครจะเป็นผู้ชนะในท้ายที่สุด ทุกวันนี้ ในแวดวงการพัฒนาซอฟต์แวร์ เราพูดถึง User Experience และ Usability แม้คำเหล่านี้จะยังไม่ใช่คำฮิตในเวลานั้น แต่เหตุผลที่เราพูดถึงมันในวันนี้ก็สำคัญไม่ต่างกันเลยในยุคนั้น ลูกค้า "ชอบ" ผลิตภัณฑ์นี้มากกว่า ดังนั้น แม้ความปลอดภัยและประสิทธิภาพจะมีความสำคัญ แต่ก็ไม่ควรมองข้ามความใช้งานง่ายของ GUI บน firewall ของ Check Point ดังคำพูดของพนักงานขาย Gauntlet คนหนึ่งในเวลานั้นที่ว่า "ไม่ว่าลูกค้าเป้าหมายจะเป็นใคร ทุกบัญชีที่ผมเข้าไป ผมต้องสู้กับ GUI ของ Check Point และส่วนใหญ่ก็แพ้" Check Point เปิดตัว firewall ของตนพร้อมระบบบริหารจัดการแบบรวมศูนย์และอินเทอร์เฟซผู้ใช้ที่ล้ำสมัยอย่างมาก ความสามารถสำคัญบางส่วนได้แก่
- ตัวแก้ไขกฎแบบกราฟิก
- คลังอ็อบเจ็กต์ส่วนกลางที่ใช้ร่วมกันระหว่าง firewall policy ต่าง ๆ
- การจัดเก็บ log แบบรวมศูนย์
- การบริหารจัดการแบบ multi-domain และ OPSEC
Policy Editor ของ Check Point
แนวคิดที่ว่า firewall rule หนึ่งกฎประกอบด้วยองค์ประกอบ 5 ส่วน ได้แก่ ต้นทาง ปลายทาง โปรโตคอล พอร์ต (โปรโตคอลและพอร์ตถูกรวมเป็นอ็อบเจ็กต์เดียวที่เรียกว่า service) และแอ็กชัน มีมานานก่อนที่ policy editor ของ Check Point จะเกิดขึ้น access control list ในยุคแรกรองรับแนวคิดนี้มาตั้งแต่ทศวรรษ 1980 แต่ Check Point เปลี่ยนกระบวนทัศน์ด้วยตัวแก้ไขกฎแบบกราฟิก ผู้ใช้ไม่จำเป็นต้องรู้ไวยากรณ์ CLI เพื่อสร้างกฎอีกต่อไป เพียงใช้เมาส์คลิกไม่กี่ครั้งก็เพียงพอ นอกจากนี้ การแก้ไขกฎยังเสริมด้วยฟีเจอร์ที่เป็นประโยชน์ เช่น การคัดลอกและวาง การใส่คอมเมนต์ที่ผู้ใช้กำหนดเอง และการใส่หลายอ็อบเจ็กต์ในแต่ละคอลัมน์ ประเด็นสุดท้ายเรื่องการใส่หลายอ็อบเจ็กต์ในคอลัมน์เดียวถือเป็นการปฏิวัติ เพราะ access control list ก่อนหน้านั้นรองรับเพียงต้นทางเดียว ปลายทางเดียว และเซอร์วิสเดียวในแต่ละคอลัมน์ การรองรับหลายอ็อบเจ็กต์ทำให้แต่ละกฎทรงพลังยิ่งขึ้น และการแก้ไข policy มักกลายเป็นการปรับกฎที่มีอยู่แทนที่จะสร้างกฎใหม่ ความสามารถส่วนใหญ่ของ policy editor นี้ตั้งอยู่บนความก้าวหน้าอีกอย่างหนึ่ง นั่นคือคลังอ็อบเจ็กต์ส่วนกลาง
คลังอ็อบเจ็กต์ส่วนกลางของ Check Point
ในอดีต access control list ถูกสร้างขึ้นโดยอ้างอิง IP address เฉพาะเจาะจงสำหรับต้นทางหรือปลายทาง วิธีนี้ใช้งานได้ แต่หาก IP ของระบบใดเปลี่ยนไป ก็หมายความว่าทุกกฎที่เกี่ยวข้องต้องถูกแก้ไข เช่นเดียวกับการใช้ซอร์สโค้ดซ้ำ Check Point เล็งเห็นว่าการสร้างคลังอ็อบเจ็กต์ส่วนกลางและนำอ็อบเจ็กต์เหล่านั้นไปใช้ในกฎคือกลยุทธ์ที่ดีกว่า เมื่อโฮสต์เปลี่ยน IP ก็แก้ไขเพียงอ็อบเจ็กต์เดียว และ policy จะสะท้อนการเปลี่ยนแปลงนั้นได้อย่างถูกต้องโดยอัตโนมัติ เนื่องจาก policy อ้างอิงถึงอ็อบเจ็กต์ที่จัดเก็บไว้ นอกจากนี้ ยังสามารถสร้างกลุ่มของอ็อบเจ็กต์เหล่านี้ (รวมถึงกลุ่มของกลุ่ม) เพื่อให้นำกลุ่มอ็อบเจ็กต์ที่ใช้บ่อยกลับมาใช้ซ้ำได้ทั่วทั้ง policy ทั้งหมดนี้คือความก้าวหน้าครั้งสำคัญสู่การบริหารจัดการ policy ที่มีประสิทธิผลยิ่งขึ้น
การจัดเก็บ log แบบรวมศูนย์
ปัญหาที่พบบ่อยอย่างยิ่งของ firewall คือการบล็อกทราฟฟิกผิดตัว โดยเฉพาะเมื่อวาง firewall ระหว่างสองเครือข่ายที่ไม่เคยถูกแบ่งเซกเมนต์มาก่อน ซึ่งในช่วงปลายทศวรรษ 1990 แทบทุกการติดตั้ง firewall ใหม่ล้วนเป็นเช่นนั้น การรวมศูนย์ log ทั้งหมดของ firewall ไว้ในที่เดียวและค้นหาได้ง่าย ทำให้การวินิจฉัยข้อผิดพลาดของ policy ชัดเจนและง่ายขึ้นมากเมื่อเทียบกับก่อนหน้า ผู้ใช้สามารถแจ้งปัญหาพร้อมระบุคู่ IP ต้นทาง / IP ปลายทาง จากนั้นผู้ดูแลระบบก็ค้นหา log แบบ "drop" ใน log viewer พร้อมกฎที่ทำให้เกิดการ drop นั้นได้ (หรืออีกทางหนึ่งคือพบ log แบบ "accept" แล้วแจ้งผู้ใช้ว่าเข้าใจผิด) ความผิดพลาดในการดูแล firewall policy เคยเป็นและยังคงเป็นเรื่องปกติ ดังนั้นการแก้ไขปัญหาได้ง่ายจึงเป็นคุณค่าเพิ่มที่สำคัญของแพลตฟอร์ม firewall ทุกราย
การบริหารจัดการแบบ Multi-Domain และ OPSEC
ในช่วงต้นทศวรรษ 2000 Check Point เดิมพันหนักขึ้นกับพลังของการบริหารจัดการ ด้วยการเปิดตัวการจัดการแบบ multi-domain ผ่าน Provider-1 และ API สำหรับการเชื่อมต่อผ่าน OPSEC ทั้งสองอย่างคือการเดิมพันครั้งใหญ่ว่าการบริหารจัดการจะเป็นสิ่งที่แยก Check Point ออกจากคู่แข่ง firewall รายอื่น และมันก็ได้ผล Provider-1 ตามชื่อที่สื่อถึง มุ่งเป้าไปที่กลุ่มผู้ให้บริการ ทั้งผู้ให้บริการโทรคมนาคมและผู้ให้บริการแบบ managed service แม้ผู้ให้บริการจะเป็นกลุ่มแรกที่นำเทคโนโลยีนี้ไปใช้ แต่องค์กรขนาดใหญ่ก็พบเหตุผลที่จะใช้ผลิตภัณฑ์นี้เช่นกันอย่างรวดเร็ว ความสามารถสำคัญ ได้แก่ การควบคุมสิทธิ์ ประสิทธิภาพของการบริหารจัดการและ UI จากการแยก policy ขนาดใหญ่และฐานข้อมูลอ็อบเจ็กต์ออกจากกัน รวมถึง global rule ที่สามารถบังคับใช้ได้ทั่วทั้งองค์กร ล้วนเป็นฟีเจอร์ที่องค์กรขนาดใหญ่ต้องการ โดยส่วนใหญ่แล้วสิ่งเหล่านี้คือข้อจำกัดของแพลตฟอร์มการบริหารจัดการมาตรฐาน แม้บางคนอาจแย้งว่า Check Point ควรแก้ไขแพลตฟอร์มการบริหารจัดการเดิม แทนที่จะให้ลูกค้าจ่ายเพิ่มในราคาสูงสำหรับ Provider-1 แต่ลูกค้าก็เห็นประโยชน์และยินดีจ่ายเพื่อความสามารถด้านการบริหารจัดการขั้นสูงเหล่านี้ OPSEC คือโปรแกรมพันธมิตรและชุด API ที่ Check Point เผยแพร่เพื่อส่งเสริมการผสานการทำงานกับผลิตภัณฑ์ของบุคคลที่สาม ความสำเร็จในช่วงแรกรวมถึงผลิตภัณฑ์ด้านรายงานที่ใช้ Log Export API (LEA) ผลิตภัณฑ์กรอง URL ที่ใช้ URL Filtering Protocol (UFP) และผลิตภัณฑ์ด้านการบริหารจัดการ เช่น FireMon ที่ใช้ Check Point Management Interface (CPMI) โปรแกรมและการผสานการทำงานเหล่านี้ประสบความสำเร็จอย่างสูง ปัจจุบันมีพันธมิตร OPSEC มากกว่า 100 รายที่นำเสนอความสามารถในการเชื่อมต่อกับแพลตฟอร์มนี้ ระบบนิเวศของผลิตภัณฑ์ด้านความปลอดภัยนี้มอบคุณค่าเพิ่มและความมั่นใจในการลงทุนให้แก่ลูกค้า ทุกวันนี้เรามองว่าการเชื่อมต่อผ่าน API เป็นเรื่องปกติ แต่ในปี 2001 ซึ่งเป็นปีที่เปิดตัว OPSEC เรื่องนี้ยังไม่ใช่เรื่องธรรมดาเลย
Cisco และ CLI คือผู้เล่นรายใหญ่
ตลาดในเวลานั้นไม่ได้ถูกครองโดย Check Point และ GUI เพียงอย่างเดียว แม้ Check Point จะก้าวขึ้นเป็นผู้นำในตลาด firewall ด้วย GUI ที่ทรงพลังและใช้งานง่าย แต่ Cisco ยังคงยึดมั่นในรากฐานของตนด้วยอินเทอร์เฟซบรรทัดคำสั่ง (CLI) บน Pix โดย Pix เป็นคู่แข่งรุ่นแรก ๆ ในตลาด firewall ซึ่งมีมาตั้งแต่ปี 1994 และถูก Cisco เข้าซื้อกิจการในปี 1995 ความคุ้นเคยที่ผู้ดูแลระบบเครือข่ายมีต่อ Cisco และ CLI ทำให้ Pix เป็นตัวเลือกอันดับแรกเมื่อทีมเครือข่ายเป็นผู้รับผิดชอบงานด้านความปลอดภัย Check Point ค่อย ๆ บั่นทอนความได้เปรียบนี้ด้วยฟีเจอร์ด้านความปลอดภัยและ GUI โดยได้แรงหนุนจากการเปลี่ยนแปลงอย่างช้า ๆ ของโครงสร้างองค์กร ที่ทีมความปลอดภัยเริ่มแยกออกจากทีมเครือข่าย เมื่อการเปลี่ยนแปลงนี้เกิดขึ้น ความสัมพันธ์เดิมที่ Cisco มีกับทีมเครือข่ายก็มีบทบาทน้อยลงเรื่อย ๆ ในการเลือกผู้จำหน่าย firewall ความสามารถด้านการบริหารจัดการที่เหนือกว่าช่วยสร้างตำแหน่งของ Check Point ในตลาด และตอกย้ำคุณค่าของการบริหารจัดการสำหรับผลิตภัณฑ์ด้านความปลอดภัย แต่เช่นเดียวกับที่ประสิทธิภาพเคยช่วยให้ Check Point เอาชนะ proxy ได้ในทศวรรษ 1990 ในปีต่อ ๆ มา ประสิทธิภาพก็กลับมาเป็นเกณฑ์ตัดสินใจสำคัญอีกครั้ง และคราวนี้ Check Point คือฝ่ายที่ถูกคุกคาม ตอนที่ 3: เมื่อประสิทธิภาพกลายเป็นจุดสนใจหลัก