การเสริมความแข็งแกร่ง Linux Infrastructure สำหรับระบบ APAC

ระบบ Linux ใน production ส่วนใหญ่ทำงานใกล้เคียงค่า default มากกว่าที่ใครอยากยอมรับ เอกสาร hardening มีอยู่จริง มักเขียนไว้เพื่องานตรวจสอบเมื่อหลายปีก่อน แต่เซิร์ฟเวอร์ไม่ตรงกับเอกสาร ช่องว่างระหว่าง “baseline ในเอกสาร” กับ “การตั้งค่าจริง” คือจุดที่ผู้โจมตีอาศัยอยู่ได้อย่างน่าเชื่อถือ

การเสริมความแข็งแกร่ง Linux คือวินัยของการปิดช่องว่างนั้น และทำในแบบที่อยู่รอดผ่านการ deploy ครั้งถัดไป

ค่า default คือจุดเริ่มต้น ไม่ใช่ท่าทีด้านความมั่นคงปลอดภัย #

การติดตั้ง Linux แบบ default ให้ความสำคัญกับความเข้ากันได้ ไม่ใช่ความมั่นคงปลอดภัย มันมาพร้อม service ที่คุณไม่ใช้ kernel feature ที่คุณไม่จำเป็นต้องใช้ และ logging ที่พอใช้ สำหรับเดสก์ท็อป แต่ไม่พอสำหรับ production host ที่ถูกเจาะ Hardening คือกระบวนการเปลี่ยน เครื่องจักรทั่วไปให้กลายเป็นเครื่องจักรที่สร้างมาเพื่องานเฉพาะ

งานหนักแบ่งออกเป็นไม่กี่หมวด:

• การปรับ kernel และ sysctl: การป้องกันเครือข่าย (เช่น ละทิ้ง ICMP redirect เปิด source-route filtering) ข้อจำกัดของ filesystem และการป้องกัน memory เช่น address space layout randomisation
• การลดจำนวน service: ปิดและถอดสิ่งที่ host ไม่ได้รัน เพื่อไม่ให้มีอะไรให้โจมตีที่ไม่ถูกใช้งาน
• Mandatory access control: SELinux หรือ AppArmor เพื่อจำกัดว่ากระบวนการ อาจ ทำอะไรได้ แม้จะถูกเจาะ
• การเสริมความแข็งแกร่ง systemd และ container: ลด capabilities บล็อกการเข้าถึง raw socket และจำกัด syscall ด้วย seccomp profile
• Audit และ logging: บันทึกเหตุการณ์ที่สำคัญ ส่งออกนอก host เพื่อให้ผู้โจมตีลบร่องรอยตัวเองไม่ได้

CIS Benchmarks ยังคงเป็นการรวบรวมมาตรการควบคุม ที่ใช้งานได้จริงและเป็นที่ยอมรับกว้างขวางที่สุด และ OpenSCAP ช่วย automate ทั้งการนำไปใช้และการตรวจสอบ

Config เป็นโค้ด ไม่งั้นมันไม่มีอยู่จริง #

คู่มือ hardening ที่อยู่ใน wiki คือ wish-list ส่วน hardening ที่อยู่ในโค้ด (Ansible role, Packer image, Kubernetes admission policy) คือข้อเท็จจริง เมื่อ baseline เป็นโค้ด สามสิ่งจะเปลี่ยนไป:

1. ทำซ้ำได้ host ใหม่ทุกตัวสืบทอด baseline ไม่ใช่แค่ตัวที่มีคนจำได้ว่าต้องตั้งค่า
2. ทดสอบได้ compliance scan ใน CI ทำให้ build ล้มเหลวเมื่อมีการตั้งค่าหลุดออกไป
3. ทบทวนได้ การเปลี่ยน baseline คือ pull request ที่มีวินัยการทบทวนแบบเดียวกับโค้ดแอปพลิเคชัน

นี่คือข้อแตกต่างระหว่าง hardening ในฐานะงานประจำปี กับ hardening ในฐานะคุณสมบัติของแพลตฟอร์ม

Immutability คือสถานะปลายทาง #

