นักพัฒนาควรมีสิทธิ์ผู้ดูแลระบบบนพีซีของพวกเขา

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

ความคิดเห็นบางส่วน:

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

เราเป็นทีมนักพัฒนา 5 คนและสร้างเว็บแอปพลิเคชั่น

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

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

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

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

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

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

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

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

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

ที่กล่าวว่าพวกเขาควรจะเป็นผู้ดูแลระบบในกล่อง THEIR ไม่ใช่เครือข่าย

ใช่และไม่.

ใช่มันช่วยประหยัดเวลาได้มากที่จะรบกวนการสนับสนุนระบบ

ไม่ผู้ใช้ของคุณไม่มีดังนั้นอย่าเชื่อใจมัน

เราพัฒนาด้วยสิทธิ์ผู้ดูแลระบบและทดสอบโดยไม่ต้อง ซึ่งใช้งานได้ดี

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

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

พวกเขาควรมีบัญชีพร้อมใช้งานของการอนุญาตเดียวกันกับผู้ใช้ของพวกเขา (มากกว่าหนึ่งบัญชีถ้ากลุ่มของผู้ใช้มีสถานะการอนุญาตที่แตกต่างกัน) ไม่เช่นนั้นพวกเขาอาจพัฒนาบางอย่างที่ยอดเยี่ยมปรับใช้แล้วพบว่ามันใช้ไม่ได้กับผู้ใช้

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

นี่เป็นคำตอบที่เฉพาะเจาะจงสำหรับ Windows ใน Linux และระบบ Unix-y อื่น ๆ นักพัฒนาสามารถเข้าใช้บัญชีผู้ใช้ได้บ่อยขึ้นเท่านั้นไม่จำเป็นต้องมีบัญชีอื่นเพื่อทำการทดสอบ sudo, แต่พวกเขาอาจจำเป็นต้องมีสิทธิ์กลุ่มเดียวกัน), และสามารถทำความเสียหายให้กับระบบปฏิบัติการได้อย่างง่ายดายมาก, ดังนั้นจึงจำเป็นต้องมีนโยบายไอทีเดียวกัน

ใช่ Half-Life 1 (และ mod ที่เกี่ยวข้องทั้งหมด: counter-strike, วันแห่งความพ่ายแพ้, ฯลฯ ) ต้องการสิทธิ์ผู้ดูแลระบบ (อย่างน้อยสำหรับการทำงานครั้งที่ 1, ฉันคิดว่า) ทำงานอย่างถูกต้องใน Windows NT, 2000, XP, ฯลฯ .

และนักพัฒนาซอฟต์แวร์ประเภทใดที่ไม่เล่น Counter Strike ในเวลากลางวัน (หนึ่งเส็งเคร็งแน่นอน)

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

แน่นอน! ฉันจะติดตั้งตัวจัดการดาวน์โหลดเพื่อดาวน์โหลดภาพยนตร์ในเวลากลางคืนได้อย่างไร

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

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

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

คำตอบคือนักพัฒนาควรมี 2 เครื่อง !!

• หนึ่งการพัฒนาที่มีสิทธิ์ผู้ดูแลระบบและพลังงานเพียงพอ, หน่วยความจำ, ขนาดหน้าจอและความสามารถในการพกพาและสิทธิ์ ADMIN โดยโหลดซอฟต์แวร์ป้องกันไวรัสขององค์กร แต่สามารถกำหนดค่าได้โดยผู้พัฒนาเมื่อจำเป็นต้องใช้นโยบาย autoreset ..

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

หากคุณกลับคำถามฉันคิดว่าจะตอบได้ง่ายกว่า เราควรลบสิทธิ์ผู้ดูแลระบบออกจากนักพัฒนาหรือไม่ กำไรคืออะไร

แต่จริงๆแล้วฉันคิดว่าคำตอบนั้นขึ้นอยู่กับบริบทของคุณสภาพแวดล้อมของคุณ การเริ่มต้นเล็ก ๆ จะมีคำตอบแตกต่างจากหน่วยงานของรัฐที่ได้รับการรับรองมาตรฐาน ISO

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

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

"มันใช้ได้กับเครื่องของฉัน" ไม่ใช่ข้อแก้ตัว!

