ติดตั้ง Wazuh: วางแผนสเปกเครื่อง เก็บ log และ rollout agent

การวางแผนติดตั้ง Wazuh คือการตัดสินใจก่อนลงมือว่าจะวาง Wazuh indexer, Wazuh server และ Wazuh dashboard บนเครื่องเดียวหรือแยกเครื่อง ใช้เครื่องขนาดเท่าไรตามจำนวน agent และปริมาณ alert เก็บ log นานเท่าไรและเก็บอย่างไร และจะติดตั้ง agent บนเครื่องเดิมทั้งหมดเป็นรอบอย่างไร โดยไม่ให้ alert ท่วมจนทีมอ่านไม่ทัน

บทความนี้เขียนสำหรับผู้ดูแลระบบและ IT Manager ที่ตัดสินใจใช้ Wazuh แล้ว และต้องเตรียมเครื่อง พื้นที่ดิสก์ และแผนติดตั้ง ถ้ายังประเมินอยู่ว่า Wazuh ทำอะไรได้และเหมาะกับองค์กรหรือไม่ อ่าน Wazuh คืออะไร และ Wazuh กับ Endpoint Detection and Response (EDR) ต่างกันอย่างไร ก่อน ข้อมูลทางเทคนิคอ้างอิงเอกสาร Wazuh 4.14 (รุ่นล่าสุดคือ 4.14.9 ออกเมื่อ 14 ตุลาคม 2026) ตรวจ ณ วันที่ 2 พฤศจิกายน 2026

วางแผนติดตั้ง Wazuh ต้องวางองค์ประกอบอะไรบ้าง?

Wazuh มี agent ที่ติดตั้งบนเครื่องปลายทาง และส่วนกลางสามตัว คือ Wazuh server (manager) ที่วิเคราะห์ข้อมูล Wazuh indexer ที่เก็บและค้นหา alert และ Wazuh dashboard ที่เป็นหน้าจอเว็บ ตามหน้า Wazuh architecture agent เก็บข้อมูลความปลอดภัยแล้วส่งต่อให้ server วิเคราะห์ หน้าที่ของแต่ละส่วนโดยละเอียดอยู่ใน Wazuh คืออะไร บทความนี้เน้นว่าจะวางส่วนเหล่านี้อย่างไร

คู่มือติดตั้ง เรียงลำดับการติดตั้งส่วนกลางเป็น indexer ก่อน ตามด้วย server แล้วจึง dashboard แต่ละส่วนติดตั้งได้สองวิธี คือ Assisted installation และ Step-by-step installation ส่วนกลางทั้งสามรองรับ Amazon Linux 2 และ 2023, CentOS Stream 10, Red Hat Enterprise Linux 7, 8, 9 และ 10 และ Ubuntu 16.04, 18.04, 20.04, 22.04 และ 24.04 บนหน่วยประมวลผล 64 บิต (x86_64 หรือ ARM64)

Wazuh ยังมี Open Virtual Appliance (OVA) สำเร็จรูปบน Amazon Linux 2023 ตามหน้า Virtual machine VM รุ่น 4.14.9 ตั้งค่าเริ่มต้นไว้ที่ 4 CPU core, RAM 8 GB และดิสก์ 50 GB ใช้ได้เฉพาะ x86_64 และไม่มี high availability หรือการขยายระบบให้ในตัว เหมาะกับการทดลองมากกว่าระบบจริง ส่วนกลางทั้งสามติดตั้งบน VM ที่ใช้ Linux รุ่นที่รองรับได้เช่นกัน

ก่อนวางเครื่อง ให้คุยกับทีม network เรื่องพอร์ต เพราะ agent ในหลาย VLAN หรือหลายสาขาต้องเข้าถึง server ได้ พอร์ตเริ่มต้นตามเอกสารมีดังนี้ (เปลี่ยนได้)

ในมุมมองของเรา คำถามแรกที่ควรตอบไม่ใช่ "ใช้กี่เครื่อง" แต่คือ "ถ้า server หรือ indexer ล่ม ยอมรับได้นานแค่ไหน" ถ้ายอมรับไม่ได้ ให้ออกแบบเป็น cluster ตั้งแต่แรก แทนที่จะเริ่มจาก all-in-one แล้วค่อยย้ายข้อมูลภายหลัง

