developersIO
การดำเนินการด้านความปลอดภัยบน AWS: วิธีการใช้งาน Secure Account

การดำเนินการด้านความปลอดภัยบน AWS: วิธีการใช้งาน Secure Account

แนะนำวิธีการตั้งค่าสภาพแวดล้อม AWS ให้ปลอดภัยและวิธีการดำเนินการอย่างละเอียด รวมถึงการตั้งค่าลับเฉพาะที่ผู้อ่านทุกท่านสามารถนำไปใช้ได้
AWSClassmethod ThailandThai LanguageAmazon GuardDutyAWS Security Hub
FacebookHatena blogX
2025.10.21

บทความนี้แปลมาจากบทความภาษาญี่ปุ่นที่ชื่อว่า [安全なAWSセキュリティ運用ナレッジ2022]セキュアアカウントの使い方 โดยเจ้าของบทความนี้คือ คุณ อุสุดะ เคสึเกะ

สวัสดีครับ ผม อุสุดะ ครับ ทุกคนใช้ AWS อย่างปลอดภัยกันอยู่ไหมครับ?

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

แม้ว่าเนื้อหาในบทความนี้บางส่วนจะเกี่ยวข้องกับบริการของบริษัทเราโดยเฉพาะ ผมเชื่อว่าความรู้ในเรื่องนี้ สามารถนำไปใช้กับ AWS Environment โดยทั่วไปได้เช่นกันครับ

ภูมิหลังเล็กน้อย

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

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

นอกจากการตั้งค่าบัญชี AWS แล้ว เรายังได้กำหนดระบบสนับสนุนอื่นๆ อย่างชัดเจน เช่น "การช่วยกู้คืนเมื่อเกิดการใช้งานที่ไม่ได้รับอนุญาต" และ "การช่วยกู้คืนเมื่อเกิดปัญหา"

Classmethod Members จะมอบความมั่นใจและความปลอดภัยให้คุณมากยิ่งขึ้นด้วย:

  • การตั้งค่าบัญชีที่ปลอดภัย
  • การตรวจจับความเสี่ยงด้านความปลอดภัย
  • การสนับสนุนการกู้คืนเมื่อเกิดการใช้งานที่ไม่เหมาะสม
  • การสนับสนุนการกู้คืนเมื่อเกิดปัญหา

บริษัท Classmethod ได้เปิดตัวบริการออกบัญชีที่ปลอดภัย เพื่อป้องกันหรือลดสาเหตุของ Event ไม่พึงประสงค์ในระบบ cloud ถึง 80% ล่วงหน้า บริการนี้มีมาตรฐานการรักษาความปลอดภัยเป็นบริการพื้นฐาน รวมถึงการสนับสนุนการปรับปรุงการดำเนินงาน, การสนับสนุนทางเทคนิค, และการเพิ่มประสิทธิภาพด้านต้นทุน ด้วยบริการนี้ องค์กรสามารถลดความเสี่ยงด้านความปลอดภัยในสภาพแวดล้อม cloud และใช้บริการ cloud ได้อย่างมีประสิทธิภาพและปลอดภัยมากยิ่งขึ้น

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

สถาปัตยกรรมของ Secure Account

secure-account-architecture-th

แม้จะมีการตั้งค่าต่างๆ มากมาย แต่มาตรฐานหลักที่ใช้ในการตั้งค่าต่างๆ คือ "AWS Foundational Security Best Practices v1.0.0"
ของ AWS Security Hub เราได้ตั้งค่าเพื่อให้เป็นไปตามมาตรฐานนี้โดยรวมครับ

การตรวจสอบติดตามบน AWS

How to use Secure Account-2

บน AWS เกือบทุกการดำเนินการจะทำผ่าน API การบันทึกประวัติการดำเนินการเหล่านี้ทำผ่านบริการ Amazon CloudTrail ส่วนบริการที่ใช้บันทึกประวัติการเปลี่ยนแปลงทรัพยากร AWS ต่างๆ คือ AWS Config บริการทั้งสองนี้ควรเปิดใช้งานเป็นอันดับแรก

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

ใน Secure Account จะมีการตั้งค่าดังต่อไปนี้

  • AWS CloudTrail
    • สร้างและเปิดใช้งาน "บันทึก trail ที่ใช้กับทุกภูมิภาค" ในภูมิภาคสิงคโปร์
    • Event ที่บันทึก:
      • management events (ไม่มีการบันทึก Event ข้อมูล)
    • การเข้ารหัสไฟล์ log ด้วย SSE-KMS:
      • เปิดใช้งาน
    • การตรวจสอบความถูกต้องของไฟล์ log:
      • เปิดใช้งาน
  • AWS Config
    • เปิดใช้งานในทุกภูมิภาค
    • ประเภททรัพยากรที่บันทึก:
      • ทรัพยากรทั้งหมดที่รองรับ
    • รวมทรัพยากรระดับโลก (global resource):
      • เปิดใช้งานเฉพาะสิงคโปร์
    • การเข้ารหัส Delivery Channel ด้วย SSE-KMS:
      • เปิดใช้งาน
  • S3 Bucket
    • ปลายทางการจัดเก็บ log ของ AWS CloudTrail
    • Bucket สำหรับ Delivery Channel ของ AWS Config
    • การเข้ารหัสเป็นค่าเริ่มต้นด้วย SSE-KMS
    • Lifecycle policy ที่เก็บรักษาข้อมูลเป็นเวลา 3 ปี
  • AWS KMS
    • CMK สำหรับ Bucket เก็บข้อมูล CloudTrail / Config
      • ประเภทคีย์: แบบสมมาตร (Symmetric)

