ระบบรักษาความปลอดภัยของ Amazon GuardDuty [ปลายปี 2022]

ในบรรดาองค์ประกอบด้านความปลอดภัยต่างๆ GuardDuty เป็นบริการตรวจจับภัยคุกคามdasdlasdเหตุการณ์ตามบันทึกและพฤติกรรมที่น่าสงสัยและจัดการเหตุการณ์ต่างๆ เลเยอร์ที่จะปกป้องนั้นค่อนข้างจะเป็นเลเยอร์ AWS แต่เลเยอร์ OS/แอพก็รวมอยู่ในขอบเขตด้วย อย่างไรก็ตาม ตรวจไม่พบ SQLi หรือ XSS เนื่องจากไม่ครอบคลุมเว็บแอปพลิเคชัน ปล่อยให้เป็นหน้าที่ของ WAF

#Classmethod Thailand

#Thai Language

#AWS

#AWS-Thai

#Amazon GuardDuty

Chawish Tilakul

2022.12.09 05:29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ภาพรวมของระบบความปลอดภัย AWS

เป็นการจัดระเบียบทุกอย่างที่อยู่ใน AWS โดยมีองค์ประกอบของความปลอดภัยใน AWS ดังนี้

ลำดับชั้นของ AWS
- การจัดการ IAM
- ความปลอดภัยของเครือข่าย
- การจัดการการตั้งค่า
เลเยอร์ OS/แอพ
- ต่อต้านมัลแวร์
- การจัดการช่องโหว่
- แอปพลิเคชันที่ปลอดภัย
- การป้องกันแอปพลิเคชัน
การจัดการทั่วไป
- การกำกับดูแลและการปฏิบัติตาม
- การดำเนินการบริการ
- การดำเนินการจัดการเ//หตุการณ์ / เหตุการณ์
- สำรอง / กู้คืน

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

ซึ่งในบรรดาองค์ประกอบด้านความปลอดภัยต่างๆ GuardDuty เป็นบริการตรวจจับภัยคุกคามdasdlasdเหตุการณ์ตามบันทึกและพฤติกรรมที่น่าสงสัยและจัดการเหตุการณ์ต่างๆ เลเยอร์ที่จะปกป้องนั้นค่อนข้างจะเป็นเลเยอร์ AWS แต่เลเยอร์ OS/แอพก็รวมอยู่ในขอบเขตด้วย อย่างไรก็ตาม ตรวจไม่พบ SQLi หรือ XSS เนื่องจากไม่ครอบคลุมเว็บแอปพลิเคชัน ปล่อยให้เป็นหน้าที่ของ WAF

ผมจะนำเสนออีกหนึ่งมุมมอง Cyber Security Framwork (CSF) มีทั้งหมด 5 ฟังก์ชันหลัก คือ identification, prevention, detection, response และ recovery GuardDuty มีการตรวจจับ role หลังจากมีการตอบสนองและตรวจสอบแล้ว ซึ่งจำเป็นสำหรับเนื้อหาที่เกี่ยวข้อง
กับการพัฒนาระบบป้องกันที่ตรวจจับข้อมูลที่ไม่พึงประสงค์ โดย AWS Cloud ใช้ MITER ATT&CK Matrix ซึ่งมีประโยชน์มากสำหรับการตอบสนองหลังจากมีอะไรบางอย่างเกิดขึ้น แต่ต้องมีการระบุตัวตนก่อนถึงจะทำการปกป้องได้

GuardDuty Overview

GuardDuty จะทำการเก็บ logs โดยอัตโนมัติบน AWS และมีการใช้งาน Machine Learning และ threat intelligence สำหรับการตรวจสอบพฤติกรรมที่น่าสงสัยว่าจะเป็นภัยต่อตัวระบบ ข้อดีของเซอร์วิสนี้คือสามารถเข้าใช้งานได้ง่าย โดยเฉพาะ 2 อย่างแรกที่ผมได้อธิบายไป

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

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

การจัดการ Event

เราจะพิจารณาการจัดการปฏิบัติการที่เกิดจากเหตุการณ์จริงภายใน GuardDuty

Event type

อันดับแรก ต้องคิดและคาดคะเนในทุกๆรูปแบบที่มีโอกาสจะเกิดขึ้น

GuardDuty จะค้นหาและเรียกร้องการค้นหา จากรายชื่อทั้งหมดด้านล่างนี้

Finding Type - Amazon GuardDuty

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

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

การแจ้งเตือน