ในฐานะผู้ดูแลระบบฉันทุกคนสำหรับนักพัฒนาที่มีสิทธิ์เป็นผู้ดูแลระบบในเวิร์กสเตชันของพวกเขา เมื่อเป็นไปได้คุณไม่ควรทำทุกอย่างด้วยบัญชีระดับ 'ผู้ใช้' มาตรฐานจากนั้นใช้บัญชี 'ผู้ดูแลระบบ' คนอื่นเพื่อทำการเปลี่ยนแปลงติดตั้งแอป ฯลฯ บ่อยครั้งที่คุณสามารถ sudo หรือ runas เพื่อทำสิ่งที่คุณต้องการโดยไม่ต้องบันทึก ออก. นอกจากนี้ยังเป็นประโยชน์ในการเตือนเราถึงสิ่งที่การรักษาความปลอดภัยทำร้ายผู้ใช้ปลายทางจะต้องข้ามไปเมื่อปล่อยไปยังการผลิต

ในหมายเหตุด้านข้างขอแนะนำให้ใช้ระบบ [clean] หรือ VM (s) เพื่อให้คุณสามารถทดสอบสิ่งต่าง ๆ ได้อย่างถูกต้องและไม่เข้ากับสถานการณ์ "ดู / ทำงานได้ดีในระบบของฉัน" เนื่องจากการปรับเปลี่ยนระบบ

ไม่มีผู้ใช้พลังงาน

ประการแรกผู้ใช้ Power นั้นเป็นผู้ดูแลระบบ - ดังนั้น " การ จำกัด " ผู้ใช้กับ Power User ไม่ได้เพิ่มความปลอดภัยให้กับระบบ - คุณอาจเป็นผู้ดูแลระบบเช่นกัน

เข้าสู่ระบบแบบโต้ตอบในฐานะผู้ใช้ปกติ

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

คุณไม่ต้องการเรียกใช้ [ใส่เบราว์เซอร์, ปลั๊กอิน, IM, ไคลเอนต์อีเมลและอื่น ๆ ] ในฐานะผู้ดูแลระบบ

ตามปกติคุณจะไม่เข้าสู่ระบบในกล่อง Linux ในฐานะรูทแม้ว่าคุณจะมีสิทธิ์เข้าถึงรูทเมื่อคุณต้องการ

ใช้บัญชีผู้ดูแลระบบส่วนบุคคลแยกต่างหาก

มอบบัญชีผู้ดูแลระบบส่วนบุคคลแยกต่างหากให้กับนักพัฒนาของเขา / เธอ (บัญชีโดเมนเด่นกว่า) ที่เป็นผู้ดูแลระบบที่ถูกต้องบนเซิร์ฟเวอร์ dev / ทดสอบและกล่องอื่น ๆ ที่บุคคลนั้นต้องการการเข้าถึงระดับผู้ดูแลระบบ

ใช้ "ทำงานเป็น" และใน Vista + UAC เพื่อแจ้งหรือขอพรอมต์และป้อนข้อมูลประจำตัวของผู้ดูแลระบบสำหรับงานและกระบวนการเมื่อจำเป็นเท่านั้น PKI ที่มีสมาร์ทการ์ดหรือสิ่งที่คล้ายกันสามารถลดความเครียดในการป้อนข้อมูลประจำตัวได้บ่อยครั้งมาก

ทุกคนมีความสุข (หรือ?;)

จากนั้นตรวจสอบการเข้าถึง วิธีนี้มีการตรวจสอบย้อนกลับและวิธีง่ายๆในการค้นหาว่าใครกำลังใช้เซสชันบริการเทอร์มินัลในเซิร์ฟเวอร์ dev / test เฉพาะที่คุณต้องเข้าถึงตอนนี้ ...

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

ฉันทำงานเป็นหลักใน * nix world และรุ่นมาตรฐานที่มีให้นักพัฒนาสามารถทำงานในบัญชีผู้ใช้ปกติที่ไม่มีสิทธิพิเศษพร้อมด้วยความสามารถ (ผ่านsudoหรือsu) เพื่อเลื่อนระดับสิทธิ์ผู้ดูแลระบบเป็น / เมื่อจำเป็น

ฉันไม่แน่ใจว่าการจัดเรียง Windows ที่เทียบเท่าจะเป็นเช่นไร แต่จากประสบการณ์ของฉันการตั้งค่าในอุดมคติ:

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

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

[ขอโทษภาษาอังกฤษไม่ใช่ภาษาแม่ของฉันทำดีที่สุดแล้ว :)] เอ่อ

ประสบการณ์ส่วนตัว (ฉันเป็น c ++ / SQL dev):

ฉันเคยเป็นผู้ดูแลระบบของเครื่อง windows ของฉันในงานก่อนหน้าของฉัน ฉันยังมีสิทธิ์ dbo (ไม่ใช่ dba) ในฐานข้อมูลรวมถึงฐานข้อมูลสภาพแวดล้อมการผลิต ใน 2 และครึ่งปีกับ 8 คนที่มีสิทธิ์สูงบ้าเหล่านี้ ... เราไม่เคยมีปัญหาใด ๆ ที่จริงแล้วเราแก้ไขปัญหาจำนวนมากด้วยการอัพเดท db ด้วยตนเอง เราสามารถทำหลายสิ่งได้อย่างรวดเร็วสำหรับการแก้ไขที่รวดเร็วและ devs