มาตรฐาน Security Hub ที่สามารถบรรลุได้ด้วยการตั้งค่านี้มีดังต่อไปนี้

  • [CloudTrail.1] ต้องเปิดใช้งาน CloudTrail และกำหนดค่าด้วยการติดตามแบบหลายภูมิภาคอย่างน้อย 1 รายการ
  • [CloudTrail.2] CloudTrail ต้องเปิดใช้งานการเข้ารหัสข้อมูลที่จัดเก็บ
  • [CloudTrail.4] ต้องตรวจสอบว่าการตรวจสอบความถูกต้องของไฟล์บันทึก CloudTrail เปิดใช้งานอยู่
  • [CloudTrail.5] ต้องตรวจสอบว่า CloudTrail trails ได้รับการผสานรวมกับ Amazon CloudWatch Logs
  • [Config.1] ต้องเปิดใช้งาน AWS Config
  • [S3.2] S3 Bucket ต้องห้ามการเข้าถึงแบบสาธารณะสำหรับการอ่าน
  • [S3.3] S3 Bucket ต้องห้ามการเข้าถึงแบบสาธารณะสำหรับการเขียน
  • [S3.4] S3 Bucket ต้องเปิดใช้งานการเข้ารหัสฝั่งเซิร์ฟเวอร์
  • [S3.5] S3 Bucket ต้องกำหนดให้ใช้ Secure Socket Layer ในการร้องขอ
  • [S3.6] ต้องจำกัดสิทธิ์การเข้าถึง Amazon S3 ที่ให้กับบัญชีผู้ใช้อื่นใน Bucket policy
  • [S3.8] ต้องเปิดใช้งานการตั้งค่าการบล็อกการเข้าถึงแบบสาธารณะของ S3 ในระดับ Bucket

การตั้งค่าการจัดการ trail บน AWS ไม่ต้องปรับแต่งมาก แต่หากต้องการปรับระยะเวลาการเก็บรักษา log สามารถแก้ไข Lifecycle Policy ของ S3 Bucket ที่เกี่ยวข้องได้

การป้องกันการเปิดเผย S3 โดยค่าเริ่มต้น

How to use Secure Account-3

Amazon S3 เป็นบริการจัดเก็บข้อมูลแบบ Object Storage ที่มีการจัดการแบบเต็มรูปแบบ แม้ว่าโดยค่าเริ่มต้น S3 Bucket จะเป็นแบบส่วนตัว แต่มักเกิดอุบัติเหตุที่มีการตั้งค่าให้เป็นสาธารณะโดยไม่ตั้งใจ ทำให้เกิดการรั่วไหลของข้อมูล

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

ใน Secure Account เราได้เปิดใช้งานการบล็อกการเข้าถึงแบบสาธารณะในระดับบัญชี AWS

มาตรฐาน Security Hub ที่สามารถบรรลุได้ด้วยการตั้งค่านี้มีดังต่อไปนี้

  • [S3.1] ต้องเปิดใช้งานการตั้งค่าการบล็อกการเข้าถึงแบบสาธารณะของ S3
  • [S3.2] S3 Bucket ต้องห้ามการเข้าถึงแบบสาธารณะสำหรับการอ่าน
  • [S3.3] S3 Bucket ต้องห้ามการเข้าถึงแบบสาธารณะสำหรับการเขียน
  • [S3.8] ต้องเปิดใช้งานการตั้งค่าการบล็อกการเข้าถึงแบบสาธารณะของ S3 ในระดับ Bucket

หากต้องการใส่ข้อมูลที่ต้องการเผยแพร่สู่ภายนอกใน S3 Bucket ให้ปิดการตั้งค่านี้ และแทนที่ด้วยการจัดการการตั้งค่า Block Public Access ในแต่ละ Bucket แทน

อย่างไรก็ตาม สำหรับเนื้อหาแบบ Static เช่น HTML/CSS/JavaScript สำหรับเว็บ หรือรูปภาพ/วิดีโอ ควรคงการตั้งค่า Block Public Access ของ S3 ไว้ และใช้ Origin Access Identity (OAI) ของ CloudFront ในการเผยแพร่แทน การเปิด S3 Bucket โดยตรงสำหรับการใช้งานแบบนี้ถือเป็นรูปแบบที่ไม่ควรทำ เนื่องจากเป็นการตั้งค่าสิทธิ์ที่ไม่จำเป็น และยังละเมิดมาตรฐานต่อไปนี้

  • [CloudFront.2] การกระจายข้อมูลของ CloudFront ต้องเปิดใช้งาน Origin Access Identity

การเข้ารหัส EBS โดยค่าเริ่มต้น

EBS

เราได้เปิดใช้งานการตั้งค่าการเข้ารหัสแบบค่าเริ่มต้นสำหรับ Amazon EBS ซึ่งเป็น block storage

ในตอนเริ่มใช้งาน Secure Account ตัว encryption key เริ่มต้นจะถูกกำหนดเป็น AWS Managed Key แต่สามารถเปลี่ยนเป็น Customer Master Key (CMK) ที่ลูกค้าสร้างเองได้ การเข้ารหัสพื้นที่เก็บข้อมูลด้วย CMK ทำให้สามารถลบข้อมูลด้วยวิธีการ Cryptographic Erase โดยการลบ encryption key ได้ ลูกค้าสามารถอธิบายการลบข้อมูลออกจาก AWS ด้วยวิธีการ Cryptographic Erase นี้ สำหรับข้อมูลการลบข้อมูลอย่างปลอดภัย โปรดดูที่ "การกำจัดข้อมูลอย่างปลอดภัยบน Cloud" ซึ่งเป็นบทความภาษาญี่ปุ่นของ AWS ญี่ปุ่นที่พูดถึงวิธีกำจัดข้อมูลให้ปลอดภัย (สามารถใช้ Google Translate แปลเป็นภาษาไทยได้ครับ)

นอกจากนี้ ในกรณีที่ต้องจัดการ EBS ที่มีรอบการทำลายข้อมูลต่างกัน (เช่น ในบริการแบบ Multi-tenant ที่แยกเก็บ EBS ตามลูกค้า) การแยก CMK สำหรับแต่ละส่วนจะช่วยให้สามารถทำการเข้ารหัสลบตามวงจรชีวิตได้ ควรออกแบบวงจรชีวิตของข้อมูลก่อนที่จะออกแบบการเข้ารหัส

