ภัยมืดของ Environment Variables: ผู้เชี่ยวชาญด้านความปลอดภัยส่งสัญญาณเตือน

Environment variables ได้เป็นส่วนพื้นฐานของระบบแบบ Unix มาหลายทศวรรษแล้ว โดยทำหน้าที่เป็นวิธีง่ายๆ ในการส่งผ่านข้อมูลการกำหนดค่าการตั้งค่าระหว่างกระบวนการต่างๆ แม้จะยังคงถูกใช้งานอย่างแพร่หลายในการพัฒนาซอฟต์แวร์สมัยใหม่ โดยเฉพาะอย่างยิ่งสำหรับแอปพลิเคชันในรูปแบบ container แต่การอภิปรายในชุมชนล่าสุดได้เน้นยึงถึงข้อกังวลด้านความปลอดภัยที่สำคัญซึ่งนักพัฒนาหลายคนอาจมองข้ามไป

ปัญหาด้านความปลอดภัยที่คุณอาจไม่รู้

หนึ่งในการเปิดเผยที่น่ากังวลที่สุดจากการอภิปรายในชุมชนคือ ความง่ายดายที่ environment variables สามารถถูกเปิดเผยให้กับกระบวนการที่ไม่มีสิทธิ์เข้าถึงได้ บนระบบ Linux กระบวนการใดๆ ที่ทำงานภายใต้บัญชีผู้ใช้เดียวกันมีศักยภาพที่จะอ่าน environment variables ของกระบวนการอื่นที่เป็นเจ้าของโดยผู้ใช้คนนั้นได้ ซึ่งหมายความว่าหากคุณกำลังเรียกใช้แอปพลิเคชันหลายตัวเป็นผู้ใช้เดียวกัน - สถานการณ์ทั่วไปบนเครื่องคอมพิวเตอร์ของนักพัฒนา - ความลับที่ส่งผ่าน environment variables อาจมองเห็นได้สำหรับแอปพลิเคชันทั้งหมดเหล่านั้น

เอเจนต์ Claude ที่ทำงานในเซสชัน CLI อื่น ตอนนี้ก็สามารถเข้าถึงโทเค็น GitHub ของฉันได้ หรือ เอ็กซ์เทนชันใดๆ ที่ฉันเคยโหลดใน VS Code ก็สามารถเข้าถึงได้เช่นกัน มันดีกว่าการเก็บไว้ในไฟล์ข้อความล้วนๆ ในระบบไฟล์ แต่ก็ดีกว่าไม่มากนัก

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

ข้อกังวลด้านความปลอดภัยของตัวแปรสภาพแวดล้อม:

• การเปิดเผยของโปรเซส: โปรเซสอื่นๆ ภายใต้ผู้ใช้คนเดียวกันสามารถอ่าน /proc/[pid]/environ ได้
• การเปิดเผยของ Systemd: ตัวแปรสภาพแวดล้อมถูกเปิดเผยผ่าน DBUS ไปยังไคลเอนต์ทั้งหมดในระบบ
• ข้อจำกัดของคอนเทนเนอร์: ตัวแปรสภาพแวดล้อมในคอนเทนเนอร์สามารถมองเห็นได้โดยโปรเซสของระบบโฮสต์
• ความเสี่ยงในการพัฒนา: AI agents และ extensions อาจเข้าถึงตัวแปรสภาพแวดล้อมที่มีความละเอียดอ่อนได้

ความประหลาดใจจาก Systemd

การค้นพบที่น่าตกใจอีกประการหนึ่งที่ถูกอภิปรายในชุมชนเกี่ยวข้องกับ systemd ซึ่งเป็นระบบ init ที่ใช้โดยการแจกจ่าย Linux หลายรุ่น ตามเอกสารประกอบและรายงานจากผู้ใช้ systemd ได้เปิดเผย environment variables ของยูนิตให้กับไคลเอนต์ระบบทั้งหมดผ่าน DBUS ซึ่งอาจหมายความว่าผู้ใช้ที่ไม่ใช่ root สามารถเข้าถึง environment variables ที่ตั้งค่าสำหรับบริการเฉพาะผู้ใช้ root เท่านั้นได้ - นี่เป็นเรื่องน่าประหลาดใจอย่างมากสำหรับผู้ดูแลระบบที่คิดว่าค่าเหล่านี้ได้รับการปกป้องแล้ว

ผลกระทบมีความสำคัญ: รหัสผ่านฐานข้อมูล คีย์ API และการกำหนดค่าความลับอื่นๆ ที่ส่งผ่าน environment variables ไปยังบริการ systemd อาจถูกเปิดเผยมากกว่าที่ผู้ดูแลระบบตระหนัก สิ่งนี้นำไปสู่คำเตือนไม่ให้ใช้ environment variables สำหรับข้อมูลลับในการกำหนดค่ายูนิตของ systemd

แนวทางทางเลือกและการแลกเปลี่ยน

