เมื่อ Kernel หมดยุค "ไว้ใจได้" : เจาะลึก Modern Kernel Design ภายใต้แนวคิด Zero-Trust Architecture

ก่อนหน้านี้ เราทำคลิปใน Youtube พูดถึง Modern OS Security ทั้งฝั่ง macOS และ Windows ไปแล้ว หนึ่งในคำที่เราพูดถึงเยอะมากคือ Zero-Trust Security ตั้งแต่ใน Kernel วันนี้เราอยากจะมาเล่าให้อ่านกันว่า เขามีการเอา Concept นี้เข้ามาใช้กันอย่างไรบ้าง

จุดเปลี่ยนที่สำคัญ

หลัง ๆ ภัยคุกคามบนคอมพิวเตอร์มันหาวิธีการที่ซับซ้อนมากขึ้นเรื่อย ๆ มาสู้ จนตอนนี้ เล่นกันยันระดับแทรกซึมเข้ามาใน OS กันแล้ว ตัว Kernel หรือ แกนกลางของ OS ที่คอยจัดการทรัพยากรทุกอย่าง ไม่ว่าจะเป็น CPU, Memory หรือ Storage สมัยก่อน เราไม่ได้มีอะไรที่น่ากลัวขนาดนี้ ทำให้เรามักจะออกแบบมาให้มันเชื่อใจ (Trust) ทุกอย่างที่อยู่ในระบบ แบบ 100%

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

นี่แหละคือจุดอ่อน ที่ทำให้ระบบแตกกันมาหลายดอกแล้ว แต่ในโลกยุคปัจจุบัน เราก้าวเข้าสู่ยุค Cloud-Native และ Containerised Architecture กันแบบเต็มตัว ระบบของเราไม่ได้เป็น Physical Server อีกต่อไป เรามีการรัน Container นับพันตัว มีการดึง 3rd Party Library เข้ามาใช้งานมากมาย เส้นแบ่งเขตแดน มันเริ่มเบลอ ๆ ลงไปจนแทบไม่มีอยู่จริงแล้ว ถ้าเกิด Hacker เจอช่องโหว่เล็ก ๆ ใน App แล้วทำ Privilege Escalation ยกระดับสิทธิ์เข้า Kernel ได้ ก็คือ เหมือนบ้านเราโดนปล้นแล้วละ

มันเลยเป็นจุดเปลี่ยนสำคัญในวงการ System Engineering เราไม่สามารถพึ่งพายามหน้าบ้านเป็นกลไกเดียวได้อีกต่อไป และนี่แหละ คือที่มาของ Concept อย่าง Zero-Trust Architecture หรือหลักการ "Never Trust, Always Verify" มายัด ตั้งแต่ Application ยัน Kernel ที่อยู่ส่วนลึกสุดของ OS

Zero-Trust ในระดับ Kernel คืออะไร ?

ปกติเวลาเราได้ยินคำว่า Zero-Trust เรามักจะคุ้นเคยกับการเอาไปใช้งานในฝั่ง Network เช่นการทำ VPN แต่พอเราเอา Concept นี้เข้ามาใช้บน Low-Level System มาก ๆ อย่าง การทำงานของ CPU และ Memory เรากำลังพูดถึงคำว่า Compute Zero-Trust

Core Concept ของมันคือ การเลิกไว้ใจ ทุก Process และ Application ที่รันอยู่ใน OS โดยมีหลักที่ต้องทำทั้งหมด 3 อย่าง ที่ Modern Kernel พยายาม Implement เข้ามา

อย่างแรกคือ Least Privilege คือ แต่ละ Application จะได้รับสิทธิ์เฉพาะสิ่งที่มันจำเป็นต้องใช้งานจริง ๆ เพื่อลด Attack Surface ให้เหลือน้อยที่สุด เพราะเมื่อก่อน App หลาย ๆ ตัวมักง่าย เขียนรอสิทธิ์ Administrator ไว้ก่อน เพื่อให้ทำงานสะดวก แล้วแตกกันมาเยอะแล้ว

อย่างที่ 2 คือ Micro-Segmentation แทนที่จะให้ Process ต่าง ๆ วิ่งเล่น เข้าถึง Memory ก้อนเดียวกันได้แบบถึงกันหมด เราจะจับมันขังอยู่ใน Sandbox ของตัวเอง ถ้ามี Process ไหนเกิดแตก Hacker เล่นแล้ว มันจะพังอยู่แค่ตรงนั้น ไม่ลามไปส่วนอื่น ๆ

อย่างที่ 3 คือ Continuous Verification คือ ไม่ใช่แค่ว่า Application เริ่มการทำงานแล้ว จบอะไร ๆ ก็ปลอดภัยแล้ว แต่ Kernel จะต้องคอยดักฟังและตรวจสอบการเรียก System Call ทุกครั้งว่า Process นี้มีอะไรที่น่าสงสัยมั้ย มีการขอเปิด หรือเข้าถึงไฟล์ระบบอะไรที่มันไม่สมควรจะทำมั้ย

