ความปลอดภัยบนคลาวด์

01คลาวด์ คือคอมพิวเตอร์ของคนอื่น ที่เราเช่าใช้ What the cloud really is

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

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

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

แล้วคลาวด์คืออะไรกันแน่ คำนิยามที่วงการใช้อ้างอิงมาจากเอกสาร NIST SP 800-145 ของสหรัฐฯ ถ้าพูดแบบบ้าน ๆ คือ การเช่าใช้ทรัพยากรคอมพิวเตอร์ของผู้ให้บริการผ่านอินเทอร์เน็ต ทั้งเครื่องเซิร์ฟเวอร์ พื้นที่เก็บข้อมูล ฐานข้อมูล ไปจนถึงตัวแอปสำเร็จรูป โดยมีลักษณะสำคัญห้าข้อ:

• บริการตัวเองได้ตามต้องการ (On-demand self-service): อยากได้เครื่องเพิ่มก็กดสร้างเองได้ทันที ไม่ต้องโทรสั่งซื้อ
• เข้าถึงได้ผ่านเครือข่าย (Broad network access): ใช้งานจากที่ไหนก็ได้ที่มีอินเทอร์เน็ต
• ใช้ทรัพยากรร่วมกัน (Resource pooling): ลูกค้าหลายรายใช้ฮาร์ดแวร์ชุดเดียวกัน โดยถูกแยกออกจากกัน
• ยืดหดได้รวดเร็ว (Rapid elasticity): ช่วงคนใช้เยอะก็ขยาย ช่วงเงียบก็ลด
• คิดเงินตามที่ใช้จริง (Measured service): ใช้เท่าไรจ่ายเท่านั้น ซึ่งก็แปลว่า ถ้าคนร้ายแอบใช้แทนเรา เราก็จ่ายเงินแทนเขาด้วย

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

ศัพท์น่ารู้: ภูมิภาค (Region) และบัญชีคลาวด์ (Cloud account)

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

02ใครดูแลอะไร: โมเดลความรับผิดชอบร่วม Shared responsibility

หัวใจของความปลอดภัยบนคลาวด์มีชื่อเรียกว่า โมเดลความรับผิดชอบร่วม (Shared Responsibility Model) ผู้ให้บริการรายใหญ่ทุกเจ้าเผยแพร่โมเดลนี้ไว้ AWS สรุปด้วยวลีที่จำง่ายที่สุดว่า ผู้ให้บริการดูแล “ความปลอดภัยของคลาวด์” (security of the cloud) คือโครงสร้างพื้นฐานทั้งหมดที่บริการทำงานอยู่ ส่วนลูกค้าดูแล “ความปลอดภัยในคลาวด์” (security in the cloud) คือทุกอย่างที่เราเอาไปใส่และตั้งค่าเอง

เส้นแบ่งนี้ไม่ได้อยู่ที่เดิมตลอด มันเลื่อนขึ้นลงตามแบบบริการที่เราเลือก ซึ่งแบ่งเป็นสามแบบหลัก:

• IaaS (Infrastructure as a Service): เช่า “เครื่องเปล่า” เช่น เครื่องเสมือน เราต้องติดตั้งและอัปเดตระบบปฏิบัติการเอง ตั้งไฟร์วอลล์เอง
• PaaS (Platform as a Service): เช่า “แพลตฟอร์ม” เช่น ฐานข้อมูลสำเร็จรูป หรือบริการรันโค้ดที่เราแค่อัปโหลดแอปขึ้นไป ผู้ให้บริการดูแลระบบปฏิบัติการให้
• SaaS (Software as a Service): ใช้ “แอปสำเร็จรูป” เช่น อีเมลองค์กร ไดรฟ์เก็บไฟล์ ระบบประชุมออนไลน์ เราแค่ล็อกอินใช้

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

Microsoft เขียนไว้ตรง ๆ ในเอกสารของตัวเองว่า สิ่งที่ลูกค้า “รับผิดชอบเสมอ” ไม่ว่าจะใช้บริการแบบไหน คือข้อมูล อุปกรณ์ปลายทาง บัญชีผู้ใช้ และการจัดการสิทธิ์เข้าถึง Google Cloud เองก็ต่อยอดแนวคิดนี้เป็น “shared fate” ที่ผู้ให้บริการพยายามช่วยลูกค้าตั้งค่าให้ปลอดภัยตั้งแต่แรก แต่เส้นแบ่งความรับผิดชอบก็ยังอยู่ที่เดิม

ศัพท์น่ารู้: การตั้งค่าผิดพลาด (Misconfiguration)

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

03ห้าประตูที่มักลืมปิด Common cloud failures

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

มาดูทีละบาน:

1. ที่เก็บไฟล์เปิดสาธารณะ (Public storage bucket)

   บริการเก็บไฟล์บนคลาวด์อย่าง Amazon S3, Azure Blob Storage หรือ Google Cloud Storage ตั้งให้ “ใครก็อ่านได้” ได้ในไม่กี่คลิก บางคนเปิดไว้ชั่วคราวเพื่อแชร์ไฟล์ให้เพื่อน แล้วลืมปิด ปัจจุบันผู้ให้บริการหลายรายตั้งค่าเริ่มต้นให้บล็อกการเข้าถึงสาธารณะไว้ก่อนแล้ว ถ้าเจอใครแนะนำให้ปิดตัวบล็อกนี้ ให้หยุดคิดก่อนทุกครั้ง

2. สิทธิ์ล้นมือ (Over-permissive IAM)

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

3. กุญแจหลุดในคลังโค้ด (Leaked keys)

   กุญแจเข้าถึงบัญชีคลาวด์แบบถาวร (access key) ที่ฝังอยู่ในโค้ด แล้วโค้ดถูก push ขึ้นที่สาธารณะ เป็นต้นเหตุคลาสสิกของบิลค่าคลาวด์พุ่งและข้อมูลรั่ว คดี Uber ปี 2016 ที่เราเล่าไว้ใน CASE-020 ก็เริ่มจากกุญแจ AWS ที่อยู่ในคลังโค้ด

4. แอดมินไม่มี MFA

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

5. บริการเปิดค้างและไม่อัปเดต (Exposed, unpatched services)

   เครื่องเสมือนที่เปิดช่องจัดการระบบอย่าง SSH หรือ Remote Desktop หรือเปิดพอร์ตฐานข้อมูลให้ทั้งอินเทอร์เน็ตเข้าได้ แถมไม่ได้อัปเดตแพตช์ ในแบบ IaaS การอัปเดตระบบปฏิบัติการเป็นหน้าที่ของเราเต็มตัว ไม่มีใครทำให้

04IAM และหลักสิทธิ์น้อยที่สุด Cloud IAM & least privilege

ในโลกคลาวด์ มีคำพูดที่คนในวงการชอบใช้ว่า “ตัวตนคือรั้วใหม่” (Identity is the new perimeter) สมัยก่อนเราป้องกันด้วยไฟร์วอลล์รอบออฟฟิศ แต่บนคลาวด์ ทุกอย่างสั่งงานได้ผ่านอินเทอร์เน็ต ด้วยบัญชีและกุญแจที่ถูกต้อง ใครถือกุญแจที่ถูกต้อง ระบบก็เชื่อทุกคำสั่ง ไม่ว่าเขาจะนั่งอยู่ที่ไหน

ระบบที่คุมเรื่องนี้เรียกว่า IAM (Identity and Access Management) มันตอบคำถามสามข้อในทุกคำขอ: ใคร (ผู้ใช้ แอป หรือบริการ) จะทำ อะไร (อ่าน เขียน ลบ) กับ ทรัพยากรไหน (ที่เก็บไฟล์ไหน ฐานข้อมูลไหน) คำตอบถูกเขียนไว้ในเอกสารสิทธิ์ที่เรียกว่า นโยบาย (Policy)

