"ทีมผม 4 คนใช้ root ร่วมกันทั้งทีม พอเว็บพังก็ไม่รู้ใครทำ" — สร้าง user แยกต่อคน + ให้สิทธิ์เฉพาะที่จำเป็น + เก็บ log ว่าใครทำอะไร (ไม่ต้องแจก root)

"พี่อ๊อด ทีมผม 4 คนใช้ root ร่วมกันทั้งทีมเลยครับ พอเว็บพังก็ไม่รู้ใครทำ แล้วล่าสุดมีคนลาออกด้วย ผมควรจัดการสิทธิ์ยังไงดี"

ข้อความนี้ทักเข้าไลน์ผมมาจากพี่คนหนึ่งที่เปิดเอเจนซีรับทำเว็บครับ — "พี่อ๊อด ทีมผม 4 คนใช้ root ร่วมกันทั้งทีมเลยครับ พอเว็บพังก็ไม่รู้ใครทำ แล้วล่าสุดมีคนลาออกด้วย ผมควรจัดการสิทธิ์ยังไงดี" พี่เขาเล่าต่อว่าทีมมี VPS เครื่องเดียว วางเว็บลูกค้าอยู่หลายราย และตั้งแต่เปิดบริษัทมาทุกคนก็ใช้รหัส root ตัวเดียวกันเข้าไปทำงาน — dev จะแก้เว็บก็ root, จะลง package ก็ root, รันสคริปต์ก็ root กันหมด เพราะตอนเริ่มต้น "มันง่ายดี ทุกคนเข้าได้เลย ไม่ต้องมาตั้งอะไรให้ยุ่งยาก"

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

ผมเข้าใจสถานการณ์นี้ดีมากครับ เพราะผมเองก็เคยเป็นคนทำเว็บที่ต้องดูแลเครื่องร่วมกับคนอื่น และนี่คือ (สิ่งที่พลาด) คลาสสิกที่เกือบทุกเอเจนซี/Software House เจอตอนทีมเริ่มโต — ตอนทีมมีคนเดียวหรือสองคน การแจก root ใช้ร่วมกันมันดู "ง่าย" แต่พอทีมโตขึ้น มีคนเข้าคนออก มีเว็บลูกค้าหลายราย มันกลายเป็นระเบิดเวลาทันที

ผมเขียนโค้ดและดูแล server มา 20 ปี และดูแล VPS ให้ลูกค้าที่เป็นเอเจนซี/ทีมหลายมือมาเยอะครับ วันนี้ผมจะอธิบายให้ครบว่า ทำไมการแจก root/รหัสร่วมให้ทั้งทีมมันอันตราย แล้วพาวางระบบที่ถูกต้องด้วยคำสั่งจริง: สร้าง user แยกต่อคน, ให้สิทธิ์เฉพาะที่จำเป็น, เก็บ log ว่าใครทำอะไร, และ offboarding เมื่อมีคนออก — อ่านจบคุณจะดูแลทีมหลายมือบนเครื่องเดียวได้อย่างสบายใจ ไล่ต้นเหตุได้ และไม่ต้องกลัวว่าคนที่ออกไปจะยังถือกุญแจอยู่

⚠️ ขอวางหลักคิดที่สำคัญที่สุดของบทความนี้ไว้ตรงนี้เลยครับ — เรื่องนี้คือหลักที่เรียกว่า least privilege (ให้สิทธิ์เท่าที่จำเป็น) ในระดับทีม หัวใจคือ: แต่ละคนควรมี "ตัวตน" (user) ของตัวเองบนเครื่อง และมีสิทธิ์เท่าที่งานของเขาต้องใช้จริงๆ — ไม่มากกว่านั้น การที่ทุกคนเป็น root เหมือนกันหมด คือการให้ทุกคนถือกุญแจ master ที่เปิดได้ทุกห้องและลบทั้งตึกได้ ทั้งที่หลายคนแค่ต้องเข้าห้องเดียว

