ตั้งค่า Cloud ไม่ระวัง ระวังบิลค่าใช้จ่ายพุ่ง! วิธีตรวจสอบความปลอดภัย AWS สำหรับมือใหม่

ทำไมการตั้งค่า Cloud ที่หละหลวมถึงกลายเป็นเรื่องเงิน?

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

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

การตรวจเช็คฐานข้อมูลที่เปิดสาธารณะทำได้ง่ายๆ ด้วยคำสั่งนี้ใน Terminal (หน้าจอพิมพ์คำสั่ง):

# ตรวจสอบฐานข้อมูลทั้งหมดที่ตั้งค่าเป็นสาธารณะ
aws rds describe-db-instances --query 'DBInstances[?PubliclyAccessible].DBInstanceIdentifier'

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

อันตรายของ Security Groups ที่เปิดกว้างเกินไป

Security Groups (กำแพงป้องกันที่คอยคัดกรองคนเข้าออกเครื่องเซิร์ฟเวอร์) เปรียบเสมือนด่านตรวจคนเข้าเมือง ถ้าคุณตั้งค่าให้เปิดรับทุกอย่างจากทุกที่ หรือที่เรียกว่า 0.0.0.0/0 คุณกำลังเปิดช่องให้ใครก็ได้ในโลกเข้ามาเคาะประตูบ้านคุณ การเปิดพอร์ตสำหรับเว็บไซต์ (80/443) เป็นเรื่องปกติ แต่การเปิดพอร์ตสำหรับรีโมทเครื่อง (SSH/RDP) หรือฐานข้อมูลให้คนทั้งโลกเห็น คือจุดเริ่มต้นของหายนะ

เหตุการณ์ที่พบบ่อยที่สุดคือเมื่อแฮกเกอร์เข้ามาได้ พวกเขาจะแอบใช้ทรัพยากรเครื่องคุณไปขุด Cryptocurrency (เงินดิจิทัล) ผลที่ตามมาคือใบแจ้งหนี้ค่าใช้จ่ายที่พุ่งสูงขึ้นแบบผิดปกติในสิ้นเดือน บริษัทมักจะรู้ตัวว่าโดนเจาะระบบก็ต่อเมื่อเห็นบิลค่าบริการแพงหูฉี่ ไม่ใช่จากระบบเตือนภัยความปลอดภัย นี่คือเหตุผลที่ทีม DevOps (ทีมที่ดูแลทั้งการพัฒนาและการใช้งานระบบ) ต้องมองเรื่องความปลอดภัยเป็นเรื่องเดียวกับเรื่องค่าใช้จ่าย

ลองใช้คำสั่งนี้เพื่อเช็คว่ามีด่านตรวจไหนที่เปิดกว้างเกินไปบ้าง:

# ค้นหา Security Groups ที่เปิดรับทุกไอพี (0.0.0.0/0)
aws ec2 describe-security-groups --filters Name=ip-permission.cidr,Values='0.0.0.0/0'

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

ความเสี่ยงที่มองไม่เห็นจาก IAM Role

IAM Role (บัตรผ่านหรือสิทธิ์ในการเข้าถึงทรัพยากรต่างๆ) ที่ตั้งค่าแบบ Wildcard (อนุญาตให้ทำทุกอย่างได้ด้วยเครื่องหมายดอกจัน *) เปรียบเหมือนการให้กุญแจมาสเตอร์คีย์กับพนักงานฝึกงาน ถึงแม้จะไม่มีอะไรเกิดขึ้นในวันนี้ แต่ถ้าเกิดมีการทำกุญแจหลุดมือไปเพียงดอกเดียว ผู้บุกรุกจะสามารถสั่งรันเครื่องเซิร์ฟเวอร์จำนวนมหาศาลในหลายๆ ภูมิภาคได้ทันที

ความเสี่ยงนี้เป็นสิ่งที่เรียกว่า Unpriced Tail Risk (ความเสี่ยงที่ยังไม่มีราคาจนกว่าจะเกิดเรื่อง) เพราะมันไม่เสียค่าใช้จ่ายใดๆ ในสภาวะปกติ แต่ถ้ามันระเบิดขึ้นมา ค่าเสียหายจะมหาศาลมาก การแก้ไขทำได้ง่ายและเกือบจะฟรี แค่คุณจำกัดสิทธิ์ให้เหลือเท่าที่จำเป็นต้องใช้จริงๆ เช่น ให้สิทธิ์อ่านข้อมูลเฉพาะ Bucket (พื้นที่เก็บไฟล์) ที่เกี่ยวข้องเท่านั้น ไม่ใช่ให้สิทธิ์ครอบคลุมทั้งระบบ

หลักการง่ายๆ คือการทำ Least Privilege (ให้สิทธิ์เท่าที่จำเป็นต้องใช้) หากคุณพบ Role ที่มีสิทธิ์ AdministratorAccess หรือมีเครื่องหมาย * ในส่วนของ Action หรือ Resource ให้รีบแก้ไขให้เป็นสิทธิ์ที่เจาะจงมากขึ้นทันทีครับ

สรุป: การรวมพลังระหว่างทีม Security และ FinOps

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

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

1. รันคำสั่งเช็ค Public RDS และไล่ปิดให้หมดหากไม่จำเป็นจริงๆ
2. ตรวจสอบ Security Groups ที่เปิด 0.0.0.0/0 แล้วจำกัดให้เหลือแค่ที่จำเป็น
3. ลิสต์รายชื่อ IAM Roles ที่มีสิทธิ์กว้างเกินไป แล้วทยอยปรับให้เป็นสิทธิ์แบบเจาะจง
4. ตั้งค่า Cost Anomaly Alert (ระบบเตือนเมื่อค่าใช้จ่ายพุ่งผิดปกติ) ในแต่ละภูมิภาคเพื่อใช้เป็นสัญญาณเตือนภัยล่วงหน้า

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

ที่มา: Publicly Accessible RDS and Unrestricted Security Groups: The Cost Side of Risky Cloud Config — DEV Community