บทความโดย: ดร. วิรินทร์ เมฆประดิษฐสิน
ในโลกของการดูแลระบบเครือข่ายระดับองค์กร (Enterprise Networking) สิ่งที่น่ากลัวที่สุดไม่ใช่การมี Policy จำนวนมาก แต่คือการมี Policy ที่ “แก้ไขยาก” และ “จำไม่ได้ว่า IP นี้คือของใคร” ครับ ลองจินตนาการว่าหากคุณมี 50 Policy ที่อ้างอิงถึง IP ของ Web Server เครื่องหนึ่ง แล้ววันหนึ่ง Server นั้นต้องเปลี่ยน IP ใหม่… คุณคงไม่อยากเข้าไปไล่แก้ทั้ง 50 จุดแน่นอน
นี่คือเหตุผลที่ Objects ถูกสร้างขึ้นมา เพื่อเปลี่ยนจากการจัดการ “ตัวเลข” ให้กลายเป็นการจัดการ “ชื่อและกลุ่ม” ซึ่งช่วยลด Human Error และเพิ่มความเร็วในการทำงานมหาศาลครับ
1. Address Objects: การให้ “ตัวตน” กับตัวเลข IP
เราสามารถเปรียบเทียบ Address Object เหมือนกับ “สมุดรายชื่อโทรศัพท์” ครับ แทนที่เราจะจำเบอร์โทร (IP Address) เราจำแค่ชื่อเพื่อน (Object Name) ก็พอ ใน FortiGate เราสามารถสร้าง Address Object ได้หลายรูปแบบตามความเหมาะสมของหน้างาน
1.1 ประเภทของ Address Objects (Type Definitions)
- IP/Netmask: พื้นฐานที่สุด เช่น 192.168.1.10/32 (รายเครื่อง) หรือ 192.168.1.0/24 (ทั้งวง)
- IP Range: ระบุจุดเริ่มต้นและสิ้นสุด เช่น 10.0.0.50 – 10.0.0.100 เหมาะสำหรับวง DHCP
- FQDN (Fully Qualified Domain Name): การระบุตัวตนด้วยชื่อโดเมน เช่น *.google.com ข้อดีคือหาก Google เปลี่ยน IP ระบบ FortiGate จะทำการ Resolve DNS และอัปเดตให้อัตโนมัติ (Dynamic Mapping)
- Geography: การระบุด้วย “ประเทศ” เช่น Thailand, Russia, China เหมาะมากสำหรับการทำ Geo-Blocking เพื่อป้องกันการโจมตีจากต่างประเทศที่ธุรกิจเราไม่ได้ติดต่อด้วย
1.2 Address Groups: พลังของการรวมศูนย์
เมื่อมี Address Object รายตัวแล้ว ขั้นต่อมาคือการสร้าง Groups ครับ เช่น เราสร้างกลุ่ม Accounting_Servers ที่รวมเอา IP ของ Server บัญชีทุกตัวไว้ด้วยกัน
- ข้อดี: หากมี Server ใหม่เพิ่มเข้ามา เราแค่เพิ่ม Object เข้าไปใน Group… Policy ทุกข้อที่ใช้ Group นี้จะทำงานได้ทันทีโดยไม่ต้องไปแตะต้องตัว Policy เลยแม้แต่น้อย
2. Service Objects: การนิยาม “ภารกิจ” ของทราฟฟิก
ถ้า Address คือ “ใคร” Service ก็คือ “ทำอะไร” ครับ Service Object คือการรวมเอา Protocol (TCP/UDP/ICMP) และ Port Number เข้าด้วยกัน
2.1 Predefined vs. Custom Services
- Predefined Services: FortiGate เตรียมบริการมาตรฐานไว้ให้แล้วเกือบทุกอย่าง เช่น HTTP (80), HTTPS (443), DNS (53) หรือ SSH (22)
- Custom Services: ในกรณีที่แอปพลิเคชันภายในองค์กรใช้พอร์ตแปลกๆ เช่น โปรแกรมบัญชีที่วิ่งพอร์ต TCP 9999 เราต้องสร้าง Custom Service ขึ้นมาเอง เพื่อให้ Policy ของเรามีความ Granular (ละเอียด) มากที่สุด ไม่ควรใช้คำว่า ALL ในการตั้งค่า Service หากไม่จำเป็นจริงๆ เพื่อลดช่องโหว่ (Attack Surface)
2.2 Service Groups
คล้ายกับ Address Group ครับ เช่น เราสร้างกลุ่ม Web_Services ที่รวมเอา HTTP และ HTTPS ไว้ด้วยกัน ทำให้การเขียน Policy ดูสะอาดตาและเข้าใจง่ายขึ้น
3. Schedules: มิติของ “กาลเวลา” ในโลกความปลอดภัย
ทำไมเราต้องปล่อยให้พนักงานเข้า Facebook ได้ตลอด 24 ชั่วโมง? หรือทำไมต้องเปิดช่องทาง VPN ทิ้งไว้ในช่วงที่ไม่มีคนทำงาน? Schedules คือคำตอบครับ
3.1 ประเภทของ Schedule ใน FortiOS
- One-Time: กำหนดช่วงเวลาแบบครั้งเดียวจบ เช่น “อนุญาตให้ทีม Vendor เข้ามาบำรุงรักษาเฉพาะวันอาทิตย์นี้เวลา 09:00 – 12:00” หลังจากนั้น Policy จะปิดตัวเองอัตโนมัติ
- Recurring: กำหนดช่วงเวลาที่เกิดขึ้นซ้ำๆ เช่น “อนุญาตให้ใช้งาน Social Media ได้เฉพาะช่วงพักเที่ยง 12:00 – 13:00 และหลังเลิกงาน 17:00 – 19:00 ของทุกวันจันทร์-ศุกร์”
3.2 การรวม Schedule เข้ากับ Policy
เมื่อนำ Schedule ไปแปะไว้ใน Policy ระบบจะทำการตรวจสอบเงื่อนไขเวลาเป็นอันดับแรกๆ หากไม่ได้อยู่ในช่วงเวลาที่กำหนด Policy นั้นจะไม่ทำงาน (Mismatch) ซึ่งช่วยประหยัดทรัพยากรเครื่องได้มาก
4. ยุทธศาสตร์การตั้งชื่อ (Naming Convention) ระดับมือโปร
สิ่งที่จะแยกแยะวิศวกรที่เก่งออกจาก Admin ทั่วไป คือ “ระเบียบในการตั้งชื่อ” ครับ การตั้งชื่อ Object ที่ดีต้องทำให้คนที่มาดูต่อรู้ทันทีว่ามันคืออะไรโดยไม่ต้องคลิกเข้าไปดู
ตัวอย่างการตั้งชื่อที่แนะนำ
- Address: LAN_Srv_Accounting_10.1.1.5 (บอก Zone, บอกประเภท, บอกชื่อ, และบอก IP ท้ายชื่อ)
- Group: GRP_Srv_Database (ขึ้นต้นด้วย GRP เพื่อให้หาใน List ได้ง่าย)
- Service: TCP_9999_Internal_App (บอกโปรโตคอลและพอร์ตชัดเจน)
5. เทคนิคขั้นสูง: Dynamic Objects & Internet Service Database (ISDB)
นอกเหนือจาก Object ที่เราสร้างเอง FortiGate ยังมี ISDB ซึ่งเป็นฐานข้อมูลขนาดใหญ่ที่ Fortinet อัปเดตให้ตลอดเวลา
- ISDB คืออะไร: มันคือการรวบรวม IP ทั้งหมดของบริการดังๆ เช่น Microsoft 365, AWS, Facebook หรือ YouTube ไว้เป็นกลุ่มเดียว
- การใช้งาน: แทนที่เราจะมานั่งไล่หา IP ของ Microsoft 365 ซึ่งมีเป็นพันช่วง เราแค่ใช้ Object Microsoft-Office365 ใน Policy ได้เลย ระบบจะจัดการให้เราเองแบบ Real-time (Dynamic)
6. การดูแลรักษา Object (Maintenance & Audit)
เมื่อเวลาผ่านไป Objects อาจจะล้นระบบ ดร. วิรินทร์ แนะนำให้ตรวจสอบดังนี้
- Unused Objects: ในหน้า GUI ของ FortiGate ตรงช่อง Ref. (Reference) หากขึ้นตัวเลข 0 แสดงว่า Object นั้นไม่มี Policy ไหนใช้งานเลย ควรลบออกเพื่อความสะอาดของฐานข้อมูล
- Object Search: ใช้ปุ่มค้นหาที่มุมบนขวาเพื่อหาว่า IP นี้ถูกตั้งชื่อว่าอะไร เพื่อป้องกันการสร้าง Object ซ้ำซ้อน (Duplicated Objects)
- Color Coding: ใช้ “สี” ในการจำแนกประเภทของ Object เช่น สีแดงสำหรับ Server สำคัญ, สีเขียวสำหรับ User ทั่วไป เพื่อช่วยในการมองเห็น (Visual Aid)
7. บทสรุป: รากฐานของการทำ Automation
การใช้ Objects อย่างเป็นระบบในวันนี้ คือรากฐานของการทำ Network Automation ในวันหน้าครับ เพราะเมื่อคุณมี Object Name ที่เป็นมาตรฐาน คุณจะสามารถเขียน Script หรือใช้เครื่องมืออย่าง Ansible/Terraform มาสั่งการ FortiGate ได้อย่างแม่นยำ
การใช้ Objects ไม่ใช่แค่เรื่องของความสะดวกสบาย แต่มันคือการสร้าง “โครงสร้างที่ขยายตัวได้” (Scalable Architecture) เพื่อรองรับ Policy ที่อาจจะเพิ่มขึ้นเป็นพันข้อในอนาคตโดยไม่ทำให้ระบบจัดการล้มเหลว
ในบทความถัดไป (บทที่ 5) เราจะก้าวข้ามจากเลเยอร์ 3 ขึ้นไปสู่เรื่องของ Layer 2 & Advanced Networking เราจะมาดูวิธีการรวมสายสัญญาณ (Link Aggregation) เพื่อเพิ่มความแรง และการแบ่งโซนเครือข่ายระดับลึก (VLAN & Segmentation) เพื่อกักบริเวณภัยคุกคามไม่ให้ลามไปทั้งองค์กรครับ
💡 เกร็ดความรู้
- Object Global Search: หากคุณไม่แน่ใจว่าสร้าง Object ไว้หรือยัง ในหน้า GUI ให้กด Ctrl + Alt + G เพื่อใช้ Global Search ค้นหาทุกอย่างในระบบได้ทันที
- FQDN Object Cache: FortiGate จะเก็บ Cache ของ FQDN ไว้ตามค่า TTL ของ DNS ดังนั้นหากคุณเปลี่ยน IP ที่ DNS Server เครื่อง FortiGate จะรู้ตัวและอัปเดตเองในเวลาไม่นานครับ