Wazuh คืออะไร: SIEM/XDR โอเพนซอร์ส ต่างจาก SIEM เชิงพาณิชย์อย่างไร เหมาะกับองค์กรแบบไหน

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

บทความนี้เขียนสำหรับ IT Manager, CISO และหัวหน้าฝ่าย IT ที่กำลังประเมิน SIEM อธิบายว่า Wazuh ประกอบด้วยอะไร ทำอะไรได้ คำว่า "ฟรี" หมายถึงอะไรในทางปฏิบัติ SIEM เชิงพาณิชย์คิดค่าใช้จ่ายด้วยหลักอะไร ข้อกำหนดไทยข้อไหนที่ SIEM ช่วยเก็บหลักฐานได้ และ Wazuh เหมาะหรือไม่เหมาะกับองค์กรแบบไหน ดูรายละเอียดบริการติดตั้งและดูแลได้ที่หน้า Wazuh SIEM/XDR

Wazuh คืออะไร?

Wazuh คือแพลตฟอร์มความปลอดภัยแบบโอเพนซอร์สที่รวมความสามารถของ SIEM และ XDR ไว้ด้วยกัน เอกสารทางการของ Wazuh นิยามว่าเป็น "free and open source security platform that unifies XDR and SIEM capabilities"

เพื่อให้เห็นภาพว่า SIEM ทำหน้าที่อะไร อภิธานศัพท์ของ NIST (อ้างอิง NIST SP 800-128) นิยาม SIEM tool ว่าเป็นแอปพลิเคชันที่รวบรวมข้อมูลความปลอดภัยจากส่วนประกอบต่าง ๆ ของระบบสารสนเทศ แล้วนำเสนอเป็นข้อมูลที่นำไปใช้ต่อได้ผ่านหน้าจอเดียว ส่วน NIST SP 800-92 นิยามสั้นกว่าว่าเป็นโปรแกรมที่ให้ความสามารถในการเก็บ log แบบรวมศูนย์สำหรับ log หลายประเภท

ในด้านเวอร์ชัน ณ วันที่เขียน (ตุลาคม 2026) รุ่นเสถียรล่าสุดคือ Wazuh 4.14.9 ซึ่งออกเมื่อ 14 ตุลาคม 2026 ตาม release notes ของ Wazuh ส่วน Wazuh 5.0 อยู่ระหว่าง pre-release ณ ตุลาคม 2026 บทความนี้จึงอ้างอิงพฤติกรรมของรุ่น 4.x เป็นหลัก

Wazuh ประกอบด้วยส่วนไหนบ้าง?

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

ในรุ่น 4.x agent เชื่อมต่อกับ server ผ่าน TCP 1514 และลงทะเบียน (enrollment) ผ่าน TCP 1515 ข้อความระหว่าง agent กับ server เข้ารหัส AES เป็นค่าเริ่มต้น จากนั้น server ส่งแจ้งเตือนไปยัง indexer ผ่าน Filebeat ด้วย TLS ทั้ง server และ indexer ตั้งเป็น cluster ได้เพื่อกระจายโหลดและเพิ่ม high availability ตามหน้า Wazuh architecture

Wazuh ทำอะไรได้บ้าง?

Wazuh ครอบคลุมทั้งการวิเคราะห์ log การตรวจสอบเครื่องปลายทาง และการตอบสนองอัตโนมัติ เอกสาร Wazuh จัดกลุ่ม use case ไว้ 12 เรื่อง ได้แก่ configuration assessment, malware detection, file integrity monitoring, threat hunting, log data analysis, vulnerability detection, incident response, regulatory compliance, IT hygiene, container security, posture management และ workload protection ความสามารถที่ผู้ประเมิน SIEM มักถามถึงมีดังนี้

