Tsm security : segregation of duties

[juanenzo]

Hello,
We have an internal audit issue. The auditor doesn't want that tsm admin people can access backup data and primary data on the clients. Of course being a tsm admin you need some privileges in tsm and on the os clients win and linux to be able to perform your daily job.
On the client : we need administrator rights to install the tsm baclient and tdp software and to look into logfiles for problem solving, starting backups manually, starting the gui for performing restores if htpp access doesn't work.
On the tsm server : related to be able to touch the backup data, meaning for instance executing delete filesystems to cleanup remaining backup data of decommissioned clients ...

Has sombody else the same issue with internal audit in the company, and could solve it without restricting the daily work.

Thanks

 

[marclant]

We have an internal audit issue. The auditor doesn't want that tsm admin people can access backup data and primary data on the clients. Of course being a tsm admin you need some privileges in tsm and on the os clients win and linux to be able to perform your daily job.

That's not going to be possible. You need the SYSTEM class to fully administer a TSM Server and with that comes access to all data.

On the client : we need administrator rights to install the tsm baclient and tdp software and to look into logfiles for problem solving, starting backups manually, starting the gui for performing restores if htpp access doesn't work.

On Windows clients, you can do backup/restore as backup operatores as opposed to administrators. Not sure if there is something equivalent on Unix. Also if the web client doesn't work, the procedure could be to fix the webclient first, then perform the restore, instead of bypassing the webclient to perform the restore.

On the tsm server : related to be able to touch the backup data, meaning for instance executing delete filesystems to cleanup remaining backup data of decommissioned clients ...

That's not going to be possible. You need the SYSTEM class to fully administer a TSM Server and with that comes access to all data.


Now, if you have multiple TSM admins, they do not all need SYSTEM class. You may have operators, etc., and you could use lower authority classes. Use HELP GRANT AUTHORITY to see all the classes.


As a former auditor, an important aspect of auditing is accountability. So if each TSM administrator have their own admin ID (they should), then all the commands they issue are logged in the activity log.

 

[moon-buddy]

When it comes to security, this question has been on the discussion list for a long time.

I have worked with various environments and the ones that needs strict security measures do have this setup:

- The TSM admin only works with the TSM server
- The System admins works on the nodes - install, configure, and troubleshoot
- DBAs works on all TDP related matter

In other words, the TSM administrator provides the service while the system admins/DBAs use the service. Service here means the Backup and Restore service.

This is my current setup. I don't have access to any node (web access is disabled and no login privileges) and for that matter, the various system admins/DBAs are the only ones that does backups and restores.

It takes discipline to roll out something like this, and a lot of ITIL processes involved to achieve this.

 

[marclant]

I have worked with various environments and the ones that needs strict security measures do have this setup:

- The TSM admin only works with the TSM server
- The System admins works on the nodes - install, configure, and troubleshoot
- DBAs works on all TDP related matter

That's the best approach.

 

[molerio]

When it comes to security, this question has been on the discussion list for a long time.

I have worked with various environments and the ones that needs strict security measures do have this setup:

- The TSM admin only works with the TSM server
- The System admins works on the nodes - install, configure, and troubleshoot
- DBAs works on all TDP related matter

In other words, the TSM administrator provides the service while the system admins/DBAs use the service. Service here means the Backup and Restore service.

This is my current setup. I don't have access to any node (web access is disabled and no login privileges) and for that matter, the various system admins/DBAs are the only ones that does backups and restores.

It takes discipline to roll out something like this, and a lot of ITIL processes involved to achieve this.

Hello,
We have an internal audit issue. The auditor doesn't want that tsm admin people can access backup data and primary data on the clients. Of course being a tsm admin you need some privileges in tsm and on the os clients win and linux to be able to perform your daily job.
On the client : we need administrator rights to install the tsm baclient and tdp software and to look into logfiles for problem solving, starting backups manually, starting the gui for performing restores if htpp access doesn't work.
On the tsm server : related to be able to touch the backup data, meaning for instance executing delete filesystems to cleanup remaining backup data of decommissioned clients ...

Has sombody else the same issue with internal audit in the company, and could solve it without restricting the daily work.

Thanks

We use a modified form of Moon Buddy's setup:
TSM admins work on the TSM servers ( TSM & AIX) since we run TSM on AIX.
the OS sysadmins are responsible for tsm client setups EXCEPT TDP & LAN Free & TSM 4VE BUT they do all the restores.

We have access to any UNIX client via the BreakGlass application which grants us sudo as root since our DBA's are too good to be bothered with checking why their backups fail.

 

[juanenzo]

Thanks for all replies the story is complicated currently we give end to end support, client and tsm server side.

 

[moon-buddy]

Thanks for all replies the story is complicated currently we give end to end support, client and tsm server side.

Then, the wishes of the Auditors cannot be achieved without ROLE-based access limitations, i.e., what I posted above.

 

[juanenzo]

Then, the wishes of the Auditors cannot be achieved without ROLE-based access limitations, i.e., what I posted above.

We have for each tsm admin a different user with system privileges , so logging can be done in actlog. For our helpdesk they have node access on a few clients to be able to perform restores only. I'm also not happy with system administrators on win or linux they can launch the dsmc command and restore whatever they want even from other clients if they know how to do it. By using the gui with http, we setup that they have to provide a tsm user and pwd which they don't have so in that way no restores can be done by them. By launching normal gui locally on the client they still can do it.
I will have a deeper look into tsm and security. The role based is a good think of course a lot of processes must be adapted and you know as well if the problem solving is spread over different teams, nobody feels responsible. I experianced that many times. A system admin doesn't like to solve backup incidents. Another story behind for tdp is that these jobs are planned by using opc job scheduler meaning they can blow up our tsm servers, they all want there backups running and finishing quickly and don't care about other backups. For oracle i'm busy setting up a tsm server without having other backups runnng. If they blow up that tsm server , no impact for others and there own fault.

{fixed quotes}