20 เคล็ดลับด้านความปลอดภัยบนคลาวด์สำหรับทีม DevSecOps ยุคใหม่

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

คู่มือนี้รวบรวมเคล็ดลับด้านความปลอดภัยบนคลาวด์ที่ใช้งานได้จริง 20 ข้อ โดยแบ่งตามชั้นต่างๆ ได้แก่ การระบุตัวตน ข้อมูล โครงสร้างพื้นฐาน และห่วงโซ่อุปทานซอฟต์แวร์ CI/CD pipelineการรักษาความปลอดภัย การตรวจจับ และการตอบสนองต่อเหตุการณ์ ไม่ว่าคุณจะเสริมความแข็งแกร่งให้กับบัญชีคลาวด์เดียวหรือรักษาความปลอดภัยให้กับหลายทีม DevSecOps pipelineมาตรการควบคุมเหล่านี้ช่วยป้องกันการละเมิดข้อมูลที่เกิดขึ้นจริงได้

เหตุใดระบบรักษาความปลอดภัยบนคลาวด์จึงยังคงล้มเหลว แม้จะมีคำแนะนำด้านความปลอดภัยบนคลาวด์มากมายก็ตาม

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

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

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

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

20 เคล็ดลับด้านความปลอดภัยบนระบบคลาวด์:

เคล็ดลับด้านความปลอดภัยของระบบจัดการข้อมูลประจำตัวและการเข้าถึงบนคลาวด์

1. เปิดใช้งานการตรวจสอบสิทธิ์แบบหลายปัจจัยทุกที่

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

บังคับใช้ MFA สำหรับทุกบัญชีผู้ใช้ในสภาพแวดล้อมคลาวด์ของคุณ: บัญชีนักพัฒนา บัญชีผู้ดูแลระบบ พอร์ทัลผู้ให้บริการคลาวด์ CI/CD dashboards. ใช้ MFA ที่ป้องกันฟิชชิ่ง (คีย์ฮาร์ดแวร์, รหัสผ่าน) สำหรับบัญชีที่มีสิทธิ์พิเศษ รหัสยืนยันตัวตนตามเวลาผ่านแอปยืนยันตัวตนถือเป็นมาตรฐานขั้นต่ำ

2. ใช้หลักการให้สิทธิ์ขั้นต่ำสุด โดยเฉพาะกับสิ่งที่ไม่ใช่มนุษย์

หลักการสิทธิ์ขั้นต่ำสุด เป็นสิ่งที่มนุษย์เข้าใจได้ดี แต่สิ่งที่ทีมงานมักมองข้ามไปคือ อัตลักษณ์ที่ไม่ใช่มนุษย์: CI/CD บัญชีบริการ, ฟังก์ชัน Lambda, เวิร์กโหลดคอนเทนเนอร์, ตัวรัน GitHub Actions

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

// Bad: wildcard S3 permissions on a Lambda function { "Action": "s3:*", "Resource": "*" }  // Good: scoped to exactly what the function needs {    "Action": ["s3:GetObject", "s3:PutObject"],   "Resource": "arn:aws:s3:::my-app-bucket/uploads/*" }

ตรวจสอบสิทธิ์การใช้งานบัญชีบริการทุกไตรมาส ลบสิ่งที่ไม่ได้ใช้งานมานานกว่า 90 วัน

3. เปลี่ยนข้อมูลประจำตัวที่มีอายุการใช้งานยาวนานเป็นโทเค็นที่มีอายุการใช้งานสั้น

คีย์ API แบบคงที่และโทเค็นที่มีอายุการใช้งานยาวนานเป็นหนึ่งในสาเหตุหลักที่พบบ่อยที่สุดของการละเมิดความปลอดภัยบนคลาวด์ พวกมัน... commitถูกส่งไปยังที่เก็บข้อมูล รั่วไหลในบันทึก CI คัดลอกไปยัง Slack และถูกลืมไปในที่สุด .env ไฟล์เหล่านั้นจะยังคงใช้งานได้เป็นเวลาหลายเดือนหรือหลายปี

ควรเปลี่ยนไปใช้ข้อมูลประจำตัวที่มีอายุสั้นกว่าทุกครั้งที่เป็นไปได้: AWS STS assume-role, การรวมข้อมูลประจำตัวของเวิร์กโหลด GCP, GitHub Actions OIDCเมื่อไม่สามารถหลีกเลี่ยงการใช้ข้อมูลประจำตัวแบบคงที่ได้ ให้จัดเก็บข้อมูลเหล่านั้นไว้ในตัวจัดการความลับ (Vault, AWS Secrets Manager, Azure Key Vault) และทำการหมุนเวียนข้อมูลประจำตัวโดยอัตโนมัติ

