Page History

...

We have not succeeded in using oracle roles. There are currently two reasons for this:

• All of our software currently assumes it is using a particular "default" schema. We have not figured out how to set up oracle connection aliases such that a particular default schema is set automatically when using a role account. So to use roles we would have to change all of our software which is not possible at the current time.
• Role accounts do not appear to allow one to modify database tables, so even if we get them working we would still need to share passwords to the owner accounts with developers.

Since we have not succeeded in getting roles working we still have to share passwords for all of our service accounts with users, and they still need to embed these passwords in their development environments. Everytime the passwords are changed we need to inform developers and they will need to waste more time updating their configuration files.

In conclusion we have spent a considerable amount of time on setting up oracle wallet and experimenting with roles etc. This effort will enable us to change oracle passwords in the future without downtime for our critical servers, but has resulted in a system which is currently considerable less secure than before. In future we should ensure that the security team

• Gives experiments sufficient lead time for such security related changes. This would typically be at least one year.
• Discusses it detail with the experiment the need for such changes.
• Ensure that an accurate assessment of manpower required implement changes is established at the outset, including manpower needed to research solutions before deciding on and implementing the solution.
• Where possible the manpower to implement such security changes should come from SCCS itself, and the resulting solutions should be documented and made available to everyone in the lab.