• Log data analysis: วิเคราะห์และดึงข้อมูลเชิงลึกจาก log ที่ระบบ แอปพลิเคชัน และอุปกรณ์ต่าง ๆ สร้างขึ้น
• File Integrity Monitoring (FIM): ตรวจความถูกต้องของไฟล์ระบบและไฟล์แอปพลิเคชัน
• Security Configuration Assessment (SCA): ตรวจว่าระบบเป็นไปตามชุด rule ที่กำหนด policy ที่มากับ Wazuh ส่วนใหญ่อิงจาก CIS benchmarks
• Vulnerability detection: agent เก็บรายการซอฟต์แวร์ที่ติดตั้งส่งให้ server แล้ว server เทียบกับข้อมูลช่องโหว่จาก Wazuh CTI หรือ offline repository
• Malware detection: ใช้หลายวิธีร่วมกัน เช่น FIM ร่วมกับ rule, YARA และการเชื่อม VirusTotal
• Active response: รัน script บนเครื่องปลายทางเมื่อเกิดแจ้งเตือนตาม rule ที่กำหนด
• MITRE ATT&CK mapping: rule ที่มากับ Wazuh ผูกกับ MITRE ID อยู่แล้ว และกำหนด MITRE ID ให้ custom rule ได้
• Compliance mapping: เอกสาร Wazuh ระบุว่า Wazuh "helps implement" ข้อกำหนดด้าน compliance โดยมีเนื้อหาสำหรับ PCI DSS, HIPAA, NIST 800-53, TSC และ GDPR และเพิ่มมาตรฐานอื่นได้ด้วยการใส่ compliance identifier ใน rule
• Container และ cloud: ติดตามเหตุการณ์ของ Docker engine และติดตามทรัพยากรใน Kubernetes cluster รวมถึง posture management สำหรับ AWS, Microsoft Azure และ Google Cloud Platform

เอกสาร Wazuh เองเตือนว่า active response ต้องพิจารณาให้รอบคอบ เพราะการตั้ง rule และ response ที่ไม่ดีอาจทำให้เครื่องปลายทางเสี่ยงมากขึ้น ในมุมมองของเรา ควรเริ่มจากแจ้งเตือนอย่างเดียวก่อน แล้วค่อยเปิด response อัตโนมัติทีละกรณีที่ทดสอบแล้ว ส่วนคำถามว่า Wazuh ใช้แทน EDR ได้หรือไม่ อ่านต่อใน Wazuh กับ EDR ต่างกันอย่างไร

Wazuh ฟรีจริงไหม?

ฟรีในแง่ license ไม่ใช่ฟรีในแง่ต้นทุนรวม (TCO) ตัวซอฟต์แวร์ไม่มีค่า license แต่องค์กรยังต้องจ่ายค่าเครื่อง พื้นที่เก็บข้อมูล คนดูแล และเวลาที่ใช้ปรับจูน rule

License ของแต่ละส่วนเป็นแบบไหน?

• Wazuh server และ agent (repository wazuh/wazuh): สำหรับรุ่น 4.x เช่น 4.14.9 ใช้ GNU GPL version 2 พร้อมข้อยกเว้นการลิงก์กับ OpenSSL และต่อยอดจากงาน OSSEC ส่วน branch ที่พัฒนารุ่น 5.0 ใช้ license แบบผสม จึงควรตรวจเงื่อนไขอีกครั้งเมื่อรุ่น 5.0 ออกจริง
• Wazuh indexer: fork ของ OpenSearch ใช้ Apache License 2.0
• Wazuh dashboard: fork ของ OpenSearch Dashboards ใช้ Apache License 2.0

ต้นทุนจริงของ Wazuh มาจากไหน?

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

1. เครื่องและพื้นที่เก็บข้อมูล: หน้า Wazuh quickstart ให้ขนาดเครื่องสำหรับการติดตั้งแบบ all-in-one (indexer, server และ dashboard บนเครื่องเดียว) โดยเก็บแจ้งเตือนที่ค้นหาได้ 90 วัน ดังนี้

เอกสารระบุว่าการติดตั้งแบบนี้มักพอสำหรับเฝ้าระวังได้ถึงประมาณ 100 endpoint ถ้ามากกว่านั้นมักต้องแยกเครื่องตามส่วนประกอบ สำหรับ indexer แต่ละ node คู่มือติดตั้ง Wazuh indexer กำหนดขั้นต่ำ RAM 4 GB และ 2 CPU core แนะนำ RAM 16 GB และ 8 core ส่วนพื้นที่ดิสก์ขึ้นกับจำนวนแจ้งเตือนต่อวินาที (APS) โดยประมาณการต่อ agent สำหรับ 90 วันไว้ว่า เซิร์ฟเวอร์ 3.7 GB, เครื่องผู้ใช้ 1.5 GB และอุปกรณ์เครือข่าย 7.4 GB ตัวอย่างในเอกสารคือ เครื่องผู้ใช้ 80 เครื่อง เซิร์ฟเวอร์ 10 เครื่อง และอุปกรณ์เครือข่าย 10 ชิ้น ใช้พื้นที่รวมประมาณ 231 GB สำหรับ 90 วัน

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

