Encryption, Access Control, Security Practices

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

ความปลอดภัยบนคลาวด์เป็นความรับผิดชอบร่วม ผู้ให้บริการดูแล "security of the cloud" คือความปลอดภัยของ data center, hardware, เครือข่ายกายภาพ และ infrastructure พื้นฐาน ส่วนลูกค้าดูแล "security in the cloud" คือการตั้งค่า การจัดการสิทธิ์ การปกป้องข้อมูล และการกำหนดว่าใครเข้าถึงอะไร เส้นแบ่งนี้เลื่อนตามโมเดลบริการ ยิ่งใช้ IaaS ลูกค้ายิ่งรับผิดชอบมาก ยิ่งใช้ SaaS ผู้ให้บริการยิ่งรับผิดชอบมาก การอธิบายเรื่องนี้ชัดทำให้ลูกค้าเข้าใจว่าคลาวด์ไม่ได้แปลว่าปลอดภัยอัตโนมัติ แต่ก็ไม่ได้แปลว่าต้องดูแลทุกอย่างเอง

ข้อมูลมีสามสถานะที่ต้องปกป้อง:

Encryption at rest (ข้อมูลที่จัดเก็บ): เข้ารหัสข้อมูลที่นอนอยู่ใน storage หรือ database GCP เข้ารหัส at rest ให้เป็นค่าเริ่มต้นอัตโนมัติทุก service โดยลูกค้าไม่ต้องทำอะไร

Encryption in transit (ข้อมูลระหว่างส่ง): เข้ารหัสข้อมูลขณะเดินทางผ่านเครือข่ายด้วย TLS เพื่อกันการดักฟัง GCP เข้ารหัส traffic ภายในเครือข่ายและกับผู้ใช้

Encryption in use (ข้อมูลระหว่างประมวลผล): ขั้นสูงสุด ปกป้องข้อมูลแม้ตอนกำลังประมวลผลใน memory ด้วย Confidential Computing ที่เข้ารหัส memory ของ VM เหมาะ workload ที่อ่อนไหวมาก

การจัดการ key มีสามระดับ: Google-managed keys (Google ดูแลให้หมด ง่ายสุด), Customer-managed encryption keys หรือ CMEK (ลูกค้าคุม key ผ่าน Cloud KMS เลือกได้ว่าจะหมุนเวียนหรือเพิกถอนเมื่อไหร่), และ Customer-supplied encryption keys หรือ CSEK (ลูกค้านำ key ของตัวเองมา คุมสูงสุดแต่รับผิดชอบเองหมด) ลูกค้าสาย regulated มักต้องการ CMEK เพื่อคุม key เอง

IAM คือหัวใจของ access control บน GCP ตอบคำถามว่า "ใคร (identity) ทำอะไรได้ (role/permission) กับทรัพยากรไหน (resource)"

แนวคิดสำคัญ:

• Authentication กับ Authorization ต่างกัน: authentication คือพิสูจน์ว่าคุณเป็นใคร authorization คือกำหนดว่าคุณทำอะไรได้
• Principle of least privilege: ให้สิทธิ์เท่าที่จำเป็นต่อการทำงานเท่านั้น ไม่ให้เกิน เป็นหลักการที่ต้องพูดถึงทุกครั้ง
• Roles: GCP มี predefined role ที่ออกแบบมาให้พอดีกับงาน และ custom role สำหรับกรณีเฉพาะ ควรเลี่ยง basic role ที่กว้างเกินอย่าง owner/editor ในงานจริง
• Service accounts: identity สำหรับให้ระบบหรือแอปคุยกันอย่างปลอดภัย แทนการฝัง credential ของคน ควรจำกัดสิทธิ์ service account ให้แคบและหมุนเวียน key
• IAM policy hierarchy: สิทธิ์สืบทอดตามลำดับชั้น organization แล้ว folder แล้ว project แล้ว resource ทำให้บริหารสิทธิ์เป็นระบบ
• MFA และ context-aware access: เพิ่มชั้นยืนยันตัวตนและพิจารณา context เช่นอุปกรณ์และตำแหน่ง

การปกป้องระดับเครือข่ายเป็นอีกชั้น:

• VPC และ firewall rules: แยก subnet public กับ private กำหนดกฎว่า traffic ไหนเข้าออกได้
• Cloud Armor: WAF และ DDoS protection กรองการโจมตีก่อนถึงแอป
• VPC Service Controls: สร้าง security perimeter รอบ service และข้อมูล เพื่อกันข้อมูลรั่วออกนอกขอบเขต แม้ credential หลุดก็ยังกันได้
• Private Google Access และ Private Service Connect: ให้ resource เข้าถึง Google API แบบไม่ผ่าน public internet
• Identity-Aware Proxy (IAP): ควบคุมการเข้าถึงแอปตามตัวตนผู้ใช้แทนการเปิด VPN

