บทความนี้เป็นบทความที่สามในชุดบทความ “วิธีควบคุมโครงสร้างพื้นฐานเครือข่ายของคุณ” เนื้อหาบทความทั้งหมดในซีรีส์และลิงก์ต่างๆ สามารถพบได้ ที่นี่.

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

แน่นอนว่าการออกแบบความปลอดภัยได้รับการบูรณาการเข้ากับสถาปัตยกรรมโดยรวม และโซลูชันความปลอดภัยที่ใช้ส่งผลต่อความสามารถในการปรับขนาด ความน่าเชื่อถือ การจัดการ ... ของโครงสร้างพื้นฐานเครือข่าย ซึ่งควรนำมาพิจารณาด้วย

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

หน้าที่ของเราในตอนนี้คือการระบุความเสี่ยงที่เกี่ยวข้องกับความปลอดภัยในระดับเครือข่ายและลดความเสี่ยงให้อยู่ในระดับที่เหมาะสม

การตรวจสอบความปลอดภัยของเครือข่าย

หากองค์กรของคุณใช้กระบวนการ ISO 27k การตรวจสอบความปลอดภัยและการเปลี่ยนแปลงเครือข่ายควรจะเข้ากันได้อย่างลงตัวกับกระบวนการโดยรวมภายในแนวทางนี้ แต่มาตรฐานเหล่านี้ยังไม่เกี่ยวกับโซลูชันเฉพาะ ไม่เกี่ยวกับการกำหนดค่า ไม่เกี่ยวกับการออกแบบ... ไม่มีคำแนะนำที่ชัดเจน ไม่มีมาตรฐานที่กำหนดรายละเอียดว่าเครือข่ายของคุณควรเป็นอย่างไร นี่คือความซับซ้อนและความสวยงามของงานนี้

ฉันจะเน้นการตรวจสอบความปลอดภัยเครือข่ายที่เป็นไปได้หลายประการ:

• การตรวจสอบการกำหนดค่าอุปกรณ์ (การชุบแข็ง)
• การตรวจสอบการออกแบบความปลอดภัย
• การตรวจสอบการเข้าถึง
• การตรวจสอบกระบวนการ

การตรวจสอบการกำหนดค่าอุปกรณ์ (การชุบแข็ง)

ดูเหมือนว่าในกรณีส่วนใหญ่ นี่คือจุดเริ่มต้นที่ดีที่สุดสำหรับการตรวจสอบและปรับปรุงความปลอดภัยของเครือข่ายของคุณ IMHO นี่เป็นการสาธิตกฎของพาเรโตที่ดี (ความพยายาม 20% ก่อให้เกิดผลลัพธ์ 80% และความพยายาม 80% ที่เหลือก่อให้เกิดผลลัพธ์เพียง 20% เท่านั้น)

สิ่งสำคัญที่สุดคือเรามักจะได้รับคำแนะนำจากผู้ขายเกี่ยวกับ “แนวทางปฏิบัติที่ดีที่สุด” เพื่อความปลอดภัยเมื่อกำหนดค่าอุปกรณ์ สิ่งนี้เรียกว่า "การแข็งตัว"

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

ตัวอย่างต่างๆ สำหรับระบบปฏิบัติการ Cisco บางระบบ

การแข็งตัวของการกำหนดค่า Cisco IOS
การแข็งตัวของการกำหนดค่า Cisco IOS-XR
การทำให้แข็งตัวของการกำหนดค่า Cisco NX-OS
รายการตรวจสอบความปลอดภัยของ Cisco Baseline

จากเอกสารเหล่านี้ คุณสามารถสร้างรายการข้อกำหนดการกำหนดค่าสำหรับอุปกรณ์แต่ละประเภทได้ ตัวอย่างเช่น สำหรับ Cisco N7K VDC ข้อกำหนดเหล่านี้อาจมีลักษณะเช่นนี้ ดังนั้น.

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

การตรวจสอบการออกแบบความปลอดภัย

โดยทั่วไปแล้ว เครือข่ายองค์กรประกอบด้วยส่วนต่างๆ ต่อไปนี้ในรูปแบบใดรูปแบบหนึ่ง:

• DC (บริการสาธารณะ DMZ และศูนย์ข้อมูลอินทราเน็ต)
• การเข้าถึงอินเทอร์เน็ต
• VPN การเข้าถึงระยะไกล
• ขอบแวน
• สาขา
• วิทยาเขต (สำนักงาน)
• แกน