ส่วนที่ 1 — ทำไมการแจก root / ใช้รหัสร่วมทั้งทีมถึงอันตราย (4 ข้อที่ระเบิดตอนทีมโต)

ก่อนจะแก้ ผมอยากให้เห็นภาพชัดๆ ว่าการที่ "ทั้งทีมถือกุญแจ root ปนกัน" มันสร้างปัญหาอะไรบ้าง — นี่คือ 4 ข้อที่ผมเจอกับเอเจนซีจริงๆ เรียงจากที่ทำให้ปวดหัวที่สุด

1) ⭐ ไม่รู้ว่าใครทำอะไร / ใครทำพัง (log บอกแค่ "root ทำ")

นี่คือข้อที่เจ็บที่สุดและเป็นเหตุผลที่พี่เอเจนซีคนนั้นทักผมมาครับ — เมื่อทุกคนเข้าเครื่องด้วย root ตัวเดียวกัน ระบบจะบันทึก log ทุกอย่างว่า "root เป็นคนทำ" แต่ root คือทุกคนในทีม วันที่เว็บพัง, ไฟล์หาย, config โดนเปลี่ยน, service ถูกปิด — คุณจะ ไล่ไม่ออกเลยว่าใครเป็นคนทำ และทำตอนไหน ทำให้แก้ปัญหายากขึ้นมาก (เพราะไม่รู้ต้นเหตุ) และที่แย่กว่าคือ มันสร้างบรรยากาศ "โทษกันไปมา" ในทีมโดยไม่มีหลักฐานชี้ชัด ย้ำนะครับว่านี่ไม่ใช่เรื่องจับผิดกัน แต่คือเรื่องของ ความรับผิดชอบและการแก้ปัญหา — รู้ว่าใครทำ = รู้ว่าจะถามใคร แก้ตรงจุดได้เร็ว

2) ถอนสิทธิ์ยากมากเมื่อมีคนออก (ต้องเปลี่ยนรหัสที่ทุกคนรู้)

ข้อนี้ตรงกับสถานการณ์ "มีคนลาออก" ที่พี่เขาเจอพอดี — เมื่อทุกคนใช้รหัส root ตัวเดียวกัน วันที่มีคนออกจากทีม คุณจะตัดสิทธิ์เฉพาะคนนั้นไม่ได้เลย เพราะ "สิทธิ์" มันไม่ได้ผูกกับตัวบุคคล มันผูกกับ "รหัสกลาง" ที่ทุกคนรู้ ทางเดียวที่จะปิดประตูใส่คนที่ออกไปคือ เปลี่ยนรหัส root ใหม่ แล้วแจกให้ทุกคนที่เหลือใหม่หมด ซึ่งวุ่นวาย เสี่ยงพลาด (เผลอแจกไม่ครบ คนทำงานไม่ได้) และในทางปฏิบัติหลายทีมก็ "ขี้เกียจเปลี่ยน" เลยปล่อยให้คนที่ออกไปแล้วยังเข้าเครื่องได้อยู่ — ซึ่งเป็นช่องโหว่ความปลอดภัยที่อันตรายมาก (เรื่อง offboarding ทีมแบบครบ ผมเขียนแยกไว้ที่ 🔑 SEC-24 — รหัสร่วม/offboarding ทีม ครับ)

3) รหัสรั่วทีเดียว = ทุกคนโดน

เมื่อทั้งทีมใช้รหัสเดียวกัน ความปลอดภัยของทั้งเครื่องก็ขึ้นอยู่กับ "จุดที่อ่อนแอที่สุด" ในทีม — ถ้ามีน้องคนใดคนหนึ่งเผลอเอารหัส root ไปจดไว้ในที่ไม่ปลอดภัย, แชตส่งให้กันในไลน์กลุ่ม, หรือเครื่องโน้ตบุ๊กของใครคนหนึ่งโดนแฮก รหัสนั้นรั่วทีเดียว = ทั้งเครื่องโดนทันที ไม่มีการแยกความเสียหาย เพราะทุกคนใช้กุญแจดอกเดียวกัน ตรงข้ามกับการที่แต่ละคนมี user + รหัส (หรือ key) ของตัวเอง ถ้าของคนหนึ่งรั่ว คุณก็ปิดเฉพาะ user นั้น ไม่กระทบคนอื่น