นี่คือ หลักสิทธิ์น้อยที่สุด (Principle of least privilege) ที่เราเจอมาแล้วใน CASE-010 และ CASE-019 แต่บนคลาวด์มันสำคัญเป็นพิเศษ เพราะสิทธิ์หนึ่งบรรทัดอาจเปิดทางไปถึงข้อมูลนับล้านแถว ลองเทียบนโยบายสองแบบนี้ (เขียนตามรูปแบบของ AWS แต่แนวคิดเหมือนกันทุกเจ้า):

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::school-app-files/reports/*"
}

นิสัยที่ช่วยให้ทำตามหลักนี้ได้จริง:

• เริ่มจากศูนย์ แล้วค่อยเพิ่ม: ให้สิทธิ์น้อยไว้ก่อน ถ้าแอปทำงานไม่ได้ค่อยเพิ่มทีละข้อ ดีกว่าเริ่มจากทุกอย่างแล้วตั้งใจจะมาลดทีหลัง (ซึ่งมักไม่เคยได้ลด)
• ใช้บทบาทกับกุญแจชั่วคราว แทนกุญแจถาวร: แอปที่รันบนคลาวด์ควรได้สิทธิ์ผ่าน “บทบาท (Role)” ที่ระบบออกกุญแจอายุสั้นให้อัตโนมัติ ถ้าหลุด กุญแจก็หมดอายุเองในไม่ช้า ไม่ต้องมีใครพก access key ถาวรติดตัว
• แยกคนแยกงาน: แต่ละคนในทีมมีบัญชีของตัวเอง ไม่ใช้บัญชีเดียวกันทั้งกลุ่ม จะได้รู้ว่าใครทำอะไร และถอนสิทธิ์ได้ทีละคน
• เก็บบัญชีเจ้าของไว้ในตู้เซฟ: บัญชี root หรือเจ้าของบัญชีมีอำนาจเหนือทุกนโยบาย ใช้เฉพาะงานที่จำเป็นจริง ๆ เปิด MFA ไว้ แล้วใช้บัญชีปกติทำงานประจำวัน
• ทบทวนสิทธิ์เป็นรอบ: ผู้ให้บริการหลายรายมีเครื่องมือบอกว่าสิทธิ์ไหนได้รับแต่ไม่เคยถูกใช้ ตัดทิ้งได้เลย

05กุญแจ การเข้ารหัส และ KMS Encryption & key management

ข้อมูลบนคลาวด์ควรถูกเข้ารหัสสองสถานะ: ตอน เดินทาง (in transit) ซึ่งก็คือ HTTPS/TLS ที่เราเรียนใน CASE-009 และตอน เก็บอยู่เฉย ๆ (at rest) บนดิสก์ของผู้ให้บริการ ข่าวดีคือบริการเก็บข้อมูลหลัก ๆ ทุกวันนี้เข้ารหัสข้อมูลที่เก็บไว้ให้เป็นค่าเริ่มต้นอยู่แล้ว คำถามที่น่าสนใจกว่าคือ กุญแจอยู่ที่ไหน และใครใช้กุญแจได้

เพราะการเข้ารหัสเก่งแค่ไหน ก็ดีเท่ากับการเก็บกุญแจเท่านั้น ถ้าวางกุญแจไว้ข้างตู้เซฟ ตู้เซฟก็ไม่มีความหมาย บริการที่แก้ปัญหานี้เรียกว่า KMS (Key Management Service) เปรียบเหมือนตู้นิรภัยของธนาคารที่เก็บ “กุญแจหลัก” ไว้ และกุญแจหลักไม่เคยถูกนำออกจากตู้ ใครอยากใช้ต้องมาขอให้ตู้ทำงานให้ และทุกครั้งที่ขอ จะถูกตรวจสิทธิ์และถูกจดบันทึก

เทคนิคในภาพเรียกว่า การเข้ารหัสแบบซองซ้อน (Envelope encryption) คือเอาข้อมูลใส่ซองที่ล็อกด้วยกุญแจข้อมูล แล้วเอากุญแจข้อมูลใส่ซองอีกชั้นที่ล็อกด้วยกุญแจหลัก ข้อดีคือข้อมูลก้อนใหญ่ไม่ต้องวิ่งไปมาที่ KMS เลย วิ่งไปแค่กุญแจเล็ก ๆ

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

ศัพท์น่ารู้: Secret Manager

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

06บันทึกทุกการกระทำ เฝ้าดู และตรวจสุขภาพอัตโนมัติ Audit logs, alerts & CSPM

ข้อดีที่คนมักมองข้ามของคลาวด์ คือทุกการกระทำเกิดขึ้นผ่านคำสั่ง (API) ทั้งหมด ไม่มีใครเดินเข้าห้องเซิร์ฟเวอร์ไปถอดสายได้ ทุกคำสั่งจึง ถูกจดบันทึกได้ ว่าใคร ทำอะไร กับอะไร เมื่อไร จากที่ไหน บริการบันทึกเหล่านี้มีชื่อต่างกันไปตามเจ้า เช่น AWS CloudTrail, Azure Activity Log หรือ Google Cloud Audit Logs

{
  "eventTime": "2026-03-14T02:47:09Z",
  "eventName": "PutBucketPolicy",
  "userIdentity": { "type": "IAMUser", "userName": "report-app" },
  "sourceIPAddress": "203.0.113.77",
  "requestParameters": { "bucketName": "customer-data",
                         "policy": "Principal: * / Action: s3:GetObject" }
}
// ตีสองกว่า บัญชีของแอปรายงาน (ซึ่งไม่ควรแก้นโยบายได้เลย) เปลี่ยนที่เก็บข้อมูลลูกค้าให้ทุกคนอ่านได้ จาก IP ที่ไม่เคยเห็น

บันทึกจะมีค่าก็ต่อเมื่อมีคนหรือระบบอ่านมัน เหตุการณ์ที่ควรตั้งให้แจ้งเตือนทันทีมีไม่กี่อย่าง แต่จับเรื่องร้ายได้เยอะ:

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

การไล่ตรวจการตั้งค่าเองทีละบริการ ทำไม่ไหวเมื่อระบบใหญ่ขึ้น จึงเกิดเครื่องมือกลุ่ม CSPM (Cloud Security Posture Management) ที่คอยสแกนการตั้งค่าทั้งบัญชีอย่างต่อเนื่อง เทียบกับแนวปฏิบัติที่ดี เช่น CIS Benchmarks แล้วแจ้งว่า “ที่เก็บไฟล์นี้เปิดสาธารณะ” “บัญชีนี้ไม่มี MFA” “พอร์ตฐานข้อมูลเปิดให้ทั้งโลก” ผู้ให้บริการรายใหญ่มีเครื่องมือแนวนี้ของตัวเอง เช่น AWS Security Hub, Microsoft Defender for Cloud และ Google Security Command Center

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

07คดีจริง: Capital One 2019 A real case

ถ้ามีคดีไหนที่สรุปบทเรียนบนคลาวด์ไว้ครบในเรื่องเดียว ก็คือคดีของ Capital One ธนาคารใหญ่ของสหรัฐฯ ที่ย้ายระบบขึ้น AWS อย่างจริงจัง และถูกยกย่องว่าเป็นองค์กรที่ใส่ใจความปลอดภัยบนคลาวด์ในยุคนั้น

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

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

08เผื่อวันที่ทุกอย่างพัง Backups across regions & accounts

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

บทเรียนที่วงการไม่เคยลืมมาจากบริษัทเก็บโค้ดชื่อ Code Spaces ในปี 2014 คนร้ายเข้าคุมหน้าควบคุมบัญชีคลาวด์ของบริษัทได้ แล้วลบทั้งข้อมูลและข้อมูลสำรองที่อยู่ในบัญชีเดียวกันทิ้ง จนบริษัทต้องปิดกิจการ ข้อมูลสำรองที่อยู่ “ในห้องเดียวกับต้นฉบับ” ไม่ได้ช่วยอะไรเลยเมื่อคนร้ายได้กุญแจห้องไป

หลักคิดจึงต่อยอดจากกฎ 3-2-1 ที่เราเรียนใน CASE-002 ให้เข้ากับคลาวด์:

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

09เช็กลิสต์สำหรับโปรเจกต์นักเรียนบนคลาวด์ A student project checklist

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

1. ล็อกบัญชีเจ้าของให้แน่น

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

2. ตั้งงบประมาณและการแจ้งเตือนค่าใช้จ่าย

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

3. ห้ามมีกุญแจในโค้ด

   ใส่ไฟล์ .env และไฟล์กุญแจไว้ใน .gitignore ตั้งแต่คอมมิตแรก เปิด push protection ของ GitHub ไว้ และถ้าเผลอหลุด ให้ยกเลิกกุญแจนั้นทันที ก่อนจะไปลบประวัติ

4. ที่เก็บไฟล์เป็นส่วนตัวไว้ก่อน

   อย่าปิดการบล็อกสาธารณะ ถ้าต้องแชร์ไฟล์ ใช้ลิงก์ที่มีวันหมดอายุ (pre-signed URL) แทนการเปิดทั้งที่เก็บ

5. เปิดพอร์ตเท่าที่ต้องใช้

   อย่าตั้งกฎไฟร์วอลล์ให้ SSH หรือฐานข้อมูลรับการเชื่อมต่อจาก 0.0.0.0/0 (ทั้งอินเทอร์เน็ต) จำกัดเฉพาะ IP ของเรา หรือใช้ช่องทางจัดการที่ผู้ให้บริการเตรียมไว้

6. เปิดบันทึกการตรวจสอบ

   เปิดไว้ตั้งแต่วันแรก ถ้าเกิดเรื่องจะได้รู้ว่าใครทำอะไรไปบ้าง

7. ไม่ใช้ข้อมูลส่วนบุคคลจริงในงานทดลอง

   ใช้ข้อมูลสมมติแทนชื่อ เบอร์โทร หรือเลขประจำตัวของเพื่อนจริง ข้อมูลส่วนบุคคลมีกฎหมายคุ้มครองข้อมูลส่วนบุคคล (PDPA) กำกับอยู่ และข้อมูลที่ไม่มี ก็รั่วไม่ได้

8. จบโปรเจกต์ แล้วเก็บของ

   ลบเครื่อง ฐานข้อมูล และกุญแจที่ไม่ใช้แล้ว ติดป้าย (tag) ทรัพยากรด้วยชื่อโปรเจกต์ตั้งแต่สร้าง จะได้ตามลบครบ ของที่ถูกลืมไว้คือของที่ไม่มีใครอัปเดต

10สรุปให้จำ Recap

คลาวด์คือห้องเช่าในตึกที่แข็งแรงมาก แต่กุญแจห้องอยู่ในมือเรา ถ้าจำได้แค่หกข้อ ให้จำหกข้อนี้

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

ลองทบทวนดู