2. คนดูแลระบบและดูแจ้งเตือน: ในมุมมองของเรา Wazuh เป็นซอฟต์แวร์ที่ไม่ได้มาพร้อมทีมเฝ้าระวัง จึงต้องมีคนรับผิดชอบสองงานแยกกัน คือดูแลตัวแพลตฟอร์ม (อัปเกรด สำรองข้อมูล ขยายพื้นที่) และอ่าน คัดกรอง และตอบสนองต่อแจ้งเตือน

3. การปรับจูน rule: Wazuh เปิดให้แก้ rule ที่มากับระบบได้ แต่ตาม เอกสาร custom rules การแก้ไฟล์ใน /var/ossec/ruleset/rules จะถูกเขียนทับเมื่ออัปเกรด วิธีที่ถูกคือคัดลอก rule ไปไว้ในไฟล์ใต้ /var/ossec/etc/rules/ เช่น local_rules.xml แก้ไข แล้วใส่ overwrite="yes" และ custom rule ควรใช้ ID ช่วง 100000–120000 ในมุมมองของเรา การปรับจูนเป็นงานต่อเนื่อง เพราะระบบงานและรูปแบบ log ขององค์กรเปลี่ยนไปเรื่อย ๆ

4. บริการเสริมแบบเสียเงิน: Wazuh, Inc. มีสองทางเลือกที่เสียค่าใช้จ่าย

• Professional support: รวมคำแนะนำด้านสถาปัตยกรรมและฮาร์ดแวร์ health check และการอัปเกรด การทำ custom rule, dashboard และ integration และ customer success manager แบ่งเป็นสองแผนตามชั่วโมงให้บริการ จำนวน health check ต่อปี และเวลาตอบสนองตามที่ Wazuh ประกาศ ณ วันที่เขียน คือ Standard ให้บริการ 8/5 ในเวลาทำการ health check 2 ครั้งต่อปี และ response SLA 8 ชั่วโมง ส่วน Premium ให้บริการ 24/7 เฉพาะปัญหาวิกฤต health check 4 ครั้งต่อปี และ response SLA 4 ชั่วโมง ราคาต้องสอบถามจาก Wazuh หน้า professional support ระบุเฉพาะบริการสนับสนุน ไม่ได้ระบุบริการเฝ้าระวังแทนองค์กร
• Wazuh Cloud: Wazuh รุ่น SaaS ที่ Wazuh, Inc. เป็นผู้โฮสต์และดูแล แบ่งแผนเป็น Small, Medium, Large และ Custom ตามจำนวน active agent (สูงสุด 100, 250 หรือ 500 หรือกำหนดเอง) ระยะเก็บข้อมูลแบบ indexed และ archive และแผน support ตารางแผนไม่ได้ระบุเพดานปริมาณข้อมูลเป็น GB และมีช่วงทดลองใช้ฟรี 14 วัน

SIEM เชิงพาณิชย์คิดค่าใช้จ่ายอย่างไร?

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