ประเมินขนาดเครื่อง Wazuh จากอะไร?

ขนาดเครื่องขึ้นกับสามเรื่อง คือ จำนวนและประเภทของเครื่องที่ส่งข้อมูล จำนวน alert ต่อวินาที (alerts per second, APS) ที่เครื่องเหล่านั้นสร้าง และจำนวนวันที่ต้องค้น alert ย้อนหลังได้ จำนวน agent อย่างเดียวบอกไม่ได้ เพราะอุปกรณ์เครือข่ายหนึ่งชิ้นอาจสร้าง alert มากกว่าเครื่องผู้ใช้หลายเท่า

สำหรับระบบไม่เกินประมาณ 100 endpoint ที่เก็บ alert 90 วัน Wazuh quickstart ให้ขนาดเครื่องแบบ all-in-one ไว้เป็นสามช่วงตามจำนวน agent

quickstart แนะนำให้ระบบที่ใหญ่กว่านั้นแยกเครื่อง (distributed deployment) เมื่อแยกเครื่อง คู่มือติดตั้งแต่ละส่วนกำหนดสเปกไว้ดังนี้

ดิสก์ของ indexer

คู่มือติดตั้ง Wazuh indexer ระบุว่าพื้นที่ดิสก์ขึ้นกับ APS และให้ค่าประมาณต่อ agent สำหรับ alert ที่ index ไว้ 90 วัน

ตัวอย่างในเอกสารคือเครื่องผู้ใช้ 80 เครื่อง เซิร์ฟเวอร์ 10 เครื่อง และอุปกรณ์เครือข่าย 10 ชิ้น ใช้พื้นที่ indexer ประมาณ 231 GB สำหรับ 90 วัน ตัวเลขทั้งหมดคิดที่ 90 วัน ถ้าต้องค้นย้อนหลังนานกว่านั้น พื้นที่ต้องเพิ่มตามระยะเวลาโดยประมาณ

ดิสก์ของ server

server ใช้ APS ชุดเดียวกัน แต่เก็บข้อมูลคนละแบบ จึงห้ามรวมกับตารางของ indexer คู่มือติดตั้ง Wazuh server ประมาณการพื้นที่สำหรับไฟล์ alert ในเครื่องไว้ดังนี้

ตัวอย่างชุดเดียวกัน (80/10/10) ใช้ประมาณ 6 GB สำหรับ alert บวกฐานข้อมูลช่องโหว่ 11 GB รวม 17 GB และเอกสารกำหนดให้ volume ที่เก็บ /var/ossec มีพื้นที่ว่างอย่างน้อย 20 GB ก่อนเริ่ม Wazuh manager ครั้งแรก เพราะฐานข้อมูลช่องโหว่จะถูกแตกไฟล์ตอนนั้น

คุมปริมาณเหตุการณ์ที่ agent ส่ง

agent มี buffer กันการส่งเหตุการณ์ท่วม (anti-flooding) เปิดเป็นค่าเริ่มต้น ตาม เอกสาร client_buffer คิวรับได้ 5,000 เหตุการณ์ และส่งให้ manager ได้ 500 เหตุการณ์ต่อวินาทีเป็นค่าเริ่มต้น (ตั้งได้ 1–1,000) เอกสารเตือนว่าการปิด buffer ในระบบใหญ่อาจทำให้ manager และเครือข่ายรับไม่ไหว ถ้าเครื่องใดต้องส่งเหตุการณ์มากเป็นพิเศษ เช่น เซิร์ฟเวอร์ที่ log ถี่ ให้ปรับค่าเฉพาะกลุ่มนั้นหลังวัดจริง

วัดว่าเครื่องพอหรือยัง

ตัวเลขทั้งหมดข้างบนเป็นค่าประมาณสำหรับวางแผนเริ่มต้น หลังติดตั้ง คู่มือ Wazuh server ให้ดูสองค่า คือ events_dropped ในไฟล์ wazuh-analysisd.state และ discarded_count ในไฟล์ wazuh-remoted.state ทั้งสองค่าควรเป็นศูนย์เมื่อระบบทำงานปกติ ถ้าค่าใดไม่เป็นศูนย์ ให้เพิ่ม node ใน cluster ส่วนการดู CPU, หน่วยความจำ และ I/O ของเครื่องเองใช้เครื่องมือตาม เครื่องมือวัดประสิทธิภาพ Linux ได้

