ประเมินความปลอดภัยระบบคลาวด์

ผู้ให้บริการ cloud รายใหญ่ทุกเจ้าทำงานอยู่บนข้อตกลงเดียวกัน คือ shared responsibility model ฝั่งผู้ให้บริการดูแลความปลอดภัยของตัว cloud เอง ทั้ง data center จริง ๆ ตัว hypervisor และเครือข่ายที่อยู่ข้างล่าง ส่วนคุณดูแลสิ่งที่คุณเอาไปวางไว้ ข้างใน ทั้ง identity, การตั้งค่า, ข้อมูล และ workload ของคุณเอง เส้นแบ่งนี้กำหนดว่าใครดูแลอะไร ฝั่งผู้ให้บริการป้องกันตัว cloud เองอยู่แล้ว ส่วนฝั่งคุณขึ้นอยู่กับการตั้งค่าของคุณ เหตุการณ์ข้อมูลรั่วบน cloud ส่วนใหญ่มาจาก misconfiguration ฝั่งลูกค้า เช่น storage bucket ที่เปิดเป็น public, role ที่ให้สิทธิ์เกินจำเป็น หรือ security group ที่เปิดกว้างออกสู่โลกภายนอก การประเมินความมั่นคงปลอดภัยของ cloud คือการตรวจฝั่งที่คุณรับผิดชอบ ครอบคลุมทั้ง Amazon Web Services (AWS), Microsoft Azure และ Google Cloud Platform (GCP)

ทำไม misconfiguration ถึงเป็นปัญหาหลัก เพราะบน cloud ทุกอย่างเป็นแค่ setting ส่วนใน data center แบบเดิม การเปิดฐานข้อมูลออกสู่อินเทอร์เน็ตต้องลงมือทำจริงจัง ทั้งเดินสาย แก้ firewall มีคนสังเกตเห็น แต่บน cloud ใช้แค่ติ๊ก flag เดียวบน resource เดียว ตั้งครั้งเดียวโดยใครสักคนที่กำลังเร่งงาน แล้วมันก็อยู่แบบนั้นเงียบ ๆ จนกว่าจะมีคนไปเจอ console และ API ชุดเดียวกับที่ทำให้สร้างของบน cloud ได้เร็ว ก็ทำให้ตั้งค่าพลาดได้เร็วพอ ๆ กัน แถม default ก็ไม่ได้ปลอดภัยเสมอไป ยิ่งจำนวนบริการ ตัวเลือก และการทำงานร่วมกันเพิ่มขึ้นทุกปี จำนวนการตั้งค่าและความเสี่ยงที่ต้องตรวจสอบก็เพิ่มเร็วจนทีมไล่ดูด้วยมือไม่ไหว การประเมินปิดช่องว่างนี้ด้วยการไล่ดูการตั้งค่าที่สะสมกันมาทั่วทั้ง environment ของคุณอย่างเป็นระบบ การตั้งค่าที่คนละคนตั้งไว้คนละเวลา เอามาวัดกับสิ่งที่ผู้ให้บริการเองบอกว่าการตั้งค่าที่ปลอดภัยควรเป็นแบบไหน

configuration review เป็นคนละงานกับ penetration test pentest ถามว่า "เราเข้าไปได้ไหม" มันพิสูจน์ว่า exploit ได้จริงจากมุมของผู้โจมตี จึงครอบคลุมเฉพาะเส้นทางที่ผู้ทดสอบค้นพบ ส่วน configuration review ถามว่า "ตั้งค่าไว้ถูกต้องหรือเปล่า" มันตรวจจากภายในโดยมองเห็น environment ที่อยู่ในขอบเขต เลยจับการตั้งค่าที่อ่อนแอซึ่งผู้โจมตียังไม่เจอได้ด้วย สองอย่างนี้เสริมกัน review ให้ภาพการตั้งค่าทั่ว environment ที่อยู่ในขอบเขต ส่วนการทดสอบแบบเจาะจงให้หลักฐานยืนยันผลกระทบตรงจุดที่สำคัญ การประเมินของเรารวมทั้งสองอย่างเข้าด้วยกัน

สิ่งที่เราประเมิน

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

นี่คือกลุ่มหลัก ๆ ส่วน checklist จริงไม่ได้ตายตัว ขอบเขตจริงจะปรับให้เข้ากับ environment และข้อจำกัดของคุณ เราเริ่มจากบริการที่คุณใช้งานอยู่จริง แล้วตกลง checklist ร่วมกับคุณ environment ที่สร้างบน managed container ตั้งคำถามคนละแบบกับที่สร้างบน virtual machine และ serverless function

ขั้นตอนการทำงาน

1. 1

   กำหนดขอบเขตของ environment

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

   checklist ของงานตกลงกันตั้งแต่ขั้นนี้ ก่อนเริ่ม review

2. 2

   เข้าถึงและทำ configuration review

   เราเข้าถึง environment แบบ read-level แล้วไล่ตรวจการตั้งค่าอย่างเป็นระบบตาม checklist ที่ตกลงกันไว้ โดยเทียบกับ CIS Benchmarks ของผู้ให้บริการที่คุณใช้ และแนวทาง security best practice ของผู้ให้บริการเอง

   ครอบคลุม IAM, เครือข่าย, storage, logging, encryption และ API control

3. 3

   การทดสอบแบบเจาะจง

   จุดไหนที่ finding ชี้ว่ามีการเปิดเผยจริง ทั้งบริการที่เข้าถึงได้ policy ที่หละหลวม หรือ store ที่เปิดออกมา เราจะเข้าไปยืนยัน

   รายงานแยกได้ว่าอันไหนเป็นแค่ความต่างบนกระดาษ กับอันไหนเป็นจุดอ่อนที่ผู้โจมตีใช้ได้จริง

4. 4

   รายงานผล

   finding เขียนออกมาพร้อมระดับความรุนแรง หลักฐาน และแนวทางแก้ไขที่ผูกกับ environment ของคุณ พร้อม executive summary สำหรับผู้บริหาร

5. 5

   Retest

   หลังทีมคุณแก้เสร็จ เราตรวจซ้ำทุก finding

   อัปเดตรายงานให้สะท้อนสิ่งที่ปิดไปแล้ว

สิ่งที่คุณได้รับ

ทุกรายงานมีอย่างน้อยเท่านี้

ทีมและใบรับรอง

บริการที่เกี่ยวข้อง

การประเมิน cloud ครอบคลุมชั้นการตั้งค่า แต่ workload ที่รันอยู่ข้างบนก็ควรได้รับการตรวจของมันเองด้วย เมื่อ server และแอปพลิเคชันของคุณรันอยู่บน cloud การประเมินนี้จับคู่ได้พอดีกับ penetration test ด้าน infrastructure และ web application การประเมินทำให้แพลตฟอร์มที่ workload ของคุณวางอยู่ปลอดภัย ส่วน pentest เข้าโจมตีตัว workload เอง