การตรวจสอบความปลอดภัยบนคลาวด์
การประเมินความสอดคล้องตามมาตรฐานคลาวด์ การรีวิวการตั้งค่า และ Penetration Testing เฉพาะแพลตฟอร์ม ครอบคลุมทั้ง AWS, Azure, GCP และ AliCloud โดยยึดตาม Shared Responsibility Model และเชื่อมโยงเข้ากับสภาพแวดล้อมด้านกฎระเบียบขององค์กรคุณ
ระบบคลาวด์ได้กลายเป็น Control Plane หลักขององค์กรยุคใหม่ไปแล้ว และยังเป็นจุดเริ่มต้นของเหตุการณ์ข้อมูลรั่วไหลที่สร้างความเสียหายรุนแรงที่สุดในรอบทศวรรษที่ผ่านมา ไม่ว่าจะเป็น Storage Bucket ที่ตั้งค่าผิดพลาด Role ที่ได้รับสิทธิ์เกินความจำเป็น Access Key ที่ถูกลืมทิ้งไว้ใน CI Pipeline หรือบริการที่เปิดสู่อินเทอร์เน็ตสาธารณะโดยไม่ได้ตั้งใจ การทดสอบความปลอดภัยคลาวด์จึงต้องก้าวให้ทันความเร็วของการเปลี่ยนแปลงในสภาพแวดล้อม และความง่ายที่การตั้งค่าผิดเพียงจุดเดียวจะกลายเป็นเหตุการณ์ข้อมูลรั่วไหล
Vantage Point ส่งมอบบริการรักษาความปลอดภัยคลาวด์ผ่านการประเมิน 2 ประเภทที่เสริมซึ่งกันและกัน การประเมินการตั้งค่าและความสอดคล้องตามมาตรฐานช่วยให้คุณมองเห็น IAM, Posture, Segmentation และ Governance ได้ชัดเจนในระดับที่ผู้ตรวจสอบยอมรับ จากนั้น Penetration Testing เฉพาะแพลตฟอร์มจะตรวจสอบยืนยันว่ามาตรการควบคุมเหล่านั้นสามารถต้านทาน Hacker ที่ได้รับสิทธิ์เข้าระบบมาแล้วและเคลื่อนไหวต่อในสภาพแวดล้อมได้จริงหรือไม่
กระบวนการตรวจสอบทั้งหมดทำงานอยู่บนแพลตฟอร์ม Velocity โดยมี Test Case ด้านคลาวด์ที่เชื่อมโยงกับ CIS Benchmarks หน่วยงานกำกับดูแลของแต่ละภาคธุรกิจ และ Security Baseline ที่เผยแพร่โดยผู้ให้บริการคลาวด์แต่ละราย ทุกช่องโหว่ที่พบผ่านการทำซ้ำเพื่อยืนยันผล มีคะแนนความรุนแรง และตรวจสอบย้อนกลับไปยังมาตรการควบคุมที่เกี่ยวข้องได้ เพื่อให้พร้อมใช้ยืนยันต่อผู้ตรวจประเมิน ไม่ใช่เป็นเพียงรายการความเสี่ยง
ไม่มีการติดตั้งเอเจนต์บนอุปกรณ์ปลายทางไม่มีศูนย์เฝ้าระวังความปลอดภัย มีเพียงระบบที่ใช้งานจริงในโปรดักชันของคุณที่เปิดออกสู่โลกอินเทอร์เน็ตโดยตรง
การตั้งค่าเปลี่ยนแปลงเร็วกว่าการกำกับดูแล
ทุกการเปลี่ยนแปลงของโครงสร้างพื้นฐานอาจกระทบความปลอดภัยเสมอ หากไม่ทดสอบอย่างต่อเนื่อง Security Posture จะค่อย ๆ อ่อนแอลงระหว่างรอบการตรวจสอบ และ IAM Policy ที่ผิดพลาดเพียงจุดเดียวก็ลบล้างงาน Hardening หลายเดือนได้
รูปแบบความรับผิดชอบร่วมกัน (Shared responsibility model) มีจุดที่ควรระมัดระวัง
ผู้ให้บริการคลาวด์ดูแลความปลอดภัยของตัวแพลตฟอร์ม แต่คุณยังคงต้องรับผิดชอบความปลอดภัยของ Identity การตั้งค่า ข้อมูล และ Workload การเจาะระบบคลาวด์ส่วนใหญ่เกิดขึ้นบนฝั่งความรับผิดชอบของลูกค้าอย่างชัดเจน
มาตรฐานต่าง ๆ มีรองรับอยู่แล้ว และเราใช้มาตรฐานเหล่านั้นในการทดสอบเปรียบเทียบวัดระดับ
CIS Benchmarks เผยแพร่ Hardening Baseline แบบทีละบรรทัดสำหรับผู้ให้บริการคลาวด์รายใหญ่ทุกราย ไม่ว่าจะเป็น AWS, Azure, GCP และ AliCloud เราตรวจสอบสภาพแวดล้อมของคุณเทียบกับแนวทางเหล่านี้ เพื่อให้ได้การประเมินตามมาตรฐานอุตสาหกรรมที่สม่ำเสมอ ซึ่งยืนยันว่าคุณใช้ฟีเจอร์ความปลอดภัยที่ผู้ให้บริการคลาวด์มีให้อยู่แล้ว และการตั้งค่าของคุณตรงตาม Best Practice ที่อุตสาหกรรมยอมรับร่วมกัน
สิ่งที่เราทดสอบ
การตรวจสอบระบบคลาวด์มุ่งเน้น 3 เลเยอร์ที่ทำงานควบคู่กัน ได้แก่ Identity, Configuration และ Runtime เพราะการเจาะระบบคลาวด์ในโลกจริงมักเชื่อมโยงทั้งสามจุดนี้เข้าด้วยกัน
Identity & access
IAM คือจุดที่การเจาะระบบคลาวด์ส่วนใหญ่ใช้ทำ Privilege Escalation และขยายผลความเสียหาย เราทำแผนผัง Permission, Trust Path และโอกาสในการทำ Lateral Movement ในรูปแบบเดียวกับที่ Hacker ทำ
- การตรวจสอบหลัก Least Privilege ครอบคลุม Role, Group และ User
- Trust Path แบบข้ามบัญชีและข้าม Tenant
- Service-to-service identity boundaries
- Credential ที่ไม่ได้ใช้งาน, Access Key อายุยาว และช่องว่างในการ Rotate Key
- เส้นทาง Privilege Escalation ผ่าน Policy ที่ตั้งค่าผิด
Configuration & posture
การรีวิวการตั้งค่าในระดับผู้ตรวจสอบ โดยเทียบกับ CIS Benchmarks และ Baseline ของผู้ให้บริการ จากนั้นตรวจทานความสมเหตุสมผลอีกชั้นจากมุมมอง Offensive Security
- การเปิดเผย Storage สู่สาธารณะ (S3, Blob, GCS, OSS)
- Network Segmentation, VPC, Security Group และ NSG
- การเข้ารหัสข้อมูลทั้งขณะจัดเก็บและระหว่างส่ง รวมถึงการจัดการ Key
- ความครอบคลุมของ Logging, Monitoring และการแจ้งเตือน
- การจัดการ Secret และการดูแล Credential ใน Pipeline ให้ปลอดภัย
Workloads & data
ในส่วนที่อยู่ในขอบเขต เราจะทดสอบลึกถึง Workload และการไหลของข้อมูลที่อยู่บนแพลตฟอร์มด้วย เพราะการตั้งค่าเพียงอย่างเดียวไม่เคยบอกเรื่องราวทั้งหมด
- แอปพลิเคชันและ API ที่โฮสต์บนคลาวด์
- Workload แบบ Container, Kubernetes และ Serverless
- การปกป้องข้อมูลทั้งใน Storage, Database และ Data Warehouse
- สถานะความปลอดภัยของระบบ Backup และ Disaster Recovery
- ความพร้อมด้าน Incident Response แบบ Cloud-Native
Serverless Functions
เราตรวจสอบ AWS Lambda, Azure Function Apps และ GCP Cloud Functions เทียบกับมาตรการควบคุมของ CIS Benchmark สำหรับ Function-as-a-Service ครอบคลุมสิทธิ์ของ Execution Role การเข้ารหัส Environment Variable การยืนยันตัวตน เครือข่าย และ Audit Logging แล้วชี้ให้เห็นว่าฟังก์ชันใดบ้างที่หลุดจาก Baseline
- AWS Lambda ครอบคลุม Execution Role, KMS Env Vars, Function URL Auth, VPC และ CloudWatch
- Azure Function Apps ครอบคลุม Managed Identity, HTTPS-only, VNet Integration และ Storage Hardening
- GCP Cloud Functions ครอบคลุม Service Account Scope, KMS Env Vars, VPC Connector และ Audit Log
- Cross-Provider ครอบคลุมการเข้าถึงได้จากสาธารณะ, Secret, Supply Chain และเส้นทาง Abuse
จุดที่กระบวนการตรวจสอบระบบคลาวด์มักจะไปสิ้นสุดหรือให้ผลลัพธ์สุดท้ายออกมาเป็นสิ่งนี้เสมอ
ข้อมูลที่นำเสนอเป็นกลุ่มช่องโหว่ที่ที่ปรึกษาของเรามักพบจากการทดสอบในลักษณะเดียวกัน ความรุนแรงและความถี่จะแตกต่างกันตามสภาพแวดล้อมและระดับความพร้อมของแต่ละองค์กร
ระบบระบุตัวตนที่ได้รับสิทธิ์เกินความจำเป็น
Role ใน Production ที่มีสิทธิ์แบบ Wildcard, ผู้ใช้ที่ผูกนโยบายระดับ Administrator ไว้ "ชั่วคราว" และ Service Account ที่มี Cross-Account Trust ซึ่งไม่จำเป็นต้องใช้แล้ว
การเปิดเผยข้อมูลภายในสู่สาธารณะ
Storage Bucket ที่เปิด ACL สาธารณะระดับ Object, บริการภายในที่เปิดผ่าน Load Balancer โดยไม่มีชั้นการยืนยันตัวตน และ Debug Endpoint ที่เข้าถึงได้จากอินเทอร์เน็ต
การรั่วไหลใน Pipeline และ Secret
Static Key อายุยาวในตัวแปร CI/CD, Secret ที่ถูก Commit เข้า Repository และ Build Agent ที่มีสิทธิ์บนคลาวด์กว้างกว่า Workload ที่นำไป Deploy
ช่องว่างใน Network Segmentation
โครงสร้าง VPC แบบแบนราบ, Security Group ที่เปิดสิทธิ์กว้างเกินไป, เครือข่ายที่ทำ Peering ไว้จนเปิดทาง Lateral Movement และการไม่จำกัด Egress บน Subnet ของ Workload
ช่องว่างใน Logging และการตรวจจับ
การปิดใช้งาน Audit Logging ในบริการสำคัญ, ระยะเก็บ Log ที่สั้นกว่าข้อกำหนดด้าน Incident Response และการแจ้งเตือนที่มีอยู่จริงแต่ไม่ได้ส่งถึงผู้รับผิดชอบ On-Call
ช่องโหว่ใน Recovery และ Resilience
Backup ที่เก็บอยู่ในบัญชีเดียวกับระบบที่ปกป้อง, การขาดคุณสมบัติ Immutability, ขั้นตอนกู้คืนที่ไม่เคยผ่านการทดสอบ และการพึ่งพา Region เดียวสำหรับ Workload ระดับ Tier-1
อ้างอิงมาตรฐานสากลที่ได้รับการยอมรับ
Test Case ด้านคลาวด์ใน Velocity เชื่อมโยงทั้งกับ Baseline ทางเทคนิคและข้อกำหนดของหน่วยงานกำกับดูแล ซึ่งเป็นปัจจัยขับเคลื่อนการตรวจสอบส่วนใหญ่ในภูมิภาคนี้
รายงานที่ออกแบบมาสำหรับงานตรวจสอบ ทีมวิศวกร และผู้บริหาร
ทุกโครงการจะส่งมอบเอกสารหลักฐานที่ตรวจสอบได้ ติดตามได้ และพร้อมส่งหน่วยงานกำกับดูแล, สร้างผ่าน Velocity และลงนามด้วยรหัสเพื่อการตรวจสอบความถูกต้อง
PDF · JSON · XML · CSV · รองรับรายงานหลายภาษา · CVSS 3.0 / 3.1 / 4.0
- รายงานฉบับสมบูรณ์พร้อมลายเซ็นดิจิทัล
- การอ้างอิง Test Case และการให้คะแนน CVSS สำหรับแต่ละช่องโหว่
- ขั้นตอนการทำซ้ำ Payload และภาพหน้าจอประกอบ
- แนวทางแก้ไข Configuration พร้อมตัวอย่าง Policy และ Code
- รายงานสรุปสำหรับผู้บริหารและ Risk Heatmap
- ตารางสรุปความครอบคลุมต่อมาตรฐานและหน่วยงานกำกับดูแล
- การประชุมสรุปผลกับผู้เกี่ยวข้องและการทดสอบซ้ำหลังการแก้ไข
คำถามจากผู้สนใจใช้บริการ
Penetration Testing บนคลาวด์ต่างจากการทดสอบเครือข่ายทั่วไปอย่างไร? +
Network Penetration Testing แบบดั้งเดิมมุ่งเน้นการเปิดเผยที่ขอบเขตของระบบและ Lateral Movement ข้ามโฮสต์ ส่วนการตรวจสอบคลาวด์เพิ่มเส้นทางการโจมตีผ่าน Identity, Configuration Drift, การเข้าถึง Control Plane และการใช้บริการเฉพาะของผู้ให้บริการในทางที่ผิด โดยทั่วไปเราจะรวมทั้งสองแบบเข้าด้วยกันเมื่อ Workload อยู่ทั้ง On-Prem และบนคลาวด์
จำเป็นต้องให้สิทธิ์ Admin เต็มของบัญชีคลาวด์หรือไม่? +
ไม่จำเป็น เราปรับสิทธิ์การเข้าถึงให้เหมาะกับแต่ละโครงการ ตั้งแต่การทดสอบภายนอกแบบ Black-Box, Credential แบบ Read-Only สำหรับการรีวิวการตั้งค่า ไปจนถึง Identity ที่จำกัดขอบเขตสำหรับการทดสอบเส้นทางการโจมตีแบบมีสิทธิ์เข้าระบบ โดย Rules of Engagement จะกำหนดชัดเจนว่าสิ่งใดอยู่ในขอบเขตและสิ่งใดไม่อยู่
ทดสอบใน Production Environment ได้อย่างปลอดภัยหรือไม่? +
ได้ แต่มีการควบคุม การรีวิวการตั้งค่าและ Identity ออกแบบมาให้ไม่รบกวนระบบอยู่แล้ว ส่วนการทดสอบเส้นทางการโจมตีเชิงรุกบน Production จะดำเนินการภายใต้ Rules of Engagement ที่เป็นลายลักษณ์อักษร ช่วงเวลาเปลี่ยนแปลงระบบ และเกณฑ์การยกเลิกที่ตกลงกันล่วงหน้า เพื่อไม่ให้กระทบการดำเนินงาน
การทดสอบนี้สอดคล้องกับข้อกำหนดของ PCI DSS หรือ ISO 27001 อย่างไร? +
ทุก Test Case ใน Velocity เชื่อมโยงกับมาตรฐานที่รองรับ รายงานจะมี Coverage Matrix ที่ส่งให้ผู้ตรวจสอบได้โดยตรง พร้อมการตรวจสอบย้อนกลับจากช่องโหว่ที่พบไปยังมาตรการควบคุมที่เกี่ยวข้อง
รองรับสภาพแวดล้อม Multi-Cloud หรือไม่? +
ได้ ปัจจุบันองค์กรขนาดใหญ่ในภูมิภาคนี้ส่วนใหญ่ใช้ Multi-Cloud โดยทั่วไปคือ AWS ควบคู่กับ Azure และใช้ GCP สำหรับงานวิเคราะห์ข้อมูล หรือ AliCloud สำหรับ Workload ในประเทศจีน การตรวจสอบครอบคลุมได้ทั้งแพลตฟอร์มเดียว หรือรวมหลายแพลตฟอร์มไว้ในการประเมินครั้งเดียวพร้อมแผนผังเส้นทางการโจมตีข้ามแพลตฟอร์ม
การทดสอบนี้จะไปเปิดใช้งานระบบตรวจจับพฤติกรรมมิชอบ (Abuse Detection) ของผู้ให้บริการคลาวด์ของคุณหรือเปล่า? +
ผู้ให้บริการคลาวด์ถือว่าการทดสอบความปลอดภัยที่ลูกค้าเป็นผู้เริ่มเป็นเรื่องปกติ สำหรับการทดสอบเชิงรุก เราจะแจ้งผู้ให้บริการตามขั้นตอนที่เหมาะสม และปฏิบัติตามเงื่อนไขการให้บริการที่เผยแพร่ไว้ ทีม Incident Response ของคุณจะได้รับข้อมูลล่วงหน้า เพื่อให้การตรวจจับภายในเชื่อมโยงกับกิจกรรมของเราได้
ทดสอบคลาวด์ในแบบที่คลาวด์เกิดความล่มจริง
พูดคุยกับผู้เชี่ยวชาญที่ได้รับการรับรองจาก CREST เพื่อกำหนดขอบเขตการตรวจสอบคลาวด์ ครอบคลุมทั้งด้านการตั้งค่า ด้าน Identity และการทดสอบเส้นทางการโจมตี ที่ออกแบบตามสภาพแวดล้อมด้านกฎระเบียบขององค์กรคุณ