Security Checklist ก่อนเปิดบริการ Self-hosted ให้คนอื่นใช้

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

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

บทความนี้จึงไม่ใช่ production hardening guide และไม่มี configuration สำเร็จรูปให้คัดลอก เป้าหมายคือช่วยตัดสินใจว่า “ระบบพร้อมพอจะให้คนอื่นพึ่งหรือยัง” และมองเห็นจุดที่ควรหยุดแก้ก่อนเปิดจริง

สาระตั้งต้นจากโจทย์

ก่อนเรียบเรียง ผมสรุปแก่นจากหัวข้อและแหล่งข้อมูลแบบตรง ๆ ไว้ดังนี้:

1. ต้องรู้ก่อนว่าบริการนี้เปิดให้ใคร ข้อมูลอะไรอยู่ในระบบ ใครเป็นเจ้าของ และรับ downtime ได้แค่ไหน
2. Authentication ต้องไม่หยุดที่ “มีหน้า login” แต่รวมถึง MFA, สิทธิ์ผู้ใช้, admin access และ account recovery
3. Backup ต้องครอบคลุมทั้งข้อมูลและสิ่งที่จำเป็นต่อการกู้ระบบ และต้องเคยทดสอบ restore
4. Update ต้องมี owner, รอบตรวจ, วิธีประเมินช่องโหว่เร่งด่วน และทางถอยเมื่อ update แล้วพัง
5. Logging ต้องตอบคำถามตอนเกิดเหตุได้ โดยไม่เก็บ password, token หรือข้อมูลอ่อนไหวเกินจำเป็น
6. Rate limit และ abuse control ต้องอยู่ตรงจุดที่มีต้นทุนหรือถูกใช้ซ้ำอัตโนมัติได้ ไม่ใช่ใส่เฉพาะหน้า login
7. Incident plan ขั้นต่ำต้องบอกว่าใครตัดสินใจ ปิดหรือแยกระบบอย่างไร ติดต่อผู้ใช้ทางไหน และกู้คืนจากอะไร

OWASP Authentication Cheat Sheet แนะนำ MFA, login throttling และการบันทึกเหตุการณ์ authentication ขณะที่ OWASP Logging Cheat Sheet เน้นให้เก็บเหตุการณ์ที่ช่วยสืบสวน แต่ไม่บันทึก password, access token, session identifier และ secret โดยตรง ส่วนแนวทางของ NIST เรื่องการป้องกันข้อมูลสูญหายด้วย backup ให้ความสำคัญกับการดูแลและทดสอบไฟล์สำรอง ไม่ใช่เพียงสร้าง backup job ไว้

1. เริ่มจาก Service Boundary ก่อนเริ่มเช็ก Security Control

Checklist จะตอบอะไรไม่ได้ หากยังไม่รู้ว่ากำลังป้องกันอะไร ก่อนเปิดบริการควรเขียน service sheet สั้น ๆ ให้ตอบคำถามต่อไปนี้:

• ใครเข้าใช้ได้: เฉพาะคนในบ้าน ทีม ลูกค้าที่เชิญ หรือบุคคลทั่วไป
• เก็บข้อมูลชนิดใด: ไฟล์ทั่วไป ข้อมูลส่วนตัว เอกสารงาน หรือ secret
• ส่วนใดเปิดสู่อินเทอร์เน็ต และส่วน admin เข้าได้จากทางไหน
• ใครเป็น owner หลัก และใครทำแทนได้เมื่อ owner ไม่อยู่
• ผู้ใช้รับ downtime และการสูญเสียข้อมูลย้อนหลังได้เท่าไร
• dependency สำคัญมีอะไรบ้าง เช่น DNS, identity provider, email, storage และ backup target

