วิธีรัน Claude Code บนเซิร์ฟเวอร์ให้ปลอดภัยและจำกัดสิทธิ์

ความหมายของการรัน Claude Code บนเซิร์ฟเวอร์อย่างปลอดภัย

การรัน Claude Code บนเซิร์ฟเวอร์อย่างปลอดภัยนั้น คุณต้องคงการแจ้งเตือนเพื่อขอสิทธิ์ไว้ รันด้วยผู้ใช้เฉพาะที่ไม่มีสิทธิ์ระดับ root และกำหนดขอบเขตที่ชัดเจนสำหรับการรันแบบอัตโนมัติแทนการให้ความไว้วางใจโดยสมบูรณ์ โดยใช้ sandbox ที่มีมาให้ในตัว, คอนเทนเนอร์ หรือ VPS แบบใช้แล้วทิ้งที่ไม่มีข้อมูลสำคัญของคุณ แฟล็ก --dangerously-skip-permissions จะข้ามขั้นตอนการขออนุมัติระหว่างโมเดลกับเชลล์ของคุณ การแลกเปลี่ยนนี้อาจสมเหตุสมผลสำหรับงานอัตโนมัติ แต่ต้องทำภายในขอบเขตที่จำกัดขอบเขตความเสียหายหากเกิดคำสั่งที่ผิดพลาดเท่านั้น คู่มือนี้จะอธิบายว่าแฟล็กดังกล่าวเปลี่ยนแปลงการทำงานอย่างไร และวิธีสร้างขอบเขตดังกล่าวโดยแบ่งเป็นระดับการแยกส่วนที่เข้มงวดขึ้นตามลำดับ

สิ่งที่ Claude Code สามารถทำได้บนเครื่องของคุณ

Claude Code คือ coding agent ที่ทำงานใน terminal ของคุณ มันสามารถอ่านไฟล์ เขียนไฟล์ และรัน shell command ในฐานะผู้ใช้ที่เรียกใช้งานมัน นี่คือคุณค่าหลักของเครื่องมือนี้: มันสามารถ clone repository, แก้ไขโค้ด, รันการทดสอบ, อ่านผลลัพธ์ที่ล้มเหลว และแก้ไขโค้ดวนซ้ำได้โดยที่คุณไม่ต้องพิมพ์คำสั่งเอง หากคุณยังไม่ได้ติดตั้งบนเซิร์ฟเวอร์ การรัน Claude Code บน VPS ด้วย tmux ได้ครอบคลุมขั้นตอนการติดตั้งและการจัดการ session ไว้แล้ว หน้านี้จะกล่าวถึงอำนาจที่คุณมอบให้มันเมื่อติดตั้งเสร็จสิ้น

ความเสี่ยงคือประโยคเดิมที่ต้องอ่านซ้ำ กระบวนการที่รัน shell command ในฐานะผู้ใช้ของคุณสามารถทำทุกอย่างที่ผู้ใช้ของคุณทำได้ มันสามารถอ่าน ~/.ssh/id_ed25519, ~/.aws/credentials และไฟล์ .env ทุกไฟล์ที่ผู้ใช้ของคุณเปิดได้ มันสามารถรัน curl และส่งข้อมูลไปยัง host ใดก็ตามที่เซิร์ฟเวอร์เข้าถึงได้ มันสามารถรัน git push --force ได้ ตัว agent ไม่มีเจตจำนงเป็นของตัวเอง อันตรายอยู่ที่งานอาจผิดพลาด หรือข้อความที่มันอ่านระหว่างทำงานอาจมีคำสั่งที่เขียนโดยผู้อื่นแฝงอยู่ เช่น หน้าเว็บที่มันดึงข้อมูลมา หรือความคิดเห็นใน issue ที่ถูกขอให้แก้ไข กรณีหลังนี้เรียกว่า prompt injection และเป็นเหตุผลว่าทำไม "โมเดลปกติจะมีความสมเหตุสมผล" จึงไม่ใช่แผนการรักษาความปลอดภัย คำสั่งอาจมาจากแหล่งที่ใกล้ตัวกว่านั้นได้ เพราะ Claude Code สอง session บนเครื่องเดียวกันสามารถส่งข้อความถึงกันได้ และข้อความจาก session พี่น้องก็เป็นเพียงข้อความที่ agent ผู้รับอ่านเท่านั้น คุณต้องวางแผนรับมือกรณีที่การทำงานผิดพลาด ไม่ใช่กรณีที่การทำงานเป็นไปตามปกติ

