นโยบายบัญชีผู้ดูแลโดเมน (หลังการตรวจสอบ PCI)


14

หนึ่งในลูกค้าของเราคือ บริษัท Tier 1 PCI และผู้ตรวจสอบได้ให้คำแนะนำเกี่ยวกับเราในฐานะผู้ดูแลระบบและสิทธิ์การเข้าถึงของเรา

เราจัดการโครงสร้างพื้นฐานที่ใช้ Windows ทั้งหมดของพวกเขาโดยประมาณ 700 เดสก์ท็อป / 80 เซิร์ฟเวอร์ / 10 ตัวควบคุมโดเมน

พวกเขาแนะนำว่าเราย้ายไปยังระบบที่เรามีบัญชีแยกกันสามบัญชี:

DOMAIN.CO.UK\UserWS  
DOMAIN.CO.UK\UserSRV  
DOMAIN.CO.UK\UserDC  
  • ที่ไหน WSเป็นบัญชีที่ล็อกออนเข้าสู่เวิร์กสเตชันเท่านั้นเป็นผู้ดูแลท้องถิ่นบนเวิร์กสเตชัน
  • ที่ไหน SRVเป็นบัญชีที่ล็อกออนเข้าสู่ Non DC Servers เท่านั้นคือ Local Administrator บนเซิร์ฟเวอร์
  • ที่ไหน DCเป็นบัญชีที่เข้าสู่ระบบของ Domain Controllers โดยเฉพาะบัญชีผู้ดูแลโดเมน

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

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

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

ฉันสนใจที่จะรับฟังมุมมองของผู้ดูแลระบบคนอื่น ๆ โดยเฉพาะผู้ที่มีส่วนเกี่ยวข้องกับ บริษัท จดทะเบียน PCI และคุณได้รับประสบการณ์พร้อมคำแนะนำที่คล้ายกัน นโยบายของคุณเกี่ยวกับการเข้าสู่ระบบของผู้ดูแลระบบคืออะไร

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


4
ในฐานะที่เป็น Tier 1 ฉันประหลาดใจจริงๆที่เครือข่ายของพวกเขาที่ใช้การชำระเงิน CC อยู่ในเครือข่ายเดียวกับที่โครงสร้างพื้นฐานของ Windows นี้เปิดใช้งานและไม่ได้แบ่งกลุ่มออกด้วยตนเอง ทำให้การปฏิบัติตามนั้นง่ายขึ้นมาก
TheCleaner

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

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

ฟังดูเหมือนประสบการณ์คล้าย ๆ กับserverfault.com/questions/224467/… - โดยหลักแล้วมันเป็นแผนที่ดีและสามารถป้องกันการโจมตีที่น่ารังเกียจได้
เลน Hallam

คำตอบ:


18

ฉันอยู่ที่ผู้ขาย Tier 1 PCI เรามีสิ่งนี้ในสถานที่มีความแตกต่างเล็กน้อย

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

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

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

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

นี่คือการบรรเทาที่ฉันจะพิจารณา:

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

  • สำหรับเวิร์กสเตชันฉันจะไม่ใช้บัญชีโดเมนเพื่อจุดประสงค์ของผู้ดูแลระบบหากเป็นไปได้ เรามีบัญชีท้องถิ่นที่สามารถใช้ในการยกระดับการดำเนินงานประเภท UAC สิ่งนี้เป็นไปตาม 99.9% ของข้อกำหนดระดับความสูงส่วนใหญ่ เวิร์คสเตชั่นมีแนวโน้มที่จะเป็นเวคเตอร์การโจมตีที่ร้อนแรงเนื่องจากการขาดการควบคุมการเปลี่ยนแปลงอย่างต่อเนื่องและการมีอยู่ของ Java JRE และ Flash

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

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

  • สำหรับบัญชีที่มีอภิสิทธิ์สูงสุด (Enterprise Admin, Domain Admin ฯลฯ ) ให้ใช้เฉพาะเซิร์ฟเวอร์กระโดด เซิร์ฟเวอร์นี้จะอยู่ภายใต้การรักษาความปลอดภัยที่เข้มงวดที่สุดการควบคุมการเปลี่ยนแปลงและการตรวจสอบ สำหรับฟังก์ชั่นการจัดการประเภทอื่น ๆ ทั้งหมดให้พิจารณาว่ามีบัญชีการจัดการแยกต่างหาก เซิร์ฟเวอร์กระโดดควรรีสตาร์ททุกวันรีสตาร์ทเพื่อล้างโทเค็นกระบวนการจากกระบวนการ LSA

  • อย่าทำงานการบริหารจากเวิร์กสเตชันของคุณ ใช้เซิร์ฟเวอร์ที่แข็งตัวหรือเซิร์ฟเวอร์กระโดด

  • พิจารณาใช้รีเซ็ต VMs อย่างง่ายดายเป็นกล่องกระโดดของคุณซึ่งสามารถรีเซ็ตเพื่อล้างหน่วยความจำหลังจากแต่ละเซสชัน

อ่านเพิ่มเติม:

https://blogs.technet.com/b/security/archive/2012/12/06/new-guidance-to-mitigate-determined-adversaries-favorite-attack-pass-the-hash.aspx

รายงาน Microsoft Security Intelligence, เล่มที่ 13, มกราคม - มิถุนายน 2555
http://www.microsoft.com/security/sir/archive/default.aspx

อ่านหัวข้อ: "การป้องกันการโจมตีแบบพาส - แฮ - แฮช"

เอาชนะการโจมตีแบบพาส - แฮชที่น่ากลัว
https://www.infoworld.com/d/security/defeat-dreaded-pass-the-hash-attacks-179753

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