วันเสาร์ที่ 8 กุมภาพันธ์ พ.ศ. 2557

จะทำ Security กับ File อย่างไร ?

จะทำ 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 ถ้ามองแค่  "เบา" สำหรับตนเอง   จะกระทบกับภาพรวม
       คนที่เกี่ยวข้อง  ถ้ายังคิดว่า   อะไรก็ได้  แต่ทำแบบเดิมๆ  น๊ะ  (ก็ไม่ได้ทำเพื่อเป้าหมาย)

ไม่มีความคิดเห็น:

แสดงความคิดเห็น