การล็อคเครื่องของนักพัฒนาพยายามมากกว่าความคุ้มค่าหรือไม่? [ปิด]


19

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


10
เมื่อพิจารณาจากกลุ่มโปรแกรมเมอร์ขนาดใหญ่ของประชากร Server Fault จาก Stack Overflow ฉันเดิมพันว่าปัญหานี้เกิดจากอคติการเลือก ผู้พัฒนารายใดจะพูดว่า 'ล็อคฉันลงโปรด!'
romandas

คำตอบ:


11

ปัญหาที่ใหญ่ที่สุดที่ไม่ได้ล็อคเครื่องของนักพัฒนาซอฟต์แวร์คือซอฟต์แวร์ใด ๆ ที่พวกเขาพัฒนาจะต้องใช้สิทธิ์ผู้ดูแลระบบเต็มรูปแบบในการทำงาน การเข้าถึงของนักพัฒนาควรเหมือนกับสภาพแวดล้อมที่พวกเขาจะต้องใช้งานถ้าพวกเขาต้องการ "self supportable" หรือ "self installable" ให้พวกเขามีบัญชีผู้ดูแลระบบอื่นเช่น Bruce.admin ซึ่งพวกเขาต้องใช้เมื่อทำการ admin สิ่งต่าง ๆ แต่ไม่ได้ใช้ในแต่ละวัน

เช่นเดียวกับที่ผู้ดูแลระบบ UNIX ที่มีค่าควรจะใช้บัญชีรูทสำหรับงานที่ไม่ใช่ผู้ดูแลระบบประจำวัน


14
ฉันทำผิด "จะต้อง" คุณกำลังทำให้ดูเหมือนว่าข้อสรุปมาก่อนว่านักพัฒนาจะทำสิ่งผิดปกติ ในขณะที่ฉันยอมรับว่าการพัฒนาซอฟต์แวร์ที่ทำงานด้วยสิทธิพิเศษสูงเกินความจำเป็นน้อยกว่าที่ต้องการฉันไม่คิดว่าฝ่ายไอทีควรพยายามบังคับใช้แนวทางการพัฒนาโดยเฉพาะอย่างยิ่งด้วยมาตรการที่รุนแรงเช่นการล็อคเครื่อง หากฝ่ายไอทีเป็นผู้มีส่วนได้ส่วนเสียในกระบวนการกำหนดความต้องการของแอปพลิเคชันและควรใช้สำหรับแอพภายในองค์กร - จากนั้นทำให้แอปพลิเคชันความต้องการได้รับการพัฒนาและทดสอบเพื่อให้ทำงานได้โดยมีสิทธิ์ต่ำกว่า
Chris W. Rea

แต่ฉันคิดว่าความคิดของบัญชีแยกต่างหากมีข้อดี แต่อย่าบังคับฉันเลยแค่นั้นแหละ
Chris W. Rea

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

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

1
เมื่อใช้เหมือนแอพหลายพันตัวเพียง 5% เท่านั้นที่ต้องการสิทธิ์ผู้ดูแลระบบโดยไม่มีเหตุผลจริง
Mircea Chirea

55

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

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

การล็อคคนลงบัญชีเพื่อใช้เพียง IE และ open word นั้นใช้ได้ แต่ถ้านักพัฒนาของคุณที่ต้องการติดตั้งเบราว์เซอร์ 4 ประเภทและต้องการติดตั้งแอปอย่างรวดเร็วเพื่อแก้ปัญหาอาจเป็นเรื่องที่น่ารำคาญ

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


10
ถ้าฉันสามารถลงคะแนนสำหรับคำตอบนี้หลายครั้งฉันจะ ฉันเป็นนักพัฒนาและยอมรับ 110% +1
Chris W. Rea

1
@ cwrea: อะไรคือส่วนเกิน 10%?
setzamora

3
ฉันเห็นด้วย แต่ บริษัท ที่เข้มงวดมากในแง่ของความปลอดภัยของข้อมูลจะไม่อนุญาตให้ติดตั้งแอปพลิเคชันที่ไม่ใช่ "มาตรฐานของ บริษัท "
setzamora

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

1
ในขณะที่บอกว่า 'ถ้าคุณถอนการติดตั้งมันไม่รองรับ' เป็นเรื่องที่ดีและดีจริง ๆ แล้วมันกลายเป็นนักพัฒนาบ่นกับเจ้านายของเขาว่าซอฟต์แวร์ xyz ไม่ทำงานและ Systems / helpdesk จะไม่ช่วยฉัน บอสถูกยิงโดยเพื่อนของเขาและสิ่งต่อไปที่คุณรู้ว่าผู้จัดการ / ผู้อำนวยการ / VP กำลังหายใจคอใครบางคนที่ไม่สนใจว่ามันไม่ได้รับการสนับสนุนเพียงแก้ไขมันทันที ตอนนี้ Systems / Helpdesk ต้องสนับสนุนโปรแกรมสุ่ม xyz สำหรับนักพัฒนาและโปรแกรมสุ่ม abc สำหรับนักพัฒนา หากคุณต้องการมันจริงๆใส่มันผ่านช่องทาง
Zypher