ระบบสิทธิ์การเข้าถึงในภาษาที่เข้าใจง่าย

โดยค่าเริ่มต้น Claude Code จะขออนุญาตก่อนดำเนินการเสมอ การอ่านไฟล์ภายในโปรเจกต์จะเกิดขึ้นโดยไม่มีการแจ้งเตือน แต่หากมีการแก้ไขไฟล์หรือรันคำสั่ง shell ระบบจะแสดงการแก้ไขหรือคำสั่งนั้นให้คุณตรวจสอบก่อนและรอการตอบรับ คุณสามารถอนุมัติการกระทำครั้งเดียว หรืออนุมัติการกระทำประเภทนั้นสำหรับช่วงเวลาที่เหลือของ session ได้ การอนุมัติเหล่านี้มีผลเฉพาะภายใน session เท่านั้น หากคุณออกจาก CLI เมื่อเริ่ม session ใหม่ ระบบจะกลับมาทำงานด้วยความระมัดระวังอีกครั้ง สำหรับกฎที่คุณต้องการคงไว้ ไฟล์การตั้งค่าจะเก็บรายการ allow, ask และ deny แบบถาวรไว้ ตัวอย่างเช่น: อนุญาต git status, ถามเมื่อมีการใช้ git push, และปฏิเสธการอ่าน .env กฎการปฏิเสธ (deny) จะมีความสำคัญสูงสุดเสมอ พื้นฐานนี้กำลังจะเปลี่ยนไปเนื่องจากโหมด auto จะกลายเป็นค่าเริ่มต้นในวันที่ 14 August 2026 ดังนั้นจึงควรทำความเข้าใจว่า โหมดสิทธิ์แต่ละแบบอนุญาตให้ทำอะไรได้บ้าง ก่อนที่คุณจะตัดสินใจว่าเซิร์ฟเวอร์ที่คุณไม่สามารถเฝ้าดูได้ควรใช้โหมดใด

การออกแบบนี้ตั้งอยู่บนสมมติฐานว่ามีมนุษย์คอยเฝ้าดู terminal อยู่ ซึ่งเป็นเรื่องจริงหากใช้งานบนแล็ปท็อป แต่บนเซิร์ฟเวอร์ ประเด็นสำคัญมักจะเป็นการที่ไม่มีใครเฝ้าดูอยู่ คุณอาจเริ่มงานระยะยาวภายใน tmux แล้วเข้านอน หากเอเจนต์หยุดเพื่อถามคำถามตอนตี 2 งานนั้นก็จะไม่คืบหน้าจนกว่าจะถึงเช้า การหยุดชะงักนี้ทำให้เสียทั้งเงินและเวลา เพราะ session ของ Claude Code ที่ไม่ได้ใช้งานจะสูญเสีย warm prompt cache และการทำงานรอบถัดไปจะต้องเสียค่าใช้จ่ายในการสร้าง cache ใหม่ นี่คือเหตุผลที่แท้จริงว่าทำไมผู้คนถึงเลือกใช้ flag สำหรับข้ามการตรวจสอบบนเซิร์ฟเวอร์ และปัญหาที่มันช่วยแก้ไขนั้นเป็นเรื่องจริง ส่วนที่เหลือของคู่มือนี้จะกล่าวถึงวิธีการแก้ไขปัญหานี้โดยไม่ต้องละทิ้งมาตรการป้องกันทั้งหมดที่มีอยู่

สิ่งที่ --dangerously-skip-permissions เปลี่ยนแปลง