เก็บ log ใน Wazuh นานแค่ไหน?

ระยะเก็บ log (log retention) ขึ้นกับว่าองค์กรมีหน้าที่ตามข้อกำหนดใด ไม่ใช่ทุกองค์กรต้องเก็บ 90 วันตามกฎหมายฉบับเดียวกัน และ log ที่ Wazuh เก็บเป็นค่าเริ่มต้นก็ไม่ใช่ log ดิบทั้งหมด ต้องแยกให้ออกก่อนว่ากฎหมายพูดถึงข้อมูลอะไร และ Wazuh เก็บอะไร

กฎหมายไทยกำหนดอะไร และใช้กับใคร

• มาตรา 26 พ.ร.บ. ว่าด้วยการกระทำความผิดเกี่ยวกับคอมพิวเตอร์ พ.ศ. 2550: ผู้ให้บริการต้องเก็บรักษาข้อมูลจราจรทางคอมพิวเตอร์ไว้ไม่น้อยกว่า 90 วันนับแต่วันที่ข้อมูลเข้าสู่ระบบคอมพิวเตอร์ ในกรณีจำเป็น พนักงานเจ้าหน้าที่สั่งให้ผู้ให้บริการรายใดเก็บเกิน 90 วันได้แต่ไม่เกินสองปี เป็นกรณีพิเศษเฉพาะรายและเฉพาะคราว วรรคสองให้เก็บข้อมูลที่ระบุตัวผู้ใช้บริการตั้งแต่เริ่มใช้บริการ และต่อไปไม่น้อยกว่า 90 วันหลังสิ้นสุดการใช้บริการ ผู้ให้บริการที่ไม่ปฏิบัติตามมีโทษปรับไม่เกินห้าแสนบาท เพดานสองปีมาจากมาตรา 17 ของ พ.ร.บ. ฉบับที่ 2 พ.ศ. 2560
• ประกาศกระทรวงดิจิทัลเพื่อเศรษฐกิจและสังคม เรื่องหลักเกณฑ์การเก็บรักษาข้อมูลจราจรทางคอมพิวเตอร์ของผู้ให้บริการ พ.ศ. 2564 (ราชกิจจานุเบกษา เล่ม 138 ตอนพิเศษ 188 ง วันที่ 13 สิงหาคม 2564) ข้อ 5 จำกัดหน้าที่ไว้กับผู้ให้บริการบางประเภท เช่น ผู้ให้บริการโทรคมนาคม ผู้ให้บริการเข้าถึงอินเทอร์เน็ต ผู้ให้บริการเช่าระบบ (host) ร้านอินเทอร์เน็ต ผู้ให้บริการสื่อสังคมออนไลน์ ผู้ให้บริการเนื้อหาและแอปพลิเคชัน และผู้ให้บริการ cloud ที่ให้บริการกับผู้ใช้โดยตรง และภาคผนวก ก ของประกาศยกตัวอย่าง "ผู้ให้บริการเข้าถึงระบบเครือข่ายคอมพิวเตอร์สำหรับองค์กร เช่น หน่วยงานราชการ บริษัท หรือสถาบันการศึกษา" และผู้ให้บริการ Mail Server ไว้ด้วย ข้อ 12 ให้เก็บไม่น้อยกว่า 90 วัน และกรณีจำเป็น พนักงานเจ้าหน้าที่สั่งให้เก็บต่อได้คราวละไม่เกินหกเดือนต่อเนื่องกัน แต่รวมแล้วต้องไม่เกินสองปี

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

Wazuh เก็บอะไรเป็นค่าเริ่มต้น

ค่าเริ่มต้นของ Wazuh เขียนและ index เฉพาะ alert คือเหตุการณ์ที่ตรง rule และมีระดับตั้งแต่ log_alert_level ขึ้นไป ตาม เอกสาร Wazuh archives ถ้าต้องการเก็บทุกเหตุการณ์ รวมถึงเหตุการณ์ที่ไม่ได้สร้าง alert ต้องเปิด archives (logall หรือ logall_json ในส่วน <global> ของ ossec.conf) ซึ่งเขียนลง /var/ossec/logs/archives/ และเลือก index เป็น wazuh-archives-* ได้ เอกสารระบุว่า archives ปิดไว้เป็นค่าเริ่มต้นเพราะเก็บ log บน server ไปเรื่อย ๆ ไม่มีกำหนด และใช้พื้นที่มาก จึงต้องคิดผลต่อดิสก์และประสิทธิภาพก่อนเปิด