คำตอบเหล่านี้กำหนดระดับ control ที่สมเหตุสมผล บริการอ่านบทความสาธารณะกับระบบแชร์เอกสารลูกค้าไม่ควรใช้เกณฑ์เดียวกัน และบริการที่ไม่มีผู้ดูแลสำรองอาจต้องออกแบบให้เรียบง่ายกว่าระบบที่มีทีมผลัดกันดู

2. Authentication ต้องครอบคลุมทางเข้าและทางกลับเข้า

การมี username กับ password ไม่ได้แปลว่า access พร้อมแล้ว จุดเริ่มต้นที่ควรตรวจคือผู้ใช้ทุกคนมีบัญชีของตนเองหรือไม่ มี MFA เมื่อระบบรองรับหรือไม่ และบัญชี admin ถูกแยกจากบัญชีใช้งานประจำหรือไม่

รายการที่ควรตอบให้ได้ก่อนเปิด:

1. ปิด default account และเปลี่ยน credential ที่มากับระบบแล้วหรือยัง
2. ผู้ใช้แชร์บัญชีกันหรือไม่ และสามารถยกเลิกสิทธิ์รายคนได้หรือไม่
3. บังคับ MFA สำหรับ admin และบัญชีที่เห็นข้อมูลสำคัญได้หรือไม่
4. หน้า admin แยกทางเข้าจากหน้าใช้งานทั่วไป หรือจำกัดด้วย VPN/secure tunnel ได้หรือไม่
5. session หมดอายุและถูกยกเลิกหลังเปลี่ยนรหัสหรือปิดบัญชีหรือไม่
6. account recovery มีหลักฐานพอยืนยันผู้ใช้ แต่ไม่เปิดช่องให้ข้าม MFA ง่าย ๆ หรือไม่
7. recovery code และ break-glass access ถูกเก็บในที่ที่ยังเข้าถึงได้เมื่อระบบหลักล่มหรือไม่

อย่าตั้ง account lockout แบบแข็งจนผู้โจมตีใช้ล็อกบัญชีคนอื่นได้ OWASP แนะนำให้คิด threshold, observation window และ lockout duration ร่วมกัน และใช้หลายชั้น เช่น MFA, throttling และการแจ้งเตือน มากกว่าฝากความหวังกับ control เดียว

3. Backup ต้องกู้ “บริการ” ไม่ใช่แค่มีไฟล์หนึ่งก้อน

คำว่า backup สำเร็จใน dashboard ยังไม่ตอบว่ากู้กลับมาใช้งานได้ ระบบหนึ่งอาจต้องใช้ database, uploaded files, encryption keys, configuration, version ของ application และลำดับการ restore ที่ถูกต้อง หากเก็บเพียง volume บางตัว เราอาจมีข้อมูลแต่เปิดอ่านไม่ได้

ก่อน launch ควรทำ restore drill ขนาดเล็กอย่างน้อยหนึ่งครั้ง:

1. เลือก backup ชุดหนึ่งโดยไม่ใช้ไฟล์ต้นฉบับ
2. กู้ลงพื้นที่แยกหรือเครื่องทดสอบ
3. ตรวจว่าบริการเปิดได้ ผู้ใช้เข้าได้ และข้อมูลตัวอย่างอ่านได้
4. จับเวลาคร่าว ๆ และบันทึกขั้นตอนที่ต้องเดา
5. ตรวจว่า backup ไม่ถูกลบง่ายด้วย credential ชุดเดียวกับระบบหลัก

แนวคิด 3-2-1 ช่วยกระจายความเสี่ยง แต่สิ่งสำคัญกว่าตัวเลขคือ backup แยกจาก failure เดียวกันและมีผลทดสอบ restore อ่านรายละเอียดต่อได้ใน 3-2-1 Backup Strategy สำหรับ Homelab

4. Update ต้องมีรอบ มี Owner และมีทางถอย

Self-hosted แปลว่าเรารับภาระ lifecycle ของ operating system, container image, application, plugin, database และ reverse proxy เอง หากไม่มี inventory เราจะไม่รู้ว่าประกาศช่องโหว่หนึ่งกระทบส่วนไหน