claude --dangerously-skip-permissions จะปิดขั้นตอนการขออนุมัติ การแก้ไขไฟล์จะเกิดขึ้นโดยไม่มีการแจ้งเตือน คำสั่ง shell จะทำงานโดยไม่มีการถามยืนยัน และการตรวจสอบ protected-path ที่ปกติจะคอยป้องกันตำแหน่งที่สำคัญก็จะถูกข้ามไปด้วย กฎการปฏิเสธ (deny rules) ที่คุณกำหนดไว้ชัดเจนจะยังคงมีผล และการกระทำที่รุนแรงมากบางอย่างยังคงมีการหยุดถาม แต่สรุปการทำงานได้ง่ายๆ คือ: สิ่งใดก็ตามที่โมเดลตัดสินใจให้รัน มันก็จะรันทันที

มีข้อเท็จจริง 2 ประการเกี่ยวกับ flag นี้ที่สำคัญบนเซิร์ฟเวอร์ ประการแรก มันจะถูกบล็อกเมื่อ Claude Code ทำงานในฐานะ root หรือภายใต้ sudo บน Linux และ macOS เนื่องจาก root ที่ไม่มีการถามยืนยันสามารถเปลี่ยนแปลงไฟล์หรือบริการใดๆ บนเครื่องได้ ตัว agent จำเป็นต้องมีบัญชีผู้ใช้ที่ไม่มีสิทธิ์พิเศษ (unprivileged account) ของตัวเองอยู่แล้ว และ flag นี้จะบังคับให้เป็นเช่นนั้น ประการที่สอง flag นี้ไม่ได้เปลี่ยนพฤติกรรมของโมเดลแต่อย่างใด มันเพียงแค่เอาตัวมนุษย์ออกจากวงจรการตัดสินใจเท่านั้น ดังนั้นทุกความผิดพลาดที่ปกติแล้วการถามยืนยันจะช่วยตรวจพบได้ ตอนนี้จะถูกดำเนินการทันที

ดังนั้น นี่คือการประเมินตามความเป็นจริง หากคุณข้ามการตรวจสอบสิทธิ์ คำถามด้านความปลอดภัยจะเปลี่ยนจาก "agent จะทำอะไรที่เลวร้ายหรือไม่" ไปเป็น "การกระทำที่ผิดพลาดหนึ่งครั้งจะสร้างความเสียหายได้มากเพียงใด" คุณต้องเลิกพยายามควบคุมทุกการตัดสินใจ และเริ่มควบคุมขอบเขตความเสียหาย (blast radius) แทน การจำกัดความเสียหายคือคำตอบ และมันมีระดับการป้องกันที่แบ่งเป็นขั้นๆ

Sandbox ในตัวของ Claude Code

ก่อนจะเข้าสู่ขั้นตอนต่างๆ โปรดทราบว่าปัจจุบัน Claude Code มาพร้อมกับ sandbox ระดับ OS สำหรับรันคำสั่ง ซึ่งช่วยลดความจำเป็นในการใช้ flag ข้ามการตรวจสอบ (skip flag) ลงไปได้มาก บน Linux ระบบจะใช้ bubblewrap เพื่อแยกส่วนระบบไฟล์ (filesystem isolation) และใช้ socat เพื่อกำหนดเส้นทาง traffic ของเครือข่ายผ่าน proxy ภายใน sandbox คำสั่งจะสามารถเขียนข้อมูลได้เฉพาะในไดเรกทอรีของโปรเจกต์และไดเรกทอรีชั่วคราวของเซสชันเท่านั้น และสามารถเข้าถึงเครือข่ายได้ผ่าน proxy ที่ตรวจสอบทุกโดเมนเทียบกับรายการที่อนุญาต (allow list) เท่านั้น ในครั้งแรกที่มีคำสั่งต้องการเข้าถึงโดเมนใหม่ Claude Code จะสอบถามคุณก่อน

เปิดใช้งานได้ด้วยคำสั่ง /sandbox ภายในเซสชัน สำหรับ Ubuntu และ Debian ให้ติดตั้งแพ็กเกจที่จำเป็นสองรายการนี้ก่อน:

sudo apt install bubblewrap socat

