ฉันควรสร้างบัญชีผู้ใช้ใหม่เพื่อใช้งานซอฟต์แวร์บนเซิร์ฟเวอร์เมื่อใด

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

ตัวอย่างเช่นสมมติว่าฉันใช้เซิร์ฟเวอร์ Debian ที่ใช้ร่วมกัน (เช่นผ่าน Dreamhost) และฉันต้องการเรียกใช้บางเว็บไซต์โดยใช้ WordPress, บางคนใช้ Redmine, บางคนใช้ Ruby on Rails, บางทีใช้ Django และฉันต้องการ Mercurial ที่เก็บเช่นกัน

บนเซิร์ฟเวอร์ Dreamhost และเซิร์ฟเวอร์อื่น ๆ ที่มีการตั้งค่าคล้ายกันทั้งหมดนี้สามารถทำได้ภายใต้บัญชีผู้ใช้เดียวแต่ฉันสามารถดูข้อเสียของวิธีการดังกล่าว:

• .bashrc ที่ยาวกว่า
• หากบัญชีนั้นกลายเป็นอันตรายไซต์ทั้งหมดจะทำงานภายใต้

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

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

กรุณาโพสต์ความคิดเห็นของคุณเกี่ยวกับเรื่องนี้โดยบอกเหตุผลของคุณ

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

ฉันเป็นแฟนของ "ผู้ใช้หนึ่งคนสำหรับทุกสิ่งที่เปิดซ็อกเก็ตการฟังบนเครือข่าย" - หนึ่งสำหรับ Apache หนึ่งสำหรับ Mail หนึ่งสำหรับ DNS และอื่น ๆ

นี่คือ (ล่าสุดที่ฉันได้ยิน) ยังคงปฏิบัติที่ดีที่สุดในปัจจุบันและเหตุผลที่อยู่เบื้องหลังนี้คือความหวาดระแวงธรรมดาและเรียบง่าย: บริการเหล่านี้มีการเปิดเผยอินเทอร์เน็ต Big Bad Internet ถ้ามีคนพบช่องโหว่และใช้ประโยชน์จากมันก่อนที่ฉันจะมีโอกาสแก้ไข อย่างน้อยฉันก็ จำกัด ไว้ในบัญชีผู้ใช้เดียวโดยมีเพียงสิทธิ์ที่จำเป็นสำหรับการเรียกใช้บริการเดียวที่รับผิดชอบ
โดยทั่วไปฉันคิดว่าการแยกระดับนี้จะเพียงพอในการปกป้องระบบแม้ว่าแต่ละแอปพลิเคชันจะเป็นช่องโหว่ (ตัวอย่างเช่นถ้ามีคนติดตั้งปลั๊กอิน WordPress ที่มีช่องโหว่ทุกสิ่งที่ Apache เข้าถึงได้ (เช่นเว็บไซต์ทั้งหมด) ในกรณีที่มีการประนีประนอม

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

การขยายข้อโต้แย้งเพิ่มเติมสำหรับการใส่ Apache แต่ละตัวใน chroot (หรือคุกหากคุณใช้ระบบ BSD) สามารถสร้างความปลอดภัยได้มากขึ้น แต่ตอนนี้คุณกำลังพูดถึงพื้นที่ดิสก์เพิ่มเติมเนื่องจากแต่ละ chroot / jail จะต้องใช้ซอฟต์แวร์ทั้งหมดที่จำเป็นในการ เรียกใช้ไซต์ที่มีอยู่ (และจำเป็นต้องอัปเดตซอฟต์แวร์นี้สำหรับทุกไซต์แทนที่จะเป็นเพียงหนึ่งสำเนาต้นแบบบนเซิร์ฟเวอร์เมื่อแพตช์ออกมา) รวมถึงข้อกำหนด RAM เช่นเดียวกับเมื่อคุณมีผู้ใช้ / อินสแตนซ์แยกต่างหาก
สิ่งนี้จะบรรเทาทุกอย่างยกเว้นข้อผิดพลาด OS / เคอร์เนลที่ช่วยให้ผู้ใช้แยกออกจาก chroot (ซึ่งกลายเป็นอาร์กิวเมนต์สำหรับการเรียกใช้ทุกไซต์บนเซิร์ฟเวอร์ทางกายภาพแยก - ซึ่งกลายเป็นอาร์กิวเมนต์สำหรับการแยกไซต์ออกเป็น vlans / subnets อื่น ๆ )

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

โดยทั่วไปสิ่งที่ฉันทำคือมีผู้ใช้หนึ่งรายสำหรับบริการภายนอกที่ไม่ได้รับอนุญาตให้ลงชื่อเข้าใช้ (ตัวอย่างเช่น "ไม่มีใคร") และหนึ่งบัญชีที่ได้รับอนุญาตเข้าสู่ระบบและ su หรือ sudo ตรวจสอบให้แน่ใจว่าชื่อผู้ใช้ของคุณแตกต่างและไม่สามารถคาดเดาได้ง่าย

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