ชื่อเรื่องนำมาจาก ซิสโก้เซฟ แต่แน่นอนว่าไม่จำเป็นต้องแนบกับชื่อเหล่านี้และกับโมเดลนี้อย่างแม่นยำ ถึงกระนั้น ฉันอยากจะพูดถึงสาระสำคัญและไม่จมอยู่กับพิธีการ

สำหรับแต่ละส่วนเหล่านี้ ข้อกำหนดด้านความปลอดภัย ความเสี่ยง และโซลูชั่นจะแตกต่างกัน

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

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

ศูนย์ข้อมูล

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

ไฟร์วอลล์จำเป็นหรือไม่?

ดูเหมือนว่าคำตอบจะชัดเจน แต่ทุกอย่างยังไม่ชัดเจนเท่าที่ควร และทางเลือกของคุณจะได้รับอิทธิพลไม่เพียงเท่านั้น ราคา.

1 ตัวอย่าง ความล่าช้า

หากเวลาแฝงต่ำเป็นข้อกำหนดที่สำคัญระหว่างส่วนเครือข่ายบางส่วน เช่น เป็นจริงในกรณีของการแลกเปลี่ยน เราจะไม่สามารถใช้ไฟร์วอลล์ระหว่างส่วนเหล่านี้ได้ เป็นการยากที่จะศึกษาการศึกษาเกี่ยวกับเวลาแฝงในไฟร์วอลล์ แต่สวิตช์บางรุ่นสามารถให้เวลาแฝงน้อยกว่าหรืออยู่ในลำดับที่ 1 mksec ดังนั้นฉันคิดว่าหากไมโครวินาทีมีความสำคัญต่อคุณ ไฟร์วอลล์ก็ไม่เหมาะกับคุณ

2 ตัวอย่าง ประสิทธิภาพ.

ปริมาณงานของสวิตช์ L3 ระดับบนสุดมักจะมีลำดับความสำคัญสูงกว่าปริมาณงานของไฟร์วอลล์ที่ทรงพลังที่สุด ดังนั้นในกรณีของการรับส่งข้อมูลที่มีความหนาแน่นสูง คุณมักจะต้องอนุญาตให้การรับส่งข้อมูลนี้เลี่ยงผ่านไฟร์วอลล์ด้วย

3 ตัวอย่าง ความเชื่อถือได้

ไฟร์วอลล์ โดยเฉพาะ NGFW (Next-Generation FW) สมัยใหม่เป็นอุปกรณ์ที่ซับซ้อน พวกมันซับซ้อนกว่าสวิตช์ L3/L2 มาก พวกเขาให้บริการและตัวเลือกการกำหนดค่าจำนวนมาก จึงไม่น่าแปลกใจที่ความน่าเชื่อถือจะต่ำกว่ามาก หากความต่อเนื่องของบริการมีความสำคัญต่อเครือข่าย คุณอาจต้องเลือกสิ่งที่จะทำให้มีความพร้อมใช้งานดีขึ้น - การรักษาความปลอดภัยด้วยไฟร์วอลล์หรือความเรียบง่ายของเครือข่ายที่สร้างบนสวิตช์ (หรือแฟบริคประเภทต่างๆ) โดยใช้ ACL ปกติ

ในกรณีของตัวอย่างข้างต้น คุณมักจะต้องหาทางประนีประนอม (ตามปกติ) ดูแนวทางแก้ไขต่อไปนี้:

• หากคุณตัดสินใจที่จะไม่ใช้ไฟร์วอลล์ภายในศูนย์ข้อมูล คุณต้องคิดถึงวิธีจำกัดการเข้าถึงโดยรอบให้มากที่สุด ตัวอย่างเช่น คุณสามารถเปิดเฉพาะพอร์ตที่จำเป็นจากอินเทอร์เน็ต (สำหรับการรับส่งข้อมูลไคลเอนต์) และการเข้าถึงศูนย์ข้อมูลระดับผู้ดูแลระบบจากโฮสต์ข้ามเท่านั้น บนโฮสต์แบบข้าม ให้ดำเนินการตรวจสอบที่จำเป็นทั้งหมด (การรับรองความถูกต้อง/การอนุญาต โปรแกรมป้องกันไวรัส การบันทึก ...)
• คุณสามารถใช้โลจิคัลพาร์ติชันของเครือข่ายศูนย์ข้อมูลเป็นเซ็กเมนต์ได้ คล้ายกับรูปแบบที่อธิบายไว้ใน PSEFABRIC ตัวอย่าง p002. ในกรณีนี้ การกำหนดเส้นทางจะต้องได้รับการกำหนดค่าในลักษณะที่การรับส่งข้อมูลที่มีความอ่อนไหวต่อความล่าช้าหรือมีความเข้มข้นสูงจะไป "ภายใน" หนึ่งเซกเมนต์ (ในกรณีของ p002, VRF) และไม่ผ่านไฟร์วอลล์ การรับส่งข้อมูลระหว่างส่วนต่างๆ จะยังคงผ่านไฟร์วอลล์ คุณยังสามารถใช้เส้นทางที่รั่วไหลระหว่าง VRF เพื่อหลีกเลี่ยงการเปลี่ยนเส้นทางการรับส่งข้อมูลผ่านไฟร์วอลล์
• คุณยังสามารถใช้ไฟร์วอลล์ในโหมดโปร่งใสและสำหรับ VLAN เท่านั้นที่ปัจจัยเหล่านี้ (เวลาแฝง/ประสิทธิภาพ) ไม่มีนัยสำคัญ แต่คุณต้องศึกษาข้อจำกัดที่เกี่ยวข้องกับการใช้ม็อดนี้สำหรับผู้จำหน่ายแต่ละรายอย่างรอบคอบ
• คุณอาจต้องการพิจารณาใช้สถาปัตยกรรมห่วงโซ่บริการ ซึ่งจะอนุญาตให้เฉพาะการรับส่งข้อมูลที่จำเป็นเท่านั้นที่จะผ่านไฟร์วอลล์ ดูดีในทางทฤษฎี แต่ฉันไม่เคยเห็นวิธีแก้ปัญหานี้ในการผลิต เราทดสอบห่วงโซ่บริการสำหรับ Cisco ACI/Juniper SRX/F5 LTM เมื่อประมาณ 3 ปีที่แล้ว แต่ในเวลานั้นโซลูชันนี้ดูเหมือน "หยาบคาย" สำหรับเรา

ระดับการป้องกัน

ตอนนี้คุณต้องตอบคำถามว่าคุณต้องการใช้เครื่องมือใดในการกรองการรับส่งข้อมูล ต่อไปนี้เป็นคุณลักษณะบางอย่างที่มักมีอยู่ใน NGFW (ตัวอย่างเช่น ที่นี่):

• ไฟร์วอลล์ stateful (ค่าเริ่มต้น)
• ไฟร์วอลล์แอปพลิเคชัน
• การป้องกันภัยคุกคาม (แอนตี้ไวรัส แอนตี้สปายแวร์ และช่องโหว่)
• การกรอง URL
• การกรองข้อมูล (การกรองเนื้อหา)
• การบล็อกไฟล์ (การบล็อกประเภทไฟล์)
• การป้องกัน

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

• ยิ่งคุณใช้ฟังก์ชันไฟร์วอลล์ข้างต้นมากเท่าใด ราคาก็จะยิ่งแพงมากขึ้นเท่านั้น (ใบอนุญาต โมดูลเพิ่มเติม)
• การใช้อัลกอริธึมบางอย่างสามารถลดปริมาณงานไฟร์วอลล์ได้อย่างมาก และยังเพิ่มความล่าช้าอีกด้วย ดูตัวอย่าง ที่นี่
• เช่นเดียวกับโซลูชันที่ซับซ้อนอื่นๆ การใช้วิธีการป้องกันที่ซับซ้อนสามารถลดความน่าเชื่อถือของโซลูชันของคุณได้ ตัวอย่างเช่น เมื่อใช้ไฟร์วอลล์แอปพลิเคชัน ฉันพบว่ามีการบล็อกแอปพลิเคชันการทำงานที่ค่อนข้างมาตรฐาน (dns, smb)

และเช่นเคย คุณจะต้องค้นหาโซลูชันที่ดีที่สุดสำหรับเครือข่ายของคุณ

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

ดังนั้น ในส่วนที่สำคัญ ทางออกที่ดีอาจเป็นการใช้ข้อเสนอจากบริษัทต่างๆ ตัวอย่างเช่น คุณสามารถเปิดใช้งานโปรแกรมป้องกันไวรัสบนไฟร์วอลล์ แต่ยังใช้การป้องกันไวรัส (จากผู้ผลิตรายอื่น) ภายในโฮสต์ได้

การแบ่งส่วน