บน Ubuntu 24.04 ขึ้นไป นโยบาย AppArmor เริ่มต้นจะขัดขวางไม่ให้ bubblewrap สร้าง user namespace ที่จำเป็น แผงควบคุมของ sandbox จะแจ้งเตือนคุณเมื่อมีบางอย่างขาดหายไป และเอกสารประกอบเรื่องการทำ sandboxing ของ Claude Code จะมีโปรไฟล์ AppArmor แบบสั้นที่ช่วยแก้ไขปัญหานี้ให้

Sandbox มีโหมดอนุญาตอัตโนมัติ (auto-allow mode): คำสั่งที่อยู่ใน sandbox จะทำงานโดยไม่มีการแจ้งเตือนใดๆ เนื่องจากขอบเขตที่ถูกบังคับใช้ (enforced boundary) ทำหน้าที่แทนการแจ้งเตือนแบบเดิมแล้ว คำสั่งที่ไม่สามารถรันภายใน sandbox ได้จะกลับไปใช้กระบวนการขออนุญาตตามปกติ ดังนั้นการกระทำที่ผิดปกติจริงๆ ก็ยังคงมีการสอบถามอยู่ สำหรับ workflow บนเซิร์ฟเวอร์ส่วนใหญ่ นี่คือสิ่งที่มาแทนที่ skip flag ได้อย่างเหมาะสม เพราะคุณจะได้รับคำถามน้อยลงมากโดยมีขอบเขตที่บังคับใช้ในระดับ OS แทนที่จะไม่มีการตรวจสอบเลย

โปรดตระหนักถึงข้อจำกัดของมัน โดยค่าเริ่มต้นคำสั่งใน sandbox ยังคงสามารถอ่านระบบไฟล์ส่วนใหญ่ได้ รวมถึงไฟล์ข้อมูลรับรอง (credential files) เว้นแต่คุณจะปฏิเสธการเข้าถึง path เหล่านั้น ซึ่งการตั้งค่า sandbox.credentials มีไว้เพื่อการนี้โดยเฉพาะ Proxy ของเครือข่ายจะตรวจสอบชื่อโดเมนแต่ไม่ได้ตรวจสอบเนื้อหาของ traffic เอง ดังนั้นการอนุญาตแบบกว้างอย่าง github.com จึงยังเปิดช่องให้มีการย้ายข้อมูลออกได้ Docker ไม่สามารถทำงานภายใน sandbox นี้ได้ Sandbox ช่วยยกระดับความปลอดภัยขึ้นมาก แต่มันไม่ใช่ขอบเขตการแยกส่วนที่สมบูรณ์ ซึ่งเป็นเหตุผลว่าทำไมขั้นตอนต่างๆ ด้านล่างนี้จึงยังคงมีความสำคัญ

ลำดับขั้นของการจำกัดสิทธิ์

มี 3 ขั้น โดยเรียงตามระดับการแยกส่วนที่เพิ่มขึ้น ให้เลือกขั้นที่ต่ำที่สุดที่เหมาะสมกับบริการอื่น ๆ ที่ทำงานอยู่บนเครื่องนั้น

ขั้นที่ 1: การใช้ผู้ใช้ที่ไม่มีสิทธิ์ (unprivileged user) แยกเฉพาะ ตัว agent จะได้รับบัญชีผู้ใช้ของตัวเอง, ไดเรกทอรี home ของตัวเอง, ไดเรกทอรีโปรเจกต์ของตัวเอง และไม่มีสิทธิ์ sudo:

sudo adduser --disabled-password --gecos "" agent

ขอบเขตของบัญชีผู้ใช้จะป้องกันไม่ให้ agent เข้าถึงไฟล์ของคุณ ไม่ว่าจะเป็น SSH keys หรือโปรเจกต์อื่น ๆ ทั้งหมดบนเครื่อง นอกจากนี้ยังทำให้การใช้ flag skip เป็นไปได้จริง เนื่องจาก flag นี้จะปฏิเสธการทำงานหากรันด้วยสิทธิ์ root นี่เป็นหลักการเดียวกับ การรันทุกบริการด้วยผู้ใช้ที่ไม่มีสิทธิ์ ซึ่งนำมาประยุกต์ใช้กับ agent สิ่งที่ขั้นที่ 1 ไม่สามารถจำกัดได้คือ เครือข่าย และสิ่งที่สามารถอ่านได้โดยทุกคน (world-readable) บนเครื่อง