มาตรฐาน Security Hub ที่สามารถบรรลุได้ด้วยการตั้งค่านี้มีดังต่อไปนี้

  • [EC2.3] EBS volumes ที่ถูกเชื่อมต่อต้องมีการเข้ารหัสในขณะจัดเก็บ
  • [EC2.7] ต้องเปิดใช้งานการเข้ารหัสแบบค่าเริ่มต้นสำหรับ EBS

การเสริมสร้างความแข็งแกร่งของ password policy

IAM

เรากำหนด password policy สำหรับผู้ใช้ IAM ด้วยการตั้งค่าต่อไปนี้

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

มาตรฐาน Security Hub ที่สามารถบรรลุได้ด้วยการตั้งค่านี้มีดังต่อไปนี้

  • [IAM.7] password policy สำหรับผู้ใช้ IAM ต้องมีการตั้งค่าที่เข้มงวด

โดยสามารถเพิ่มความเข้มงวดของนโยบายนี้ให้มากขึ้นได้อีก

เคล็ดลับในการจัดการ ID บน AWS: เมื่อมีการใช้งานบัญชี AWS จำนวนมาก การจัดการผู้ใช้ IAM อาจซับซ้อนยุ่งยาก ดังนั้นควรพิจารณาใช้วิธีการ Jump Account ที่รวมผู้ใช้ IAM ไว้ในบัญชี AWS เดียวแล้วใช้ Switch Role ไปยังบัญชี AWS อื่นๆ หรือพิจารณาใช้ SSO ผ่าน AWS SSO หรือ IDaaS (Identity as a Service) จากบุคคลที่สาม การสร้างผู้ใช้ IAM ให้น้อยที่สุดถือเป็นแนวทาง Best practice

การลบ default VPC

How to use Secure Account-6

เราจะลบ default VPC ที่มีอยู่หนึ่งตัวในแต่ละภูมิภาค

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

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

มาตรฐาน Security Hub ที่สามารถบรรลุได้ด้วยการตั้งค่านี้มีดังต่อไปนี้

  • [EC2.2] Security Group เริ่มต้นของ VPC ต้องห้าม traffic ขาเข้าและขาออก

การเปิดใช้งาน security service + tuning

security-tuning-fix

เราจะเปิดใช้งานบริการด้านความปลอดภัยแบบ Fully Managed ต่างๆ ของ AWS เนื่องจากมีหลายบริการ โดยจะอธิบายทีละบริการครับ

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

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

เนื่องจากบน AWS มีบริการและการตั้งค่าจำนวนมาก ทำให้ยากที่คนจะดูแลได้ทั่วถึง GuardDuty จึงเป็นกลไกที่ยอดเยี่ยมในการตรวจจับความผิดปกติได้ทันที โดยจะทำการเก็บและวิเคราะห์ CloudTrail, VPC Flow Logs, DNS Logs, S3 Data Event Logs และ Kubernetes Audit Logs โดยอัตโนมัติในเบื้องหลัง ซึ่งง่ายและคุ้มค่ากว่าการที่เราต้องเก็บและประมวลผล log เหล่านี้เองหลายเท่า

มาตรฐาน Security Hub ที่สามารถบรรลุได้ด้วยการตั้งค่านี้มีดังต่อไปนี้

  • [GuardDuty.1] ต้องเปิดใช้งาน GuardDuty

เคล็ดลับในการใช้งาน GuardDuty คือการตอบสนองหลังการตรวจจับและการเตรียมการล่วงหน้าสำหรับการตอบสนองนั้น วิธีการดำเนินการที่เฉพาะเจาะจงจะอธิบายในภายหลังพร้อมกับบริการด้านความปลอดภัยอื่นๆ

AWS Security Hub
เป็นบริการที่มีสองฟังก์ชันหลัก คือ การรวบรวม Event ด้านความปลอดภัยบน AWS และการตรวจสอบการตั้งค่าที่อาจเป็นอันตราย โดยเฉพาะฟังก์ชันการตรวจสอบความปลอดภัยนั้นมีประโยชน์มาก ที่ผ่านมาเราได้กล่าวถึงเกณฑ์การตรวจสอบต่างๆ มากมาย ซึ่ง Security Hub จะทำการตรวจสอบเหล่านี้โดยอัตโนมัติ

เราจะเปิดใช้งานในทุกภูมิภาค และเปิดใช้งาน "AWS Foundational Security Best Practices v1.0.0" สำหรับการตรวจสอบความปลอดภัย อย่างไรก็ตาม การตรวจสอบความปลอดภัยบางอย่างอาจทำให้การจัดการซับซ้อน จึงสามารถปิดการใช้งานได้ ใน Secure Account เราได้ปิดการใช้งานรายการต่อไปนี้ พร้อมเหตุผลประกอบ

  • รายการที่เปิดการใช้งาน:
    • [IAM.6] ต้องเปิดใช้งาน Hardware MFA สำหรับผู้ใช้ Root
      • Classmethod ใช้ Software MFA ในการจัดการแทน และมีการแบ่งแยกหน้าที่อย่างเหมาะสม
    • [EC2.8] อินสแตนซ์ EC2 ต้องใช้ IMDSv2
      • แม้ว่า IMDSv2 จะช่วยป้องกันการโจมตีแบบ SSRF แต่เราได้ปิดการใช้งานเนื่องจากความยากในการจัดเตรียมสภาพแวดล้อมที่รองรับ หากมีการทดสอบอย่างเพียงพอและสภาพแวดล้อมรองรับ IMDSv2 ก็สามารถเปิดใช้งานได้
    • [CloudTrail.5] ต้องตรวจสอบว่า CloudTrail trails ได้รับการผสานรวมกับ Amazon CloudWatch Logs
      • โดยปกติการเก็บ CloudTrail log ใน S3 ก็เพียงพอแล้ว การส่งออกไปยัง CloudWatch Logs ช่วยให้สามารถส่งการแจ้งเตือนได้รวดเร็ว หากต้องการใช้งานในลักษณะนี้ก็สามารถเปิดใช้งานได้ โดยทั่วไปหน้าที่นี้มักจะให้ GuardDuty เป็นผู้ดูแล
    • [Config.1] ต้องเปิดใช้งาน AWS Config (เปิดใช้เฉพาะภูมิภาคสิงคโปร์)
      • เงื่อนไขรวมถึงการบันทึกทรัพยากรระดับโลก (global) ซึ่งตั้งค่าไว้เฉพาะในภูมิภาคสิงคโปร์ จึงปิดการใช้งานในภูมิภาคอื่นๆ การบันทึกทรัพยากรระดับ global ในทุกภูมิภาคจะทำให้ log ซ้ำซ้อน จึงตั้งค่าเฉพาะในภูมิภาคหลักเท่านั้น