• Splunk: มีสี่โมเดล คือ activity-based, ingest, workload และ entity โดย Enterprise Security เลือกได้ระหว่าง activity-based, workload หรือ ingest แบบ ingest คิดตาม GB ที่ส่งเข้า แบบ workload คิดตามทรัพยากร compute และ storage ที่ใช้ค้นหาและวิเคราะห์ แบบ activity-based มีสองมิเตอร์ คือ ingest และ search activity ส่วน entity เป็นอีกโมเดลหนึ่งที่ไม่ได้คิดตามปริมาณข้อมูล
• Microsoft Sentinel: analytics tier เลือกได้ระหว่าง pay-as-you-go หรือ commitment tier ซึ่งจองปริมาณข้อมูลต่อวันในค่าบริการรายวันคงที่ มี data lake tier สำหรับเก็บระยะยาวโดยแยกมิเตอร์ compute กับ storage และบริการ Azure อื่นที่ใช้ร่วม เช่น Log Analytics หรือ Logic Apps คิดค่าใช้จ่ายแยก
• Elastic: Elastic Cloud Hosted คิดตามทรัพยากร (resource based) Elastic Cloud Serverless คิดตามการใช้งาน (usage based) ส่วนแบบ self-managed ซึ่งไม่ใช่ Elastic Cloud คิด license ตามจำนวน node และ RAM ที่ใช้ สำหรับ Elastic Security Serverless คิดรายเดือนตาม GB ที่ส่งเข้า GB ที่เก็บ และ egress ตามอัตราของ feature tier ที่เลือก
• Google Security Operations (เดิมชื่อ Chronicle): ใช้โมเดลแบบ credit สำหรับการนำข้อมูลเข้า แพ็กเกจ Standard, Enterprise และ Enterprise Plus มีทั้งค่าสมัครสมาชิกและส่วนที่วัดตามการใช้งาน ปริมาณ GB ที่ซื้อกลายเป็น credit ที่ถูกหักตามข้อมูลที่ส่งเข้า และถ้าใช้เกิน commitment โดยไม่มี credit เหลือจะมีค่าส่วนเกิน
• IBM QRadar: ในเดือนพฤษภาคม 2024 IBM ประกาศขายสินทรัพย์ QRadar SaaS ให้ Palo Alto Networks ตามแผนที่ประกาศในขณะนั้น ลูกค้า QRadar SaaS จะย้ายไปใช้ Cortex XSIAM และ IBM จะยังสนับสนุนลูกค้า QRadar แบบ on-premises ต่อ องค์กรที่ใช้ QRadar อยู่ควรตรวจแผนรองรับกับผู้ขายโดยตรง

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

Wazuh ต่างจาก SIEM เชิงพาณิชย์อย่างไร?

ความต่างหลักอยู่ที่ใครเป็นผู้แบกต้นทุนและงานดูแล Wazuh แบบติดตั้งเองไม่มีค่า license แต่องค์กรต้องดูแลโครงสร้างพื้นฐานและ rule เอง ส่วน SIEM เชิงพาณิชย์คิดค่าใช้จ่ายตามโมเดลของผู้ขาย และในรุ่น cloud ผู้ขายรับภาระดูแลโครงสร้างพื้นฐานไป

ข้อกำหนดไทยข้อไหนที่ SIEM ช่วยเก็บหลักฐานได้?

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

รายละเอียดที่ควรรู้เพิ่มเติม:

• ประกาศ กกม.: ประกาศในราชกิจจานุเบกษาเมื่อ 6 กันยายน 2564 ระบุว่าเป็นข้อกำหนดขั้นต่ำ และให้ใช้บังคับเมื่อพ้นหนึ่งปีนับแต่วันประกาศ กรอบแบ่งเป็นห้าหัวข้อหลักที่มีคำกำกับภาษาอังกฤษว่า Identify, Protect, Detect, Respond และ Recover นอกจากส่วน Detect แล้ว ส่วน Respond ยังกำหนดให้มีแผนรับมือภัยคุกคามที่ฝึกซ้อมและทบทวนอย่างน้อยปีละครั้ง ซึ่งเป็นงานของคนและกระบวนการ ไม่ใช่ของเครื่องมือ
• ข้อมูลจราจรทางคอมพิวเตอร์: พ.ร.บ. คอมพิวเตอร์ฯ ที่แก้ไขในปี 2560 ให้พนักงานเจ้าหน้าที่สั่งให้เก็บนานกว่า 90 วันเป็นรายกรณีได้แต่ไม่เกินสองปี ประกาศกระทรวงฯ ปี 2564 ระบุตัวอย่างวิธีป้องกันการแก้ไข เช่น Centralized Log Server, Data Archiving หรือ Data Hashing บริษัททั่วไปที่ไม่ได้ให้บริการแก่บุคคลอื่นไม่ได้อยู่ในขอบเขตนี้โดยอัตโนมัติ จึงควรตรวจก่อนว่าองค์กรเข้าข่ายผู้ให้บริการตามข้อ 5 หรือไม่
• ธปท.: แนวปฏิบัติที่มาพร้อมประกาศ สกช. 5/2566 คาดหวังให้มีหน่วยงานที่ทำหน้าที่เฝ้าระวัง ติดตาม วิเคราะห์ และประสานงานอย่างชัดเจน ซึ่งเป็นแนวปฏิบัติ ไม่ใช่ตัวประกาศ และสะท้อนว่าเครื่องมืออย่างเดียวไม่พอ