ชุมชนได้สำรวจทางเลือกต่างๆ สำหรับ environment variables ในการจัดการความลับ โดยแต่ละวิธีมีข้อได้เปรียบและข้อจำกัดของตัวเอง Kubernetes Secrets API ให้แนวทางหนึ่ง แต่ผู้เชี่ยวชาญบางคนเตือนเกี่ยวกับการถูกผูกมัดกับผู้ขายและความซับซ้อนในสภาพแวดล้อมการพัฒนา Hashicorp Vault และระบบการจัดการความลับที่คล้ายกันให้โซลูชันที่แข็งแกร่ง แต่แนะนำการพึ่งพาบริการภายนอก

นักพัฒนาบางส่วนสนับสนุนแนวทางแบบใช้ไฟล์ โดยที่แอปพลิเคชันอ่านความลับจากไฟล์ที่ได้รับการป้องกันเมื่อเริ่มต้นทำงาน อย่างไรก็ตาม สิ่งนี้นำมาซึ่งความท้าทายของตัวเองเกี่ยวกับสิทธิ์การเข้าถึงไฟล์และความซับซ้อนในการปรับใช้ โซลูชันขั้นสูงมากขึ้นเช่น system call memfd_secret ของ Linux ให้ความหวังโดยการสร้างพื้นที่หน่วยความจำที่กระบวนการอื่นไม่สามารถเข้าถึงได้ แม้ว่าการสนับสนุนในภาษาต่างๆ ยังคงมีจำกัด

แนวทางการจัดการข้อมูลลับทางเลือก:

• แบบไฟล์: อ่านจากไฟล์ที่มีการป้องกันด้วยสิทธิ์การเข้าถึงที่เข้มงวด
• Kubernetes Secrets: ติดตั้งในรูปแบบ volumes หรือ environment variables
• Secret Managers: Hashicorp Vault, AWS Secrets Manager
• Systemd-creds: ระบบข้อมูลรับรองที่เข้ารหัสโดยใช้ TPM
• memfd_secret: Linux system call สำหรับสร้างพื้นที่หน่วยความจำที่ไม่สามารถเข้าถึงได้

ปัญหาของนักพัฒนา

สำหรับงานพัฒนาประจำวัน สถานการณ์สร้างสมดุลที่ยาก Environment variables นั้นสะดวก รองรับได้ดี across ภาษาการเขียนโปรแกรมและแพลตฟอร์มการปรับใช้ และรวมเข้ากับระบบ container orchestration ได้อย่างราบรื่น กระนั้นข้อกังวลด้านความปลอดภัยก็เป็นเรื่องจริง โดยเฉพาะสำหรับนักพัฒนาที่ทำงานบนเครื่องส่วนตัวซึ่งแอปพลิเคชันหลายตัวทำงานภายใต้บัญชีผู้ใช้เดียวกัน

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

ข้อจำกัดของตัวแปรสภาพแวดล้อม:

• ไม่มี namespacing: เป็นพจนานุกรมแบบ global ที่เก็บค่าเป็นสตริงเท่านั้น
• ข้อจำกัดของประเภทข้อมูล: รองรับเฉพาะค่าที่เป็นสตริงเท่านั้น
• ข้อจำกัดของขนาด: 128 KiB ต่อตัวแปร, 2 MiB ทั้งหมด (ใช้ร่วมกับ command line arguments)
• การสืบทอด: ถูกส่งต่อไปยัง child processes โดยอัตโนมัติ เว้นแต่จะถูกป้องกันไว้อย่างชัดเจน
• ความซับซ้อนในการ debug: การตั้งค่าหลายชั้นทำให้การติดตามแหล่งที่มาทำได้ยาก

มองไปข้างหน้า

การอภิปรายเผยให้เห็นถึงการยอมรับที่เพิ่มขึ้นว่าแนวทางดั้งเดิมของเราต่อการกำหนดค่าแอปพลิเคชันจำเป็นต้องได้รับการคิดใหม่ แม้ว่า environment variables จะไม่หายไปในเร็วๆ นี้ แต่ผู้พัฒนาก็ตระหนักถึงข้อจำกัดและผลกระทบด้านความปลอดภัยมากขึ้นเรื่อยๆ ดูเหมือนว่าชุมชนกำลังเคลื่อนไปสู่วิธีการที่ชัดเจนและปลอดภัยมากขึ้นในการจัดการการกำหนดค่าและความลับ แม้ว่าจะหมายถึงการเสียสละความสะดวกสบายบางส่วนที่ทำให้ environment variables เป็นที่นิยมก็ตาม

ในขณะที่การพัฒนาซอฟต์แวร์ยังคงวิวัฒนาการต่อไป ด้วยแอปพลิเคชันมากขึ้นที่ทำงานในสภาพแวดล้อมที่แบ่งปันกันและความสนใจที่เพิ่มขึ้นต่อแนวทางปฏิบัติด้านความปลอดภัยที่ดีที่สุด environment variable ที่เรียบง่ายอาจจำเป็นต้องสละพื้นที่ให้กับทางเลือกที่แข็งแกร่งและปลอดภัยมากขึ้นสำหรับข้อมูลการกำหนดค่าที่มีความละเอียดอ่อน

อ้างอิง: Environment variables are a legacy mess: Let's dive deep into them