เนื่องจากเมื่อไม่นานมานี้สามารถรวบรวม Event ด้านความปลอดภัยจากหลายภูมิภาคมาไว้ที่ภูมิภาคเดียวได้แล้ว เราจึงรวมศูนย์ไว้ที่ภูมิภาคสิงคโปร์

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

Amazon Detective
เป็นบริการสำหรับการสืบสวนเมื่อเกิด Event ด้านความปลอดภัย โดยรวบรวมล็อกและให้บริการวิเคราะห์ความสัมพันธ์และการแสดงผลแบบภาพ

เราจะเปิดใช้งานในทุกภูมิภาคครับ

Detective ใช้กลไกการเก็บ log แบบเดียวกับ GuardDuty โดยจะเก็บ CloudTrail, VPC Flow Logs และผลลัพธ์จาก GuardDuty โดยอัตโนมัติ แล้วสร้างความสัมพันธ์ระหว่าง Entity ต่างๆ เช่น IAM User, IAM Role, Temporary Credentials, EC2, IP Address ในฐานข้อมูลแบบกราฟภายใน และแสดงผลออกมาอย่างสวยงาม ผู้ใช้ไม่จำเป็นต้องสืบค้น log หรือนำข้อมูลลง Excel เพื่อหาความสัมพันธ์ด้วยตัวเอง เพราะระบบจะเชื่อมโยงให้โดยอัตโนมัติ

วิธีการใช้งาน Detective มีความสัมพันธ์ใกล้ชิดกับ GuardDuty รายละเอียดจะอธิบายในภายหลัง

IAM Access Analyzer
เป็นบริการที่ตรวจจับการตั้งค่าที่อนุญาตให้ทรัพยากรภายนอกเข้าถึงได้ ไม่ว่าจะเป็น IAM, S3, Lambda และอื่นๆ บริการนี้ฟรี จึงไม่มีเหตุผลที่จะไม่ใช้

แม้จะมีคำว่า IAM ในชื่อ แต่เป็นบริการระดับภูมิภาค (regional) ไม่ได้เป็นระดับโลก (global) แบบ IAM ปกติ

สำหรับ IAM Access Analyzer เราจะเปิดใช้งานในทุกภูมิภาคครับ

ใน Secure Account เราได้ลงทะเบียนกฎการเก็บถาวรสำหรับ IAM ที่ Classmethod ตั้งค่าไว้เพื่อไม่ให้ถูกตรวจจับ

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

การตั้งค่า security alert + การแจ้งเตือน

How to use Secure Account-8

เราจะรวบรวมและจัดรูปแบบการแจ้งเตือนที่ส่งออกมาจากบริการด้านความปลอดภัยต่างๆ แล้วส่งการแจ้งเตือนไปยังอีเมล, Slack หรือระบบอื่นๆ ตามความจำเป็น บริการด้านความปลอดภัยที่เกี่ยวข้องได้แก่ Amazon GuardDuty, AWS Security Hub และ AWS IAM Access Analyzer

แผนภาพด้านบนจะเป็นเพียงภาพรวม แต่ภาพสถาปัตยกรรมโดยละเอียดจะอยู่ข้างล่างนี้ครับ

How to use Secure Account-9

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

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

เราจัดรูปแบบโดยเน้นประเด็นต่อไปนี้

  • ใส่ระดับความเร่งด่วนในหัวข้อ
  • อธิบายสิ่งที่ควรทำเป็นภาษาไทยไว้ในส่วนแรก
  • ใส่หัวข้อภาษาไทยให้แต่ละรายการ
  • แทรกลิงก์ที่ควรเปิดในลำดับถัดไป

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

ในอดีต การจัดรูปแบบเหล่านี้ส่วนใหญ่ทำผ่าน AWS Lambda แต่เมื่อไม่นานมานี้ AWS StepFunctions ได้รับการพัฒนาให้ดีขึ้นมาก จึงสามารถใช้งานได้โดยไม่ต้องใช้ Lambda กลไกที่ใช้ Lambda แม้จะมีความยืดหยุ่นสูง แต่ก็ต้องดูแลรักษา language library ที่ใช้ ซึ่งอาจไม่เหมาะกับระบบที่ต้องสร้างและส่งมอบ ดังนั้นใน Secure Account เราจึงไม่ใช้ Lambda

ผมจะอธิบายการทำงาน จากซ้าย ของแผนภาพสถาปัตยกรรมด้านบนนะครับ:

เริ่มจากซ้ายสุดคือภูมิภาคอื่นๆ นอกเหนือจากสิงคโปร์ Security Hub สามารถรวมข้อมูลข้ามภูมิภาคได้จึงใช้ฟังก์ชันนั้นในการส่งไปยังภูมิภาคสิงคโปร์ ส่วน GuardDuty และ Access Analyzer ไม่มีฟังก์ชันนี้ จึงใช้กฎของ EventBridge ในการส่งไปยัง EventBridge Default Bus ในภูมิภาคสิงคโปร์

ใน EventBridge ของภูมิภาคสิงคโปร์ เราสร้างกฎสำหรับตรวจจับ Event จากทั้งสามบริการ และส่งต่อไปยัง StepFunctions

การจัดรูปแบบโดย StepFunctions มีขั้นตอนดังนี้

How to use Secure Account-10