ข้อสรุปเชิงตรรกะคือ immutable infrastructure: host และ container ไม่เคยถูก patch อยู่กับที่ มีแต่ถูกแทนที่ image ใหม่ถูก build สแกน และ deploy ตัวเก่าถูกทำลาย configuration drift เป็นไปไม่ได้เพราะไม่มีอะไรให้ drift: ระบบที่รันอยู่คือ build artifact

immutable infrastructure เข้ากับ hardening-as-code อย่างเป็นธรรมชาติ คุณไม่ได้รักษา baseline แต่คุณ compile ความมั่นคงปลอดภัยลงใน image และเมื่อมีช่องโหว่ปรากฏ ทางแก้คือ rebuild ไม่ใช่ SSH ตอนเที่ยงคืน

ไกลกว่า host #

hardening ไม่ได้หยุดที่ระบบปฏิบัติการ วินัยเดียวกัน extends ออกไปหลายทิศทาง แต่ละทิศมี failure mode ของตัวเอง

Container สืบทอดทุกอย่าง แล้วเพิ่มความเสี่ยงของตัวเองอีก image ที่ build จาก base layer ที่ยังไม่ hardened พา weakness ระดับ host ทุกอย่างเข้าไปในทุก pod ที่ run มัน ทางแก้อยู่ต้นน้ำ: minimal base image, scan ใน CI, run แบบ non-root พร้อม read-only filesystem, drop capabilities และ seccomp profile ที่จำกัด syscall เฉพาะที่ workload ต้องใช้จริง default profile บล็อกไปได้เยอะ profile ที่ tune ตามพฤติกรรม syscall ที่ observe จริงจะบล็อกส่วนที่เหลือ Kubernetes admission policy enforce ทั้งหมดนี้ทั้ง fleet จน deployment ที่ไม่ตรงมาตรฐาน schedule ไม่ได้เลย

OT environment เพิ่มเดิมพัน ใน industrial และ operational technology hardening ชนกับ availability แบบที่ office IT ไม่เคยเจอ control จาก CIS benchmark ที่ apply ผิดลงบน building management system, network ของ production line PLC หรือ device segment ของโรงพยาบาล ไม่ได้ produce finding: มัน produce downtime บางครั้งมีผลต่อความปลอดภัยของชีวิตด้วย hardening ฝั่ง OT จึงกลับลำดับ: passive monitoring กับ inventory มาก่อน, change เกิดใน maintenance window พร้อม rollback plan และ control ถูก pilot บน mirror ของ production ก่อนแตะของจริงเสมอ ฝั่ง IT ถามว่า “ระบบนี้ปลอดภัยไหม?” ฝั่ง OT ต้องถามว่า “เรา secure มันได้โดยไม่หยุดมันได้ไหม?”

Drift detection ปิด loop baseline เสื่อมผ่านการเปลี่ยนแปลงประจำวัน: engineer เปิด port เพื่อ debug, installer เปิด service กลับมา, hotfix ไม่เคยกลับเข้าโค้ด ถ้าไม่มี detection host ที่ hardened วันนี้ คือ host ที่ soft ในปีหน้า pattern ที่ work: configuration scan ตามรอบรายวัน เทียบ live host และ image กับ baseline ที่เป็นโค้ด แล้ว route finding เป็น alert ให้ owner ตรง ๆ ไม่ใช่เก็บไว้ใน quarterly report ที่ไม่มีใครอ่าน drift ที่ detect ได้ในหนึ่งวันคือ ticket; drift ที่ detect ในหนึ่งปีคือการ investigate incident

host ที่ hardened แต่อยู่หลัง cloud IAM role ที่ให้สิทธิ์เกิน หรืออยู่ใน container pipeline ที่ไม่ scan ก็ยังเสี่ยงอยู่ ท่าทีที่ยั่งยืนคือการปฏิบัติต่อ host baseline, container build chain, cloud configuration และขอบเขต identity เป็นพื้นผิวเดียวที่ต่อเนื่องกัน และ monitor มันแบบนั้น

บริการ การเสริมความแข็งแกร่งของ Linux และโครงสร้างพื้นฐาน ของเราส่งมอบ baseline เป็นโค้ดพร้อมการตรวจจับ drift แบบอัตโนมัติ และ การประเมินการตั้งค่าและสถาปัตยกรรม ทบทวน cloud และ identity layer รอบ ๆ host หากต้องการภาพรวมทั้งหมด นัดหมายพูดคุยขอบเขตงาน