ข้อกำหนดเรื่อง integrity และนาฬิกาเป็นจุดที่ควรออกแบบตั้งแต่แรก ถ้า log ถูกแก้ได้หรือเวลาของแต่ละเครื่องไม่ตรงกัน หลักฐานจาก SIEM จะมีน้ำหนักน้อยลง

Wazuh เหมาะกับองค์กรแบบไหน และไม่พอเมื่อไร?

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

มักเหมาะเมื่อ:

• ต้องการเก็บข้อมูลไว้บนโครงสร้างพื้นฐานที่องค์กรเลือกเอง เช่น data center ภายในหรือ cloud ที่กำหนด
• มีเครื่องปลายทางหลายระบบปฏิบัติการ รวมถึง Solaris, AIX หรือ HP-UX
• ต้องการ FIM, SCA และ vulnerability detection ร่วมกับการวิเคราะห์ log ในแพลตฟอร์มเดียว
• มีคนที่เข้าใจ Linux และ log พอจะปรับจูน rule หรือมีพาร์ทเนอร์ทำให้

ยังไม่พอเมื่อ:

• ต้องการทีมเฝ้าระวังตลอดเวลา: ในมุมมองของเรา Wazuh เป็นซอฟต์แวร์ที่ไม่มีทีม SOC มาด้วย และหน้า professional support ของ Wazuh ระบุเฉพาะบริการสนับสนุน ไม่ได้ระบุบริการเฝ้าระวังแทนองค์กร จึงต้องจัดทีมเองหรือพิจารณาบริการ managed security แยกต่างหาก
• ไม่มีใครรับผิดชอบการปรับจูน: ถ้าไม่มีคนดู rule และแจ้งเตือนอย่างสม่ำเสมอ ในมุมมองของเรา ระบบจะกลายเป็นที่เก็บ log ที่ไม่มีใครเปิดดู
• ต้องการเครื่องมือตอบสนองที่เครื่องปลายทางแบบเฉพาะทาง: ให้เปรียบเทียบกับ EDR ก่อนตัดสินใจ ดู Wazuh กับ EDR

ติดตั้งใช้งาน Wazuh ได้กี่แบบ?

มีสี่แนวทางหลัก คือ ติดตั้งเองแบบ all-in-one, ติดตั้งเองแบบแยกส่วนหรือ cluster, ใช้ Wazuh Cloud และให้พาร์ทเนอร์ติดตั้งและดูแลภายใต้ขอบเขตที่ตกลงกัน

ถ้าเลือกให้พาร์ทเนอร์ดูแล ให้ตรวจสัญญาตามแนวทางใน เช็กลิสต์สัญญา MA และ SLA และดูการเปรียบเทียบ Managed Services กับทีม IT ภายใน ประกอบ

ก่อนเลือก SIEM ต้องเช็กอะไรบ้าง?

ก่อนเลือก Wazuh หรือ SIEM เชิงพาณิชย์ ให้ตอบคำถามด้านล่างให้ได้ก่อน เพราะคำตอบเหล่านี้กำหนดทั้งขนาดระบบ ค่าใช้จ่าย และคนที่ต้องใช้