4) ทุกคนมีอำนาจลบทั้งเครื่องเท่ากันหมด (ไม่ว่าจะ junior หรือ senior)

ข้อสุดท้ายที่คนมองข้าม — เมื่อทุกคนเป็น root น้อง junior ที่เพิ่งเข้าทีมวันแรก กับ senior ที่ดูแลระบบมา 5 ปี มีอำนาจเท่ากันเป๊ะ คือลบทั้งเครื่องได้เหมือนกัน น้องที่ยังไม่ชำนาญ พิมพ์ rm -rf ผิด path ทีเดียว เว็บลูกค้าทั้งเครื่องก็หายได้ในวินาทีเดียว ทั้งที่จริงๆ งานของน้องอาจแค่ต้องแก้ไฟล์ในโฟลเดอร์เว็บเดียว ไม่จำเป็นต้องมีสิทธิ์แตะระบบทั้งเครื่องเลย นี่แหละคือเหตุผลที่เราต้อง ให้สิทธิ์ตามบทบาท ไม่ใช่แจกสิทธิ์สูงสุดให้ทุกคนเท่ากัน

🧭 สรุป 4 ข้อสั้นๆ: แจก root/รหัสร่วมทั้งทีม = (1) ไล่ไม่ออกว่าใครทำพัง · (2) ถอนสิทธิ์ยากเมื่อคนออก ต้องเปลี่ยนรหัสที่ทุกคนรู้ · (3) รหัสรั่วทีเดียวทุกคนโดน · (4) ทุกคนมีอำนาจลบทั้งเครื่องเท่ากัน — ทั้งหมดนี้แก้ได้ด้วยหลักเดียว: แต่ละคนมี user ของตัวเอง + ให้สิทธิ์เท่าที่จำเป็น + เก็บ log ว่าใครทำอะไร

ส่วนที่ 2 — วิธีที่ถูก: สร้าง user แยกต่อคน + ให้สิทธิ์เฉพาะที่จำเป็น (คำสั่งจริง)

ข่าวดีคือ การวางระบบสิทธิ์แบบนี้ไม่ได้ยากเลยครับ ทำครั้งเดียวตอนตั้งต้นแล้วใช้ยาว มาทำกันทีละขั้น (ขั้นพวกนี้ต้องทำด้วยสิทธิ์สูง — ถ้าคุณเลิก root มาทำงานผ่าน sudo user แล้วตามที่ผมแนะนำใน SRV-013 เลิกใช้ root ก็เติม sudo หน้าคำสั่งเหล่านี้)

ขั้นที่ 1 — สร้าง user แยกให้แต่ละคนในทีม

หลักง่ายๆ คือ หนึ่งคน หนึ่ง user ตั้งชื่อให้รู้ว่าใครเป็นใคร เช่น som, aof, bank:

adduser som        # สร้าง user ให้น้องส้ม (ทำซ้ำสำหรับทุกคนในทีม)

คำสั่งนี้จะสร้าง user ใหม่พร้อมถามตั้งรหัสผ่าน (ให้แต่ละคนตั้งรหัสของตัวเอง อย่าใช้รหัสร่วม) ตอนนี้แต่ละคนมี "ตัวตน" ของตัวเองบนเครื่องแล้ว — ทุกอย่างที่เขาทำต่อจากนี้จะถูกบันทึกในชื่อเขา ไม่ใช่ "root"

💡 ในทางปฏิบัติ ทีมส่วนใหญ่ควรให้แต่ละคน login ด้วย SSH key ของตัวเอง แทนรหัสผ่าน (ปลอดภัยกว่าและถอนทีละคนง่าย) — แต่ละคนสร้าง key คู่ของตัวเอง แล้วเอา public key ไปใส่ในไฟล์ ~/.ssh/authorized_keys ของ user เขาบนเครื่อง วิธีนี้ทำให้ตอน offboarding แค่ลบบรรทัด key ของคนที่ออกก็ตัดสิทธิ์ได้ทันที (รายละเอียด key auth เต็มรูปอยู่ที่ SRV-016 hardening SSH)

