การตรวจสอบความเสี่ยงจริง

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

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

ขอการตรวจสอบทางเทคนิค กลับไปหน้าบริการ

การเช็กเบื้องต้นอยู่ใน audit เดียวกัน

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

สัญญาณวิกฤต

ฟอร์ม แอดมิน และไฟล์ที่เปิดเผย

เราตรวจว่า endpoint, backup, ไฟล์เก่า, error ทางเทคนิค, สิทธิ์แอดมิน หรือ flow ติดต่อถูกเปิดเผยหรือถูกนำไปใช้โจมตีได้หรือไม่

ความเสี่ยงเชิงปฏิบัติการ

CMS, deploy และ dependency

เราตรวจความต่างระหว่าง repository กับ server, plugin หรือ component ที่ไม่มีใครควบคุม, configuration ที่ไม่สอดคล้อง และปัญหาในขั้นตอนเผยแพร่

ลำดับการแก้ไข

จัดลำดับก่อนลงมือ fix

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

เราตรวจอะไรบ้าง

ฟอร์ม จุดรับอีเมล ลำดับการใช้โทเคน เซสชัน และการโจมตีจากบอท
แผงแอดมิน เวิร์กโฟลว์ของ CMS จุดเชื่อมการยืนยันตัวตน และเส้นทางการนำระบบขึ้นใช้งาน
การตั้งค่าที่เปิดเผยไฟล์สำรอง ไฟล์สำคัญ และตำแหน่งที่เสี่ยง
เมื่อมีข้อตกลง ขอบเขตงาน และสิทธิ์เข้าถึงที่เหมาะสม เราตรวจไฟล์ที่เกี่ยวข้องแบบทีละบรรทัด พร้อมระบบสแกนเฉพาะของเราเพื่อค้นหารูปแบบผิดปกติ เช่น backdoor หรือ payload แฝง และตรรกะ bypass ที่ไม่ควรมี
การพึ่งพา ตรรกะของระบบ .htaccess robots และโครงสร้างการเผยแพร่

Remediation และ BST Fortress

Audit ไม่ควรจบแค่รายการปัญหา เมื่อบริบททางเทคนิคเหมาะสมและได้รับอนุญาต เราใช้วิธีทำงาน BST Fortress เพื่อปิดช่องโหว่ ทำความสะอาดจุดอ่อน ลดพื้นผิวโจมตี และเสริมความมั่นคงให้ flow สำคัญ โดยไม่ทำให้การทำงานหลักของเว็บไซต์เสียหาย

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

สัญญาณที่บอกว่าอาจมีความเสี่ยง

ไม่แน่ใจว่า backup, log, ไฟล์เก่า หรือ credential อยู่ที่ไหน
ฟอร์มได้รับ spam, lead ปลอม, error หรือข้อความซ้ำ
CMS ใช้ plugin, theme หรือ component เก่าที่ไม่มีคนดูแลจริง
server ที่ออนไลน์อยู่ไม่ตรงกับ repository อย่างชัดเจน
sitemap, canonical, hreflang หรือ robots ไม่ได้ถูกควบคุมอย่างตั้งใจ
ต้องการรีดีไซน์เว็บโดยไม่พาช่องโหว่เดิมไปด้วย

สิ่งที่คุณจะได้รับ

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

ข้อสำคัญ

Audit ที่ดีช่วยหลีกเลี่ยงสองความผิดพลาดที่แพงมาก: ทำใหม่ทั้งหมดทั้งที่ไม่จำเป็น หรือเก็บชิ้นส่วนที่เป็นต้นเหตุของปัญหาไว้จนกลับมาสร้างความเสี่ยงอีกหลังรีดีไซน์

FAQ

การเช็กความปลอดภัยรวมอยู่ใน audit หรือไม่?

รวมอยู่แล้ว เราใช้เป็นช่วงแรกของ audit ไม่ใช่สินค้าแยกที่ทำให้สับสน

Audit เป็นแค่การสแกนอัตโนมัติหรือไม่?

ไม่ใช่ ระบบอัตโนมัติช่วยได้ แต่ส่วนสำคัญคือการวิเคราะห์แบบ manual ในฟอร์ม แอดมิน ไฟล์ configuration, deploy และลำดับการแก้ไข

ควรขอ audit เมื่อไร?

เมื่อเว็บไซต์สร้าง lead, เก็บข้อมูลสำคัญ, ใช้ CMS หรือ plugin ที่ไม่มีใครควบคุม, เจอ spam จากฟอร์ม, มี error แปลกๆ หรือกำลังจะรีดีไซน์โดยไม่อยากพาความเสี่ยงเก่าไปด้วย