การกำหนดสิทธิใน PPS M&A

ในการใช้งาน PPS M&A มีการกำหนดสิทธิในหลาย component ซึ่งมีวัตถุประสงค์ที่แตกต่างกันดังนี้

1. สิทธิใน PPS M&A component
สิทธิใน PPS M&A จำเป็นสำหรับการใช้ Dashboard Designer โดยคุณสามารถให้สิทธิกับ user ใน Active Directory โดยสามารถกำหนดบทบาท (Role) ของ user ได้ 4 ประเภทดังนี้:

• Admin ผู้ใช้ในบทบาทนี้มี complete control ใน Monitoring Server สามารถเข้าถึงทุก dashboard และสามารถ create, edit และ delete ทุกประเภทของ dashboard elements รวมทั้งสามารถ publish dashboards ไปยัง server นอกจากนั้นยังสามารถกำหนดสิทธิให้ users ท่านอื่นในระบบได้ local administrator group บนเครื่องที่ติดตั้ง PPS M&A จะได้บทบาทนี้โดยอัตโนมัติ และไม่สามารถ remove สิทธิได้
  
• Data Source Manager ผู้ใช้ในบทบาทนี้สามารถ create, delete และ publish data sources
• Creator ผู้ใช้ในบทบาทนี้สามารถ create KPIs, scorecards และ indicators นอกจากนั้นยังสามารถ publish dashboard elements ไปยัง server และสามารถ delete elements ที่ตนเองมีสิทธิเป็น Editor โดยปกติ user ที่สร้าง Element นั้นๆ จะได้สิทธิเป็น Editor โดยอัตโนมัติ แต่สามารถลบตนเองออกจากสิทธิเป็น Editor ได้
  
• Power Reader ผู้ใช้ในบทบาทนี้มีสิทธิ read only ใน dashboard element ทุกประเภท
  

นอกเหนือจากบทบาท (role) แล้วคุณยังสามารถกำหนดสิทธิ (element role หรือ element permission) ใน dashboard element เพิ่มเติมว่าเป็น Editor หรือ Reader โดยมี element ที่สามารถกำหนดสิทธิได้ดังนี้: KPI, scorecard, report, data source และ indicator โดยข้อมูลดังกล่าวจะไปรวมกับ Filter ที่ตั้งไว้แล้วนำเสนอให้ user เห็นบน Webpage ผ่านทาง SharePoint Service

Important
หากมีการกำหนดสิทธิ Reader ให้ Authenticated Users จะหมายความว่าผู้ใช้ที่ log on เข้า Domain ทุกคนจะสามารถ
เห็นข้อมูลใน dashboard element นั้นๆ แต่ข้อมูลที่เขาจะสามารถเห็นได้ขึ้นอยู่กับ Setting เรื่องการเข้าถึงข้อมูลใน
Data Source อีกครั้ง  กรุณาอ่านหัวข้อถัดไปเพิ่มเติม 

2. สิทธิใน SharePoint Server หรือ SharePoint Service
เป็นการควบคุมสิทธิในการเข้าถึงหน้ากากในการดู Webpage บน PPS M&A ถ้า user ไม่มีสิทธิในการเข้า SharePoint ก็จะเข้าถึง Webpage ที่ render จาก PPS M&A ไม่ได้

Important
คุณสามารถเลือกกลยุทธ์ในการ set security ในระบบได้หลายอย่าง ตัวอย่างเช่น

(a) ให้สิทธิในระบบ SharePoint Service ให้กับทุกคน แต่มา limit สิทธิในระบบ PPS M&A วิธีนี้จะทำให้ user สามารถ
เห็นได้ว่าคุณมีีรายงานอะไรบ้างบน Intranet แต่อ่านจะไม่สามารถดูรายงานได้เนื่องจากไม่มีสิทธิ  นอกจากนั้นยังสามารถแบ่งสิทธิใน
การเข้าถึงข้อมูลที่แตกต่างกันออกไปโดยกำหนดใน Element ในระบบ PPS M&A ที่ต่างกันออกไปได้  โดยจะขึ้นอยู่กับ design
ของ Element ตัวอย่างเช่นมีกำหนด KPI เป็นของสินค้ากลุ่มสุรา และสินค้ากลุ่มเบียร์  เราอาจจะให้สิทธิในการเข้าถึง Dashboard
กับ User ทุกท่าน แต่กำหนดสิทธิในการเข้าถึงข้อมูลในระดับ KPI ที่แตกต่างกันขึ้นอยู่กับ Security Group ใน Active
Directory ได้

(b) ให้สิทธิในระบบ SharePoint Service ให้กับกลุ่มคนจำกัด  แต่กำหนดสิทธิใน PPS M&A เป็น Authenticated User
All domain users) วิธีการแบบนี้จะไม่ค่อยยุ่งยากในการจัดการในจัดการสิทธิในระบบ PPS M&A โดยจะไปจัดการใน
Sharepoint แทน  ซึ่งหมายความว่า User อาจจะมองเห็น link ใน sharepoint ไม่เหมือนกัน แต่จะเห็นข้อมูลในระบบ
PPS M&A เหมือนกัน  ถ้าต้องการทำให้เห็นข้อมูลไม่เท่ากัน อาจจะต้องใช้ลูกผสม (เหมือนในหัวข้อ c) หรือไม่ก็ต้องไปจัดการสิทธิ
ที่ Data Source แทน