ขั้นที่ 2 — จัด groups ตามบทบาท

แทนที่จะให้สิทธิ์ทีละคน ให้คิดเป็น "บทบาท" แล้วจัดเป็น group — เช่น ทีม dev ที่ต้องแก้ไฟล์เว็บ จัดเข้า group web, ทีมที่ดูแลระบบจริงๆ จัดเข้า group ที่มีสิทธิ์ sudo:

groupadd web                  # สร้าง group สำหรับคนที่ดูแลไฟล์เว็บ
usermod -aG web som           # เพิ่มน้องส้มเข้า group web
usermod -aG web aof           # เพิ่มน้องเอฟเข้า group web

⚠️ -aG สำคัญมาก: -a คือ "เพิ่มเข้าไป" (append) — ถ้าลืม -a แล้วใช้ -G เดี่ยวๆ มันจะ เขียนทับ group ทั้งหมดของ user นั้น (เตะหลุดจาก group อื่นที่เคยอยู่) เป็น (สิ่งที่พลาด) คลาสสิกอีกอันที่ทำคนงงว่าทำไมจู่ๆ user เข้าอะไรไม่ได้ — จำไว้ว่าต้อง -aG เสมอ

การจัด group แบบนี้ทำให้คุณกำหนดสิทธิ์การเข้าถึงไฟล์/โฟลเดอร์เว็บให้ทั้ง group ทีเดียว (ผ่าน ownership/permission ของไฟล์ ซึ่งผมลงลึกเรื่องนี้ที่ SEC-18 file permissions/ownership) — มีคนใหม่เข้าทีม ก็แค่เพิ่มเข้า group ไม่ต้องไล่ตั้งสิทธิ์ใหม่ทั้งหมด

ขั้นที่ 3 — ให้สิทธิ์ sudo เฉพาะคนที่จำเป็น (และจำกัดได้ถึงระดับคำสั่ง)

นี่คือหัวใจของ least privilege ระดับทีมครับ — ไม่ใช่ทุกคนต้องมี sudo น้อง dev ที่แค่แก้ไฟล์เว็บในโฟลเดอร์ของตัวเอง อาจไม่ต้องการ sudo เลยด้วยซ้ำ ส่วนคนที่ต้องดูแลระบบจริงๆ (ลง package, restart service) ค่อยให้ sudo

ให้สิทธิ์ sudo เต็ม (สำหรับคนที่ไว้ใจให้ดูแลระบบ) — คำสั่งต่างกันตามดิสโทร:

# RHEL / AlmaLinux / Rocky / CentOS — group ที่ให้สิทธิ์ sudo ชื่อ wheel
usermod -aG wheel aof

# Ubuntu / Debian — group ที่ให้สิทธิ์ sudo ชื่อ sudo
usermod -aG sudo aof

แต่ถ้าคุณอยากให้บางคน ทำได้แค่บางคำสั่ง (เช่น น้องคนหนึ่งมีหน้าที่ restart web server ได้ แต่ไม่ให้แตะอย่างอื่น) — ตรงนี้คือพลังของ visudo ครับ อย่าแก้ไฟล์ sudoers ด้วย editor ธรรมดาเด็ดขาด ให้ใช้ visudo เสมอ เพราะมันจะ ตรวจ syntax ให้ก่อนบันทึก ถ้าพิมพ์ผิดมันจะเตือน ไม่งั้นไฟล์ sudoers พังแล้วทั้งเครื่องใช้ sudo ไม่ได้เลย:

sudo visudo

แล้วเพิ่มบรรทัดแบบจำกัดคำสั่งเฉพาะ เช่น (ให้ user bank restart ได้เฉพาะ nginx เท่านั้น โดยไม่ต้องใส่รหัส):

bank ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx

หรือถ้าจะจัดเป็นทั้ง group ให้ใช้ % นำหน้าชื่อ group:

%web ALL=(ALL) /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx

แบบนี้ทุกคนใน group web จะ restart/reload nginx ได้ (ระบบจะถามรหัสของเขาเอง) แต่ทำอย่างอื่นที่เป็น root ไม่ได้ — นี่คือ least privilege ของจริง: ให้เท่าที่งานต้องใช้ ไม่ให้ทั้งพวง

ขั้นที่ 4 — ทดสอบว่าสิทธิ์ทำงานถูกต้อง (ขั้นนี้ห้ามข้าม)

หลังตั้งสิทธิ์ ให้ทดสอบจริงเสมอ เปิด session ของ user คนนั้นแล้วลอง:

ssh aof@<ip-server>
sudo whoami                    # ควรถามรหัส aof แล้วตอบ root (ถ้าให้ sudo เต็ม)

ส่วน user ที่จำกัดคำสั่ง ให้ทดสอบว่าคำสั่งที่อนุญาตทำได้ และคำสั่งที่ไม่อนุญาต ต้องโดนปฏิเสธ:

sudo systemctl restart nginx   # ควรทำได้ (อยู่ในรายการที่อนุญาต)
sudo dnf install something      # ควรโดนปฏิเสธ "not allowed" (เพราะไม่ได้ให้สิทธิ์นี้)

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

ส่วนที่ 3 — เก็บ log ว่าใครทำอะไร (ไล่ต้นเหตุได้จริง)

ประโยชน์ที่ใหญ่ที่สุดของการแยก user ต่อคน คือตอนนี้ระบบ บันทึกได้ว่าใครทำอะไร เมื่อไหร่ — มาดูกันว่าจะเปิดดูที่ไหนบ้างเมื่อเกิดเรื่อง

ดูว่าใครเข้าเครื่องบ้าง (login history):

last           # แสดงรายการ login ล่าสุดทั้งหมด — ใคร เข้าจาก IP ไหน เมื่อไหร่ นานแค่ไหน
lastlog        # แสดงเวลา login ล่าสุดของแต่ละ user (ใครไม่ได้เข้านานแล้วก็เห็น)
who            # ใครกำลัง login อยู่ "ตอนนี้"

last มีประโยชน์มากเวลาสงสัยว่ามีใครเข้ามาแตะเครื่องช่วงที่เกิดปัญหา — คุณจะเห็นเลยว่าช่วงเวลานั้น user ไหนเข้ามาบ้าง เข้าจาก IP อะไร

ดู log การ login และการใช้ sudo (ใครยกสิทธิ์ทำอะไร):

# RHEL / AlmaLinux / Rocky / CentOS
sudo cat /var/log/secure | grep sudo

# Ubuntu / Debian
sudo cat /var/log/auth.log | grep sudo

ไฟล์ /var/log/secure (RHEL) หรือ /var/log/auth.log (Ubuntu) จะบันทึกทุกครั้งที่มีคน login และทุกครั้งที่มีคนใช้ sudo — รวมถึง "user ไหน รันคำสั่ง sudo อะไร เมื่อไหร่" นี่คือสิ่งที่คุณไล่ไม่ได้เลยตอนทุกคนเป็น root แต่ตอนนี้ไล่ได้ ตัวอย่างเช่นถ้าเว็บพังเพราะมีคน restart service ผิดตัว คุณก็ค้น log เจอว่า "user som สั่ง sudo systemctl ... เวลา 14:32" แล้วไปคุยกับน้องส้มได้ตรงจุด

💡 ใน distro ใหม่ๆ ที่ใช้ systemd คุณดู log การใช้ sudo ผ่าน journalctl ได้ด้วย เช่น sudo journalctl _COMM=sudo หรือ sudo journalctl -u sshd เพื่อดู log การเข้า SSH — เลือกใช้ตามที่ถนัดครับ ผลลัพธ์คล้ายกัน

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

ส่วนที่ 4 — Offboarding: ปิด/ลบ user ทันทีเมื่อมีคนออก

