การเสริมความแข็งแกร่ง 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 เป็นโค้ด สามสิ่งจะเปลี่ยนไป:

ทำซ้ำได้ host ใหม่ทุกตัวสืบทอด baseline ไม่ใช่แค่ตัวที่มีคนจำได้ว่าต้องตั้งค่า
ทดสอบได้ compliance scan ใน CI ทำให้ build ล้มเหลวเมื่อมีการตั้งค่าหลุดออกไป
ทบทวนได้ การเปลี่ยน 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 ตอนเที่ยงคืน

flowchart LR A[Baseline CIS benchmark เป็นโค้ด] --> B[Build image ที่ hardened ใน CI] B --> C[Compliance scan ใน pipeline] C -- ผ่าน --> D[Deploy และหมุนเวียน instance] C -- ไม่ผ่าน --> B style C stroke:#0EA5E9,stroke-width:2px style D stroke:#10B981,stroke-width:2px

ไกลกว่า host #

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

ไม่แน่ใจว่าเซิร์ฟเวอร์ของคุณตรงกับเอกสาร hardening จริงหรือไม่? ติดต่อเพื่อรับการตรวจสอบแบบตรงไปตรงมา คุยได้ทาง LINE (@PureSecurity) หรืออีเมล (hello@puresecurity.com)

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