14

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

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

สร้างอิมเมจที่คุณสามารถใช้เพื่อสร้างเครื่องจักรใหม่ได้หากจำเป็น การติดตั้ง SQL Server dev edition ด้วยตนเอง Visual Studio, Cygwin และ MikTex รวมถึงแอพอื่น ๆ ที่ใช้เวลาค่อนข้างนาน รูปภาพที่ติดตั้งแอพขนาดใหญ่เหล่านี้จะมีค่าพอสมควรหากคุณต้องทำการถ่ายภาพเครื่องจักรใหม่อีกครั้ง

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

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

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

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

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

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

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

ฉันจะเพิ่มว่านี่เป็นปัญหาที่น้อยมากในสภาพแวดล้อม unix หรือ linux; ผู้ใช้สามารถปรับแต่งสภาพแวดล้อมของตัวเอง.profileได้อย่างสวยงาม คุณสามารถรวบรวมและติดตั้งสิ่งต่าง ๆ ภายใต้/home/bloggsj/binไดเรกทอรีของคุณเองเพื่อความสุขใจของคุณ 'สิทธิ์ผู้ดูแลระบบท้องถิ่น' ส่วนใหญ่เป็นปัญหาของ windows แม้ว่ายังมีบางสิ่งที่ต้องการการเข้าถึงรูทภายใต้ Unix


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

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

8

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

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


2
ฉันได้รับการสนับสนุนประมาณ 20 นาทีจากนั้นจึงเสนอภาพใหม่ ทำงานได้ดีสำหรับเรา
Preet Sangha

6

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

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

หากคุณกำลังจะให้ devs เต็มรูปแบบเข้าถึงระบบของพวกเขาอย่างอิสระคุณควรพิจารณามาตรการเพิ่มเติมต่อไปนี้:

  • จัดให้มีระบบอื่นล็อคลงได้มากเท่ากับระบบผู้ใช้ทั่วไปที่ถูกล็อคลงสำหรับการใช้งานทั่วไปที่ไม่ใช่ dev
    • ใส่เครื่อง dev ที่เข้าถึงได้อย่างเต็มรูปแบบไว้ใน VLAN พิเศษด้วยการเข้าถึงทรัพยากร dev เท่านั้น
  • ถามว่ามีอะไรที่จะป้องกันระบบที่ติดไวรัสไม่ให้ทำอันตรายต่อโค๊ดเบส เครื่องแบ็คดอร์จะตรวจสอบรหัสที่เป็นอันตรายหรือลบล้างโค้ดเบสในมือของแฮ็กเกอร์ที่เป็นศัตรูหรือไม่? ทำตามขั้นตอนที่เหมาะสมเพื่อลดความเสี่ยงนี้
  • ในทำนองเดียวกันถามว่ามีอะไรปกป้องข้อมูลทางธุรกิจที่จัดขึ้นในระบบที่ devs เข้าถึง
  • ทำรายการซอฟต์แวร์อย่างสม่ำเสมอและตรวจสอบความปลอดภัยของระบบ dev
    • รับความคิดเกี่ยวกับสิ่งที่พวกเขากำลังทำงานและใช้ข้อมูลนี้เพื่อสร้างภาพการปรับใช้ระบบ dev ของคุณใหม่
    • ไม่ช้าก็เร็วคุณจะมีนักพัฒนาที่ไม่ประมาทและติดตั้งสิ่งต่าง ๆ ที่เห็นได้ชัดว่าเป็นอันตรายหรือไม่เกี่ยวข้องกับงาน เมื่อส่งคำเตือนอย่างรวดเร็วเมื่อเกิดเหตุการณ์นี้คุณจะต้องให้ชุมชนผู้พัฒนาทราบว่าใช่มีคนดูอยู่และพวกเขามีความรับผิดชอบที่จะอยู่ในมาตรฐานที่เหมาะสม
  • คุณสแกนมัลแวร์เป็นประจำหรือไม่ ในบางกรณีผู้พัฒนาซอฟต์แวร์จะบ่นเกี่ยวกับภาษีประสิทธิภาพที่เรียกเก็บจากระบบ AV ที่เข้าถึงได้ (ระบบ AV ที่เปิดใช้งานอยู่เสมอสแกนทุกครั้งที่เข้าถึงไฟล์) อาจเป็นการดีกว่าที่จะย้ายไปใช้กลยุทธ์การสแกนทุกคืนและ / หรือสร้างการยกเว้นไฟล์ / โฟลเดอร์ไปยังการสแกนที่เข้าถึงของคุณ ตรวจสอบให้แน่ใจว่าสแกนไฟล์ที่ถูกแยกออกแล้วด้วยวิธีอื่น
    • devs ที่เปิดใช้งานโดยผู้ดูแลระบบของคุณสามารถปิดการสแกน AV ทั้งหมดได้หรือไม่ คุณจะตรวจจับและแก้ไขสิ่งนี้ได้อย่างไร

