การตรวจสอบความปลอดภัยด้วยนโยบายกลุ่มภายในเครื่อง (Local Group Policy) ในสภาพแวดล้อมของ Windows

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

ในบทความนี้ เราจะอธิบายขั้นตอนการวางแผนทีละขั้นตอน การตรวจสอบความปลอดภัยโดยอิงตามนโยบายกลุ่มภายในเครื่องและ GPO บนตัวควบคุมโดเมน เซิร์ฟเวอร์ และเวิร์กสเตชัน คุณจะได้เห็นทั้งส่วนประกอบคลาสสิกของ Windows (นโยบายการตรวจสอบขั้นสูง, SACL, auditpol เป็นต้น) และวิธีการที่ทั้งหมดนี้ผสานรวมเข้ากับโซลูชันต่างๆ เช่น Microsoft Defender สำหรับ Identity และด้วยสถานการณ์แบบไฮบริดใน AWS รวมถึงเคล็ดลับและแนวทางปฏิบัติที่ดีที่สุดเพื่อหลีกเลี่ยงการลดประสิทธิภาพหรือการเต็มไปด้วยเหตุการณ์ที่ไม่จำเป็น

เหตุใดการตรวจสอบความปลอดภัยด้วย Local Group Policy จึงมีความสำคัญมาก?

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

ในสภาพแวดล้อมขนาดใหญ่ที่มีผู้คนจำนวนมาก GPO ที่เชื่อมโยงกับ OU ต่างๆด้วยโดเมนหลายโดเมนและเซิร์ฟเวอร์จำนวนมาก การติดตามการเปลี่ยนแปลงทั้งหมดจึงกลายเป็นเรื่องยุ่งยากหากไม่ได้เปิดใช้งานการตรวจสอบอย่างถูกต้องตั้งแต่เริ่มต้น นั่นคือเหตุผลที่ผลิตภัณฑ์อย่างเช่น จึงมีความสำคัญ Microsoft Defender สำหรับ Identity หรือโซลูชันจากบริษัทภายนอก เช่น Semperis DSP อาศัยเหตุการณ์ด้านความปลอดภัยของ Windows เป็นอย่างมากในการตรวจจับพฤติกรรมที่น่าสงสัย

แนวคิดหลักยังคงเหมือนเดิมเสมอ คือ การกำหนดค่า การตรวจสอบที่มีรายละเอียดเพียงพอ เช่น การตรวจจับกิจกรรมที่สำคัญ (การเปลี่ยนแปลงใน GPO การแก้ไขบัญชี การละเมิด NTLM การเคลื่อนไหวใน AD FS หรือ AD CS การเข้าถึงโฟลเดอร์ทางการเงิน ฯลฯ) แต่โดยไม่ก่อให้เกิดการใช้ทรัพยากร CPU ดิสก์ และเครือข่าย หรือสร้างไฟล์บันทึกขนาดหลายเทราไบต์ที่ไม่สามารถวิเคราะห์ได้

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

Defender สำหรับการตรวจสอบข้อมูลประจำตัวและการตรวจสอบเหตุการณ์ของ Windows

Microsoft Defender for Identity พึ่งพาอย่างมากกับ... เหตุการณ์ด้านความปลอดภัยของ Windows เพื่อตรวจจับการเคลื่อนย้ายข้ามระบบ การเปลี่ยนแปลงบัญชีที่น่าสงสัย การใช้ NTLM ในทางที่ผิด หรือการแก้ไขที่สำคัญใน Active Directory หากการตั้งค่าการตรวจสอบไม่ถูกต้อง ผลิตภัณฑ์จะสูญเสียความสามารถในการมองเห็นและส่งผลให้สูญเสียความสามารถในการตรวจจับไปด้วย