ตอนนี้ฉันเปลี่ยนงาน ฉันจัดการ (ร้องไห้เป็นจำนวนมาก) เพื่อเป็นผู้ดูแลเครื่อง windows ของฉัน แต่เซิร์ฟเวอร์ dev เป็นเซิร์ฟเวอร์ red hat ที่เราเชื่อมต่อโดยใช้ ssh การพยายามติดตั้ง Qt นั้นเป็นการทรมาน จำกัด โควต้าพื้นที่ จำกัด การดำเนินการและสิทธิ์ในการเขียน ในที่สุดเราก็ยอมแพ้และขอให้ผู้ดูแลระบบทำเพื่อเรา 2 สัปดาห์ต่อมาก็ยังคงไม่มีอะไรติดตั้ง ฉันอ่านหนังสือได้เร็วมากและกด ALT + tab

ฉันขอสิทธิ์ของผู้ดูแลระบบเนื่องจากมีเพียงซอฟท์แวร์ของฉันที่ใช้ซอฟท์แวร์นี้

-> คำตอบ: "หากมีกระบวนการสำหรับคุณที่จะไม่ทำสิ่งที่คุณต้องการมันต้องทำงานได้ดีครั้งเดียวในแยง"

-> พยายามอธิบายให้ผู้จัดการที่ไม่ใช่ช่างเทคนิค: "ฉันจะไม่มีสิทธิ์ของผู้ดูแลระบบในการผลิตหรือสภาพแวดล้อม UAT แต่เครื่อง dev ของฉันแตกต่างกันถ้าฉันจะสร้างเก้าอี้แทนโปรแกรมคุณจะบอกฉันว่าฉันสามารถ ไม่ต้องใช้เครื่องมือใด ๆ ที่ฉันต้องการในเวิร์คช็อปเพราะเวิร์คช็อปของฉันต้องดูว่าจะใช้เก้าอี้ตัวไหนฉันจะมอบแพ็คเกจปฏิบัติการให้ uat libs และเครื่องมือที่ฉันใช้ในการสร้างมันจะมองไม่เห็นต่อผู้ใช้หรือ เพื่อนกำลังติดตั้งแพ็คเกจ "

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

คุณสามารถตอบคำถามนี้ได้สองวิธี ใช่และไม่ใช่หรือขึ้นอยู่กับ - ฉันจะคลุมเครือมากกว่านี้ไหม ....

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

ใช่และไม่ขึ้นอยู่กับมุมมองของคุณ วิศวกรบางคนมองว่าคอมพิวเตอร์เป็นโดเมนและเป็นกฎของโดเมน คนอื่นไม่ต้องการความรับผิดชอบ

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

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

ht tp: //msdn.microsoft.com/en-us/library/aa302367.aspx

จากประสบการณ์ของฉันการประนีประนอมระหว่างเรา (ผู้เขียน) และพวกเขา (ความปลอดภัย) เป็นสิ่งจำเป็นเสมอ ฉันยอมรับ (แม้ว่าฉันจะเกลียด) มีบุญในบทความ Microsoft ด้านบน เนื่องจากฉันเป็นโปรแกรมเมอร์มานานหลายปีฉันมีประสบการณ์กับความเจ็บปวดที่ฉันต้องการเพียงแค่ติดตั้งดีบักเกอร์แบบอื่นเพื่อที่จะได้รับความรำคาญฉันไม่สามารถทำได้ มันบังคับให้ฉันต้องคิดอย่างสร้างสรรค์ในการทำงานให้สำเร็จ หลังจากต่อสู้กับทีมรักษาความปลอดภัยของเราเป็นเวลาหลายปี (และการสนทนาหลายครั้ง) ฉันเข้าใจว่าพวกเขาต้องรักษาความปลอดภัยทุกด้านรวมถึงเดสก์ท็อปของฉัน พวกเขาแสดงให้ฉันเห็นช่องโหว่รายวันที่ออกมาแม้ในแอพ Quicktime ที่ง่ายที่สุด ฉันสามารถเห็น frutration ของพวกเขาทุกครั้งที่ฉันต้องการติดตั้งโปรแกรมอรรถประโยชน์อย่างรวดเร็วหรือปรับแต่ง IIS ท้องถิ่นของฉันที่ฉันสามารถทำให้เกิดปัญหาด้านความปลอดภัยที่ร้ายแรง ฉันไม่เข้าใจอย่างเต็มที่จนกระทั่งเห็นนักพัฒนาคนอื่นได้รับอาหารกระป๋อง เขาพยายามที่จะดีบั๊กและจบลงด้วยการปิดไซแมนเทคเพื่อให้ได้ไวรัส (แล้วให้) แก่คนหลายร้อยคน มันเป็นระเบียบ ในการพูดคุยกับหนึ่งใน "secheads" (ผู้รักษาความปลอดภัย) เกี่ยวกับสิ่งที่เกิดขึ้นฉันเห็นว่าเขาต้องการพูดว่า "บอกคุณแล้ว ... "