เรากำลังพูดถึงการแบ่งส่วนเชิงตรรกะของเครือข่ายศูนย์ข้อมูล ตัวอย่างเช่น การแบ่งพาร์ติชันเป็น VLAN และซับเน็ตก็เป็นการแบ่งส่วนแบบลอจิคัลเช่นกัน แต่เราจะไม่พิจารณาเนื่องจากความชัดเจน การแบ่งส่วนที่น่าสนใจโดยคำนึงถึงเอนทิตีเช่นโซนความปลอดภัย FW, VRF (และแอนะล็อกที่เกี่ยวข้องกับผู้จำหน่ายหลายราย), อุปกรณ์ลอจิคัล (PA VSYS, Cisco N7K VDC, ผู้เช่า Cisco ACI, ... ), ...

ตัวอย่างของการแบ่งส่วนแบบลอจิคัลและการออกแบบศูนย์ข้อมูลที่เป็นที่ต้องการในปัจจุบันมีระบุไว้ในนี้ p002 ของโครงการ PSEFABRIC.

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

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

บ่อยครั้งที่การแบ่งส่วนจะขึ้นอยู่กับโซนความปลอดภัย FW เท่านั้น จากนั้นคุณจะต้องตอบคำถามต่อไปนี้:

• คุณต้องการโซนความปลอดภัยอะไร
• คุณต้องการใช้การป้องกันระดับใดกับแต่ละโซนเหล่านี้
• การรับส่งข้อมูลภายในโซนจะได้รับอนุญาตตามค่าเริ่มต้นหรือไม่
• ถ้าไม่เช่นนั้นจะใช้นโยบายการกรองการรับส่งข้อมูลใดภายในแต่ละโซน
• นโยบายการกรองการรับส่งข้อมูลใดที่จะนำไปใช้กับแต่ละคู่โซน (ต้นทาง/ปลายทาง)

TCAM

ปัญหาที่พบบ่อยคือ TCAM (Ternary Content Addressable Memory) ไม่เพียงพอ ทั้งสำหรับการกำหนดเส้นทางและการเข้าถึง IMHO นี่เป็นหนึ่งในปัญหาที่สำคัญที่สุดในการเลือกอุปกรณ์ ดังนั้นคุณต้องปฏิบัติต่อปัญหานี้ด้วยความระมัดระวังในระดับที่เหมาะสม

ตัวอย่างที่ 1 ตารางการส่งต่อ TCAM

ลองพิจารณากัน ปาโลอัลโต 7k ไฟร์วอลล์
เราจะเห็นว่าขนาดตารางการส่งต่อ IPv4* = 32K
ยิ่งไปกว่านั้น เส้นทางจำนวนนี้เป็นเรื่องปกติสำหรับ VSYS ทั้งหมด

สมมติว่าตามการออกแบบของคุณ คุณตัดสินใจใช้ 4 VSYS
VSYS แต่ละตัวเชื่อมต่อผ่าน BGP กับ MPLS PE สองตัวของระบบคลาวด์ที่คุณใช้เป็น BB ดังนั้น 4 VSYS จึงแลกเปลี่ยนเส้นทางเฉพาะทั้งหมดระหว่างกัน และมีตารางการส่งต่อที่มีชุดเส้นทางเดียวกันโดยประมาณ (แต่ NH ต่างกัน) เพราะ VSYS แต่ละรายการมี 2 เซสชัน BGP (ด้วยการตั้งค่าเดียวกัน) จากนั้นแต่ละเส้นทางที่ได้รับผ่าน MPLS จะมี 2 NH และรายการ FIB 2 รายการในตารางการส่งต่อตามลำดับ หากเราถือว่านี่เป็นไฟร์วอลล์ตัวเดียวในศูนย์ข้อมูลและต้องทราบเส้นทางทั้งหมด นั่นหมายความว่าจำนวนเส้นทางทั้งหมดในศูนย์ข้อมูลของเราไม่สามารถเกิน 32K/(4 * 2) = 4K

ตอนนี้ ถ้าเราสมมติว่าเรามีศูนย์ข้อมูล 2 แห่ง (ที่มีการออกแบบเหมือนกัน) และเราต้องการใช้ VLAN แบบ "ขยาย" ระหว่างศูนย์ข้อมูล (เช่น สำหรับ vMotion) ดังนั้น เพื่อแก้ไขปัญหาการกำหนดเส้นทาง เราต้องใช้เส้นทางของโฮสต์ . แต่นั่นหมายความว่าสำหรับศูนย์ข้อมูล 2 แห่ง เราจะมีโฮสต์ที่เป็นไปได้ไม่เกิน 4096 แห่ง และแน่นอนว่านี่อาจไม่เพียงพอ