4. นำระบบการเข้าถึงแบบทันเวลา (Just-in-Time Access) มาใช้สำหรับสิทธิ์ระดับสูง

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

ระบบการเข้าถึงแบบ JIT (AWS IAM Identity Center, GCP Privileged Access Manager, Okta Access Requests) ให้สิทธิ์การเข้าถึงระดับสูงตามความต้องการ จำกัดเวลา และมีบันทึกการตรวจสอบอย่างครบถ้วน นักพัฒนาจะได้รับสิ่งที่ต้องการเมื่อต้องการ ในขณะที่ผู้โจมตีจะไม่พบเป้าหมายที่ง่ายต่อการโจมตี

5. บังคับใช้ Zero Trust ในการสื่อสารระหว่างบริการต่างๆ

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

ความน่าเชื่อถือเป็นศูนย์ หมายความว่าทุกคำขอจะได้รับการตรวจสอบและอนุญาต ไม่ว่าคำขอนั้นจะมาจากที่ใดก็ตาม ให้ใช้การตรวจสอบสิทธิ์ระหว่างบริการ (mTLS, การระบุตัวตนของเซอร์วิสเมช) บังคับใช้นโยบายเครือข่ายในระดับเวิร์กโหลด และถือว่าการรับส่งข้อมูลภายในไม่น่าเชื่อถือโดยค่าเริ่มต้น

เคล็ดลับการปกป้องข้อมูลและความปลอดภัยบนระบบคลาวด์

6. เข้ารหัสทุกอย่าง รวมถึงการรับส่งข้อมูลภายใน