การกำหนดค่า State Machine มีลักษณะดังต่อไปนี้ คำสั่งจะยาวพอสมควรนะครับ

  {
    "Comment": "A description of my state machine",
    "StartAt": "Choice Service",
    "States": {
      "Choice Service": {
        "Type": "Choice",
        "Choices": [
          {
            "Variable": "$.source",
            "StringEquals": "aws.guardduty",
            "Next": "GuardDuty Sharping"
          },
          {
            "Variable": "$.source",
            "StringEquals": "aws.securityhub",
            "Next": "Choice Severity"
          },
          {
            "Variable": "$.source",
            "StringEquals": "aws.access-analyzer",
            "Next": "AccessAnalyzer Sharping"
          }
        ],
        "Default": "Fail"
      },
      "Choice Severity": {
        "Type": "Choice",
        "Choices": [
          {
            "Or": [
              {
                "Variable": "$.detail.findings[0].Severity.Label",
                "StringEquals": "LOW"
              },
              {
                "Variable": "$.detail.findings[0].Severity.Label",
                "StringEquals": "INFORMATIONAL"
              }
            ],
            "Next": "Severity Low"
          },
          {
            "Variable": "$.detail.findings[0].Severity.Label",
            "StringEquals": "MEDIUM",
            "Next": "Severity Middle"
          },
          {
            "Or": [
              {
                "Variable": "$.detail.findings[0].Severity.Label",
                "StringEquals": "HIGH"
              },
              {
                "Variable": "$.detail.findings[0].Severity.Label",
                "StringEquals": "CRITICAL"
              }
            ],
            "Next": "Severity High"
          }
        ],
        "Default": "Severity None"
      },
      "Severity None": {
        "Type": "Pass",
        "Next": "Security Hub Sharping",
        "Result": "Unknown",
        "ResultPath": "$.SeverityName"
      },
      "Severity Low": {
        "Type": "Pass",
        "Next": "Security Hub Sharping",
        "Result": "Low",
        "ResultPath": "$.SeverityName"
      },
      "GuardDuty Sharping": {
        "Type": "Pass",
        "Next": "EventBridge PutEvents",
        "Parameters": {
          "Subject.$": "States.Format('Severity: {} GuardDuty Security Alert Account: {}', $.detail.severity, $.detail.accountId)",
          "Message.$": "States.Format('The following threat was detected.\\nPlease confirm if this was intended.\\nDetection Type: 
  {}\\nDetails: {}\\nRegion: {}', $.detail.type, $.detail.description, $.region)"
        }
      },
      "EventBridge PutEvents": {
        "Type": "Task",
        "Resource": "arn:aws:states:::events:putEvents",
        "Parameters": {
          "Entries": [
            {
              "Detail": {
                "Subject.$": "$.Subject",
                "Message.$": "$.Message"
              },
              "DetailType": "Sharped GuardDuty Findings",
              "EventBusName": "cm-security-alert-aggregator-bus",
              "Source": "custom.securityalert.stepfunctions"
            }
          ]
        },
        "End": true
      },
      "Fail": {
        "Type": "Fail"
      },
      "Security Hub Sharping": {
        "Type": "Pass",
        "Parameters": {
          "Subject.$": "States.Format('Severity: {} Security Hub Security Alert Account: {}', $.SeverityName, $.account)",
          "Message.$": "States.Format('Security Hub detected a security configuration issue.\\nPlease confirm if this was 
  intended.\\nDetection: {}\\nResource Type: {}\\nResource ID: {}\\nDetails: {}\\nRegion: {}', $.detail.findings[0].Title, 
  $.detail.findings[0].Resources[0].Type, $.detail.findings[0].Resources[0].Id, $.detail.findings[0].Description, 
  $.detail.findings[0].Region)"
        },
        "Next": "EventBridge PutEvents"
      },
      "Severity Middle": {
        "Type": "Pass",
        "Next": "Security Hub Sharping",
        "Result": "Medium",
        "ResultPath": "$.SeverityName"
      },
      "Severity High": {
        "Type": "Pass",
        "Next": "Security Hub Sharping",
        "Result": "High",
        "ResultPath": "$.SeverityName"
      },
      "AccessAnalyzer Sharping": {
        "Type": "Pass",
        "Parameters": {
          "Subject.$": "States.Format('IAM Access Analyzer Security Alert Account: {} Resource Type: {}', $.detail.accountId, 
  $.detail.resourceType)",
          "Message.$": "States.Format('The following resource is shared externally.\\nPlease confirm if this is the intended 
  configuration.\\nResource Type: {}\\nResource Name: {}\\nRegion: {}\\nPrincipal: {}', $.detail.resourceType, $.detail.resource, 
  $.detail.region, $.detail.principal)"
        },
        "Next": "EventBridge PutEvents"
      }
    }
  }

สามารถตั้งค่าเพิ่มเติมนอกเหนือจากที่ตัวอย่างให้ได้ครับ

หลังจากจัดรูปแบบ Event แล้ว Event ที่ถูกรวบรวมใน Custom Event Bus จะถูกส่งไปแจ้งเตือนทางอีเมลและ Slack ใน Secure Account การตั้งค่าการแจ้งเตือนจากจุดนี้เป็นต้นไปจะไม่ได้ถูกตั้งค่าไว้เป็นค่าเริ่มต้น เนื่องจากต้องมีการตั้งค่าแยกตามปลายทางการแจ้งเตือน เรามีเทมเพลต CloudFormation เตรียมไว้สำหรับการลงทะเบียนปลายทางการแจ้งเตือนแล้ว ส่วนรายละเอียดขั้นตอนจะอธิบายในภายหลังครับ

สิ่งที่ต้องทำเป็นอันดับแรก

สำหรับทุกท่านที่ได้รับ Secure Account มีสิ่งที่ต้องทำ 2 อย่างเป็นอันดับแรก กรุณาดำเนินการตามนี้ครับ

  • ตั้งค่า MFA สำหรับผู้ใช้ IAM (หรือการตั้งค่าเริ่มต้นสำหรับการจัดการการเข้าถึง)
  • ตั้งค่าการแจ้งเตือนด้านความปลอดภัย

การตั้งค่า MFA สำหรับผู้ใช้ IAM (หรือการตั้งค่าเริ่มต้นสำหรับการจัดการการเข้าถึง)