ตัวอย่างที่ 2 ACL TCAM

หากคุณวางแผนที่จะกรองการรับส่งข้อมูลบนสวิตช์ L3 (หรือโซลูชันอื่น ๆ ที่ใช้สวิตช์ L3 เช่น Cisco ACI) เมื่อเลือกอุปกรณ์ คุณควรคำนึงถึง TCAM ACL

สมมติว่าคุณต้องการควบคุมการเข้าถึงอินเทอร์เฟซ SVI ของ Cisco Catalyst 4500 จากนั้น ดังที่เห็นได้จาก ของบทความนี้เพื่อควบคุมการรับส่งข้อมูลขาออก (รวมถึงขาเข้า) บนอินเทอร์เฟซ คุณสามารถใช้ TCAM ได้เพียง 4096 บรรทัดเท่านั้น ซึ่งเมื่อใช้ TCAM3 จะทำให้คุณได้ประมาณ 4000 ACEs (เส้น ACL)

หากคุณประสบปัญหา TCAM ที่ไม่เพียงพอ ก่อนอื่นคุณต้องพิจารณาถึงความเป็นไปได้ของการเพิ่มประสิทธิภาพ ดังนั้นในกรณีที่เกิดปัญหากับขนาดของ Forwarding Table จะต้องคำนึงถึงความเป็นไปได้ในการรวมเส้นทางด้วย ในกรณีที่เกิดปัญหากับขนาด TCAM สำหรับการเข้าถึง ตรวจสอบการเข้าถึง ลบบันทึกที่ล้าสมัยและทับซ้อนกัน และอาจแก้ไขขั้นตอนในการเปิดการเข้าถึง (จะกล่าวถึงรายละเอียดในบทเกี่ยวกับการตรวจสอบการเข้าถึง)

ความพร้อมใช้งานสูง

คำถามคือ: ฉันควรใช้ HA สำหรับไฟร์วอลล์หรือติดตั้งกล่องแยกกันสองกล่อง “พร้อมกัน” และหากกล่องใดกล่องหนึ่งล้มเหลว ให้กำหนดเส้นทางการรับส่งข้อมูลผ่านกล่องที่สอง

ดูเหมือนว่าคำตอบจะชัดเจน - ใช้ HA เหตุผลที่คำถามนี้ยังคงเกิดขึ้นก็คือ น่าเสียดายที่ในทางทฤษฎีและการโฆษณา 99 และเปอร์เซ็นต์การเข้าถึงที่เป็นทศนิยมหลายเปอร์เซ็นต์ในทางปฏิบัติ กลับกลายเป็นว่าห่างไกลจากสีดอกกุหลาบนัก HA เป็นสิ่งที่ค่อนข้างซับซ้อนในทางตรรกะ และบนอุปกรณ์ที่แตกต่างกัน และด้วยผู้จำหน่ายที่แตกต่างกัน (ไม่มีข้อยกเว้น) เราพบปัญหา ข้อบกพร่อง และการหยุดให้บริการ

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

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

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

ความสามารถในการจัดการ

โดยหลักการแล้ว HA ยังเกี่ยวกับความสามารถในการควบคุมด้วย แทนที่จะต้องกำหนดค่า 2 กล่องแยกกันและจัดการกับปัญหาในการรักษาการกำหนดค่าให้ตรงกัน คุณจะจัดการได้มากเหมือนกับว่าคุณมีอุปกรณ์เครื่องเดียว

แต่บางทีคุณอาจมีศูนย์ข้อมูลจำนวนมากและไฟร์วอลล์จำนวนมาก คำถามนี้ก็เกิดขึ้นในอีกระดับหนึ่ง และคำถามไม่ได้เกี่ยวกับการกำหนดค่าเท่านั้น แต่ยังรวมถึงด้วย

• การกำหนดค่าการสำรองข้อมูล
• อัปเดต
• การอัพเกรด
• การตรวจสอบ
• การบันทึก

และทั้งหมดนี้สามารถแก้ไขได้ด้วยระบบการจัดการแบบรวมศูนย์

ตัวอย่างเช่น หากคุณใช้ไฟร์วอลล์ Palo Alto ภูมิประเทศ เป็นวิธีแก้ปัญหาดังกล่าว

จะยังคง

ที่มา: will.com