(c) แบบลูกผสม คือมีการกำหนดสิทธิเป็นกลุ่มๆ ทั้งในระบบ SharePoint และระบบ PPS M&A

3. สิทธิในการเข้าถึง Data Source
การกำหนดสิทธิแบบนี้จะขึ้นอยู่กับประเภทของ Data Source ที่ใช้ ถ้า Data Source เป็นไฟล์ก็จะจัดการอะไรมากไม่ได้ได้ ถ้าเป็น Database ก็อาจจะให้กำหนดสิทธิในการเข้าถึงข้อมูลว่าดูได้ หรือ ดูไม่ได้ แต่ไม่สามารถจำกัดช่วงของข้อมูลได้ (เช่น จำกัดสิทธิตามสาขา หรือ ประเภทสินค้า) แต่ถ้า Data Source เป็น Cube อยู่แล้วก็สามารถใช้ Role ของ Cube ในการจำกัดการเข้าถึงข้อมูลได้ ทั้งนี้จะต้อง set ค่าที่ Application และ Web Config ให้ถูกต้อง โดยจะแบ่งได้ 3 แบบดังนี้
3.1 Application Pool
การเชื่อมต่อแบบนี้จะใช้สิทธิของ user ที่กำหนดใน application pool ในการเข้าถึงทุก Data Source
3.2 Per User Connection
การเชื่อมต่อแบบนี้จะใช้สิทธิของ user ที่เข้าใช้ PPS M&A ในการเข้าถึง Data Source โดยในกรณีนี้จะต้องมีการ Delegate สิทธิจาก user ไปยัง process บน PPS M&A
3.3 Custom Data
การเชื่อมต่อแบบนี้จะยังใช้สิทธิแบบ application pool ใน initial connection จากนั้นจะใช้ Setting ใน connection string ในการเช้าถึง Data Source โดยเราสามารถ customize เพื่อส่งข้อมูลผู้ใช้ไปให้ process บน PPS M&A ให้ทำงานคล้ายกับกรณีของ Per User Connection ได้

ในการทำงานจริงจะเห็นว่าการ set ระบบจะใช้องค์ประกอบของการตั้งสิทธิทั้ง 3 ส่วน( 1 - 3) การติดตั้งระบบ โดยแต่ละ combination อาจจะมีข้อดีข้อเสียแตกต่างกันออกไปบ้าง เพื่อให้การตั้งสิทธิใน project team เป็นไปในทิศทางเดียวจึงใคร่ของให้แนวทางในการตัดสินใจดังนี้:

Data Source	No. of User	Recommened Setting	Note
MS Excel	N/A	เนื่องจากไม่สามารถอาศัย Data Source ในการกำหนดสิทธิเนื่องจากเป็น File และยังคงต้องการให้ integrate กับ AD ได้ ในกรณีนี้จึงแนะนำให้ใช้แบบ Application Pool โดยยังคงให้ใช้ User หรือ Security Group ใน AD เป็นตัวช่วย โดย Security Group ดังกล่าวยังสามารถนำไปในการกำหนดสิทธิในการเข้าถึง Webpage บน SharePoint Service ได้ด้วย	หากเป็น Multiple Security Domain อาจจะทำให้ยากในการกำหนดสิทธิ
DB Table	N/A	ขอแยกกรณีนี้ออกเป็น 2 กรณีย่อย (1) กรณีที่ผู้ใช้ไม่จำเป็นต้องอ่านข้อมูลโดยตรงจาก Database ให้ใช้แบบ Application Pool และอาจจะใช้ feature ของ securable ใน MS SQL Server เพื่อจำกัดสิทธิในการเข้าถึงข้อมูลใน database โดยตรงของ user ที่ใช้ในการติดตั้ง application pool (2) กรณีที่ผู้ใช้ต้องอ่านข้อมูลโดยตรงจาก Database เช่น ใช้ pivot table จากบน MS Excel เชื่อมต่อกับ Database เพื่อออกรายงาน หรือ วิเคราะห์ข้อมูลต่างๆ เพิ่มเติมเอง ในกรณีนี้เพื่อให้เกิดความ consist ระหว่าง user ที่จะ access เข้าไปที่ database โดยตรง และการ Access ผ่าน PPS M&A ควรจะใช้แบบ Per User Connection
OLAP Cube	N/A	กรณีที่ผู้ใช้ต้องอ่านข้อมูลโดยตรงจาก OLAP Cube เช่น ใช้ pivot table จากบน MS Excel เชื่อมต่อกับ Cube เพื่อออกรายงาน หรือ วิเคราะห์ข้อมูลต่างๆ เพิ่มเติมเอง ในกรณีนี้เพื่อให้เกิดความ consist ระหว่าง user ที่จะ access เข้าไปที่ Cube โดยตรง และการ Access ผ่าน PPS M&A ควรจะใช้แบบ Per User Connection	Scenario แบบนี้น่าจะเป็นแบบที่ใช้บ่อยที่สุดใน Project