ไม่จำเป็นต้อง update ทุกอย่างทันทีแบบไม่ทดสอบ แต่ต้องมีวิธีตัดสินใจ:

• มีรายการ component และ version สำคัญหรือไม่
• ใครติดตาม security advisory และตรวจอย่างน้อยตามรอบที่กำหนด
• ช่องโหว่ที่ถูกโจมตีจริงหรือกระทบบริการ public ถูกเร่งได้อย่างไร
• ก่อนเปลี่ยนมี snapshot หรือ backup ที่ใช้ย้อนกลับได้หรือไม่
• มี maintenance window และช่องทางแจ้งผู้ใช้หรือไม่
• หลัง update ตรวจ login, upload, notification, backup และ integration สำคัญหรือยัง

ระบบที่ update อัตโนมัติทุกอย่างโดยไม่มี health check ก็เสี่ยง downtime ส่วนระบบที่รอให้ “ว่างก่อนค่อยอัป” มักค้างยาว ทางที่ใช้งานได้จริงคือกำหนด cadence ปกติ พร้อม fast track สำหรับเรื่องเร่งด่วน และมี rollback ที่เคยตรวจแล้ว

5. Logging ต้องตอบคำถาม และ Alert ต้องมีคนรับ

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

ขั้นต่ำควรเห็น:

• login สำเร็จและล้มเหลว, MFA failure และ account lockout
• การเปลี่ยนสิทธิ์ การสร้าง admin และการเปลี่ยน security setting
• การเข้าถึงหรือส่งออกข้อมูลที่สำคัญ
• application error, service restart, disk ใกล้เต็ม และ backup failure
• request ที่ชน rate limit หรือมี pattern ผิดปกติ

อย่าเก็บทุก payload เพียงเพราะทำได้ เพราะ log อาจกลายเป็นแหล่งรวม token, session, personal data และ secret ชุดใหม่ กำหนด retention, จำกัดสิทธิ์อ่าน และทดสอบว่าค้น timeline ได้จริง หากมี alert แต่ไม่มีใครได้รับ หรือแจ้งทุกเรื่องจนไม่มีใครอ่าน ก็ยังไม่ถือว่ามี monitoring

ถ้าต้องการเริ่มแบบไม่สร้าง SIEM ขนาดใหญ่ อ่านต่อได้ที่ วิธีวาง Log และ Monitoring สำหรับ Homelab แบบเรียบง่าย

6. Rate Limit ต้องวางตามจุดที่ถูก Abuse ได้

Rate limit ไม่ได้มีไว้ป้องกัน DDoS ขนาดใหญ่เท่านั้น มันช่วยลดการเดารหัส การยิง password reset, การสร้างบัญชี, การ upload จำนวนมาก, การเรียก API ราคาแพง และงานที่ trigger email หรือ webhook

OWASP Business Logic Security Cheat Sheet เตือนว่าการจำกัดเฉพาะ edge หรือ login ไม่พอ ฟังก์ชันที่สร้างมูลค่า ใช้ทรัพยากร หรือถูกทำซ้ำอัตโนมัติได้ควรมี limit ตามบริบทของมัน

ก่อนเปิดจริงให้ถามว่า:

1. Endpoint ใดสร้างต้นทุน CPU, storage, email หรือ API ภายนอก
2. จำกัดตาม IP อย่างเดียวจะกระทบผู้ใช้ที่แชร์เครือข่ายหรือไม่
3. หลัง login สามารถจำกัดตาม account หรือ action ได้หรือไม่
4. เมื่อชน limit ผู้ใช้ปกติได้รับข้อความที่ไม่เปิดเผยรายละเอียดการป้องกันเกินไปหรือไม่
5. เหตุการณ์ชน limit ถูกบันทึกและมี threshold แจ้งเตือนหรือไม่