เมื่อมีการออก Secure Account จะมีการสร้างผู้ใช้ IAM หนึ่งบัญชี โดยค่าเริ่มต้น ผู้ใช้ IAM นี้สามารถเข้าสู่ระบบได้ด้วยชื่อผู้ใช้และรหัสผ่าน (และ ID บัญชี AWS)

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

กรุณาตั้งค่า MFA (การยืนยันตัวตนแบบหลายปัจจัย, Multi-Factor Authentication) สำหรับผู้ใช้ IAM โดยทันที มีอุปกรณ์ MFA หลายประเภท แต่ที่ใช้งานง่ายที่สุดคืออุปกรณ์ MFA เสมือน โปรดดูการตั้งค่าจากข้อมูลอ้างอิงด้านล่าง

https://dev.classmethod.jp/articles/how-to-activate-aws-iam-mfa-on-mobile/

การตั้งค่าการแจ้งเตือนด้านความปลอดภัย

ใน Secure Account บริการด้านความปลอดภัยต่างๆ ได้ถูกเปิดใช้งานไว้แล้ว เมื่อมี Event เกิดขึ้น จะมีการส่งการแจ้งเตือน แต่สำหรับค่าเริ่มต้น ยังไม่ได้ตั้งค่าการลงทะเบียนปลายทางการแจ้งเตือน ดังนั้นกรุณาตั้งค่าให้แน่ใจว่าจะได้รับการแจ้งเตือนด้วยนะครับ

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

หากต้องการส่งการแจ้งเตือนไปยังที่อื่นนอกเหนือจากอีเมลหรือ Slack สามารถสร้างกฎจาก Custom Event Bus ที่กล่าวถึงก่อนหน้านี้ และตั้งค่าปลายทางการแจ้งเตือนตามต้องการ

สำหรับการตั้งค่า Slack App สามารถดูข้อมูลเพิ่มเติมได้จากด้านล่าง

https://dev.classmethod.jp/articles/amazon-guardduty-with-aws-chatbot-to-slack/

สิ่งที่ต้องทำในการปฏิบัติงานด้านความปลอดภัย

บริการด้านความปลอดภัยต่างๆ ของ AWS ไม่ได้จบแค่การเปิดใช้งาน แต่นั่นคือจุดเริ่มต้นครับ

ผมเข้าใจว่ามีหลายท่านที่อาจ "ยังไม่ค่อยเข้าใจเรื่องความปลอดภัย (Security)" แต่ไม่ต้องกังวลครับเพราะ AWS security service ออกแบบมาได้ดีมาก หากท่านเข้าใจเคล็ดลับการใช้งานที่จะอธิบายด้านล่างนี้ จะช่วยให้การรักษาสภาพแวดล้อมที่ปลอดภัยบน AWS ง่ายขึ้น

ขอแจ้งเผื่อไว้ก่อนครับ ว่าการทำตามนี้ไม่ได้รับประกันความปลอดภัย 100% และยังจำเป็นต้องมีมาตรการรักษาความปลอดภัยและการใช้งานสำหรับ application และระบบต่างๆ ที่สร้างขึ้นบน AWS ด้วย ดังนั้นที่นี่จึงไม่ได้ครอบคลุมทุก layer ให้เราทำไปทีละขั้นตอนกันครับ

การปฏิบัติงานด้านความปลอดภัยบน AWS แบ่งเป็น 2 ส่วนใหญ่ๆ

preventive-detective_th

หนึ่งคือ 1. preventive control (การควบคุมเชิงป้องกัน) และอีกอันคือ 2. detective control (การควบคุมเชิงตรวจจับ)

preventive control คือการตรวจสอบล่วงหน้าเพื่อป้องกันไม่ให้เกิดอุบัติเหตุ detective control คือการตรวจจับอุบัติเหตุที่เกิดขึ้นอย่างรวดเร็วและตอบสนอง และ service ที่รองรับแต่ละส่วนคือ สำหรับ preventive control มี AWS Security Hub และ IAM Access Analyzer สำหรับ detective control มี Amazon GuardDuty และ Amazon Detective ซึ่งทั้งหมดนี้จะถูกเปิดใช้งานเป็น default ใน secure account และได้รับการ tuning ให้มีการตั้งค่าที่เหมาะสมครับ

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

เคล็ดลับการใช้งาน AWS Security Hub

Security Hub จะตรวจสอบการตั้งค่าของบริการต่างๆ ในสภาพแวดล้อม AWS เพื่อดูว่ามีการตั้งค่าที่ไม่ปลอดภัยหรือไม่ และหากพบการละเมิดการตรวจสอบ จะมีการแจ้งเตือนด้านความปลอดภัย การปฏิบัติงานพื้นฐานคือการดูการแจ้งเตือนที่เข้ามา แล้วแก้ไขการตั้งค่าที่ไม่ปลอดภัย หรืออนุญาตให้เป็นข้อยกเว้น

รายการสิ่งที่ตรวจสอบถูกระบุไว้ใน "การควบคุมแนวปฏิบัติที่ดีที่สุดด้านความปลอดภัยพื้นฐานของ AWS - AWS Security Hub" เมื่อได้รับการแจ้งเตือน คุณสามารถตรวจสอบรายการที่เกี่ยวข้องกับการตรวจสอบความปลอดภัยนั้นๆ ได้ เอกสารนี้มีข้อมูลต่อไปนี้

  • ระดับความสำคัญ
  • เนื้อหาที่ตรวจสอบ
  • ทำไมถึงอันตราย
  • จะแก้ไขอย่างไร

ผมขอลองยกตัวอย่างเนื้อหาการตรวจสอบหนึ่งรายการ สมมติว่ามีการแจ้งเตือน "[S3.8] ควรเปิดใช้งานการตั้งค่าการบล็อกการเข้าถึงสาธารณะของ S3 ในระดับ Bucket"

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

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