มาถึงส่วนที่พี่เอเจนซีคนนั้นกังวลที่สุด — "น้องที่ลาออกไป ยังเข้าเครื่องผมได้อยู่ไหม" เมื่อแต่ละคนมี user ของตัวเองแล้ว การจัดการตอนคนออกจะ ง่ายและสะอาดมาก ไม่ต้องไปยุ่งกับคนที่เหลือเลย

ทางเลือกที่ 1 — ล็อก user ไว้ก่อน (ปิดชั่วคราว ยังไม่ลบ):

sudo usermod -L som        # lock — ปิดไม่ให้ login ด้วยรหัสผ่านได้ แต่ยังเก็บไฟล์/ข้อมูลไว้

ผมแนะนำให้ lock ก่อนลบเสมอ ในช่วงแรกครับ เพราะถ้าน้องที่ออกไปมีไฟล์งานค้างอยู่ใน home directory หรือมี cron job/process อะไรที่ยังต้องเช็ก คุณจะได้มีเวลาตรวจสอบก่อน ไม่ลบทิ้งแล้วมารู้ทีหลังว่ามีของสำคัญอยู่

ทางเลือกที่ 2 — ลบ user ออกเลย (เมื่อแน่ใจแล้ว):

# Ubuntu / Debian
sudo deluser som

# RHEL / AlmaLinux / Rocky / CentOS
sudo userdel som
# ถ้าต้องการลบ home directory ของเขาด้วย
sudo userdel -r som

ขั้นที่ห้ามลืม — เพิกถอน SSH key ของคนที่ออก:

ถ้าทีมคุณใช้ SSH key (ซึ่งควรใช้) การ lock/ลบ user ปกติก็ตัดทางเข้าแล้ว แต่ให้เช็กให้ชัวร์ว่า public key ของคนที่ออก ไม่หลงเหลืออยู่ใน authorized_keys ของ user อื่น ด้วย (บางทีมเผลอเอา key เดียวกันไปใส่หลาย user):

