สิทธิ์ Windows สำหรับนักพัฒนา

ฉันทำงานที่ บริษัท Fortune 500 ในฐานะนักพัฒนาซอฟต์แวร์ Windows ในการวิจัยและพัฒนา ปัจจุบันฝ่ายไอทีขององค์กรกำลังเตรียมพร้อมสำหรับการปรับใช้ Win7 ทั่วทั้ง บริษัท และเป็นส่วนหนึ่งของพวกเขากำลังมองหาการล็อคสิทธิ์ผู้ดูแลระบบอย่างสมบูรณ์ในทุกช่อง (รวมถึงเวิร์กสเตชัน dev ของเรา)

ฉันได้รับมอบหมายให้ทำงานกับพวกเขาเพื่อให้การเปลี่ยนแปลงราบรื่นที่สุดเท่าที่จะทำได้ ฉันโชคดี.

ฉันต้องการทราบว่ามีแหล่งข้อมูลที่เผยแพร่หรือทรัพยากรที่เคารพนับถืออื่น ๆ ที่ฉันสามารถใช้เพื่อ:

1. คิดออกว่าจะวาดเส้นในทราย
2. สำรองตำแหน่งของฉัน

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

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

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

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

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

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

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

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

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

สิ่งเหล่านี้อาจช่วย:

• http://www.slate.com/id/2226279/pagenum/all/
• /server/232416/should-dev-be-admin-on-their-computer
• http://avecto.com/blog/2010/09/the-pros-and-cons-of-windows-7-application-control-with-applocker/

ป.ล. : โชคดีที่สุด!

ทางเลือกหนึ่งคือขอสถานีทดสอบที่อนุญาตการเข้าถึงระดับผู้ดูแลระบบ

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

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

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

ฉันนึกภาพไม่ออกว่าจะพยายามพัฒนาโดยไม่ต้องเป็นผู้ดูแลระบบในท้องที่ แต่ฉันคิดว่าความต้องการจะแตกต่างกันไปขึ้นอยู่กับงานพัฒนาและวิธีมาตรฐานกระบวนการพัฒนาและ toolchain ที่เป็นมาตรฐานในที่ทำงานของคุณ

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

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

จากมุมมองด้านไอทีที่บริสุทธิ์และมุมมองการพัฒนาหลาย ๆ บริษัท แก้ปัญหาในลักษณะนี้:

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

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

พิจารณาให้นักพัฒนาสองบัญชี

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

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

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

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

สิทธิ์ที่จำเป็นสำหรับการพัฒนาซอฟต์แวร์ไม่เหมาะสมสำหรับผู้ใช้ทั่วไป

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

1. โปรแกรมเมอร์คือการเข้าถึงของผู้ดูแลระบบในเครื่องของพวกเขา
2. เครื่องพัฒนาไม่ได้เชื่อมต่อกับเครือข่ายของ บริษัท

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

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

คุณสามารถใช้สภาพแวดล้อมเสมือนจริงได้หรือไม่?

หากคุณไม่ได้ทำสิ่งที่หนักกราฟิกแล้วใช้ MSVC ใน vmware หรือ virtualbox เป็นเรื่องปกติ (ถ้าคุณมี ram จำนวนมาก) จากนั้นคุณสามารถมีผู้ดูแลระบบในสภาพแวดล้อมเสมือนและติดตั้ง 'พวกเขา' ถูกล็อคลง