ฉันได้เรียนรู้ว่า secheads ของเรา (ดีอย่างน้อยฉัน) เพียงต้องการปกป้อง บริษัท ของเรา ข่าวดีก็คือเราพบว่ามีการประนีประนอมและฉันสามารถทำงานให้สำเร็จและ secheads นั้นยอดเยี่ยมกับเครือข่ายที่ปลอดภัยของเรา!

ลัทธิ

ใช่ถ้าคุณต้องการเพนเทอร์หรือผู้ใช้ที่เป็นอันตรายที่มีทักษะเพื่อตั้งหลักในการประนีประนอมโดเมนของคุณ

เช่นการประนีประนอมบัญชีระดับต่ำ> ค้นหาที่ผู้ดูแลระบบ -> Mimikatz -> ยกระดับสิทธิ์ -> ผู้ดูแลโดเมน

ดังนั้นไม่ผู้ใช้ปกติไม่ควรเป็นผู้ดูแลระบบ

Microsoft ยังกล่าวอีกว่า UAC ไม่ใช่ขอบเขตความปลอดภัยดังนั้นอย่าใช้เช่นนี้ มีการข้ามผ่าน UAC ในโลกแห่งความเป็นจริงมากมาย

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

สภาพแวดล้อมใด ๆ ที่บัญชีผู้ใช้ปกติเป็นผู้ดูแลเป็นสูตรสำหรับภัยพิบัติด้านความปลอดภัย

ว้าวคำถามนี้จะเปิดขึ้นอย่างแน่นอนกับคำตอบที่น่าสนใจ ในการตอบกลับฉันอ้างผู้ทรงใช้ - 'มันขึ้นอยู่กับ' :)

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

โดยส่วนตัวฉันเป็นแฟนของ "บัญชีผู้ดูแลระบบ" ซึ่งสามารถใช้เมื่อจำเป็น - เช่น "เรียกใช้เป็น .. " (ฉันสังเกตเห็นว่าวิธีการนี้คล้ายกับหลักการของ UAC ในภายหลัง)

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

ต้องบอกว่าถ้าคุณมีห้องปฏิบัติการทดสอบที่ดีและ / หรือทีมงาน QA ที่ดีนี่อาจเป็นจุดที่สงสัย - โดยเฉพาะอย่างยิ่งถ้าคุณมีแบบฝึกหัด ALM ที่เหมาะสมครึ่งหนึ่ง

ดังนั้นในที่สุด - ฉันพัฒนาโดยไม่มี UAC ส่วนใหญ่เป็นเพราะฉันเชื่อมั่นในตัวเองและทักษะของฉัน ในสภาพแวดล้อมแบบทีมฉันจะลงคะแนน ในองค์กรขนาดใหญ่คุณอาจไม่มีอิสระในการนี้ ... ผู้ดูแลระบบขององค์กรมักจะมีคำพูดสุดท้าย :)

ที่ บริษัท ของฉันนักพัฒนาวิศวกรและหัวหน้าของฉัน (เจ้าของ บริษัท ) มีสิทธิ์เป็นผู้ดูแลระบบท้องถิ่น เจ้านายของฉันยังมีสิทธิ์ผู้ดูแลระบบเครือข่ายเช่นกันในกรณีที่ฉันถูกรถชนทางนั้น (หรือออก) คนอื่น ๆ ถูกล็อค

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

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

ขึ้นอยู่กับทักษะของนักพัฒนาและไม่ว่าจะเป็นที่ปรึกษาหรือไม่ก็ตาม

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

ไม่มีใครใน Windows XP ที่ควรใช้บัญชีผู้ดูแลระบบสำหรับการใช้งานแบบวันต่อวันและใน Vista หากคุณต้องเป็นผู้ดูแลระบบอย่างน้อยต้องเปิดใช้งาน UAC โดยเฉพาะนักพัฒนาเว็บและนักพัฒนาอื่น ๆ ที่ท่องเว็บด้วย Internet Explorer

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