• ระบุแหล่ง log ที่ต้องเก็บ (เซิร์ฟเวอร์ เครื่องผู้ใช้ อุปกรณ์เครือข่าย ระบบงาน cloud) และจำนวนโดยประมาณ
• ระบุข้อกำหนดที่ใช้กับองค์กรจริง เช่น เป็น CII หรือไม่ เป็นผู้ให้บริการตามประกาศข้อมูลจราจรหรือไม่ อยู่ภายใต้ ธปท. หรือไม่ แล้วกำหนดระยะเก็บ log ตามนั้น
• ประเมินพื้นที่ดิสก์จากจำนวน agent และระยะเก็บ แล้ววัดซ้ำจากระบบจริงในช่วงทดลอง
• กำหนดว่าข้อมูลต้องอยู่ที่ไหน (on-premises, cloud ในประเทศ หรือ SaaS)
• ออกแบบการป้องกันการแก้ไข log สิทธิ์ผู้ดูแล และการซิงก์เวลาของทุกเครื่อง
• กำหนดผู้รับผิดชอบดูแลแพลตฟอร์ม และผู้รับผิดชอบดูแจ้งเตือนและตอบสนอง แยกกันให้ชัด
• วางวิธีปรับจูน rule ที่ไม่ถูกเขียนทับตอนอัปเกรด และจดเหตุผลของการเปลี่ยนแต่ละครั้ง
• เปิด active response ทีละกรณีหลังทดสอบแล้ว ไม่เปิดทั้งหมดตั้งแต่วันแรก
• เปิด firewall สำหรับพอร์ตที่ใช้ (ในรุ่น 4.x คือ TCP 1514 และ 1515 สำหรับ agent) และวางแผนอัปเกรดเมื่อรุ่นใหม่ออก
• เปรียบเทียบค่าใช้จ่ายรวมหลายปี ทั้งค่า license หรือค่าบริการ ค่าเครื่องและดิสก์ และค่าคน ไม่ใช่เฉพาะค่า license

ถ้าระบบที่ต้องเฝ้าระวังเป็นระบบเก่าที่ยังต้องรันต่อ อ่าน วิธีดูแลระบบเก่าให้รันต่ออย่างปลอดภัย ประกอบ

UNIXDEV ติดตั้ง ปรับจูน และดูแล Wazuh ให้องค์กรภายใต้ขอบเขตที่ตกลงกัน ตั้งแต่ประเมินขนาดเครื่องและระยะเก็บ log ติดตั้ง agent วางโครงสร้าง rule ที่ปรับเพิ่มได้โดยไม่ถูกเขียนทับตอนอัปเกรด ไปจนถึงดูแลแพลตฟอร์มต่อเนื่องผ่านบริการ DevOps & Managed Services ดูรายละเอียดเพิ่มเติมที่หน้า Wazuh SIEM/XDR

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

• Wazuh documentation — Getting started
• Wazuh documentation — Components
• Wazuh documentation — Architecture
• Wazuh documentation — Use cases
• Wazuh documentation — Quickstart
• Wazuh documentation — Wazuh indexer installation guide
• Wazuh documentation — Custom rules
• Wazuh documentation — Active Response
• Wazuh documentation — MITRE ATT&CK framework
• Wazuh documentation — Regulatory compliance
• Wazuh 4.14.9 release notes
• Wazuh — LICENSE (wazuh/wazuh, tag v4.14.9)
• Wazuh Cloud
• Wazuh — Professional support
• NIST CSRC Glossary — SIEM tool
• NIST CSRC Glossary — Security Information and Event Management (SP 800-92)
• Splunk — Pricing models
• Splunk — Pricing
• Microsoft Sentinel pricing
• Elastic pricing
• Elastic Security Serverless pricing
• Google Security Operations — Understand billing
• TechTarget — IBM sells QRadar SaaS assets to Palo Alto Networks (พฤษภาคม 2024)
• ประกาศ กกม. เรื่องประมวลแนวทางปฏิบัติและกรอบมาตรฐานด้านการรักษาความมั่นคงปลอดภัยไซเบอร์ฯ พ.ศ. 2564
• Lawplus — สรุปการแก้ไข พ.ร.บ. คอมพิวเตอร์ฯ ปี 2560 (ภาษาอังกฤษ)
• ประกาศกระทรวงดิจิทัลฯ เรื่องหลักเกณฑ์การเก็บรักษาข้อมูลจราจรทางคอมพิวเตอร์ของผู้ให้บริการ พ.ศ. 2564
• พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (สคส.)
• ประกาศ ธปท. ที่ สกช. 5/2566 และแนวปฏิบัติประกอบ
• บทความที่เกี่ยวข้อง: Wazuh กับ EDR ต่างกันอย่างไร
• บทความที่เกี่ยวข้อง: ดูแลระบบเก่าให้รันต่ออย่างปลอดภัย

บทความโดย UNIXDEV Team · 30 ตุลาคม 2026 · ข้อมูลผลิตภัณฑ์และรูปแบบการคิดค่าบริการ ณ ตุลาคม 2026 ควรตรวจกับผู้ขายอีกครั้ง และสรุปข้อกฎหมายเพื่อประกอบการวางแผน ไม่ใช่คำแนะนำทางกฎหมาย