How to restrict developers from viewing sensitive information in system

[Chuks]

Hi All,

Is there any way that we could restrict a developer with admin access from viewing a particular cube data? Or can we create a group which can do all work similar to admin, but no access to sensitive cubes?

Thanks for your inputs.

[BariAbdul]

Yes,You need to create extra group named 'Admin' and restrict the access to it according to your requirement.Thanks

[lotsaram]

... well you can't create a group called "Admin" because that is a built in group with built in (god of the server) access rights, and try as you might you won't really be able to change those rights. If a user is admin then they can see everything, edit everything, destroy everything, etc, etc.

You can create alternative groups that have admin rights on cubes, dimensions, application folders but excluding certain cubes and assign developers or sys admins rights to these other groups and not the built-in Admin group. But you run into some trouble with TI processes as for non Admin and DataAdmin users processes can only be assigned as READ or NONE with no ability to edit. If your environment is full D-Q-P then this may not be an issue as processes will never be edited on prod.

The other alternative is to segregate the sensitive data to another instance with more restrictive access but usually this is solved with NDA, separation of duties, etc. (not to mention trusting people .

[BariAbdul]

Thanks a lot ,lotsaram.

[paulsimon]

Hi

I would suggest that you have a development environment with just test data in the sensitive cube. Developers can be in the Admin group on that environment. You then ensure that the developers have ordinary user rights in the production environment, eg NONE access to the cube holding sensitive data. In that way the developers can still develop using the structure of the sensitive cube, but they cannot see sensitive data.

I and probably a number of other developers have routines that manage automated promotions of code to the production environment. These can be put under the control of IT Ops, so the developers can specify the .pro, .rux etc files that are to be promoted, but they cannot actually promote them themselves and they have no access to the production server file system.

The problem with this is then who supports production problems? Sometimes it will need more than end-user access to investigate these.

Even if you bar developers from the production environment, you would probably need some sort of code review meeting to stop a developer from promoting a process that changed the security on the sensitive cube or exported the data from the sensitive cube to a different cube or to a file they could pick up, etc.

The DataAdmin and SecurityAdmin groups were an attempt to implement SOX requirements in TM1, but they can be too restrictive. Ultimately the only real defence is to have someone reviewing all the code that goes into production and ensuring that there is no collusion. However TM1 teams are not usually big enough to allow for this. IT Ops won't understand the TM1 code without a lot of training.

TM1 data isn't normally that sensitive. The issues are normally around Salary data. I have seen various approaches to this, such as trust the TM1 developer - after all you have to trust someone - some people in Finance and HR will have access to this data. Or hold the data at a summary level, etc total for a Dept (although if there are two people in a Dept and you are one of them, you can do the maths), Or anonymise that data, eg a random number instead of an Employee Name, etc.

These are issues that are common to any development tool, not just TM1

Regards

Paul Simon