ไฟล์ log บน server ถูกหมุนและบีบอัดรายวัน พร้อมค่า checksum แบบ MD5, SHA1 และ SHA256 กำกับไว้ ซึ่งช่วยตรวจได้ว่าไฟล์ถูกแก้หรือไม่ ถ้าเก็บค่า checksum ไว้ในที่ที่ผู้ดูแลระบบแก้ไม่ได้ ส่วนการกันไม่ให้ผู้ดูแลระบบแก้หรือลบ log ยังต้องออกแบบสิทธิ์และที่เก็บเพิ่ม

ตั้งระยะเก็บด้วย Index State Management

ระยะเวลาที่ alert อยู่ใน indexer ตั้งได้ด้วย Index State Management (ISM) ตาม เอกสาร index lifecycle management ตัวอย่างในเอกสารคือ policy ชื่อ wazuh-alert-retention-policy ที่จับ index pattern wazuh-alerts-* แล้วลบ index เมื่อ min_index_age ถึง 90d (ปรับจำนวนวันได้) และนำ policy ไปใช้กับ index ที่มีอยู่แล้วผ่านเมนู Indexer management > Index Management > Indices > Actions > Apply policy

เอกสารเดียวกันอธิบายสถาปัตยกรรม hot-warm โดยกำหนด node.attr.temp เป็น hot หรือ warm ใน /etc/wazuh-indexer/opensearch.yml ตัวอย่าง policy ย้าย index ไปไว้บน warm node เมื่ออายุ 30 วันและลบ replica ออก hot node เร็วแต่แพง ส่วน warm node ช้ากว่าแต่ถูกกว่า หน้านี้ไม่ได้อธิบาย cold tier หรือการทำ snapshot จึงต้องออกแบบที่เก็บระยะยาวแยกต่างหาก ถ้าต้องเก็บนานกว่าที่จะเก็บไว้บนดิสก์ของ indexer

สิ่งที่ต้องออกแบบรอบ Wazuh ถ้าองค์กรเป็นผู้ให้บริการตามข้อ 5

วางแผน rollout Wazuh agent บนระบบเก่าอย่างไร?

เริ่มจากกฎเรื่องรุ่นก่อน แล้วจึงตรวจว่าระบบปฏิบัติการแต่ละตัวมีแพ็กเกจ agent หรือไม่ จากนั้นทดสอบกับเครื่องตัวแทนและติดตั้งเป็นรอบ

กฎเรื่องรุ่นของ agent และ manager

คู่มืออัปเกรด กำหนดว่าส่วนกลางทุกตัวต้องมีเลขรุ่นตรงกันจนถึงระดับ patch และ manager ต้องเป็นรุ่นเดียวกันหรือใหม่กว่า agent เสมอ คู่มือติดตั้ง agent ระบุเช่นกันว่าความเข้ากันได้รับประกันเมื่อ manager มีรุ่นเท่ากันหรือใหม่กว่า agent Wazuh แนะนำให้ปิด repository ของ Wazuh หรือ hold แพ็กเกจบนเครื่องปลายทาง เพื่อไม่ให้ agent ถูกอัปเกรดโดยไม่ตั้งใจ ลำดับที่ถูกจึงเป็นอัปเกรดส่วนกลางก่อน แล้วจึงอัปเกรด agent

ระบบปฏิบัติการเก่าที่มีแพ็กเกจ agent

รายการแพ็กเกจของ 4.14.9 ยังมี agent สำหรับระบบรุ่นเก่าหลายตัว

