ความปลอดภัยของพื้นที่จัดเก็บบนคลาวด์และความเสี่ยงจากการเปิดเผยข้อมูล
เรียนรู้ว่าการตั้งค่าบัคเก็ต S3 คอนเทนเนอร์ Azure Blob และบัคเก็ต GCS ที่ไม่ถูกต้องนำไปสู่การเปิดเผยข้อมูลได้อย่างไร รวมถึงวิธีบังคับใช้นโยบายบัคเก็ตและมาตรการควบคุมการเข้าถึง
ความปลอดภัยของพื้นที่จัดเก็บบนคลาวด์และความเสี่ยงจากการเปิดเผยข้อมูล เป็นบทเรียน Security+ Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Security+ Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Security+ Academy มีบทเรียนทั้งหมด 4 บทเรียน
พื้นฐานพื้นที่จัดเก็บออบเจ็กต์บนคลาวด์
พื้นที่จัดเก็บออบเจ็กต์บนคลาวด์ ได้แก่ AWS S3, Azure Blob Storage และ Google Cloud Storage (GCS) ใช้จัดเก็บไฟล์เป็นออบเจ็กต์ในเนมสเปซแบบราบที่เรียกว่า bucket หรือคอนเทนเนอร์ ต่างจากระบบไฟล์แบบดั้งเดิม สิทธิ์จะถูกควบคุมผ่าน policy ที่แนบกับ bucket และออบเจ็กต์ แทนที่จะใช้ ACL ของระบบไฟล์ พื้นที่จัดเก็บออบเจ็กต์เหมาะสำหรับข้อมูลขนาดใหญ่ แต่ต้องกำหนดค่าสิทธิ์อย่างรอบคอบ เพราะ bucket ที่กำหนดค่าผิดเพียงรายการเดียวอาจทำให้ข้อมูลสำคัญหลายเทราไบต์ถูกเปิดเผยต่ออินเทอร์เน็ตสาธารณะ
การกำหนดค่า bucket แบบสาธารณะผิดพลาด
ช่องโหว่ของพื้นที่จัดเก็บบนคลาวด์ที่พบได้บ่อยที่สุดคือ bucket ที่เข้าถึงได้แบบสาธารณะ ซึ่งเป็น bucket ที่ policy อนุญาตให้อ่านโดยไม่ระบุตัวตน (หรืออนุญาตให้เขียนได้) การกำหนดค่าผิดพลาดนี้ก่อให้เกิดเหตุการณ์ข้อมูลรั่วไหลครั้งใหญ่หลายสิบครั้ง เช่น Verizon (ข้อมูลลูกค้า 14 ล้านรายการ), FedEx (หนังสือเดินทาง 119,000 ฉบับ) และ Capital One (ใบสมัครบัตรเครดิต 100 ล้านรายการ) ผู้โจมตีใช้เครื่องมือสแกนอัตโนมัติเพื่อค้นหา bucket สาธารณะตามรูปแบบการตั้งชื่อบัญชี AWS ที่รู้จักทั้งหมด ทำให้ค้นพบได้ง่ายทันทีที่เกิดการกำหนดค่าผิดพลาด
# Check if S3 bucket is publicly accessible
aws s3api get-bucket-policy --bucket my-bucket
aws s3api get-bucket-acl --bucket my-bucket
# Block all public access (AWS recommended default)
aws s3api put-public-access-block \
--bucket my-bucket \
--public-access-block-configuration \
'BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true'Policy ของ bucket เทียบกับ ACL
พื้นที่จัดเก็บบนคลาวด์ใช้การควบคุมการเข้าถึงสองประเภทที่อาจขัดแย้งกัน policy ของ bucket เป็นเอกสาร JSON ที่แนบกับ bucket และกำหนดว่า Principal ใดทำ Action ใดได้บ้าง ส่วน รายการควบคุมการเข้าถึง (ACL) เป็นการให้สิทธิ์ต่อออบเจ็กต์แบบเดิม AWS แนะนำให้ปิดใช้ ACL และใช้ policy ของ bucket แทนเพื่อให้มีความสอดคล้อง เมื่อมีทั้งสองอย่าง policy ที่ผ่อนปรนมากที่สุดจะเป็นผล ซึ่งหมายความว่า ACL ที่อนุญาตกว้างเกินไปอาจให้สิทธิ์เข้าถึงแบบสาธารณะ แม้ policy ของ bucket จะจำกัดการเข้าถึงไว้ก็ตาม
# S3 bucket policy example — restrict to specific account
{
'Version': '2012-10-17',
'Statement': [{
'Effect': 'Allow',
'Principal': { 'AWS': 'arn:aws:iam::123456789012:root' },
'Action': 's3:GetObject',
'Resource': 'arn:aws:s3:::my-bucket/*'
}]
}
# All other principals implicitly deniedการเข้ารหัสขณะจัดเก็บในพื้นที่จัดเก็บออบเจ็กต์
ผู้ให้บริการพื้นที่จัดเก็บบนคลาวด์มีการเข้ารหัสฝั่งเซิร์ฟเวอร์สำหรับออบเจ็กต์ที่จัดเก็บอยู่ SSE-S3 (AWS) ใช้คีย์ที่ AWS จัดการโดยอัตโนมัติ SSE-KMS ใช้คีย์ที่ลูกค้าจัดการใน AWS Key Management Service ทำให้มีบันทึกตรวจสอบที่ดีกว่า (การถอดรหัสทุกครั้งจะถูกบันทึกใน CloudTrail) และควบคุมการหมุนเวียนคีย์ได้ ส่วน SSE-C ใช้คีย์ที่ลูกค้าเป็นผู้จัดหาและจัดการทั้งหมดภายนอก AWS สำหรับข้อมูลสำคัญ SSE-KMS ที่ใช้คีย์ซึ่งลูกค้าจัดการจะให้การควบคุมและหลักฐานด้านการปฏิบัติตามข้อกำหนดที่รัดกุมที่สุด
# Enforce encryption on S3 bucket (deny unencrypted uploads)
{
'Effect': 'Deny',
'Principal': '*',
'Action': 's3:PutObject',
'Resource': 'arn:aws:s3:::my-secure-bucket/*',
'Condition': {
'StringNotEquals': {
's3:x-amz-server-side-encryption': 'aws:kms'
}
}
}การเข้ารหัสระหว่างส่ง
แม้ข้อมูลที่จัดเก็บจะเข้ารหัสไว้อย่างเหมาะสม ก็ยังอาจถูกเปิดเผยได้หากส่งผ่านช่องทางที่ไม่ได้เข้ารหัส ควรเข้าถึง API ของพื้นที่จัดเก็บบนคลาวด์ทั้งหมดผ่าน HTTPS/TLS เท่านั้น สำหรับ S3 สามารถใช้ policy ของ bucket บังคับ HTTPS ได้โดยปฏิเสธคำขอที่มี aws:SecureTransport: false URL ที่ลงลายมือชื่อไว้ล่วงหน้า ซึ่งเป็น URL ที่ตรวจสอบสิทธิ์ชั่วคราวและให้สิทธิ์เข้าถึงออบเจ็กต์ในช่วงเวลาจำกัด ควรใช้ HTTPS เสมอและกำหนดระยะเวลาหมดอายุให้สั้น เพื่อจำกัดช่วงเวลาที่ข้อมูลอาจถูกเปิดเผยหาก URL ถูกดักจับ
# S3 bucket policy — deny HTTP (require HTTPS)
{
'Effect': 'Deny',
'Principal': '*',
'Action': 's3:*',
'Resource': ['arn:aws:s3:::my-bucket', 'arn:aws:s3:::my-bucket/*'],
'Condition': {
'Bool': { 'aws:SecureTransport': 'false' }
}
}การจัดประเภทข้อมูลและระดับพื้นที่จัดเก็บ
ข้อมูลทุกประเภทไม่จำเป็นต้องได้รับการปกป้องในระดับเดียวกัน ข้อมูลสำคัญ (PII, PHI และบันทึกทางการเงิน) ต้องจัดเก็บใน bucket ที่เข้ารหัส จำกัดการเข้าถึง และเปิดใช้การบันทึกกิจกรรมตรวจสอบ ข้อมูลที่มีความอ่อนไหวน้อยกว่าอาจอนุญาตให้เข้าถึงได้กว้างขึ้น ควรใช้ ป้ายกำกับการจัดประเภทข้อมูล ตั้งแต่การสร้างออบเจ็กต์ และใช้ป้ายกำกับเหล่านี้กำหนดเส้นทางข้อมูลไปยังพื้นที่จัดเก็บที่กำหนดค่าไว้อย่างเหมาะสมโดยอัตโนมัติ policy ที่ย้ายข้อมูลไปยังพื้นที่จัดเก็บที่ปลอดภัยยิ่งขึ้นโดยอัตโนมัติตามแท็กการจัดประเภท จะลดโอกาสที่ข้อมูลสำคัญจะไปอยู่ใน bucket ที่มีความปลอดภัยต่ำ
การบันทึกกิจกรรมและการตรวจสอบการเข้าถึงพื้นที่จัดเก็บบนคลาวด์
การบันทึกการเข้าถึงมีความสำคัญอย่างยิ่งต่อการตรวจจับการเข้าถึงโดยไม่ได้รับอนุญาตย้อนหลังและการตรวจสอบการปฏิบัติตามข้อกำหนด บันทึกการเข้าถึง AWS S3 และ การบันทึกเหตุการณ์ข้อมูลของ CloudTrail จะบันทึกการเรียกใช้ API ระดับออบเจ็กต์ทุกครั้งว่าใครร้องขอออบเจ็กต์ จาก IP ใด และเมื่อใด การบันทึกการวินิจฉัยของ Azure Blob และบันทึกตรวจสอบของ GCS มีความสามารถในลักษณะเดียวกัน หากไม่มีบันทึกเหล่านี้ ก็จะไม่มีหลักฐานทางนิติวิทยาศาสตร์เมื่อค้นพบการรั่วไหลของข้อมูล ทำให้ไม่สามารถระบุขอบเขตการเปิดเผยข้อมูลได้
# Enable S3 access logging
aws s3api put-bucket-logging \
--bucket my-bucket \
--bucket-logging-status '{
"LoggingEnabled": {
"TargetBucket": "my-access-logs-bucket",
"TargetPrefix": "my-bucket-logs/"
}
}'ความเสี่ยงจากการเข้าถึงข้ามบัญชี
พื้นที่จัดเก็บบนคลาวด์มักใช้ร่วมกันระหว่างบัญชีต่าง ๆ (พัฒนา เตรียมใช้งานจริง และใช้งานจริง รวมถึงคู่ค้าบุคคลที่สาม) การเข้าถึงข้ามบัญชีที่กำหนดค่าอย่างไม่รอบคอบอาจให้สิทธิ์มากเกินไป แนวปฏิบัติที่ดี ได้แก่ การใช้ ID บัญชีที่ระบุอย่างชัดเจนใน policy ของ bucket แทน Principal แบบไวลด์การ์ด การใช้ AWS Organizations SCPs เพื่อจำกัดว่าบัญชีภายนอกใดจะได้รับสิทธิ์ได้บ้าง การตรวจสอบการให้สิทธิ์ข้ามบัญชีเป็นประจำ และเลือกใช้ AWS PrivateLink แทนอินเทอร์เน็ตสาธารณะสำหรับการถ่ายโอนข้อมูลระหว่างบัญชี
การกำหนดเวอร์ชันและการป้องกันการลบ
การกำหนดเวอร์ชันของออบเจ็กต์ จะเก็บออบเจ็กต์ทุกเวอร์ชัน รวมถึงเวอร์ชันที่ถูกลบ ช่วยป้องกันการลบโดยไม่ตั้งใจ การเข้ารหัสออบเจ็กต์ด้วยแรนซัมแวร์ และภัยคุกคามจากบุคคลภายใน สำหรับข้อมูลสำคัญ ให้ใช้การกำหนดเวอร์ชันร่วมกับ Object Lock (เทียบเท่า S3 Glacier Vault Lock) ซึ่งเป็น policy แบบ WORM (เขียนครั้งเดียว อ่านได้หลายครั้ง) ที่ป้องกันการลบหรือแก้ไขในช่วงระยะเวลาเก็บรักษาที่กำหนด Object Lock สามารถตอบสนองข้อกำหนดตามกฎระเบียบสำหรับบันทึกที่แก้ไขไม่ได้ในอุตสาหกรรมการเงินและการแพทย์
# Enable S3 versioning
aws s3api put-bucket-versioning \
--bucket my-critical-bucket \
--versioning-configuration Status=Enabled
# Enable Object Lock (immutable storage)
aws s3api put-object-lock-configuration \
--bucket my-critical-bucket \
--object-lock-configuration \
'ObjectLockEnabled=Enabled,Rule={DefaultRetention={Mode=COMPLIANCE,Days=365}}'การตรวจจับการกำหนดค่าพื้นที่จัดเก็บผิดพลาดด้วย CSPM
เครื่องมือ Cloud Security Posture Management (CSPM) จะสแกนการกำหนดค่าพื้นที่จัดเก็บบนคลาวด์โดยอัตโนมัติและเปรียบเทียบกับเกณฑ์มาตรฐานด้านความปลอดภัย การตรวจสอบของ CSPM ได้แก่ มี bucket ใดเข้าถึงได้แบบสาธารณะหรือไม่ เปิดใช้การเข้ารหัสขณะจัดเก็บหรือไม่ เปิดใช้การบันทึกกิจกรรมหรือไม่ เปิดใช้การกำหนดเวอร์ชันใน bucket สำคัญหรือไม่ และ policy ของ bucket อนุญาตกว้างเกินไปหรือไม่ เครื่องมือ CSPM เช่น Prisma Cloud, Wiz และ AWS Security Hub ให้การตรวจสอบการปฏิบัติตามข้อกำหนดอย่างต่อเนื่อง และแจ้งเตือนเมื่อการกำหนดค่าเบี่ยงเบน ก่อนที่ผู้โจมตีจะค้นพบ
URL ที่ลงลายมือชื่อไว้ล่วงหน้าและการเข้าถึงชั่วคราว
URL ที่ลงลายมือชื่อไว้ล่วงหน้า ให้สิทธิ์เข้าถึงออบเจ็กต์เฉพาะรายการในช่วงเวลาจำกัด โดยผู้รับไม่จำเป็นต้องมีข้อมูลประจำตัว AWS เหมาะสำหรับการแชร์ไฟล์กับบุคคลภายนอก ความเสี่ยงด้านความปลอดภัย ได้แก่ URL ที่มีระยะเวลาหมดอายุนานเกินไปจนยังใช้งานได้นอกช่วงเวลาที่ตั้งใจแชร์ URL ที่ผู้รับส่งต่อให้บุคคลนอกกลุ่มเป้าหมาย และโทเค็นที่ฝังอยู่ใน URL ปรากฏในบันทึกของเซิร์ฟเวอร์ ควรกำหนดระยะเวลาหมดอายุที่สั้นที่สุดเท่าที่ใช้งานได้เสมอ และหลีกเลี่ยงการบันทึก URL ที่ลงลายมือชื่อไว้ล่วงหน้า
# Generate a pre-signed URL (expires in 3600 seconds)
aws s3 presign s3://my-bucket/report.pdf \
--expires-in 3600
# Returns a URL valid for 1 hour
# After expiry, the URL returns 403 Forbidden
# Best practice: shortest expiry viable for the use caseตรวจสอบความเข้าใจอย่างรวดเร็ว
ทดสอบความเข้าใจแนวคิดของ CompTIA Security+ (SY0-701) จากบทเรียนนี้
สรุปบทเรียน
ในบทเรียนนี้ คุณได้เรียนรู้ว่า การกำหนดค่า bucket แบบสาธารณะผิดพลาดเป็นสาเหตุที่พบบ่อยที่สุดของการรั่วไหลของข้อมูลจากพื้นที่จัดเก็บบนคลาวด์ SSE-KMS ให้การควบคุมการเข้ารหัสที่รัดกุมที่สุด พร้อมการบันทึกกิจกรรมตรวจสอบผ่าน CloudTrail และ การกำหนดเวอร์ชันของออบเจ็กต์ร่วมกับ Object Lock ช่วยป้องกันแรนซัมแวร์และการลบข้อมูลสำคัญโดยบุคคลภายใน บทถัดไปเราจะศึกษาอัตลักษณ์บนคลาวด์ผ่านบทบาท IAM และบัญชีบริการ
คำถามที่พบบ่อย
บทเรียน “ความปลอดภัยของพื้นที่จัดเก็บบนคลาวด์และความเสี่ยงจากการเปิดเผยข้อมูล” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “ความปลอดภัยของพื้นที่จัดเก็บบนคลาวด์และความเสี่ยงจากการเปิดเผยข้อมูล” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Security+ Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Security+ Academy มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “ความปลอดภัยของพื้นที่จัดเก็บบนคลาวด์และความเสี่ยงจากการเปิดเผยข้อมูล”
เรียนรู้ว่าการตั้งค่าบัคเก็ต S3 คอนเทนเนอร์ Azure Blob และบัคเก็ต GCS ที่ไม่ถูกต้องนำไปสู่การเปิดเผยข้อมูลได้อย่างไร รวมถึงวิธีบังคับใช้นโยบายบัคเก็ตและมาตรการควบคุมการเข้าถึง คุณปฏิบัติ Security+ Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Security+ Academy หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Security+ Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน
บทเรียน “ความปลอดภัยของพื้นที่จัดเก็บบนคลาวด์และความเสี่ยงจากการเปิดเผยข้อมูล” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Security+ Academy นี้ได้ไหม
ได้ บทเรียน Security+ Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- รูปแบบความรับผิดชอบร่วมกัน: IaaS, PaaS, SaaS
- ความปลอดภัยของพื้นที่จัดเก็บบนคลาวด์และความเสี่ยงจากการเปิดเผยข้อมูล
- อัตลักษณ์บนคลาวด์: บทบาท IAM และบัญชีบริการ
- การจัดการสถานะความปลอดภัยบนคลาวด์ (CSPM)