Tech Stack กลไก และเทคโนโลยีเบื้องหลัง

ถามว่า ทฤษฏีเป็นแบบนี้ แล้วโลกจริงเขาสร้างเครื่องมืออะไรขึ้นมา เพื่อทำให้ Kernel ขี้ระแวงได้อย่างมีประสิทธิภาพบ้าง

อย่างแรก ช่วงนี้กำลังมาเลยคือ eBPF (Extended Berkeley Packet Filter) นี่แหละ คือ OP ของยุคนี้เลย สมัยก่อนเวลาเราอยากจะเพิ่ม Feature ให้ Linux Kernel เราจะต้องเขียน Module โหลดเข้าไป ความชิบหายอยู่ที่ว่า ถ้าเกิด Code แตก เช่น อุ๊ย ลืม Stop Loop ตัว Kernel จะ Panic แล้วแตกทั้งเครื่อง

eBPF เข้ามาแก้ปัญหานี้ด้วยการที่มันยอมให้เราเอา Code เราเองมารันในพื้นที่ Kernel ได้อย่างปลอดภัย โดยไม่ต้องแก้ Source Code ของ Kernel หรือโหลด Module ให้ชิบหายเลย ความเจ๋งของมันอยู่ที่ Feature eBPF Verifier ก่อนที่ Code สายลับจะถูกรัน ตัว Verifer มันจะทำ Static Analysis อย่างโหด เพื่อให้มั่นใจว่า Code นี้จะไม่ทำให้ระบบพัง ไม่กิน Memory มั่วซั่ว และทำงานได้จบจริง ๆ เช็คไปถ้าไม่ผ่าน มันจะดีดออกไม่ยอมให้โหลดแน่นอน ซึ่งมีการเอาไปใช้กันเยอะมาก ๆ ตัวอย่างเด็ด ๆ ยกให้ Magic Firewall ของ Cloudflare เลย

อย่างที่ 2 คือ Confidential Computing ถ้าเราย้อนกลับไปตอนเราคุยกันเรื่อง Runtime Security ว่า แล้วถ้าเกิด Hacker ทำท่าบางอย่างทะลุ Kernel ได้ละ นี่แหละ คือที่มาของคำว่า Confidential Computing โดยปกติ ข้อมูลทั้งหลายจะถูกเข้ารหัสตอนเก็บ (Data at Rest) และตอนจะส่งผ่าน Network (Data in Transit) อยู่แล้ว แต่ข้อมูลใน Memory ที่กำลังประมวลผล (Data in Use) มักจะไม่ได้เข้ารหัส

เทคโนโลยีนี้มันจะเข้ามาจัดการแก้ปัญหาตรงนี้ ผ่าน Hardware ที่ออกแบบมาเฉพาะ เช่น Intel SGX (Software Guard Extension) หรือ AMD SEX (Secure Encrypted Virtualisation) มาสร้างสิ่งที่เรียกว่า TEE (Trusted Ececution Environment) โดยมันจะเข้ารหัส Memory ของ Application ระดับ Hardware เลย ดังนั้น ถึงเราจะพยายาม Wiretrap ข้อมูลออกจาก Hardware โดยตรง มันก็จะทำไม่ได้เลย

อย่างที่ 3 เข้ามาช่วยในเรื่องการจัดการ Memory เพราะช่องโหว่ร้ายแรงของ OS กว่า 70% เกิดจาก Memory Safety เราเคยเล่าเรื่องนี้ไปแล้ว ย้อนกลับไปดูได้ ซึ่งปัญหานี้ มันเลี่ยงได้ยากมาก โดยเฉพาะเมื่อพัฒนาด้วยภาษา C ที่ให้อิสระกับนักพัฒนาแบบสุด ๆ ไปหน่อย การตัดสินใจเอา Rust เข้ามาเขียนใน Linux Kernel คือ การทำ Zero-Trust ตั้งแต่ Source Code เลย เพราะ Rust มีระบบ Borrow Checker ที่โหดมาก ๆ จะไม่ยอม Compile Code ที่จัดการ Memory พลาดได้ยากมาก ปิดความชิบหายจาก Human Error ได้มหาศาล

และสุดท้ายอย่างที่ 4 คือการใช้งานกลุ่มเทคโนโลยีรากฐานสำคัญอย่าง Seccomp (Secure Computing Mode), SELinux และ AppArmor ที่เข้ามาขีดขอบเขตของ App อย่างชัดเจน ป้องกันไม่ให้ไปเรียกอะไรที่ไม่สมควร หรือไปยุ่งกับชาวบ้านเขา

เราเอาหลักการ และเครื่องมือนี้ไปทำอะไรแล้วบ้าง