CentOS 7 อยู่ในช่วง "6 ขึ้นไป" ส่วน Windows Server 2012 R2 ไม่ได้ถูกระบุชื่อ แต่อยู่ในช่วงที่ คู่มือ agent สำหรับ Windows ระบุไว้ คือตั้งแต่ Windows XP จนถึงรุ่นล่าสุด รวมถึง Windows 11 และ Windows Server 2022 เอกสารไม่ได้ยืนยันว่าทุกความสามารถทำงานเท่ากันบนระบบเก่า จึงควรติดตั้งบนเครื่องตัวแทนของแต่ละระบบปฏิบัติการก่อน แล้วตรวจว่าข้อมูลที่ต้องการขึ้นบน dashboard ครบ การติดตั้ง agent ไม่ได้แก้ปัญหาที่ระบบปฏิบัติการไม่ได้รับแพตช์แล้ว แนวทางดูแลระบบลักษณะนี้อยู่ใน วิธีดูแลระบบเก่าให้รันต่ออย่างปลอดภัย

วิธีติดตั้ง agent ทีละมาก

ตาม คู่มือติดตั้ง agent agent ใช้หน่วยความจำเฉลี่ยประมาณ 35 MB และสำหรับระบบใหญ่ เอกสารแนะนำเครื่องมืออัตโนมัติ เช่น Puppet, Chef, SCCM และ Ansible นอกจากนี้ยังสร้างคำสั่งติดตั้งจาก dashboard ได้ที่ Agents management > Summary > Deploy new agent

• Windows: ติดตั้งผ่านหน้าจอ หรือผ่านบรรทัดคำสั่ง เช่น msiexec.exe /i wazuh-agent-4.14.9-1.msi /q WAZUH_MANAGER="10.0.0.2" พร้อมตัวแปรอื่น เช่น ชื่อ agent, group และรหัสลงทะเบียน ต้องใช้สิทธิ์ administrator สำหรับการกระจายผ่าน Group Policy (GPO) ใน Active Directory Wazuh มี บทความบน Wazuh blog อธิบายวิธีไว้ ไม่ได้อยู่ในเอกสารหลัก
• Linux: Wazuh มี repository wazuh-ansible ที่มี role และ playbook สำหรับส่วนกลางและ agent ตาม คู่มือ Ansible role ansible-wazuh-agent ติดตั้ง agent บน Linux ผ่าน SSH และลงทะเบียนกับ manager ให้ใช้ branch ที่ตรงกับรุ่น เช่น v4.14.9 และเอกสารระบุว่าการติดตั้ง agent บน Amazon Linux 2 ด้วย Ansible 2.17 ขึ้นไปไม่รองรับ
• อัปเกรด agent จากส่วนกลาง: ตาม เอกสาร remote upgrade ใช้ /var/ossec/bin/agent_upgrade บน server (-l แสดง agent ที่รุ่นเก่า, -a ระบุ agent ID) หรือใช้ Wazuh server API (GET /agents/outdated, PUT /agents/upgrade, GET /agents/upgrade_result) ถ้าใช้ cluster เอกสารแนะนำให้ใช้ API และถ้าอัปเกรดเกิน 3,000 agent พร้อมกัน ให้ตั้ง wait_for_complete=true เพื่อไม่ให้ API หมดเวลา

ในมุมมองของเรา ลำดับที่ปลอดภัยคือ (1) ติดตั้งกับเครื่องตัวแทนของแต่ละระบบปฏิบัติการ (2) ขยายเป็นกลุ่มเล็ก เช่น เซิร์ฟเวอร์ที่ไม่ใช่ระบบหลัก (3) เก็บสถิติ alert และปรับ rule สักระยะ แล้วจึง (4) ขยายเป็นรอบตาม group ของ agent การกำหนด group ตั้งแต่ลงทะเบียนช่วยให้แยกค่าตั้งตามประเภทเครื่องได้ตั้งแต่แรก

ลด alert noise ใน Wazuh อย่างไร?

ลดที่ rule ทีละแหล่ง ไม่ใช่เพิ่มค่า log_alert_level ทั้งระบบ เพราะการเพิ่มค่านี้ทำให้ alert หายไปพร้อมกับหลักฐานที่อาจต้องใช้ภายหลัง

