Score:3

มีจุดประสงค์ที่แท้จริงในการใช้บัญชีผู้ดูแลระบบภายใน "เรียกใช้ในฐานะ" แทนการเข้าสู่ระบบในฐานะผู้ดูแลระบบภายในหรือไม่

ธง uz

เรามาเริ่มกันที่การจัดฉาก -- ฉันเป็นผู้ดูแลระบบรุ่นเยาว์ที่ได้รับมอบหมายให้ดำเนินการเปลี่ยนแปลงบริษัทไปสู่รูปแบบ "สิทธิพิเศษน้อยที่สุด"ซึ่งรวมถึงการลบสิทธิ์ของผู้ดูแลระบบออกจากผู้ใช้ของเรา ซึ่งส่วนใหญ่ทำงานกับ Windows 10

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

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

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

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

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

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

สิ่งนี้ถูกต้องหรือไม่? ฉันทราบถึงคำกล่าวอ้างที่ว่า "92% ของช่องโหว่ที่สำคัญของ Microsoft ที่เปิดเผยในปี 2013 สามารถบรรเทาได้โดยการลบสิทธิ์ของผู้ดูแลระบบ"(SANS, 2016, อ้างถึงการศึกษาของ Avecto) และการยืนยันอื่น ๆ และฉันรู้สึกว่าการเป็นผู้ดูแลระบบในพื้นที่นั้นไม่ใช่ความคิดที่ดีจริง ๆ แต่วิธีแก้ปัญหาของเราดีกว่าจริง ๆ หรือไม่

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

in flag
IMO คำถามนี้เหมาะสำหรับ [security.se] มากกว่า
Score:5
ธง cv

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

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

การเปลี่ยนแปลงที่เสนอมีความปลอดภัยมากขึ้นหรือไม่? ใช่. ความเสี่ยงยังคงมีอยู่ในโมเดลใหม่หรือไม่? ใช่. รุ่นใหม่มีความเสี่ยงน้อยกว่าหรือไม่? ใช่.

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

spectras avatar
ro flag
นโยบายเหล่านั้นจริง ๆ แล้วเป็นการเสียเวลาจริง ๆ เนื่องจากจำนวนเวลาที่คุณต้องการสิทธิ์ของผู้ดูแลระบบในวันปกติในการพัฒนาซอฟต์แวร์ (ยกเว้นเว็บ) และพวกเขาพลาดประเด็นไปอย่างสิ้นเชิง: สิ่งที่จำเป็นต้องได้รับการปกป้องในระบบของนักพัฒนาไม่ใช่ระบบ แต่เป็นรหัส ซึ่งสามารถเขียนได้อย่างสมบูรณ์แบบในฐานะผู้ใช้ทั่วไป â กล่าวอีกนัยหนึ่ง มันไม่ได้ทำอะไรเพื่อปกป้องระบบไคลเอ็นต์ แต่เดี๋ยวก่อน อย่างน้อยเวิร์กสเตชันของนักพัฒนาของเราได้รับการปกป้องที่ดีกว่าเล็กน้อย ซึ่งคุ้มค่ากับประสิทธิภาพการทำงานที่ลดลง
Score:0
ธง ng

ขึ้นอยู่กับสเปกตรัมความเสี่ยงของคุณ

เพื่อเป็นการป้องกันการโจมตีเป้าหมาย มาตรการนี้ค่อนข้างไร้ประโยชน์

เพื่อเป็นการป้องกันการโจมตีจากวงใน มาตรการนี้ก็ไม่มีประโยชน์เช่นกัน

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

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

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

นอกเหนือจากนั้น การรับเครื่อง dev ที่มี IP มากที่สุดหรือโครงสร้างพื้นฐานสำรองที่มีทุกอย่างอยู่เพื่อเข้าร่วม AD นั้นไม่ดีตั้งแต่แรก

มันสร้างความล้มเหลวเพียงจุดเดียว การยุ่งกับนโยบายทำให้ผู้พัฒนาโกรธและสร้างสรรค์ที่จะเลี่ยงการรักษาความปลอดภัย

ปล. ฉันยังไม่เห็นการปรับใช้ AD ที่ไม่ได้ pwned ที่ระดับผู้ดูแลระบบโดเมนใน 5 ปี ไม่ว่าผู้ดูแลระบบที่ถูกต้องตามกฎหมายจะทราบหรือไม่ก็ตาม

โพสต์คำตอบ

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