ในโลกความเป็นจริง เรื่องนี้เป็นประเด็นที่สำคัญมาก ๆ ใน Software สมัยใหม่เลยก็ว่าได้ เพราะรากฐานที่ปลอดภัย ย่อมช่วยลด Attack Surface นำไปสู่อัตราความสำเร็จในการโจมตีที่ต่ำได้จริง วันนี้เราขอยกออกมาสัก 2 เคสที่เห็นได้ชัด ๆ ละกัน

เคสแรกคือ Runtime Security บน Kubernetes (K8s) ถ้าใครใช้งาน ก็จะรู้เลยนะว่า การจัดการกับ Container Security นับร้อยถึงพัน Container มันปวดหัวขนาดไหน เครื่องมือเดิม ๆ เราไม่เห็นเลยว่า มันเกิดอะไรขึ้นบ้างใน Container แต่พอมี eBPF เกมเปลี่ยนเลย

Tetragon นำ eBPF มาทำ Runtime Enforcement แบบโหดสุด ๆ มาก ๆ สมมุติว่า Hacker เจอช่องโหว่พวก RCE แรง ๆ ใน Web Application ของเราแล้วพยายามจะรันคำสั่งเพื่อเปิด Shell หรืออ่านรหัสผ่านต่าง ๆ ใน Container แทนที่ระบบจะรอให้คำสั่งถูกรันแล้วค่อยตามจับทีหลัง eBPF นั่งดูดมะม่วงดองรออยู่ที่หน้าประตู Syscall ในระดับ Kernel เลย พอ Container ผีสิง มันรัน execuv ลงมา eBPF ประเมินแล้วว่า Web Server ไม่น่าจะต้องเปิด Shell นะ มันจะทำการ Kill Process ทิ้งไป ก่อนที่คำสั่งนั้นจะถูกส่งไปประมวลผลด้วยซ้ำ นี่แหละ คือการป้องกันแบบ Real-time ที่ดุดันไม่เกรงใจใครมาก ๆ

อีกเคสขอเป็นเรื่อง Confidential Computing ละกัน คือ Cloud Provider ได้ Requirement มาว่า ลูกค้าบางกลุ่มกลัวการเอาข้อมูลขึ้น Cloud เพราะรู้สึกว่าตัวเองไม่ได้คุม Hardware เอง วันดีคืนดี Cloud Admin แอบ Dump Memory ไปก็ชิบหาย แต่ค่ายใหญ่อย่าง AWS เปิดตัว AWS Nitro System และ Nitro Enclaves ออกมา หรือฝั่ง Google เขามี Confidential VMs ออกมาสู้ เทคโนโลยีพวกนี้ใช้ระดับ Hardware มาการันตีเลยว่า ข้อมูลที่กำลังทำงานอยู่ใน Memory จะถูกเข้ารหัสแบบ E2E ต่อให้เป็นพนักงานเข้าถึงเครื่องได้ ก็จะเห็นแค่ข้อมูลที่อ่านไม่ออก นี่แหละคือการสร้าง Zero-Trust ให้กับลูกค้า เพื่อให้ใช้งาน Cloud ได้อย่างมั่นใจมากขึ้น

สรุป : สู่ยุคใหม่ของ ความปลอดภัย

ยุคสมัยของการฝากความหวังไว้กับ Firewall หน้าบ้าน และการยอมให้สิทธิ์ Kernel ทำทุกอย่างแบบไม่มีใครตรวจสอบมันจบแล้ว ระบบสมัยใหม่ถูกออกแบบมาภายใต้สมมุติฐานว่า ระบบของเราถูกเจาะอยู่ตลอดเวลา เชื่อใจใครไม่ได้เลย เพราะเส้นแบ่งเขตแดน (Security Boundary) มันไม่ได้อยู่ไกลแล้ว มันหดลงเรื่อย ๆ อยู่รอบ ๆ ตัว Application รอบ ๆ Thread หรือกระทั่งที่ Syscall ถูกเรียกด้วยซ้ำ เทคโนโลยีสมัยใหม่อย่าง eBPF, TEE, Rust ใน Linux Kernel และ Sandboxing เข้ามาเป็นมาตรฐานใหม่ที่แทรกเข้ามาเพื่ออุดรอยรั่วที่เราอาจเจอในชีวิตประจำวันได้

เราว่า สำหรับ Developer ปัจจุบันนี้ ภัยคุกคามมันน่ากลัวมาก การจะเขียน Code แล้วเอาแค่มันใช้งานได้ แล้วโยนให้งาน Infra และ SecOps จัดการ Security ให้เราต่อ มันไม่ได้แล้ว การออกแบบ Application สมัยใหม่ เราจะต้องคำนึงถึงเรื่อง ความปลอดภัย ตั้งแต่การออกแบบรากฐานเลย เราจะต้องรู้ว่า Application เราใช้ Network Port ไหน ต้องการสิทธิ์เข้าถึงอะไรได้บ้าง ถึงแค่ไหน เพื่อให้ทีม Infra สามารถออกแบบ Policy กำกับการทำงานของ Application เราได้รัดกุมที่สุดนั่นเอง