สิ่งแรกที่ Microsoft แนะนำคือการเรียกใช้โปรแกรม สคริปต์ PowerShell ที่ตรวจสอบการกำหนดค่าปัจจุบัน ตรวจสอบและสร้างรายงานเกี่ยวกับสิ่งที่ขาดหายไป โดยดำเนินการผ่านโมดูล Defender for Identity PowerShell และคำสั่ง cmdlet รายงานการกำหนดค่า MDI ใหม่ซึ่งช่วยให้สามารถสแกนได้ทั้ง GPO ของโดเมนและการกำหนดค่าภายในเครื่อง

ตัวอย่างทั่วไปคือการเปิดตัวสิ่งต่างๆ เช่น: New-MDIConfigurationReport -Path «C:\\Reports» -Mode Domain -OpenHtmlReportคำสั่งนี้จะบันทึกรายงาน HTML ไปยังเส้นทางที่ระบุ อ่านข้อมูลทั้งหมดจาก GPO ของโดเมน และเปิดรายงานในเบราว์เซอร์เริ่มต้นโดยอัตโนมัติ เพื่อให้คุณสามารถตรวจสอบการตั้งค่าที่คุณต้องนำไปใช้ได้

รายงานฉบับนี้วิเคราะห์นโยบายการตรวจสอบขั้นสูง การกำหนดค่า NTLM, SACL บนวัตถุ Active Directory ที่สำคัญ การตั้งค่า AD FS และอื่นๆ แนวคิดคือ เมื่อตรวจสอบเสร็จแล้ว คุณจะสามารถ ปรับนโยบาย GPO และนโยบายท้องถิ่น ก่อนที่จะเปิดใช้งานการเก็บรวบรวมเหตุการณ์อย่างเต็มรูปแบบในสภาพแวดล้อมของคุณ

หากคุณไม่ต้องการจัดการกับขั้นตอนด้วยตนเอง Defender for Identity มีตัวเลือกให้คุณ การตรวจสอบอัตโนมัติของ Windows ซึ่งจะตรวจสอบการกำหนดค่าที่มีอยู่ทุก 24 ชั่วโมง ตรวจจับช่องว่าง และทำการแก้ไขที่จำเป็นกับตัวควบคุมโดเมนโดยอัตโนมัติ

การตรวจสอบอัตโนมัติเทียบกับการกำหนดค่าด้วยตนเอง

การโทร การตรวจสอบอัตโนมัติของ Windows ภายใน Defender for Identity นั้น จะจัดการงานหลายอย่างที่คุณต้องทำด้วยตนเองใน Group Policy Objects (GPOs) หรือนโยบายภายในของตัวควบคุมโดเมน ซึ่งรวมถึงการตรวจสอบการตรวจสอบบริการไดเร็กทอรีขั้นสูง การตรวจสอบ NTLM การตรวจสอบวัตถุโดเมน การกำหนดค่า AD FS และนโยบายการตรวจสอบของ Windows เองด้วย

เซ็นเซอร์ Defender for Identity แก้ไข SACL ในอ็อบเจ็กต์รากของโดเมน เพื่อบันทึกการเปลี่ยนแปลงไดเร็กทอรีที่เกี่ยวข้อง อัปเดตค่าบันทึกสำหรับการตรวจสอบ NTLM (รวมถึงการบันทึกเหตุการณ์ 8004) เพิ่มรายการตรวจสอบในคอนเทนเนอร์การกำหนดค่า AD FS และปรับนโยบายการตรวจสอบภายในโดยใช้ API ของ Windows LSA

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

หากต้องการเปิดใช้งาน เพียงเข้าไปที่พอร์ทัล Microsoft Defender แล้วเข้าสู่ส่วนของ... การตั้งค่า > ข้อมูลประจำตัว > คุณสมบัติขั้นสูง และเปิดใช้งานตัวเลือกการกำหนดค่าการตรวจสอบอัตโนมัติของ Windows อย่างไรก็ตาม แนะนำให้ตรวจสอบอีกครั้งในภายหลังด้วยรายงานการกำหนดค่าและเครื่องมือต่างๆ เช่น auditpol.exe ทุกอย่างได้รับการดำเนินการตามที่คุณคาดหวังไว้

หากคุณชื่นชอบวิธีการแบบดั้งเดิม คุณสามารถเลือกใช้ ได้เสมอ กำหนดค่าการตรวจสอบทั้งหมดด้วยตนเอง: นโยบายขั้นสูง, SACL บนอ็อบเจ็กต์ AD ที่สำคัญ, นโยบาย NTLM, การตรวจสอบ AD FS, AD CS, Microsoft Entra Connect และคอมพิวเตอร์ที่ทำหน้าที่เป็นเซิร์ฟเวอร์ไฟล์หรือมีข้อมูลที่ละเอียดอ่อน

กำหนดค่าการตรวจสอบขั้นสูงบนตัวควบคุมโดเมน

หัวใจสำคัญของการตรวจสอบที่ดีมักจะอยู่ที่... ตัวควบคุมโดเมน (แบบสอบถาม ระบบรักษาความปลอดภัยขั้นสูงใน Windows Serverนโยบายเหล่านี้ใช้ในการควบคุมการเข้าถึง การสร้างบัญชี การเปลี่ยนแปลงกลุ่มผู้มีสิทธิ์ และการดำเนินการที่สำคัญที่สุดส่วนใหญ่ใน Active Directory นั่นเป็นเหตุผลว่าทำไมนโยบายการตรวจสอบขั้นสูง (Premium) ที่ใช้กับ OU ของตัวควบคุมโดเมนจึงมีความสำคัญมาก

ในการตั้งค่า ให้ล็อกอินด้วยชื่อผู้ใช้/รหัสผ่าน ผู้ดูแลโดเมน บนคอนโทรลเลอร์ ให้เปิดตัวแก้ไขการจัดการนโยบายกลุ่ม (Group Policy Management Editor) และแก้ไข GPO ที่ใช้กับคอนโทรลเลอร์โดเมน (ตัวอย่างเช่น นโยบายคอนโทรลเลอร์โดเมนเริ่มต้น หรือ GPO ใหม่ที่เฉพาะเจาะจงสำหรับความปลอดภัย)

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

หมวดหมู่ย่อยที่สำคัญบางส่วน ได้แก่: การตรวจสอบความถูกต้องของข้อมูลประจำตัวผู้เข้าตรวจสอบ (เหตุการณ์ 4776)รวมถึงตัวเลือกการตรวจสอบการจัดการบัญชีต่างๆ (การสร้างและการลบบัญชีทีม กลุ่มการแจกจ่าย และกลุ่มความปลอดภัยด้วยเหตุการณ์ต่างๆ เช่น 4741, 4743, 4728, 4729, 4730, 4732, 4733, 4756, 4757, 4758 และ 4726) การตรวจสอบการเปลี่ยนแปลงบริการไดเร็กทอรี (5136) การตรวจสอบส่วนขยายระบบรักษาความปลอดภัย (7045) และการเข้าถึงบริการไดเร็กทอรี (4662)

หลังจากใช้การเปลี่ยนแปลงใน GPO แล้ว การอัปเดตจะถูกบังคับ gpupdate บนตัวควบคุมโดเมน และตรวจสอบใน Event Viewer ภายใต้บันทึกความปลอดภัย ว่ามีการสร้างรหัสเหตุการณ์ใหม่ถูกต้องหรือไม่ หากไม่แน่ใจ ให้ใช้คำสั่งนี้ auditpol.exe /get /category:* ฟังก์ชันนี้จะแสดงสถานะจริงของการตรวจสอบขั้นสูงในระดับทีม

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

การตรวจสอบ NTLM และเหตุการณ์ 8004

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

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

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

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

การตรวจสอบวัตถุโดเมนและการกำหนดค่า

หากสิ่งที่คุณกังวลคือการรู้ว่าใครเปลี่ยนไป ผู้ใช้ กลุ่ม คอมพิวเตอร์ หรือวัตถุอื่นๆ ใน Active Directoryนอกเหนือจากนโยบายการตรวจสอบแล้ว จะต้องกำหนดค่า SACL ภายในไดเร็กทอรีเองด้วย โดยปกติจะทำได้จากคอนโซล Active Directory Users and Computers โดยการเปิดใช้งานคุณสมบัติขั้นสูงเพื่อดูแท็บความปลอดภัย

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

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

สามารถใช้วิธีการเดียวกันนี้กับวัตถุประเภทต่างๆ ได้ เช่น กลุ่ม คอมพิวเตอร์ บัญชีบริการที่มีการจัดการ (msDS-GroupManagedServiceAccount, msDS-ManagedServiceAccount, msDS-DelegatedManagedServiceAccount) และคอนเทนเนอร์สำคัญอื่นๆ ด้วยวิธีนี้ การเปลี่ยนแปลงต่างๆ จะถูกบันทึกไว้ในบันทึกความปลอดภัยของตัวควบคุมโดเมนอย่างเป็นระบบ

มีการใช้ SACL ประเภทเดียวกันเมื่อมีบริการเพิ่มเติมในสภาพแวดล้อม เช่น AD FS หรือ Microsoft Exchangeโดยเฉพาะอย่างยิ่งในองค์กรที่มีการเข้าถึงอินเทอร์เน็ตสูง หรือมีการใช้งานระบบเครือข่ายแบบเฟเดอเรชันอย่างหนัก จะมีคอนเทนเนอร์การกำหนดค่าเฉพาะบางอย่างที่ควรได้รับการตรวจสอบด้วย

การตรวจสอบใน AD FS, AD CS และ Microsoft Entra Connect

บริการเช่น บริการ Active Directory Federation Services (ADFS)Active Directory Certificate Services (AD CS) และ Microsoft Entra Connect ต่างก็อาศัยเหตุการณ์การตรวจสอบเพื่อแสดงภาพรวมที่ครอบคลุมของสถานะข้อมูลประจำตัวและการเข้าถึง โดยแต่ละระบบต้องการการกำหนดค่า GPO และการกำหนดค่าภายในเครื่องที่แตกต่างกันไป

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

เพื่อให้มั่นใจได้ว่าเซ็นเซอร์ที่ทำงานบนเซิร์ฟเวอร์ AD FS สามารถมองเห็นได้อย่างชัดเจนที่สุด ขอแนะนำให้ปรับค่าต่อไปนี้ ระดับการตรวจสอบโดยละเอียด โดยใช้คำสั่ง Set-AdfsProperties -AuditLevel Verbose ซึ่งจะเพิ่มรายละเอียดของเหตุการณ์ที่สร้างขึ้นสำหรับบริการนั้น

ในกรณีของ AD CS จะมีการสร้าง GPO เฉพาะสำหรับเซิร์ฟเวอร์ใบรับรอง เพื่อเปิดใช้งานการตรวจสอบบริการออกใบรับรองภายในนโยบายการตรวจสอบขั้นสูง รวมถึงบันทึกความสำเร็จและความล้มเหลว นอกจากนี้ยังสามารถใช้เครื่องมือนี้ได้อีกด้วย certutil ในการปรับตัวกรองการตรวจสอบ CA โดยใช้คำสั่งต่างๆ เช่น certutil -setreg CA\AuditFilter 127 และรีสตาร์ทบริการใบรับรอง

ในขณะเดียวกัน บนเซิร์ฟเวอร์ของ ไมโครซอฟต์ เอ็นเตอร์ คอนเน็กต์ (เดิมคือ Azure AD Connect) แนวทางปฏิบัติขั้นต่ำที่แนะนำโดยทั่วไปคือการเปิดใช้งานการตรวจสอบการเข้าสู่ระบบ/ออกจากระบบ เพื่อดูว่าใครเข้าถึงโหนดสำคัญเหล่านี้ในกระบวนการซิงโครไนซ์ข้อมูลประจำตัวและเมื่อใด ซึ่งสามารถทำได้ผ่าน Group Policy Objects (GPOs) โดยการเปิดใช้งานหมวดหมู่ย่อยการตรวจสอบการเข้าสู่ระบบขั้นสูงที่เกี่ยวข้อง

การตรวจสอบการเข้าถึงไฟล์และโฟลเดอร์ด้วย GPO ระดับโลกและ SACL

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

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

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

แนวทางนี้มีข้อดีคือ แม้ว่าจะไม่ได้กำหนด SACL ไว้อย่างชัดเจนในแต่ละโฟลเดอร์หรือไฟล์ก็ตาม การตรวจสอบทั่วโลก ระบบจะจัดการการบันทึกข้อมูลที่จำเป็นทั้งหมด สิ่งที่เหลืออยู่คือการอัปเดตนโยบายด้วยคำสั่ง `gpupdate /force` บนเซิร์ฟเวอร์ไฟล์ และตรวจสอบใน Event Viewer ว่าการดำเนินการกับเอกสารได้รับการบันทึกตามที่คาดไว้หรือไม่

ในระดับเวิร์กสเตชัน หลายคนสงสัยว่าจะตรวจสอบโฟลเดอร์ เช่น C:\Test บนเครื่องทั้งหมดในโดเมนได้อย่างไร วิธีที่สะอาดที่สุดไม่ใช่การตรวจสอบทีละเครื่อง แต่เป็นการตรวจสอบโดยรวม กำหนด SACL ผ่าน GPO หรือใช้เทมเพลตและสคริปต์ด้านความปลอดภัยที่ใช้สิทธิ์การตรวจสอบเหล่านั้นในวงกว้าง หลีกเลี่ยงการใช้บัญชีผู้ดูแลระบบโดเมนสำหรับงานประจำในแต่ละเวิร์กสเตชัน

การติดตามการเปลี่ยนแปลงใน GPO และเครื่องมือต่างๆ เช่น Semperis DSP

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

เครื่องมืออย่าง Semperis Directory Services Protector (DSP) อาศัยเหตุการณ์การตรวจสอบของ Active Directory เพื่อให้ข้อมูล ภาพรวมที่ชัดเจนของการเปลี่ยนแปลง GPOตัวอย่างเช่น พวกเขาสามารถตรวจจับได้ว่ามีใครบางคนที่มีสิทธิ์แก้ไข GPO ใช้ยูทิลิตี้อย่าง SharpGPOAbuse เพื่อเพิ่มผู้ใช้เข้าไปในกลุ่มผู้ดูแลระบบในเครื่องโดยไม่ให้ใครรู้ ผ่านนโยบายโดเมนเริ่มต้นหรือไม่

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

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

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

สถานการณ์แบบไฮบริด: การรวมศูนย์การตรวจสอบไว้ใน AWS ด้วย CloudWatch และ OpenSearch

ในสภาพแวดล้อมแบบไฮบริดที่ส่วนหนึ่งของโครงสร้างพื้นฐาน Active Directory อยู่ภายในองค์กรและอีกส่วนหนึ่งอยู่ในระบบคลาวด์ เป็นเรื่องปกติที่จะมองหา... แพลตฟอร์มส่วนกลางสำหรับการรวบรวมและวิเคราะห์เหตุการณ์การตรวจสอบตัวอย่างทั่วไปคือการใช้บริการของ AWS เช่น Managed Microsoft AD, Amazon FSx สำหรับ Windows File Server และ Amazon OpenSearch

ในสถานการณ์เหล่านี้ คุณจะเริ่มต้นด้วย Active Directory forest ในเครื่อง (โดยมี domain controller บางตัวอยู่ใน Amazon EC2 หากคุณขยายไปยังระบบคลาวด์) บวกกับ AWS managed directory (Managed Microsoft AD) และ file volume ใน Amazon FSx ที่กำหนดค่าให้ทำงานร่วมกับ directory นั้น

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

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

เมื่อข้อมูลอยู่ใน CloudWatch Logs แล้ว ส่งต่อบันทึกเหล่านั้นไปยัง Amazon OpenSearch Serviceโดยปกติแล้ว ขั้นตอนนี้จะดำเนินการโดยใช้ฟังก์ชัน AWS Lambda ที่สร้างขึ้นโดยอัตโนมัติ (โดยมีชื่อเช่น LogsToElasticSearch_whatever) ซึ่งทำหน้าที่เป็นขั้นตอน ETL: ฟังก์ชันนี้จะรับเหตุการณ์ ประมวลผล แยกข้อมูลที่เกี่ยวข้อง (ใคร เมื่อไหร่ อะไร ที่ไหน) และจัดทำดัชนีใน OpenSearch ในรูปแบบที่เป็นเนื้อเดียวกันและเหมาะสมที่สุด

ฟังก์ชันนี้มักต้องการการปรับแต่งเพิ่มเติมเล็กน้อย: การอ่านค่า ไฟล์การกำหนดค่า JSON ซึ่งอธิบายวิธีการแมปเหตุการณ์ประเภทต่างๆ ของ Windows (ซึ่งมาในรูปแบบ XML) กับฟิลด์ของดัชนีสุดท้าย (เช่น @source, @action, @timestamp, user, source machine เป็นต้น) และกำจัดข้อมูลที่ซ้ำซ้อนซึ่งไม่เป็นประโยชน์ต่อการตรวจสอบหรือการปฏิบัติตามกฎระเบียบ

การแสดงภาพบันทึกการตรวจสอบด้วยแดชบอร์ด OpenSearch

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

ขั้นตอนพื้นฐานประกอบด้วยการกำหนด รูปแบบดัชนี (ตัวอย่างเช่น auditlog*) โดยระบุฟิลด์เวลา @timestamp จากนั้นสร้างแผนภูมิวงกลม แผนภูมิแท่ง แผนภูมิเส้น หรือตาราง ขึ้นอยู่กับประเภทของการวิเคราะห์ที่คุณต้องการดำเนินการ ในแผนภูมิวงกลมทั่วไป คุณสามารถแบ่งส่วนตามแหล่งที่มา (@source.keyword) และประเภทการกระทำ (@action.keyword) เพื่อดูว่าแหล่งที่มาใดสร้างกิจกรรมมากที่สุดและเป็นกิจกรรมประเภทใด

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

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

อย่างไรก็ตาม เนื่องจากบริการเหล่านี้ไม่ได้ให้บริการฟรี จึงควรวางแผนการใช้ทรัพยากรที่สร้างขึ้นอย่างรอบคอบ (โดเมน Managed AD, FSx, OpenSearch, อินสแตนซ์ EC2, ฟังก์ชัน Lambda เป็นต้น) เพื่อให้สามารถลบออกได้เมื่อการทดสอบแนวคิดเสร็จสมบูรณ์ หลีกเลี่ยงค่าใช้จ่ายที่ไม่จำเป็น.

การปรับปรุงที่สำคัญ: แสดงข้อมูลการเข้าสู่ระบบครั้งล่าสุดและข้อผิดพลาดในการเข้าสู่ระบบ

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

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

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

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

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

สุดท้ายแล้ว ทุกสิ่งที่เราได้เห็นล้วนเกี่ยวข้องกับแนวคิดเดียวกัน: กำหนดสิ่งที่คุณต้องการตรวจสอบให้ชัดเจน ตั้งค่าให้สม่ำเสมอโดยใช้ Local Group Policy หรือ GPO และรวมศูนย์การวิเคราะห์เหตุการณ์ด้วยการกำหนดค่านโยบายการตรวจสอบขั้นสูงอย่างเหมาะสม การออกแบบ SACL ที่ดีบนวัตถุและระบบไฟล์ เครื่องมืออย่าง Defender for Identity หรือโซลูชันประเภท DSP ที่คอยตรวจสอบการเปลี่ยนแปลง และแพลตฟอร์มอย่าง AWS OpenSearch ที่รวมศูนย์บันทึกข้อมูล จะทำให้เกิดความสมดุลที่เหมาะสมระหว่างการมองเห็น ประสิทธิภาพ และความสามารถในการตอบสนองต่อเหตุการณ์อย่างแท้จริง