ขั้นที่ 2: การใช้คอนเทนเนอร์ (container) Anthropic ได้เผยแพร่ devcontainer อ้างอิงที่รัน Claude Code ในฐานะผู้ใช้ที่ไม่ใช่ root พร้อมด้วยกฎ firewall ที่จำกัดโฮสต์ที่ agent สามารถเข้าถึงได้ และคอนเทนเนอร์ที่คุณสร้างขึ้นเองก็สามารถทำหน้าที่เดียวกันนี้ได้ ระบบไฟล์จะถูกจำกัดเหลือเพียง volume ที่คุณ mount ไว้ และการเชื่อมต่อขาออกจะถูกจำกัดตามกฎของคอนเทนเนอร์ นี่เป็นขั้นกลางที่เหมาะสมเมื่อเซิร์ฟเวอร์ของคุณโฮสต์บริการอื่น ๆ ที่คุณให้ความสำคัญ ข้อจำกัดของมันคือคอนเทนเนอร์ใช้ kernel ร่วมกับโฮสต์ และการ mount ที่ไม่ระมัดระวังเพียงครั้งเดียวจะทำลายขอบเขตนี้ทันที หากคุณส่ง /var/run/docker.sock ให้กับคอนเทนเนอร์ มันจะสามารถเข้าถึงโฮสต์ทั้งหมดได้

ขั้นที่ 3: การใช้ VPS แยกเฉพาะ ขั้นที่แข็งแกร่งที่สุดคือวิธีที่ตรงไปตรงมาที่สุด นั่นคือการให้ agent ใช้เครื่องทั้งเครื่องที่ไม่มีข้อมูลสำคัญใด ๆ ของคุณอยู่เลย VPS ขนาดเล็กมีค่าใช้จ่ายเพียงไม่กี่ดอลลาร์ต่อเดือน ให้ตั้งค่าโดยใช้ คู่มือการตั้งค่า VPS ใหม่ใน 10 นาทีแรก จากนั้นทำ snapshot สถานะที่สะอาดไว้ แล้วปล่อยให้ agent ทำงาน โดยไม่มีสิ่งอื่นใดอยู่ในนั้น ไม่มี SSH key ส่วนตัว มีเพียง deploy key ที่จำกัดสิทธิ์ไว้เฉพาะ repository เดียวเท่านั้น ไม่มี cloud credentials และไม่มีข้อมูลการผลิต (production data) เมื่อการทำงานผิดพลาด หรือเมื่อคุณต้องการเริ่มต้นใหม่เพียงแค่ restore snapshot หรือทำลายและสร้างเครื่องใหม่ในเวลาไม่กี่นาที รัศมีของความเสียหายจะจำกัดอยู่แค่ค่าเช่าเครื่อง นี่คือการตั้งค่าที่ทำให้ --dangerously-skip-permissions ไม่น่ากลัวอีกต่อไป เพราะผลลัพธ์ที่เลวร้ายที่สุดที่เป็นไปได้คือการต้องสร้างเซิร์ฟเวอร์ใหม่และเพิกถอน token หนึ่งรายการ

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

การปกป้องข้อมูลรับรอง

กฎที่สำคัญที่สุดคือ: ผู้ใช้ของ agent ต้องไม่สามารถอ่านข้อมูลลับที่เป็นของบริการอื่นได้

ให้มอบ API key แก่ agent เท่านั้น ห้ามมอบให้ผู้อื่น นำไปเก็บไว้ในไฟล์ที่ผู้ใช้ของ agent เป็นเจ้าของ โดยกำหนดสิทธิ์เป็น 600 และโหลดข้อมูลดังกล่าวเมื่อ shell เริ่มทำงาน:

install -m 600 /dev/null /home/agent/claude.env
echo 'export ANTHROPIC_API_KEY=your-key-here' >> /home/agent/claude.env
echo 'source ~/claude.env' >> /home/agent/.bashrc

