โครงสร้างพื้นฐานรุ่นเก่าแทบไม่อธิบายตัวเองอยู่ที่เดียว ระบบจริงกระจายอยู่ใน service ที่รันอยู่ configuration, code, scheduled maintenance, data store และ network device การเปลี่ยนส่วนใดก่อนเข้าใจภาพรวมมักเพิ่มความไม่แน่นอนมากกว่าลด
เริ่มด้วยสัญญาแบบอ่านอย่างเดียว
ก่อนตรวจต้องกำหนดขอบเขต: ไม่แก้ configuration, restart, เปลี่ยน package, เขียน database หรือรันคำสั่งทดสอบที่กระทบ session เป้าหมายของรอบแรกคือสร้าง system map ที่มีหลักฐาน ไม่ใช่พิสูจน์ว่าการแก้ไขที่เสนอใช้ได้
ข้อจำกัดนี้ทำให้ audit ดีขึ้น เพราะทุกข้อสรุปต้องย้อนกลับไปยังสิ่งที่สังเกตได้ และความไม่แน่นอนถูกระบุไว้อย่างชัดเจน
ตรวจเป็นชั้น
ลำดับที่ใช้ได้จริงคือ:
- บทบาทของ host — ตรวจอายุระบบปฏิบัติการ service ที่ทำงาน ทรัพยากร และหมวดบริการที่เปิดออก
- Service topology — ทำแผนที่ authentication service, policy store, management application, enforcement device และ job สนับสนุน
- Configuration dependencies — บันทึกว่า component ใดอ่านข้อมูลจากแหล่งใด และจุด trust boundary ที่กว้างหรือไม่ชัดอยู่ตรงไหน
- Application command inventory — แยกสิ่งที่ code ทำได้ออกจากสิ่งที่ active flow เรียกใช้จริง
- Runtime evidence — เทียบ code/configuration กับ process, connection, schedule และ log ที่พบ
ต้องแยกสามประโยคออกจากกันเสมอ: “มีใน code”, “เชื่อมกับ active flow” และ “พบว่า execute ที่ runtime”
ไล่ flow การทำงานให้ครบ
operator ต้องเห็นลำดับแบบ end-to-end ไม่ใช่เพียงรายชื่อไฟล์ ตัวอย่าง flow หลักคือ authentication, accounting, management และ maintenance การทำแผนที่เหล่านี้เผย coupling ที่ซ่อนอยู่ เช่น web interface ใหม่อาจยังพึ่ง policy engine เก่า หรือ maintenance job ซ้ำซ้อนอาจสำคัญกว่า source file ใด file หนึ่ง
เปลี่ยนผลตรวจเป็นลำดับการปรับปรุง
deliverable รอบแรกควรเป็น system map ที่ sanitize แล้ว evidence matrix, risk register และรายการการตัดสินใจที่ต้องมี owner ไม่ใช่ข้อเสนอ rewrite ทันที
ลำดับที่ปลอดภัยมักเริ่มจากยืนยัน source of truth ด้าน identity/policy/session, บันทึก interface และ failure behaviour, ลด trust boundary, เพิ่ม health check และ recovery ที่ทำซ้ำได้ แล้วเปลี่ยน dependency ครั้งละส่วนพร้อม rollback ที่ทดสอบแล้ว
บทเรียนสาธารณะคือวิธีทำงาน ไม่ใช่ inventory ของ infrastructure ชื่อ host, address, username, credential, database, internal path, network range และ finding ที่ใช้โจมตีได้ควรอยู่ในเอกสารภายใน