จากนั้นมีการแนะนำลิงก์วิธีการแก้ไขจริง "การบล็อกการเข้าถึงสาธารณะไปยังที่เก็บข้อมูล Amazon S3 - Amazon Simple Storage Service" หาก S3 Bucket ควรมีการบล็อกการเข้าถึงสาธารณะ ให้ใช้วิธีนี้ในการแก้ไข

เมื่อแก้ไขเสร็จแล้ว หลังจากผ่านไปสักพัก คุณจะสามารถตรวจสอบได้ว่าการตรวจสอบความปลอดภัยใน Security Hub กลับมาเป็นปกติ

ในทางกลับกัน บางครั้ง Bucket อาจจำเป็นต้องเปิดเผยต่อสาธารณะ ในกรณีนี้ให้ลงทะเบียนเป็นทรัพยากรยกเว้น การลงทะเบียนยกเว้นทำได้โดยตั้งค่าสถานะเป็น "Suppressed" ในหน้ารายละเอียดทรัพยากรของ Security Hub

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

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

How to use Secure Account-11

เคล็ดลับการใช้งาน IAM Access Analyzer

IAM Access Analyzer ช่วยตรวจจับการตั้งค่าที่อนุญาตให้ทรัพยากรภายนอกเข้าถึงได้ ทั้ง IAM, S3, Lambda และอื่นๆ

เนื่องจากใน AWS ทรัพยากรต่างๆ สามารถอนุญาตการเข้าถึงจากบัญชี AWS อื่นหรือจากภายนอกได้ จึงจำเป็นต้องตรวจสอบว่าการอนุญาตเหล่านี้เหมาะสมหรือไม่

การแจ้งเตือนความปลอดภัยของ IAM Access Analyzer จะแสดงให้เห็นว่า "ทรัพยากรใด" "มาจากที่ใด" และ "ได้รับอนุญาตให้เข้าถึงอะไร" เมื่อเข้าไปดูในหน้าจอ IAM Access Analyzer จะเห็นดังนี้

secure_account_fix_02

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

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

เคล็ดลับการใช้งาน Amazon GuardDuty

GuardDuty ช่วยตรวจจับภัยคุกคามต่างๆ ที่เกิดขึ้นบน AWS การตรวจจับแบ่งเป็น 3 ประเภทหลัก ได้แก่ IAM, EC2 และ S3 โดยแต่ละประเภทจะตรวจจับเนื้อหาดังต่อไปนี้ (เพียงบางส่วน)

  • ประเภท IAM
    • การเข้าสู่ระบบที่ไม่ได้รับอนุญาต
    • การใช้ข้อมูลรับรองที่รั่วไหล
    • การปิดการใช้งาน CloudTrail
  • ประเภท EC2
    • Coin Mining
    • การเชื่อมต่อกับเซิร์ฟเวอร์ C&C [1]
    • การโจมตีแบบ SSH Brute Force (ขาเข้าหรือขาออก)
  • ประเภท S3
    • การเปิดเผย Bucket
    • Tor access [2]

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

  • ประเภท IAM
    • ปิดการใช้งาน credential
  • ประเภท EC2
    • แยก เก็บรักษา และตรวจสอบ EC2
    • สามารถเตรียมการโดยจ้างบริษัทที่เชี่ยวชาญในการตรวจสอบ
  • ประเภท S3
    • จำกัดสิทธิ์การเข้าถึง

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

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

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

https://aws.amazon.com/th/about-aws/whats-new/2022/01/amazon-guardduty-elastic-kubernetes-service-clusters/

เคล็ดลับการใช้งาน Amazon Detective

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

Detective มีลักษณะการใช้งานที่ส่วนใหญ่จะเข้าถึงจากหน้าจอของ GuardDuty ตรวจสอบ incident ในหน้าจอ GuardDuty และเมื่อตัดสินใจว่าจำเป็นต้องตรวจสอบรายละเอียดเพิ่มเติม ก็สามารถเปลี่ยนไปได้โดยใช้ปุ่ม "Investigate with Detective" ตามภาพด้านล่างครับ

secure_account_fix_01

  • ในตัวอย่างข้างบน ใน GuardDuty --> Findings เราคลิกไปที่ชื่อของ Incident หน้าต่างข้างขวาจะแสดงขึ้นมา โดยเราสามารถกด Investigate with Detective ได้

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

How to use Secure Account-14

ราสามารถตรวจสอบประวัติการ execute API ที่เกี่ยวข้องกับแต่ละ resource ในสถานะที่รวบรวมแล้ว และยังสามารถใส่ filter ได้ด้วยครับ วิธีนี้เราจะสามารถตรวจสอบได้ว่าผู้โจมตีได้ execute API อะไรบ้าง และขอบเขตของผลกระทบมีมากน้อยแค่ไหน

สามารถดูเพิ่มเติมที่ด้านล่างสำหรับขั้นตอนตั้งแต่การตรวจจับจนถึงการตอบสนองต่อ Incident

https://aws.amazon.com/th/about-aws/whats-new/2022/01/amazon-guardduty-ec2-instance-credentials-aws-account/?nc1=f_ls

เคล็ดลับอื่นๆ สำหรับการปฏิบัติงานด้านความปลอดภัย

จนถึงตอนนี้ ผมได้สรุปวิธีการปฏิบัติงานสำหรับบริการด้านความปลอดภัยต่างๆ แล้ว แต่ในความเป็นจริง ยังมีสถานการณ์อีกมากมายบน AWS ที่เราต้องพิจารณาด้านความปลอดภัย อันดับแรก ให้ทำความเข้าใจความรับผิดชอบด้านความปลอดภัยที่ผู้ใช้ AWS ต้องดำเนินการจาก AWS Shared Responsibility Model

จากนั้น ให้ทำความเข้าใจเรื่อง security best practice และ security pillar of the Well-Architected Framework ครับ

โดยเฉพาะอย่างยิ่ง ในบทความนี้ได้กล่าวถึงการ operate security ที่มุ่งเน้นการใช้ประโยชน์จาก security service เป็นหลัก แต่อย่าลืมว่าก่อนหน้านั้นเราได้มีการจัดการ IAM และ access control อยู่ ตามที่ระบุไว้ใน best practice และ security pillar ด้าน security มีหลักการของ least privilege อยู่ ต้องระมัดระวังและใส่ใจเรื่อง access control อยู่เสมอ อย่างไรก็ตาม ควรตระหนักด้วยว่ามี Security Hub และ IAM Access Analyzer เป็นกลไกที่ช่วยเสริมเรื่องนี้ เราไม่จำเป็นต้องกังวลมากเกินไปครับ