หากคุณกำลังจะไปที่ระบบ dev lockdown แล้วคุณควรพิจารณาดังต่อไปนี้:

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

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

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

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

โดยส่วนตัวฉันไม่คิดว่าทุกคนควรอยู่เหนือรูปแบบการรักษาความปลอดภัยบางรูปแบบ ทุกคน (sysadmins, devs, ผู้บริหารระดับสูงรวมอยู่ด้วย) ควรได้รับการปฏิบัติตามขั้นตอนการรักษาความปลอดภัยที่เพียงพอ การพูดอย่างอื่นคือการกล่าวว่าระบบและข้อมูลของ บริษัท ไม่คุ้มค่ากับความพยายามในการปกป้อง

ลองอีกวิธีกัน หาก Mark Russinovich สามารถยึดครองโดยรูทคิตทุกคนสามารถทำได้!


3

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

ปัญหาคือคุณจะต้องจบลงด้วยนักพัฒนาทั้งหมดโดยที่แต่ละคนทำสิ่งที่พวกเขาทำโดยส่วนใหญ่ไม่ได้ใส่ใจเรื่องความปลอดภัยและต้องการให้แอปทำงานได้ จากนั้นคุณจะได้รับคำขอ - "เราได้เสร็จสิ้นขั้นตอนการพัฒนาแล้วโปรดจำลองสภาพแวดล้อม dev ของเราไปยังการทดสอบ pre-prod และ prod"

พวกเขายังติดนิสัยในการติดตั้งขยะสุ่ม (ซอฟต์แวร์ที่บรรจุไม่ดี) จากนั้นมอบหมายให้คุณติดตั้งบนเซิร์ฟเวอร์โหลหรือมากกว่านั้นในชั้นอื่น ๆ

ฉันทำนโยบายค่อนข้างง่าย:

  • นักพัฒนาไม่ได้รับสิทธิ์เข้าถึงรูท - สำหรับสภาพแวดล้อมการพัฒนา
  • ผู้พัฒนาทำการเข้าถึงรูทไปยังเซิร์ฟเวอร์ VMware ล่วงหน้า แต่ไม่รองรับ
  • นักพัฒนาจะต้องให้แพคเกจ RPM ที่เป็นของการกระจาย OS ซึ่งแอพของพวกเขาจะทำงานหรือแพคเกจ RPM ที่สอดคล้องกับ FHS และ LSB
  • ไม่มีแอปพลิเคชันของพวกเขาใด ๆ ที่สามารถทำงานในฐานะรูท
  • จะไม่สามารถเข้าถึงsuหรือsudoผู้ใช้แอปพลิเคชัน - ซึ่งจะถูกล็อคลงไปที่ไม่มีการเข้าถึงเปลือก (นี่สำหรับการบัญชี / การตรวจสอบ)
  • คำสั่งใด ๆ ที่พวกเขาจำเป็นต้องเรียกใช้ด้วยการเข้าถึงที่มีสิทธิพิเศษจะต้องได้รับการร้องขอและอนุมัติอย่างชัดเจนซึ่งในเวลานั้นจะถูกเพิ่มลงในsudoersไฟล์
    • คำสั่ง / สคริปต์เหล่านี้จะไม่สามารถเขียนได้โดยพวกเขา
    • ไม่มีการอ้างอิงสคริปต์ (โดยตรงหรือโดยอ้อม) โดยคำสั่งเหล่านี้จะสามารถเขียนได้โดยพวกเขา

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


2

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

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

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


1

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

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

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


เป็นความจริงที่ MS แนะนำให้ใช้ VS2005 ในฐานะผู้ดูแลระบบ แต่ Michael Howard หนึ่งในผู้รักษาความปลอดภัยซอฟต์แวร์ชั้นนำที่ MS กล่าวว่า 99% ของเวลาทำงานได้ดีเหมือน nonadmin: blogs.msdn.com/michael_howard/archive/2007/01/04/ ...... ดังนั้น หากการรักษาความปลอดภัยมีความสำคัญกับคุณคุณอาจลองใช้ nonadmin ความประหลาดใจน่าจะรอคุณอยู่!
quux

