Cloud Security for FS

Gartner คาดการณ์ต่อเนื่องหลายปีว่า cloud incident ส่วนใหญ่มีสาเหตุจากความผิดพลาดของลูกค้า ไม่ใช่ cloud provider และส่วนใหญ่คือ misconfiguration ที่ป้องกันได้ด้วย control พื้นฐาน บทนำนี้อธิบายโมเดล shared responsibility ที่ธนาคารและบริษัทจดทะเบียนในไทยต้องเข้าใจให้ชัด พร้อมสรุปแนวปฏิบัติของ ธปท. และ ก.ล.ต. ที่เกี่ยวกับการใช้ cloud และชี้ให้เห็นว่าเหตุใด cloud security จึงต้องถูกออกแบบตั้งแต่วัน landing zone ไม่ใช่หลังจากระบบ production online

 

ประเด็นความปลอดภัยของ cloud ในสถาบันการเงินมีความเฉพาะตัวเมื่อเทียบกับอุตสาหกรรมอื่น เนื่องจากการรั่วไหลของข้อมูลลูกค้ามีผลกระทบต่อความเชื่อมั่นของทั้งภาคธุรกิจ และข้อกำหนดของ ธปท. กำหนดให้ธนาคารต้องรายงานการใช้งาน cloud ที่เก็บข้อมูลลูกค้าหรือข้อมูลทางธุรกรรมอย่างเป็นระบบ พร้อมทำ risk assessment และจัดให้มี control ในระดับเทียบเท่ากับ on-premise

 

Series G จัดโครงสร้างตามเส้นทางการใช้งาน cloud ขององค์กร ตั้งแต่ shared responsibility model, การจัดการ identity ในระดับ enterprise, การปกป้องข้อมูลในสภาพ cloud การออกแบบ workload security, การบูรณาการ DevSecOps และปิดด้วยการปฏิบัติตามแนวทางของหน่วยกำกับ ผู้อ่านจะได้รับ reference architecture ที่อ้างอิงประสบการณ์ร่วมกับธนาคารในประเทศไทย

 

ส่วนใหญ่

ของสถาบันการเงินไทยใช้บริการ public cloud อย่างน้อยหนึ่ง workload ในสภาพ production (จากการสำรวจในอุตสาหกรรมโดยสมาคม TB-CERT)

 

45%

ของ misconfiguration ใน cloud ยังคงเป็นสาเหตุอันดับหนึ่งของการรั่วไหลของข้อมูล (Verizon DBIR)

 

3 ชั้น

ของ control ที่แนวปฏิบัติของ ธปท. IT Risk Management ระบุ ครอบคลุม governance, technical และ operational

 

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

 

 

CHAPTER ONE · THE RESPONSIBILITY

 

 

Shared responsibility model ของ AWS, Azure และ GCP มีแนวคิดเดียวกัน — cloud provider รับผิดชอบ security of the cloud (hardware, network fabric, hypervisor) ขณะที่ลูกค้ารับผิดชอบ security in the cloud (data, identity, configuration, application) แต่รายละเอียดต่างกันตามประเภทบริการ — IaaS ลูกค้ารับผิดชอบมากที่สุด, PaaS กลาง ๆ, SaaS น้อยที่สุด

 

“Shared responsibility ที่ไม่เป็นลายลักษณ์อักษร = ความเข้าใจที่ต่างกันในวันที่เกิดเหตุ”

 

 

CHAPTER TWO · THE POSTURE

 

 

Cloud Security Posture Management (CSPM) เป็นเครื่องมือที่ scan configuration ของ cloud resource อย่างต่อเนื่อง เพื่อหา misconfiguration เช่น S3 bucket ที่เปิด public, security group ที่เปิด 0.0.0.0/0 ไปที่ database, IAM role ที่มี AdministratorAccess เครื่องมือ native เช่น AWS Security Hub, Azure Defender for Cloud, GCP Security Command Center เริ่มเพียงพอสำหรับองค์กรขนาดเล็ก-กลาง ขณะที่ third-party เช่น Wiz, Orca, Prisma Cloud เหมาะสำหรับ multi-cloud และ organization ขนาดใหญ่

 

“CSPM ที่มี finding 10,000 รายการแต่ไม่มี owner = noise ไม่ใช่ security”

 

 

CHAPTER THREE · THE IDENTITY

 

 

ใน cloud ที่ network perimeter จางลง identity กลายเป็น control plane หลัก การโจมตีส่วนใหญ่ใน cloud เริ่มจาก identity compromise — phishing, credential stuffing, หรือ token theft — ก่อนที่ผู้โจมตีจะเคลื่อนไหวภายในผ่าน IAM role ที่มีสิทธิ์กว้าง

 

