TM1 Forum

Hi,

I am currently struggling with a customer request as follows :

. a Payroll Application has been built with 3 specific cubes which are populated with TurboIntegrator processes and which contain rules for automatic calculations of Payroll Components.
. since the Cubes contain confidential information, the TM1 ADMIN, DataAdmin and SecurityAdmin Groups are to be restricted and should not see any data in the 3 Payroll Cubes
. however, the ADMIN role should still be able to edit the TI Processes and Cube Rules if this would be required.

Basically, the question is how can a User from an Admin Group in TM1 be restricted from seeing any data - by default, by being a user of an Admin Group it means you have all Admin Rights including Read/Write Access to Data.

Assigning the TM1 User (in this case the TM1 Administrator who maintains the overall TM1 environment) to a 'normal' User Group enables to restrict access to data. However, in this case, that user can only read and execute TI Processes. Editing of TI's/Rules is possible BUT saving the changes is not possible.

To my opinion, the only way is creating a new TM1 Payroll Instance where the ADMIN role is assigned to another person (let's say the Payroll Super User) and the real TM1 Administrator (i.e. the User who maintains the overall TM1 environment) is not a user within that separate Payroll Instance.

Please advise me if this would be the only solution since I was hoping the TM1 Security within the same instance would be able to deal with this - I assume that this request is not so exotic, especially lately where TM1 Applications are subject to GDPR and TM1 Admin Users are to be restricted from accessing Personal-related data.

Looking forward to any reactions ...

Hello Stefan,

To me, unless I miss something, this is also the only way to implement this. Admin means everything.
Maybe data reservations or security overlays could be an option but that's not obvious and needs to be looked at. I have no ready-made answer.

If it's a different TM1 model, you would also lock access to the data directory of the other instance, and other access to files in general, for example.
And use a password that goes beyond 'apple' or any other obvious choice or pattern (like username - password is 'first name - first name')
If data comes back to the main model, it should be done in such a way that for example salaries are not visible (like in, you see as an admin person the salary costs of an entire department by functional role, but there's only 1 person with that functional role working in the said department).

Best regards,

Wim

Hi Wim,

good to hear you again on the forum here - I do agree with your additional comment that a separate environment would also require limited access to the TM1 Data Directory and other directories. Also, in the separate instance for Payroll, then ADMIN LogOn will have to have a dedicated password.

As you also state, the resulting calculations will need to be transferred at later stage to a P&L Cube within the broader application, so the transfer process will have to generate ASCII Output Files from the Payroll Instance to be imported to the Main Instance in such a way that the level of detail does not give way to what is considered as too confidential (e.g. 1 person in 1 single cost center).

Thanks for your reply, and definitely it confirms my initial concern that only a separate TM1 instance could resolve this request.

As per statement of a colleague consultant, I guess it would make sense that IBM would come up with a new upgrade feature of TM1 where the admin would be able to access all the objects but where data would be automatically encrypted for such profile (credit to Xavier VDL for this).

sleoni72 wrote: ↑Thu Mar 22, 2018 12:43 pmAs per statement of a colleague consultant, I guess it would make sense that IBM would come up with a new upgrade feature of TM1 where the admin would be able to access all the objects but where data would be automatically encrypted for such profile (credit to Xavier VDL for this).

Maybe a fourth category:

- Admin
- SecurityAdmin
- DataAdmin
- Admin with limited data access

Just thinking out loudly.

sleoni72 wrote: ↑Thu Mar 22, 2018 12:43 pm Thanks for your reply, and definitely it confirms my initial concern that only a separate TM1 instance could resolve this request.

Hi sloeni72,

I now find myself in exactly the same situation, need to prevent access to confidential data from other Admin users and my considerations came to the same conclusion, i.e. having a separate TM1 model for that purpose with very limited access, and some further impacts related to that approach:

• Protection required on file level as well
• Even a different service user should run the confidential TM1 service, as current service user credentials are part of documentation of "normal" environment
• Real-time calculation into GL accounts for personnell costs or into PNL of main application not possible due to required file transfer
• All support requests will hit the one administrator of the confidential model, colleagues cannot support here (by the way this is my main concern)
• Significant portion of total effort for this HR module goes into those extra measures, without adding value from a functional point of view

Would you mind to share your experience? How did you finally approach this requirement? Any suggestions and recommendations, lessons learned?

Thanks a lot!

Hi,

• "Protection required on file level as well": you can use tm1crypt utility: https://www.ibm.com/support/knowledgece ... ption.html

• "Real-time calculation into GL accounts for personnell costs or into PNL of main application not possible due to required file transfer": you can make a "near real-time calculation" by using a TI process (datasource=ODBO) ran by User, or you can use REST API to transfer data

• "All support requests will hit the one administrator of the confidential model, colleagues cannot support here": for support requests like "Explain the value in this cell" - yes. But if you have a request to change the code, you can have an "HR_Dev" server with obfuscated data so that other developers can participate. And yes, the HR_Admin will have to move from "HR_Dev" to "HR_Prod" server

I did this once with a separate tm1 model that ran on a separate / isolated server that had file system level encryption and a different set of OS user accounts.
Data was transferred to the main model using file transfer, but files were PGP encrypted. HR server would export the encrypted files to the target server and kick off runTI to decrypt & ingest them.

It was before data encryption was supported in Tm1, so built-in encryption might be a better choice of doing it now. The challenge I see with encryption is that you'd need to change the way you promote changes, file copy & restart wouldn't work anymore. Using Git would solve this though, as well as allow looking into the rules / TI code without seeing data, I think it might be a good area to investigate.

Re DEV_HR servers -- there's some undocumented data obfuscation capability ( http://feederwhisperer.blogspot.com/201 ... -your.html ) that should allow you to copy prod to dev without exposing anything of value.

Cheers