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

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

• Identity and access management (IAM) — role และ policy ที่ให้สิทธิ์เกินจำเป็น, credential ที่ไม่ได้ใช้แล้ว, MFA ที่อ่อนหรือไม่มี และ trust relationship ที่ให้สิทธิ์เกินกว่าที่ใครตั้งใจ บน cloud นั้น identity คือ แนวเขตป้องกัน credential ที่มีสิทธิ์เกินตัวถ้าโดนยึด ก็ข้ามทุก network control ที่คุณมีได้หมด
• การตั้งค่าเครือข่าย — บริการที่เปิดออกสู่อินเทอร์เน็ตทั้งที่ไม่ควร, security group และ firewall rule ที่กว้างเกินกว่าที่ workload ต้องใช้ และการไม่แบ่ง segment ระหว่าง environment
• การเปิดเผยของ storage — bucket และ blob ที่เป็น public, access policy บน object storage ที่หละหลวมเกินไป และข้อมูลที่ถูกแชร์กว้างเกินกว่าความอ่อนไหวของมัน
• Logging และ monitoring — audit logging เปิดอยู่ในจุดที่จำเป็นหรือเปล่า, log ได้รับการป้องกันไม่ให้ถูกแก้ไขไหม และถ้ามีเหตุกำลังเกิดขึ้นจริง จะมีใครสังเกตเห็นหรือเปล่า
• Encryption — ข้อมูลทั้งตอน at rest และ in transit อะไรถูกเข้ารหัส อะไรไม่ถูก และ key ถูกจัดการอย่างไร
• ความปลอดภัยของ API — ทั้ง management API และ application API ที่ระบบ cloud ของคุณเปิดออกมา และ access control ที่คุมอยู่ด้านหน้า

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

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

1. กำหนดขอบเขตของ environment — เราวางแผนที่ของ cloud ร่วมกับคุณ ว่าใช้ผู้ให้บริการเจ้าไหนบ้าง มี account หรือ subscription ใด บริการใดที่ใช้งานอยู่ และอะไรสำคัญที่สุดต่อธุรกิจ checklist ของงานตกลงกันตรงนี้ ก่อนเริ่ม review
2. เข้าถึงและทำ configuration review — เราเข้าถึง environment แบบ read-level แล้วไล่ตรวจการตั้งค่าอย่างเป็นระบบตาม checklist ที่ตกลงกันไว้ ทั้ง IAM, เครือข่าย, storage, logging, encryption และ API control โดยเทียบกับ CIS Benchmarks ของผู้ให้บริการที่คุณใช้ และแนวทาง security best practice ของผู้ให้บริการเอง
3. การทดสอบแบบเจาะจง — จุดไหนที่ finding ชี้ว่ามีการเปิดเผยจริง ทั้งบริการที่เข้าถึงได้ policy ที่หละหลวม หรือ store ที่เปิดออกมา เราจะเข้าไปยืนยัน เพื่อให้รายงานแยกได้ว่าอันไหนเป็นแค่ความต่างบนกระดาษ กับอันไหนเป็นจุดอ่อนที่ผู้โจมตีใช้ได้จริง
4. รายงานผล — finding เขียนออกมาพร้อมระดับความรุนแรง หลักฐาน และแนวทางแก้ไขที่ผูกกับ environment ของคุณ พร้อม executive summary สำหรับผู้บริหาร
5. Retest — หลังทีมคุณแก้เสร็จ เราตรวจซ้ำทุก finding แล้วอัปเดตรายงานให้สะท้อนสิ่งที่ปิดไปแล้ว

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

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

• Executive summary — ภาพความเสี่ยงระดับธุรกิจ ให้ผู้บริหารและ auditor อ่านต่อได้
• Finding จัดตาม Risk Level — แต่ละประเด็นให้ระดับ Critical, High, Medium หรือ Low เพื่อจัดลำดับการแก้ไขได้อย่างเป็นกลาง
• ขั้นตอนการทำซ้ำและ POC เมื่อมี — สำหรับจุดที่ยืนยันการเปิดเผยได้ ระบุขั้นตอนที่แสดงปัญหานั้นได้ชัด ๆ ส่วนความต่างของการตั้งค่า ระบุค่าที่ตั้งผิดและตำแหน่งที่จะไปเจอ
• แนวทางแก้ไข — วิธีแก้ที่ปฏิบัติได้จริง ผูกกับ environment และผู้ให้บริการของคุณ ไม่ใช่ boilerplate ทั่ว ๆ ไป
• Retest ยืนยันผล — finding ถูกตรวจซ้ำหลังคุณแก้ แล้วรายงานอัปเดตให้สะท้อนรายการที่ปิดไปแล้ว

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

การประเมินนี้ทีมภายในของเราลงมือเอง ถือใบรับรองในวงการอย่าง OSCP, OSCE, CREST CRT, CREST CPSA และ GIAC GREM ที่ได้มาจากการสอบภาคปฏิบัติอย่างเข้มข้น พื้นฐานสาย offensive security ชุดเดียวกันนี้ก็ส่งต่อเข้ามาในงาน review ด้วย เราประเมินการตั้งค่าในมุมที่ผู้โจมตีจะเอาไปใช้ ไม่ใช่แค่ไล่ติ๊กตาม checklist ดูใบรับรองทั้งหมดที่ทีมถือ

มาตรฐานที่ใช้

การตรวจนี้เทียบกับ CIS Benchmarks ของผู้ให้บริการที่เกี่ยวข้อง ซึ่งเป็น hardening baseline ที่ชุมชนช่วยกันดูแลสำหรับ AWS, Azure และ GCP ควบคู่ไปกับแนวทาง well-architected และ security best practice ของผู้ให้บริการแต่ละเจ้า นี่คือแหล่งอ้างอิงที่ทีม cloud ของคุณใช้งานอยู่แล้ว finding เลยแมปตรงเข้ากับสิ่งที่ต้องลงมือทำได้ทันที

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