จากนั้นให้ปิดกั้นการเข้าถึงในทิศทางอื่น บน Debian และ Ubuntu ไดเรกทอรี home มักถูกสร้างขึ้นมาให้ผู้ใช้ทุกคนในเครื่องอ่านได้ ดังนั้นให้จำกัดสิทธิ์ของตนเองด้วย chmod 750 /home/youruser ตรวจสอบด้วย ls -ld /home/* และแก้ไขทุกสิ่งที่บัญชีของ agent สามารถแสดงรายการได้

จำกัดขอบเขตของ token ทุกตัว การใช้ GitHub token แบบละเอียดที่จำกัดไว้เพียง repository เดียว หรือการใช้ deploy key แยกตาม repository จะช่วยให้มั่นใจได้ว่าหากข้อมูลรับรองรั่วไหล จะส่งผลกระทบเพียงโครงการเดียว ไม่ใช่ทั้งบัญชีของคุณ หากคุณใช้ sandbox ให้เพิ่มการตั้งค่าข้อมูลรับรองเพื่อปฏิเสธการเข้าถึง ~/.ssh และ ~/.aws แม้กระทั่งการอ่าน และควรเก็บข้อมูลรับรองสำหรับ production ไว้นอกเครื่องทั้งหมด เพราะ agent ไม่สามารถทำข้อมูลลับรั่วไหลได้หากข้อมูลนั้นไม่ได้อยู่ในเครื่อง หากข้อมูลลับเหล่านั้นอยู่ในโปรแกรมจัดการรหัสผ่านที่คุณโฮสต์เอง ให้เก็บไว้ในเครื่องอื่นที่แยกจาก agent และตรวจสอบความปลอดภัยแยกต่างหาก เนื่องจาก จุดอ่อนของ Vaultwarden คือ admin token และไฟล์สำรองข้อมูล ไม่ใช่ตัว vault ที่เข้ารหัสไว้เอง

Git คือตาข่ายนิรภัย

ทุกการเปลี่ยนแปลงที่ agent ทำควรสามารถตรวจสอบและย้อนกลับได้ ซึ่ง git มอบทั้งสองอย่างนี้ให้คุณโดยอัตโนมัติหาก agent ทำงานบน branch:

git switch -c agent/refactor-auth

ตรวจสอบการทำงานที่เกิดขึ้นด้วย git diff main...agent/refactor-auth จากนั้น merge สิ่งที่ถูกต้อง และลบ branch ทิ้งหากการทำงานนั้นไม่นำไปสู่ผลลัพธ์ที่ต้องการ การทำงานที่แก้ไขไฟล์เพียง 3 ไฟล์นั้นอ่านทำความเข้าใจได้ง่ายกว่าการเขียนทับโมดูลครึ่งหนึ่งในตอนเช้า ซึ่งเป็นเหตุผลเชิงปฏิบัติสำหรับ ทักษะที่ควบคุมให้ agent ทำการเปลี่ยนแปลงที่เล็กที่สุดเท่าที่ใช้งานได้ ปกป้อง main branch ที่ฝั่ง forge เพื่อไม่ให้ token ของ agent สามารถ push เข้าไปได้ และไม่สามารถ force-push ได้ในทุกกรณี ประวัติการ commit จะทำหน้าที่เป็น audit log ของสิ่งที่เกิดขึ้นในขณะที่คุณหลับ ซึ่งมีค่ามากกว่าการเลื่อนดูประวัติใน terminal ใดๆ

เครือข่ายเป็นส่วนหนึ่งของขอบเขตความเสียหาย (blast radius)

เอเจนต์สามารถรัน curl ได้ ประโยคนั้นคือปัญหาทั้งหมดของการส่งข้อมูลออก (egress): สิ่งใดก็ตามที่เอเจนต์อ่านได้ มันก็สามารถส่งไปยังที่อื่นได้เช่นกัน และเอเจนต์ที่ถูก prompt injection อาจทำเช่นนั้นได้ ผู้ใช้ทั่วไปที่ไม่มีสิทธิ์พิเศษไม่ได้จำกัดเรื่องนี้เลย เพราะผู้ใช้ทุกคนสามารถเข้าถึงทุกสิ่งที่เซิร์ฟเวอร์เข้าถึงได้ แซนด์บ็อกซ์ (sandbox) จะจำกัดขอบเขตนี้ตามโดเมนผ่านพร็อกซีของมัน คอนเทนเนอร์สามารถจำกัดขอบเขตด้วยกฎไฟร์วอลล์ของตัวเอง ส่วน VPS เฉพาะทางจะจำกัดสิ่งที่อาจรั่วไหลได้ตั้งแต่ต้น ซึ่งเป็นวิธีแก้ปัญหาที่แข็งแกร่งที่สุดในทั้งสามวิธี

อย่าพยายามแก้ปัญหาการส่งข้อมูลออกด้วย ufw เพียงอย่างเดียว ufw อนุญาตให้ทราฟฟิกขาออกทั้งหมดโดยค่าเริ่มต้น และการเขียนกฎขาออกที่ยังคงอนุญาตให้ apt, npm, git และ Claude API ทำงานได้นั้นเป็นงานที่ยุ่งยากและมักจะล้มเหลวโดยไม่มีการแจ้งเตือน ให้เลือกจำกัดขอบเขตที่ระดับแซนด์บ็อกซ์ คอนเทนเนอร์ หรือระดับเครื่องแทน ซึ่งการใช้รายการอนุญาตโดเมน (domain allow list) หรือการใช้เครื่องเปล่าจะทำงานได้สะอาดกว่า

หากคุณกำลังสร้างเอเจนต์ของคุณเองโดยใช้ API แทนที่จะรัน Claude Code แนวคิดเดียวกันนี้ก็ยังคงใช้ได้โดยไม่มีการเปลี่ยนแปลง การสร้างเอเจนต์ AI ด้วย Claude บน VPS ครอบคลุมแนวทางนั้น และเอเจนต์ของคุณก็ควรได้รับสิทธิ์ผู้ใช้เฉพาะทาง โทเค็นที่จำกัดขอบเขต และแซนด์บ็อกซ์ที่ทิ้งได้เช่นเดียวกัน

เสริมความปลอดภัยให้กับเครื่องก่อน

ไม่ว่าคุณจะเลือกใช้ระดับใด เครื่องเซิร์ฟเวอร์จำเป็นต้องมีการตั้งค่าพื้นฐานก่อนที่เอเจนต์จะเริ่มทำงาน ได้แก่ การใช้เฉพาะ SSH keys เท่านั้น, การไม่อนุญาตให้ root ล็อกอิน, การตั้งค่า firewall เป็นแบบ default-deny และการเปิดใช้งานการอัปเดตความปลอดภัยอัตโนมัติ ให้สร้างรายการตรวจสอบของคุณที่นี่และดำเนินการตามลำดับจนครบ:

FAQ

การใช้ --dangerously-skip-permissions บนเซิร์ฟเวอร์ปลอดภัยหรือไม่?

ไม่ปลอดภัยหากใช้เพียงลำพัง แฟล็กนี้จะข้ามการแจ้งเตือนเพื่อขออนุมัติทั้งหมด ดังนั้นคำสั่งที่ไม่เหมาะสมคำสั่งแรกจะถูกรันทันทีที่โมเดลสร้างขึ้น การใช้งานนี้จะยอมรับได้ก็ต่อเมื่อจำกัดขอบเขตความเสียหายไว้แล้วเท่านั้น เช่น การใช้บัญชีผู้ใช้ที่ไม่มีสิทธิ์พิเศษ (unprivileged user) เป็นอย่างน้อย หรือหากเป็นการทำงานแบบอัตโนมัติโดยไม่มีผู้ดูแล ควรใช้ภายในคอนเทนเนอร์หรือ VPS แบบใช้แล้วทิ้งที่เก็บเฉพาะโปรเจกต์เดียวและใช้โทเค็นที่มีขอบเขตจำกัด ห้ามใช้แฟล็กนี้บนเครื่องที่เก็บข้อมูลรับรอง (credentials) ของระบบงานจริง (production) หรือข้อมูลสำคัญที่ไม่สามารถสูญเสียได้

Claude Code มี sandbox หรือไม่?

มี Claude Code มาพร้อมกับ sandbox ในตัวสำหรับรันคำสั่งเชลล์ ซึ่งเปิดใช้งานด้วยคำสั่ง /sandbox โดยใช้ bubblewrap บน Linux และ Seatbelt บน macOS ซึ่งจะจำกัดการเขียนไฟล์ไว้เฉพาะภายในไดเรกทอรีของโปรเจกต์ และกำหนดให้การเข้าถึงเครือข่ายต้องผ่านพร็อกซีที่อนุญาตเฉพาะโดเมนที่กำหนดไว้เท่านั้น โหมด auto-allow จะรันคำสั่งใน sandbox โดยไม่ต้องรอการยืนยัน จึงช่วยลดการขัดจังหวะได้เช่นเดียวกับการใช้แฟล็กข้ามการยืนยัน โดยยังคงรักษาขอบเขตความปลอดภัยระดับระบบปฏิบัติการไว้ อย่างไรก็ตาม นี่ไม่ใช่การแยกส่วนแบบสมบูรณ์ ดังนั้นควรใช้งานร่วมกับบัญชีผู้ใช้เฉพาะหรือเครื่องเฉพาะสำหรับการรันงานแบบอัตโนมัติ

ทำไมแฟล็กข้ามการยืนยันถึงปฏิเสธการรันในฐานะ root?

เนื่องจาก root ที่ไม่มีการแจ้งเตือนขออนุญาตสามารถแก้ไขไฟล์และบริการใดๆ ในระบบได้ Claude Code จึงบล็อกการใช้ --dangerously-skip-permissions เมื่อรันในฐานะ root หรือภายใต้ sudo บน Linux และ macOS วิธีแก้ไขไม่ใช่การพยายามเลี่ยงการตรวจสอบนี้ แต่ให้สร้างบัญชีผู้ใช้ที่ไม่มีสิทธิ์พิเศษสำหรับเอเจนต์และรันงานที่นั่น เพราะการแบ่งแยกบัญชีผู้ใช้คือชั้นการป้องกันด่านแรกที่ประหยัดและมีประสิทธิภาพที่สุด

Claude Code สามารถอ่าน SSH keys และไฟล์ .env ของฉันได้หรือไม่?

เอเจนต์สามารถอ่านทุกอย่างที่บัญชีผู้ใช้ที่รันมันสามารถอ่านได้ และแม้แต่นโยบายเริ่มต้นของ sandbox ก็อนุญาตให้อ่านเส้นทางที่เก็บข้อมูลรับรองได้จนกว่าคุณจะปฏิเสธการเข้าถึง ดังนั้นควรให้เอเจนต์รันภายใต้บัญชีผู้ใช้ของมันเอง ตั้งค่าโหมดไดเรกทอรี home ของคุณเป็น 750 หรือเข้มงวดกว่านั้น ปฏิเสธการเข้าถึงเส้นทางข้อมูลรับรองในการตั้งค่า sandbox และเก็บความลับของระบบงานจริงไว้นอกเครื่องนี้โดยสิ้นเชิง ความลับที่เครื่องไม่เคยได้รับย่อมไม่สามารถถูกอ่านหรือรั่วไหลได้

วิธีที่ปลอดภัยที่สุดในการรัน Claude Code แบบอัตโนมัติคืออะไร?

การใช้ VPS ราคาประหยัดที่แยกออกมาสำหรับงานเอเจนต์โดยเฉพาะ: ทำการ hardened ภายในสิบนาที, ทำ snapshot สถานะที่สะอาดไว้, รัน Claude Code ภายใต้บัญชีผู้ใช้ที่ไม่มีสิทธิ์พิเศษโดยเปิดใช้งาน sandbox, เก็บ API key ไว้ในไฟล์โหมด 600, ใช้ deploy key แยกตาม repository และทำงานทั้งหมดบน branch ที่คุณตรวจสอบก่อนทำการ merge หากการรันงานเกิดข้อผิดพลาด คุณเพียงแค่เพิกถอนโทเค็นนั้นและกู้คืน snapshot โดยที่ทรัพย์สินอื่นของคุณจะไม่ได้รับผลกระทบใดๆ