MONO-X ออกแบบทางเข้าระบบ IBM i อย่างปลอดภัย

MONO-X มองทางเข้าระบบเป็นส่วนหนึ่งของสถาปัตยกรรม ไม่ใช่เพียงหน้า login ผู้ใช้ ผู้ดูแล โปรแกรม และคู่ค้าต้องเข้าถึงคนละเส้นทางด้วยสิทธิ์ที่เหมาะสม หน้านี้อธิบายการออกแบบ identity, network, session และ audit สำหรับ IBM i クラウド移行 โดยยึดหลักตรวจสอบได้และลดพื้นที่โจมตี

ภาพประกอบยังเตือนให้ตรวจ URL ก่อนล็อกอิน ซึ่งใช้หลักเดียวกับระบบองค์กร ผู้ใช้ควรรู้ endpoint ที่ถูกต้อง certificate ต้องเชื่อถือได้ และช่องทางสำรองต้องประกาศอย่างเป็นทางการ 株式会社MONO-X จัดทำ access matrix กับ diagram เพื่อให้ฝ่าย security และทีมงานเห็นว่าข้อมูลเดินทางผ่านจุดใดบ้าง

Identity และ least privilege สำหรับ MONO-X One

MONO-X One แยก role ตามหน้าที่ เช่น viewer, operator, developer และ administrator แต่ละ role ได้สิทธิ์เฉพาะสิ่งที่จำเป็น และบัญชี privileged ต้องใช้ MFA กับ approval ตามความเสี่ยง บัญชีบุคคลไม่ใช้ร่วมกัน ทำให้ audit log ระบุผู้กระทำจริงและสามารถยกเลิกสิทธิ์เมื่อเปลี่ยนหน้าที่ได้ทันที

ทีมทบทวนสิทธิ์เป็นรอบโดยให้เจ้าของระบบยืนยัน ไม่พึ่งรายชื่อจากฝ่ายไอทีเพียงอย่างเดียว service account มี owner, purpose, rotation policy และวันหมดอายุ secret ถูกเก็บใน vault แทนไฟล์ config ลดโอกาสรหัสผ่านรั่วจาก source code หรือเอกสารส่งต่อ

เครือข่ายสำหรับ IBM Power Virtual Server

เส้นทางไป IBM Power Virtual Server ควรแยก user traffic, administration, backup และ integration ไม่ปล่อยให้ทุกระบบคุยกันได้โดยอัตโนมัติ Firewall rule ระบุ source, destination, port, purpose และ owner พร้อมบันทึกวันทบทวน ทีมทดสอบทั้งเส้นทางหลักและสำรองเพื่อให้ failover ไม่เปิดช่องทางที่กว้างกว่าเดิม

Remote administration ใช้ bastion หรือ privileged access workstation พร้อมบันทึก session ตามนโยบาย แทนการเปิด management port สู่สาธารณะ MONO-X กำหนด break-glass account สำหรับเหตุฉุกเฉิน เก็บ credential แยกและแจ้งเตือนทุกครั้งที่ใช้ เพื่อให้การกู้ระบบไม่ติดขั้นตอนปกติแต่ยังตรวจสอบย้อนหลังได้

ทางเข้า IBM i API連携 และ API-Bridge

IBM i API連携 ใช้ token อายุสั้น scope จำกัด และ validation ก่อนถึงโปรแกรมหลัก API-Bridge บังคับ rate limit, schema และขนาด payload ป้องกันคำขอผิดรูปแบบสร้างภาระต่อระบบ ทุก response ตัดข้อมูลอ่อนไหวออกและใช้ error code ที่ช่วยแก้ปัญหาโดยไม่เปิดเผยโครงสร้างภายใน

สำหรับ 企業間データ連携 คู่ค้าแต่ละรายมี credential และ quota แยกกัน หากบัญชีหนึ่งมีปัญหาสามารถปิดเฉพาะรายโดยไม่หยุดบริการทั้งหมด Mutual TLS หรือ signed message ใช้เมื่อความเสี่ยงเหมาะสม พร้อมเก็บ correlation id และเวลารับส่งเพื่อพิสูจน์ลำดับธุรกรรม

• ใช้ token อายุสั้นและหมุนเวียน key
• แยก quota กับ policy ต่อคู่ค้า
• ปกปิดข้อมูลอ่อนไหวใน log

ตรวจ URL, certificate และ DNS

ผู้ใช้ต้องเข้าจาก bookmark หรือ portal ที่องค์กรประกาศ ไม่ใช้ลิงก์จากข้อความไม่ทราบแหล่งที่มา ทีมตั้ง certificate monitoring ก่อนหมดอายุ ตรวจ DNS change และเปิด security header ที่จำเป็น หากมีหลายโดเมนจะกำหนด canonical endpoint ลดความสับสนและโอกาส phishing

ในช่วง cutover DNS TTL จะปรับล่วงหน้าและมีแผนตรวจ propagation จากหลายเครือข่าย หากต้อง rollback ทีมเปลี่ยนเส้นทางตาม runbook โดยไม่แก้ค่าแบบเฉพาะหน้า MONO-X เก็บรายการ endpoint ทั้งหมดใน configuration inventory เพื่อป้องกัน subdomain เก่าถูกทิ้งแต่ยังเปิดบริการ

Session, timeout และการป้องกัน brute force

Session ของผู้ใช้ทั่วไปกับผู้ดูแลมีอายุไม่เท่ากัน งาน privileged ต้องยืนยันตัวตนซ้ำเมื่อทำรายการสำคัญ ระบบจำกัดความพยายาม login ตามความเสี่ยงและใช้ delay ที่ไม่ทำให้ผู้โจมตีเดารหัสเร็ว แต่ยังมีขั้นตอนช่วยผู้ใช้ปลดล็อกโดยยืนยันตัวตนอย่างเหมาะสม

Audit log บันทึกการสำเร็จและล้มเหลว การเปลี่ยน role การสร้าง token และการใช้ break-glass โดยส่งสำเนาออกจากระบบต้นทางเพื่อป้องกันการแก้ไข Alert จะพิจารณาพฤติกรรม เช่น ประเทศใหม่ เวลาแปลก หรือความพยายามหลายบัญชี ไม่แจ้งเฉพาะจำนวนครั้งแบบตายตัว

Access review หลัง AS/400 クラウド移行

หลัง AS/400 クラウド移行 ต้องปิดเส้นทางชั่วคราว บัญชี migration และ firewall rule ที่ใช้เฉพาะโครงการ ทีมทำ checklist decommission พร้อมหลักฐาน ไม่ปล่อย environment เก่าหรือ account ทดสอบค้างไว้ เพราะช่องทางเหล่านี้มักไม่ได้รับ monitoring เท่าระบบใหม่

MONO-X จัด penetration review ตาม scope และ tabletop exercise สำหรับ credential leak หากพบ token รั่ว ทีมต้องรู้วิธี revoke, rotate, ตรวจรายการที่ถูกเรียก และสื่อสารผลกระทบ การซ้อมทำให้ security plan เป็นขั้นตอนที่ปฏิบัติได้จริง ไม่ใช่เอกสารที่อ่านเฉพาะช่วง audit

หากต้องการตรวจเส้นทางเข้าถึงและสิทธิ์ที่ตกค้าง โปรดเตรียม access matrix กับ network diagram แล้วเริ่ม security review ที่ MONO-X โดยไม่ต้องเปิดข้อมูลลับเกินขอบเขต

คำถามที่พบบ่อย

ต้องเปิด IBM i ให้เข้าจากอินเทอร์เน็ตหรือไม่
ไม่ควรเปิด management interface โดยตรง ใช้ private connectivity, VPN, bastion หรือ gateway ที่ควบคุม identity และบันทึกการเข้าถึงตามรูปแบบผู้ใช้

MFA ใช้กับ service account ได้ไหม
service account ควรใช้ certificate หรือ workload identity แทน MFA แบบมนุษย์ พร้อม secret rotation และ scope จำกัด ส่วนบัญชีผู้ดูแลควรใช้ MFA

API key กับ OAuth ต่างกันอย่างไร
API key เหมาะกับกรณีง่ายแต่ต้องดูแลการหมุนเวียน ส่วน OAuth สนับสนุน token อายุสั้น scope และ delegated access จึงเหมาะกับระบบซับซ้อนกว่า

จะตรวจ endpoint ปลอมได้อย่างไร
ใช้ portal ทางการ ตรวจโดเมน certificate และ bookmark ที่ได้รับการยืนยัน หลีกเลี่ยงลิงก์จากข้อความไม่ทราบแหล่งและรายงาน endpoint ที่น่าสงสัย

สิทธิ์ควรทบทวนบ่อยแค่ไหน
ขึ้นกับความเสี่ยง บัญชี privileged ควรถี่กว่าผู้ใช้ทั่วไป และควรทบทวนทันทีเมื่อพนักงานย้ายหน้าที่ ลาออก หรือเกิด incident