การรักษาความปลอดภัยการดูแลระบบ Active Directory - ส่วนที่ 3
เรายังคงโพสต์ชุดเกี่ยวกับแง่มุมต่างๆ ของการรักษาความปลอดภัยการดูแลระบบ Active Directory ซึ่งสร้างโดย Brian Svidergol ชุดข้อมูลนี้มีสามส่วน แต่ละส่วนเกี่ยวข้องกับปัญหาเฉพาะเกี่ยวกับการรักษาความปลอดภัยการดูแลระบบ Active Directory หากต้องการทราบข้อมูลเชิงลึกเกี่ยวกับหัวข้อนี้มากขึ้น คุณสามารถอ่านส่วนแรกโดยเน้นไปที่หลักการของสิทธิพิเศษน้อยที่สุด และโพสต์ที่สองซึ่งบอกเล่าเกี่ยวกับข้อควรพิจารณาด้านโครงสร้างพื้นฐาน วันนี้ ในส่วนสุดท้ายของซีรีส์ คุณสามารถเรียนรู้เกี่ยวกับการตรวจสอบ การติดตาม และการแจ้งเตือน
หัวข้อการติดตามเพียงอย่างเดียวอาจกินเวลาทั้งเล่ม ดังนั้นสามารถตรวจสอบและแจ้งเตือนได้! ดังนั้น สำหรับโพสต์บนบล็อกนี้ เราจะพูดถึงส่วนเล็กๆ ของระบบเหล่านี้ในระดับสูงเท่านั้น สิ่งที่พบบ่อยที่สุดที่ฉันเห็นและได้ยินเกี่ยวกับการตรวจสอบสภาพแวดล้อมคือผู้ดูแลระบบได้รับการแจ้งเตือนมากเกินไป และการแจ้งเตือนมากเกินไปมักนำไปสู่สิ่งเดียว นั่นคือขาดการตอบสนองหรือตอบสนองช้าสำหรับเหตุการณ์ต่างๆ บ่อยครั้งผู้คนตระหนักถึงปริศนานี้ แต่ไม่ได้เปลี่ยนการกำหนดค่าสำหรับองค์กรจำนวนมาก ฉันต้องการพูดคุยเกี่ยวกับ 3 ประเด็น - ทำไมคุณควรตรวจสอบความสำเร็จและความล้มเหลว วิธีการติดตามผลในการรักษาความปลอดภัย Active Directory และการลดจำนวนการแจ้งเตือนเพื่อให้การตอบสนองต่อเหตุการณ์ได้รับการปรับปรุง
- ทำไมคุณควรตรวจสอบความสำเร็จและความล้มเหลว ดูการกำหนดค่าการตรวจสอบของคุณ คุณกำลังตรวจสอบเฉพาะความล้มเหลวหรือไม่? ถ้าเป็นเช่นนั้น คุณไม่ได้อยู่คนเดียว! แต่ถึงเวลาที่จะต้องคิดใหม่เกี่ยวกับกลยุทธ์นั้น การตรวจสอบความสำเร็จและความล้มเหลวเป็นกลยุทธ์ที่แนะนำเป็นอย่างยิ่ง ผมขอยกตัวอย่างบางส่วนเกี่ยวกับความสำคัญของการตรวจสอบเพื่อความสำเร็จ ขั้นแรก คุณกำลังตรวจสอบการเปลี่ยนแปลงการกำหนดค่าบนตัวควบคุมโดเมน ได้ทำการเปลี่ยนแปลง ซึ่งจำเป็นต้องมีการรับรองความถูกต้องที่สำเร็จและการดูแลระบบระยะไกลบางประเภท (RDP หรือ MMC) ในกรณีนี้เส้นทางทั้งหมดจะเกลื่อนไปด้วยการกระทำที่ประสบความสำเร็จ หากคุณไม่ได้บันทึกสิ่งเหล่านี้ด้วยการตรวจสอบ จะยากแค่ไหนในการพิจารณาว่าใคร/อะไร/เมื่อไหร่ ค่อนข้างน้อย. อีกตัวอย่างหนึ่ง - คุณเห็นการตรวจสอบความล้มเหลวจำนวนมากที่เกี่ยวข้องกับบัญชีบริการที่รับรองความถูกต้องของตัวควบคุมโดเมน ข่าวดีก็คือ คุณบันทึกความพยายามที่ล้มเหลวในการตรวจสอบได้ ข่าวร้าย คุณไม่แน่ใจว่าความพยายามหยุดลงเพราะผู้โจมตียอมแพ้หรือเพราะเขาเข้ามาจริงๆ การตรวจสอบความสำเร็จและความล้มเหลวช่วยเชื่อมโยงสิ่งต่างๆ เข้าด้วยกัน
- การตรวจสอบมีผลอย่างไรต่อการรักษาความปลอดภัย Active Directory มีหัวข้อมากมายเกี่ยวกับการตรวจสอบ Active Directory...หลายหัวข้อมากจนมีการเขียนเอกสารไวท์เปเปอร์ไว้ทั้งหมด สำหรับวันนี้ ฉันจะไม่เจาะลึกเรื่องการติดตามสุขภาพและเกณฑ์ขั้นต่ำ เรามาเน้นที่กลุ่มความปลอดภัยกันก่อน เรามาพูดถึงกลุ่มผู้ดูแลระบบโดเมนกันดีกว่า (แม้ว่าคำแนะนำที่กำลังจะเกิดขึ้นจะนำไปใช้กับกลุ่มความปลอดภัยที่สำคัญทั้งหมดก็ตาม) คุณควรติดตามการเปลี่ยนแปลงทั้งหมดของการเป็นสมาชิกกลุ่ม (การบวกและการลบ) หากคุณไม่ทำเช่นนั้น คุณอาจไม่มีทางรู้ว่ามีใครถูกเพิ่มชั่วคราวหรือไม่ (เช่น เพื่อสร้างความหายนะให้กับเครือข่ายของคุณ) จากนั้นจึงลบออกในอีกสองสามชั่วโมงต่อมา ตอนนี้เรามาเปลี่ยนเกียร์เป็นนโยบายกลุ่ม นโยบายกลุ่มมักเป็นพื้นที่ที่ถูกมองข้ามเมื่อตรวจสอบ Active Directory สถานการณ์ที่น่าเกลียดหลายประการเกิดขึ้นในใจด้วยนโยบายกลุ่ม: ผู้โจมตีต้องการเริ่มการโจมตีแบบฟิชชิ่งทั่วทั้งองค์กร แต่การตั้งค่า IE ในปัจจุบันป้องกันหรือลดประสิทธิภาพ - เปลี่ยนแปลง GPO อย่างรวดเร็วและไป ผู้โจมตีจำเป็นต้องส่งมัลแวร์บางตัวไปยังคอมพิวเตอร์ที่เข้าร่วมโดเมนทั้งหมด - สร้าง GPO แล้วไปได้เลย อย่างที่คุณเห็น การตรวจสอบนโยบายกลุ่มมีบทบาทสำคัญในกลยุทธ์การติดตามโดยรวม คุณจำเป็นต้องทราบว่าเมื่อใดที่สร้าง GPO ใหม่ ลิงก์ GPO เปลี่ยนแปลงเมื่อใด และการตั้งค่า GPO เปลี่ยนแปลงเมื่อใด คุณยังต้องการทราบว่าใครเป็นผู้ทำการเปลี่ยนแปลง ในที่สุดเครือข่ายย่อยของผู้ดูแลระบบก็เข้ามามีบทบาท การมีเครือข่ายย่อยการดูแลระบบแบบรวมศูนย์ช่วยให้สามารถติดตามตรวจสอบได้อย่างตรงเป้าหมาย และเปิดศักยภาพในการกำหนดค่าการติดตามเริ่มต้นจำนวนมากโดยอัตโนมัติ แทนที่จะกำหนดเป้าหมายการตรวจสอบที่เซิร์ฟเวอร์เฉพาะ IP เฉพาะหรือกลุ่มเฉพาะ (คอนเทนเนอร์/กลุ่ม/หรือคอลเลกชันอื่น ๆ ) คุณสามารถกำหนดเป้าหมายการตรวจสอบที่เครือข่ายย่อยทั้งหมดได้
- ลดจำนวนการแจ้งเตือน สำหรับใครก็ตามที่เคยใช้งาน System Center Operations Manager (OpsMgr) คุณก็รู้แล้วว่าฉันกำลังจะไปที่ไหน ปัจจุบัน เครื่องมือตรวจสอบมีความซับซ้อนอย่างไม่น่าเชื่อ มาพร้อมจอภาพมากมายในตัวและปรับแต่งให้เหมาะกับบทบาทของเซิร์ฟเวอร์ตั้งแต่แกะกล่อง OpsMgr มีชุดการจัดการสำหรับเกือบทุกอย่าง! นั่นคือข่าวดี ข่าวร้ายก็คือทันทีที่คุณเปิดทุกอย่างและกำหนดค่าพื้นฐานให้เสร็จสิ้น ผู้ดูแลระบบจะรู้สึกหนักใจกับจำนวน "ปัญหา" ที่มีอยู่ในสภาพแวดล้อมของตน
ในตอนแรกมันน่าตื่นเต้นมาก มีกิจกรรมมากมายและผลไม้ห้อยต่ำมากมาย แต่หลังจากผ่านไปหลายวัน หลายสัปดาห์ผ่านไป การแจ้งเตือนก็ยังคงมีมาเรื่อยๆ สิ่งต่อไปที่คุณรู้ โฟลเดอร์ Monitoring เล็กๆ น้อยๆ ที่ดีที่คุณสร้างในกล่องจดหมายเข้าของคุณเต็มไปด้วยข้อความแจ้งเตือนที่ยังไม่ได้อ่านนับพันข้อความ คุณหยุดดูโฟลเดอร์ Monitoring แบบเรียลไทม์และเพียงอ่านมันเมื่อคุณมีเวลาหยุดทำงาน นี่เป็นเรื่องปกติ แน่นอนว่ายังมีสิ่งที่เลวร้ายกว่านั้นอีก ครั้งหนึ่ง ฉันทำงานกับบริษัทที่มีผู้ดูแลระบบบางคนดึงที่อยู่ SMS ของตนออกจากการแจ้งเตือน เนื่องจากปริมาณการแจ้งเตือนทาง SMS มีจำนวนมากเกินไป ฉันได้พูดคุยกับหลายๆ คนเกี่ยวกับการลดจำนวนการแจ้งเตือน แต่มักจะเกิดเหตุการณ์ก่อนที่จะดำเนินการ เหตุการณ์ทั่วไปเริ่มต้นด้วยการไฟฟ้าดับ เมื่อทุกอย่างได้รับการสำรองข้อมูลแล้ว การสืบสวนการหยุดทำงานมักจะพิจารณาที่การตรวจสอบ แน่นอนว่าคงเป็นเวลาที่ดีที่จะเพิ่มหรือปรับปรุงการติดตามเพื่อให้ผู้ดูแลระบบได้ทราบเรื่องนี้ล่วงหน้าในครั้งต่อไปใช่ไหม? ใช่ แต่ในกรณีนี้ ผู้ดูแลระบบรู้ล่วงหน้า พวกเขาได้รับการแจ้งเตือน 15 รายการในบ่ายวันพุธ ปัจจุบันมีข้อความ #550-564 อยู่ในโฟลเดอร์ Monitoring ซึ่งมีข้อความ 2,600 ข้อความ ดังนั้นจึงไม่มีใครสังเกตเห็นพวกเขาเลย เมื่อเหตุการณ์ดังกล่าวเกิดขึ้น ผู้คนจะเริ่มมองหาการลดจำนวนการแจ้งเตือนในที่สุดเพื่อให้จัดการสิ่งต่างๆ ได้ง่ายขึ้น
คุณสามารถลดจำนวนการแจ้งเตือนหรือจ้างคน 10 คนเพื่อเฝ้าดูจอภาพและบันทึกข้อมูลได้ตลอดทั้งวัน (หรือในองค์กรที่มีงบประมาณมาก คุณสามารถทำได้ทั้งสองอย่าง) กลยุทธ์ของฉันในการลดการแจ้งเตือนนั้นค่อนข้างง่าย ทุกครั้งที่เกิดปัญหา (การหยุดทำงาน ความเสื่อมโทรม ฯลฯ) - ฉันมองไปที่การตรวจสอบ ฉันพบว่าเรารู้เรื่องนี้หรือไม่ และถ้าเรารู้ เรารู้เรื่องนี้เร็วพอที่จะดำเนินการและหลีกเลี่ยงปัญหาหรือไม่ ฉันพบว่าการตรวจสอบให้ข้อมูลแก่เราเพียงพอที่จะดำเนินการหรือไม่ ฉันพบว่ามีคนที่เหมาะสมได้รับแจ้งหรือไม่ บ่อยครั้งที่ผู้ดูแลระบบในแผนกหนึ่งได้รับการแจ้งเตือนมากกว่าแผนกของตน สิ่งนี้เกิดขึ้นกับหลายทีม จากนั้น เมื่อมีการแจ้งเตือนเข้ามา แม้ว่าผู้ดูแลระบบจะเห็นแล้ว ก็ไม่มีใครดำเนินการใดๆ เพราะพวกเขาคิดว่ามีคนอื่นเห็น ในกลยุทธ์การติดตามของฉัน ฉันยังถามคำถามสำคัญเมื่อมีการแจ้งเตือนเข้ามา การแจ้งเตือนกำหนดให้ฉันหรือใครก็ตามต้องดำเนินการหรือไม่ ถ้าไม่เช่นนั้น แสดงว่าสงสัยว่ามีค่าของการแจ้งเตือน ในโลกที่สมบูรณ์แบบ การแจ้งเตือนทุกครั้งจะเทียบเท่ากับการดำเนินการของผู้รับ ผู้คนจะได้รับการแจ้งเตือนเฉพาะเมื่อจำเป็นต้องดำเนินการ และการแจ้งเตือนจะมีทุกสิ่งที่พวกเขาจำเป็นต้องรู้ หากต้องการสรุปกลยุทธ์การติดตามของฉันในการลดจำนวนการแจ้งเตือน ให้ทำตามขั้นตอนเหล่านี้:
- ตรวจสอบให้แน่ใจว่าได้ดำเนินการใดๆ กับการแจ้งเตือนที่ได้รับหรือไม่ ถ้าไม่ทำไมจะไม่ได้? สามารถลบการแจ้งเตือนออกโดยไม่ส่งผลกระทบใดๆ ได้หรือไม่ จากนั้นจึงถอดออก ข้อมูลจะยังคงอยู่ในฐานข้อมูลการตรวจสอบสำหรับการรายงาน แต่จะไม่อุดตันโทรศัพท์หรืออีเมลของคุณ
- คุณได้รับการแจ้งเตือนว่ามีผู้อื่นกำลังดำเนินการอยู่หรือไม่? หากเป็นเช่นนั้น พวกเขาจะได้รับการแจ้งเตือนด้วยหรือไม่ หากเป็นเช่นนั้น ให้พิจารณาถอดตัวเองออก ถ้าไม่ ให้เพิ่มลงในการแจ้งเตือนแล้วลบตัวคุณเองออก เฉพาะผู้ที่จะดำเนินการเท่านั้นที่ควรได้รับการแจ้งเตือน
- คุณได้รับการแจ้งเตือนทางโทรศัพท์ทาง SMS เกี่ยวกับปัญหาที่ไม่สำคัญ (เช่น พื้นที่ดิสก์เหลือ 20%) หรือไม่? ถ้าเป็นเช่นนั้นให้ถอดตัวเองออก การแจ้งเตือนทาง SMS ควรเกิดขึ้นเฉพาะสำหรับปัญหาการผลิตและการหยุดทำงานหรือปัญหาการผลิตและการหยุดทำงานที่กำลังจะเกิดขึ้น หากดิสก์ทำงานอยู่ที่ 20% แต่จะไม่เต็มอีก 8 วัน คุณจะยังไม่ได้รับการแจ้งเตือนทาง SMS
ฉันหวังว่าฉันจะได้พูดถึงบางหัวข้อที่โดนใจและช่วยให้คุณเริ่มคิดถึงบางประเด็นเหล่านี้ในสภาพแวดล้อมของคุณ ดังที่ Bruce Schneier พูดย้อนกลับไปในเดือนเมษายนปี 2000 “ความปลอดภัยเป็นกระบวนการ ไม่ใช่ผลิตภัณฑ์” ขอให้สนุกและปลอดภัยในการใช้คอมพิวเตอร์!