sudo grep -r "ชื่อหรือ comment ใน key ของคนที่ออก" /home/*/.ssh/authorized_keys

เจอตรงไหนก็ลบบรรทัดนั้นออก — เท่านี้คนที่ออกไปก็เข้าเครื่องไม่ได้อีกเลย โดยไม่ต้องเปลี่ยนรหัสของใครในทีมที่เหลือเลยสักคน เห็นความต่างชัดๆ ไหมครับ — เทียบกับสมัยใช้ root ร่วมที่ต้องเปลี่ยนรหัสแล้วแจกใหม่ทั้งทีม ตอนนี้แค่ปิด user คนเดียวก็จบ (เรื่อง offboarding ทีมแบบครบทุกบัญชี ไม่ใช่แค่ server — รวมถึงรหัสร่วมในระบบอื่นๆ — ผมเขียนต่อไว้ที่ SEC-24 ครับ)

📌 (สิ่งที่พลาด): การแจก root หรือใช้รหัสร่วมให้ทั้งทีม "เพราะมันง่าย ทุกคนเข้าได้" คือ (สิ่งที่พลาด) ที่หลอกเราด้วยความสะดวกตอนทีมยังเล็ก — แต่พอทีมโต มีคนเข้าคนออก มีเว็บลูกค้าหลายราย มันระเบิดทันที: (1) ไล่ไม่ออกว่าใครทำพัง เพราะ log บอกแค่ "root ทำ" = ทุกคน · (2) ถอนสิทธิ์ยากเมื่อคนออก ต้องเปลี่ยนรหัสที่ทุกคนรู้พร้อมกัน · (3) รหัสรั่วทีเดียวทุกคนโดน เพราะใช้กุญแจดอกเดียวกัน · (4) ทุกคนมีอำนาจลบทั้งเครื่องเท่ากัน ไม่ว่า junior หรือ senior — ทางแก้ไม่ใช่ "ระวังกันเอง" แต่คือ วางระบบให้แต่ละคนมี user ของตัวเอง + ให้สิทธิ์เท่าที่จำเป็น + เก็บ log + ปิด user ทันทีเมื่อคนออก (least privilege ระดับทีม)

สรุปเป็นตาราง — บทบาทในทีม → สิทธิ์ที่ควรได้

เล่าให้ฟังหนึ่งเคส

ผมขอเล่าเคสที่ตรงกับเรื่องนี้มากครับ (ขอปรับรายละเอียดเล็กน้อยเพื่อความเป็นส่วนตัว) — มีเอเจนซีรับทำเว็บเจ้าหนึ่งย้ายมาอยู่กับเรา ทีมประมาณ 4-5 คน ตอนแรกทุกคนใช้ root ร่วมกันหมดตามที่เคยทำมา วันหนึ่งมีเว็บลูกค้ารายใหญ่ของเขาล่ม — ปรากฏว่ามีการตั้งค่าอะไรบางอย่างเปลี่ยนไป แต่ถามทั้งทีมก็ไม่มีใครรู้ว่าใครทำ เพราะ log ขึ้น "root" หมด พี่เจ้าของเอเจนซีเครียดมากเพราะลูกค้ารายนั้นสำคัญ

ตอนพี่เขาทักมาหาผม ผมช่วยกู้เว็บกลับมาก่อนจาก auto backup รายวันที่เราเก็บแยกไว้ที่ QNAP NAS off-site (ไม่ได้กองอยู่บนเครื่องเดียวกับเว็บ) เว็บกลับมาภายในไม่นาน หลังจากนั้นสิ่งที่ผมช่วยพี่เขาทำเป็นอันดับแรกคือ วางโครงสิทธิ์ใหม่ทั้งหมด — สร้าง user แยกให้ทุกคนในทีม, จัด group ตามบทบาท (ใครแก้เว็บอย่างเดียวก็ไม่ต้องมี sudo), ให้ sudo เฉพาะคนที่ดูแลระบบจริงๆ, แล้วเปิดให้ดู log ผ่าน last และ /var/log/secure ได้

ผ่านไปไม่กี่สัปดาห์ มีน้องในทีมพี่เขาลาออก — คราวนี้พี่เขาแค่ usermod -L ปิด user น้องคนนั้น แล้วลบ key ออก ใช้เวลาไม่ถึงนาที ไม่ต้องไปยุ่งกับใครในทีมที่เหลือเลย พี่เขาทักมาบอกผมว่า "พี่อ๊อด ผมเพิ่งเข้าใจว่าที่ผ่านมาผมนั่งบนระเบิดเวลามาตลอด — ทุกคนถือ root เหมือนกันหมด ถ้าวันนั้นน้องที่ออกไปไม่พอใจอะไรขึ้นมา เขาเข้ามาทำอะไรกับเครื่องผมก็ได้ และผมไล่ไม่ได้ด้วยซ้ำว่าใครทำ" นั่นแหละครับ คือเหตุผลที่ผมอยากให้ทุกทีมวางระบบสิทธิ์ให้ถูก "ก่อน" จะเจอวันที่เกิดเรื่อง

แล้ว PhalconHost ช่วยเรื่องนี้ยังไง?

เรื่องการจัดสิทธิ์ทีมนี้ผมว่ามันสะท้อนวิธีที่ผมดูแลลูกค้าได้ชัดมากครับ เพราะลูกค้าผมจำนวนไม่น้อยเป็นเอเจนซี/Software House ที่ดูแลกันหลายมือ

อย่างแรก — ผมเป็นนักพัฒนาที่เคยทำงานในทีมที่ดูแล server ร่วมกับคนอื่นมาก่อน ผมเลย เข้าใจ ขั้นตอนการทำงาน ของทีมเอเจนซีจริงๆ ไม่ใช่แค่ "ส่งเครื่องให้แล้วจบ" — เวลาลูกค้าที่เป็นทีมเริ่มใช้ VPS กับเรา ผมช่วยวางโครงสิทธิ์ให้เหมาะกับวิธีทำงานของทีมเขา ใครควรมี sudo ใครไม่ควร จัด group ยังไงให้แก้เว็บลูกค้าหลายรายได้โดยไม่ปนกัน และสำหรับลูกค้าที่ใช้ DirectAdmin การแยก user/แยกเว็บแต่ละราย (reseller, หลาย user) ก็มีโครงสร้างรองรับอยู่แล้วในตัว ทำให้จัดการทีม + ลูกค้าหลายรายบนเครื่องเดียวได้เป็นระเบียบ — นี่แหละครับคือ Dev ดูแล Dev ผมดูแลเครื่องคุณแบบที่ผมเข้าใจว่าทีมที่ทำงานจริงต้องการอะไร

อย่างที่สอง — และสำคัญไม่แพ้กัน — ไม่ว่าจะวางสิทธิ์ดีแค่ไหน วันหนึ่งคนในทีมก็พลาดกันได้ ลบผิด แก้ทับผิด มันเกิดขึ้นได้เสมอโดยเฉพาะทีมที่มีหลายมือ ผมเลยให้ auto backup ฟรีรายวันกับลูกค้าทุกคน ไม่คิดเพิ่ม และเก็บแยกที่ QNAP NAS off-site (ไม่กองบนเครื่องเดียวกับเว็บ) สำหรับผม backup ไม่ใช่แค่ "ฟีเจอร์" แต่มันคือ ตาข่ายนิรภัยตัวสุดท้ายเวลาใครในทีมพลาดลบของจริงๆ — เหมือนเคสเอเจนซีที่เล่าไปข้างบน ถ้าวันนั้นไม่มี backup เก็บแยกไว้ เรื่องคงจบไม่สวย นี่คือเหตุผลที่ผมยืนยันมาตลอด 11 ปีว่า "ข้อมูลลูกค้าต้องไม่หาย" แม้ตอนเกิดเรื่อง

ปิดท้าย

ถ้าตอนนี้ทีมคุณยังแจก root หรือใช้รหัสร่วมกันอยู่ — ผมไม่ได้จะบอกว่าคุณทำผิดนะครับ ตอนทีมเล็กมันก็ดูง่ายดีจริงๆ ผมแค่อยากให้คุณวางระบบให้ถูก "ก่อน" ที่จะต้องเจอวันที่เว็บพังแล้วไล่ไม่ออกว่าใครทำ หรือวันที่มีคนออกแล้วถอนสิทธิ์ไม่ได้ ตั้งหลักตามนี้: สร้าง user แยกต่อคน (adduser) → จัด group ตามบทบาท (usermod -aG) → ให้ sudo เฉพาะคนที่จำเป็น และจำกัดถึงระดับคำสั่งได้ด้วย visudo → เก็บ log ไล่ต้นเหตุได้ (last, /var/log/secure หรือ auth.log) → พอมีคนออกก็ปิด/ลบ user ทันที (usermod -L, deluser/userdel) + เพิกถอน key — ทำครั้งเดียวตอนตั้งต้น แล้วทีมคุณจะดูแลเครื่องร่วมกันได้อย่างสบายใจและตรวจสอบได้

หรือถ้าทีมคุณกำลังจะย้าย VPS มา หรือมีเครื่องอยู่แล้วแต่ไม่แน่ใจว่าจะจัดสิทธิ์ทีมหลายมือยังไงให้ถูก — ทักมาคุยกับผม (คุณอ๊อด) ทาง LINE ได้เลยครับ ผมช่วยวางโครงสิทธิ์ให้เหมาะกับวิธีทำงานของทีมคุณ แยก user/แยกเว็บลูกค้าหลายรายให้เป็นระเบียบ และตั้ง log ให้ไล่ต้นเหตุได้ — คุยกับ Dev ตัวจริงที่เข้าใจ ขั้นตอนการทำงาน ของทีมเอเจนซี ไม่ใช่ปล่อยให้ทั้งทีมถือกุญแจ root ปนกันจนวันหนึ่งไล่ไม่ออกว่าใครทำครับ