• ระดับของ alert: log_alert_level ใน ossec.conf กำหนดระดับต่ำสุดที่จะถูกบันทึกลง alerts.log และ alerts.json ค่าเริ่มต้นคือ 3 และ email_alert_level ค่าเริ่มต้นคือ 12 ตาม การจัดระดับ rule ระดับ 0 คือ ignored ใช้ตัดเหตุการณ์ที่เป็น false positive ระดับ 12 คือเหตุการณ์สำคัญสูง ระดับ 14 บ่งชี้การโจมตี และระดับ 15 คือการโจมตีรุนแรงที่ต้องดูทันที
• custom rule: ตาม เอกสาร custom rules แก้เล็กน้อยใน /var/ossec/etc/rules/local_rules.xml ถ้ามากให้สร้างไฟล์ใหม่ใต้ /var/ossec/etc/rules/ ใช้ ID ช่วง 100000–120000 ถ้าจะเปลี่ยน rule ที่มากับระบบ ให้คัดลอกไปไว้ใต้ /var/ossec/etc/rules/ แล้วใส่ overwrite="yes" แต่เปลี่ยน if_sid, if_group, if_level, if_matched_sid และ if_matched_group ด้วยวิธีนี้ไม่ได้ ไฟล์ใต้ /var/ossec/ruleset/rules ถูกเขียนทับทุกครั้งที่อัปเกรด
• custom decoder: ตาม เอกสาร custom decoders เพิ่ม decoder ใน /var/ossec/etc/decoders/local_decoder.xml ถ้าจะแก้ decoder ที่มากับระบบ ให้คัดลอกไฟล์ decoder ทั้งไฟล์ (เช่น 0310-ssh_decoders.xml) ไปไว้ใน /var/ossec/etc/decoders/ แล้วตัดไฟล์เดิมออกจากการโหลดด้วย <decoder_exclude> ใน ossec.conf เอกสารระบุว่าไฟล์ที่คัดลอกมาจะไม่ถูกเขียนทับตอนอัปเกรด แต่ก็จะไม่ได้รับการแก้ที่ไฟล์เดิมได้รับในรุ่นถัดไป จึงต้องตรวจเทียบทุกครั้งที่อัปเกรด ทุกครั้งที่แก้ rule หรือ decoder ต้อง restart manager จึงจะมีผล

ในมุมมองของเรา วิธีที่ได้ผลคือเปิด agent กลุ่มแรกแล้วเก็บ alert ช่วงหนึ่งเป็น baseline ดูว่า rule ใดเกิดถี่ที่สุดและมาจากเครื่องใด แยกให้ออกว่าเป็นพฤติกรรมปกติของระบบหรือเป็นปัญหาจริง แล้วปรับเฉพาะ rule นั้นด้วย custom rule ที่ระบุเงื่อนไขให้แคบที่สุด และจดเหตุผลของการเปลี่ยนแต่ละครั้งไว้ เพื่อให้คนที่ดูแลต่อรู้ว่าทำไม alert บางตัวถูกลดระดับ

เช็กลิสต์ก่อนติดตั้ง Wazuh

• นับเครื่องที่จะติด agent แยกตามประเภท (เซิร์ฟเวอร์ เครื่องผู้ใช้ อุปกรณ์เครือข่าย) และระบบปฏิบัติการ
• ตัดสินว่าต้องการ high availability หรือไม่ แล้วเลือก all-in-one, single-node หรือ cluster
• คำนวณดิสก์ของ indexer และ server แยกกัน จาก APS และจำนวนวันที่ต้องค้นย้อนหลัง และเผื่อพื้นที่ว่าง 20 GB บน /var/ossec
• ระบุข้อกำหนดที่ใช้กับองค์กร แล้วตัดสินว่าต้องเก็บ log ดิบหรือไม่ เก็บที่ไหน นานเท่าไร และใครแก้หรือลบได้
• ตั้ง ISM สำหรับ wazuh-alerts-* (และ wazuh-archives-* ถ้าเปิด) ให้ตรงกับระยะที่ตัดสินไว้
• เปิด firewall ตามพอร์ตที่ใช้จริง และตั้ง NTP ให้ทุกเครื่องอ้างแหล่งเวลาเดียวกัน
• ทดสอบ agent บนเครื่องตัวแทนของทุกระบบปฏิบัติการ โดยเฉพาะระบบเก่า
• hold แพ็กเกจ agent และวางลำดับอัปเกรดให้ส่วนกลางนำหน้า agent เสมอ
• วาง custom rule และ decoder ไว้ใต้ /var/ossec/etc/ เท่านั้น และจดเหตุผลการปรับแต่ละครั้ง
• กำหนดผู้รับผิดชอบดูแลแพลตฟอร์มและผู้รับผิดชอบอ่าน alert แยกกัน ถ้าจ้างผู้อื่นดูแล ให้ระบุขอบเขตใน สัญญาบำรุงรักษา (MA) และข้อตกลงระดับบริการ (SLA) และดูการเปรียบเทียบ Managed Services กับทีม IT ภายใน ประกอบ