Defense in depth คือการป้องกันหลายชั้นซ้อนกัน เพื่อว่าถ้าชั้นหนึ่งถูกเจาะ ยังมีชั้นอื่นกันอยู่ ไม่พึ่งกำแพงเดียว ครอบคลุมตั้งแต่ network, identity, application, data ถึง monitoring

Zero trust คือแนวคิด "ไม่เชื่อใครโดยอัตโนมัติ" แม้อยู่ใน network เดียวกัน ทุกการเข้าถึงต้องพิสูจน์ตัวตนและตรวจ context ทุกครั้ง ต่างจากโมเดลเดิมที่เชื่อทุกอย่างที่อยู่ใน perimeter ภายใน Google ใช้แนวทางนี้ในชื่อ BeyondCorp ซึ่งให้พนักงานเข้าถึงแอปได้ตามตัวตนและอุปกรณ์โดยไม่ต้องพึ่ง VPN

• Security Command Center: ศูนย์รวมมองเห็นภัยคุกคาม ช่องโหว่ และสถานะ compliance ทั้งองค์กร
• Audit logging: บันทึกว่าใครทำอะไรเมื่อไหร่ จำเป็นต่อการสืบสวนและ compliance
• Cloud Logging และ Cloud Monitoring: เก็บ log และเฝ้าระวังความผิดปกติ
• Compliance frameworks: ควรรู้จักชื่อกรอบที่ลูกค้าถาม เช่น ISO 27001, SOC 2, PCI DSS (สำหรับบัตรเครดิต), HIPAA (สุขภาพ) และในไทยคือ PDPA สำหรับข้อมูลส่วนบุคคล GCP มี certification และ compliance รองรับหลายมาตรฐาน ซึ่งช่วยลดภาระลูกค้าในการพิสูจน์ compliance
• Data residency: ความต้องการให้ข้อมูลอยู่ในภูมิภาคหรือประเทศที่กำหนด ตอบได้ด้วยการเลือก region และนโยบายควบคุมตำแหน่งข้อมูล

ถาม: "GCP รักษาความปลอดภัยข้อมูลอย่างไร" ตอบ: เล่าสามชั้น encryption (at rest อัตโนมัติ, in transit, in use), IAM least privilege, network security และ monitoring พร้อมอธิบาย shared responsibility

ถาม: "ลูกค้ากลัวว่าข้อมูลบนคลาวด์ไม่ปลอดภัยเท่า on-prem จะตอบอย่างไร" ตอบ: อธิบายว่าคลาวด์มีการลงทุนด้านความปลอดภัยและ compliance ระดับที่องค์กรส่วนใหญ่ทำเองได้ยาก เข้ารหัสเป็นค่าเริ่มต้น มี certification มาตรฐานสากล และอธิบาย shared responsibility ว่าลูกค้ายังคุมส่วนของตัวเองได้

ถาม: "ความต่างของ authentication กับ authorization" ตอบ: authentication พิสูจน์ตัวตน authorization กำหนดสิทธิ์ พร้อมตัวอย่าง

ถาม: "least privilege คืออะไรทำไมสำคัญ" ตอบ: ให้สิทธิ์เท่าที่จำเป็น ลดความเสียหายเมื่อ credential หลุดหรือถูกใช้ผิด

ถาม: "ลูกค้าต้องคุม encryption key เอง ทำอย่างไร" ตอบ: ใช้ CMEK ผ่าน Cloud KMS หรือ CSEK ถ้าต้องคุมสูงสุด

มองความปลอดภัยเป็นจุดเดียวแทนที่จะเป็นหลายชั้น; ไม่เข้าใจ shared responsibility จึงตอบผิดว่าใครดูแลอะไร; สับสน authentication กับ authorization; ลืมพูด least privilege; ไม่รู้จักชื่อ compliance framework ที่ลูกค้าถาม; ตอบเรื่อง encryption แต่ไม่แยกสามสถานะ; มองข้าม data residency ทั้งที่เป็นข้อกังวลใหญ่ของลูกค้าในภูมิภาค

ความปลอดภัยคือเรื่องของหลายชั้นซ้อนกัน เริ่มจากเคลียร์ shared responsibility เข้ารหัสครบสามสถานะโดย at rest เป็นค่าเริ่มต้นบน GCP ใช้ IAM แบบ least privilege และ service account ปกป้องเครือข่ายด้วย VPC, Cloud Armor และ VPC Service Controls ยึดหลัก defense in depth และ zero trust มองเห็นทุกอย่างผ่าน Security Command Center และ audit log และรู้จัก compliance framework กับ data residency เพื่อตอบลูกค้าสาย regulated ได้ เป้าหมายสูงสุดคือเปลี่ยนความกลัวของลูกค้าให้เป็นความมั่นใจ