เมื่อ GuardDuty ตรวจจับการบุกรุกได้ จะมีการแจ้งเตือน event แต่ GuardDuty ไม่สามารถที่จะแจ้งเตือนโดยตรงได้ แต่สามารถแจ้งเตือนได้ผ่านการเชื่อมต่อจาก event อื่น ที่มีการเกิดขึ้นของการค้นหาใน EventBridge ให้เป็นทริกเกอร์

สำหรับการอ้างอิง ต่อไปนี้ใช้กลไกในการแจ้งเตือนผ่านทางอีเมล SNS จาก EventBridge (เดิมคือ CloudWatch Event Rule)

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

GuardDuty ไม่มีฟังก์ชั่นการจัดการ event/incident (ฟังก์ชั่นการจัดการตั๋ว) ดังนั้นจึงมีประสิทธิภาพที่จะเชื่อมโยงกับระบบเช่น JIRA หรือ Backlog เพียงครั้งเดียวเพื่อเพิ่มตั๋วแล้วแจ้งให้ Slack ทราบ

การสำรวจเบื้องต้น

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

ตัวอย่างเช่น การสื่อสารกับเซิร์ฟเวอร์ C&C และการขุดเหรียญเป็นเหตุการณ์ด้านความปลอดภัยที่อันตรายเกือบ 100% ดังนั้นระบบะตอบสนองด้วยลำดับความสำคัญสูงสุด

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

หากเราได้รับการโจมตี SSH เราสามารถตัดสินได้ว่าไม่มีปัญหาใดเป็นพิเศษตราบเท่าที่มีการป้องกันอย่างถูกต้องและไม่มีอิทธิพลอื่น (ในกรณีนี้ จำเป็นต้องสร้างกลไกที่ไม่ได้รับสิ่งนี้ตั้งแต่แรก)

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

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

จากตัวอย่าง สามารถดูรายละเอียดเพิ่มเติมได้ที CryptoCurrency:EC2/BitcoinTool.B says:

Instance EC2 จะแสดง IP Addresses ที่เชื่อมโยงกับกิจกรรมที่เกี่ยวข้องกับสกุลเงินดิจิทัล

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

เมื่อเรากำหนดระดับของการตอบสนองเบื้องต้นได้แล้ว เราจะดำเนินการตรวจสอบโดยละเอียด ยืนยันขอบเขตของผลกระทบ และดำเนินการตามความเหมาะสม

หลังจากนั้นจะเปลื่ยนไปมากขึ้นอยู่กับสิ่งที่ค้นพบ ดังนั้นเราจะเลือกเฉพาะสิ่งที่ต้องทำคร่าวๆ

ในการตรวจสอบโดยละเอียด ขณะตรวจสอบสถานะของอินสแตนซ์ EC2 เป้าหมาย / IAM / S3 ที่อธิบายไว้ใน Finds และบันทึกโฟลว์ VPC / บันทึก CloudTrail / บันทึกการเข้าถึงข้อมูล S3 ฯลฯ ที่เกี่ยวข้อง ใครเป็นผู้ดำเนินการและจะตรวจสอบอย่างไรและเมื่อใดสำหรับการยืนยันี้น จำเป็นต้องรวบรวมบันทึกเหล่านี้ล่วงหน้า GuardDuty ไม่มีการบันทึกให้กับผู้ใช้ ดังนั้นการเตรียมการล่วงหน้าจึงเป็นสิ่งจำเป็นสำหรับการด้าน้าลึกนี้ การวิเคราะห์บันทึกสามารถยืนยันได้อย่างง่ายดายโดยการสอบถามโดยใช้ Amazon Athena

นอกจากนี้ยังมี Amazon Detective เป็นบริการที่ช่วยให้การสืบสวนเหล่านี้ง่ายขึ้น สามารถดูข้อมูลเพิ่มเติมได้ด้านล่างนี้

[ภาษาญี่ปุ่น]นำเสนอที่ AKIBA.AWS ONLINE #04 โดยมีหัวข้อ "จะตรวจสอบเหตุการณ์ด้านความปลอดภัยของบัญชี AWS ได้อย่างไร ประเด็นสำคัญของการตรวจสอบโดยใช้ Amazon Detective" #AKIBAAWS

การตรวจสอบความสอดคล้องกัน

จะมีการตอบกลับทันทีที่เราสามารถตรวจสอบได้อีกทางหนึ่ง อาจจัดการเรื่องเร่งด่วนอย่างคร่าวๆก่อน และมีการติดต่อเป็นกรณีๆ ไป แต่ทั้งนี้ก็เป็นการอธิบายคร่าวๆสำหรับแต่ละประเภท

EC2 type

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

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

IAM type

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

S3 type

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

การป้องกัน

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

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

สรุป

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