UNIXDEV ประเมินขนาดเครื่องจากจำนวนเครื่องปลายทางแยกตามประเภท ปริมาณเหตุการณ์ต่อวินาที (events per second, EPS) ที่ agent ส่ง และจำนวน alert ต่อวินาที (APS) ที่เกิดจริง ติดตั้ง Wazuh manager, indexer และ dashboard บน Linux วาง agent บนเซิร์ฟเวอร์ และรับ syslog จากอุปกรณ์เครือข่าย ปรับจูน rule เพื่อลด false positive และดูแลต่อตามขอบเขต MA ที่ตกลงกันผ่านบริการ DevOps & Managed Services จุดเริ่มที่แนะนำคือประเมินการวาง Wazuh จากระบบจริงก่อน ส่งจำนวนเครื่องแยกตามประเภทและระบบปฏิบัติการ ระยะเก็บ log ที่ต้องการ และข้อกำหนดที่ใช้กับองค์กร ผ่านแบบฟอร์มส่งโจทย์ได้

แหล่งอ้างอิงและอ่านต่อ

• Wazuh documentation — Release notes
• Wazuh documentation — Architecture
• Wazuh documentation — Installation guide
• Wazuh documentation — Quickstart
• Wazuh documentation — Wazuh indexer installation
• Wazuh documentation — Wazuh server installation
• Wazuh documentation — Wazuh dashboard installation
• Wazuh documentation — client_buffer
• Wazuh documentation — Wazuh archives
• Wazuh documentation — Index lifecycle management
• Wazuh documentation — Packages list
• Wazuh documentation — Wazuh agent installation
• Wazuh documentation — Wazuh agent for Windows
• Wazuh documentation — Deploying with Ansible
• Wazuh blog — Deploying Wazuh agents using Windows GPO
• Wazuh documentation — Upgrade guide
• Wazuh documentation — Remote agent upgrade
• Wazuh documentation — alerts (ossec.conf)
• Wazuh documentation — Rules classification
• Wazuh documentation — Custom rules
• Wazuh documentation — Custom decoders
• Wazuh documentation — Virtual machine (OVA)
• พ.ร.บ. ว่าด้วยการกระทำความผิดเกี่ยวกับคอมพิวเตอร์ พ.ศ. 2550 และฉบับที่ 2 พ.ศ. 2560 (ETDA)
• พ.ร.บ. ว่าด้วยการกระทำความผิดเกี่ยวกับคอมพิวเตอร์ (ฉบับที่ 2) พ.ศ. 2560 ราชกิจจานุเบกษา เล่ม 134 ตอนที่ 10 ก (สำเนา)
• ประกาศกระทรวงดิจิทัลฯ เรื่องหลักเกณฑ์การเก็บรักษาข้อมูลจราจรทางคอมพิวเตอร์ของผู้ให้บริการ พ.ศ. 2564 (ราชกิจจานุเบกษา) · สำเนา
• บทความที่เกี่ยวข้อง: Wazuh คืออะไร
• บทความที่เกี่ยวข้อง: Wazuh กับ EDR ต่างกันอย่างไร
• บทความที่เกี่ยวข้อง: ดูแลระบบเก่าให้รันต่ออย่างปลอดภัย
• บทความทั้งหมดในหมวด Wazuh และ Security Monitoring

บทความโดย UNIXDEV Team · 2 พฤศจิกายน 2026 · ข้อมูลทางเทคนิคอ้างอิงเอกสาร Wazuh 4.14 (4.14.9) ณ วันที่เขียน ซึ่งอาจเปลี่ยนในรุ่นถัดไป ตัวเลขขนาดเครื่องเป็นค่าประมาณจากเอกสาร ควรวัดจากระบบจริง และสรุปข้อกฎหมายเพื่อประกอบการวางแผน ไม่ใช่คำแนะนำทางกฎหมาย