การเข้ารหัสขณะจัดเก็บ (AES-256(จัดการโดย KMS) ตอนนี้ standard การฝึกฝน ช่องว่างที่ทีมส่วนใหญ่มีคือ การเข้ารหัสระหว่างการส่งข้อมูลสำหรับทราฟฟิกภายใน.

ใน VPC ที่มีไมโครเซอร์วิสและการสื่อสารระหว่างคอนเทนเนอร์ การรับส่งข้อมูลที่อยู่ "ภายใน" นั้นไม่ปลอดภัยโดยเนื้อแท้ จึงควรใช้ Mutual TLS (mTLS) สำหรับการสื่อสารภายในบริการ และใช้ Service Mesh (Istio, Linkerd) หรือ Zero-Trust Networking Layer เพื่อบังคับใช้สิ่งนี้โดยอัตโนมัติ แทนที่จะพึ่งพาแต่ละทีมในการกำหนดค่าอย่างถูกต้อง

7. ตรวจจับและแก้ไขความลับที่ถูกเปิดเผยก่อนที่จะแพร่กระจาย

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

การป้องกันหลายชั้นมีความสำคัญ (pre-commit hooks(รวมถึงปลั๊กอิน IDE) แต่ก็ยังไม่เพียงพอ คุณจำเป็นต้องสแกนอย่างต่อเนื่องทั่วทุกแหล่งเก็บข้อมูล รวมถึงข้อมูลเก่าด้วย commits, CI/CD บันทึก IaC ไฟล์และอิมเมจคอนเทนเนอร์ เมื่อตรวจพบข้อมูลลับ ต้องตอบสนองทันที: เพิกถอน หมุนเวียน และประเมินว่ามีการเข้าถึงข้อมูลนั้นระหว่างช่วงที่ถูกเปิดเผยและช่วงที่ตรวจพบหรือไม่

8. จัดประเภทข้อมูลและใช้มาตรการควบคุมตามระดับความไว

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

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

ความปลอดภัยของโครงสร้างพื้นฐานและการกำหนดค่า

9. สแกน IaC ในทุกๆ Commitไม่ใช่แค่ก่อนการใช้งานจริงเท่านั้น

Infrastructure as Code คือจุดที่เกิดการตั้งค่าที่ไม่ถูกต้อง ไม่ใช่ในสภาพแวดล้อมการใช้งานจริง เช่น บักเก็ต S3 สาธารณะ กลุ่มความปลอดภัยแบบเปิด หรือบทบาท IAM ที่มี * * * * * * * * การตั้งค่าสิทธิ์ไม่ได้เกิดขึ้นโดยบังเอิญ มันเริ่มต้นจากบรรทัดหนึ่งในไฟล์ Terraform หรือไฟล์ manifest ของ Kubernetes ที่ไม่มีใครตั้งค่าไว้

IaC การสแกนต้องทำงานบนทุกๆ pull requestโดยมีข้อค้นพบปรากฏขึ้นในขั้นตอนการตรวจสอบโค้ด สแกน Terraform, Kubernetes manifests, CloudFormation, Helm charts, Dockerfiles และ CI/CD การกำหนดค่า

# This fails immediately in Xygeni IaC scanning: resource "aws_s3_bucket" "data" {   bucket = "company-data"   acl    = "public-read"   # ← flagged: public access enabled }

ไซเกนี IaC Security สแกนทุกรูปแบบที่รองรับบนทุกอุปกรณ์ commitโดยจะเชื่อมโยงผลการค้นหากับแหล่งข้อมูลเฉพาะ และผสานรวมเข้ากับเวิร์กโฟลว์ PR ของคุณ เพื่อให้นักพัฒนาได้รับข้อเสนอแนะในที่ทำงาน ไม่ใช่ในหน้าต่างแยกต่างหาก dashboard พวกเขาไม่เคยเปิดเลย เริ่มทดลองใช้งานฟรี →

10. ปฏิบัติต่อนโยบายความปลอดภัยเสมือนเป็นรหัสโปรแกรม

การตรวจสอบความปลอดภัยด้วยตนเองไม่สามารถขยายขนาดได้ แต่การกำหนดนโยบายด้วยโค้ดทำได้

ใช้เครื่องมืออย่าง OPA (Open Policy Agent) หรือ Kyverno เพื่อกำหนดกฎความปลอดภัยในรูปแบบโค้ดที่มีการกำหนดเวอร์ชันและทดสอบได้ บังคับใช้กฎเหล่านั้นที่ pipeline ระดับดังกล่าวเป็นการปรับใช้ Kubernetes ด้วย สิทธิพิเศษ: จริง หรือคอนเทนเนอร์ที่ทำงานในฐานะ root จะทำให้การสร้างล้มเหลวโดยอัตโนมัติทุกครั้ง เมื่อนโยบายอยู่ในโค้ด พวกมันจะได้รับการตรวจสอบและปรับปรุงเหมือนกับสิ่งประดิษฐ์ทางวิศวกรรมอื่นๆ แต่เมื่อพวกมันอยู่ในเอกสาร พวกมันก็จะเปลี่ยนแปลงไป

11. บังคับใช้มาตรฐานการกำหนดค่าที่ปลอดภัยและตรวจสอบการเปลี่ยนแปลงที่เกิดขึ้น

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

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

12. แบ่งส่วนเครือข่ายและจำกัดการเคลื่อนที่ด้านข้าง

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

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

เคล็ดลับด้านความปลอดภัยบนคลาวด์สำหรับห่วงโซ่อุปทานซอฟต์แวร์

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

13. ตรวจสอบทุกส่วนประกอบก่อนที่จะนำไปใช้ในการสร้างโปรแกรม

แพ็กเกจโอเพนซอร์สเป็นช่องทางเข้าถึงเริ่มต้นที่พบได้บ่อยที่สุดในการโจมตีห่วงโซ่อุปทานสมัยใหม่ แคมเปญ Shai-Hulud ในปี 2024 โจมตีแพ็กเกจ npm มากกว่า 830 รายการ ช่องโหว่ XZ Utils เกือบทำให้การตรวจสอบสิทธิ์ SSH ในระบบ Linux หลายล้านเครื่องถูกโจมตี ในทั้งสองกรณี โค้ดที่เป็นอันตรายเข้ามาทางกระบวนการติดตั้งส่วนประกอบตามปกติ

ขั้นพื้นฐาน SCA (การวิเคราะห์องค์ประกอบซอฟต์แวร์) และรายการ CVE ดิบๆ นั้นไม่เพียงพอ สิ่งที่คุณต้องการจริงๆ คือ:

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

14. ล็อคดาวน์ CI/CD Pipelines

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

มาตรการควบคุมที่ต้องบังคับใช้:

กำหนดให้มีการตรวจสอบโค้ดก่อนทำการเปลี่ยนแปลงใดๆ pipeline ไฟล์การกำหนดค่า (.github/workflows/, เจนกินส์ไฟล์ฯลฯ )
จำกัดการใช้งานรันเนอร์แบบโฮสต์เองให้เฉพาะกับแหล่งเก็บข้อมูลที่ได้รับอนุมัติเท่านั้น การเข้าถึงรันเนอร์ที่ไม่ได้รับการตรวจสอบเป็นช่องทางโดยตรงสู่การขโมยข้อมูลประจำตัว
ห้ามส่งข้อมูลลับผ่านตัวแปรสภาพแวดล้อมที่เป็นข้อความธรรมดาเด็ดขาด ให้ใช้ระบบจัดการข้อมูลลับแทน
กรรมการตรวจสอบ pipeline บันทึกคำสั่งที่ไม่คาดคิด การเรียกใช้เครือข่ายที่ผิดปกติ หรือการดำเนินการในเวลาที่ไม่คาดฝัน

ไซเกนี CI/CD ⁠ความปลอดภัย บังคับใช้ guardrails โดยตรงของคุณ pipeline รวมถึงการบล็อกการสร้างที่ไม่ปลอดภัย การตรวจจับเวิร์กโฟลว์ที่ถูกแทรก และการรับประกัน pipeline ความซื่อสัตย์สุจริตในทุกขั้นตอน จองการสาธิต →

15. ตรวจสอบความถูกต้องของการสร้างและลงนามในไฟล์ที่สร้างขึ้น

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

บังคับใช้การควบคุมความสมบูรณ์ของการสร้าง:

กำหนดเวอร์ชันของไลบรารีและอิมเมจพื้นฐานทั้งหมดให้ตรงกับค่าแฮชที่แน่นอน ไม่ใช่แท็ก
ลงนามในไฟล์ที่สร้างขึ้นและตรวจสอบลายเซ็นก่อนนำไปใช้งาน
คอยตรวจสอบการเปลี่ยนแปลงที่ไม่คาดคิด CI/CD ไฟล์เวิร์กโฟลว์และเวิร์กโฟลว์ที่ถูกแทรกเข้าไปนั้นเป็นตัวบ่งชี้สำคัญในการโจมตี เช่น การโจมตี Shai-Hulud
ใช้การรับรอง SLSA เพื่อพิสูจน์ทางคริปโตกราฟีว่าสิ่งใดถูกสร้างขึ้น จากแหล่งใด และโดยอะไร pipeline

การตรวจจับภัยคุกคามและการตอบสนองต่อเหตุการณ์

16. รวมศูนย์การบันทึกข้อมูลและสร้างความสามารถในการมองเห็นภาพรวมทั่วทั้งระบบ

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

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

17. จัดลำดับความสำคัญของสิ่งที่ค้นพบโดยพิจารณาจากความสามารถในการนำไปใช้ประโยชน์ ไม่ใช่แค่ความรุนแรง

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

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

Xygeni ASPM นำผลการค้นพบทั้งหมดมารวมกัน SAST, SCA, IaCความลับ และ pipeline security แปลงให้เป็นมุมมองความเสี่ยงที่เป็นหนึ่งเดียว พร้อมการจัดลำดับความสำคัญตามบริบท ซึ่งจะบอกทีมของคุณได้อย่างชัดเจนว่าควรแก้ไขปัญหาใดก่อน จองการสาธิต →

18. กำหนดเกณฑ์มาตรฐานด้านพฤติกรรมและแจ้งเตือนเมื่อพบความเบี่ยงเบน

การตรวจจับภัยคุกคามที่รู้จักกันดี (Known-bad signatures) จะตรวจจับภัยคุกคามที่ทราบแล้ว ส่วนการตรวจจับความผิดปกติทางพฤติกรรม (Behavioral anomaly detection) จะตรวจจับภัยคุกคามที่ไม่รู้จัก ช่องโหว่ Zero-day รูปแบบการโจมตีใหม่ๆ และภัยคุกคามจากภายในองค์กร

สำหรับคุณ CI/CD โดยเฉพาะอย่างยิ่งในสภาพแวดล้อมนั้นๆ ให้กำหนดค่าพื้นฐานสำหรับระยะเวลาการสร้างโดยทั่วไป รูปแบบการติดตั้งแพ็กเกจตามปกติ ปลายทางเครือข่ายที่คาดหวังระหว่างการสร้าง และอื่นๆ standard รูปแบบการเข้าถึงข้อมูลลับ การเบี่ยงเบนจากรูปแบบพื้นฐานเหล่านี้คือสัญญาณเตือนแรกสุด และเป็นส่วนที่ทีมส่วนใหญ่ไม่มีข้อมูลใดๆ เลย

19. กำหนดคู่มือการปฏิบัติงาน (Runbook) สำหรับสถานการณ์เหตุการณ์เฉพาะของระบบคลาวด์

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

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

20. เรียกใช้โปรแกรมออกกำลังกายบนโต๊ะcisใช่ อย่างน้อยปีละสองครั้ง

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

วิ่งอย่างน้อยสองครั้งcisต่อปี โดยจำลองสถานการณ์ต่างๆ เช่น การถูกโจมตีในห่วงโซ่อุปทาน การรั่วไหลของข้อมูลที่เกิดจากการตั้งค่าที่ไม่ถูกต้อง และการถูกโจมตีของ CI Runner รวมทั้งทีมที่จะตอบสนองเหตุการณ์จริง ได้แก่ ทีมรักษาความปลอดภัย ทีม DevOps และนักพัฒนาที่พร้อมรับสาย

รายการตรวจสอบเคล็ดลับด้านความปลอดภัยบนคลาวด์: คู่มืออ้างอิงฉบับย่อ

ชั้น	ปุ่มควบคุม
เอกลักษณ์	MFA ทุกที่, สิทธิ์ขั้นต่ำสุด, ข้อมูลประจำตัวที่มีอายุสั้น, การเข้าถึงแบบ JIT
ข้อมูล	เข้ารหัสข้อมูลทั้งขณะจัดเก็บและขณะส่งผ่าน การสแกนความลับและการยกเลิกอัตโนมัติ การจำแนกประเภทข้อมูล
โครงสร้างพื้นฐาน	IaC กำลังสแกน commitนโยบายในรูปแบบโค้ด CIS การบังคับใช้เกณฑ์พื้นฐาน การแบ่งส่วนเครือข่าย
ห่วงโซ่อุปทาน	SCA พร้อมคุณสมบัติการเข้าถึงและการตรวจจับมัลแวร์ CI/CD การเสริมความแข็งแรง ความสมบูรณ์ของโครงสร้าง และ SLSA
การตรวจพบ	การบันทึกข้อมูลแบบรวมศูนย์ การจัดลำดับความสำคัญตาม EPSS การตรวจจับความผิดปกติทางพฤติกรรม
คำตอบ	คู่มือปฏิบัติการเฉพาะระบบคลาวด์, แบบฝึกหัดจำลองสถานการณ์cisเช่น การประเมินรัศมีแรงระเบิดที่บันทึกไว้

Xygeni ช่วยนำเคล็ดลับด้านความปลอดภัยบนคลาวด์ไปใช้กับระบบแบบครบวงจรได้อย่างไร

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

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

ชั้น	ความสามารถของไซเจนี	สิ่งที่ป้องกันได้
รหัสที่มา	SAST + การแก้ไขด้วย AI	การโจมตีแบบ Injection, การตรวจสอบสิทธิ์ล้มเหลว, การออกแบบที่ไม่ปลอดภัย
การอ้างอิง	SCA + การตรวจจับมัลแวร์ + EPSS	ช่องโหว่ในห่วงโซ่อุปทาน บรรจุภัณฑ์ที่เปราะบาง
ความลับ	การรักษาความลับ + การยกเลิกอัตโนมัติ	การเปิดเผยข้อมูลประจำตัว ความเสี่ยงของโทเค็นที่มีอายุยาวนาน
IaC และการกำหนดค่า	IaC Security	การตั้งค่าที่ไม่ถูกต้องก่อนถึงขั้นตอนการผลิต
CI/CD Pipeline	CI/CD ระบบรักษาความปลอดภัย + การตรวจจับความผิดปกติ	Pipeline การฉีด, การประนีประนอมของนักวิ่ง
สร้างสิ่งประดิษฐ์	Build Security + SLSA provenance	สิ่งประดิษฐ์ที่ถูกดัดแปลง เอกสารที่ไม่ได้ลงนาม
ท่าทีเสี่ยง	ASPM	มุมมองที่เป็นหนึ่งเดียว การจัดลำดับความสำคัญข้ามเลเยอร์

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

ข้อสรุป

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

นั่นหมายถึงการรักษาความปลอดภัยมากกว่าแค่โครงสร้างพื้นฐานขณะรันไทม์ หมายถึงการปกป้องซอร์สโค้ด ส่วนประกอบต่างๆ และความลับต่างๆ ด้วย IaC, CI/CD พิจารณาเวิร์กโฟลว์ ผลลัพธ์การสร้าง และสถานะความเสี่ยงของแอปพลิเคชันไปพร้อมกัน

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

???? เริ่มทดลองใช้ฟรี 7 วันของคุณ ไม่ต้องใช้บัตรเครดิต สแกนได้ผลในไม่กี่นาที
???? จองตัวอย่าง และดูว่า Xygeni เชื่อมต่อกับระบบคลาวด์ของคุณได้อย่างไร pipeline การติดตั้ง