1

ฉันเห็นด้วยกับแนวคิดของการใช้เครื่องเสมือนบนเดสก์ท็อปที่ จำกัด -

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


+1 .. ฉันไม่เข้าใจว่าเพราะเหตุใดจึงใช้งาน VMs ไม่เพียง แต่สำหรับวัตถุประสงค์ที่คุณกล่าวถึง แต่การแจกจ่ายซอฟต์แวร์จะทำได้ง่ายขึ้นโดยใช้ VMs

1

ฉัน (ในฐานะของตัวเอง) ชอบควบคุมเครื่องจักรของฉันอย่างเต็มความหมาย ทำงานเป็นผู้ดูแลเมื่อจำเป็น

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

ส่วนใหญ่พวกเขาจะต้องรู้เพิ่มเติมเกี่ยวกับโครงสร้างพื้นฐานด้านไอทีจากมุมมองผู้ดูแลระบบ IT / IT, สิ่งที่เกี่ยวข้องกับความปลอดภัยรวมถึงสาเหตุที่ไม่ควรพัฒนาด้วยสิทธิ์ระดับสูง (และวิธีการตรวจสอบให้แน่ใจว่าคุณไม่ได้ ... )

"อย่าสุ่มสี่สุ่มห้าไว้วางใจเราเมื่อเราบอกว่าเรารู้ว่าทั้งหมดที่เราจำเป็นต้องรู้เกี่ยวกับคอมพิวเตอร์" ;-)

คุณจะยังคงต้องสนับสนุนพวกเขาด้วยเครือข่ายโดเมนและสิ่งที่บัญชีติดตั้งซอฟต์แวร์ของเครื่องมือที่ไม่ใช่ dev ฯลฯ


สิ่งหนึ่งที่เพิ่มเติม: ตรวจสอบให้แน่ใจว่าเรามี AV ที่เหมาะสมติดตั้ง ... บังคับถ้าจำเป็น ... ;-)
Arjan Einbu

1

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

เราลงเอยด้วยกระบวนการต่อไปนี้:

  • อิมเมจมาตรฐานของเรามีเครื่องมือพื้นฐาน: Windows, Office, Anti-virus, Acrobat, ยูทิลิตี้บางอย่าง
  • เราให้พื้นที่ดิสก์เครือข่ายจำนวนมากเพียงพอที่จะเก็บทุกอย่างไว้ในเครือข่าย เกี่ยวกับข้อยกเว้นเพียงอย่างเดียวคือไฟล์วิดีโอที่กำลังดำเนินการซึ่งต้องอยู่ในพื้นที่
  • พนักงาน (ในการปรึกษาหารือกับหัวหน้างาน) มีสองตัวเลือก: ฝ่ายไอทีดูแลเครื่องพีซีทำการติดตั้งและกำหนดค่าทั้งหมดหรือพวกเขาสามารถเข้าถึงผู้ดูแลระบบเพื่อทำเอง ไม่ว่าในกรณีใดข้อมูลทั้งหมดจะถูกสำรองในเครือข่าย
  • หากฝ่ายไอทีดูแลระบบและมันก็ตายเราจะนำมันกลับสู่สถานะเดิมรวมถึงการเพิ่มซอฟต์แวร์พิเศษที่พวกเขาต้องการที่เราติดตั้ง
  • หากพวกเขามีสิทธิ์การเข้าถึงของผู้ดูแลระบบและระบบเสียชีวิตเราต้องดูและพยายามแก้ไข แต่ความมุ่งมั่นของเราคือนำพวกเขากลับไปที่อิมเมจมาตรฐานและพวกเขาจะต้องใช้มัน หากพวกเขามีข้อมูลในท้องที่เราจะพยายามกำจัดมันเสียก่อน แต่ SLA ของเรานั้นเพียงเพื่อให้พวกเขาใช้งานพีซีมาตรฐานโดยเร็วที่สุด
  • ทุกคนต้องมีสิทธิ์การเข้าถึงของผู้ดูแลระบบเพื่อทราบวิธีการตรวจสอบให้แน่ใจว่าการอัปเดตของ Windows นั้นใช้งานได้เพื่อให้มีการปรับปรุงการป้องกันไวรัสและมัลแวร์

เราอยากให้ทุกคนเข้าถึงผู้ดูแลระบบบน vlan ที่ "ไม่น่าเชื่อถือ" แต่เราไม่เคยทำเช่นนั้น

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.