Resticting VMS access to DBAs ?

[Chris Barratt]

Here is a typical sample, slightly changed for posting purposes....

Object type: file, Object name: SAN$03:[IMSPRODN.RDB]IMS_MST_DATABASE.RDB;2, on 19-APR-2006 13:22:21.24

(IDENTIFIER=[USER,SPECIALUSER1],ACCESS=READ+WRITE+RMU$ALTER+RMU$ANALYZE+RMU$BACKUP+RMU$CONVERT+RMU$COPY+RMU$DUMP+RMU$LOAD+RMU$MOVE+RMU$OPEN+RMU$RESTORE+RMU$SHOW+RMU$UNLOAD+RMU$VERIFY)
(IDENTIFIER=[USER,SPECIALUSER2],ACCESS=READ+WRITE+RMU$ALTER+RMU$ANALYZE+RMU$BACKUP+RMU$CONVERT+RMU$COPY+RMU$DUMP+RMU$LOAD+RMU$MOVE+RMU$OPEN+RMU$RESTORE+RMU$SHOW+RMU$UNLOAD+RMU$VERIFY)
(IDENTIFIER=[USER,SPECIALUSER3],ACCESS=READ+WRITE+RMU$ALTER+RMU$ANALYZE+RMU$BACKUP+RMU$CONVERT+RMU$COPY+RMU$DUMP+RMU$LOAD+RMU$MOVE+RMU$OPEN+RMU$RESTORE+RMU$SHOW+RMU$UNLOAD+RMU$VERIFY)
(IDENTIFIER=IMS_READ,ACCESS=READ+EXECUTE)
(IDENTIFIER=IMS_UPDATE,ACCESS=READ+WRITE+EXECUTE)
(IDENTIFIER=IMS_MANAGER,ACCESS=READ+WRITE+EXECUTE+CONTROL)
(IDENTIFIER=[OPERS,*],ACCESS=READ+WRITE+RMU$ALTER+RMU$ANALYZE+RMU$BACKUP+RMU$CONVERT+RMU$COPY+RMU$DUMP+RMU$LOAD+RMU$MOVE+RMU$OPEN+RMU$RESTORE+RMU$SHOW+RMU$UNLOAD+RMU$VERIFY)
(IDENTIFIER=[1,*],ACCESS=READ+WRITE+RMU$ALTER+RMU$ANALYZE+RMU$BACKUP+RMU$CONVERT+RMU$COPY+RMU$DUMP+RMU$LOAD+RMU$MOVE+RMU$OPEN+RMU$RESTORE+RMU$SHOW+RMU$UNLOAD+RMU$VERIFY)

The special users accounts are used by IT support staff or batch jobs. The ims_read and ims_update are gratned to user accounts that access the database. ims_update is for support users that need to change metadata in database (but mostly not used at the moment). The [opers,*] entry is for our operators who initiate backups. The [1,*] is for system manager/DBA type accounts who need access - but we don't always have a clear delineage here between the 2 roles.

You will have to use your own judgement on whether this is good security or not, but it seems to work for us. :-)

[Chris Barratt]

oops !

>ims_update is for support users that need >to change metadata in database (but mostly >not used at the moment).

this should have said ims_manager not ims_update !

[Robert Gezelter]

Chris and Thomas,

A (strong) suggestion concerning the ACLs that were posted in an earlier posting. Do not use ACLs with individual or group UICs (e.g., [1,*]).

It is far superior, from both an auditing and control perspective, to express the access in terms of roles, which can be granted to (and/or revoked from) individuals. Both of the cases cited above fall into this category.

Authorizing an individual UIC for a category of access prevents tasking another individual from being tasked with those function without violating important tennets of security policy and auditing, to wit:
- giving them access to either the account (creating a situation where two people have access to the same account) OR
- granting access (and then removing access) every affected ACL to add the temporary access, an extremely time consuming and error prone operation.

Group permissions pose a similar problem. Granting access to an entire group makes it impossible to revoke access for an individual within that group without:
- revoking access for the entire group
- editing each and every ACL to insert a DENY access for the affected member of the group
- removing the affected individual(s) from the group in question (which has cascading issues)

It is far more efficient, safer, and auditable to grant access rights based upon non-UIC rights identifiers, and then grant those identifiers to user accounts. This is quite efficient (computers make excellent clerks) and it is emminently auditable.

- Bob Gezelter, http://www.rlgsc.com

[Robert Gezelter]

Thomas and Chris,

My apologies for omission from my preceding posting.

I have used this precise approach at clients without a problem (performance, management, or auditor-caused) on multiple occasions. Those experiences formed the backdrop to my hands on workshop at HP World 2004 on OpenVMS User Environments. The summary notes (alas, not the workbook) for that workshop can be found at http://www.rlgsc.com/hpworld/2004/N227.html.

- Bob Gezelter, http://www.rlgsc.com

[Robert Gezelter]

Thomas and Chris,

My apologies for omission from my preceding posting.

I have used this precise approach at clients without a problem (performance, management, or auditor-caused) on multiple occasions. Those experiences formed the backdrop to my hands on workshop at HP World 2004 on "OpenVMS User Environments". The summary notes (alas, not the workbook) for that workshop can be found at http://www.rlgsc.com/hpworld/2004/N227.html.

- Bob Gezelter, http://www.rlgsc.com