ค่า limit ที่เข้มเกินไปอาจทำให้บริการใช้ไม่ได้ ส่วนค่าที่กว้างเกินไปไม่ช่วยอะไร เริ่มจากข้อมูลการใช้งานปกติ ทดสอบ burst ที่คาดว่าจะเกิด และปรับโดยดูทั้ง security กับ usability

7. Incident Plan ต้องใช้ได้ในวันที่เข้า Dashboard ไม่ได้

แผนขั้นต่ำไม่ต้องเป็นเอกสารยาว แต่ควรอยู่นอกระบบที่อาจล่มและตอบได้ว่า:

• ใครเป็น incident owner และใครมีสิทธิ์ตัดสินใจปิดบริการ
• จะ revoke session, token และ account ที่สงสัยอย่างไร
• จะแยกเครื่องหรือปิด public access โดยยังเก็บหลักฐานได้อย่างไร
• ติดต่อผู้ใช้นอกระบบผ่านช่องทางใด
• backup ชุดไหนน่าเชื่อถือ และเกณฑ์กลับมาเปิดคืออะไร
• ต้องบันทึก timeline, ขอบเขตผลกระทบ และการแจ้งผู้เกี่ยวข้องอะไรบ้าง

ลองซ้อมสถานการณ์ง่าย ๆ เช่น “พบ admin login จากที่ไม่รู้จัก” หรือ “database เปิดไม่ได้หลัง update” แล้วเดินตามแผน หากติดเพราะ credential อยู่ใน password manager ที่ผูกกับระบบเดียวกัน หรือช่องทางประกาศอยู่บนบริการที่ล่ม นั่นคือสิ่งที่ควรพบก่อนเกิดเหตุจริง

สำหรับโครงสร้าง role, escalation, evidence และ communication อ่านเพิ่มได้ใน Incident Response สำหรับ SME: ถ้าไม่มี SOC ควรเริ่มเตรียมจากอะไรบ้าง

Launch Gate: คำถามสุดท้ายก่อนเปิด

ผมแนะนำให้ยังไม่เปิดบริการ หากข้อใดข้อหนึ่งต่อไปนี้ตอบว่า “ไม่รู้”:

• รู้หรือไม่ว่าข้อมูลอะไรจะอยู่ในระบบและใครรับผิดชอบ
• admin ใช้ MFA และมี recovery path ที่ทดสอบแล้วหรือไม่
• เคย restore backup ลงสภาพแวดล้อมแยกและเปิดข้อมูลได้หรือไม่
• รู้หรือไม่ว่า component สำคัญตัวไหนต้องติดตาม update
• log ตอบ login, permission change, error และ backup failure ได้หรือไม่
• endpoint ที่ถูก abuse ได้มี rate limit และ alert ที่สมเหตุสมผลหรือไม่
• มีวิธีปิด public access, ติดต่อผู้ใช้ และเริ่มกู้คืนโดยไม่พึ่งระบบที่เสียหรือไม่

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

คำตอบที่เหมาะขึ้นกับจำนวนผู้ใช้ ความอ่อนไหวของข้อมูล บริการที่เปิดสาธารณะ acceptable downtime, admin workflow, monitoring และเวลาที่เจ้าของดูแลได้ หาก checklist นี้ยังมีคำตอบไม่ชัดหลายข้อ ให้เริ่มจากทำ sanitized diagram กับ service list หนึ่งหน้า แล้วค่อยขอ fixed-scope review ก่อนให้ผู้ใช้อื่นพึ่งระบบจริง

อ่านต่อที่เกี่ยวข้อง

• ตั้ง Reverse Proxy สำหรับหลาย service อย่างไรให้ดูแลง่ายในระยะยาว

แหล่งข้อมูล

• OWASP Authentication Cheat Sheet
• OWASP Logging Cheat Sheet
• OWASP Business Logic Security Cheat Sheet
• NIST: Protecting Data from Ransomware and Other Data Loss Events
• CISA: Use Logging on Business Systems