Cloud IAM ที่ดีต้องมี MFA (ไม่ใช่ SMS), least privilege (ใช้ service-control policies, permission boundaries), just-in-time access (AWS IAM Identity Center, Azure PIM), และ workload identity ที่ไม่ใช้ long-lived access key การนำ IAM Access Analyzer หรือเทียบเท่ามาใช้ช่วยระบุ role ที่มี permission เกินกว่าที่ใช้จริง

 

“Identity คือ perimeter ใหม่ — ถ้า identity compromise, cloud ทั้งหมดเปิดออก”

 

 

CHAPTER FOUR · THE DATA

 

 

Data encryption ใน cloud มี 3 ระดับ — at rest (S3, EBS, RDS), in transit (TLS), in use (confidential computing) Cloud provider มี encryption at rest เป็น default แล้ว แต่ประเด็นสำคัญคือ key management — ใครถือ key, เก็บที่ไหน, rotate อย่างไร BYOK (Bring Your Own Key) และ HYOK (Hold Your Own Key) เป็นตัวเลือกสำหรับ FS ที่ต้องการ control มากกว่า default provider-managed key

 

“Encryption at rest ไม่ช่วยถ้า key ถูกเก็บอยู่ใกล้ข้อมูลที่มันปกป้อง”

 

 

CHAPTER FIVE · THE WORKLOAD

 

 

Workload protection ใน cloud แบ่งเป็น 3 รูปแบบหลัก — VM ยังต้องการ EDR/antivirus เหมือน on-premise, container ต้องมี image scanning (Trivy, Snyk, Prisma), runtime protection (Falco, Aqua, Sysdig), และ admission controller ที่บังคับ policy ก่อน deploy, ส่วน serverless มี attack surface น้อยกว่าแต่มีความเสี่ยงเฉพาะทาง เช่น over-privileged function, exposed endpoint

 

“Container ที่ไม่ scan image = การ deploy ช่องโหว่ที่เร็วและ scalable”

 

 

CHAPTER SIX · THE REGULATOR

 

 

ธนาคารแห่งประเทศไทยออก ประกาศเรื่อง IT Risk Management ที่กำหนดแนวทางการใช้ cloud สำหรับธนาคาร ได้แก่ การประเมิน risk ก่อนย้าย critical workload, การมี exit strategy, การทดสอบ DR, และการ monitor ความเสี่ยงของ provider ก.ล.ต. มีข้อกำหนดสำหรับ brokers และ asset management ที่ใกล้เคียงกัน PDPC ออก guideline เรื่อง data protection ใน cloud ที่เน้น controller-processor relationship

 

“ธปท. ไม่ได้ห้ามใช้ cloud — แต่คาดหวังว่าคุณมี control ที่เท่ากับ on-premise”

 

 

CHAPTER SEVEN · THE DELIVERY

 

 

DevSecOps ที่ทำงานในบริบท FS ต้องไม่ทำให้ release slow ลง — ถ้า security process ช้ากว่า dev process 2 เท่า นักพัฒนาจะหาทางเลี่ยง การออกแบบที่ใช้ได้คือ 'guardrail' — security check ที่ฝังใน pipeline โดยอัตโนมัติ (SAST, SCA, IaC scanning, secret detection) และ fail-fast เมื่อพบปัญหา โดย dev team แก้ได้เองก่อน push to PR review

 

“DevSecOps ที่ช้ากว่า DevOps เดิม = คนจะหาทางเลี่ยง — ต้องออกแบบให้เป็น guardrail ไม่ใช่ gate”

 

 

ในภาค FS ของไทย การย้ายสู่ cloud ไม่ใช่คำถามว่า 'เมื่อไหร่' อีกต่อไป แต่คือ 'จะย้ายอย่างไรให้ปลอดภัยและตอบผู้กำกับได้' Cloud security ที่ออกแบบดีเป็น enabler ที่ทำให้ธนาคารเปิดตัว product ใหม่ได้เร็วขึ้น ขณะที่รักษา control ที่เท่าหรือดีกว่า on-premise

 

หากท่านต้องการเนื้อหาฉบับเต็มที่ครอบคลุมทุกบท พร้อมแนวปฏิบัติเชิงเทคนิค ตัวอย่าง workflow และคำศัพท์เฉพาะทาง กดตาม URL นี้เพื่อดาวน์โหลด: