จะทำ Security กับ File อย่างไร ?
ในระบบที่สร้างมานาน กับบริษัทฯ ที่ไม่กังวลเรื่องความปลอดภัย
เช่น โรงงาน ,บริษัท(ที่ไม่ใช่ ธนาคาร,ประกันชีวิต)
การออกแบบ กับ Security มักจะออกแบบให้ ง่าย ไว้ก่อน
เนื่องจาก Security จะทำให้ดี ต้องรู้จริง และ วางแผน (ทั้ง องค์กร, วิธีทำงาน และ IT)
ในอดีต ไม่มีใครสนใจ และไม่มีใครตรวจ
การทำ Security อาจจะอยู่ในรูปแบบ
- Lock ด้วย IT ที่ประตูทางเข้า UserProfile
- ห้าม! ด้วย วาจา, ประกาศเป็นกฏ (ต่างๆ)
- (ยังเชื่อใน) ความไว้วางใจ ว่าข้างต้น ยังถูกต้อง
วันนี้ สภาพแวดล้อม ที่เปลี่ยนไป
- มีกฏหมาย, มีหน่วยงานตรวจสอบ ทั้งจากภายในและภายนอก
- ต้อง Share ข้อมูลต่างๆ มากขึ้น
- ผู้ใช้งาน มีมากและหลากหลาย
ผลที่ตามมา
- ไม่รัดกุม (ทางเข้าในปัจจุบัน มีมากกว่าที่เห็น)
- ขาดความยืดหยุ่น - มีข้อมูลแต่ ห้ามๆๆๆ จน Share กับใครไม่ได้ หรือ ขั้นตอนมาก
- เมื่อมีคนมากขึ้น ความเชื่อใจเปลี่ยนเป็น ไม่ไว้ใจซึ่งกันและกัน
การออกแบบ ที่ดี คือ ทำตามคำคู่มือในหนังสือของ iSeries
ในขณะที่ คำแนะนำ "เหมาะสม" จะเกิดจาก การปรับสภาพแวดล้อม
- องค์กร, หน้าที่ ที่ชัดเจน
สิ่งที่จะเข้าใช้ (Function, Object) ... กำหนดหน้าที่ + สิทธิ ในการ เข้าใช้
- วิธีทำงานปัจจุบัน ... ทบทวน ปรับวิธีจากความคุ้นเคย ให้เหมาะ กับ หน้าที่+สิทธิข้างต้น
- IT ... จัด เทคนิค,ตัวเลือก ที่เหมาะกับสิ่งที่ต้องทำ
ข้างต้น
ตย.
* ลงทะเบียน ระดับบุคคล + จัดสิทธิร่วม หลาย บุคคล ให้เป็น "กลุ่ม"
(IBM แนะนำให้เริ่มที่ UserProfile)
- บางบริษัทฯ มี admin คนเดียวแต่มี programmer หลายคน
เพื่อลดงาน Admin ได้ให้ programmer สร้าง database จัดการกันเอง
>> OS จะมองไม่เห็น "ตัวตน" การจัดสิทธิใน Lib หรือ File จะทำ "ยุ่งยาก"
>> เมื่ออ่านต่อจนจบ จะพบว่า การเลือกวิธีนี้ ทำให้ งานด้านหลังทำ "ยากขึ้นไปอีก"
# ถ้าอนุญาต ให้ Programmer จัดการ (และมักจะให้ User Admin ทำต่อ)
>> Admin เพียงแค่ สร้างโปรแกรมแล้วให้ Programmer หรือ User ระดับ admin จัดการได้
ปัญหาอยู่ที่ไหน ? Admin ไม่เขียนโปรแกรม, ใช้เครื่องมือใหม่ ไม่คล่อง, ...
แก้ไขให้ถูกจุด -> งานจะวิ่งต่อได้ สะดวก
* การออกแบบ P-file และ L-File ที่มีโครงสร้าง เหมือนกัน (จำง่าย)
เช่น P-file ข้อมูลพนักงาน มี เงินเดือน
L-file แบบเดิม จะเห็นทุกช่องเหมือน P-file
--- ไม่อนุญาตให้ ใครใช้ข้อมูลพนักงาน ---
>> copy data ไป อีก table (ตัด field ที่ไม่ต้องการ) ทำทุกคืน
เกิดปัญหา ไม่ real time (ยื่นลา ตอนเช้า ต้อง รอดูผลพรุ่งนี้)
Run โปรแกรมให้ ถี่ขึ้น (AddJobSchE)
หรือ ใช้เครื่องมือของ Admin (เช่น Replicate)
L-file มีคุณสมบัติ อีกอันหนึ่ง คือ การสร้าง View ให้เหมาะกับ การใช้งาน
>> จำกัดสิทธิ การใช้ Lib, P-file
>> สร้าง Lib ที่แยก และ share แบบจำกัด
สร้าง L-file ให้เหมาะกับ การใช้งาน เช่น ไม่มี Field เงินเดือน
* ภาษา โปรแกรมที่ใช้
ภาษามาตรฐานใหม่ ที่ไม่ใช่ RPG มีทางเลือกที่ยืดหยุ่นกว่ามาก
ขนาดหน้าจอ, รายงาน ที่เกินข้อกำหนด จัดวางให้ใช้งานได้ง่าย
? ทีมงานดั้งเดิม ไม่ยอมเปลี่ยน
>> แผน/ขั้นตอน การเปลี่ยน ภาษาหลัก หรือ เพิ่มภาษารอง ในการใช้งาน
>> ถ้าทำได้ จะมีทางเลือก ต่อไปนี้ช่วย
สร้างเป็น Class ที่ Encapsulate แล้ว (ไม่เห็น Source Code) ให้เรียกใช้
(เหมาะกับ ภาษารอง ใช้ภาษาเดียว เช่น Java, ASP, Php เป็นต้น)
Web Service : วิธีการที่ถูกออกแบบมาเพื่องานลักษณะนี้ อาจจะมีข้อจำกัดมากกว่า เพราะทำบน internet ได้
>> สร้าง Web Service ด้วย Java, DotNet
ข้อแนะนำอื่นๆ
- ทดสอบ ก่อนเปิดใช้
การปรับแล้วทำเลย สไตล์ลูกทุ่ง ไม่เหมาะกับงาน Security บางกรณีต้องหยุดเครื่องกันเลย
- จะเห็นว่า ปัญหาใหญ่ คือ ทีมงานหลัก
Key Man ถ้ามองแค่ "เบา" สำหรับตนเอง จะกระทบกับภาพรวม
คนที่เกี่ยวข้อง ถ้ายังคิดว่า อะไรก็ได้ แต่ทำแบบเดิมๆ น๊ะ (ก็ไม่ได้ทำเพื่อเป้าหมาย)