มีบริการมากมายที่ช่วยปรับปรุงความปลอดภัยของแอปพลิเคชันที่สร้างบน AWS AWS WAF ช่วยปกป้องแอปพลิเคชันเว็บจากการโจมตี Systems Manager / Secrets Manager ช่วยจัดการข้อมูลที่เป็นความลับอย่างปลอดภัย และ CloudFormation ช่วยป้องกันข้อผิดพลาดและปรับใช้สภาพแวดล้อมได้อย่างรวดเร็ว

เราใช้ประโยชน์จากกลไกที่แสนสะดวกของ AWS ให้เต็มที่กันครับ

คำถามที่พบบ่อย

หลังจากติดตั้งการแจ้งเตือน Slack Security Hub ตรวจพบ "[SecretsManager.1] ต้องเปิดใช้งาน auto-rotation สำหรับข้อมูลลับใน Secrets Manager" ควรทำอย่างไร?

การตรวจพบนี้เกิดขึ้นเมื่อ EventBridge ลงทะเบียนข้อมูลรับรองโดยอัตโนมัติใน Secrets Manager เมื่อผู้ใช้ลงทะเบียน Token สำหรับการแจ้งเตือน Slack การเก็บข้อมูลรับรองใน Secrets Manager ถือเป็น Best practice

ข้อมูลรับรองบางประเภทแนะนำให้มีการ rotation เป็นระยะ และรายการ Security Hub นี้มีไว้เพื่อตรวจจับสิ่งนี้ สำหรับ Slack token ที่เป็นเป้าหมายในครั้งนี้ คุณต้องพิจารณาว่าควรดำเนินการหรือไม่ตามสภาพแวดล้อมของคุณ ตัวเลือกมี 2 อย่างคือ จะดำเนินการตาม หรือยอมรับเป็นข้อยกเว้นเฉพาะและตั้งค่าสถานะรายการที่เกี่ยวข้องใน Security Hub เป็น "Suppressed"

หากคุณสร้าง Slack App ตามการตั้งค่าของบริษัทเรา จะมีเพียงสิทธิ์ chat:write เท่านั้นที่ถูกผูกไว้ ซึ่งหมายความว่าสามารถโพสต์ได้แต่ไม่สามารถอ่านได้ คุณควรพิจารณาว่านี่เป็นความเสี่ยงในระดับใด

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

อนึ่ง มีคำอธิบายเกี่ยวกับวิธีการหมุนเวียนใน "Token rotation | Slack" ซึ่งคุณสามารถใช้สิ่งนี้เพื่อเตรียม Lambda ของคุณเองเพื่อให้เป็นไปตามข้อกำหนดของ Security Hub ได้

จะจัดการความปลอดภัยของบัญชี AWS หลายบัญชีพร้อมกันได้อย่างไร?

กลไกที่แนะนำในครั้งนี้สามารถทำงานได้กับบัญชี AWS เดี่ยว แต่ในทางกลับกัน อาจมีส่วนที่ทำซ้ำซ้อนกัน เช่น การเปิดใช้งานและการรวมศูนย์ CloudTrail/Config และบริการด้านความปลอดภัย รวมถึงการตั้งค่าการแจ้งเตือน

เมื่อจัดการบัญชี AWS จำนวนมากทั้งหมด การใช้โซลูชันที่เหมาะสำหรับการจัดการหลายบัญชี AWS จะช่วยให้จัดการได้มีประสิทธิภาพมากขึ้น

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

https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html

สรุป

บทความนี้ได้แนะนำวิธีการตั้งค่าบัญชี AWS ให้ปลอดภัยและวิธีการปฏิบัติงานอย่างละเอียด

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

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

บทความต้นฉบับ

脚注

  1. เซอร์เวอร์ C&C (Command and Control Server ) เป็นคอมพิวเตอร์ที่ออกคำสั่งไปยังเครื่องที่ถูกบุกรุก เพื่อควบคุมมัลแวร์ในเครื่องหรือสั่งการเครื่องที่ถูกบุกรุก เพื่อขโมยข้อมูล, แพร่กระจายมัลแวร์, ฯลฯ ↩︎

  2. Tor Access หมายถึงการเข้าถึงบริการหรือเว็บไซต์ผ่านเครือข่าย Tor (The Onion Router) ซึ่งเป็นเครือข่ายที่เน้นความเป็นส่วนตัวโดยการส่งข้อมูลผ่านหลายชั้นการเข้ารหัสเพื่อซ่อนตัวตนผู้ใช้ ในบริบทของการรักษาความปลอดภัย S3 bucket เมื่อพบ "Tor access" มักหมายถึงมีผู้เข้าถึง bucket ผ่าน Tor เพื่อซ่อนตัวตน ซึ่งอาจเป็นสัญญาณเตือนของกิจกรรมที่ไม่ได้รับอนุญาต เนื่องจากผู้โจมตีมักใช้ Tor เพื่อหลีกเลี่ยงการตรวจจับขณะเข้าถึงข้อมูลที่ละเอียดอ่อน ↩︎

この記事をシェアする

FacebookHatena blogX

関連記事

[アップデート] EBSボリュームのクローンを高速に作成できるようになりました
のんピ
2025.10.21
Secure Account: การตั้งค่าการแจ้งเตือนความปลอดภัย (Security Alert) ทางอีเมล์
kan-jittapramoulboon
2025.10.21
AWS Backup のバックアップボールトにボールトロックを設定した状態で AWS アカウントを削除するとボールトロックしたデータはどうなりますか？
m.hayakawa
2025.10.21
Amazon Q in Connectセルフサービスで自動回答後、質問内容をもとにエスカレーション先を振り分ける方法
平井裕二
2025.10.21